Interviewing Game Developers Is Hard

Interviewing game developers is hard.No question about it... It's really difficult to know who's good and who's 'not a good fit'. They may have worked on some amazing game that you completely love.. But you have no way to really know what they actually did on that project. Was their code amazing groundbreaking stuff? Did they break things constantly to the point where they were not allowed to commit?

In the US, we can't really ask their previous employer (or at least we won't get an answer if we do).

So what can you do? Most companies I've been to have terrible interviewing processes. They go through some canned, mostly irrelevant questions. Ask you about some algorithm you haven't looked at since college, maybe a couple really exciting and interesting riddle questions... *grunt

Then they'll talk about what you like and how you'll fit in. It's rare that anyone talks about the things we actually do day to day... Or how to do things cleanly and 'correct'. Which is why one interview I had a few years ago pleasantly surprised me. It was the kind of interview I hear people complain about often.

A take home test... But not the stupid 'go solve this algorithm question that's available on google as result #1' type.. It was to build a project. A simple racing game.. (using a car starter pack that handled the movement & physics already). All I had to do was take those working cars, and make them race.

I enjoyed this for a few reasons.

1. It wasn't boring!

So often the test interviews are to do boring, pointless tasks that you'd never do in a real project... Usually looking for a very specific answer. To see if you're as clever with this 1 specific useless problem as the person who wrote the stupid boring test.

2. It showed real world skills.

A test like this lets you show that you know more than some intro to algorithms class would teach. It shows if you know how to build a game... If you can take an idea and turn it into something. (you know, kinda like the job you're applying for)

But it also shows quality. I can open up a project like this, take a look at your code, and know almost instantly where you are skill wise. Is everything a big spaghetti mess? Are variables named a1, a2, a3, like we're still in the 90's and struggling for screen space/memory?

Maybe everything is in 1 giant file. Whatever the case is, I'll have a much better idea where you are than I could ever get with the standard canned questions and personality checks. Now I understand the push back..

"Why should I have to waste my time building this project for the interview?"

But I think it's like anything else in life. If you want something, you've gotta put in the effort. If you can't put in that effort, someone else will, and that person will get the job. Of course if the thought of completing the test project is overwhelming, the job probably isn't a good fit.

They're likely looking for someone a bit more experienced, who won't have any problem at all finishing it (and having a good time while doing it). And there's nothing wrong with that, we just have to realize it early. If the test says it should take 4h and you think in your head 'this would take me a week'... simply bow out and move on to the next job :)

But if you get a test like this and it seems interesting and doable... Go full force! Finish the project, then add a little extra flair of your own. Build it to your phone, polish it up, and show it off... turn it into your very short term side project and blow them away :)