18.5 Resume, Networking & Applying

Every earlier chapter in this book was about making something: a game, a system, a shader, a tool. This chapter is about the step nobody teaches in school — turning that work into a job. A CV (curriculum vitae, the one- or two-page document listing your skills and projects; called a "resume" in the US) is not a life story. It is a filter. A recruiter or hiring manager with a stack of 150 applications and one afternoon to get through them spends seconds on yours, not minutes. This chapter covers what actually gets read in that time, how to write bullet points that survive it, how to write a short cover note, how to be visible in the industry without being pushy, where junior jobs actually get posted, how to apply as a total beginner, and a weekly routine you can run for months without burning out. None of this requires being a genius programmer. It requires presenting real work so a busy stranger can see it fast.

1. The 20-Second Test: What Actually Happens to Your CV

When a CV lands in a pile of applications, almost nobody reads it top to bottom on the first pass. They skim it. Different studies of recruiter behavior put the first skim anywhere from about 6 to 30 seconds; treat 20 seconds as a working number, not a scientific law. What matters is the shape of that skim, because it is the same shape every time:

Notice what is not on that list: your GPA, the paragraph explaining why you love games, the objective statement at the top saying you are "a passionate and driven individual." None of that helps a reader decide anything in 20 seconds. What does help: a role title that matches what they are hiring for, project names and technologies that match their stack, and links that a reader can click without hunting for them.

This has a direct, practical consequence: keep it to one page, unless you genuinely have several years of professional experience that will not fit. A beginner who pads a CV to two pages with half-finished coursework and generic soft skills is not showing more — they are diluting the few strong lines that do matter. Every single line on the page is competing for a slice of that 20 seconds. If a line does not help a stranger decide "yes, look closer," it should probably not be on the page at all.

2. Order That Matches How People Actually Read: Links First, Projects Above Education

Because a reader's eyes only reliably reach the top portion of the page in a skim, the order sections appear in is not a matter of taste — it decides what gets seen at all. Two rules follow directly from Section 1:

• Contact details and links go at the very top, not the bottom of page one and never on page two. If a reader has to hunt for your GitHub link, most will not hunt.
• For a junior candidate with little or no paid experience, PROJECTS come before EDUCATION. A university degree is a credential — it says you completed a program. A shipped project is evidence — it shows what you can actually build. A reader hiring for a programming role wants evidence first. (This flips once you have several years of paid experience: at that point, experience becomes the strongest evidence and moves to the top, and projects and education shrink or drop off. This chapter is about the first job, so projects lead.)

Three links are usually enough: a portfolio (a personal site or a single page collecting your work — not required if your other two links carry enough on their own), a playable build (an actual thing someone can run — an itch.io page, an APK, a TestFlight link, a WebGL build in a browser), and your code (a GitHub or similar repository). Of these three, the playable build matters most and gets skipped most often by beginners. A recruiter cannot press a resume bullet and see if it is true. They can press a link and play your game in thirty seconds.

3. Bullets That Show Impact, Not a List of Duties

Most beginner CVs describe a duty: what the person was assigned to do. A strong CV describes an impact: what changed because that person did the work. The difference is not about writing fancier sentences — it is about finishing the sentence with a result instead of stopping at the task.

The Formula

A reliable pattern for a strong bullet has four parts: a strong action verb, the specific thing you built, the technique or technology you used, and — wherever you honestly can — a measurable result.

Here is the exact example that pattern is built from — a duty-style bullet turned into an impact-style bullet:

WEAK:   Worked on enemy AI.

STRONG: Built the enemy AI for a 3-month student project: behaviour
        trees, navmesh pathfinding and perception; profiled and cut
        AI frame cost roughly in half.

Notice everything the strong version adds without becoming a paragraph: how long the project ran (3 months — shows scope), the specific techniques (behaviour trees, navmesh pathfinding, perception — shows real technical vocabulary, not a vague claim), and a measured result (cut frame cost roughly in half — shows the work actually had an effect, and was measured rather than guessed at).

Five More Rewrites

The same formula applies far beyond AI. Here are five more, covering gameplay systems, tools, optimization, multiplayer, and leadership:

WEAK:   Worked on inventory system.

STRONG: Built a drag-and-drop inventory and equipment system in
        Unity (C#) for a 4-person team project, using
        ScriptableObjects for item data; shipped in a public demo
        played by 200+ people at a local game jam showcase.

WEAK:   Made a level editor tool.

STRONG: Built a custom Unity editor tool that let 3 designers place
        and tweak enemy spawn points without touching code, cutting
        level setup time from about 2 hours to 20 minutes per level.

WEAK:   Optimized the game.

STRONG: Reduced frame time on a mid-range Android device from 22ms
        to 15ms by batching draw calls and compressing textures to
        ASTC, taking the game from an unstable 35fps to a steady
        60fps.

WEAK:   Helped with multiplayer.

STRONG: Implemented client-side prediction and reconciliation for
        player movement over Unity Netcode for GameObjects, cutting
        visible rubber-banding at 150ms simulated latency from
        constant to rare.

WEAK:   Was team lead.

STRONG: Led a 4-person team through a 48-hour game jam, split work
        across gameplay, art and audio, and delivered a finished,
        submitted build with no missed deadline.

Notice that "weak" verbs share a pattern: worked on, helped with, was involved in, responsible for. Every one of them describes a relationship to the task (you were near it) rather than an action and its outcome (you did this specific thing and this specific thing happened). Swap them for verbs like built, implemented, fixed, optimized, shipped, led, reduced, designed — verbs that only make sense if you actually did the thing.

4. Putting It Together: A Full One-Page CV

Here is a complete, realistic example CV for a junior gameplay programmer, following the order from Section 2 and the bullet formula from Section 3. The persona and every project on it are invented for this lesson, but the shape, length and phrasing are exactly what a real junior CV in this field should look like.

A few things worth noticing about this example: every project bullet uses the strong-verb formula from Section 3. There is no "Objective" paragraph and no "About Me" section — the projects and links already say what kind of programmer this is. The skills block is a dense list, not sentences, because a reader scanning for "does this person know C# and Unity" wants the answer in half a second, not buried in a paragraph. And education is exactly two lines, at the bottom, because for a junior candidate it is the weakest evidence on the page, not the strongest.

5. Tailoring Your CV per Job: Mirror the Words in the Ad

Tailoring means adjusting your CV for a specific job ad rather than sending the identical document everywhere. It does not mean rewriting your whole CV each time — it means reading the ad carefully, noting the exact nouns it uses (its tools, its systems, its priorities), and, wherever it is honestly true of your work, phrasing your existing bullets using those same words instead of a synonym.

This is not about lying. It is about the fact that the same true fact can be phrased two different ways, and one of those ways is easier for a specific reader to recognize as a match. Say a job ad reads: "Looking for a programmer with experience in gameplay systems and combat design." If one of your bullets already reads "Built the enemy AI... behaviour trees, navmesh pathfinding and perception," that phrasing already matches — leave it. But if another bullet reads "Built a physics-based movement system," and that system genuinely included hit reactions and knockback for a boss fight, tailoring means surfacing that true detail with the word "combat" in it for this application, because it is honestly there and it is what this specific reader is scanning for. What tailoring never means is adding "combat systems" to a bullet about a project that never touched combat at all.

Why does this matter more than volume? Compare sending the identical CV to 100 studios against tailoring a CV for 10:

The generic approach spreads a fixed amount of effort thin across many low-quality attempts. The tailored approach concentrates the same rough amount of total effort into fewer, stronger attempts — and the side effect of doing the tailoring work is that you actually learn something true about each studio, which is exactly what an interviewer is listening for when they ask why you applied.

6. The Honest Part: Keyword Filters and Applicant Tracking Systems (ATS)

Here is something beginners are rarely told directly: at many studios, especially larger ones, your application does not go straight to a human. It first passes through an Applicant Tracking System (ATS) — software that scans, ranks, or filters applications by keyword match against the job description before anyone opens them. At high application volume, this is simply how the process scales, not a conspiracy against beginners. But it does mean a CV can lose before a human ever sees it, for reasons that have nothing to do with your actual skill.

The practical response is the same plain, simple format this chapter has already been building toward:

• Prefer a plain, text-based layout over a heavily designed, image-based, or multi-column PDF. Some parsers read image content as nothing at all, or scramble multi-column text into the wrong order.
• Use standard section names — Projects, Skills, Education — because both a human skimmer and a parser look for exactly these words.
• Honestly include the specific keywords from the job ad somewhere on the page, in context, as covered in Section 5. A filter cannot match a skill you have but never wrote down.

This is the real reason the plain, boxy layout from Sections 2 and 4 matters twice over: it is what a rushed human reads fastest in their 20 seconds, and it is also what an automated parser can actually extract correctly. A visually striking CV template full of icons, sidebars, and graphics might look impressive on your own screen and still fail completely the moment it goes through a parser.

7. The Cover Note: Three Paragraphs That Do a Job

A cover note (also called a cover letter) is a short message that goes alongside your CV — an email, or a text box on an application form. It is not a second copy of your CV in sentence form. Its job is to do three specific things, each in roughly one short paragraph:

• Why this studio, specifically. Something concrete and true — a shipped game you actually played, a specific technology they use, a talk someone from the team gave. Never generic flattery like "I've always dreamed of working at your amazing company," which could be pasted into a letter to any studio on earth and therefore proves nothing.
• What you bring. Two or three of your most relevant pieces of work, mapped to what the ad actually asked for, in your own words — not copied verbatim from your CV, but referencing it.
• The link, and a simple close. The one or two links most relevant to this specific job, your availability, and a short, polite sign-off. No pressure, no dramatic closing line.

Subject: Junior Gameplay Programmer application -- {Your Name}

Hi {Studio / Hiring Team},

{Paragraph 1 -- why this studio, something specific and true}

{Paragraph 2 -- what you bring, 2-3 concrete things tied to the ad}

{Paragraph 3 -- the most relevant link(s), your availability, thanks}

{Your Name}
{portfolio link} | {build link} | {code link}

Filled in for the persona and project from Section 4, applied to a small fictional studio:

Subject: Junior Gameplay Programmer application -- Jordan Reyes

Hi Lantern Peak Games,

I played through Driftlight on my phone last month, and the way
combat stays smooth even on my three-year-old Android is exactly
the reason I'm writing -- getting that kind of frame time on
mid-range hardware is the kind of problem I like solving.

For a solo project called Reef Runner I built a physics-based
movement system from scratch and brought frame time down from
22ms to 15ms through draw call batching and texture compression,
and for a 3-person student project I built enemy AI with
behaviour trees and navmesh pathfinding, cutting its frame cost
roughly in half. Both are C# in Unity, which I saw is your stack
too.

A playable build of Reef Runner is at jordanreyes.itch.io and the
code is at github.com/jreyes. I'm finishing my degree in Bangkok
and free to start part-time now, full-time from May. Thanks for
reading this far -- happy to send anything else that's useful.

Jordan Reyes
jordanreyes.dev | jordanreyes.itch.io | github.com/jreyes

Notice the first paragraph does not say "I love Lantern Peak Games." It says something specific enough that it could only have been written by someone who actually played the game — that specificity is what makes it read as genuine rather than templated, even though, structurally, it is a template.

8. Being Visible: Networking Without Being Weird

Networking, in this context, does not mean working a room of strangers or being fake-friendly to people because they might be useful later. The lowest-effort, most durable form of networking available to a beginner is simply being visible over time: posting progress on your own work, consistently, where other people who make games will see it.

• Post progress publicly and regularly. A short devlog (development log) entry, a ten-second clip, a screenshot — posted on itch.io, a forum, or social media, on some kind of steady rhythm, is worth far more over months than one polished trailer posted once.
• Go to jams and meetups, in person where possible, online where not. A game jam (a short, timeboxed event where people build a small game together, usually 48 hours to a week) puts you in a room with other people who make games, working alongside them rather than talking at them — which is a far more natural way to become a known face than cold messaging ever is.
• Comment genuinely on other people's work, not just post your own. A community where you only ever show up to promote yourself reads exactly as it looks.

The underlying principle is give before you ask: be a name someone already recognizes positively — because they have seen your posts, played your jam entry, or gotten a useful comment from you — before you ever need anything from them. A message from a total stranger who has never contributed anything to a space reads very differently from the same message sent by someone whose work people have already seen.

9. Messaging Someone in the Industry Politely

Eventually, being visible is not enough on its own, and you will want to message someone directly — maybe a programmer whose talk you watched, or someone at a studio you are interested in. There is one rule that separates a message people are glad to answer from one they scroll past:

The fix is to ask for one small, specific thing that can be answered in under two minutes — not "can you get me a job." A specific question, a thirty-second look at one screenshot, a yes/no about whether something is true in their experience. Keep the whole message to four to six sentences, personalize it with one true, specific detail about their actual work, and explicitly say there is no pressure to reply.

Hi {Name},

I saw your {specific thing -- talk / post / shipped game / clip}
about {specific detail}, and it changed how I think about {topic}.

I'm a student / self-taught programmer working on {one-line
project description}. I have one small question, no pressure to
answer: {one specific, answerable-in-two-minutes question}.

Thanks either way, and congrats on {specific thing} again.
{Your name}

Filled in as a real example:

Hi Priya,

I saw your GDC talk clip about tuning navmesh agent avoidance for
crowds of 200+ NPCs, and it changed how I set up pathfinding for
my own student project.

I'm a student programmer finishing a 3-person game with a fairly
dense NPC crowd. One small question, no pressure to answer: did
you find agent radius or avoidance priority mattered more for
keeping frame cost down at that count?

Thanks either way, and congrats again on the GDC talk.
Jordan

Notice what this message does not do: it does not ask for a job, a referral, or a resume review anywhere in it. If the conversation goes well and continues naturally over time, those bigger asks sometimes come up later, from the other person's own side. But the opening message only ever earns the right to a reply by being small, specific, and genuinely easy to answer.

10. Where Game Jobs Actually Get Posted

Junior game programming jobs show up in a handful of predictable places:

• Dedicated game industry job boards — sites built specifically for games work, which tend to have less noise than general job sites.
• itch.io's job board and similar indie-adjacent listing pages, which skew toward smaller studios more willing to take on a junior with a strong portfolio and no professional history yet.
• General job boards (LinkedIn and similar), useful mainly for volume and for company research, but with far more competition per posting.
• Studio career pages, checked directly. Worth visiting even when no specific role is listed — some studios, especially smaller ones, keep an evergreen "always open to strong junior applicants" note, or quietly accept unsolicited applications from people whose portfolio catches an internal recruiter's eye.
• Local or regional game-dev communities — Discord servers, forums, university game-dev societies — where small and mid-size studios sometimes post openings directly to a community instead of (or before) a public board.
• Conferences and expos, which often run their own job boards and booths alongside the event itself.

A cold application — applying directly to a studio with no listed opening and no prior contact — rarely works at a large structured studio, which usually only hires through a formal pipeline tied to actual open roles. It works far more often at very small or indie studios, who sometimes hire opportunistically the moment a strong, relevant portfolio lands in front of the right person, opening or not.

11. Applying as a Beginner: Junior, Intern, and the QA-to-Programmer Route

There are three realistic entry routes into a first programming job, and it is worth knowing all three rather than fixating on only the most visible one.

Junior / Graduate Programmer Roles

The most direct route, and also the one with the fewest openings and the most competition per opening — especially at large, well-known studios with structured graduate programs. These do exist and are worth applying to, but treat them as one route among three, not the only plan.

Internships

Often the single best entry route available to a student. An internship is explicitly meant for someone without professional experience, the bar is calibrated for that, and many internships convert into a full-time offer at the end. The catch: many internship cycles recruit many months ahead of the actual start date, so applying "when you feel ready" is often already too late — apply broadly and apply early.

QA (Quality Assurance) Tester, Then an Internal Move to Programming

A very common real path that beginners underrate. QA (Quality Assurance) testing — systematically playing a game to find and report bugs — has a much lower bar to enter than a programming role, and there are simply more QA openings than junior programming ones at most studios. Once inside, you learn the studio's actual codebase, tools, and people, and you become a known, trusted name well before you ever apply for an internal engineering opening. Plenty of working game programmers took exactly this path. It is slower, and it only works if you take the QA work itself seriously and do it well — showing up expecting to coast until "something better" opens up is visible to the people around you, and it works against the whole point of the route.

Smaller studios are worth applying to first for concrete reasons, not just because they are easier to get into: fewer applicants per opening, faster hiring decisions (sometimes weeks instead of months), and broader day-one responsibility — at a small team you touch more systems and learn faster because there is nobody else to hand the work to. A real shipped credit at a small studio is a stronger line on your next CV than another unfinished personal project, even if the studio itself is not a household name.

12. The Application Funnel: Realistic Numbers, Rejection, and Silence

An application funnel is the sequence of stages an application passes through, with the number of applications shrinking at each stage. Seeing realistic numbers ahead of time changes how the process feels while you are in it. The numbers below are an illustrative example, not a promise or a guarantee — but the shape of the funnel, heavily narrowing at every stage, is close to normal for a first junior search:

Two things follow directly from this shape. First: silence is the default outcome, not a verdict on you. Most companies, especially larger ones, do not send a rejection email to every applicant — a non-reply is normal operational behavior at high volume, not a personal judgment, and treating every silent application as a small failure is not an accurate reading of what is actually happening on the other end.

Second: there is a correct, limited way to follow up. If you sent a genuinely tailored application and have heard nothing after roughly two weeks, one short, polite follow-up is appropriate — reaffirm interest, restate the single most relevant link, ask if there is any update. After that one follow-up, whether or not you get a reply, let it go. Continuing to chase past that point reads as pressure, not enthusiasm, and does not improve your odds.

13. A Weekly Application Routine You Can Actually Keep Up

A job search for a first programming role commonly takes months, not weeks. A routine that sprints hard for two weeks and then collapses from exhaustion produces worse results over a full search than a small, steady weekly cadence maintained for as long as it takes. The goal of a routine is not maximum daily effort — it is a pace you can actually sustain without quietly stopping.

The Routine

The one habit worth adding on top of the daily routine: track every application in a simple spreadsheet — studio, role, date applied, whether it was tailored, which links you sent, your follow-up date, and the outcome. After a month or two, that spreadsheet becomes a real diagnostic tool: if response rate is low, the CV or tailoring is probably the bottleneck; if you get responses but few interviews convert, technical interview practice is probably the bottleneck; if interviews go well but offers do not land, it may be worth practicing how you talk about your work out loud. Guessing at which stage is weak wastes effort improving the wrong thing; a few weeks of tracked data tells you directly.

14. Glossary

• CV (resume) — a one- or two-page document listing your skills and projects, used to apply for a job; "resume" is the common US term for the same document.
• Portfolio — a personal site or single page collecting examples of your work, meant to be browsed by someone deciding whether to interview you.
• Playable build — an actual runnable version of your game that someone can play themselves, as opposed to a description or screenshot of it.
• Cover note (cover letter) — a short message sent alongside a CV, explaining specifically why you are applying to this studio and what you bring.
• Tailoring — adjusting a CV or cover note's wording for a specific job ad, honestly mirroring the ad's own terms where they are true of your work.
• ATS (Applicant Tracking System) — software many studios use to scan, rank, or filter applications by keyword match before a human reads them.
• Keyword mirroring — phrasing a true fact about your work using the same specific words a job ad uses, so both a human and an ATS recognize the match.
• Cold application — applying to a studio with no listed opening and no prior contact with anyone there.
• Warm introduction (referral) — being pointed toward a role, or having your application flagged, by someone who already knows your work, even loosely.
• Game jam — a short, timeboxed event (commonly 48 hours to a week) where people build a small game, often in a new team formed just for the event.
• Devlog — a development log: a short, regularly posted update showing progress on a project.
• QA (Quality Assurance) tester — someone who systematically plays a game to find and report bugs before release; a common entry point into a studio.
• Internship — a fixed-term junior role explicitly meant for someone without professional experience yet, often recruited many months ahead of its start date.
• Junior / entry-level role — a position aimed at someone applying for their first professional job in the field.
• Live-ops — the ongoing operation of a live game after launch: regular content updates, events, and balancing, as opposed to one-time shipped work.
• Application funnel — the sequence of stages an application passes through (applied, acknowledged, interviewed, offered), with the number of surviving applications shrinking at each stage.
• Follow-up — a short, single, polite message sent after a period of silence to reaffirm interest and ask if there is an update.
• Ghosting (silence) — receiving no response at all to an application; the most common outcome at nearly every stage of a job search, not a verdict on skill.
• Networking — building genuine visibility and relationships within an industry over time, as distinct from asking strangers for favors with no prior contact.

15. Exercises

1. Built the inventory and pause-menu UI in Unity (C#) for a
   3-person team project, using the UI Toolkit; reduced menu
   input lag reported in playtests from noticeable to unnoticed.

2. Ran structured QA passes across a 6-week production cycle for
   a 5-person team, filing 60+ bug reports with repro steps;
   cut the pre-launch critical bug count from 14 to 0.

3. Built a custom Unity editor tool for placing and previewing
   collectible pickups in-scene without entering Play mode,
   cutting level-dressing time roughly in half for 2 designers.