Interviewing Programmers – the do’s and don’ts from both sides.

When interviewing programmers there are several things I’ve noticed over the years that either help or hinder the entire process.
I’ve personally been on interviews where I left discouraged, unengaged and in serious doubt of my fitness for this industry in general because of the treatment I received. And I’ve left others on top of the world feeling that even if I didn’t get that job, I was just glad to be in this industry at all, just because of the coolness of the people I just spoke with.

There are some interesting issues with interviewing in general – you probably get about an hour to make a judgment call on someone you may well be working with in close quarters for months. It’s a far from ideal situation, but with the distances involved in lots of cases, it’s about the best you can expect.

Based on some interviews I’ve had over the years, and some I’ve run myself, I thought I’d offer up some basic rules to interviewing programmers so everyone feels they got the best out of the time, and the best judgment can be rendered.


For the Interviewee

1. If the company you are looking at has published some games then PLAY THEM. It doesn’t matter if you have to rent them from blockbuster, or only play the demo on Xbox Live. Whatever you do, have something to talk about that’s company related when you get there. It proves you do your homework and it also says something about the fact that you’ve thought about the interview before you got there.

2. Similar to 1, do some web research before you go. Look up the company on Yahoo Financies, look for press releases on sites like ShackNews or Blues or Games Radar or whatever. Look and see what the current news is on this company, so when they ask you “Do you have any questions?” you can ask something topical about the company.

3. Dress appropriately. Do NOT go in there wearing the TShirt from your last company. If the last game you worked on was great, someone might well compliment you on it. But others will not, and you won’t even know you’ve been marked down for it.

4. Do NOT diss the last company you worked for. If you got fired, or you genuinely think they were idiots, keep that express information to yourself. Phrases like “They were going in a direction I couldn’t see myself going” is enough – you don’t have to run them down. Remember this company doesn’t want to hire malcontents and you don’t want to display yourself as one. Yes, you may have worked for EA in the past; try and find the positives about your time there, not the negatives.

5. Agree with the interviewer as much as you can. Obviously you don’t want to sound sycophantic, but you *do* want the words “Yes, absolutely” and “I totally agree; that’s been my experience as well” to be flowing as much as possible. I’ve found the phrase “Yes, I can totally see what you mean. I’ve found some other issues in addition to that” as being a way of disagreeing with what someone has said without being confrontational about it.

6. Do NOT argue with the interviewer. I’ve had that delight a few times when I’ve been asked to produce a result, done so and then found that because it wasn’t the way the way the interviewer would have done it they want to pick it to pieces. Care must be taken not to argue this out with the interviewer, no matter how much of an obvious idiot he may be. The engineer in all of us likes to be right, but the moment any open confrontation occurs in an interview you might as well get your coat because you are done, whether they say so or not.

7. Try and remember names. Nothing is nicer than being addressed by name as an interviewer.

8. Be sure to do a follow up “Thank you email”. Nothing shows a little class like a thank you note, regardless of how well you do. You may not get this job, but you may be thought of for the next one.

9. Do some preparation. A evenings worth of brushing up on C?+ or OOP terminology can be the difference between getting a job or not sometimes. Trying to remember how trig works is just good anytime, let alone for an interview.

10. Try and ensure you actually have a description of the job you are going for before you show up – that way you can prepare for what the job requirements are rather than just hoping that you are either smart enough of have enough experience to cover it. There’s nothing worse than sitting in an interview being asked if you have experience of A, or B or C and just sitting there saying “no, nope, uh uh”.

11. Understand that at the end of the day your experience may not match the precise requirements of the job you are there for, but enthusiasm can make up for it in many areas. As an interviewer I may judge that you don’t have the experience to be a lead server engineer just yet, but that you have the desire and will to be one, and as such you can grow into the roll. Being engaged with the interviewer and the questions, interested and looking for ways you think you can fit the profile matters hugely in a very subtle way.


For the interviewer.

1. Please please please review the candidates resume before you sit down with them, if this is the ONLY thing you take from this. Having some idea of my history and skill set starts us off in the right direction, rather than me having to waste some of the little time we have recounting my personal history. It just shows some respect for the candidate’s time.

2. Following on from 1, have some prepared questions. Having some idea of what you specifically want to ask about enables you to keep the interview on track, without it wandering all over the place and overrunning because neither of you can keep to the point. Remember, the candidate doesn’t know what you want to know about – it’s up to you to ask.

3. On the subject of questions, you do need to think about what your questions represent. There are some questions that is a test of knowledge “what does the virtual keyword do?” etc. Those are simple and obvious questions to ask, however most of the simple stuff should have already been asked before the candidate gets there (see the Technical Tests section). What you really need to know is how the candidate thinks, what his experience level is and what he wants to be doing, to see if it matches up with your requirements. So the questions need to be exploratory questions rather than questions with specific answers – the question itself is just a spring board for a conversation where you explore an issue together. In the same way you’d collaboratively develop by bouncing ideas off each other from you need to foster that in the interview process. Sometimes I’ve even used situations I need to solve in my work as interview questions, because then I don’t know the answers and are judging more how the candidate works than his ability to just know the answer.

Further to that, try and avoid trick clever questions that you already know the answer to. The Bumble Bee question is an example of that (the question is how would you work out the total distance a bumble bees wing tip moves in a minute, relative to the bee’s body) – the answer is something you would either know or you wouldn’t – if you know it then nothing is being learned about the candidate except they’ve heard the question before, and if they don’t know it the likelihood that they’ll work out the answer in a very artificial situation like an interview is unlikely indeed, which just makes everyone feel awkward.

There’s also a type of favorite question that lots of engineers have that they like to ask in order to see what a developer knows (at least that?s what they say), but in actual fact it?s to confirm to themselves that the other people isn?t as clever as they are. And there are many many programmers like this. It?s usually a ?if I have this situation, how do I work out X?? kind of ques?ion – where the programmer doing the asking already has in his mind the perfect answer and if you don?t arrive at that, you aren?t as clever as they are.

This quickly degenerates into a Can I Read Your Mind situation as the interviewer tries to guide the candidate to his perfect answer, which does no one any good.

The whole point of the questions you ask is to provide as close to a real development situation as you can, rather than an artificial situation where the candidate is not relaxed, is sweating getting the ?right? answer in front of several people with their arms folded staring at him. No one does development like that – why would you interview people like that, apart to intimidate them?

4. Be on time for your interview. Nothing says ?I don?t respect the time of others? like being late for an interview. If that?s the case, the candidate is going to be sitting there thinking ?what are you like to work for???.

5. Remember the candidate is interviewing you as much as you are interviewing them. Let them have their say about the questions you ask rather than butting in with how great a solution you have. I have, in the past, when faced with a verbal technical test said ?Sure, let?s do that. You need to know that I know what I am talking about. But since interviews are two ways, for every question you ask me, I’ll ask one back – that way I’ll know you know what you are talking about too” – which is actually pretty hard to argue with from the interviewers side. That actually enables me to ask them awkward questions if they insist on asking me ones – it basically makes them look as stupid as it will make me look, so balance is restored.

6. Give the candidate time to ask you questions – they WILL have some and you need to give them time to ask them.

7. Remember, this candidate has been talking all day – when you start the interview, ask them if they need anything to drink or if they need the bathroom.

8. If you are going to do White Board programming questions, don’t make people write code on the whiteboard. It takes forever and you are constantly erasing stuff and re-writing it to fit it in. If you are going to do that, use a laptop and a projector. By all means use a whiteboard for math and trig questions, but not for actual code.

9. The most important thing is to Be Interested in the Candidate and Engage Them. Ask them questions on their answers they’ve already given you – don’t just read from a stock set of questions you have. See where their mind goes and have a conversation rather than just lobbing questions at them, hearing the answers and asking the next one on your list.

10. Try and be on topic relative to the position under discussion with your questions. I once went to an interview for a process engineer (he who tries to find better ways to make games – checkin processes, ways to keep the build more stable – auto testing situations etc) and the first interviewer wanted to do trig questions. I hadn’t done any of that in years, and it wasn’t at all relevant to the position I was there for, but they asked it anyway. I was completely unprepared and looked bad and it all went downhill from there. Would I have made a good process engineer? Sure. But I was never asked about that, only about trig math I hadn’t done in years. I consider that to be a massive failure on the part of the people doing the interview, since they weren’t appropriate for the position being discussed.

11. If you can, get together as an interviewing group before the candidate arrives as well as afterwards. At the before you should be asking and explaining what each person intends to cover in their session – am I doing a technical interview, or am I doing fit for studio? Is there something specific we want to cover given the resume we have in front of us? Once the interview is over, get together again to report your findings. Doing it in person is Much Better?than via email, since a dialog ensues rather than simple thumbs up or down.


Technical tests.

Do the technical tests before they get to the studio. You have precious little time with these people (as people) to make a judgment call that might well have them uprooting their lives and that of their family. Sitting them in an office with them chewing a pencil trying to remember if the ‘=’ operator override carries down through an inheritance, or which one is dot product and which one is cross product is Not the way to spend that time.

By the time the candidate gets to you you should already be fairly sure they are at least not completely stupid regarding their technical abilities. A timed test sent over the internet via email is usually sufficient to deal with testing the basics. “But they can cheat and use the internet!” I hear you cry. Yes they can, and quite frankly I have no problem with that. What do you think they are going to do when they work for you? The Internet is a resource and as such should be used as one.

Regarding the actual content of a test, I am personally a fan of essay type test questions since it forces those taking the test to put stuff in their own words rather than just cutting and pasting. Cutting and pasting becomes obvious with those kinds of questions and even just reformatting in your owns words means you still have to actually grok the answers, which is the whole point.

One nice hint. Putting in a section on each question for How long did you predict the answer and How long it took is nice. It doesn’t always get filled in and it isn’t always actual values that are real that are put in there, but as an interviewee it’s nice to be able to gauge yourself. Another item in that feedback section that gives your feeling on appropriateness of each question is also nice feedback.

Another thing to understand is that while you may do C++ specific sections, those sections that are actual coding questions need to be acceptable in any language, be it perl, php, python etc. Of course that does mean you’ll need someone who can understand the answers, but it’s worth it to allow the candidate some degree of comfort level.

Remember, a test will only act as a negative filter – if someone does well on a test it does not mean they are great programmers and a fit for your studio. However if someone does badly on a test like this, it probably means they won’t be. So it’s just a filter for use to determine who moves forward to the phone / onsite conversations.


Some great personality fit questions I’ve been asked in the past –

1) If I hire you, what would I most regret about that 6 months from now (hint, the answer to this is in how long they take to answer, not what the answer actually is too slow and they are trying to think of something you’ll want to hear. Too fast and they aren’t thinking about who they are at all)?

2) Can you tell me something in your life that you tried, was hard, but you were successful at? How you went about it, and how you felt on accomplishing it? (Remember, you can’t ask about personal life, although if they want to volunteer it, then great)

3) The reversal of 2 – Now tell me something you tried, that was hard, and you failed at. What would you do differently if you had to do it again?

4) If you died tomorrow, what would you regret not doing? (Not “what would you regret” – the question is “What did you *not* do that you wished you had?”). Again though, keep it game development related.

5) What would keep you in this job for 5 years or more?

6) If money was no object, what game would you make?

Good luck out there!

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>