As engineers move into senior roles (title dilution not withstanding—”senior” here means many years of practice), their work becomes less and less about writing code all day. It’s more about judgment than logic. They’re shaping systems, guiding teams, making decisions that ripple through architecture, culture, and future projects. They’re solving fewer “how do I write this” problems and more “what’s the right thing to build and how do we build it responsibly” problems (note the alignment of this statement with LLM-assisted programming—a different topic for another time).
So it’s strange—honestly, absurd—that when interviewing for these roles, we still reach for the same tired approach, typically some combination of live coding, whiteboarding systems design, random technical questions, and/or rushed hypotheticals. As a proxy for real conversation, it’s a worn-out strategy for predicting whether someone is right for the role.
The Interview as Performance
For seasoned engineers, technical interviews can be a challenging format for learning anything useful. It’s a performance—a show of nerves and endurance rather than ability or judgment. When you ask someone to rebalance a binary tree or walk through a caching strategy in an interview, what you’re really asking is how well they can adapt to an artificial environment. Can they quickly decode what’s expected? Can they perform under pressure? Can they think out loud in the “right” way?
That might be helpful if you’re hiring stage actors, but for thoughtful, accomplished engineers who are used to solving real problems over weeks or months, it’s just noise. Worse, sometimes it’s a power move, especially when the candidate is very senior. In that situation, throwing down technical puzzles isn’t about assessment—it’s about control, and it’s toxic.
Why Do We Keep Doing It This Way?
Because it feels fair—or at least, it feels standardized. Everyone gets the same kinds of questions, the same time limit. It creates the illusion of objectivity. But fairness isn’t the same as insight. Just because something is easy to score doesn’t mean it’s meaningful.
There’s also inertia. We’ve done it this way for years, it’s how the big companies do it, and isn’t it reasonable to expect everyone to know the same things? But that’s bias, not purpose. At best, it reflects a narrow definition of engineering competence. At worst, it’s just lazy hazing.
It’s not easy to get off the stage and into the real world. It can be intimidating to really talk shop with someone you just met, especially a battle-hardened senior engineer. Asking questions where you don’t already know the answer takes vulnerability. The standard bag of tricks offers comfort and control.
Don’t Ask Trick Questions—Talk About the Work
Real signal comes from lived experience. What did this person build? Why that way? What broke? What would they do differently? What tradeoffs did they make? How did they define “done”?
If you listen with interest and curiosity, you’ll get more insight from a single war story than ten rounds of technical tests or whiteboard sessions. Ask what failed in production. Ask what tough call they had to make. Ask what they learned. If the conversation is honest, you’ll come away with a real sense of how they think and lead.
If your team isn’t equipped to have that conversation—if they need a script, actors and a theatre instead—then the problem isn’t the candidate.
Koster is one of our industry’s most credible designers. His contributions to MMORPGs, notably Ultimate Online and Star Wars Galaxies, are seminal, and he has been a steady design influence for many years, whether speaking at industry conferences, his blog (it’s been around forever), or his books, especially A Theory of Fun for Game Design (a delight).
On the heels of a successful new Kickstarter campaign, Stars Reach is starting to look as if there is more there there, and it’s the most excited I’ve been about an MMO in years. Originally announced last June, Koster and team at Playable Worlds have been full speed ahead with dev blogs, pre-alpha tests, and a YouTube channel.
The game is a single-shard sandbox MMORPG with strong procedural elements, thousands of planets, spaceships, space stations, destruction, rebirth, housing, and ecosystems running in the background (planets have health bars that can drop to zero!). Much to my delight as a long-time Unity developer, it’s using Unity.
There is an inevitable comparison here to No Man’s Sky, but the approach appears quite different. Stars Reach is more focused on creating a collaborative, living galaxy of sorts, with a deep skill tree and a horizontal progression system. There is a broader simulation system at work, too, with community-driven goals and cooperation at the core.
I can’t help but feel that something pivotal lies in the direction of Stars Reach. While having a clear structure and a predictable gameplay loop is fundamental to most video games, marrying that to the effects of fun, well-executed dynamic environments and emergent behaviors on choices and outcomes is a tall order. Stars Reach is getting a complex weather simulation, on top of allowing players to modify and destroy elements in the game world (using cellular automata, not voxels), purportedly without lasting negative consequences.
It will be interesting to see how it all shakes out. Koster seems fully aware of the challenges of a deep sandbox. This is definitely a project to follow as it moves toward release over the next few years.
Brad Feld once wrote a little gem called Something New is Fucked Up In My World Every Day. It’s an inspirational reminder that the way out of your problems is through, and that you don’t need to look far to discover how insignificant your significant woes may be. It also reminded me that sometimes problems don’t look like problems.
Years ago my mother managed a facility for psychiatric patients who were hoping to eventually reintegrate into society. Once, on a visit home, I was chatting with her in her office when someone knocked on the door, came in with a clipboard and a stack of papers, and proceeded to discuss medication schedules and patients with her.
He was dressed well, articulate, and personable. He introduced himself to me and asked how my visit was going. He enthusiastically talked about how much he enjoyed working with my mother.
After he left I said, “Great guy, mom, he seems like a go-getter”, to which she replied, “He’s a patient—one of our most difficult”. Turns out that he was a well-adjusted fellow most of the time (though delusional about his role there), but every couple of weeks he would have a terrible psychotic break for a day or two. He was bipolar with short, intense manic periods. Without medication, he was much worse, but with medication (and the harmless delusion that he was an assistant at the facility), I had no idea there was a problem there.
Of course there are many ways in which a problem does not look a problem. Since this blog is mostly about video game development, I can think of a few:
Minimized by Something Else. Frustrating level design might be minimized by adjustable difficulty settings. While this makes the game more accessible, it doesn’t address bad core design choices.
Masked by Something Else. Underlying performance issues could be masked by high-end graphics and engaging gameplay. Players may not notice problems until later levels or in non-persistent subsystems, like VFX, that are more demanding on the system.
Compensated by Other Strengths. In a game where story is crucial, exceptional programming skill might compensate for inexperienced story writing, leading to a game with strong mechanics but a weak narrative.
Overshadowed by Larger Issues. Minor glitches might go unnoticed because developers (and players) are more concerned with major bugs that significantly affect gameplay.
Delayed Effects. The long-term impact of crunch may not be immediately apparent, but over time it leads to burnout and high turnover.
Normalization of Deviance. Cutting corners to meet deadlines, such as not fully testing patches or bypassing QA, could become the cultural norm if no immediate issues arise, potentially leading to bigger problems down the line.
Of course you can’t anticipate every bump in the road, but you can concede a bumpy road. In the Eat Me If You Wish parable referenced in Feld’s post, a man whose cave is full of demons makes them disappear by surrendering to their unknown wishes. Another way to view this is that you render your demons powerless by consenting to their nature, rather than fighting to accept them as some sort of intractable finitude.
Consent is powerful. Consent to problems you can’t see. Get comfortable with uncertainty. Allow for plenty of unknown mistakes. And be willing to pivot.
The scene is all too familiar: A whiteboard (real or virtual), a distracted interviewer with little time or patience, and a contrived problem to solve in thirty minutes. The job candidate’s heart races, fingers poised over the keyboard, while the pressure mounts—the syntax, the algorithm, the fear of forgetting a semicolon—until it’s all anxiety and adrenaline, a far cry from the collaborative, iterative process that defines real-world game development.
It’s so… suboptimal. And for senior game developers—battle-hardened by years of thoughtful problem-solving, who have built formidable programming war chests—it’s downright silly. Yet these interviews are all too often an integral part of the hiring process, even at small studios.
The Three Virtues, or Lack Thereof
Larry Wall, the sage behind Perl, bestowed upon us the three virtues of a programmer: Laziness, Impatience, and Hubris. But in the pseudo-crucible of live coding interviews, the virtues morph into darker counterparts:
Artificial Pressure. Laziness in its virtuous form drives programmers to automate, optimize, and streamline, and that takes time. When an interviewer lords over an artificially short deadline that stifles creativity and encourages careless thinking, they are simulating a type of high-pressure scenario that mirrors the worst kind of real-world game development.
Narrow Focus. Impatience, when wielded by interviewers, becomes a blunt instrument. Swift solutions ignore the intricacies of real problem-solving, while senior developers long for deeper discussions about topics that transcend mere code snippets.
Cryptic Trivia. Hubristic interviewers can’t see past their canned code problems, problems they themselves would likely not be able to quickly solve. They scoff at candidates who question the relevance of the exercise or can’t solve it exactly the way they want. Meanwhile, senior developers are thinking: “I’ve shipped games, optimized renderers, battled nasty memory leaks, rewritten entire subsystems from scratch. Why not discuss that?”
False Positives
Imagine a job description that optimizes for the three [non]virtuous qualities:
Of course no one would advertise for such an absurd developer—a false positive if there ever was one—since these qualities would result in highly undesirable outcomes:
Stagnation in problem-solving and inability to adapt to novel challenges
Poorly designed systems, technical debt, and frustrated teammates
Lack of groundbreaking features, outdated practices, and missed opportunities
Broken features, uninspired implementations, and missed UX opportunities
Clunky interfaces, inconsistent gameplay, and spaghetti code
Misaligned goals, communication breakdowns, and missed optimizations
Wasted time on trivial details, missed deadlines, and strained relationships
All kidding aside, it’s not difficult to see how, at best, a live coding interview optimizes for a more realistic false positive: a much more junior developer:
Junior candidates may excel in live coding because they are more accustomed to rapid coding challenges from their academic or early career experiences
Juniors may have more recent practice with coding challenges due to recent coursework or coding bootcamps
Live coding tests sometimes favor memorization of common algorithms or patterns, which junior candidates may have studied more recently
Live coding interviews assess specific coding skills, but senior roles require broader expertise like architecture, system design, and project management
False Negatives
Live coding interviews also have a knack for producing false negatives. This results in:
Missed Opportunities. Rejecting a senior candidate due to to a poor live coding interview means missing out on their potential contributions—you know, the things real senior developers do. They could have optimized code, improved performance, enhanced gameplay mechanics, and mentored others.
Costly Delays. Game development timelines are always tight. A false negative prolongs the hiring process. You’ll need to restart the search, interview new candidates, and onboard someone else. Meanwhile, the game faces delays, impacting release dates and revenue.
Team Morale. Imagine the impact on team morale when a promising senior developer is turned away. Existing team members may question your judgment or feel demotivated. It’s essential to maintain a positive atmosphere.
A Better Approach
Studios deserve a interview process that discourages false positives and false negatives, and senior game developers deserve an interview that celebrates their craft, not one that reduces them to code-spewing automatons. Here are some ideas:
Higher-Level Discussions. Replace live coding with an in-depth conversation. Imagine discussing game architecture, engine choices, plugins and frameworks, optimization strategies, workflow, and pipelines. Senior developers shine when they can articulate their vision, share war stories, and debate trade-offs.
Take-Home Projects. Instead of a whiteboard, assign a small take-home project, for instance building a game mechanic, optimizing existing code, or implementing a non-trivial state machine. This mirrors real-world tasks and allows creativity to flourish.
Collaborative Problem-Solving. Conducta short problem-solving session. Sit down with the candidate, present a real issue from a real game, and discuss different approaches. Collaboration reveals teamwork, adaptability, and communication skills—essential for any senior role.
Jaron Lanier has another great piece called “How to Picture A.I” in the New Yorker. He is so good at using simple metaphors to explain complex ideas, and I loved this last little bit:
The science-fiction writer Arthur C. Clarke famously stated that a sufficiently advanced technology is indistinguishable from magic. But that is only true if that technology is not explained well enough. It is the responsibility of technologists to make sure their offerings are not taken as magic.
At the moment, OpenAI appears to be content with offerings that are taken as magic. Magic is exciting. Magic creates drama. Magic generates investment.
I really want to trust Sam Altman, his board, and the optimistic engineering team at OpenAI. Altman comes across as a natural-born CEO—confident, purposeful and thoughtful, albeit with a fair dose of tech-bro. But he is no scientist which, given the stakes, makes me uneasy.
Lex Fridman(01:35:02) There could be major theatrical moments, also. What to you would be an impressive thing AGI would do? You are alone in a room with the system.
Sam Altman(01:35:16) This is personally important to me. I don’t know if this is the right definition. I think when a system can significantly increase the rate of scientific discovery in the world, that’s a huge deal. I believe that most real economic growth comes from scientific and technological progress.
“I wish it need not have happened in my time,” said Frodo.
“So do I,” said Gandalf, “and so do all who live to see such times. But that is not for them to decide. All we have to decide is what to do with the time that is given us.”
J.R.R. Tolkien, The Fellowship of the Ring
Some believe that the video game industry is in crisis due to the spate of layoffs over the last couple of years. It’s not been easy, and my heart goes out to every game developer who has lost their livelihood—it’s a very tough pill to swallow to be let go from a job you love.
But remember, we’ve seen this before. Things cycle and consolidate like crazy in this business. Teams ramp up, then reconfigure or downsize. Companies wax and wane. I’ve seen this many times over a nearly thirty-year career.
“Happiness can be found, even in the darkest of times, if one only remembers to turn on the light”.
Albus Dumbledore
Owing to other commitments, I will miss GDC this month. Frankly, I won’t miss Moscone and San Francisco in March, or how verbose many of the sessions have become. (I still pine for the days when it was held in San Jose!)
But I will miss the faces, minds and hearts of fellow game developers—so many creative spirits in one place—and the random, sometimes deep (often hilarious), conversations that tend to popup right after a session, in a queue for a slice of pizza, in the lobby of the W, and certainly at parties.
And for those a bit too worried about the state of things, I will miss the chance to say: Have hope. Find your happy place. Shine your light—it is still there, through the darkness, I promise you. Keep making things. Keep learning. Keep that delightful creative spirit that lives within you alive—it’s the thing that got you into this business in the first place. Remember your light!
