Joe McMahon

So the tech interview is starting to change. I am very glad to see the end of the "puzzle palace" interview. Had a number of those and never did very well at them.

To quote the meat of the article:

Quickly filter out the technically inept by asking half a dozen basic technical questions – Atwood calls this “the FizzBuzz filter.” Ideally you can do this online. You’ll be amazed how many people fail. (If they’ve been recommended to you, you can skip this step.)

Talk to them–in person if they’re local, voice-only if they’re not–about technical problems they’ve faced, tools they use, decisions they’ve made, pet peeves, etc. This is the “behavioral interviewing” that Google’s data shows to be actually useful. Note, however, that while you’re discussing technical concepts, you are not grilling them with technical questions that must be answered correctly.

Above all, discuss their past projects, how they got them done, and the decisions they made en route. Maybe have them talk you through some of their code on Github. To reiterate my own line: Don’t hire anyone who hasn’t accomplished anything. Ever. If a developer doesn’t have a portfolio they can talk to you about, not even any side or pet projects…then don’t waste your time talking to them at all.

Try to establish “cultural fit” … although be very careful that you’re just talking about work culture, eg enterprise vs. startup, and that this doesn’t lead to “subconsciously excluding people who aren’t just like you.” Don’t become a frat full of brogrammers.

Finally, if they’ve gotten this far, give them an audition project. Something relatively bite-sized, self-contained, and off-critical-path, but a real project, one that will actually ship if successful. Hire them on a paid basis for a week or so to build it, and keep a close eye on their code and progress. (If you do pair programming, have them pair with your existing team.)

Hire them. Or don’t.

I think a) this is much more likely to get you good programmers, and b) is much more likely to be a path to success for good programmers who don't have The Resume but have the talent. I know a lot of folks who would totally shine at this but can't write "code on the board" worth crap.

I do like to do a "so how would you design this? how would you test it? what might you do to deploy it?" section; it's nice to see if someone actually has experience with getting stuff off their desk and out in the world.