How to Get a Job at Fog Creek (and Other Selective Software Companies), Part 3: Programming Interviews
Posted September 01, 2009
This is the third (and final) installment of a series on how to get a job at Fog Creek Software (and other selective software companies).
Assuming you do well on the design question, you will be scheduled for a second phone interview. This one will involve code. We use our remote assistance software, Copilot, to log in to your computer so you can use the editing tools you're comfortable with. (Of course, if you're not comfortable with that we can always fall back to EtherPad, which is also pretty awesome.)
Before we get into any specifics, make sure you've read the post on phone interviews. Everything I mentioned there carries over to coding interviews, especially the part about talking through what you're thinking. It can be easy to jump into a programming problem and just start writing down your answer without explaining your process. While this may work for actual programming, it defeats the point of an interview. You need to make a point of communicating your solution to your interviewers. It will show them that you have a good, thorough thought process and that you can work with other people.
Speaking of being able to work with people, try to remember manners and common courtesies to everyone you interact with during the process. Our office managers may not be asking you technical questions, but if you treat them rudely or disrespectfully, you can be sure that we'll hear about it. (If you haven't learned it yet, learn it quick: the office manager is, by far, the most important person in the office.) They don't want to work with jerks, and neither do we. Also remember to respect the space you're in. I try to have fun and interesting objects in my office for visitors, but going around, picking up, playing with, and moving EVERY SINGLE OBJECT in my office does not make me want to work with you, no matter how good the solution you're mumbling to yourself is.
Not that a candidate has ever done that...
A programming phone interview will be nearly identical to a in-person interview, so I'm addressing both here. The interviewer will talk with you about your background for a bit, then he will jump into programming questions. Personally, I have one go-to question that I use for both phone and in-person interviews. This allows me to judge candidates based on their relative performance, as well as to help those that might get off track a little. Other interviewers have a few questions that work through progressively. A little hint: if an interviewer asks you several different programming questions over the course of an interview, there's a good chance they're related. See if you can build on your previous answers.
Whether you get one question or several, you will probably arrive at the final solution through an iterative process. Don't spend too much time perfecting the first code you write. Most likely, you've not taken something major into consideration, and are not yet headed in the right direction. It's better to quickly find any fundamental flaws in your code than to have a beautiful, but incorrect solution. As you progress towards a better solution, start thinking about the little stuff like error checking, corner cases, and typos.
When you're done, give it a look over just to be sure. Then, talk your interviewer through the full execution path a few sample inputs. You may think your solution is clear to them -- and it probably is -- the sample input is not for them, it's for you. There are still bugs in your code. Nobody writes perfect code in interviews. You're talking to some stranger who put you on the spot, solving a problem you were just introduced to a few minutes ago, and your solution could determine whether or not you get the job. It's a stressful situation. So run a few sample inputs, find those bugs, and impress the interviewer with your thoroughness. I've interviewed so many people that showed a lot of promise, but fell flat at the end because they refused to test their code, despite several glaring errors.
So what's the best way to prepare for all of this? Programming Interviews Exp osed is a good, if somewhat basic primer on coding interviews. Joel's Guerrilla Guide to Interviewing v1.0 and v3.0 have some sample questions that we actually used to ask during interviews. You can also search for "programming interviews" on Google and find a lot of sample questions.
All that will help, but there is one way that you can really improve your chances in an interview: Learn C.
Hey, I thought you guys didn't care what language the interview was in, what gives?!
It's true, we don't really care what language you use for the interview, as long as it's common enough to be suitable for communication. If you want to use Java in an interview with me, go for it.
But here's the catch: most other languages make things easier. While that's good for being more productive, it makes it harder for you to demonstrate your skills the interviewer. If you can sit down and reverse the words in a string, in place, all with pointer arithmetic, I'm going to start thinking you might have an idea of what you're doing. If you do it in Java and forget to mention that the language you chose makes it impossible to do it in constant memory, you just earned yourself one demerit.
If you don't already have one, go find yourself a copy of K & R and read it cover to cover. Once you're familiar with C, find a set of questions (like this one from an MIT course on programming interviews) and work out the solutions in C, using pointers. Treat it like production code, come up with weird inputs, test it all. Then find a CS buddy and challenge them to find bugs. You may not get to the point where you are comfortable doing a real interview in C, but the thought process and preparation will help you regardless.
By being deliberate and methodical, and making a point of communicating your thought process to your interviewers as you go, you eliminate the common pitfalls and increase the chances that the interviewer will help nudge you in the right directions. And try to have some fun; after all, programming is what you love doing, right?