The hiring pipeline: stages, readers and the ATS

Before you can write for your reader, you need to know who your reader is. There is more than one, and they arrive in a fixed order.

This lesson follows one application through a typical company. First the stages, then the three human readers and what each is looking for, and finally the software that sits in front of all of them — the part of the process with the most folklore attached.

The stages, end to end

Here is what happens to an application at a typical mid-size or large technology company. In order:

1. Apply — you submit your resume through a careers page, a referral, or a recruiter.
2. ATS — the applicant tracking system parses and stores it.
3. Recruiter screen — a recruiter reads the resume and decides whether to call you.
4. Recruiter call — a short conversation about the role, your background, level and logistics.
5. Hiring manager review — an engineer or engineering manager reads the resume more slowly, for scope and fit.
6. Technical screen — a first technical interview, usually coding.
7. Interview loop, debrief and offer — the full set of interviews, the interviewers' discussion, then the decision.

Smaller companies collapse stages — at a twenty-person startup the hiring manager may be the first and only reader. Larger ones add stages, such as a separate recruiter sourcing step or a hiring committee after the debrief.

Where the resume is read

The resume is not read once. It is read at four points.

After the interview loop begins, the resume stops mattering. Its entire influence is spent in the first four rows of that table. So your resume is read four times by three different kinds of reader, all before your first technical interview.

Who reads it, and what each one wants

This is the most useful idea in this section: your three readers want different things, and several of the arguments people have about resume advice come from imagining only one of them.

The recruiter

Time spent: seconds. Volume: possibly hundreds of resumes for one role.

A recruiter is usually not an engineer. They are matching against a requisition: the job's required years of experience, its must-have technologies, its location and work authorisation constraints, and its level.

What helps them:

• A clear, standard job title. "Software Engineer II" is instantly legible. "Code Ninja" is not, and it is not charming — it is friction.
• Technologies named plainly, in the roles where you used them.
• Dates that are easy to read and add up.
• Your location, or explicit willingness to relocate.

What hurts them: anything that requires interpretation. A recruiter who cannot tell what level you are will usually move on rather than investigate.

The hiring manager

Time spent: around a minute. Volume: a shortlist, maybe ten to thirty.

This reader is technical. They are not checking whether you have used PostgreSQL. They are asking whether you operate at the level they need.

They read for three things:

1. Scope — how big was the thing you were responsible for? One feature, one service, one system, or several teams' worth of architecture?
2. Ownership — did you decide, or were you told? Did you own the outcome or just the task?
3. Ambiguity — was the problem given to you well-defined, or did you have to work out what the problem even was?

Almost every "this candidate seems more junior than their title suggests" judgement comes from a resume that is strong on activity and silent on these three.

The interviewer

Time spent: a few minutes, often just before the interview. Volume: one — yours.

They are mining your resume for questions. A project described in a way that invites a follow-up is doing you a favour, provided you can answer it.

What an ATS actually does

Before any of those people see your resume, software does. There is a great deal of folklore about applicant tracking systems, and most of it leads people to do harmful things to their resumes. Here is what is actually going on.

What it does

An ATS is a database with a parser in front of it. When you apply, it:

1. Parses your file, trying to extract structured fields — name, email, employers, job titles, dates, education, skills.
2. Stores the parsed fields alongside the original document.
3. Lets recruiters search and filter. A recruiter might search for "Kubernetes" and "Golang" across the applicant pool, or filter to candidates with five or more years of experience.

Some systems add keyword-match scoring against the job description, and some auto-reject on knockout questions such as work authorisation. But the core function is search, not judgement.

What it does not do

What this means for you

The real risk is not being scored badly. It is being parsed badly, so that your experience never appears in the searches that would have found you.

If the parser reads your two-column layout in the wrong order, your skills may end up attached to the wrong employer, or your job titles may not be extracted at all. You are then absent from a search you should have matched.

So the practical rules are about parseability, and they are all in Section 4 (Tech Resume Basics):

• One column for the main content flow.
• Standard section headings: Experience, Education, Skills. Not Where I've Been.
• No critical information inside tables, text boxes, headers, footers, or images.
• Real selectable text, never a scan or screenshot of a document.
• Dates in a consistent, ordinary format.