This article is written with considerable snark--put on your flameproof suit if needed. I'm not actually a jerk when interviewing people, but I do get frustrated when candidates fail to do basic preparation. If you're unsure about how to prepare for a programming interview, read on...

I know this might come as a shock to you, but most programming job applicants suck. I’ve interviewed my fair share this month, and it’ll be a lot easier for all of us if I tell you upfront what I’m looking for.

As a hiring manager, my job is to make sure you can do the job you’re applying for. For programming that means you need to be able to program. So when I whip out a laptop in our round-one interview and ask you to write some code, try to hide your terrified expression.

Reasons for Suckitude

Bit Rot

A common sucky interviewee is the guy whose last job was management and he apparently thinks, “since I was a programmer before, this should be a piece of cake.” As it happens, if you haven’t been programming for a while, you can’t program anymore. Programming is not like riding a bike, it’s a skill that requires constant use, because:

• It’s a highly detail-oriented activity. Computers are real persnickety about details like pointers versus values, where you stick your semicolons, and the types of variables. (I’m talking C here.) If I tell you to return a long and you start typing int everywhere, I’ll give you a test case that’ll overflow your ints.

• Programming languages move on. Even C moves on. Have you heard about C99? It appears that most C programmers haven’t. I know, I know, it’s hard to keep pace with technology and it’s only been a decade since the standard was released.

• Computers think differently than humans. If you’re not fresh on thinking algorithmically, then you won’t be able to flip into that mode on the spot. You need to be able to reason through a problem in a way that you can then express in code.

I brought in a guy that hadn’t programmed professionally in years, in fact he didn’t even have programming on the first page of his resume. However, he had been practicing while looking for a job and he rocked my programming interview. He reasoned through the problem, wrote the code, it ran perfectly the first time. I hired him.

Over-Hyping Yourself

Whether in your resume or the initial phone screen, a lot of candidates hype their skills to make it into the in-person interview. Here’s the problem: I set the difficulty of my programming interview to match what you say you can do. If you say you’re a master of network protocols, guess what, I’ve maintained a TCP/IP stack, and unless you’re really a master I’m going to bury you.

Be honest, tell me what you do and don’t know. If you wrote some Scheme in college but have mostly forgotten it since, tell me that. If you say you’re still good at Scheme, I’ll brush up on Scheme myself just so I can give you a Scheme programming question. And yes, I actually do that, because it’s worth a few hours of my time to prepare for an interview if it saves me from making a bad hire.

Not Understanding The Problem

Generally I consider it a good thing when someone starts typing away. Better than the blank stare, certainly. But before you type, make sure you understand the problem. If the question isn’t so easy that you know the answer offhand, then:

• State the problem, out loud, in your own words and get my agreement that you understand the question correctly. Example: “just to be clear, you want me to reverse the characters of this string in place. I shouldn’t allocate a new buffer for the reversed string.” Now’s the time to ask questions about object/memory ownership, size of data types, performance expectations, etc..

• State how you intend to solve it, again out loud. Example: “I’ll find the length of the string, iterate over the first half of it, and at each offset I’ll swap the character with its corresponding character offset from the end of the string. For an odd-length string the middle character will stay where it is.”

• Now start typing.

I’ve interviewed several people that couldn’t write Fibonacci sequence. I’d tell them what it was and write on the whiteboard the first ten numbers so they could see it. They’d start typing and immediately go into the weeds. I would ask, “tell me in English what the n-th Fibonacci number is.” And they wouldn’t say anything, they’d keep trying to type. I didn’t hire any of them.

Forgetting How To Test

With the problem understood, how can you test that your program is correct? You don’t need to go all xUnit-crazy, just write some asserts that test boundary conditions. If you screw up your code, you should be the first to know. Don’t make me point out cases where your code breaks.

One other thing: if I ask for a program sample ahead of an interview, don’t even think about sending in code that doesn’t include unit tests.

Forgetting Basic Debugging

So, your code isn’t working, what do you do? Stare blankly at the monitor? No. If you’ve got a source-level debugger handy, use that. Otherwise just use printf(). Keep it simple and keep going. I’m happy to wait while you work through the problem, in fact it’s refreshing to see someone that’s undaunted by a bug.

If you’re still stuck, start sketching out the problem on paper and start asking me questions. I’m happy to answer questions if you’re taking charge and just need a second opinion.

Editor Flailing

It’s funny how many people can’t edit text on any machine but their own. I tend to interview people on a laptop running Ubuntu, and I open gedit for them to use, with the offer that they can use any other Unix editor they like. Most can barely navigate gedit, and it’s stupid simple.

Don’t ever let yourself get hung up on the editor. If you can’t figure out the magic command keys to indent code the way you like, just press the damn space bar and indent it yourself. Flailing in the editor wastes time.

I interviewed a guy that was a Windows programmer but he could barely use vi. He went ahead and, without much elegance or speed, plowed ahead with vi. He gave up on pretty formatting, instead he stayed focused on the problem and wrote solid code. I hired him.

Getting Back on Track

Say you’re a manager and there’s no management jobs around, so you decide to go back to programming. There’s a simple way to prep for a programming interview: program. Shocking but true. Don’t think about how you’d reverse a string in place or determine if a number is prime (common interview questions) but actually write the programs. You’ll be surprised how rusty you’ve gotten.

Think of it like “Programming Kata,” practice you do daily to keep your head in the game. Google for common interview questions and write them. Write simple programs in every language you know. Try pushing yourself, too–struggling through a problem is a skill in itself. This isn’t something you need to spend all day doing, but spend at least a half hour each day.

Pre-Interview Research

First of all, if we get to the point of the interview where I ask if you’ve got questions for me, and you say, “so what does your company do?” the interview is over. Sure, I’ll humor you and answer the question, but I’ve mentally stuck your resume in the trash can. There is absolutely no excuse for not looking up the company’s web site and seeing what we do.

There are fair variants of the question. For example, “what part of the product does your group work on?” That’s not obvious to an outsider, and you should ask that question so you know what you’re getting into.

Second, if the HR person scheduling the interview tells you any names of people you’ll be interviewing with, write them down and Google them immediately. If you’re interviewing with me, guess what you’ll find? (If that’s how you got to this page, congratulations, you’ll probably do well in my interview.)

Finally, brush up on any technologies mentioned in the job post. You don’t need to be an expert, but you better at least have a looked-it-up-on-Wikipedia level of knowledge. When I say, “we write our management GUI in Ruby” and you reply, “what’s Ruby?” then the interview is over. It was in the job post–duh.

Thank You

Thanks for taking the time to prep for our interview. You’ll know how to impress me and other technical hiring managers. I haven’t given away any of my secrets (in particular my Kobayashi Maru interview question for systems programmers that get cocky) but now you know what to expect.

I want to close with a bit of perspective: if you’re a solid programmer, the programming interview should be fun. Show me the passion you’ve got for your craft and we’ll be pals real quick. I’m not trying to beat up candidates because I’m a sadist, I’m looking for people I want to work with. So get ready to type, I’m looking forward to it, and so should you.