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 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.

Quote: Original post by VladR
It`s 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, doesn`t mean he`s 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 you`re 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 there`s 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.

Don`t 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 isn`t that bad as it seems ;-) And that`s 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.