How I Hire

I do not have a degree. I learned to program by making mods for Modern Warfare 2 as a teenager, under an alias, which means my earliest work is not something I can put in a portfolio.

For most of my career I was the one applying. Now I run GhostJam and I am the one reading applications. Last year, a few weeks before we shipped Backseat Drivers, I hired an engineer to help us firefight.

There are a lot of good people looking for work right now, and I have written about why that is. So this is how I hire: the process, what I look at, and what I do not.

Most of it applies to any role. One section is just for programmers, because that is the job I know from the inside. We are also a small studio, so this is how I hire for a team our size, not how a company with a recruiting department does it.

The process

Most of my hiring starts with word of mouth.

I value people’s time, so I refuse to do long, drawn-out interview processes. There is no separate technical interview, no take-home code assignment, and no second or third round. I have been on the receiving end of them, and I am not a fan.

I review the application, then go over it with the team so they can point out things I missed. If I want to talk, it is one video call, up to an hour. Cameras are not required, but I prefer them, and ours will be on. We go through your portfolio, I get to know you, I ask technical questions, and the call ends. You get an answer within a week. It is not that hard.

There is always a second person from the team on the call. Sometimes that is to help vet the things I am not as familiar with, like art. Sometimes it is so someone you would work with day to day gets a say.

What I ignore

Degrees. I do not have one, so it would be strange for me to ask you for one. A degree tells me you can finish a four-year program. It does not tell me you can finish a game.
Studio names. A big name on a résumé tells me where you sat. It does not tell me what you did there. Credits list everyone the same. I would rather hear what you personally made.
Walls of text. Show me the work instead of describing it.

What I look for

Finished things. Not perfect things. Show me something that exists: a released game, a mod, a jam game, a tool, a finished model or level. Small and finished beats large and abandoned.
Experience, for the roles that need it. I do not ignore years of experience. It depends on the role. The engineer I hired to firefight had a decade of it, and that was the point. We were weeks from launch and needed someone to come in and put out fires, so having done it before was what I was hiring for. For other roles the number matters less than what you did with the time.
Whether you can explain your own work. Why you made it that way, what you tried first, and what you would change now. If you cannot walk me through it, I start to wonder how much of it was yours.
How you communicate. Always respond. Flag a blocker when you hit it, not three days later. Ask the question when something is unclear. I do not need you to be chatty. Some people do their best work heads down, and that is fine. I just need to know the message landed.
When you ask for help. Try to solve it yourself first. Give it a few hours, and if you are still stuck, ask. I do not want someone who asks the second something gets hard. I did that for a long time, and it slowed down how fast I learned. I also do not want someone who stays stuck for a week and says nothing.

Red flags

You cannot say “I do not know.” Nobody knows everything. If you have an answer for everything, some of the answers are made up.
Everything was someone else’s fault. Every past team was bad, every lead was clueless, every project was a mess. Some of that may be true. Not all of it is.
A lot of opinions and nothing shipped. Strong views about the right way to do the work, and very little to show for it. I was this person.
Silence. If you go quiet during the hiring process, I assume you will go quiet on the job.

For programmers

This is the part I can judge directly, because it is still my job too.

Pragmatism over purity. For years I cared more about code being perfect than about it being done, and I did not get much done. I once wrote a whole post about why I hate Blueprint. At GhostJam we now build almost everything in Blueprint first, because we can iterate quickly, and move things to C++ when maintainability or performance calls for it. I want people who pick the tool that gets the thing done.
Whether you can debug. Tell me about a bug. A specific one. What you thought it was, what it actually was, and how you found out. If you tracked it down yourself, you will remember every wrong guess along the way. If you did not, you will not have much to say.
How you use AI. I use it for a first pass or a second opinion, and it is fine if you do too. What matters is whether you can explain what the code does and why. This matters most in Unreal. Something can work in a test level and still have terrible memory usage, frame-time spikes, or network traffic it does not need. If it breaks after launch, somebody has to debug it.

If you are applying

Lead with the thing you finished, and say which part of it was yours.
If you have a portfolio, put videos in it, or at the very least GIFs. I want to see what you have made, even if you do not think it is very good.
Say what you do not know. Then say how you would find out.
Reply to the message. Even if it is just “got it.”
If you are a programmer, have one bug story ready.
Apply anyway. I have talked myself out of applying for jobs I could have done.

Garry Newman covers getting hired in his post on getting into the industry, and it is worth reading. His test is shorter than mine: will you make his life harder or easier? He also says to apply directly and tell the studio why you want that job in particular. Both are good advice.

I got into this industry without a degree. Somebody had to look at what I could do instead of what was on paper. I try to do the same.

until next time