If you find yourself interviewing for a software engineering position today, you can be 90 percent sure that you will be asked to solve some programming puzzles.

We’ve all been there. You come to the office for an interview, spend a few minutes talking about the job and you, and then the inevitable hits: programming puzzles and quizzes. You are asked to solve nonsensical, irrelevant, theoretical problems on the spot while the interviewer waits. These problems in no way represent the actual work for which you’re interviewing.

How do you detect a palindrome? What is the worst-case performance of the quicksort algorithm? How do you find depth of a binary tree? These are all utter nonsense. If your cutting-edge application needs to detect palindromes, I’m pretty sure you have bigger problems than you think. All of these can be easily solved after a few minutes of research on the Internet.

I get especially annoyed at these things because my mind doesn’t work well in this area. I don’t like to solve unrealistic problems. My nonsense detector kicks in and I can’t concentrate. Instead, ask me if I know how to debug messaging queue issues, how I like to set up a new server, how I like to run my Django apps, how I’d solve a specific problem you’re having, etc. Have me work on your product alongside someone in your company. Get to know me. I can program. I’m good at what I do. I’m just not good at those stupid puzzles.

It’s not that I don’t like to think. I’m learning Haskell and I think I have understood monads (don’t ask me to explain them to you though). I like parsers and parser combinators. That stuff is hard to understand and takes some serious alone time to grok.

I’m sure you can find a person out there who is the inverse of me. They love puzzles and excel at them. They get to the final round of Google Jam. I don’t. Not even close. But they are terrible programmers. Who would you rather hire? Every now and then I get this idea that I’ll go and learn a whole bunch of puzzles and quizzes so I can wow the next interviewer. But then I inevitably start to feel dishonest and drop the whole thing.

How to interview someone

Find a small problem in your code base. Give them access to your Git repository. Assign the ticket to them. Explain why it’s a problem and suggest a few possible solutions. Have them work on it either alone or alongside one of your developers. This gives your team the chance to get to know this potential hire and see if they would be a good fit. This is how I interviewed at Amara and it was great.

I’d like to end with a brilliant Zach Holman quote on interview:

I think programming riddles, games, and brain teasers are a great way to hire. First one to say “fuck this” and walk out gets the job.