Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases
October 31, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Interviewing Software Engineers
by Jason Taylor on 05/29/13 04:12:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


Summary: I recently went through the interview gauntlet in search of my next job. I was reminded of how badly most companies interview software engineers. Here are some anecdotes and suggestions for companies to improve their process.

Interviewing Software Engineers

I have done a lot of software engineer interviewing in my career. I've been on both sides of the table of course. Most of the interviewing advice you read is targeted at the candidate. "Study these principles," "memorize this model," "review these standard questions," "arrive early," "play their games," "come prepared with good questions," etc. There is very little advice for the interviewer available, and that is evident from the many, many bad interviews I've suffered through over the years.

I'll classify bad interviews into the following categories: Too Hard, Too Easy, Inconsiderate, Inconsistent, Unrepresentative.

Too Hard

This type of interview is the easiest to spot. It begins with a culture of elitism from the interview team. When I worked at HP one of the hiring managers in our group actually said, "If they didn't go to a top-ten school why are we even talking to them?" Young, hot-shot engineers often treat the interview as a pissing contest or a hazing ritual. Grizzled, grumpy veterans with a "what's wrong with kids today" attitude will be merciless.

Proponents will say, "We need to set the bar high." Fair enough, but interviews that are extremely hard are less effective at actually determining the quality of the candidate. Simply put, hard interviews assume the candidate has fundamental and mid-level skills and focuses on deep understanding in a small set of topics.

The result of the Too Hard interview is too many good candidates get passed over, and occasionally you hire an idiot that happens the know a lot about the one thing you grilled him on.

My advice: Start with easy questions and ramp up difficulty based on how well they are doing. Ideally spend only a short time on easy questions, about half of the time on medium, and a fair amount of time on hard. If there are doubts about the candidate have them back for a second interview focussing on suspect areas or specific skills.

Too Easy

I was once on an interview where, at the end, I wasn't sure that I had said a single thing that demonstrated I had the skills for the job. As it turned out the interviewer, my future boss, had no experience in this field or even as a manager. It was lucky for them I was qualified. But it was also stupid of me to take the job, which turned out to be the worst job I've ever had.

The interviewer is either incompetent, apathetic, or timid.

The result of the Too Easy interview is you'll hire anyone who walks in the door. Almost as bad, you put people in roles that are at the wrong level for their skill set (either too high or too low) because there is no way for the interviewer to distinguish good from great from okay. Finally, the candidate doesn't get a sense of what is actually required for the job and whether they would be a good fit for it.

My advice: Geez, just have good interviewers. How hard is that? Hard. Well, here are some one-off suggestions: Don't send a client engineer to interview a server engineer. Don't send a my-first-job engineer to interview a 15-year veteran. Reduce the likelihood of apathy by having the affected team interview the candidate, i.e. don't have a neutral hiring committee. Don't let timid or socially-awkward people interview. (Yes, this last one can be challenging.)


I once arrived for an interview and couldn't find the company in the building. I checked the recruiting email and the company's web site. I was in the right place. I called the recruiter. "Oh, you're at our old address. We recently moved."

A few weeks ago I interviewed at a startup. The HR rep told me to ask for her, but she wasn't there when I arrived. I was directed to a room by one of the engineers. I didn't know how long I was going to be there or who I was interviewing with. "Hi, my name's Mike. I'm the client lead. Well, let's get right into it. I want you to write code on the board to solve the following problem..." An hour later another engineer did practically the same thing. Then it happened again. After talking with the VP of Engineering and the CEO I finally met the HR rep. My performance was less than my potential, but I was pretty sure I didn't want to work there anyway.

When I was a hiring manager at EA the internal recruiter routinely would fail to greet the candidate in the lobby. The engineers would end up retrieving the candidate 10 minutes late. By the time the first session started they had lost 15 minutes.

When you are inconsiderate to candidates you make them not like you and not want to work for you. Pretty straightforward. What is less obvious is that you throw off their game. You agitate them and likely negatively affect their performance.

The result of the Inconsiderate interview is you miss out on good candidates because they didn't seem that good or YOU didn't seem that good.

My advice: Make sure it is clear who is responsible for recruiting, set clear expectations, and take action against those who aren't doing their job. (Note that there is no shortage of recruiters. If you have a crappy one fire him and get a better one.) Greet the candidate, give them a schedule, give them breaks, provide lunch if it's lunch time, thank them for taking the time to come in, make sure they know how to get to their hotel/airport/whatever, walk them out. Don't be a dick.


I'll jump straight to advice here. Be consistent with who is interviewing and what types of questions they ask. Not only does this allow you to compare apples-to-apples with multiple candidates, but it allows you to inspect and refine your interview process. Questions that don't seem to predict ability of the candidate can be replaced in favor of ones that do. Interviewers that don't ever have much of value to add to the post-interview discussion can be replaced with ones that do.


This is my favorite category. And by favorite I mean least favorite. I'll go so far as to say I believe this is the most frequent bad interview type. Also, it's probably the worst for your company.

I once applied at a social gaming company for a Flash/ActionScript job. Even at the time I was a Flash expert with several years of experience and a few projects under my belt. After a successful phone screen they gave me a take-home programming test. I was to solve a problem... in JavaScript.

Many of the engineers I've worked with love to pose logic problems. "So you have this gold brick, and you can only cut it four times. Each day you need to pay blah blah blah." "You have two stables and all these horse. Each horse runs at a different speed. You want to get all the horses from the first stable to the second stable blah blah blah." Okay, these kinds of questions are bullshit. First, you are assessing if either they've heard the problem before or they're pretty smart. You don't know which. Second, while smart is good is doesn't directly translate to coding ability. Third, if you really need someone to solve these types of problems on the job there are known solutions to them that can be looked up. Forth, you don't need someone to solve these types of problems.

"Here's a problem. Now start coding the answer on the whiteboard. You explain what you’re doing with half your brain while the other half of your brain performs the entirely different activity of writing code. I'll sit behind you awkwardly judging your every move. Each step of the way I will interrupt you for things like missing parenthesis, off-by-one errors, and typos in variable names. You'll need to know the exact function signatures of any library call you make. Oh, and I don't know the language you want to code in, so I'll just have you code my favorite language that you haven't used in over five year." Yes, dreaded whiteboard coding happens pretty much every interview. Because on the job that's how you code. You don't do it quietly, by yourself, after careful consideration of the problem in context of the entire system. You don't have an IDE with syntax highlighting and code completion. You don't have reference material. You can't quickly write and test small increments of code. And you certainly aren't proficient in the language that you do your work in. Oh, wait. #sarcasm

I was at a conference on how to be successful at engineering outsourcing. In relation to hiring I heard excellent advice from a manager from BioWare Austin. They worked with a company in Russia to do a significant amount of work on a project. He said, "Interview like you work." The leads communicated via email, in English, with system specifications for the Russian developers. The developers did their work however they wanted, checked in code, and emailed back that it was done. For this type of relationship, he said, it didn't make sense to have a traditional conversational interview. Instead he handed them a piece of paper with a problem, provided them a laptop with a Java IDE, and left them undisturbed until they were finished.

For the Unrepresentative interview you waste time assessing skills that aren't actually needed for the job. You might end up with a puzzle-loving, unintimidated whiteboarder, but that doesn't mean you have a good engineer.

My advice: Include a take-home programming test BEFORE the candidate comes in. The test should take about four hours. Assuming it looks good bring them in and spend at least thirty minutes discussing it to make sure 1) they actually wrote it, and 2) that they can discuss design considerations and trade-offs meaningfully. NO WHITEBOARD CODING. Save the whiteboard for drawing architectural diagrams and other things that engineers actually do at work when discussing things with each other.


The bottom line is you want candidates to perform their best, you want to ask a broad range of questions to accurately assess their abilities, you want a consistent interview process with a qualified and professional interviewing team, and you want to interview in a manner and on the topics that are relevant to the position.

Related Jobs

Amazon — Seattle, Washington, United States

Sr. Software Development Engineer - Game Publishing
Intel — Folsom, California, United States

Senior Graphics Software Engineer
Pocket Gems
Pocket Gems — San Francisco, California, United States

Software Engineer - Mobile, Backend & Tools
Grover Gaming
Grover Gaming — Greenville, North Carolina, United States

3D Generalist / Artist


james sadler
profile image
I cannot begin to express how much I agree with your statements. I recently applied for a general programmer position at a game studio and was told to take an at home test. I had 8 hours to complete it and it needed to be done in C (no not C++ but C). Granted I have experience in C, but it had been a long time since I had touched that low level of a language in awhile. The other part that bothered me about that is that this was a company that didn't do hardware level gaming so there really was no reason I could see to program at that low level. When I had roughly 8 hours I could afford to spend on the test I went ahead and looked at it. Two questions that spread over 5 pages. The questions themselves were not clearly written in a way that one understood exactly what the employer wanted and their complexity was ridiculous for an entry level position test. The internal struggle came in of whether or not I even wanted to attempt it. Did I really want to work for a company that had this level of expectation of a general programmer? I worked through the problems for about 4 hours before giving up. Needless to say I don't work there.

Jonathan Jennings
profile image
I am terrible at working under visible pressure, not tense situations or meeting close deadlines but working out a solution under anothers supervision or watching eye . I have no idea why that is but it is the case. it's not even a problem if they are in my general area but for some reason when i am being observed in that situation my insecurity / nervousness combine to make me a nerve-wracked mess.

so for a person like me being asked to write down even a basic program in this setting is nightmarish , I fully understand that my future employers would like to see me work through a problem and that is fair but how often is it that a programmer has to work with an audience ? usually a task is handed out and you report it once its finished .

to me being tested in that situation is the worst . maybe its a problem I myself need to work on but I also feel like it forces me to work / think in a very unrealistic situation for most programmers and so nearly every time I have to interview in that situation I perform terribly/ nervously/ and I never feel like I get to demonstrate myself to the best of my ability which of course makes it an extremely long ride home.

Rich Levine
profile image
It seems that often baseball teams will put rookies with promising talent in the minor leagues to gain the skills they require to pitch in the majors. Too many tech companies don't do that. They interview and test as if candidates magically already have all the skills and knowledge they need. A better way would seem to be like in baseball. Test for abilities and promising talent, and after hiring be willing to train and nurture the specific skills desired.

Craig Jensen
profile image
I want you to write a LISP program on this whiteboard that writes Prolog programs that can solve logic puzzles like the ones you mention in your article above in the "Unrepresentative" section. You have 5 minutes: GO!

That was a funny article and had some good advice. I am in academia and to be honest we basically have already figured out all of the academic qualifications of a person before we fly them over. If they actually get to the interview stage, we are mainly assessing their social skills (including their ability to convey ideas by talking) at that point.

I am sorry you had some dreadful interviews.

Jason Taylor
profile image
No need to be sorry for my bad interviews. I'm sure mine were no worse than those of all the other engineers out there. :)

Ernesto Rojo
profile image
In reference to the inconsiderate:

I applied at a company a couple of years ago. Sent out resume and cover letter. A couple of hours later, I receive an email from someone in HR and they said "Here's a programming test. You need to finish it in 4 hours. You must finish it in order to qualify for the position." There was no warning. There was no scheduling of the test. Simply, "here you go." I emailed back and said "I'm sorry but I'm not available to take the test at this time. Can we schedule it for another day?" "She responded with, "I'm sorry that's our only test. Since you already have the test, if you can't finish it within four hours, we'll have to disqualify you."

Liz Canacari-Rose
profile image
*headesk* That's so terribly inconsiderate I would probably start a website to advertise to not apply to them.

Wylie Garvin
profile image
Consider yourself lucky--if their hiring practices are that bad, the work environment probably would have been unpleasant too.

Andy Lundell
profile image
That is moronic.

That's a bad sign of how their company must work internally.

Billy Xiong
profile image
Hi Jason. Thanks for sharing this. I'm not technically an engineer, nor do I code a lot, but these tips help in any situation, I believe.

As this topic specifies in the programming aspect of an interview, any form of interview should follow these guidelines to the job position. This all helps in what the company is looking for. Amazingly, not many people like you get to be in that hiring position to make that difference, let alone teach others.

We all want to be somewhere in our careers and in a companies point of view, they want the best. The solution to all of that, you start at the beginning of the rainbow or whatever that position is considering experience wise.

Now, this might all sound ridiculous, and it probably is. Why? I'm a recent Game Design grad. I consider all possibilities and want to work as a team towards a goal.

If I begin my programming career, I'll definetly keep this in the back of my head when the time comes--and an altered one at all times for other positions. Thanks again.

Ron Dippold
profile image
While I appreciate the at home coding test of something 'real', I think the in-room coding tests are just too useful to give up just because it gives you so much insight into their problem solving process (or lack of it). You can make them useful by:
- Use any language you want.
- Don't be too picky about syntax, unless you're hiring for a C job, they have C expert on their resume, and they don't know how to code a for loop (this happens far too often).
- Make it a real easy problem. It turns out there is almost nothing too trivial.
- Stay flexible.

For instance, I'll ask them to sort a list of integers, speed is not an issue. You get bonus points for saying 'Well, I'd just call qsort' or 'I'd invoke mylist.Sort()' since that should usually be your strategy. Okay, so then we talk about in what situations you wouldn't want to call qsort.

Either way, then they dive in, and it's really instructive to see if someone can just rattle off a bubble or insertion sort. Most people haven't done this, or it's been a really long time, so they have to think about it... It's a bad (but not fatal) sign if they just start writing code but can't nail it. Almost everyone who does this flounders at first. Eventually they'll realize that (almost) every sort takes at least two loops and muddle through. A really good sign is if they actually draw an unsorted list of integers and play around on paper or in their head what the process would be before they actually start coding. We care about that more than the code!

Once we get some code, and assuming it wasn't just total floundering, well then how would you optimize this...? When would you actually /want/ to use a bubble sort? It's give and take. At the end of it, all the people in the room usually have a very good sense of this person's problem solving skills, which is what we are really interested in. If you blow this our thought is that you won't be good at solving in a timely manner the much harder problems we face day to day. We had one guy who talked a good game but insisted, and was still insisting at the end of the interview, that he could do it with a one pass insertion sort and would not let us move on!

So far this hasn't produced any duds (knock on wood) and has filtered out quite a few resume padders.

Craig Jensen
profile image
Ron Dippold: I am a mathematics professor and so outside of the discipline--I teach cryptography classes occasionally but my field is topology. So feel free to ignore this.

Having sat on many graduate student oral examinations, I am with you when you say, " It turns out there is almost nothing too trivial." I am amazed at the questions which some very bright people can miss when put in this situation.

I find that the abilities to:
(1) Solve problems while at a whiteboard chatting with people;
(2) Solve problems at your own desk using tools available to you there;
are almost completely unrelated to each other. One is a somewhat extroverted on-the-spot oral problem solving ability and the other is more introverted research lookup related. If what you are after consists of people with the first type of problem solving ability, that is fine, but be sure that is what you really want. To be honest, I can see both skill sets being useful in different situations.

Ron Dippold
profile image
Hi Craig, I do kind of agree - In this case our needs are specifically for people who can solve problems fast (and well) with very little supervision even if there is very little published or searchable material. That's when we get called in. A common one is the hardware is defective in some strange way but can't be fixed in any reasonable timeframe and they need a software workaround now. In my experience the people who can't think about how to solve a simple problem on the spot will thrash in that situation, even though they might do great in another.

So it really depends on what you're hiring for - in our case it's a great tool. If you're looking for someone to design a new lighting algorithm, maybe not so applicable.

Ian Richard
profile image
I actually disagree with you Ron.

In the real world we have debuggers, Google (And other reference material), and far more information about what needs to be done and why. I recently took a programming exam and nailed it... every question with little difficulty. Sure, the internet didn't have the answers to the exact problems they had... but it could give me a starting point or refresh my memory. No problem completing the task in the given time.

When they called me on the phone and started asking questions Jeopardy style. That's a whole 'nother ball game. Without a full picture of what I was trying to do or time to breath... I fell apart. Misunderstood one question... it threw off my game and I couldn't think straight. It was over after that.

I don't blame the company for not hiring me, but they did miss out. I'm darn good at what I do... not so good at game shows.

I solve problems and I make things happen using ANY and ALL tools at my disposal. It wasn't my encyclopedic knowledge that made me hit every crazy deadline the industry threw at me... It was my ability find a solution and get it done.

Ron Dippold
profile image
@Ian: That is definitely the risk we take - but we've explicitly decided that a false negative is better than a false positive. And that if you can't deal with our friendly though demanding interviewers (we really want you to succeed!), you probably can't deal with our customers. But as Craig pointed out it entirely depends on what kind of position you're hiring for.

I guess, going back to the original post, I just wanted to say that in some cases a coding test makes perfect sense for the people doing the asking. We really are as accommodating as possible, and have hired people who technically failed the coding test, but the insight it gives into someone's problem solving process is unmatched. We can't see what you did on a takehome test. We know it risks rejecting people who just can't concentrate while being relentlessly watched, but for us it's worth it to only hire slam dunks and run short on staff for a while if we have to compared to working with someone incompetent.

However! Based on the conversation here I'm going to suggest the phone interviewers give an optional at home problem (which we'll come up with) that the candidate can bring in for the interview. It's more work for the candidates if they choose to do it, and I'd still like to see some active problem solving, but if you can shine on that, it's certainly a consideration for a job that doesn't deal with customers. I'm gunshy from dealing with so many bad programmers who think they're engineers, but I don't want to miss out on a genuinely good problem solver either.

Wylie Garvin
profile image
Ah, fond memories ;) I drove over two hours to get to the interview for my current job. It turned out they had no parking lot for visitors, and all of the nearby street parking was either taken up by employees, or had parking meters. So I parked where a meter was and had to leave the building multiple times during the interview process to put more money in the meter. I was quite surprised back then, because I'd never worked for a company that didn't have a parking lot for visitors, and my workplace at that time had acres of parking lots. Of course now I realize that nobody has parking lots in the city here, and I hardly use my car in the city because figuring out where to park it is a hassle.. Turns out working in a city core is a little different from working in the suburbs.

Edit: one of the team leads who interviewed me that day, described a hypothetical problem scenario to me (random crash with not-exactly-clear root cause, or something like that) and asked me how I would go about trying to solve it. It seemed to me like a good question for an interviewer to ask, because it gets the candidate into a problem-solving mode and shows what their approach is like, and the candidates who have experience debugging real stuff will clearly stand out from the candidates who don't. That kind of thing seems much more useful to know than whether they can write a 6-line function on a whiteboard for some contrived example problem.

Jason Taylor
profile image
Ron: I definitely agree that seeing how a candidate approaches and works through problems is very important. The give and take example of yours as well as Wylie's are exactly right. At that point you are assessing problem solving and possibly data structures, algorithms, and best practices. Independent of that you still need assess their coding ability. The whiteboard will give you many false negatives.

I advocate the pre-interview coding test because by the time a candidate has come in you are already heavily invested as a company. There's lost productivity for the whole interview team, potentially travel costs, etc. For relatively little effort on the company's part, a coding test will give you a very strong filter for the most important job requirement. If they pass that and come in you can focus on problem solving, social skills, communication, specific technical knowledge, or whatever else is important for the role.

Ron Dippold
profile image
Hi Jason - take a look above, but I'm going to come up with a pre-interview coding test for our phone interviewers to suggest to candidates. We generally prefer false negatives over false positives, but if someone can blow us away with an offline coding test...

chris kirby
profile image
My favourite was a two day, write a game with our engine test.. had great fun doing that.. Unfortunately had to turn the job down as i was offered another (not necessarily better as it turned out) position.

Rich Skorski
profile image
"Don't send a my-first-job engineer to interview a 15-year veteran"

That situation can be very beneficial if that younger engineer asks the right questions. They should not be assessing the veteran's knowledge, but rather how well that veteran can teach. In my opinion, it would be unwise to hire that seasoned engineer if they can't help out the younger ones. This trick works for senior inerviewers if they are evaluating somebody for a discipline that they are not strong in, too.

Mike Swayze
profile image
Job interviews for Engineers/Architects- so when does my EIT certificate come into play. I thought Architects were building designers- ya know -residential or commercial. Where's that shingle (Pros)
Reality bites- usually HR do things to justify their jobs- a few I've met didn't (thank God).
Software Jobs- I'm just getting started- Debating a PE license in the process (I wonder how that Dept. of Insurance paperwork plays into it.(license to practice)..)

Best Interviews are questions related to your work habits and attitudes- the rest is usually OJT with a given initial skillset. Worst one I had was with EDS(Ross Perot) when they were after GM business (and hiring extra bodies for the contract work...). It was all about how you handled 'stress'- A bunch of lightning fast, wrong answer questions(no matter what you answered...). LOL
Usual Interviews with HR are to satisfy upper management/lawyers-not the people you'd work with( the ones who should make the decision to hire you...)

Kenneth Blaney
profile image
Although these interview types are great for determining whether or not people are qualified, only the representational interview has the added benefit of also testing how well someone fits within a specific corporate culture. Working for a company like Valve or Google would be a lot different from working for a company like EA or Microsoft.

Katie L
profile image
"My advice: Include a take-home programming test BEFORE the candidate comes in. The test should take about four hours."

The problem with this is that loads of people are already doing this. I've recently been round a bunch of places interviewing to see if there's something more fun than my current roles. I've turned a bunch down, just because they were the fourth, fifth and sixth in line to try to deliver me anything between three and eight hours of pre-work before they'll even let me to talk to someone to see if I want the role. It's not a very good way of cutting down the demand I'll admit, but the thing is, I've got no shortage of recruiters phoning me up, no shortage of places to talk to and actually pending offers.

There's a limit to how many of these things you can physically do if you already have a job. Also it gets dull really quickly; especially after 20 years in the business. While I agree there's a lot of people out there who actually can't program, there has to be a better way of doing this than loading them up with homework. And risking that you're not at the front of the queue demanding a free day's labour off the ones who can... remember the joke about shredding half the CVs because you want to hire lucky people? Demand a day's free work off someone who already has a pile of such demands and you're being filtered the same way. Is that a way to aim for hiring good people?

A trend I'm seeing is that these tests are getting longer -- they used to be an hour to do which wasn't too bad. Now they're supposed to take a working day. You want me to take a half day off for a phone screen with a non-technical recruiter, a day off to do the programming assignment and then a day off to come to interviews... that's quite an investment of my time in your company. Unless you're a BIG name company whose reputation proceeds you, that's a lot of investment before you deign to respond with any.

Notable Google, Facebook, Amazon and Microsoft don't do these things and they're ALREADY companies that people want to work for and would jump off buildings for a chance to interview with.

The problem with building ever more elaborate mazes for your candidates to run is that increasingly you'll get the candidates who are just desperate to run your mazes. The ones who didn't get a job on their first interview attempt... An hour isn't a problem to fit in round things. I had a recent one insist I cancel a medical appointment to do their day-long test to their timescale... they may have missed the point that I already have a full-time job and they need to look less, not more annoying than my current workplace.

Another one won't accelerate their interview schedule by skipping the tests (which I don't have a spare day to do) despite me holding several offers including one from their larger competitor...

And certainly if you're trying to take really good experienced staff off a competitor, sending them a noddy puzzle to see if the can code at all doesn't really start the relationship off on the right sort of foot. All too often these things come across as condescending.

Interviews with good staff are TWO WAY processes. Too many companies seem to forget this. Spend a fortune attracting talented people and then run an interview process which drives people away.

Jason Taylor
profile image
To be clear, I'm advocating a coding test before you bring someone in, but AFTER they have been filtered so some degree. I prefer an engineering lead or hiring manager to screen resumes, then a recruiter to talk to the candidate for 15-30 minutes (tell them about the role, see what things they are interested in, assess their social skills), then an engineer to ask them tech questions for 30-60 minutes.

You could bring them at that point (which is traditional), but again I'll say that you will not be able to accurately assess their coding skills specifically when they are on site. It's just the wrong environment. A four hour coding test is a potential waste of time, but so is a 4 hour in-person interview.

Reasons to skip a coding test: "I've worked with that guy before. He's an awesome coder," and, "That guy was the lead engineer on [awesome game]."

Lastly, I'll say that you need a process that your team is happy with. Maybe that means a one-hour coding test before a candidate comes in. Maybe that means a two-hour coding test on site. Maybe you give them bad code and have them identify what's wrong with it. Please don't ask someone to code on the whiteboard though. :)