ResumeWorld
ResumeWorld
Screening guide
Engineering resumes are the easiest to screen badly. Tech stacks are listed in a sidebar, so keyword matching finds everything and distinguishes nothing. The signal that actually predicts performance is ownership — evidence that this person made decisions about something that ran in production and had consequences. That is what a screening rubric for engineers has to be built around.
Signal
Look for what the candidate decided, not what the team delivered. "Led the migration" and "was on the team during the migration" are different resumes written to look identical.
A long technology list is cheap to write. One stack described with specifics — scale, constraints, what broke — is the harder signal to fake.
Something that ran, had users, and had to be maintained. Coursework and tutorial projects read very differently once you know to look.
Strong engineers describe the constraint before the solution. Bullets that are pure tooling lists usually indicate someone who followed a plan rather than made one.
Short tenures matter less than what happened during them. Two years of shipped work beats four years of unclear contribution.
Noise
None of these is disqualifying on its own. Each is a reason to ask a question rather than assume an answer.
A stack list that has no corresponding evidence anywhere in the experience section
Every bullet in the passive voice with no identifiable decision
Seniority in the title that the described scope does not support
Metrics with no baseline — "improved performance by 300%" from what, measured how
Identical bullets across three different employers
Rubric
Write the criteria down before you look at anyone. An undocumented standard drifts, and it cannot be audited afterwards.
Demonstrated, specific experience in the primary language and framework the role runs on.
Evidence of working at or near the scale, complexity or constraint profile of your system.
At least one project where the candidate clearly made the calls, not just the commits.
Code review, mentoring, cross-team work — the part that decides whether a strong engineer is a net positive.
Prior exposure to your problem domain, weighted as a nice-to-have unless the domain is genuinely the hard part.
Next step
Ask the same ones of every candidate. Comparability is the whole point.
FAQ
Put it into practice
Score every application against the role you are actually hiring for, then get a ranked shortlist with the reasoning attached.
ExploreTurn a pile of applications into a ranked shortlist where every inclusion and every rejection has a reason attached.
ExploreGet a competency signal with the application instead of discovering the gap in the second interview.
ExploreOther roles
Everyone lists SQL and Python. Almost nobody describes a decision their analysis changed.
Read the guideThe portfolio is the application. The resume is context for it.
Read the guideCertification lists are long and cheap. Incident ownership is short and expensive.
Read the guideGo deeper
Most screening criteria are unfalsifiable. How to turn a job description into five to eight requirements you could actually verify from a document.
Read the guideStructured interviews predict job performance far better than unstructured ones. What structure actually means, and how to implement it well.
Read the guideHow resume parsing, scoring and ranking actually work, the four failure modes that cost you good candidates, and a workflow that keeps a human in the loop.
Read the guideDefine the criteria once, screen every application against them, and get a ranked shortlist with the reasoning attached.