Game Programmer interview questions
Author
Hi guys,
I have an interview for a games company coming up, which includes a C++ and Maths test (presumably one test that mixes both). I've scouted around and found plenty of resources for what questions to expect in a programming interview, however I cant find much that covers the game related questions I might get thrown at me.
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? Any help would be hugely appreciated.
The position is Junior Programmer, however any contributions from interviews for more specific roles (e.g. Tools Programmer) that others might find useful would still be much appreciated.
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.
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.
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.
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.
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.
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.
Author
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement