Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I just did the online tech test for Lionhead and found it a bit defeating. There were questions that required you to work out the answers to recursive algorithms that accepted arrays as arguments and made multiple calls each run through, thus splitting off into exponentially more versions. This all had to be done on paper or in your head.

There were also questions that asked you to evaluate the efficiency of theoretical algorithms and say what Big O notation you think would best describe their scaling, something that I have never been taught or learned.

There were 27 such questions. Is this usual? Is this the standard of entry level games programming? I mean, I've written 3D games, but I found this really hard.

EDIT - I have actually done another tech test for another company now which was considerably easier. I had to write various different linked list algorithms and write a routine in sudo code for how I would mathematically calculate a bot's sight given a world up vector and a forward vector.

share|improve this question
Is the content of this test available to the public? I'm curious even though I have no means of applying. – David Gouveia Jan 16 '12 at 15:03
The two things you mentioned sound like a standard CS Algorithm Analysis test questions to me. – KlashnikovKid Jan 16 '12 at 15:14
@KlashnikovKid Exactly what I was thinking. These are testing CS major knowledge straight out of an algorithms and data structures class. Seeing as how Lionhead focuses very strongly on console development where resource limitations are always considered, rigorous questions about efficiency seem about right. – Sean O'Hollaren Jan 17 '12 at 18:18
Most of the companies where I've worked have had similar written tests, which intentionally had more questions than someone could complete in the time available, and which were intentionally more difficult than we expected people to be able to answer. This was to give us extra information about how candidates behaved under pressure, and also to give us an idea of what areas people thought were their strengths (based upon which questions they chose to spend their time answering). When we tested them against current employees, we expected them to achieve around a 60% final score. – Trevor Powell Jan 18 '12 at 9:45
up vote 3 down vote accepted

A lot of games companies have tests that have questions as difficult as that. Not separate ones for intermediate / advanced levels. You will probably find that they would be expecting a low percentage correct for an entry level programmer, say 40% or something.

Was there a lot easier questions? And even with the harder ones did you attempt them and show how you worked it out, etc.? It is more for them to gauge what you do actually know and your aptitude when trying to attempt to answer them.

At least with an online test you have the advantage of being able to look up things you have forgotten, etc., which is probably another reason for them to make it more difficult.

Do you have a copy of it you could message me by any chance? I would be interested in seeing it.

share|improve this answer
Yes there were easier questions, but it was actually a very large multiple choice drop down so there was no way to show working. – SirYakalot Jan 16 '12 at 14:50
I think this is a really good point so i've marked it as correct - seems like studio's give the same test to many levels of programmer and expectations vary accordingly. – SirYakalot Jan 17 '12 at 10:44
Not just in games. I tend to ask the same kind of escalating questions (in person) as a way to understand many things: the applicant's understanding of programming, the language, ability to problem solve, reaction to the impossible, reactions to obvious stupidity. – DampeS8N Jan 17 '12 at 16:08

It is worth noting that there are no industry standards for either the test material or the evaluation thereof, so your mileage may (read: will) vary wildly from that described by the answers here (my own included).

That said, what you describe doesn't sound like an uncommon test structure to me (the number of questions is a bit higher than any test I've ever taken or administered, but that's about it). Both the topics you specifically called out -- complex recursion and Big-O notation -- are topics that are typical of a solid computer science education and can be extremely useful in game development. Their presence on a test is a good way to measure if you are familiar with them, or probe for potential areas of discussion in an in-person interview.

Remember that, as others have noted, a test for a job isn't necessarily like a test in school. Doing poorly may not immediately disqualify you for further interviews. Code tests are just another screening and evaluation metric to help see where you stand in terms of your technical ability and if that would be an appropriate fit for the available position or positions.

Above all, don't be discouraged if you feel you didn't do well. Look at is as an opportunity to grow and perhaps try again later. If you're eventually told that you didn't do well enough on the test, it's worth asking for clarification (sometimes you won't get it, but it can't really hurt to ask) so you know where specifically to focus your continuing education.

share|improve this answer
How do programmers handle these questions on complex recursion? How would you go about working it out? – SirYakalot Jan 16 '12 at 17:57
It kind of depends on the specific question. As a general rule I find my notepad of graph paper invaluable for sketching whatever diagrams or notes I'd need to maintain the model of a problem that has grown too big to fit comfortably entirely in my head. – Josh Petrie Jan 16 '12 at 17:59
In exams, I used to draw execution trees for this. Simply draw out all the different branches that the function launches, what input values they received and what they return once the recursion has hit the base case. This got pretty messy for functions which call more than two sub-branches, but it's the simplest and safest way to get it done imo. – TravisG Jan 16 '12 at 20:06
@AsherEinhorn also try and understand what the algorithm is actually doing instead of trying to simulate it. Your brain might be able to work it out without having to recurse. – Jonathan Dickinson Jan 17 '12 at 10:56
@Asher Read about the substitution method and master theorem for recursive analysis. – Sean O'Hollaren Jan 17 '12 at 18:23

This is almost standard in even the smaller software studios now. I haven't applied to any game studios but it's easy to assume they would be at the same level of difficulty if not more in the interview.

They want to know exactly what you said. If you've ever been taught that or not. If you didn't get a degree in computer science or have significant experience in game development, you may find it very hard to get a job at a studio that big, or even smaller ones.

These questions are geared for the entry level by the way. They need something to compare you against with all of the other applicants. If you don't know algorithm efficiency, they are assuming you are less qualified than the entry levels that do, as most CS grads know this stuff well. I use "you" in the general term to mean any applicant.

share|improve this answer
The on site interview is likely much harder as they will probably have you work out algorithms on the spot in front of a few developers. When you finish they will ask you to write it again, only more efficient. – brandon Jan 16 '12 at 14:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.