> 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.<p>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?<p>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.<p>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.<p>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.
I've heard the Singapore civil service, renown for recruiting smart people, have what they call the 'helicopter test'. Specifically they are looking for people who are just as able to converse intelligently flying 1000 feet above a topic as they are skimming the surface and getting into the details, and will specifically test candidates on both perspectives and their ability to fly between the two. Seems well aligned with what you are looking for.
"You’re looking for people who are 1) smart and 2) get things done"<p>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.
the author seems to be in the business of creating fairly simple internet apps, so I'm not sure why his interviews would ever need to deal with the implementation of hash tables...
I agree with the value you place in intelligence and like how you qualify your essay as a discussion, but in perspective, your methods are simply imprecise and as you said, anecdotal.<p>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.<p>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?
I interview for maturity, discipline, and honesty. My codebase is made to be maintainable by most programmer. I dont include any magic and make sure that it is understandable. But I don't interview for intelligence. Because intelligence without the three factors I look for does not mean a thing.
This is confusion of intelligence and knowledge. I don't know how a hash function works...but that is a reflection of my experience, not my intelligence. I did not study to be a computer scientist...but I sure as hell can optimize your supply chain.
In which alternate universe would the exact formula needed to compute the GDP be absolutely crucial to explaining what a liquidity trap is?<p>And of course his "appeal to authority" consists in citing an article from the totally and utterly overrated Spolsky...<p>Dismissed.