How to get hired as a game developer in 2026-27

What "game developer" means in a posting, and the disciplines hiding behind the word

The job title is ambiguous and the ambiguity costs people interviews. In practice a posting headed Game Developer means one of three things. Most often it means a programmer on a game team, and the responsibilities name a language, an engine and a subsystem. At a small studio or on a user-generated-content platform it means a generalist who writes code, builds content and does some design. In non-games companies hiring for training simulations, visualisation or serious games it sometimes means anyone on a game-shaped project, including designers and technical artists. Read the responsibilities and ignore the title. The fastest tell: a posting asking for C++ and a named engine subsystem means programmer, and a posting asking for systems design, balance and documentation means designer.

If it is a programming role, work out which discipline before you apply, because each one has a different portfolio, a different interview and a different market. Pick a lane for the application, not for life. The most common silent rejection is sending a generalist version of yourself to a specialist posting. A resume that says "gameplay programmer: traversal, melee, animation integration" with a portfolio that proves it beats a resume listing nine engines and twelve languages, because a lead is filling a specific hole on a specific team and has to believe you can fill it in week one.

Technical designers and technical artists sit alongside the programming disciplines and are hired on a reel plus tool demonstrations rather than on a code test: Blueprints a designer can tune, shader graphs, Houdini digital assets, rigging and animation tooling. If your instinct is to make the thing look and feel right and then build the tool that lets someone else do it faster, that is the lane, and it is a real career rather than a stepping stone.

The programming disciplines, and what each interview is actually looking for:

• Gameplay programmer: character controllers, combat, abilities, input handling, animation integration, state machines. In Unreal that is the Gameplay Ability System, Enhanced Input, animation blueprints and motion matching; in Unity it is the Input System, the Animator and an entity-based approach for crowds. The interview tests feel: frames, windows, timings, and whether you can tell a designer why a request will not fit the time available.
• Engine or systems programmer: memory, threading, the asset pipeline, serialisation, streaming, the platform layer. C++ and nothing else. Hardest to fake, hardest to enter without a degree or a very specific portfolio, and least affected by market swings, because every project needs it and few candidates can do it.
• Graphics or rendering programmer: HLSL, the render graph, lighting, post-processing, GPU performance, and how the same shader behaves on a PlayStation 5, a Series S, a Switch 2 and a mid-range Android phone. The portfolio is unambiguous: a renderer you wrote, plus frame captures.
• Tools and pipeline programmer: editor tooling, asset import automation, Python and C# that content creators use daily, and keeping the build system alive. The most underrated route in. Every studio needs it, far fewer candidates aim for it, and your work is visible to the whole team within a week of starting.
• Network or online programmer: replication, client-side prediction, rollback, dedicated servers, matchmaking, backend services. This is where the steadiest demand sits, because live-service titles are the ones still earning.
• Game AI programmer: navigation, behaviour trees, utility systems, goal-oriented planning, perception, crowds. A completely separate skill set from machine learning and still hired as such.
• UI programmer: UMG and Slate, or Unity's UI Toolkit, carrying localisation-aware layout, controller navigation and accessibility, which is now a platform requirement rather than a nice-to-have.
• Build and release engineer: the build farm, continuous integration on a project measured in hundreds of gigabytes, cook and package times, automated test runs on development kits.

The 2026-27 market in plain terms, and where the jobs actually are

Be clear-eyed about the last few years. Across 2023, 2024 and 2025 the games industry shed staff at a scale it had not seen before: whole studios closed, projects were cancelled after years of work, publishers consolidated after acquisitions, and several large platform holders cut deeply. The only running public counts are trackers maintained by developers themselves, and they are honest about undercounting, because many cuts are never announced. The shape matters more than any number: many thousands of people with shipped credits entered the applicant pool at once, and the pool has not cleared.

The consequence for a job seeker is specific and it is the most important fact in this guide. A junior opening in 2026 is not a competition between juniors. It is a competition between you and someone who was a mid-level gameplay programmer on a shipped console title eighteen months ago and will take the junior salary to get back in. That is why the entry bar moved from showing promise to showing completion. A tutorial portfolio was enough in 2019. It is not read in 2026.

It also means something reassuring, and you should internalise it before your first screen: being laid off carries essentially no stigma in games now. Almost everyone interviewing you has either been laid off or has had to do the laying off. A gap, a cancelled project, a run of short contracts: one plain line each, no apology, no account of whose fault it was. The developers who struggle in interviews are not the ones with gaps, they are the ones who sound ashamed of them.

Geography still decides a lot, because studio location follows tax credits and labour cost rather than talent. Canada (Quebec, Ontario and British Columbia), the United Kingdom, Poland, the Nordics, France, Germany, Japan and, for co-development, parts of South East Asia, India and China are the clusters. Government support for games production exists in several of these and is amended periodically, so check the current scheme rather than trusting a figure you read somewhere. The practical implication: if you cannot relocate and cannot reach a cluster, you are competing for the smaller remote-friendly slice, which is mostly mobile, web, tools and contract work.

Fully remote games hiring narrowed from its peak and several large publishers tightened office expectations, so do not infer the arrangement from a posting's tags. Ask in the recruiter screen how many days a week the team is actually in the office, because posting language and daily practice diverge more in this industry than in most.

Where the work actually is, in rough order of volume and stability:

• Live-service and mobile. These products already have revenue and need content pipelines, seasonal updates, server work, performance work across a huge device matrix, and the engineering around monetisation and analytics.
• Co-development and outsourcing studios, which now carry a large share of real production work on AAA titles. You work on someone else's game, under a non-disclosure agreement, often on a fixed-term contract, for less than the publisher pays its own staff. The credit is sometimes individual and sometimes a studio-level thank you. The engine experience is entirely real, and this is the most realistic first job for a great many people.
• Tools, build, release and platform engineering. Never glamorous, always needed, far less competition than gameplay.
• User-generated-content platforms. Roblox development in Luau and Fortnite creative work in Verse are paid work for a real and growing number of people. Be clear about the financial shape: this is usually revenue share rather than salary, which is a different risk profile, and a hit is not a career plan. It is still a route in, and a Roblox experience with sustained concurrent players is a credit a lead will take seriously, because it proves you shipped something and then operated it live.
• Realtime 3D outside games, badly underused by people leaving the industry: automotive in-car interfaces, virtual production for film and television, architecture and construction visualisation, defence and medical simulation, industrial digital twins, location-based entertainment, social casino and gambling. All of them hire Unity and Unreal engineers, several pay better than games, most will read a games portfolio directly, and many are less exposed to the cancellation cycle. A significant number of developers moved into these during the contraction and some moved back afterwards with skills that had grown rather than stalled. If your runway is short, that is the pragmatic move, and it does not close the door on games.

What gates the job: no licence, a portfolio, and a credit

Nothing gates entry to game development the way an apprenticeship gates an electrician or a board exam gates a nurse. There is no licence, no registration, no mandatory training hours and no professional body whose approval anyone checks. That is genuinely good news, and it is also why the market is crowded: the only filter is evidence, so you have to manufacture evidence.

Before listing what works, here is what people buy that does not. Generic programming bootcamps that end in a tutorial-shaped capstone produce portfolios that look identical to two hundred others and are recognised instantly. Paid course certificates carry no weight with a lead. Engine vendor certifications are close to worthless for games hiring, though they occasionally satisfy a procurement or HR checklist in simulation and training work. Paid portfolio review services vary wildly and none of them substitutes for shipping something. The money is better spent on the hardware and the time to finish one real project.

On degrees, the honest position is that it depends on the discipline. For engine, graphics, physics and network programming, a computer science or mathematics degree is the common route and the usual way candidates acquire the linear algebra, memory and numerical fundamentals those interviews reach for. Self-taught people do get these jobs, and they get them by covering the same ground visibly: a renderer, a physics solver, a netcode prototype, with the mathematics shown. For gameplay, tools, UI, mobile, user-generated-content and indie work, nobody checks. A degree also smooths visa paperwork in several countries, which matters if relocation is part of your plan.

Specialist games programmes with real industry placement records exist, and what gets graduates hired out of them is the shipped team project and the internship, not the award. The internship is the single most effective structural route into the industry for a student, and it is also what the contraction cut hardest, so apply to more of them than feels reasonable and apply early.

On timelines, refuse to be flattered. Starting from zero with no adjacent programming experience, twelve to twenty four months of consistent project work is the realistic distance to a first callback in this market, and the first job may be in quality assurance, co-development, mobile or tooling rather than the gameplay seat you pictured. Starting as a working software engineer in another industry, six to twelve months of focused engine work can produce a credible portfolio, and you should expect a pay cut on entry that may take a few years to recover. Quality assurance remains a genuine internal route to a programming seat and people still make the move, but it is a thinner ladder than it was: it is the most outsourced function in the industry and the most exposed to test automation, so going in with a plan and a visible side project matters more than it used to.

What does gate the job, in rough order of weight:

• Finished playable work: one thing other people have played, that still runs, with a clear statement of which parts you wrote.
• A credit, meaning a verifiable association with something released. A credited role on a studio title is strongest. A released personal or team game with a store page is next. A mod with real download numbers for a game with an active modding community is stronger than most people realise, because it proves you worked inside someone else's codebase under someone else's conventions, which is exactly the job. A Roblox or Fortnite creative experience with real players counts. A game jam entry is not a credit, but it is proof you finish, and a jam game you then polished for two weeks and published is close to one.
• Depth in one engine rather than surface in three. A lead needs to believe you can be useful in their engine in week one.
• Being readable: code someone can open and understand, and a project breakdown that says plainly what problem you solved and how you measured it.
• Being reachable at all. Games hiring is heavily referral-driven and the industry is small. Applications that arrive through a person get opened; applications that arrive through a portal often do not.
• Right to work. Studios in cluster cities do sponsor visas, but sponsorship concentrates at mid and senior level and is rare for juniors. Ask directly rather than inferring it from a posting.
• For defence, government and some medical simulation work only, a security clearance, which an employer with a contract sponsors and which you cannot obtain on your own.

The portfolio that gets a callback, and the breakdown that closes it

Design your portfolio around what actually happens when someone opens it. A discipline lead in production has a shortlist of twenty applications, an hour, and no intention of installing anything. They watch the top of your video, read one line about what you owned, maybe open one source file, and decide. Everything you want them to know has to survive ninety seconds of attention. The most common portfolio failure is not weak work, it is good work buried behind a four gigabyte download and a wall of text.

The structure that works, per project: the title, the platform and engine, your discipline, the team size, roughly how long it took, and one sentence on what you personally owned. Then a video of sixty to ninety seconds with the most interesting thing in the first ten seconds and no logo animation. Then a playable build, ideally in a browser or under a gigabyte, tested on a clean machine. Then a direct link to the specific code, not the repository root. Then a short technical breakdown: the problem, the approach, the thing that went wrong, and a measurement.

One practical note on builds. Unity and Godot export to the web, so an itch.io page with a playable browser build removes every obstacle between a lead and your work. Unreal does not export to the web, so an Unreal portfolio needs a clean Windows build plus a video that carries the project on its own, and the video then matters more than it does for anyone else.

The measurement is what almost nobody does, and it is the loudest professional signal available to you. Not "optimised the crowd system" but "the crowd update went from 11 ms to 3.2 ms per frame at 400 agents after moving to a jobified update and a spatial hash, measured in the Unity Profiler on a 2019 laptop". Not "improved the UI" but "UI draw calls dropped from 180 to 24 by batching to a single atlas". Not "reduced load times" but "cold load fell from 19 seconds to 6 by moving the asset load off the main thread and deferring audio bank loading, timed over ten runs". Two sentences in that form tell a lead more about your seniority than the rest of the page combined. The numbers above are the shape to copy, not figures to quote: yours have to come from your own captures.

What to build depends on the lane. For gameplay, do not build a platformer; build a traversal and combat system with the feel work made visible. Input buffering with the window stated in frames, coyote time, a different gravity curve past the jump apex, hit-stop on impact, animation cancel windows, and a debug overlay that shows the current state and every live timer. Record the overlay running. Put the tuning values in a data table a designer could edit without you. That one project demonstrates the actual craft of the discipline, which is making a fixed set of milliseconds feel good.

For network programming, build a small arena shooter or a physics game with server authority, client-side prediction and reconciliation, and lag compensation, then record it with artificial latency and packet loss injected and shown on screen. Almost nobody in the junior pool does this. It is the highest-leverage portfolio piece available right now, because live-service is where the hiring is and because the skill is genuinely hard to bluff. For graphics, write a renderer: a clustered forward or deferred pipeline with shadow maps and a post-processing stack, or one specific effect with RenderDoc captures and before and after GPU timings. Include the thing that was wrong and how you found it. For engine and systems, build an allocator, a job system, a serialisation format or an asset hot-reload path, with a benchmark harness and numbers. For game AI, build a utility or planning agent with a visualiser that shows the scores and the chosen action, and write up one behaviour that looked stupid and why. For tools, build an editor tool and state the time it saves; get someone on a real team to use it and quote them. For mobile, ship something small to a store and talk about memory ceilings, thermal throttling and crash-free session rate.

Two gaps are worth closing deliberately because self-taught candidates almost always have them. The first is version control for games: most studios run Perforce, not Git, and a candidate who has never checked out a locked binary asset or resolved a workspace is visibly new. Set up a small depot and use it on one project. The second is build hygiene: a packaged build that launches on a machine that has never had the engine installed, which is a different thing from a build that runs in the editor.

Cut ruthlessly. Engine tutorial clones using the tutorial's own art get recognised in seconds. Five half-finished prototypes read worse than one finished small thing, because the scarce skill in this industry is finishing. A project assembled largely from asset store packages and presented as your own work is the fastest way to lose a lead's trust. Anything whose playable build does not launch is worse than including no build at all. And a long list of technologies with no project attached is read as padding.

Label what you did not write. Asset packs, tutorial-derived sections, code adapted from a talk or a blog post, anything generated by an assistant: say so, in one line, next to the thing. "Which parts of this did you write?" is now a standard interview question precisely because generated code is cheap, and the candidate who volunteers the answer before being asked gains far more than they lose. The candidate who is caught out by it loses the interview and the referral.

Finally, the non-disclosure problem, which bites everyone with professional experience. Much of your best work may be unshowable, either because it is unannounced or because the project was cancelled and the publisher never acknowledged it. Two responses. First, keep one personal piece you are always allowed to show, however small, and keep it current. Second, learn the permissible description of your professional work and use it without hesitation: "unannounced third-person action title, 2024 to 2026, gameplay programmer, owned the mantling and cover systems on a team of sixty" is acceptable almost everywhere and tells an experienced lead a great deal. Cancelled projects count on a resume and in an interview. Everyone in the room has one.

How the hiring process actually runs, stage by stage

Who screens you depends on studio size. At a large publisher: a recruiter or talent partner first, then a discipline lead, then two or three members of the team, then a studio-level lead, technical director or producer. At a studio of thirty people the first human reading your application is often the technical director or a founder, which means a specific, short cover note matters far more than it does at scale. At a co-development studio the process is usually faster and more test-driven, because they are staffing a contract that has a start date.

Where applications come from matters more than how many you send. Referral and community contact first: former colleagues, people you met in a game jam, maintainers of a project you contributed to. Then studio careers pages directly. Then games-specific boards, several of which are well run and widely used, including Work With Indies, Hitmarker and GameJobs.co, plus the games jobs resource set Amir Satvat maintains publicly, which is the most useful single collection to come out of the layoffs. General technology boards are the weakest channel for games roles. If you are starting cold with no network, the fastest way to build one is not networking events, it is making something in public: a jam (Global Game Jam, Ludum Dare, the GMTK jam), a plugin, an open-source contribution to an engine or a tool, a devlog with real technical content.

Stage one is the recruiter screen, twenty to thirty minutes. It checks a short list of things: where you are and whether you can legally work there, your salary expectation, which discipline you actually are, your notice period, and whether you can describe your own work plainly to a non-engineer. Have a range ready. Refusing to give any number in games usually just slows the process down, and where pay transparency rules apply you can anchor it on posted bands for the same title and level. Use your turn to ask three things: is this contract or permanent, what stage is the project at, and what is the office expectation in practice.

Stage two is the test, and it comes in three shapes. You are entitled to ask which before you agree. A timeboxed take-home of four to eight hours with a written spec, often "prototype this mechanic in Unreal or Unity": scope it down, finish it, and include a README saying what you cut and why, because that README is where most of the points are. A live coding or pairing session, which has become more common precisely because unsupervised take-homes stopped being informative once generated code became free: practise narrating your thinking while you type, because silence reads as not knowing. Or the long unpaid test of one to two weeks, which some studios still send. It is entirely reasonable to ask whether it is paid, to ask for a timebox, and to ask what they will do with the result. Declining an unpaid two-week test is a legitimate decision, and you should weigh it against your own runway rather than against guilt.

Stage three is the technical interview with a discipline lead, sixty to ninety minutes. Games interviews lean less on abstract algorithm puzzles than general software interviews and far more on three things: debugging code you did not write, reasoning about where a frame's time goes, and knowing the engine you claim to know. Expect a shared screen with real code on it, a callstack, or a profiler capture. Some larger publishers and platform teams do also run one conventional data structures round, so do not arrive unable to write a hash map or reason about complexity. The next section covers the content in detail.

Stage four is the portfolio deep dive, and candidates routinely under-prepare it. Your own code goes on screen and you talk through it. Reread it the night before. Know why every non-obvious decision was made. Have three things ready that you would change now and why, because "I would not change anything" is read as not having grown. If part of it is weak, say so first and say what you learned; leads respect that far more than a defence of code you no longer believe in.

Stage five is the cross-discipline conversation, usually with a designer, an artist or a producer. They are testing one thing: whether you can hear "it does not feel right" without becoming defensive and turn it into a technical question. Have a real story about changing something because a designer could not articulate why it felt wrong, and what you did to find out. Artists will quietly check whether you understand that your optimisation suggestion costs them two days of rework.

Stage six, for designers and increasingly for gameplay programmers, is play and critique: play our game and come back with notes. Do it properly. Play enough to have earned an opinion, be specific and mechanical rather than evaluative, pick two or three things rather than twenty, and for each one name what you would try and how you would know whether it worked. A list of what is bad is a failed exercise. A note that says "the dodge feels unreliable in the second phase, I suspect the cancel window closes before the animation reads as finished, I would instrument the window and test a four frame extension against a fixed encounter" is a hire signal.

On timing and silence: games loops run slower than general software because the people interviewing you are in production. Three to eight weeks from first contact to offer is normal, and a milestone landing mid-process can add two weeks of silence that means nothing about you. Follow up once a week, briefly. On references: the industry is small enough that back-channel checks are routine and often informal, which is to say a lead will text someone who worked with you in 2022 rather than calling the referee you listed. This cuts both ways, and it is the strongest practical argument for leaving every job well, finishing your handover, and not burning a bridge in public.

The resume and the credits list: what gets read, what gets ignored

A discipline lead reads a games resume in a fixed order: shipped titles, engine and language, your discipline and what you owned, then the portfolio link, then everything else if the first four earned it. Lay the page out in that order and you have already outperformed most of the pile.

Write each credit in a form that answers the questions a lead has: title, platforms, year, your discipline, the engine and language, the team size, and the specific systems you owned. Here is the shape, with an invented title standing in for a real one: "Harbour Line (PS5, Xbox Series, PC, 2025). Gameplay programmer, Unreal Engine 5 and C++, team of 60. Owned traversal, mantling and the melee hit-reaction system." Platforms matter because shipping on console means you survived platform certification, which is a fact about you that no personal project can establish. If the project is unannounced or cancelled, keep the same shape and drop the name: "unannounced first-person co-op title (cancelled 2025). Network programmer, UE5 and C++, team of 40. Owned replication for inventory and the dedicated server session flow."

Quantify in the units the job uses: milliseconds per frame, megabytes of memory, draw calls, load time in seconds, build or cook time, crash-free session rate, concurrent players supported, agents simulated, automated test suite runtime. Avoid percentages with no baseline, which read as decoration. "Cut the animation update from 4.1 ms to 1.3 ms at sixty characters" is worth more than "improved performance by 70%", and it is also harder to fake, which is exactly why it lands.

What gets ignored, and in some cases actively hurts: "passionate gamer since the age of four", a list of your favourite games, skill proficiency bars and percentage ratings, soft-skill adjectives with nothing attached, engine vendor certificates, tutorial projects listed as projects, an objective statement, a photograph in most markets, your grade point average once you have a first job, and an exhaustive list of courses taken. Every line that is not evidence pushes a line that is evidence further down the page.

Keep it to one page until you have roughly ten years in, then two. Senior developers with ten credits still fit on two pages, because by then the credits do the work and the descriptions get shorter. Put the portfolio link in the header as a short readable URL, and check that it loads on a phone, because a surprising amount of first-pass reading happens on one.

On applicant tracking systems: large publishers run Greenhouse or Workday, and a recruiter searches keywords before a lead sees anything. Write for the lead but include the literal words from the posting: the engine name in both forms ("Unreal Engine 5" and "UE5"), the language, the subsystem, the platform. Once each, in a sentence that means something. Do not keyword-stuff a skills block; it survives the filter and then fails the human.

The cover note is three short paragraphs and it is worth twenty minutes. Which posting you are applying for and which discipline you are. One specific technical observation about their actual game, which requires playing it: a system you noticed, a problem you suspect they have, a decision you would have made differently and why. Then the one thing in your portfolio closest to the work in the posting, with a direct link to it. No passion claims. Generated cover letters are now so common and so uniform that one genuinely specific sentence about their game is a real differentiator, and it is the cheapest advantage available to you.

On gaps and contract stacking: list contract work by project with the studio and the title, and label it as contract. A run of three-month and six-month contracts is normal now and reads as experience rather than instability once it is labelled. A gap gets one line: "2025: studio closure, took six months to ship a personal project and learn Unreal's replication model." Then move on. Do not explain, do not apologise, do not blame a former employer in writing.

What the interview really tests

Strip away the format and four things are being assessed: can you debug something you did not write, do you know where the frame time goes, can you defend and criticise your own code, and will you finish. Everything in a games technical interview is a proxy for one of those.

For C++ roles, the fundamentals that actually get asked: virtual dispatch and what it costs, object layout with padding and alignment, cache lines and why an array of structures versus a structure of arrays changes a hot loop, move semantics and where a copy you did not intend happens, ownership and RAII, which smart pointer and why, const correctness, undefined behaviour you have personally hit and how you found it, custom allocators and why a game would want one, and why exceptions and runtime type information are disabled in some console codebases. Then the engine-specific layer, which separates people who have used Unreal from people who have watched Unreal tutorials: what the reflection macros actually do, UObject lifetime and garbage collection, why your pointer is null after a level transition, the difference between a server function, a client function and a multicast, and when a replicated property is the wrong tool.

For Unity and C# roles: value versus reference types and where allocation happens, boxing in places you did not expect it, avoiding per-frame allocation and what a garbage collection spike looks like in a profiler capture, the difference between Update, FixedUpdate and LateUpdate and which one physics and input belong in, coroutines versus the job system, what Burst will refuse to compile and why, Addressables and memory ownership, and why a design with one MonoBehaviour per entity falls over at ten thousand entities and what you do instead.

The mathematics that genuinely comes up, and the form it comes in. A dot product used for a facing or field-of-view test. A cross product used to decide whether a target is to the left or the right. Basis vectors and moving between world, local and screen space without guessing. Quaternions, why Euler angles gimbal lock and interpolate badly, and when spherical interpolation matters. Ray against plane and ray against sphere. A simple separating-axis test. And why a fixed timestep matters for physics determinism, which leads directly into the classic question about why the jump height changes when the frame rate does.

Frame budget literacy is tested relentlessly and is easy to prepare. Know without pausing that 60 frames per second is 16.67 ms, 30 is 33.3 ms, 120 is 8.33 ms, and a 90 Hz headset is 11.1 ms with a hard latency requirement on top. Be able to split a budget across simulation, animation, the render thread and the GPU, and say what you would cut first and what you would never cut. The question usually arrives as a scenario: the game drops to 24 frames per second when the player enters the market square, what do you do. The correct answer starts with measuring and names the tool: Unreal Insights, the Unity Profiler and Memory Profiler, RenderDoc or PIX for a GPU capture, a sampling profiler such as Superluminal or Tracy for the CPU. Establish whether you are CPU bound, GPU bound or stalled on input and output before proposing anything. A candidate who begins optimising before measuring fails that question no matter how good the optimisation is.

The debugging exercise is often the most revealing stage. A callstack with a null or a corrupted object. A bug that reproduces one time in fifty. A crash that only happens in a packaged console build. They are not testing whether you know the answer, they are watching your process: narrow the surface, make it deterministic, bisect the change history, read the actual memory rather than guessing at it, and state your assumptions out loud so you can notice which one is wrong. Say what you would check and why, in order, and say when you would stop and ask a colleague.

If the role touches multiplayer, prepare the netcode conversation properly: who is authoritative, what you predict and what you must never predict, how you reconcile a mispredicted state without the player noticing, what you do about a client you cannot trust, and why hiding latency is as much a design problem as an engineering one. Candidates who can discuss this concretely are scarce relative to demand.

The behavioural questions in games are not generic and should not be answered generically. The time you cut a feature you cared about. The time certification sent you back and what you changed. The time you disagreed with a designer and turned out to be wrong. What you actually did in the last week before a milestone. How you handled a project being cancelled. Every one of these probes the same thing: whether you have been near a ship date and behaved well under it.

Use your own questions to screen the studio, because in this market that matters. What stage is the project at and what is the next milestone. Is this role funded for the project or for the studio. What happened to the last person in it. How many hours did the team work in the last crunch period and what changed afterwards. How many of the current team shipped the previous title. How heavily modified is the engine, and who maintains the modifications. Who has the authority to cut scope. The answers tell you more about your next two years than the salary does.

Pay, contracts, unions, and the offer questions that protect you

Do not trust a salary band quoted without a source, including one quoted confidently in a forum. In the United States most game programmers are counted under BLS OES code 15-1252, Software Developers, which lumps games in with far better paid enterprise and financial software, so the published median overstates junior games pay and understates senior engine and graphics pay in expensive metros. Use it for shape, not for a number.

The sources that actually help. Postings from jurisdictions with pay transparency requirements, read in volume for the same title and seniority: California, Colorado, Washington, New York and Illinois all push bands into postings, and a sample of twenty postings for the same role tells you more than any survey. The GDC State of the Game Industry survey, published annually in the run-up to the conference, for industry-wide direction. The IGDA Developer Satisfaction Survey for conditions as well as pay. Skillsearch's games and interactive salary survey for the United Kingdom and Europe. For contract work, day rates quoted by games-specialist recruiters, which move faster than any published survey. Naming the source in a negotiation is also more persuasive than naming a number.

The structural facts worth knowing before you negotiate. Games generally pays below equivalent non-games software for the same skill level, and has for a long time; the gap is narrowest for graphics, engine and network specialists and widest for generalist gameplay and design. Bonuses are usually studio-wide or project-based and frequently do not pay out on a cancelled project, so treat a bonus in an offer as variable rather than as salary. Royalties and profit share are rare and mostly immaterial. Equity exists meaningfully only at startups and as restricted stock at publicly listed publishers. Overtime treatment varies by country and by contract and is worth reading carefully rather than assuming.

Contract and fixed-term work is a larger share of this market than it was, particularly in co-development. If you are taking a day rate with no holiday, no sick pay, no notice and no benefits, the rate per day should be meaningfully above the salaried equivalent per day, and if it is not, you are subsidising the studio. Ask the end date, ask the notice period on both sides, ask what fraction of the team is contract, and ask what happened at the end of the last contract cohort. Repeated extension is common and is not the same as security.

On crunch, ask the direct question rather than the polite one: how many hours did the team work in the last month before the previous milestone, and what specifically changed afterwards. Some studios genuinely reformed. Some renamed it. The answer, and the speed of the answer, tells you which.

Collective organisation in games changed materially in recent years and it is now a reasonable topic in an offer conversation. Quality assurance staff and then wall-to-wall development units at several North American studios organised, largely with the Communications Workers of America, and CWA holds a labour neutrality arrangement covering studios Microsoft owns, which makes organising there materially easier than elsewhere. An industry-wide direct-join union for game workers, United Videogame Workers, also now exists with CWA, which matters particularly to contractors and to people at studios too small to organise conventionally. Separately, SAG-AFTRA's interactive media agreement, renegotiated after the interactive strike, added consent and disclosure terms covering digital replicas of voice and performance, which is why voice recording now arrives with more paperwork than it used to. None of this gates your hiring. It does change which questions are fair to ask, and whether a studio is unionised is a legitimate thing to ask a recruiter.

On relocation and visas, be explicit early. Sponsorship concentrates at mid and senior level in cluster cities, and "remote friendly" in a posting frequently means remote within one country or one time zone band. Ask which countries they can employ in, whether they sponsor, and whether relocation support exists, in the first screen rather than the fourth.

What actually gives you leverage in a games negotiation: a competing offer, and a specialism the studio cannot source locally. Network programming, graphics, engine work, build and release engineering, and anything involving performance on a constrained platform all put you in a thinner pool than the market mood suggests. What gives you no leverage at all is enthusiasm for their games, which every candidate has. If you are mid-level and specialised, ask for more than feels comfortable. If you are entering, prioritise the shipped credit and the team you will learn from over a few thousand on the base, because the credit is what prices your next three jobs.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Game developer
• Game programmer
• Gameplay programmer
• Game engineer
• Unreal Engine 5
• UE5
• Unreal Engine
• Unity
• Unity 6
• Godot
• C++
• Modern C++
• C#
• HLSL
• Shader programming
• Blueprints
• Gameplay Ability System
• Enhanced Input
• Unreal Insights
• Unity Profiler
• RenderDoc
• PIX
• Engine programmer
• Systems programmer
• Graphics programmer
• Rendering programmer
• Tools programmer
• Pipeline programmer
• Network programmer
• Online programmer
• Multiplayer replication
• Client-side prediction
• Lag compensation
• Dedicated server
• Game AI programmer
• Behaviour trees
• Navmesh
• Utility AI
• Goal-oriented action planning
• UI programmer
• UMG
• Slate
• UI Toolkit
• Build engineer
• Release engineer
• Perforce
• Git LFS
• Continuous integration
• Data-oriented design
• Entity component system
• Burst compiler
• Job system
• Addressables
• Memory optimisation
• Frame budget
• Performance profiling
• Physics programming
• Animation programming
• Motion matching
• Linear algebra
• Quaternions
• Fixed timestep
• PlayStation 5
• Xbox Series X and S
• Nintendo Switch 2
• Steam Deck
• Mobile game development
• Live service
• Platform certification
• Technical designer
• Technical artist
• Houdini
• Lua
• Luau
• Roblox Studio
• Verse
• UEFN
• Python tooling
• Co-development
• Shipped titles
• Game jam
• Modding
• Playable build
• VR development
• DLSS
• FSR
• Upscaling
• Frame generation
• AI-assisted development

Mistakes that cost people this job

Questions people ask