TL;DR: Hiring a Unity developer goes wrong when you judge the demo reel and skip the questions about shipping. A good Unity hire for a real product can explain how they structure a project so it survives growth, how they get builds onto devices repeatably, how they handle the platform-specific parts (native plugins, headsets, app stores), and how they find and fix performance problems on the weakest device you support. Ask for something they shipped, not something they rendered, give a small paid trial on your actual codebase, and match the hire to your product type, because a mobile game, an AR app and an enterprise XR tool need different Unity people. I have been on the other side of this for more than five years, freelancing in Unity for clients in Australia and the US and then building AR at ARCortex, cross-platform SDKs at Geonode and clinical XR at Nystag, so this is the checklist I would want a client to use on me.
Most founders who hire a Unity developer are not Unity people themselves. That is normal, and it is exactly why the hiring process tends to over-weight the part that is easiest to see: a slick video of something running in the editor. The editor is the easy part. The hard part is everything between "it works on my machine" and "it works on ten thousand phones, a headset in a clinic, or a tablet on a fire ground."
Start with what kind of Unity product you are building
"Unity developer" covers several different jobs, and the first mistake is hiring the wrong one. Before you write a job post, decide which of these you actually are:
- A mobile game or interactive app. You need someone strong on UI, performance on mid-range Android phones, monetization SDKs and App Store and Play Console releases.
- An AR app. You need someone who has fought real tracking problems outdoors and indoors, knows the trade-offs between AR Foundation, ARKit, ARCore and Vuforia, and has tested on site rather than at a desk. I wrote up how I choose an AR SDK and why AR testing has to happen in the field.
- VR or XR on a standalone headset. You need someone who treats frame rate as a hard requirement, because a dropped frame in a headset is a comfort problem, not a cosmetic one. My notes on Unity performance on standalone VR headsets cover what that looks like.
- A non-game product built in Unity. Training tools, visualization, digital twins, sports-tech experiences. Here you need someone who thinks like an application engineer, with clean data flow and a backend that owns the truth. More on that in Unity for non-game apps.
My own work has crossed most of these. At ARCortex it was the ERIS XR platform for the California Fire Brigade and AR tools like AR Planes and AR Properties. At Nystag Healthcare XR it was clinical eye-tracking diagnostics on the Vive Focus 3. At RAQTS it was the Lumo interactive platform inside a larger sports-tech product. Those projects shared an engine and very little else. A candidate who is excellent at one is not automatically right for another, and a good one will tell you so.
What to look for in a portfolio
Shipped beats pretty
The single most useful question is "what did you ship, and where can I get it?" An App Store link, a Play Store listing, a client who can confirm the deployment, a product page. Shipping means they dealt with signing, store review, crash reports, devices they did not own and users who did things nobody expected. A beautiful scene that never left the editor tells you about taste, not about delivery.
When they show you something shipped, ask what broke after launch. Everyone who has shipped has an answer. Someone who says "nothing" either has not shipped much or was not the one getting the bug reports.
Ask them to walk the architecture, not the visuals
Ask them to explain how one of their projects is organized. You do not need to follow every detail. You are listening for whether there is a structure at all: where game or app state lives, how scenes load, how data comes in from a backend, how they avoid one giant manager script that everything depends on. A developer who can explain that clearly to a non-specialist is usually one who can keep a codebase sane for the next person, and that next person might be you, a year from now, inheriting the project.
The technical questions that separate senior from junior
These are the questions I would ask, and what a strong answer sounds like.
"How do you get a build onto a device?"
A junior answer is "I press Build in the editor." A senior answer involves a pipeline: builds made by a machine rather than a laptop, versioning that is automatic, signing handled in one known place, and artifacts that land somewhere testers can install them. At Geonode I implemented Unity and Windows CI/CD pipelines for exactly this reason, and I wrote up how I set up a Unity CI/CD pipeline. You do not need perfect automation on day one of a small project, but you need someone who knows why it matters.
"Tell me about a time you had to call native code."
Real products eventually need something Unity does not give you out of the box: a platform SDK, a background service, a device sensor, a payment flow. That means native plugins in Java or Kotlin for Android and Objective-C or Swift for iOS. On the Repocket SDK at Geonode the core networking had to run correctly across Windows, Android and iOS, which is about as deep into platform differences as Unity work gets. A candidate who has never touched this is fine for a simple app, but should not be the only developer on anything that integrates with hardware or third-party SDKs. My post on Unity native plugins for iOS and Android lists what tends to break.
"How do you find a performance problem?"
Listen for the Profiler, the Frame Debugger, testing on the slowest supported device, and a habit of measuring before optimizing. Red flags are vague answers like "I optimize the code" or "I reduce polygons" without any mention of how they knew where the time was going. On headsets and older phones, performance is not a polish phase at the end. It is a constraint you design for from the first week.
"Have you upgraded Unity on a live project?"
Upgrading the engine version under a shipped product is one of the most underrated skills in Unity work. Packages change, render pipelines change, plugins stop compiling, and store requirements eventually force your hand. Someone who has done it will talk about branches, testing on devices, and upgrading one step at a time. I covered the process in upgrading Unity on a live project.
Red flags I would watch for
- No source control habits. If they do not use Git (or Plastic) with sensible commits and an ignore file that keeps Library folders out, walk away. Unity projects without discipline here become impossible to hand over.
- Everything is a singleton. Some managers are fine. A project where every script reaches into every other script through globals is a project nobody else can safely change.
- Asset store as architecture. Using good assets is smart. Stacking ten of them as the foundation of your product, without understanding what each one does, is a maintenance bill you will pay later.
- No device testing story. "It runs in the editor" is not a status update. Ask which physical devices they test on.
- Estimates without questions. If they quote a price for an AR or XR feature without asking about lighting, target devices, tracking environment or backend, the estimate is a guess.
How to run a trial that tells you something
Interviews only go so far. The best signal I know, from both sides of the table, is a small paid trial on your real project. Not a toy test. Pick something bounded and genuinely useful: fix a known bug, add one small feature, or set up a build pipeline that produces an installable build. A week or less.
What you are evaluating is not only the result. Watch how they communicate when they get stuck, whether they ask questions before assuming, whether they leave the code cleaner than they found it, and whether the handover note at the end would let someone else continue. When I started freelancing in Unity, first on small projects and then for clients in Australia and the US, the clients I kept were the ones who saw how I worked on a real slice of their problem, not the ones who picked from a portfolio alone. I wrote more about that period in lessons from freelancing for US clients.
Pay for the trial. Unpaid "test projects" filter for people with time to spare, not people who are good.
Freelancer, agency or in-house?
- Freelancer works well for a defined product or feature, a prototype, or specialist work like AR tracking or headset performance. Make sure the code lives in your repository from day one.
- A small studio or agency makes sense when you need design, Unity, backend and mobile release handled together, and you want one accountable party.
- In-house is right once Unity is the core of your product and you will be iterating on it for years.
Whichever you choose, insist on owning the repository, the store accounts, the signing keys and the build pipeline. Those are the parts that make it possible to change developers later without starting over.
The short version
Hire for shipping, not for screenshots. Match the developer to your product type. Ask how they build, how they test on devices, how they handle native code and performance, and whether they have upgraded a live project. Then run a short paid trial on your actual codebase and judge the communication as much as the code.
I made the move from Unity game development into XR platforms and then AI engineering, a path I described in from Unity game dev to AI engineer, and the thing that carried across every step was the same: the engine was never the hard part. Getting real software onto real devices, reliably, was.
I build Unity, AR and XR products and lead engineering as a fractional CTO for teams that need them shipped properly, from first prototype to store release. If you are hiring for a Unity project and want a second opinion or a builder, more about my background here, or book a call.