How To Answer A Programming Interview Question And Look Good Doing It

Look goodRather 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

Coding 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.

  1. 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…
  2. 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.
  3. 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.
  4. 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.
  5. 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 :).

  6. 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.
  7. 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

Cunning

  • 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

  • Amber

    I like these tips and think they’re useful for any developer to brush-up before his/her next interview. I once read that there are two kinds of people, ones that think before they talk and ones that think out loud. It’s not that one is smarter than the other, or anything like that, it’s just two ways of working and we’re born with it.

    I’m the kind of person who likes to come up with an idea first, clean it up and then say it. At first this really got in the way in interviews because it would mean long pauses. By working (out loud) with colleagues and on the whiteboard in real-life problem solving sessions, this has become second nature and now comes easily in interviews.

    Whether you talk it out or not, you need to have good problem solving skills (in addition to good technical skills) in order to be successful in this kind of an interview.

    • http://www.skorks.com Alan Skorkin

      Hi Amber,

      I agree with you about the two kinds of people, the problem is that you really NEED to be the think out loud kind not just for interviews but in the workplace as well. In any team environment discussion is how decisions get made and if you can’t think out loud any, you will not be able to contribute much to a discussion which is evolving an idea. What I mean is, you need to be able to voice your ideas before they are fully formed in any kind of group thinking exercise.

  • http://schipplock.de Andreas Schipplock

    Hi,
    what if there is no whiteboard at all? I applied for some jobs for now and only one company had it and I even used it but the others didn’t.

    One company even wanted me to work five days for free to see how I work. I still worked for another company and it was suspicious either way.

    I’d never recommend to accept that for anyone.

    • http://www.skorks.com Alan Skorkin

      Hi Andreas,

      If people don’t have a whiteboard than presumably they don’t want you to answer any programming questions. I’d question the worth as a company, but it makes for a much easier interview :).

      The 5 days for free seems a bit suss, unless they have an awesome industry-wide reputation and everyone is clamoring to work there, it is probably not worth the hassle.

  • Krom

    They’re very nice tips. However, one might realize that sometimes it might be the luck of the draw for an interview. In many cases, I have had many of my friends for a Microsoft interview and several of them have an interviewer and the others and I would have another.

    At the end of the day, all of my group all got a second round and the people with the other interviewer didn’t. It’s happened twice so far, so sometimes, it can really be the fact that it’s having a different interviewer.

    • http://www.skorks.com Alan Skorkin

      This is most definitely true, much of the time it is about being able to adjust to the particular interviewer you have and figuring out what they would find valuable and impressive. One person might be a null check nazi and if you make sure you focus on that they will be happy, while another would think you’re focusing too much on minutia and won’t look on it favourably. You probably get better at this the more you do it, but then again noone wants to do lots of interviews :).

  • Korny

    I’d emphasize the TDD point – if you are going for a job that is anywhere on the agile spectrum (and why would you go anywhere else? :) you should make sure you indicate, at minimum, “well, first of course I’d write a test…”

    • http://www.skorks.com Alan Skorkin

      I agree, if it is an agile related job, you have to mention the fact that you do agile related, things, it would be silly not to.

  • Pingback: Dew Drop – Weekend Edition – March 27-28, 2010 | Alvin Ashcraft's Morning Dew

  • Pingback: Shared Items - March 28, 2010 « Jeetu’s Shared Memory

  • Some Guy

    Dealing with people is not an exact science? Ok, I’m good with that.

    I want to be hired for my skills with developing. The guy interviewing me works in HR, therefore he was hired for his skills dealing with people.

    And, as a result, if I want to land the job I have to have enough “people skills” to get around the fact that he apparantly has absolutely no way to assess my suitability as an employee, and is as useful as a dead fish when it comes to dealing with the fact that I may not “interview well” even though I could be the ideal person for the position.

    Now, for my question: what exactly is that dead fish in a suit working in HR doing all day long, if I’m the one who has to work around his inadequacy as an interviewer?

    In the real world, complaining does no good – this is the way the world is, if you want the job you have to have the “interviewing skills” to go with your “doing the job” skills. But the fact that none of the people hired for their “people skills” actually have any skill at dealing with people who aren’t exactly like themselves depresses me.

    Also, it should help explain why technical people have no respect for non-technical people. It has nothing to do with their lack of technical skills, and everything to do with the fact that we have to work around their lack of people skills as well.

  • Some Guy

    Also, how to move Mt Fuji:

    1) Find out why they want to move it, and identify more cost effective solutions

    2) If they insist, prepare a budget and let the client declare it to be too expensive and thus not actually necessary

    3) If that fails, leave Mt Fuji where it is and do some ineffective busy-work with earthmoving equipment while collecting money until the client goes bankrupt. This is standard for most multi-billion dollar contracts that end up several years overdue and then get cancelled anyway.

  • Pingback: Jak przygotować się do rozmowy w sprawie pracy – programista Java ? « Luka Blog

  • Pingback: 99 de cada 100 programadores, no pueden programar – Hipótesis o tesis? | GeeksRoom

  • Pingback: The Main Reason Why You Suck At Interviews: Lack Of Preparation | Lifehacker Australia

  • Pingback: The Main Reason Why You Suck at Interviews: Lack of Preparation

  • Pingback: Why You Suck at Interviews: Lack of Preparation | internetz

  • Pingback: The Paltering Grounds - How To Answer A Programming Interview Question And Look Good Doing It