How to hire a Unity developer: skills, tests and what to expect
Unity is one of the most widely used engines for mobile games, indie titles, AR and VR apps and interactive 3D tools. Because it is so popular, there are many Unity developers to choose from, and their experience varies a lot. This guide covers what to look for, how to test candidates fairly and how to bring a new developer into your project. If your project needs film-quality 3D on PC or console, compare this with our page on Unreal Engine developers.
Start with your platform and genre
Write down where the project will run and what kind of experience it is. A casual mobile game lives or dies on smooth performance on cheap phones, short sessions and well-placed ads. A VR training app needs steady frame rates and comfortable movement. A PC strategy game needs deep systems and save files that never break. The right developer has shipped something close to yours, so share this summary with every candidate.
Skills to check
- C#: readable classes, events and coroutines or async code, without huge scripts that do everything.
- Unity basics done well: prefabs, ScriptableObjects, scene management and sensible folder structure.
- Performance: using the Profiler, cutting allocations in frequently called code, batching and texture compression.
- Platform know-how: input, screen sizes, memory limits and store rules for each target.
- Teamwork: version control with Git or Plastic SCM, clear commit messages and smooth work with artists.
Questions that reveal real experience
- Tell me about a game or app you shipped. What broke in the last month before launch?
- Our game stutters on older Android phones. How do you find out why?
- When do you use a ScriptableObject instead of a MonoBehaviour?
- How would you structure a save system that survives updates to the game?
- How do you keep a designer from needing you for every small tuning change?
Strong candidates answer with specific tools, numbers they measured and trade-offs they made. Vague answers about “optimising everything” are a warning sign.
Use a short paid playable task
Instead of a long take-home project, give finalists a task of a few hours: for example a character that moves, collects items and shows a score, with a menu to restart. Ask for the project folder and a short note on what they would improve with more time. You learn far more from how the project is organised than from a polished video.
Junior, mid-level or senior
A junior can build features from clear tasks if a senior reviews their work. A mid-level developer can own a whole system, such as combat or the shop, from design notes to release. If the developer will be the only programmer on the project, or the project has already slowed down under messy code, choose a senior who has led a release before.
Engine plans and licence
Check which Unity version and plan your project needs before you start. Unity’s own pricing page explains the current plans; small teams can often start on Unity Personal, while larger companies need a paid plan. Your developer should keep the project on a supported version and plan upgrades between milestones, not in the week before a release.
Test on the devices your players own
The editor on a powerful laptop hides most problems. Keep a small set of real test devices that match your audience, such as an older Android phone, a recent iPhone and the headset you target, and ask the developer to check every important build on them. Agree on a target frame rate and a memory budget early, and treat a drop below them as a bug like any other.
How the developer works with artists and designers
Unity projects move fastest when artists can import and test their own work. Ask how the candidate sets up import rules, naming conventions and simple tools so that a new model or animation appears in the game without a programmer touching it. A developer who makes the rest of the team faster is worth more than one who only writes code quickly.
Working across time zones
Game work involves a lot of quick feedback, so agree on a daily overlap window for playtests and reviews. Many teams record short videos of each new build so feedback can flow even when people are offline. A shared bug board with clear steps to reproduce saves hours of back and forth.
The first months
In the first week, have the developer get the project building, read the code and fix one small bug. In the first month, give them ownership of one system with clear goals. By the third month, a good hire is suggesting improvements to tools and workflow, reviewing other people’s changes and helping plan the next update.
Common mistakes
- Hiring for a portfolio of tech demos when you need someone who has finished and released a product.
- Testing on high-end devices only and finding performance problems after launch.
- Leaving engine upgrades until a deadline is close.
- Skipping version control because the team is small.
Planning a wider remote engineering team? Read our remote software engineering hiring playbook.