Interviewing for Intelligence
refer.ly
refer.ly
A lot of advice I've read about interviewing suggests that a candidate should leave answers open and provide room for the interviewer to poll for more info. I'm curious to know if the author goes out of their way to poll about the specifics of the hash table implementation?
In fact, one of my favorite interviews in recent memory was a hash table discussion not unlike the one the author is hoping for. I was happy to find an interviewer whose questions balanced theory with practice and was happy to drive to a solution with them. However, I wouldn't have offered up this analysis without first understanding that this is where the interviewer wanted to drive the discussion. Every good programmer knows that premature optimization is the devil.
The author may instead be trying to raise the point that its up to the discretion of the interviewee to see that the hash table implementation is the critical performance detail. e.g. gotta do open addressing here b/c our hashing function has weird edge cases where it collides all the time and chained hash would bring us closer towards a log(n) traversal on that edge case.
However, in my limited interviewing experience, interview problems such as this are often designed to be open-ended conversation rollers moreso than where implementation specifics like this are able to jump out easily.
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)
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.
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.
Number 2 is a lot harder to determine than number 1 in my experience. You can determine if someone is a good programmer by having good programmers ask them increasingly challenging programming questions. The hard part is figuring out if they are an effective and productive employee.
You humorously contrast your essay to a "randomized clinical trial," but to be matter-of-fact, these trials exist: IQ tests or their politically acceptable stand-in, the SAT.
I guess what I'm asking is this: what's stopping you from requesting something like the SAT even if it's only for curiosity's sake?
If asked a question completely outside their domain of expertise, they wouldn't bail on it but instead start trying to find an answer.
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?
If you want someone to BS answers all day long, then you're hiring for a CEO.
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..."
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.
And of course his "appeal to authority" consists in citing an article from the totally and utterly overrated Spolsky...
Dismissed.
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.