October 29, 2026·6 min read
On day one, no backend engineer writes a greenfield service. They open a repository someone else built, get handed a ticket, and have to figure out where the relevant code lives, how it works, and how to change it without breaking three other things. That is the job for months before they build anything from scratch.
We interview them by asking for code on a blank page. The blank page is the one situation they will almost never face. The situation they will face constantly, reading and safely modifying unfamiliar code, is the one we rarely test.
A from-scratch problem measures whether someone can produce a known solution quickly. It is a real skill, but it is a small and unrepresentative slice of backend work. It tells you nothing about the behaviors that actually determine whether a hire is productive or dangerous:
Those are the day-to-day skills, and the only way to see them is to give the candidate real code they have never seen.
The exercise is simple to describe and hard to fake: a running backend service the candidate has not seen, and a concrete ticket. "Users report that canceling an order sometimes leaves the inventory count wrong. Find the cause and fix it."
Good repos and tickets for this share a few traits:
This is the backend-specific version of assessing debugging skill, which we cover more generally in how to assess debugging skill. The difference here is the emphasis on navigating an unfamiliar codebase, which is the defining backend skill.
The fix is the last five minutes. The first twenty are the interview. Watch how they orient:
The anti-signal is a candidate who starts editing within the first minute, ignores the surrounding code, and produces a fix that works locally but clearly does not fit the system, with no idea what else it touches.
Write the behaviors into a rubric so the panel agrees (see how to write a technical interview rubric):
A candidate who navigates cleanly, explains the system correctly, and runs out of time before the perfect fix is a stronger backend hire than one who produces a clever patch that ignores the codebase and breaks an assumption elsewhere.
Reading code fluency is invisible on a shared document. The signal is the sequence: where they looked, what they searched for, how they traced the flow. That only exists in a real environment with the actual repo and tools.
EasyEnv drops the candidate into a real workspace with the codebase and records the session. The panel can watch how they navigated, which turns "they seemed comfortable in the code" into a concrete record of how they built a mental model of a system they had never seen. Since that is the exact thing a backend hire does every day, it is the most predictive signal you can capture.
Backend work is mostly reading and safely changing code you did not write. Interview for that. Give the candidate a real repo and a real ticket, and score how they navigate, not just the diff.
Test the day-one job, not the one they will rarely do.
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
The backup job is green and nobody has ever run the other half. Here are four tasks on a real box that test whether a candidate can restore, verify, and tell you in minutes how much data was lost, which is the only number that matters during an incident.
Everyone says they know Git until a bad merge lands on main and the team loses a morning. Here are four tasks on a real repository, a conflict that is not textual, a commit that has to come out, a branch that has drifted, and a bug with an unknown origin.
Read more
Most API interviews turn into a style argument about plurals and status codes. The decisions that cost money are elsewhere. Here are four tasks on a running service that test retries, compatibility, pagination and error design, with what a strong answer sounds like.
Read more
