The Interview Loop Map, Rebuilt From Public Reports for One Employer

This is the read I run on a target employer before applying or saying yes to the first call: how many rounds, how many days from first interview to offer, what each round tests, and whether a take-home is likely. It is for job seekers with a shortlist who want a dated loop map instead of a vague impression. I carry one software engineering candidate through every filter, count and wrong turn, so you can run the same read on your own list in under an hour.

Which clock a loop length runs on

A loop length means nothing until you name its clock, meaning the event that starts it and the event that ends it. Public figures start at a requisition, an application or a first interview, and end at an offer, a hire or an acceptance, so two honest numbers for the same employer can sit weeks apart.

A loop map is the deliverable here: a one-page, dated record of one employer's process for one role family, holding the assessed round count, expected days from first interview to offer, a take-home flag and a confidence level. The clock is the first field you fill, because every later comparison depends on it.

Here is the full set of public benchmarks I use, sorted by clock.

Two limits apply to this table. First, no public benchmark measures first interview to offer, which is the clock a candidate cares about most. Ashby's first-to-last interview figure is the closest, and you add offer turnaround on top. Second, I found the Ashby loop figures only through secondary write-ups, not on Ashby's own report page, so check the primary Ashby Talent Trends Report before you quote them anywhere that matters.

The procedure, from careers page to a dated loop map

The read has eight steps and should take about an hour. The official page comes first, then the aggregator counts narrowed by role and recency, then stage and take-home calls, one recruiter question, and a same-clock comparison. The time budgets are my own proposal to fit the hour; no source publishes them.

The worked example is a software engineer with two employers on their list, and I use each one where its public record is complete. Glassdoor reviewed as an employer (I'll call it Glassdoor-as-employer) supplies the count filters, because its public interview pages show the report count behind every average. GitLab supplies the stage-count and take-home forks, because its candidate handbook is public and third-party guides disagree with it. I would rather split the example honestly across two employers than make up counts for one.

Report counts after each filter, worked on one employer

Each filter cuts the report count and moves the average, and the role-level figure can be half the company figure. On Glassdoor-as-employer, the company-wide average is 24 days on 1,301 reports, while the software engineer average is 12 days on 27 reports.

These are the cuts the candidate saw, with the count behind each.

Step 2: the headline, and the first wrong turn

The candidate's first instinct was to take "24 days" as the answer. That figure blends every role family the company hires for, including a Senior Product Manager process reported at 120 days. One slow, senior track can drag a company average a long way, and the headline tells you nothing about which track you are on.

The second wrong turn was the regional page. The .ca version of the same employer shows 21 days, which looks like a second opinion confirming the first. It rests on 12 reports. It is not a confirmation. It is a smaller, noisier sample of the same blend.

Step 3: the role filter

Filtering to Software Engineer leaves 27 reports and a 12-day average. That is the figure the rest of the read builds on. The Help Desk row is the cautionary twin: 6 days, displayed with the same confidence as everything else, on 2 reports.

Step 4: the recency filter

The role page does not publish a recency-filtered average, so you count by hand. Open the 27 software engineer reports, keep those dated within the last 12 months, and write down how many survive. Whatever the result, it can be no more than 27. If it falls under 10, the practitioner floor for role-filtered recent reviews, the estimate is low confidence no matter how tidy the average looks.

Sources disagree on order. One practitioner guide filters by role first, then recency. I do the same for a practical reason: dating 27 reports by hand is fast, and dating 1,301 is not. The final set is the same either way.

No published threshold says when an interview-length estimate stabilises. Glassdoor's own difficulty ranking once required at least 20 ratings per company, and practitioners suggest 10 to 15 role-filtered reviews from the last 12 months. Treat 10 as a floor, not proof.

Settling a stage count when sources disagree

Count only the events where you are assessed, and the disagreement usually goes away. Employer stage lists include administrative stages such as references and the offer, while candidates count interviews, so both sides can be right about different things.

GitLab is the clean example. Here is what the candidate found.

The wrong turn: picking the bigger, more official number

The candidate's first read was "7 rounds, official source, done." The handbook is authoritative about the process, but it is not a round count. Remove the reference check and the offer and the handbook comes down to 5 events, which agrees with "four to five" and "5 rounds." The 4-step list most likely groups two sessions together. You cannot confirm that without the report text, so write the reconciled answer as a mode and a range: 5 assessed rounds, range 4 to 5.

A stage list from the employer and a round count from candidates are answering different questions.

What to tally from each report

For each surviving role-matched report, write one line: date, outcome (offer or no offer), number of assessed events, and anything unsupervised. Keep offer and no-offer reports in separate columns. Candidates who received offers rate the process more warmly, so a pile of glowing short loops may just be a pile of winners.

A third-party GitLab guide says it draws on 672 candidate reports. That number tells you nothing about your role or the last 12 months unless the guide shows its split, so it does not replace your own tally.

Market reference for round counts

Secondary write-ups of Ashby's data put typical loops at about 4 rounds per business hire and 5 per technical hire, and a ZipRecruiter survey of recent hires found a median of 5 interviews. Do not confuse these with "interviews per hire." Ashby's 17.6 per technical hire counts candidates interviewed, and Gem's figure of 20 counts interview sessions across all candidates. Neither is the number of rounds you will sit.

Setting the take-home flag

Mark a take-home as likely only when the official page or several recent role-matched reports show one, and define it before you look. My definition: a take-home is unsupervised work you complete before a session. Anything done live with an interviewer watching is a technical interview, however it is labelled.

The flag takes one of three values:

• Likely: the official page names it for your role, or several recent role-matched reports describe it.
• Unlikely: the official page describes every assessed stage and none is unsupervised, and recent reports agree.
• Unknown: the page says assessments vary by role and the reports are thin or split. Ask the recruiter.

The GitLab fork

GitLab's handbook says an assessment is "required for certain roles," so the official page alone gives you unknown. The harder part is the merge request review. Some third-party guides call it a take-home. The handbook places it inside the technical interview. Under the definition above, the answer depends on one fact: is the review done alone before the session, or live within it? Recent role-matched reports are where you settle that. If they disagree, the flag stays unknown and goes into the recruiter question.

When the page does answer it

Some employers are explicit by role. Atlassian names a coding test for graduate software engineers and a take-home case study for graduate product managers. In that case the flag is likely for those tracks and the reports only confirm the format. Other employers, Gartner and GM among them, say only that the process varies by role. Treat that wording as unknown, not unlikely.

The recruiter question, and who is answering it

One question at the first call, covering stages, format, timeline and whether the recruiter is in-house, closes most of the gaps the public record leaves. How much the answer is worth depends on who gives it: an in-house recruiter knows the loop, and an agency recruiter may only know the client's summary of it.

Practitioner guides agree recruiters can usually give the stages, the format of each round, the timeline and who decides. They usually cannot describe what a strong performance looks like in each round, so do not spend the question on that. One guide treats a recruiter who cannot describe the timeline as a sign they have not spoken to the hiring manager recently. Log that as a finding, not as a failed call.

Before we book the next step, could you walk me through the rest of the process for this role? Specifically:
1. How many interviews are there after this call, and what format is each one?
2. Is there any work I'd complete on my own before one of the sessions?
3. Roughly how long from this call to a decision, and from the final interview to an offer?
4. Are you in-house at the company, or working with them as a recruiting partner?

Who is on the other end of the call

In Refolk's index of professional profiles, technical recruiting is a large and uneven population.

Three things from these figures affect how you use the answer:

• Agency recruiters are common. In both 25-profile samples, US and UK, 20 of 25 held the exact title, and staffing firms appeared among the top employers (Randstad Digital in the UK sample). That is why question 4 is in the template.
• Coordinators are thin relative to recruiters. There are about 0.31 US coordinators per technical recruiter, roughly one for every three recruiters. In many loops the person you talk to also books the rounds, so the timeline they give you is a scheduling estimate as much as a process fact.
• The UK count is likely too low. UK firms often use "Recruitment Consultant" as the title, so the roughly 29.9x US-to-UK ratio overstates the gap. Do not read it as a scarcity of UK recruiters.

Is a 6 week interview process normal? Comparing on the same clock

Six weeks is normal if it starts at application and slow if it starts at the first interview. Forty-two days from application sits near Ashby's 40-day technical median, but 42 days from first interview is more than double the 17.9-day technical loop.

The same reasoning covers any loop length. Business roles are tighter: 42 days from application is about 1.4x Ashby's 30-day business median, and 42 days from first interview is nearly three times the 14.4-day business loop. Sector matters too. Glassdoor's UK data puts the average at 27 days, with consulting the longest at 55, so a long consulting loop may be normal for consulting and still slow against the overall market.

Converting the worked example

The software engineer's figure is 12 days on 27 reports. The clock behind a candidate-reported average is not defined on the role page, so I treat it as the clock Glassdoor used in its own published study: application to offer or rejection. That is an assumption, and it goes on the map in writing.

Now convert:

1. The start event. SmartRecruiters data puts the interview stage at about day 14 after application, with median hire at day 38. A 12-day average cannot contain a 14-day wait before the first interview, which suggests many reporters started counting at first contact, not at application. Either way, days from first interview to outcome can be no more than 12.
2. The end event. The figure includes rejections, not just offers, so it is not a pure time to offer. Note it and move on.
3. The comparison. Ashby's technical first-to-last interview figure is 17.9 days, and offer turnaround comes on top of that. Even at its upper bound of 12, this loop finishes faster than the benchmark loop alone.
4. The verdict. Fast against the market, on the same clock.

The confidence level is the honest part. The 27 reports have not yet been filtered for recency, the clock is assumed, and the figure mixes outcomes. That makes it low to medium until the recency count clears 10 and the recruiter's timeline agrees.

A fast loop leaves less room between the screen and the final round, so your materials need to be ready before you apply, not after the first call. Refolk tailors the resume to each posting and scores how well you fit, so you can decide whether a 12-day loop is worth starting before the clock begins.

How this read goes wrong

Most bad loop estimates come from eight failure modes, and each has a one-line check. These are worth more than the procedure, because a confident wrong map does more harm than having none.

1. Clock mismatch. An application-to-offer aggregator figure is set against a first-to-last interview benchmark, and the loop looks slow when it is not. What it looks like: "24 days, but the benchmark says 17.9, so they're slow." Check: write both clocks beside both numbers before comparing.
2. The same figure meaning three things. "17.9" is quoted as days from first to last interview, as interviews per engineering hire, and as candidates interviewed per hire. What it looks like: a benchmark that fits your argument a little too neatly. Check: confirm the unit against Ashby's primary page.
3. Role mixing. The company-wide 24 days hides a 12-day software engineer figure and a 120-day senior product track. What it looks like: a single headline number with no role attached. Check: always quote the role-level N.
4. Tiny N shown as an average. A 6-day Help Desk average rests on 2 reports. What it looks like: a clean, specific number on a role with few reviews. Check: under 10 recent role-matched reports, mark confidence low.
5. Stage-count inflation or deflation. GitLab's handbook lists 7 stages, while candidates report 4 to 5. What it looks like: the official list feels more rigorous, so it wins. Check: count only events where you are assessed.
6. Take-home ambiguity. GitLab's merge request review is a take-home in one guide and part of the technical interview in another. What it looks like: two sources that seem to contradict each other. Check: apply the definition, unsupervised work done before a session, and read the report text.
7. Extreme-reviewer skew. Voluntary reviews over-represent extreme experiences, an effect Marinescu and coauthors measured against reviews prompted by an incentive. One study found 37.7% five-star reviews on Glassdoor against 22.0% on Blind, which verifies reviewers. Huyen's analysis found offer acceptance of 87.5% after a positive interview experience and 33.8% after a negative one, so experience and outcome travel together. What it looks like: a warm, short-loop consensus. Check: separate offer and no-offer reports before you average anything.
8. Agency recruiter answers. Staffing firms rank among the top employers of technical recruiters in Refolk's index, and an agency recruiter may not know the client's loop. What it looks like: a confident timeline that later slips. Check: ask whether the recruiter is in-house.

Two biases have not been measured for interview reports specifically: recency skew and role mixing within a role filter. Nobody has published how much stale or mislabelled reports distort these averages. The recency filter and the report-by-report tally are how you check it on your own case.

Keeping the loop map current

A loop map is a dated snapshot, not a profile. Re-read it before each application to that employer and whenever the posting, the role family or the recruiter changes. Aggregator pages, careers pages and handbooks are all edited without notice, so the date you read each source is part of the evidence.

Keep one record per employer and role family, in this shape.

LOOP MAP: [Employer] / [Role family] / read on [date]
Official process: [N stages] from [page], read [date]; role-dependent notes: [ ]
Reports: raw [N] at [avg] days / role-matched [N] at [avg] days / last 12 months [N]
Outcome split: offer [N] / no offer [N]
Assessed rounds: mode [ ] / range [ ] (references and offer removed)
Take-home: likely / unlikely / unknown; evidence: [ ]
Aggregator clock: [start event] to [end event] (assumed or stated: [ ])
Recruiter said: stages [ ] / format [ ] / timeline [ ] / in-house: yes / no
Estimate: first interview to offer, about [ ] days
Benchmark: Ashby first to last interview, [14.4 business / 17.9 technical] days, plus offer turnaround
Verdict: fast / in line / slow
Confidence: high / medium / low, because [ ]
Re-check by: [date or trigger]

Run this read across a shortlist and you have a sequencing tool. Start the slow, many-round loops first and the fast ones later, so offers land close together. When the map shows a fast loop with a likely take-home, have the tailored resume and cover letter done before you apply. Refolk drafts both from your own history for each posting, so the prep fits inside the loop instead of falling behind it.