In the past week, I’ve spent the majority of my time in job interviews–both as the interviewer and interviewee. Since most of the people my own team interviews tend to be inexperienced recent college graduates, most of whom have never had to interview for a job before, and many of whom seem to make the same very avoidable rookie mistakes, I thought it might be interesting to write down what I’ve learned about how (and how not) to go about selling yourself for a job.
Before I start, I should point out, first, that these are my own opinions and do not necessarily reflect the policy of my employer; and, second, that, while I think these principles would hold true at most Silicon Valley companies, your mileage may vary.
That said, here are my pearls of wisdom:
Show enthusiasm: It may be hard to overcome your nervousness and seem happy to be there, but its important that you establish yourself as someone who is interested not just in a job, but in the job. No one wants to feel like someone is “settling for” them, and employers are the same way. This is especially true of high profile Silicon Valley companies, which usually have a lot of fans eager to work for them.
Be proactive: It’s difficult to get a sense of a person in an interview, and it’s even more difficult when the person passively makes you pry information out of them. While you obviously shouldn’t try to seize control of the interview, it behooves you to use whatever opportunities you get to let the interviewer know why you would be particularly suited to the job.
Interviewing for a job on the OS? Well, then it would probably be a good idea to mention how much you enjoyed your Operating Systems class (and why) when asked about your education. Know that the application you’re interviewing to work on has some particular engineering problems to solve? Try to specifically mention a time in the past when you had to solve similar problems when asked about projects you’ve worked on. Have access to part of the source for the project you’re interviewing with? Familiarize yourself with it, and impress your interviewers with your initiative.
Be familiar with the programming “canon”: As a college English minor, I learned a lot about what used to be called “The Western Canon:” the common body of literature that educated people were once expected to digest. Because everyone in Western, English-speaking society was once raised on Shakespeare and the King James Bible, for example, writers could use phrases like “a hawk from a handsaw” and “through a glass darkly” with full confidence that readers would understand their meaning.
I have a theory that programming has a very similar canon, and its King James Bible may well be Kernighan & Richie’s famous C Programming Language book. Because so many programmers cut their teeth on K&R, a great many common interview questions are culled directly from its pages (implement atoi(), for example).
Other candidates for inclusion in the canon would probably include: the dinosaur book about operating systems, the Gang of Four design patterns book, and UNIX Network Programming (to name a few random examples I’m familiar with). These are the books your interviewers probably used in college, and the examples contained within them may well have formed the foundation of their understanding of computer science. It might not be a bad idea to review them.
Know your algorithms and data structures: It’s a fair bet that at least one interviewer will ask you a question about a specific algorithm or data structure, as well as its runtime (Big-O) characteristics (as I’ve pointed out before, some organizations even seem to have particular biases when it comes to data structures). Make sure you’re familiar with the basic ones: linked lists, hashtables, binary trees, etc. I’ve always thought Stanford’s CS library website was an excellent resource for reviewing linked list and binary tree basics, and the NIST Dictionary of Algorithms and Data Structures is a good resource for more advanced topics like hashtables.
Be prepared to discuss specific implementation details: This one comes from my own personal experience as an interviewee. As it happens, I was recently beaten out for a job I really wanted at least partially (I was told) because the interviewers were concerned about my inability to recall certain specific implementation details from projects I had worked on. Assume that your interviewer will be very interested in programming projects you’ve worked on in the past, and make sure you’re ready to talk in specific terms about your design decisions, algorithms and data structures you used, challenges you overcame, and how you could do things better. If its on your resume, you should be ready to talk about it.
Don’t pad your resume: It’s tempting to exaggerate the breadth of your knowledge on your resume, especially when you don’t have a lot of experience, but, while padding your resume may get you past HR, it could make for an embarrassing interview experience. I’m constantly amazed at the diversity of knowledge on my own team, and if you mention that you know something exotic like OCaml, Lisp, or Smalltalk, chances are someone will be excited at the opportunity to quiz you about their pet under-appreciated language.
Oh, and for God’s sake, if you mention that you know Cocoa, make sure you can at least explain how Cocoa memory management works! So many self-professed Cocoa programmers screw that up that I almost made a separate category in this list for it!
At least try to answer every question: I’ll let you in on a little secret about my personal interview expectations: I don’t expect every person I interview to answer every question I ask perfectly. What I do expect, however, is that people will at least make an attempt to answer every question, and quite often I’m just interested to see how they go about trying to reason their way to an answer. Make an educated guess rather than offering a blank “I don’t know” (just be sure to admit it’s an educated guess). If you’re coding at the whiteboard, talk through the problem and let the interviewers know about your thought process.
Assume that your prospective employer will read your weblog: You may think I’m joking about this, but, like everything else here, this advice comes from personal experience. When I came out to Cupertino to interview with Apple, my first interviewer of the day presented me with a printout of one of my weblog entries and asked me some questions about it. These days it’s pretty easy to Google someone you’re curious about, and you should assume that at least one of your interviewers will be curious enough to do so.
None of this advice means I’m a perfect interviewee (or interviewer), of course. As I said before, I recently lost out on a job I really wanted. Still, I’d be willing to bet that if you follow my advice, you’ll find yourself facing much friendlier interviewers and much better odds in your job hunt.
