Hi folks! I'm going on a job interview in about a week from now. It's for a position as tools programmer at the swedish company Avalanche Studios. This is my very first interview for a games company. I have been told that I will write a "general gameprogrammers test" once there, and afterwards discuss it with their lead programmer. The test will take 1 hour. I feel that i'm quite a confident programmer, but this scares the jeepers out of me anyhow. Maybe because if I get there and just don't understand anything of the test I will feel so worthless afterwards. I don't have any university degree or industry experience. All I have is a 3 year gameprogrammer education and some example sourcecode in my trunk. I'm surprised they even noticed my application. Do anyone have any clues to what they would ask me to do on this test? Is it common practice to test possible employees before hiring?

Hi there. I work for a UK gamedev studio, it was the first place I applied when I entered the industry and I got the job so it ended up being the only technical test I sat. I would say that if you are going for a programmer position, then any decent gamedev house will do some form of test, whether it written or oral.

Basically, I would be prepared for anything. Make sure that your 3D maths is of a decent standard, matrix multiplication, vector - matrix maths, perhaps even some quaternion mathematics (although for an entry position I have never heard of quats being on tests).

You could perhaps be presented with a body of code and are asked to say what the problem is, or what it does, or maybe a half finished piece of code and you have to complete it. Maybe you are asked what are the performance problems of a functionally valid block of code.

I have heard from friends applying to other places of being asked a few programmer-tricks style questions. I.e. what is the best way to multiply by 2? (single left bitshift). What is the best way to test for an odd number? (bitwise AND with 1). things like that.

Converting decimal to hex and back again would be a good bet. Bitwise operations on hex numbers or their binary equivalents also possible. Expect some more high level questions as well... what is a memory manager? Why is it bad to put complex function definitions into a header?

I was asked questions about physics implementations ... why might a physically modelled stack of objects jitter? Or collapse prematurely? Why might a fast moving object pass right through another?

Perhaps questions pertaining to crunch time...what suggestions would you make to a team that are running out of memory, both on disk and RAM. Some scenarios as well perhaps...You have a game level that has many characters. When a new character type comes into view, the game stutters, why might this be? Can you think of ways to remove this performance problem?

I know I haven't narrowed things down for you, I'm afraid thats just not possible. Try and be prepared for as much as you can, a general test could cover a vast quantity of things. Good luck though! It's a great industry to be in when you find the right company :)

EDIT : Also brush up on your jargon :) Knowing what sprites are, what parallax mapping is, what texture mapping is and how to do it, what the differences are between a fixed-function render pipeline and a shader based model. The list could go on and on, do you know what an OBB is ?(oriented bounding box), or an AABB? (axis aligned bounding box). What is rasterisation? What are mipmaps? What is aliasing? etc.

Try not to worry too much about the test.

These things vary quite a bit from one studio to another, but a good studio will not treat the test as a pass/fail thing, they will simply use it to gauge your strong points and your weaknesses.

Make sure that if you can't answer something, that you don't immediately write off the interview as a failure. Just do your best, and then be prepared to talk though with the interviewer afterwards, and go through any parts that you had difficultly with. You may find that they only expect the most senior people with lots of previous experience to get most of it right anyway.

Typical things I've seen asked are...

*Basic C++ questions. Const correctness, Virtual destructors, Operator overloading etc.
*Implement simple functions to do things like string manipulation.
*Identify what a function with obfuscated variable names does.
*Questions about common game programming issues like memory management, leak detection, uninitialised variables etc.

One important point; don't be afraid to say that you don't understand something, or that a particular term doesn't make sense (perhaps you just know it under different name), and don't make claims that you can't back up. These are common sense things I know, but you'd be surprised at the number of people who when asked 'do you know how to implement such and such' will simply say Yes, as they are too embarrassed to admit they can't. This usually ends in tears, when the interviewer digs deeper on the subject.

To summarise : Be yourself. Be open and honest. Don't worry about getting everything correct.

Good luck!

At a company I was part owner in quite a while back we gave them a test involving linked lists and some other stuff. Actually I think it was a IRC client-server that we have them the basis for. What we looked at mostly wasn't so much as if they managed to do the test but more so they didn't do something completetly stupid and dangerus. Like not freeing up any memory at all. Strange use of memory. More or less obvious things if you have actually done some programming and not just done your university course. We wanted people with passion for programming. Who liked to fiddle with small projects during their sparetime.

What kind of tools are you going to make?

Thanks for the tips, guys! I will definitly have to brush up on some of the basics, so it's a good thing I have some time before the interview. I will probably have to look into algorithms and that stuff too. I always use STL, so I guess i'm a bit spoiled.

Xetick: I think it will be tools for content creation. I guess they will fill me in more when I meet them.

Don't sweat it. Unless you do extremely horrible on the test you probably won't be thrown out from it.

That short of a test is often just a paper + pencil test of 2-3 pages to show that you know what you are doing, and can implement basic concepts without the aid of a compiler, debugger, IDE's autocomplete, or any web sites.

Other places sometimes give you a computer to work on, but I prefer making people write it out, then reviewing it with them afterword.

For some of the harder programmer positions I've been on both ends of a multi-hour test. It can take under 90 minutes for an experienced person, about 120-180 for a pretty good college grad, and less-skilled or less-experienced people generally don't finish within a 3 hour time limit. These are nice because you can see a lot of insights to their abilities and the choices they make given a tough situation.

The other posters have included the things you should know and do. Don't lie or cheat (those are bad signs in an employee).

The one thing I would add about those tests is that if you don't know the details, write down whatever you DO know. I'd rather see that they understand the concept but not the details than to just get "I don't know".

The purose of this type of tests is not to see if you get everything right. It is often to probe your knowledge and dig down until you are uncomfortable. With only a few questions I can find out how deep a candidate's knowledge on a topic is by asking progressivly harder questions. Once I can see how much they know on the topic, I can judge if they are able to do the job.

The second thing, as important or even more important that programming ability, are your team skills and how well you are likely to get along in the office. Even if you score perfectly on the test, if you have no team skills or seem like you won't fit in, then I don't want you on the team.

For me, the point of interviews is twofold: 1) Can they do the job? 2) Will they fit in or will they be a disruption?

> It is often to probe your knowledge and dig down
> until you are uncomfortable.

Open-ended problems like "how would you measure the amount of water flowing in the Colorado river at any particular point" were a particular favorite at my place. It's the thought process that counts for those and it is expected you would try to seek as much information as possible before you start exploring a solution.

-cb

Although this article is written from the interviewers perspective, you will probably find it very useful reading.

Please try to get a hold of this test and post it here, I am sure many people here will be very interested in seeing what they're like.

Good luck!

Thanks for all your replies. And that article was good reading!

I have been given a remote test from Massive Entertainment (ground control series). If I pass it, they will call me for an interview. I'm not sure they would want me to spread their test here, but I can post a few questions.

Q: Name the 3 biggest problems you want to avoid when making an OO design and how you try to work around them.

Q: Describe 2 different methods for automatically generating the node graph that is used as a basis for A* to traverse. and their advantages and disadvantages.

Q: In an action oriented game you have a number of static objects in the world that all your bullets would have to collide with. You need to be able to tell which object it collided with though. If memory isn’t an issue what kind of data structure would you use for collision detection and why?

Q: You have a triangle defined by the 3D points P1, P2 and P3. How do you calculate the normal of this polygon ? (point traversal order is from 1 to 3)