How to Pass an Interview with Me

I do a lot of interviews. I mean, seriously, a lot of interviews. One a day is getting to be pretty normal.

I’ve read before Jeff Atwood’s classic “The Non-Programming Programmer,” and it’s still disturbingly valid, half a decade later: A very large percentage of the phone screens and in-person interviews I do are dismal, epic failures: The person can’t code, and, more significantly, doesn’t realize how poor their coding skills are.

Our dev shop is populated by really capable people. We get stuff done. Our flagship product has two and a half million lines of code in it — and growing — and there are a raft of satellite products orbiting not far from its gravitational well. And it’s not large because it’s wasteful; it’s large because that’s the smallest we could make it and still do what it needs to do.

And what that means is that if you want to join our staff, you have to know what you’re doing. We don’t have time to hand-hold. You need to be able to make stuff on your own. If you can’t deal with a business person giving you some abstract requirements and saying, “I need this in a month,” you’re not going to last. (Yes, we’re Agile, and we do plan better than that quote might imply, but a lot of stuff really boils down to, “Here’s a rough idea, go build it.”)

When you bomb out of our interviews, you’re actually doing yourself a favor. I know it seems like we’re being mean, but I swear we aren’t. In our initial interviews with you, we give you programming problems. Easy problems. These are all things that should have been homework in your Freshman or Sophomore year of college.

And any one of our current employees can do these problems in about five minutes. Literally. We’ve had phone screens that ran 15 minutes total. The reason we give these easy problems is because the real work is way harder. You’re never going to last in a two-million-line codebase full of graph algorithms and complex data structures if you can’t count letters in a string. We know this because we used to have weaker interviews, and people bombed out hard during the first month of employment afterward.

So here’s the deal. If you want to work for us, here are the critical parts:

  • Focus on the basics. That’s anything that a professor would ask you during your first two years of computer science. If you don’t have any basic computer science backing you up, you’re going to fail. Period. So you’d better know how to sort and search, how to read and write output, and how to work with strings.
  • Make sure you know your language. The interview consists of writing code in a programming language. The interview consists ENTIRELY of writing code in a programming language. So if you’re applying for, say, a Javascript programming job, you’d better know it’s spelled JavaScript and not Javascript. You’d also better know what the heck a closure is, never leak a global, and be able to write inheritance-safe array iteration off the top of your head. You will be tested on this. All of it. On the spot. And that’s 99% of what you’ll be doing in the interview. If you can’t write a correct if-statement or a while loop without typos, the interview will be over so fast it’ll leave your head spinning.
  • Skip the brand-name technologies. I don’t care how good you are with Oraclesoft JComet.NET 6.0 Super-Professional Edition. Really. The more buzzwords you put on your resume, the more I think you’re trying to cover up a lack of real knowledge. We can teach you how to use a technology, but we can’t teach you how to think clearly, and if you can’t think clearly, you won’t pass the interview.
  • I don’t look at your resume. Whatever you were told to write by your professors/recruiters/hiring-agency/employment-textbook, I don’t care. I don’t care where you worked, what you did, where you went to school, what your GPA was, or what your certifications are. I look at your resume in an interview when I’m bored or when you’re failing and I have nothing else to do. I don’t care how much flowery text you put on there. Your performance on the test is the only thing that matters to me, because the test doesn’t lie: You either solve the problems we give you or you don’t.
  • Well, actually, I do look at one part of your resume. I look at your resume for lies. And anything you wrote on it is fair game. Pro tip: I’m fluent in about 30 programming languages and a giant pile of frameworks and toolkits and libraries — and my interview colleagues aren’t exactly slouches either — so when you say you know X, you should expect to be given a programming problem involving X. And that means: Don’t claim you know Lisp if you can’t eval (car (cdr '(1 2 3))). Don’t claim you can code SPARC assembly if you don’t know what a register window is. Don’t claim you know C# if you can’t talk intelligently about lambda functions. Don’t claim you know jQuery if you can’t explain why $(".foo > a.bar").filter("span") doesn’t work. You can and will be called on anything that’s a lie. Also, keep it short: The more you say on your resume, the more I think you’re trying to cover up a weakness.
  • We’ll help you, if you can stand on your own two feet. I know all of the above looks scary, but if you have the goods, don’t be nervous. We give major leeway for nerves because we know how scary the interviews can seem. If you forget X, we’ll help you remember it — but we can tell the difference between “I forget exactly how to do X” and “I never learned how to X” and “I’m not capable of doing X”. If you need a breather, you can take it. You don’t get points off for poor spelling: You only get points off for not knowing what you’re doing.

There you go. If you know what you’re doing, good luck, and we can’t wait to have you aboard.