An ocean of ink has been spilled about interviewing for jobs in the technical industry (see, just for example cracking the coding interview or get that job at google). I’m probably not going to cover any new ground here, but these are some basic tips for doing better on technical interviews.
This post was inspired by my repeated recent frustration as a hiring manager watching candidates that had potential (or even proven prior performance!) do poorly at the in-depth interview loop phase of the process. If every candidate took fifteen minutes to read and internalize these points in addition to however many hours they spend self-flagellating with Cormen et al’s algorithms tome, I am guessing the pass rate might double. Interviewing is not like regular work (for better or for worse), and competency at the latter does not a priori translate well to the unnatural constraints of you + interrogator + whiteboard.
- When you’re practicing for an interview that will involve whiteboard time, write out your solutions long-hand on paper first, and make a note of what you have to google to remember. Not that an interview will be passed or failed based on remembering all the printf format specifiers or whatever, but it doesn’t hurt to get them right either.
- Ask questions before you dive in! (I would stipulate “good questions” but really, anything more than silence that’s on topic would be better than nothing.) Many many many times a problem can be dramatically simplified by asking clarifying questions or stipulating a reasonable constraint. No interviewer will hold this against you; on the contrary, it’s usually regarded as a small but very positive signal for the candidate’s competency.
- Think out loud as much as you can. Remember that we’re not just looking for banged out code or whatever, but trying to see how you think. Thinking is 90% of technical work, the rest is just typing and irritating planning meetings. If nothing else, outline the solution that comes to mind at a high level and ask if that sounds reasonable before diving into implementing it. That alone can save you many precious minutes from being wasted by barking up the wrong tree.
- Post-solution follow up work: after you’ve banged out an implementation, take a moment to talk — even at a footnote level — about efficiency / avenues for possible improvement / how to test your work. For example, in a code interview, take a moment to walk through a very simple test case. These are hugely positive signals that the candidate is driven to do good, thorough work and possesses initiative/responsibility/etc.
- Take a deep breath and relax. :) I know (I know) this is maybe the hardest element of this list, because you’ve got all this stuff riding on whether or not you pass the interview, and rightly you’re a bit stressed out with all of it. But your brain will work better if you aren’t in fight-or-flight mode. Try to, as much as is possible, relax and view interview sessions as a friendly chat to solve a problem between colleagues rather than an Inquisition. Good interviewers will make allowances for nerves, but still, it goes a lot easier if you chill out a bit about things.
Good luck!