Live data from Hacker News

Interviewing for Intelligence

refer.ly

11–20 of 29 posts

Re: Interviewing for Intelligence

#11
post #7

Confidence: If asked a question completely outside their domain of expertise, they wouldn't bail on it but instead start trying to find an answer.

It's a weird balance that people are looking for confidence and intelligence at the same time. Some intelligent people are humble about the subjects they lack expertise in. Doesn't looking for confidence carries a risk of finding people who sound better than they are?

I agree. If I am asked a question outside of my domain of expertise, I'm not going to BS around it. I will say that I don't know and start asking questions so that I can learn the topic.

If you want someone to BS answers all day long, then you're hiring for a CEO.

Re: Interviewing for Intelligence

#12
post #5

Wait, when did refer.ly pivot from being a startup helping people with affiliate marketing and social shopping, to an online magazine?

i have the same question - i could have sworn just the other month when the betapunch post came out referly was still the referral tracking system

Referly CEO here - We've been headed in this direction for awhile, but just crossed over (with the new tagline) about a week ago. An in-depth blog post from me about the change and our new direction, plus a ton of stuff we learned, is forthcoming - probably this weekend if I can sit down for a few hours and knock it out. I'd really appreciate any feedback you have on the new experience, both as a reader and as a contributor (if you decide to go that far).

Re: Interviewing for Intelligence

#14
post #4

> It's surprising to me how many candidates explain these algorithms' performance as if the hash table was a magic black box that instantly works. Here they've lost the tree for the forest! They know what hash table is, at least at a high level, but forget that it has specific implications. A lot of advice I've read about interviewing suggests that a candidate should leave answers open and provide room for the interv…

The whole "forest = knowing how a hastable works" is interesting! I'm trying to ascertain if the author's forest is a tree. I think there's good and evil in that statement.

Good being that its groovy if you love what you do are curious. Evil in that he could be optimizing the wrong thing.

Does every great software engineer have the inner workings of every data structure committed to memory? (I don't)

Re: Interviewing for Intelligence

#15
post #10

Confidence: If asked a question completely outside their domain of expertise, they wouldn't bail on it but instead start trying to find an answer.

That's also the sign of a bs'r You know, the person who knows nothing about a topic, but will talk for hours on it? There should never be shame in admitting "I don't know" and then following it up with, "but if faced with that I would..."

What I have found to be interesting is that the more I learn about a technical topic, the less confident I become. Because I am now more aware of how much I don't know, or about how a small detail can make a big difference.

I used to think I was pretty knowledgeable about web security. The more I learn about it, and about how easy it is to get it wrong, or overlook something important, the less confident I feel in my ability to implement a secure web app.

Re: Interviewing for Intelligence

#16
In which alternate universe would the exact formula needed to compute the GDP be absolutely crucial to explaining what a liquidity trap is?

And of course his "appeal to authority" consists in citing an article from the totally and utterly overrated Spolsky...

Dismissed.

Re: Interviewing for Intelligence

#17

In which alternate universe would the exact formula needed to compute the GDP be absolutely crucial to explaining what a liquidity trap is? And of course his "appeal to authority" consists in citing an article from the totally and utterly overrated Spolsky... Dismissed.

I don't understand what you mean. The author said "Despite his confidence, he couldn't even explain what GDP is, which was essential to his explanation." which seems like a perfectly reasonable complaint. If you are trying to describe a concept to me that I don't know about, I might ask you to explain to me a much more basic idea that you are referring to. If they can't explain the basics then all of the explanation of the original subject matter is wasted.

Re: Interviewing for Intelligence

#18
post #4

> It's surprising to me how many candidates explain these algorithms' performance as if the hash table was a magic black box that instantly works. Here they've lost the tree for the forest! They know what hash table is, at least at a high level, but forget that it has specific implications. A lot of advice I've read about interviewing suggests that a candidate should leave answers open and provide room for the interv…

In the question I was referring to, I don't care if they can implement a hash table. I just want them to recognize that when they compare using a hash table to other alternatives, that looking up items in a hash table has a performance cost.

I agree it would be sort of silly to ask an open ended question and then hold it against a candidate when they don't talk about something as if they're supposed to read your mind.

Re: Interviewing for Intelligence

#19

In which alternate universe would the exact formula needed to compute the GDP be absolutely crucial to explaining what a liquidity trap is? And of course his "appeal to authority" consists in citing an article from the totally and utterly overrated Spolsky... Dismissed.

I wasn't asking the guy an exact formula for GDP, but at least some definition of what it was trying to measure. Aaronc's point below is exactly my concern.

As per appeal to authority, I didn't think I was asseting anything controversial. I doubt you are saying it's better to hire dumb people or just ignore intelligence, so I am confused what you're arguing with here.

Re: Interviewing for Intelligence

#20
post #4

> It's surprising to me how many candidates explain these algorithms' performance as if the hash table was a magic black box that instantly works. Here they've lost the tree for the forest! They know what hash table is, at least at a high level, but forget that it has specific implications. A lot of advice I've read about interviewing suggests that a candidate should leave answers open and provide room for the interv…

In the question I was referring to, I don't care if they can implement a hash table. I just want them to recognize that when they compare using a hash table to other alternatives, that looking up items in a hash table has a performance cost. I agree it would be sort of silly to ask an open ended question and then hold it against a candidate when they don't talk about something as if they're supposed to read your mind…

Hi kevin,

First of all, thanks for replying!

I think without more view of the forest, as it were, I'm finding difficult as a reader to understand the type of analysis you're hoping to get out of your interviewees.

Would you agree that one interpretation of your thesis is to have interviewees be able to adress the "why" behind a given implementation? Your reply suggests that it's not the implementation specifics that you're after, but that was the understanding I got out of the original article.

> I just want them to recognize that when they compare using a hash table to other alternatives, that looking up items in a hash table has a performance cost.

As you obviously know, looking up items in a hash table has exactly a constant performance cost (amortizing the cost of a resize, and accounting for load factor, etc.), making it an attractive solution in cases where you need a lookup. I'm curious if your point is that the interviewee is missing that nasty c constant in front of the big o, (e.g. computing a hash for an item or the cost of a resize is impractical, say) or if the issue is that they are just missing something big picture and fundamental given the problem statement.

The former really speaks of "losing the tree for the forest", as in the person black-boxed something they needed to open up, whereas the latter strikes me as more of a lack of conceptual reasoning.

Thanks for your time! I noticed I was downvoted, so apologies if my inquiry frustrates or upset you.

Post reply on HN