Imagine this scenario: you found your dream game company, they have the perfect opening for you, the job spec is a great fit to your skills and experience, the project is cool and exciting. You decide to prepare an application, you brush up your resume and write a tailored cover letter explaining why you’re the best candidate for this role, and send it their way.
A few days later you get on an intro call, you go through your profile and learn more about the company. Everything seems to be going great. Finally, as the hiring manager explains the hiring process, you learn that the next step, before talking to the engineering team, is to complete a timed technical test.
You probably don’t need to imagine this, as every engineer working in the game industry, at some point in their career, had to endure a lengthy technical test as part of a recruitment process.
Tests are in my opinion an ineffective way to conduct tech recruitment. In this article I’d like to explain why they provide an unclear and biased picture of the candidate, the burden they put both on the applicant and your hiring team, and a better way to assess your candidates that is more fair and inclusive.
Technical tests come in multiple variations. Some companies will give you a problem, asking you to solve it using their preferred language and tools, and following a list of requirements before sending the source files back. Others will ask you to develop a small game from start to finish, based on a design spec they provide. Some studios will provide a starting project with a few bugs baked in, and request you to further develop it and bugfix.
In all of those cases, the end result is some pieces of code, with little context and without an understanding of the thought process of the candidate. This feels like a less than optimal way to assess their technical skills, easily leading to misunderstandings and confusion.
Writing code is not even the main thing you should expect from an engineer. Code is just the final
Read more on gamesindustry.biz