Games make good interview questions
2025-09-22
Leetcode isn’t the best differentiator
A lot of people don’t like Leetcode. My reason is practical. Most good candidates from Waterloo can comfortably do medium problems. Hard problems test recall more than problem solving.
It’s hard to evaluate problem solving when people can memorize Leetcode problems, or worse, cheat with AI. At a small startup, each person is a big part of the team, so getting technical hiring right is close to existential.
The alternatives have trade-offs
When interviews move away from Leetcode to “real world coding”, the problems usually get easier, and they don’t get more fun. There are two reasons.
Leetcode is simple. The input is an array, a tree or a graph, and you return some output. The solution can be hard, but the problem is easy to understand. Real-world context is often not intuitive for the candidate, so the interviewer has to lower the difficulty to make room for it.
Take a Ramp onsite problem as an example. It tests basic networking by turning graph traversal into a puzzle:
Given a starting URL
ramp_interview.com/0that returns a list of URLs like[ramp_interview.com/322, ramp_interview.com/yellow], find the URL that returnssuccess.
It’s more interesting than plain graph traversal. There are easter eggs in the response headers, and some requests fail with a 5XX so you have to retry. In practice, the candidate needs too much hand-holding. When they get a 5XX they ask if the service is down, and the interviewer has to steer them to the real question: how do you handle 5XX responses here?
Leetcode has a clear measure of correctness. You pass the test cases or you don’t. O(n) beats O(n log n). Judging OOP, code cleanliness or how well someone prompts Cursor is subjective, and a rubric for it is hard to keep consistent across many interviewers. So most “non-Leetcode” problems end up as Leetcode with seasoning on top.
The problem
Ours is tic-tac-toe, in two parts.
Take-home: write a program that plays every possible game and prints the number of valid, completed board states. Valid means reachable under the rules. Completed means someone won or the board is full. Two games that end in the same state count once.
Onsite, 50 minutes: write a strategy for O. A simulator plays 10 games against a computer strategy: the computer opens with each of the 9 squares, then you go first once. Anything is allowed, including Google, any library and calls to Claude. The computer strategy is documented, and you can read it, copy it or exploit it. It also isn’t optimal and loses to itself.
Candidates usually take one of four paths:
- Heuristics: take a win, block a win, make or block a fork, take the center or a corner.
- Start from the computer strategy, then find and fix where it loses.
- Minimax. Tic-tac-toe is small enough that it needs no pruning or depth limit.
- Something new, like importing the computer strategy and using it to look ahead.
Why games work
Games are simple. I never had to explain the rules of tic-tac-toe. The take-home also preps candidates for the onsite without them knowing, so nobody is lost at the start. The exception is someone who didn’t write their own take-home, and that’s obvious when you compare the two.
Games have a clear measure of success. You win, lose or tie. The simulator is a wrapper around 10 test cases. But the testing is adaptive, because another strategy plays against yours. Candidates also get to decide what “good” means. Is it better to lose once and win nine times, or to always at least tie?
Games test real-world coding without forcing it. I think experience shows most when people fix problems. The engineers I look up to find issues fast because they’ve fixed so many, and they move naturally across the code. How someone uses their IDE, and where they put breakpoints or print statements, tells me more than their resume. Open-ended games rarely work on the first try, so candidates end up reading the starter code and debugging their own logic. That’s a better experience than “this code has 10 bugs, find them”.
Games test culture fit. I had a lot of fun making this problem. When a candidate has fun solving it, that’s a strong signal, and we’ve worked well together when they joined.
AI struggles with them. It can probably one-shot the take-home now. The onsite is still hard for it.