Interview Questions

Started by
10 comments, last by Tom Sloper 12 years, 10 months ago
Hi all,

I'd like to preface this by saying I did a search on this forum for interview questions and didn't find excatly what I was looking for so I thought i'd make a post. I have two interviews next week for games companies one for tools programming and one for gameplay programming both are at a graduate level.

What I would like from you guys is programming questions that you have had in interviews or that you can think of as relevant tests in order to help me prepare. I had an interview for a games company a few months ago and basically did not do very well on the programming test due to not knowing the specific answer they wanted and generally being nervous, feel free to critisize my portfolio (in my sig) as I am using it while applying for jobs.

Thanks!

Edit:

Ok so I found one thread that is like what I want, but feel free to add your own questions here so I can get as many as possible!
Advertisement
Every company asks different questions.

I'd share my experiences and what I was asked, but I'm under NDA, so sadly I can't. But I can tell you this much: if you're a decent programmer, you have nothing to worry about.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]


I'd like to preface this by saying I did a search on this forum for interview questions and didn't find excatly what I was looking for so I thought i'd make a post. I have two interviews next week for games companies one for tools programming and one for gameplay programming both are at a graduate level.

What I would like from you guys is programming questions that you have had in interviews or that you can think of as relevant tests in order to help me prepare. I had an interview for a games company a few months ago and basically did not do very well on the programming test due to not knowing the specific answer they wanted and generally being nervous, feel free to critisize my portfolio (in my sig) as I am using it while applying for jobs.


The point isn't to have you regurgitate a bunch of answers you read online.

The point of the questions is to find out how you think and how much you know.



You can cram on topics like const correctness and pointer manipulations and such, but that is not the purpose of the interview. A good technical interviewer will drill down to the point where you are uncomfortable. When I have interviewed people I start with basics and when in going in depth have gone mentally through portions of the language standard (I'm a 'language lawyer' myself) and asked questions that few people know the answer to. That will tell me how much they know of the language, sadly many beginners cannot even work with pointers. I'll ask other questions about concepts and theories in computer science generally, to see how much they understand it. I'd ask them about specific problems that we have encountered in our job to see how they would think about them. That is the only way to handle it since so many people want to simply memorize answers from the net.
It's pretty impossible to study for an interview, because you really have no idea what they'll ask.

I'll throw you some off the top of my head:

C++ questions:
How are constructors and destructors called in an inheritance hierarchy.
What should you consider when making virtual functions calls from a constructor or destructor?
Describe what virtual inheritance is and why it's used.
Draw a simple class as laid out in memory. Now draw one that derives from it. Now draw one that derives virtually from it.
What are some good reasons to use templates and some good reasons to avoid templates?
Can the order that I declare data members of a struct affect performance in any way? If so, how? If not, why not?
Why should you use smart pointers?


Some more general game programming questions:
What's data-oriented design? What are the pros and cons?
Pros and cons of using a scripted language?
Pros and cons of multithreaded programming?
Thanks for the feedback guys, I appreciate all of it. I'm not trying to just memorise answers from the net it's more just an exercise for my brain to help my state of mind when in the interview. The reason I asked here is that you guys are mostly within the context of games and have had experience with the interview process and could provide some relevant questions!

C++ questions:


How are constructors and destructors called in an inheritance hierarchy.
If the hierarchy is non virtual the constructor or destructor will be called for whatever class is currently in context (i.e. no lower in the inheritance chain than the current class).

What should you consider when making virtual functions calls from a constructor or destructor?

Not entirely sure I'm right about this one but, it should be taken into consideration that the virtual function that you are calling may call functions or use variables that may not be fully initialised within the inheritance structure.

Describe what virtual inheritance is and why it's used.
Virtual inheritance allows for functions that are defined at a base class level, when called to start execution at the lowest possible child class provided that the relevant function is defined. This allows for multiple objects to be handled through one base class but retain their own unique functionality.

Draw a simple class as laid out in memory. Now draw one that derives from it. Now draw one that derives virtually from it.
Not sure.

What are some good reasons to use templates and some good reasons to avoid templates?
Templates allow for generic programming in that they allow code to be written that is not directly tied to a single class. Downsides to templates are that they might produce some compatability issues, templates cannot be distributed as part of a library.

Can the order that I declare data members of a struct affect performance in any way? If so, how? If not, why not?
Not sure.

Why should you use smart pointers?
Not sure.


Some more general game programming questions:

What's data-oriented design? What are the pros and cons?
Not sure.

Pros and cons of using a scripted language?
Pro could be that the language would provide a more 'directed' API relevant to whatever was being developed, allowing developers to become familiar with the scripting language rather than having to learn something like C++ or C#. Cons could be that the scripting language would require some sort of interface between the native code in order to get it running taking time and possibly making the execution slower.

Pros and cons of multithreaded programming?
Pros are that jobs within a system can be process concurrently allowing the overall throughput of the system to increase. Cons are that the system would need to be made 'thread safe' so that objects and variables are protected from contesting threads.
I wasn't really asking you. You should look up any answers you don't know and verify any that you feel you do :)

I wasn't really asking you. You should look up any answers you don't know and verify any that you feel you do :)


Haha oh well, felt good to write them down anyway! Yeah I am doing so now, thanks very much for the questions!
If you are interviewing at a graduate level then you won't be expected to know everything. Hopefully the other candidates will be near your level of competency. The company will probably be looking for a quick learner with a keen mind who will fit in well with the team. Full knowledge of all the details is something you'll get with time.

To some level graduates will need to be "broken down", to get rid of some bad habits you may have formed outside a team. You might find yourself introduced for the first time to a large, shared code base; revision control; formal bug tracking; complicated build and a proper release cycle. Your usual development process will probably need to be changed.

It should not be about the correctness of the answers you give but about the way you answer them. A good interviewer should not penalise you too much for not knowing a specific question, provided you can give an overall good account of yourself - provided the specifics in question are not fundamentals!

Take the opportunity to branch out from the questions you are given, if you can. Show the depth of your knowledge, not on the question but on the details around it. For example, talking about "the VTable" for some of Brain in a Vat's questions would look good, even though the question doesn't strictly require it.

Avoid just saying "I dunno". Try give an answer - but do clarify when you're making an informed guess. Maybe don't roll with a total stab in the dark, that could turn out worse. Certainly explain your reasoning. For example, if you were asked Brain in a Vat's question #2: "What should you consider when making virtual functions calls from a constructor or destructor" (without being first asked question #1) you could talk about how objects are constructed, which you can give as your reasoning for your answer. That way, even if you are incorrect you get to talk about the stuff you do know, which looks better.
Some places will give you a programming exercise to do at home or on site. I remember one company giving a small framework and asking you to make a space invaders clone.

A good interviewer will give a non trivial problem or exercise and work through your solution to it. The solution itself doesn't have to be completely right, but the idea is to look at your reasons for certain decisions. Why are you using this particular pattern or algorithm? Have you considered scenario XYZ?

Steven Yau
[Blog] [Portfolio]


If you are interviewing at a graduate level then you won't be expected to know everything. Hopefully the other candidates will be near your level of competency. The company will probably be looking for a quick learner with a keen mind who will fit in well with the team. Full knowledge of all the details is something you'll get with time.

To some level graduates will need to be "broken down", to get rid of some bad habits you may have formed outside a team. You might find yourself introduced for the first time to a large, shared code base; revision control; formal bug tracking; complicated build and a proper release cycle. Your usual development process will probably need to be changed.

It should not be about the correctness of the answers you give but about the way you answer them. A good interviewer should not penalise you too much for not knowing a specific question, provided you can give an overall good account of yourself - provided the specifics in question are not fundamentals!

Take the opportunity to branch out from the questions you are given, if you can. Show the depth of your knowledge, not on the question but on the details around it. For example, talking about "the VTable" for some of Brain in a Vat's questions would look good, even though the question doesn't strictly require it.

Avoid just saying "I dunno". Try give an answer - but do clarify when you're making an informed guess. Maybe don't roll with a total stab in the dark, that could turn out worse. Certainly explain your reasoning. For example, if you were asked Brain in a Vat's question #2: "What should you consider when making virtual functions calls from a constructor or destructor" (without being first asked question #1) you could talk about how objects are constructed, which you can give as your reasoning for your answer. That way, even if you are incorrect you get to talk about the stuff you do know, which looks better.


This is great advice. I was told later on by one of the leads who gave me my test for my first game interview that I got the job because they were impressed at how I talked them through my thought processes, even for questions I didn't know 100%.

A company that knows what it's doing wants a smart person rather than a C++ language expert. A person with good critical thinking skills can learn any language put in front of him, but more importantly he is capable of tackling any problem put in front of him.

This topic is closed to new replies.

Advertisement