More On the In-Person Interview

In my interviews I typically ask a combination of ‘soft’ questions and technical ‘trivia’ type questions; I also ask the candidate to write some code or web markup. Some candidates are put off by this, assuming that their stellar resume should speak for itself. But I have found that a lot of people who can “talk the talk” can’t “walk the walk”, and stumble badly when asked to write actual code. Part of that can be chalked up to nervousness, but after doing a number of interviews I can tell when someone is a BS’er – and a coding exercise can flush out the pretenders from the contenders.

Mind you, these exercises I speak of are not rocket science problems. They are simple exercises that a good developer should be able to complete in a few minutes – e.g., looking for a character pattern in a string, for instance, or coding up an HTML table.

If you are presented with a coding or other exercise in an interview, follow this advice:

1. Relax and take a deep breath, and make sure you understand what the interviewer has asked for. Ask him to repeat the question if necessary.
2. Don’t freeze up; nothing’s worse than someone panicking and turning into a statue. Ten seconds of silence can seem like an eternity in an interview. It’s better to think out loud, as it displays your thought process.
3. Don’t be afraid to ask questions. The interviewer will likely be willing to clarify the question and provide course corrections, or even provide hints. It’s only the rare sadistic interviewer who’ll sit there with crossed arms and furrowed brow and refuse to help out the candidate.
4. If you are rusty with a particular programming language’s syntax, ask if you can use a different language or write pseudocode.
5. If you feel that you truly cannot solve the problem, just say so up front and move on to the next topic or exercise. It’s better than spending ten minutes spinning your wheels and looking foolish.
6. Sometimes the interviewer will ask you whether you prefer “Approach A” or “Approach B” to solving a problem. Most of the time there is no ‘correct’ answer; they just want to see that you have thought about the problem in the past, and that you can discuss it in an intelligent manner. e.g. – Waterfall vs. Agile development processes.
7. If you are presented with a ‘Microsoft’ type of silly logic question (which I personally detest), simply talk out the problem verbally. e.g.,”How would you get 500 kerfoozles into a diddlysquat?” Answer: “Well, let’s start out by agreeing on the average size of a kerfoozle, and the methods available for transporting them…”
8. Given the types of pressures in the above situations, if you are offered water at the beginning of the interview you should accept it even if you’re not thirsty. You might need it desperately later on.