Programmers Are Confessing Their Coding Sins To Protest a Broken Job Interview Process

A number of programmers have taken it Twitter to bring it to everyone’s, but particularly recruiter’s, attention about the grueling interview process in their field that relies heavily on technical questions. David Heinemeier Hansson, a well-known programmer and the creator of the popular Ruby on Rails coding framework, started it when he tweeted, “Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don’t do riddles.” Another coder added, “Hello, my name is Tim. I’m a lead at Google with over 30 years coding experience and I need to look up how to get length of a python string.” Another coder chimed in, “Hello my name is Mike, I’m a GDE and lead at NY Times, I don’t know what np complete means. Should I?”

When I interview people I do rely on technical questions.

But I use them as a form of behavioral interviewing.

Meaning I don’t give a damn if you can solve the problem. I really don’t. What I care about is how you act when I give the interview.

Further, I limit my technical questions to two phases–and I do this only after breaking the ice and talking about you and your previous jobs. (The “why did you leave your last job, why did you go to the college you did, how is your dog doing?” sorts of questions.)

The first phase of technical questions: I’ll ask very basic questions about the platform I’m interviewing you for. If you’re a Java programmer I’ll ask about different collection classes. If you’re interviewing to do iOS development, I’ll ask what a view controller is. Questions which, if you are actually actively writing code, you should know the answer because you deal with those things on a daily (or weekly) basis.

Now I don’t care if you stumble on the questions. I expect you to stumble. It’s a God-damned interview, and no-one is comfortable during an interview. You want a job, I’m waving money in front of your face–of course you’re going to choke when I ask you what a UINavigationController is. It’s a stupid question, and I must have a hidden reason for asking a stupid-simple question, right?

But these questions are designed to screen out those who are pretending to be an iOS developer, or pretending to be a Java programmer, or pretending to be an Android developer. There are a lot of people out there who claim 5 years of Java programming who haven’t actually written one line of code in Java.

The second phase of technical questions: I will ask you to write code on the whiteboard. I have two standard questions I ask (one which requires you to write code with a single loop, another with two loops), and I’ll happily walk you through the exercise if necessary.

But even with the second phase, what I’m looking for is your behavior. Do you remember to close your curly braces? Do you know what the modulus operator (‘%’) is? Do you know how to write a for loop? And if not, do you ask? Do you think or do you panic? Do you try to correct me? Do you push back?

I don’t care if you can write code on a white board. I really don’t.

But I do care how we interact. I’m not watching if your code is correct–though bonus points if it is. I’m watching to see how you approach the problem.

Sometimes someone blows through my questions quickly, and at that point I start digging out the harder questions: what is the P vs NP problem. How do you calculate prime factors? Can you write a quick sort from memory?

But if we’re on those questions, I guarantee you three things:

First, you’ve got the job if you want it.

Second, I’m trying to impress you on how smart the other people you will be working with–because I’ve noticed many programmers like the idea of working with smart people.

And three, I’m trying to kill time because I’ve already decided I want to hire you, but I still have a few minutes to fill.

I’ve gone through a lot of interviews, and I’ve noticed most interviewers ask technical questions–but have absolutely no fucking clue how to ask them or what to look for when someone tries to solve them. They’re just looking for the correct answer, not for someone who seems smart and motivated. And that often leads them to making poor hiring decisions–overlooking those who would make great additions to their team, hiring people who may not actually work well with the existing group culture.

But remember: you’re hiring a human being; someone you will work with, someone you will chat with over coffee, someone you will use as a sounding board when you have a problem you’re struggling with.

You’re not hiring a fucking search engine.