Game Programmer interview questions

The couple interviews I've had were pretty light on maths (although I don't advise you to expect the same). A lot of the questions I dealt with were things like general C++ questions (pros/cons of templates, virtual functions overhead in terms of memory/performance) and other game related concepts such as memory management, collision detection, etc.

While light on math, there were a few vector questions such as distance between two points and a few theory questions on matrices.

It really depends on the person interviewing you (unless there's a set test). There are some people in my office that really like throwing probability questions around, and there are some that prefer to ask programming problems. There's even one or two that like asking about debugging techniques (which usually throw new graduates for a bit of a loop).

I guess the best advice I could give you is to try to understand math and programming as they apply to the job you're interviewing for, since there's no single list that will help you prepare.

Thanks, I appreciate the feedback.

Quote:

Original post by Lexdysic I just had a day long interview last Wednesday at a studio in California. I experienced all different types of questions about math, c/c++, general programming questions, low level programming questions, graphics questions, and questions about my own projects. Basically, I had four different interviews. 1) Low level/ optimization. Really tough low level programming questions which had you question your knowledge about the pros and cons about different things like virtual functions, templates, multi-platform programming, and the graphics pipeline. At the very end they threw in some whiteboard programming. Search for "Programming interview questions" on Google for some examples. There really is no way to prepare for these, you just have to think things through and do your best to explain what you understand and how you will attack the problem. Usually if you know the problem they will just give you a different one anyhow. 2) Programming exercise. This was a test to see how well I would do just jumping into a project and trying to learn a new API and code base while getting the a job done. This is really just up to your skills and knowledge. This tests wasn't so much how I code or how efficient I could make functions. It really was just about how well I adapt. 3) Specific C/C++ questions. This was just how well I knew the language and how to solve known problems. Things like the inheritance, virtual functions, polymorphism, linked lists, recursion, trees, casting, and design patterns. Really, these questions were to find out how well I knew the language. It was either I knew how to answer a question or I didn't. I was given some code snippets printed on a piece of paper and they would ask different questions about what would happen in different situations. I was also given some problems in which I had to write the solution on a paper. 4) Project questions. This was probably the easiest interview. It was just questions about what I have done and how I did it. Mostly just to find out that I wasn't lying on my resume about my accomplishments. I was even surprised to find out that they had downloaded and played a couple of my games and were able to ask very specific questions about each game. All in all, there is only so much you can prepare for and a lot of other things were just to find out if you have the knowledge or not. Every interview will be slightly different and certainly not all will be a day long event like what I experienced.

Was this for an entry level position? Seems rather excessive to me for a code monkey position where you are told what to do.

>> What sort of questions have you guys been asked in the past? What are the main skills that potential employers look for from their programmers? If you've actually given interviews for potential employees, what questions did you ask and what did you look for in the responses?

You've had some answers from the candidate's perspective, but you should also consider the view of the employer.

An employer is interested in exactly two things:
1) Will you do the job well?
2) Will you fit in with the team?

That's it.

Keep that in mind when answering questions. If they ask you some stupid trivia question (ie: "Why are man-hole covers round?", or "Roughly how many gas stations are there in the city?" or some such) they are just trying to look for your answers in terms of those two questions.

If you know the answer to the questions, then great. If you don't know the answers, let the interviewer see your thought process by thinking aloud, asking smart questions, and using appropriate social graces.

One co-worker loved to ask candidates what their favorite music style and favorite band was. Another asked preferences of right-handed or left-handed world spaces and which direction +z should go.


As a job candidate, YOU should be asking questions of them, too.

You should be interested in the exact same questions they are:

1) Can you do the job well?
2) Will you have a comfortable fit with the company?

Those two points lead to a lot of questions for you to ask: What would be expected of you? With whom will you work? How is individual performance measured? How is it rewarded? How are mistakes within the team handled? How big is the team? What are their backgrounds? etc.



Good luck with the interview. Just have fun and be yourself.

Thanks a lot for all of the advice, I really appreciate it.

Hey guys, I have another question which is related to the first so I thought I'd keep the forum a bit tidier and just post it in here.

Is it necessary/useful to learn C in addition to C++? I had assumed that C++ covers all things related to C and then builds upon it, however I'm not sure if typical C++ literature covers everything that I might need to know about C to get a game development position in the future.

Quote:

Original post by Exomoto Hey guys, I have another question which is related to the first so I thought I'd keep the forum a bit tidier and just post it in here. Is it necessary/useful to learn C in addition to C++? I had assumed that C++ covers all things related to C and then builds upon it, however I'm not sure if typical C++ literature covers everything that I might need to know about C to get a game development position in the future.

I would at least read up on some of the more common C library functions such as malloc and free. I remember taking some tests that were all C based when I was looking for a job.

Quote:

Original post by Exomoto Is it necessary/useful to learn C in addition to C++?

It may not have to be necessary, depends on the job, but it certainly isn't unuseful. Many C++ programmers prefer to use C-like vogue, so it will help you to read and understand their code.

Quote:

I had assumed that C++ covers all things related to C and then builds upon it

C is no longer a subset of C++; the two have grown into separate languages that just share the same lineage.

I have had questions where they say you have an assembly language made up of a few instructions then ask you to write some function. Usually a pretty simple function. I have had software engineering questions like how would you design an inventory system that had certain characteristics. Really there is no way of knowing what they are going to ask outside of finding someone who has already interviewed with the company.

My company has an entry test which includes small programming exercises, programming theory and maths. If you have already programmed you shouldn't have any problem to pass my company's test. Furthermore, to understand the potentiality of the programmer, they give big importance to his programming examples and previous experiences.

I've heard of companies which put on their test much harder stuff like assembly exercises!

It's very important to know how C works.
We are working on Nintendo DS and PSP and we haven't things like string, vector.
We are using classes and polymorphism but we still had to write A LOT of old style C code.

A lot of these tests are just used to judge your experience. Don't panic about not getting a few questions right here and there if you're going for a junior job.

Hey guys, thanks again for the advice.

I had the interview and unfortunately someone else with more experience beat me to the position, still I thought I'd come back here and share my experience.

The test I was given was a simple C++ test designed to test my aptitude for problem solving. I needed to understand the basics like polymorphism and pointers to be able to answer most of the questions, but this wasn't the focus.

None of the answers required any real prior knowledge, just the ability to think problems through and find a solution. The interviewer was particularly interested in following my thought process.

Here's some of the questions I was asked:

Find out if a loop exists within a linked list.

Swap two variables without using any additional memory.

Write code to count from 1 to 100 and 100 to 1 without using any loops (while, for, goto, etc).

The rest all gave code examples which had to be checked/improved.

The interviewer seemed more than happy to talk through my examples and input his own ideas, and responded well to technical questions.

ok now I'm feeling like a noob programmer cause of those questions you posted. What are the answers to:

Swap two variables without using any additional memory.

Write code to count from 1 to 100 and 100 to 1 without using any loops (while, for, goto, etc).

?? I have no idea how I would answer those?

Quote:

Original post by RespeckKnuckles Swap two variables without using any additional memory.

I suspect the question didn't require a generalized function that would work with any type of variables, but probably rather swapping the value of two integers or similar as that is fairly easy to do with arithmetic operations.

void swap( int &a, int &b ){  a = a - b;  b = b + a;  a = b - a;}

Quote:

Write code to count from 1 to 100 and 100 to 1 without using any loops (while, for, goto, etc).

This is trivial to implement using recursive functions.

Quote:

Original post by Luctus Quote: Original post by RespeckKnuckles Swap two variables without using any additional memory. I suspect the question didn't require a generalized function that would work with any type of variables, but probably rather swapping the value of two integers or similar as that is fairly easy to do with arithmetic operations. void swap( int &a, int &b ){ a = a - b; b = b + a; a = b - a;} Quote: Write code to count from 1 to 100 and 100 to 1 without using any loops (while, for, goto, etc). This is trivial to implement using recursive functions.

That's how I did both of those, although I was told there are multiple solutions to the first answer. One thing that did catch me out though is that I counted from 1 to 100 then immediately counting back to 1, when I should've printed 100 twice (the interviewer was very particular about the details).

The interviewer also pointed out that my answer for finding a loop in a linked list would fail if it was called multiple times.

[Edited by - Exomoto on May 10, 2008 6:43:41 PM]

Another solution to the swapping variables is to use the xor operator.

x ^= y;
y ^= x;
x ^= y;




As for counting to 100 and back, are you allowed to use recursion, or is that considered looping?

You should have writen

printf("1\n");
printf("2\n");
.
.
.
printf("100\n");
printf("100\n");
.
.
.
printf("1\n");



just to see what they would say.

Its sad that trivia catchas like the above dictate whether you can get the job or not. Just because someone else had read up a book on all those trivias, doesnt mean hes better candidate.
What youre missing is the context of where these things are applicable. It could very well be, that you might implement a better optimized code to a problem using different approach, instead of these stupid tricks which might come in handy in low-level DS/PS3 coding in specific scenarios.

Most of all, if anyone is stupid enough, to consider your level of expertise, based on your answers to those questions, youre better off not working there. Seriously. They might throw up some general bullshit like - we need to know if you can think and decompose the problems. Which is OK, except the fact that you might have your own 3D engine/games on your belt proving that you know how to do the job and fix the problems.

But, since theres an overpressure of eager candidates, willing to devote their health, sanity and life for the chance to actually just devote their health, sanity and life to gamedev, they must have an easy way how to weed out most of the eager candidates.


Dont despair for not getting the job, though. Sooner or later you might realize that earning 4-times as much per hour in a non-gamedev job isnt that bad as it seems ;-) And thats just a starting point, which goes up with experience. Oh, and as a byproduct, you can have a real life outside the work, if youre not afraid to live it :-)

Quote:

Original post by VladR Its sad that trivia catchas like the above dictate whether you can get the job or not. Just because someone else had read up a book on all those trivias, doesnt mean hes better candidate.

That is true in some respects. Unfortunately most interviewers at game companies don't have specialized training in interviewing candidates.

These little tricks do have a side benefit - they are usually picked up by people who strive to be in the field.

Quote:

What youre missing is the context of where these things are applicable. It could very well be, that you might implement a better optimized code to a problem using different approach, instead of these stupid tricks which might come in handy in low-level DS/PS3 coding in specific scenarios.

Those are along the lines a good interviewer will ask, yes.

I'd be careful disregarding a good job just because you weren't happy with the questions an interviewer asked. It is important for you to interview the company, not just for them to interview you. Hopefully the OP did that, as was recommended earlier in this thread.

Quote:

But, since theres an overpressure of eager candidates, willing to devote their health, sanity and life for the chance to actually just devote their health, sanity and life to gamedev, they must have an easy way how to weed out most of the eager candidates. Dont despair for not getting the job, though. Sooner or later you might realize that earning 4-times as much per hour in a non-gamedev job isnt that bad as it seems ;-) And thats just a starting point, which goes up with experience. Oh, and as a byproduct, you can have a real life outside the work, if you`re not afraid to live it :-)

Fortunately, relatively few game studios operate this way.



Most studios have regular work days. Most studios pay well, and once you pass the entry level jobs, many pay equivalent with non-games industry. Most studios have other perks that you can't get in more mainstream jobs.

I've worked inside the industry and outside it. I've got experience with everything from migrating live database engines, writing conversion ETL jobs, and running performance measurements on data warehouses on one side. On the other side I've worked on engines, written rendering systems on three platforms, written AI systems for AAA games, and measured and optimized some parts of the most heavily used code in those games.

I am picky about where I work. Every game company I've been at has paid me roughly the same or more than the non-game counterparts, and have had a similar quality of life. I have turned down jobs at less-than-stellar companies, even when they have flown me across the country for interviews, because I wasn't sure about their quality of life. (ie: I personally wouldn't work at one particular company in New Jersey because I hate the lifestyle and pace over there. Other people may love it, but not me. )

It is the employee's job to make sure he is working at a good company. It is his own job to ensure the employer pays him well. It is his responsibility to demand a reasonable quality of living.



The difficulty part is getting that first game credit under your belt. There are, unfortunately, many game companies that churn through recent grads or near-grads, put them through a death march, and spit them out a few months later. In some respects, those places do us a favor by scaring off many wannabes with horror stories, and pruning those who don't really want to work in the first place.

Once you have your first game credit or two under your belt, if you are willing to work hard and willing to interview the companies while they interview you, and skillfully negotiate your salary, PTO, and other details, there is no reason to earn less or have a lower QoL than you would in any non-game industry.

I have to admit, I find these tests pretty pointless. I did my first ever round of interviews a while back and the tests I did poorly in was these C++ trivia tests, and the ones I did well in were the ones where they sat you down at the computer to make a game.

It's like playing a quiz machine. You either know the answer because you came across it before or you don't. It probably does appear like the test measures skill and experience, but it's like saying swaying trees cause wind, as the applicant is just showing they've been around long enough to have done tests like this before.

The good news is that it's always the same questions that keep cropping up. Should be easy to revise a bunch of stuff next time I go job hunting.