Why we don't hire programmers based on puzzles and tricks

Are completely different questions. The first is useless: It tests if someone remembers how a heap sort works, and whether or not they use the term "worst case" in the answer.

The second one is much better. Some could sort the list, (nlogn time, constant memory) then walk through it. They could use a hash table (idealy n time, assuming no collisions, but more memory). You also get to see if their solution handles the 0 case. If they answer it very quickly, you can move on to the three sum problem. If they recognize the question from university or something you can do a different one.

If someone doesn't know the big-O time of iterating through a list of integers once for every integer, then I seriously doubt their dedication to the field of software. This is not some pie in the sky doubt, it is of legitimate concern whether someone knows how to properly approach a problem of this nature with the right data structures, code, and communication.

Good interviewers put the interviewee at complete ease before they bring out the technical questions. From an economics point of view, it is better to hire the person that is in all other ways identical, yet interviews poorly, since they are less likely to want to leave.

Let's just summarize the points:

- Not everyone can produce real-world code. Most of what we do for a living belongs to our employer. Side projects, particularly in the US, can be an issue for IP reasons (California is somewhat of an exception here);

- Side projects, even open source projects, can be of questionable "real world" value;

- I've personally encountered many "programmers" who can talk a good game but can't code a for loop;

- tests like the FizzBuzz test [1] are, in my experience, remarkably effective as an early negative filter. This is an important point. If someone blows you away at FizzBuzz, it doesn't mean they're an awesome engineer. But if they can't do it, it almost certainly means they aren't. The idea here is to spend the most time with candidates who might potentially work out and wasting as little time as possible on those that probably won't;

- the problem with these kinds of whiteboard coding problems is that the tendency is for interviewers to think the problem needs to be "hard". It doesn't. In making it too hard (IMHO) you risk destroying the value of your filter;

- pop-quizzes of obscure language features, the kind that might appear in certification exams, are a waste of time. I have no argument with that;

- whiteboarding code by itself is not a great filter. It should be used in conjunction with a multi-faceted interviewing approach that involves testing fundamentals, the ability to construct a relatively simple algorithm, the issues of working on a team and on a production code base and systems design.

- the problem with simply talking about "real world" code, as the author suggests, is you're no longer finding a good engineer, you're finding someone you like, someone who thinks like you. This falls under the umbrella of cultural fit, which is of course important, but don't mistake that for engineering skill.

- I think we can all agree that "logic" puzzles like "how would you move Mount Fuji?" or "if you shrunk to 1cm in size and dropped in a blender, what would you do?" are stupid.

- testing "back of the envelope" estimation however can be useful. I mean things like "how much storage is required to store satellite images for Google Maps?" The idea isn't to get an accurate answer. It's to see what assumptions the candidate states and, based ont hose assumptions, to come up with a reasonable ballpark number.

The problem here is that there are many engineers who can't comprehend the possibility that there is someone being paid to be a programmer who can't code. But I assure you this is the case. It's shocking but true. Simple coding tests largely filter these people out so if you're offended by such simple tests, just do it and move on. I assure you there's a reason why they exist.

One final prediction: There's some guy here on HN who always posts the exact same huge comment on any hiring thread. I'm sure it'll pop up any moment now.

EDIT: let me add a point about trial periods and take home assignments.

Both of these are guaranteed recipes for mediocrity. Truly outstanding candidates need to justify the time investment for either option and very few companies have the kind of gravitas that would justify it.

Anything written without supervision will be of questionable provenance at best.

As for whether or not someone will work out in your organization, bringing them in for a day is (IMHO) of questionable value. Many engineers are introverts. I include myself in this. It's incredibly awkward as is to be in a new company or even a new team in the same company. I question the value of any such assessment over what you learn in 1-4 hours of interviewing.

[1]: http://www.codinghorror.com/blog/2007/02/why-cant-programmer...

More importantly, the elevator control system uses mathematical expertise that is normally used solving variants of the multi-commodity flow problem, used extensively in the Supply Chain.

The sad truth about this is that I think many companies are afraid an employee will leave shortly after receiving training. They fear that a competitor will entice away the employee without incurring the training cost. Of course, one way to avoid this is to make the work environment desirable enough so that no one wants to leave but that takes effort.