Rather than continuing to talk about how hardcore developers should have hardcore math fu, I’d like to shift the focus a little to softer skills (although, as I said, I will come back to math stuff often). I believe that technical people should place even more of an emphasis on soft/people skills than non-techies (I mentioned this in one of the comments to my last post). I will expand on my reasons for this in a later post. In the meantime let’s just take it as a given and look at the value of these skills in a technical interview situation.
The thing with a programming interview, or any interview for that matter, is the fact that it is more of a conversation rather than a grilling. The company, and by extension the interviewer, has just as much invested in the process as the interviewee and therefore want to get the most information from the time they spent talking to you as they possibly can. Of course, in a programming interview the main objective is to assess your skills, but people rarely make decisions regarding other people (e.g. hiring decisions) based on hard factual data:
Only 70% of your friends rate you as a ‘nice guy’ and therefore we will be unable to pursue a friendship with you at this time.
Missing a semicolon on the second line of the last question, clearly puts you below the historical 95-th percentile of all candidates, which unfortunately means we’re unable to hire you.
It just doesn’t happen – people mostly go by how they ‘feel’ about another person based on what is important to them. They may try to get an objective picture of your skills, but no matter how well you think you did, if they don’t feel like they want to work with you themselves (i.e. they don’t really like you), you will not get a positive report, at best the interviewer will be ambivalent:
He clearly knew his stuff but was a bit of a cold fish. I guess he was ok overall.
Not really the best outcome, ambivalence usually means – no hire.
This does not at all mean that you can bluff your way through a technical interview just by creating ‘good vibes’. Most technical people value technical skills highly and if you don’t measure up in that regard you won’t succeed. What it does mean, is that you can be in the middle of the pack as far as pure technical skill is concerned, but still come out as the preferred candidate at the end of your programming interview. Some developers (i.e. highly technical/analytical people) may not like it, but that’s just the way it is, dealing with people is not an exact science.
The Objective Of A Technical Interview
A regular interview is all about psychology – can you leave the interviewer with a good impression, can you ‘click’ with the person in the short time that you have. A technical interview should be all about technical skill, but people are involved, which means regardless of what you might like, it is still as much about psychology as it is about technology. The objective is to answer the questions to the best of your ability, while at the same time giving the interviewer as much positive clues about yourself as you can, to allow them to form a good overall impression. The impression is just as important as the answers you give. To that end here is the process I would use when answering a programming interview question which will allow you to not only give yourself the best chance of answering the question correctly, but should also give the interviewer a decent feel for who you are and how you work. If you disagree with any of this, or have other tips, do leave a comment.
The Process
The majority of technical interviews onsite, consist of answering a programming question on the whiteboard. I don’t like it either, but we work with what we have, so this process is geared towards that.
- When you’re asked a question, don’t try and jump straight into writing code unless it is truly trivial. It’s not a race, sit and think about the question for a little bit. This shows the interviewer that you’re not a “cowboy” and don’t go off half-cocked to try and solve a problem you don’t yet understand. To help you understand the problem…
- Use the whiteboard. A picture is worth 1000 words so use the whiteboard to draw the problem as you understand it. At this point you should be talking to the interviewer to make sure you both have the same view of the problem; the picture will help with this. This also gives the interviewer a chance to clarify the question if necessary. From your point of view, you’re talking and eliciting requirements, the value of this should be self-evident. Don’t fill up the whole whiteboard with pictures, you don’t want to have to wipe your diagram as it may be useful later on for debugging purposes.
- Don’t be afraid to start over and keep talking. You should be chatting with your interviewer throughout, to keep them engaged and to allow them to understand your thought process. As you’re coming up with a solution you may start writing it up, but if you find that you’ve gone down the wrong path, or come up with a better solution, don’t be afraid to start again. Keep talking, tell your interviewer what you’re going to do – this gives them a chance to point you in the right direction if they think it necessary, or stop you before you waste too much time (if you’re completely off base). All of this should not only demonstrate the fact that you have decent coding skills, but show that you’re a good communicator, can reason logically and can recognise when you’re wrong (and take the appropriate steps). All of it helps the interviewer form a positive overall image of you. If you just stand there silently writing or thinking, you get none of those benefits. Infact you do the silence thing for long enough and it can get a little awkward, which is the last thing you want.
- Take your time, like I said, it’s not a race. If you’re taking too long the interviewer will let you know, otherwise assume you have all the time you need (this should also help with stress if you’re prone to panicking during interviews). As you’re thinking, don’t forget to do some of it out loud, I can’t stress the importance of walking the interviewer through your thought process enough. When you’re actually writing the code, take the time to consider things like boundary conditions. Many technical interviewers are extremely pedantic about stuff like null checks, I personally wouldn’t be, but it takes little time and better safe than sorry.
Don’t be afraid to ask questions or even ask for hints if you’re stuck. The interviewer will often have some prepared anyway and will be happy to give them to you (i.e. you won’t lose too many ‘points’). If you don’t remember specific API details, let the interviewer know, they will either tell you or let you know that it is not important. This demonstrates that you know what you’re talking about while at the same time don’t get hung up on the details.
If you’re stuck (but think you should know the answer), don’t panic. Stressing-out is one of the worst things you can do in any interview, it just isn’t the best image to project. Iterate over steps 2-5 again. It will probably be obvious that you’re under a bit of pressure but equally obvious that you’re taking it well – not a bad thing for an interviewer to know about you. It also shows that you don’t give up easily :).
When you’re finished, you’re not really finished. Remember what I said about interviewers being pedantic about null checks and boundary conditions, now is the time to make sure you don’t get caught out by this. Walk through your code and find any potential bugs, use the examples you drew in step 2. This demonstrates thoroughness and – chances are – you will find a little bug or two (which even the interviewer may have missed) which looks good. If you’re short on time, at least tell the interviewer that you would have liked to walk through the code.
Demonstrate that you know what you’re on about and didn’t just stumble on to the solution by accident. You can do this by telling the interviewer a little more about your code, consider things like, strengths, weaknesses, running time (big Oh). You may also mentioned other potential ways to solve the problem and any improvements you would make if you had more time. Chances are the interviewer was going to ask about this stuff anyway, but preempting displays professionalism (you’re aware of the issues and what is required) and the ability to think about the problem at more than just a superficial level.
Some Extra Tips
- Don’t write too small on the whiteboard, that can be really annoying (too large is usually not an issue, but watch for that too). If you’re writing is of a decent size and you’ve run out of whiteboard while still being nowhere near the end of the solution, you’re probably missing something, go back to step 1.
- If you’re into TDD it may help to think about the problem in a test first fashion. What would you test in order to solve – and go from there, it may help get you into your normal flow.
- Books like How Would You Move Mount Fuji? may be a bit of a cliche, but are worth reading for the insights into the mind of an interviewer (and it certainly won’t hurt to be prepared if someone ever does ask you THOSE questions) and how to leave them feeling positive towards you. Another good one is Programming Interviews Exposed for more technically-minded questions/tips.
- If you don’t know the answer and none of the hints help (in short, if you have no idea), don’t try to bluff it. Just admit it and move on, you can ask the interviewer to explain it later if you have time. As far as I am concerned, it is unfortunate that you couldn’t answer the question, but you get points for being man enough to admit it, after all, noone can know everything. It is obviously not as good as solving it, but is better than nothing and a damn sight better than trying to bluff it, the interviewer is not an idiot (and even if they are, pretend like they’re not) they’ll see through it and that’s an automatic fail.
This is how I would go about answering a coding interview question these days. Looking at it from the other side, if I was the interviewer and someone went through this kind of process I would rate them pretty highly (unless they couldn’t actually answer ANY of the questions :)). Doing all this allows you to demonstrate your coding skills, shows that you’re a good communicator, have decent people skills, work well under pressure are thorough and generally personable. Compare that with – “He was ok. He solved all the questions.” – big difference.
Images by urban don, pvera and Sugarmonster