I hired over 40 engineers in my previous work before starting Fonzi. I've reviewed a few thousand resumes in that time, and I can tell you that my honest reading behavior looks almost nothing like what most resume advice assumes is happening.
There is a small amount of eye-tracking research on resume reading patterns. It consistently shows that attention concentrates heavily at the top of the document and drops off quickly below the fold. The hiring manager reads about 80% of what's in the first third of the document and considerably less of everything after. They're not being lazy. They're doing triage. At 30 to 150 resumes for an engineering role, the mental economics are unforgiving.
Here is what actually captures and holds attention in the first 90 seconds.
What Gets Read First: The Most Recent Job Title and Employer
The first thing a hiring manager looks at in an engineering resume is the most recent role. Specifically, the title and the employer name. This takes about three seconds. In those three seconds, they're running a rough pattern match: is this person at the right level? Are they coming from a context that might be relevant?
This pattern match is coarser than most engineers realize. A "Staff Engineer" title at a mid-sized product company reads differently than the same title at a large infrastructure company or a two-person startup. The employer context shapes what the title actually means, and hiring managers apply a lot of implicit context here.
The implication for engineers who work at less recognizable companies is that the resume needs to do more work to surface context fast. A one-line company description ("8-person fintech startup building payment infrastructure for emerging markets") anchors the employer immediately. Without it, the hiring manager's brain fills in the gap with a generic default, which usually undersells the candidate's actual context.
What Gets Skimmed Quickly: Technology Stack
After the most recent role, attention moves to the technical skills section or wherever the primary stack is visible. This part gets read in about five to ten seconds as a fast check: do the core technologies match? Is there a red flag (nothing the team uses) or a green flag (direct overlap)?
What most engineers get wrong here is treating the skills section as a comprehensiveness exercise. Long lists of technologies, especially older or peripheral ones, dilute the signal. A hiring manager reading a backend role that needs Go and Postgres doesn't benefit from seeing that the candidate also knows jQuery, Perl, and SVN. The signal-to-noise ratio drops.
The more important part of the stack is what's implied by the project context, not what's listed as a skill. "Built a high-availability distributed cache that handled 200k requests/sec" tells a hiring manager more about real Go and systems competence than "Go (5 years)" in a skills section. The projects are where the credible signal lives. The skills section is just a fast keyword scan.
What Gets Read Carefully: The Two or Three Most Recent Job Descriptions
Assuming the first passes the rapid triage, the hiring manager now reads the two or three most recent roles at something approaching full speed. This is where the real evaluation happens. They're looking for three things.
First, scope and scale. The descriptions should give a sense of what the person owned, what the system or team size was, and what kind of decision-making they were doing. "Contributed to the backend team" is useless here. "Owned the data ingestion pipeline (12M events/day) from schema design through production monitoring, with two direct reports" is useful.
Second, trajectory. Is the most recent role a step up from the one before it in scope or responsibility? A flat or downward trajectory in role scope raises a question that the hiring manager now has to resolve in a screen call, which costs time. Clear upward trajectory is a positive signal that doesn't require explanation.
Third, specificity of impact. Vague contributions ("improved system performance") are common and register as low-quality signal. Specific impact with plausible numbers ("reduced p95 latency from 850ms to 180ms by replacing a synchronous cache invalidation pattern with an event-driven approach") is memorable and credible. It also shows how the engineer thinks about their own work, which is itself a signal.
What Gets Largely Ignored: Objective Statements, Earlier Roles, and Education (Mostly)
Objective statements at the top of a resume are almost universally skipped. They've been a resume-writing recommendation for decades and they rarely contain information that the rest of the document doesn't duplicate more usefully.
Earlier roles, especially anything more than five or six years old, get light attention at most. Hiring managers are focused on what you've been doing recently and whether you can do the thing they need now. An early career role at a well-known company might still be read, but a mid-career role at a smaller company from eight years ago essentially disappears.
Education is read quickly and checked against a simple filter: is there a red flag? For most mid-to-senior engineering roles, education is not a positive differentiator after the first few years of career. It's checked, not evaluated. The exception is specific academic work directly relevant to the role (a machine learning thesis for an ML engineer role, for instance) where it provides real signal beyond the credential.
The Formatting Effect on Attention
Dense walls of text in a resume are skipped faster than structured, scannable content. This is not about aesthetics. It's about how a tired brain processes information under time pressure.
Bullet points are read. Paragraphs are mostly skimmed. If a candidate puts their most important context in a paragraph, there's a meaningful chance the hiring manager processes the first sentence and moves on. If the same information is the first bullet under a role with a clear company context line, it gets read.
The cognitive load argument also applies to length. A six-page resume isn't a signal of depth. It's a signal that the candidate hasn't edited. Hiring managers who've seen thousands of resumes develop a low-grade irritation toward documents that respect neither their time nor their working memory. That irritation doesn't help the candidate.
What This Means for How We Think About Resume Screening
One of the things we've grappled with in building Fonzi's matching layer is that resume screening is genuinely imperfect as a signal source. Hiring managers bring real expertise to this task, but they're also pattern-matching under cognitive load in ways that miss strong candidates whose resumes don't happen to match the visual pattern of past good hires.
We're not arguing that resume review should be eliminated. The information is valuable. But treating it as a comprehensive evaluation rather than a fast filter is a mistake. The resume screens out candidates who are clearly wrong for the role. It doesn't reliably identify the right ones. That part needs more signal, from a different source, and that's the problem we're trying to solve.
The 90-second resume read is a feature of the hiring process, not a bug. The bug is building everything downstream on it as if it were more reliable than it is.
