I always hated "programming problems" when I was interviewing for jobs. I now also hate them as someone who is trying to hire programmers.
As a candidate, I felt like these kinds of problems had little relationship to real work. How often do I really need to find the number of ways that one could walk down a set of stairs (a classic recursion interview question) or what floor an egg breaks on? (nice one, google) And what am I supposed to do if I already know the answer? (which was often) There are multiple levels of weirdness at play -- not exactly what I call enjoyable.
As an employer, I hate them for an entirely different reason. My objective during an interview is to find out two things: a) is this person smartb) can this person work well with our team Canned interview problems may given you the answer to (a), but they do so at the cost of having any chance of knowing (b).
By giving them a contrived problem that I know the answer to (and they know I know the answer), I've immediately forced an artificial interrogation-style power dynamic between us and likely amplified their anxiety by a couple orders of magnitude. My goal is to get as far away from that dynamic as possible.
To the best of my ability, I want to simulate an hour or two of work and see whether we can collaborate effectively. Here's the rough approach I've worked out so far, comments are appreciated as I'm pretty new at this myself:
- Have them share a personal project with you, it doesn't have to be of epic proportion, just something they're working on.
- Talk through some of their code during the interview if possible. This can give you both an idea of what a code review will look like.
- Have them explain any problems they are having, and see if you can help. This informs whether you will be able to collaborate on projects they own.
- Walk through some of your own code and explain some of the problems you've been having. See if they have any insight and whether you can brainstorm together.
In both cases of reviewing your respective work, you are admitting that you don't know the answer to the problem. In the case of your own problem, you're also admitting that it's something you could use help with. You have now mitigated the power dynamic somewhat, which means the candidate can feel comfortable in throwing out ideas. You've moved from waiting for the "right" solution to asking for ideas on a real problem.
You come away with a good indication of their ability, as well as a decent indication for how well you would work together. And a possible side benefit may be new insight into the problems that you're struggling with. It takes a little extra courage to fly without a net, but that's the whole point - leveling the field so you can actually talk.If this sounds sane to you and you're looking for dev work in San Francisco, please get in touch.