How to win the coding interview

I get that. I am too.

I'm around 13+ years of experience. I have contributions to major open source projects, have given talks at a few conferences, write about my experiences on a blog... it doesn't matter. I've ran into a few interviewers who take a few minutes before the interview to skim my blog. Once I ran into someone who actually read a few posts and saw a talk I've given (always a boon).

If you really want to get a sense of how I think and what my code looks like it's out there in the open. Few people will bother to look.

Thankfully I've done enough interviews that there are some patterns I can share. Here's my unofficial guide to acing programming interviews:

1. Be honest. Don't put something on your resume because you think it will make you sound good. Yes the first screen is just keyword bingo... but at some point you might make it to a technical interview with someone who hates it when people do this and will make a point of asking you obscure questions about the ANSI C standard. If you've written a few small C programs or done a few tutorials you don't know C -- you've just used it. We tend to over-estimate our abilities which is why interviewers don't trust resumes. But if you want to get a job doing more C don't be afraid to put that out there.

2. Whiteboard coding is stupid. Instead learn logic and predicate calculus. Learn to take a written or oral description of a problem and work out what the constants are and write out an invariant or two. Use pseudo-code. Pretend you are a caricature of a white-haired professor teaching a class... write out the problem, go on tangents, explain your reasoning in steps. Write pseudo-code only if pressed.

3. Coding. Long before you start interviewing start a repository. Pick the language you're strongest in and work out the following problems: a function to detect a palindrome, a function to detect an anagram, a function to find the Nth number of the fibonacci sequence, a function to generate the list of numbers of the fibonacci sequence, and fizzbuzz. Try to come up with more than one solution to each problem. Re-type them out. Commit them to memory by rote practice. Work out problems on coding practice sites and add the most popular, boring ones to your repository. As you interview add questions you come across to your repository. Practice the most common ones. Commit them to memory. This is probably one of the most inane practices in hiring but it's also one of the easiest to overcome. 90% of interview coding problems are regurgitated Google searches for interview coding problems.

4. Prepare a list of questions to ask the interviewer before hand. At some point they're going to ask you if you have any questions for them. Grill them hard. What makes them excited about their job? What's the hardest problem they've had to overcome? What is their greatest failure? What did they do about it after? What is the most common problem they expect you to encounter in this role? Etc, etc. Know who you're talking to -- save this for the technical interviewer whom you'll likely be working alongside/for.

Before you know it you'll be done. You might get an email or a phone call letting you know whether you made it to the next round or whatever. You may not make it.

The important thing to remember: It's not personal, it's not pervasive, and it's not permanent. Remember that every person you encounter is living a life and story that is every bit as complex and deep as yours. There are a number of possible circumstances affecting your position that you have very little control over: it's not your fault if you don't ace every interview as you likely won't despite how hard you try. If you're persistent you'll eventually find something.

Happy hacking.

First, "scrawling some pseudocode on a whiteboard" and "we absolutely must get this code out to the customer by Friday because a $50M contract is on the line" are not the same thing and it is fallacious to use performance on one to infer performance on the other. "Stress" is not some universal feeling that differs from situation to situation only in amount. It has types, which different people handle differently.

Second, related to my response to a sibling comment, if "we absolutely must get this code out to the customer by Friday because a $50M contract is on the line" has a high enough probability of occurring that it is worthwhile to screen candidates for ability to handle this, your company is fundamentally broken and you are trying to use your hiring to compensate for the real problems.

(Fellow defense/aerospace internee here. I managed to get half-out four years ago but have failed multiple times to get full out on non-technical grounds.)

I have never had a need to write actual code on a whiteboard. Neither has anyone I have ever worked with.