The Questions a Technical Reviewer Is Trying to Answer
At some point your resume gets read by an engineer rather than a recruiter — usually the person who would end up reviewing your pull requests. That reader is not scoring your document. They are trying to answer a small set of questions so they can give a yes, a no, or a “worth a call”.
Most resumes fail not because they’re badly written but because they never answer any of the questions. Here they are, and what a page has to contain to satisfy each one.
Question one: have you done work shaped like our work?
Not the same work. The same shape. A reviewer hiring for a service-oriented backend wants to know whether you’ve operated something with a network boundary, a database under load, and consequences when it breaks. Whether it was in Go or Java is secondary and both of you know it.
What answers it: a description of systems, not a list of technologies. “Owned the ingest service that received webhook traffic from payment providers and wrote to a partitioned Postgres table” tells a reviewer the shape immediately. “Backend development using Java, Spring, and PostgreSQL” does not — it’s compatible with anything from an internal CRUD app to a high-throughput pipeline.
What fails it: bullets that describe the team’s product rather than your system. If your bullet would be equally true of six colleagues, it’s about context, not about you. There’s a fuller treatment of this in writing engineering bullets that say something.
Question two: how deep does it go?
Every reviewer is calibrating depth, because depth is what separates two candidates with identical technology lists. The question underneath is: when this system misbehaved, were you the person who found out why, or the person who was told afterwards?
Depth shows up in surprisingly small details. Mentioning that you tuned autovacuum, or that you found the problem in the connection pool rather than the query, or that the fix was a change to the retry policy rather than a bigger instance — these are all one clause long and they are the difference between someone who used a database and someone who has been inside one.
You do not need many of them. One or two clauses per role that could only have been written by someone who was actually debugging changes how the whole page reads.
Question three: what were you responsible for, and how much of it?
This is the seniority question, and it is mostly a question about scope rather than about skill. A reviewer wants the boundary of your ownership: one service or a domain, one team’s tooling or the organisation’s, your own work or also other people’s.
The mistake here runs in both directions. Some resumes inflate — “led the migration” when you were one of eight — and get taken apart in the first probing question. Others deflate, describing genuine ownership in the passive voice until it sounds like the work happened nearby. Both are worse than a plain statement of what your part was. Scope, not years goes into what scope actually consists of and how to make it visible without exaggerating.
Question four: would you be a net positive on the team, quickly?
This one is rarely stated and it’s doing a lot of work. Reviewers are imagining you in their codebase next quarter. The things that predict a fast start are unglamorous: can you read unfamiliar code, do you write things down, do you take review feedback, will you notice when something is off.
Evidence for this hides in ordinary bullets. Having got a non-trivial change through the review process of a project you didn’t own. Having written the design document that changed a decision. Having onboarded onto a legacy system and made it less frightening. Having improved a test suite so other people could move. None of these look like flagship achievements and all of them answer the question.
Question five: is anything here going to be a problem?
Reviewers do look for reasons to say no, not out of malice but because their time is finite. The common triggers are all self-inflicted:
- A claim that doesn’t survive arithmetic — a stack list too long to be real, or an impact figure with no plausible source.
- A technology name used incorrectly. This one is fatal with technical readers in a way it isn’t with anyone else. Spelling Kubernetes as “Kubernetics” or describing gRPC as a database is a single-word credibility loss.
- Wildly inconsistent seniority signals: staff-level title, bullets that describe ticket work.
- A resume that appears to have been generated wholesale, with the tell being that it says nothing specific about any system.
None of these require a perfect document to avoid. They require the document to be honest and proofread by someone who knows the terminology.
Where the page has to answer them
The five questions do not get answered in five sections. They get answered in roughly this order as the reader moves down the page:
The first block — title, company, one-line company descriptor. Question one starts here. A reader who has never heard of your employer cannot infer scale, so a short parenthetical does real work: (B2B logistics platform, roughly eighty engineers).
The first two bullets of the most recent role. This is where question two and question three get their answer, or don’t. If your strongest ownership statement is the fourth bullet of your second job, move it.
Anything cross-cutting. Mentoring, design review, incident ownership, cross-team work — this is question four’s evidence, and it belongs in the experience section rather than in a separate skills-adjacent block where it reads as a list of virtues.
The skills list, read last and used as a check. Experienced reviewers use it to confirm the shape they already inferred, not to form an impression. That’s part of why an enormous one backfires: it contradicts the specific picture the bullets just built. See the tech stack list problem.
The rewrite this suggests
Take your current resume and, for each of the five questions, find the exact sentence that answers it. Not “the section that gestures at it” — the sentence.
Most people find they have a strong answer to question one, a weak answer to question three, and no answer at all to questions two and four. That’s a tractable problem. It usually means finding two clauses of real technical detail you left out because it felt too small to mention, and one sentence about something you did for other engineers.
Both of those are already true about your work. They’re just not on the page yet.