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

I think the point of the article is this:

Trivial puzzlers like:write a fizzbuzz program, swap two variable contents without using a temp variable, how do you count the stars in the universe

Just encourage people to game the system. It's impossible to get real insight from them, because you can't differentiate between those who worked it out, and those who have read about it. If you're in an interview by now and someone asks one of these cookie-cutter questions like: how much storage is required to store satellite images for Google Maps? or How would you count the starts in the universe?

If you're good at problem solving but haven't though it through before you might come up with a general ballpark solution, or you might freeze under pressure of the interview of course. If you're a slick liar and have been reading codinghorror, you'll have an answer down pat for this category of questions before you even enter the room, one which you cribbed off the internet, as you will for all the other common categories. If you're so incompetent that you're neither, I guess you'd be weeded out - not a huge win - I wouldn't expect such people even to get to interview, which is a vastly expensive process (in time and money).

In contrast a real world problem, if the discussion is led properly by the interviewer, offers the opportunity for real in-depth discussion about the sort of problems you're going to be expecting this programmer to tackle every day - what trade-offs should they make when designing data structures to balance normalisation and speed, which libraries would they use to solve a particular problem, which problems they have seen in the past which are similar and how did they solve them, etc etc. and it also deals with cultural fit. There is not a clear dichotomy here between logic (puzzles), and wishy-washy cultural fit (a chat about code) - an informal chat, if held properly, can provide far more insight than a set of questions.

This depends entirely on the sort of job you're hiring for of course, but if you're hiring a web developer then a good background in interview teasers is not really on the list of desirable attributes, but a good understanding of real code is. I guess if you don't control the entire interview process and/or work at a large organisation, this sort of filter might become appealing because of the standard of interviewees you receive, but that's a reaction to a failed process.

One hiring project which I really admire is the stripe CTF as it selects for a certain type of person that they're obviously keen to find. It's a puzzle, but one so original and unique that it's very hard to game, and also one which records the users' attempts in real time (if they keep logs).

> On the other hand, if I'm hiring someone for a high pressure job I don't want them to fail when under pressure.

Programming is not like in those hacker movies, we don't have to solve problems in 60 seconds while getting a blow job[1].

[1]https://www.youtube.com/watch?v=rUY8HysBzsE

I do tests for prospective candidates, but my approach is slightly different.

After the interview I email them a small unfinished program. I then give them a set of instructions on what I would like them to do to finish it off, and they can then do it at home on their own dev setup; with the internet and any other resource they would normally use for development.

I give a coding style guide, and in the areas where some specific technique is required I make that explicit.

The app has a few bugs in it, and some of the techniques asked for are slightly leftfield.

I instruct them that if at any point they have any questions then feel free to email me - and they won't be marked down for asking questions.

In fact I mark candidates up if they ask questions.

The task shouldn't take more than 30-45 mins for a decent coder.

I find this to be a really valuable approach to seeing how a coder works. It shows how they work with others' code, it shows they can follow instruction, it shows they can communicate when unsure rather than hiding away and it gives a good guide to their style of coding.

It's a far less confrontational approach, and gives the candidate the best chance of showing what they can do.

In the interview I tend to be much more interested in the person, because I'd rather have a coder who is slightly less capable that I can train, than a coder who is amazing at everything but won't fit in. I'll still discuss past projects and dig deeper where necessary, but I like to find out how they influenced the outcomes of projects rather than get too deep on algorithms and the like.

So far it's worked very well :)

I used to give interview candidates a little background lecture on our problem domain then ask them for input on whatever I was working on that week. E.g. If you were trying to parallelize this code, how would you structure it? I never asked fizzbuzz style coding questions, because I think they're stupid and I probably couldn't code a linked list on a white board (I rarely code on whiteboards you see).