The Title-Translation Read: Claimed Level, Bracket, or One Down

This is the read I run before an interview loop is booked, when a candidate's title comes from an employer whose ladder I do not know. It is for engineering managers, technical founders, developer-relations leads, and technical sourcers who have to decide what level the loop should be calibrated to. It gives you six scored dimensions, a rule that turns the score into one of three loop levels, and a one-page record that names the evidence that would flip the call.

What does the title-translation read decide?

It decides which level on your ladder the interview loop is calibrated to. The answer is one of three outcomes: at the claimed level, a two-level bracket, or one level down. The read translates the employer's title into your ladder before the loop runs. It does not grade the candidate's own work. That is the loop's job.

Three terms, defined once:

• Claimed level: the level on your ladder that the candidate's current title maps to at face value. A "Staff Software Engineer" claims your Staff level.
• Bracket loop: one loop designed to land at either the claimed level or the level below. At least one session is calibrated to the claimed level, so the candidate has a real chance to show it.
• One down: a loop calibrated entirely to the level below the claimed one.

Sources disagree about when the level is really set. Gergely Orosz writes that interview performance "is the most common reason for down leveling", which puts the decision after the loop. Stefan Mai of Hello Interview says "usually you're interviewing for a specific level", which puts it before. A third account notes that "recruiters often run a single loop that can land at two adjacent levels".

I read all three as one mechanism seen from different sides. The way the loop is calibrated limits the evidence the debrief gets to see. So the level you set before the loop is the ceiling, even when the debrief makes the final call. That is why this read happens before booking, and why the bracket is one of the outcomes.

Why does the same title mean different scopes at different employers?

A title only means something next to the ladder that issued it, because every employer writes its own scope sentences, promotion gates, and level names. Two people with the same title can sit two levels apart on your ladder, in either direction.

The public reference ladders show the spread plainly:

Dropbox's IC5 line reads: "I set the multi-year, multi-team technical strategy and deliver it through direct implementation or broad technical leadership." GitLab's Staff "generally operates at a team level scope, serving as the technical leader for one or more of their team's domains." Both are honest ladders. They describe different jobs under the same word.

Titles can also understate a level. Dropbox titles IC1 to IC4 all as "Software Engineer", yet levels.fyi lists the Dropbox IC4 median total compensation at $468,940. A secondary source reports that Amazon's L6 is titled "Senior Software Engineer". If you take titles from employers like these at face value, the candidate looks a level lower than they are.

Titles also drift upward across the market. Datapeople reported "a 100% increase between 2019 and 2021 in job titles that included 'Lead' or 'Principal,' and a 25% increase in titles that included 'Senior.'" Title inflation on that scale is why a static company-to-company equivalence table goes stale even if it was right when someone wrote it.

The six dimensions and how to score each

Score each dimension -1, 0, or +1 against the claimed level. +1 supports the claimed level, 0 is neutral or unknown, and -1 points one level down. Five dimensions read the employer. Evidenced scope reads the person, and it counts double.

1. Employer ladder visibility

Check whether the employer publishes a ladder. Look at its own handbook, at the collections on progression.fyi (which include Monzo, Etsy, and Rent the Runway) and the bmoeskau/engineering-ladders list on GitHub, and at the level names levels.fyi maps for that employer.

• What it proves: the employer has a written scope sentence for the candidate's title, and you can compare it with your own.
• How it lies: a public ladder looks rigorous, which tempts you to match titles. GitLab Staff and Dropbox Staff share a word but differ in scope by design.
• Scoring note: a rigorous public ladder whose scope sentence is narrower than your level still scores -1.

2. Engineering headcount when the title was granted

Estimate how many engineers the employer had on the date it granted the title, not today. Will Larson's StaffEng archetypes give the anchor: "The Architect and Right Hand roles have generally emerged as the organizations reached one hundred and one thousand engineers, respectively." Larson also calls the Tech Lead "the most accessible archetype to attain your first Staff engineering role".

• What it proves: which kinds of Staff scope were possible at all. A Staff title granted below about 100 engineers can only reflect Tech Lead or Solver scope.
• How it lies: today's headcount makes an early grant look legitimate. A Staff title granted at 20 engineers looks like a big-company title once the company has grown. Date the grant from funding rounds or archived team pages.
• Scoring note: this dimension matters most for Staff and above. If your Staff level is team-scoped Tech Lead work, a small employer at grant scores 0. If your Staff level expects cross-org architecture, it scores -1. For Senior claims it usually scores 0.

3. Senior-title density at the employer

Count the Senior, Staff, and Principal titles among the employer's engineers and compare the mix with two benchmarks. Refolk lets you ask for a named employer's engineers in plain English and count titles across the profiles that come back. That replaces a slow manual search with a short tally.

Levels.fyi adds a ceiling. Of its multi-team tier it says "typically less than 30% of employees in a company are at this level", and of its org-spanning tier, "less than 10%".

• What it proves: whether the employer's titles are distributed anything like the market's. An employer whose engineers are mostly Staff and above falls outside both ratios, and that points to inflation.
• How it lies: index counts include stale and drifted titles, and a substring search for "Staff Software Engineer" can also match "Senior Staff". At small employers the counts are too small to mean much.
• Scoring note: if you can count fewer than about a dozen engineers, score 0. Senior-title density broken down by employer size is not published anywhere, and I cannot filter Refolk's index by employer size, so this is a count you make per employer.

Use the candidate's own market as the benchmark. Staff counts and their concentration differ sharply by country:

4. Time-to-title

Compare how long the candidate took to reach the title with the large-employer benchmark: "after 4 years as a software engineer to become senior, it takes another 4 years to become a staff engineer." Practitioner consensus puts Staff at 7-10 years, with the note that "some startups hand out Staff earlier, while in FAANG it's more rigid". For earlier levels, levels.fyi says Meta E3 engineers "typically have 1 - 2 years of experience" and E4 engineers "typically have 3 - 4 years".

• What it proves: whether the climb was unusually fast, which is worth asking about.
• How it lies: in both directions. Under-titling at big tech makes a slow climb look weak, and a fast title at a small company is not inflation by default. GitLab requires "a position of need" for promotion from Senior to Staff, so a long-tenured Senior there may be capped by headcount, not by ability.
• Scoring note: the 4+4 benchmark is derived from years spent at the current level, not from observed promotion dates, and no median exists for small startups. Treat it as a coarse yardstick. A fast climb alone scores 0. Keep -1 for Staff or above within about 4 years of starting as an engineer.

5. Evidenced scope (counts double)

Find out in the screen what the person defined, owned, and delivered. One practitioner rubric draws the line cleanly: Senior is "given a problem, designs and delivers the solution", and Staff is "given a business goal, defines the problem". Dropbox adds multi-year, multi-team goals and defining both the "what" and the "how".

• What it proves: it is the only dimension about the person rather than the employer, which is why it counts double.
• How it lies: Tech Lead work can look like Staff work. Someone who ran a team's delivery end to end can describe it in Staff vocabulary even though every problem was handed to them.
• Scoring note: none of the rubrics I found names design docs, on-call severity, or decisions made without approval as explicit separators. Ask about them if they help the conversation, but do not score on them.

6. Posted pay band for that title

Pull the employer's posted ranges for the same title from job postings in states that require a range in the posting itself.

Colorado's law also covers "remote roles that could be performed by a Colorado resident", so remote postings can surface a range even when the employer has no office there.

An analysis of 11,746 public postings puts the Staff median at $225K, "$36K (+19%) more than a Senior Software Engineer at $189K". Meanwhile, "Compensation for the same job title can differ by up to 3 to 5 times across different 'tiers' of companies." A later secondary write-up puts that spread at 2 to 4 times, so the sources conflict.

• What it proves: mostly the employer's tier. Pay varies far more across employers than between adjacent levels, so a posted band is stronger evidence about the employer than about the candidate's level.
• How it lies: medians can invert. Levels.fyi lists Visa's Associate Software Engineer L3 at $128K and its Software Engineer L4 at $122K. Wide ranges overlap two levels. One compliance guide reports that under a California clarification, "broad, placeholder, or unrealistic ranges may be treated as non-compliant", which tells you such ranges exist.
• Scoring note: compare base pay only, at the same employer and in the same metro. A range that covers two of your levels scores 0.

How does the score become a loop level?

Add the six scores, doubling evidenced scope, for a total between -7 and +7, then apply three rules. Only evidence about the person can rule out the claimed level. Employer signals alone can move the loop to a bracket, never to one down.

1. Claimed level: the total is +4 or higher and evidenced scope is +1.
2. One down: the total is -3 or lower and evidenced scope is -1.
3. Bracket: everything else. Book the claimed level and the level below, with at least one session calibrated to the claimed level.

These thresholds are my own working calibration, not a validated model. No public source gives a downleveling or upleveling rate to tune them against. Track your own outcomes, and move the cut-offs if your brackets keep landing the same way.

Here is an illustrative case. A "Staff Software Engineer" title was granted at a startup when it had about 20 engineers, within 4 years of the candidate starting out:

• No public ladder: 0.
• Your Staff level expects multi-team strategy, which could not exist at 20 engineers: -1.
• More than half of the engineers you can count hold Staff or above: -1.
• Staff within 4 years: -1.
• No posting in the four states: 0.
• In the screen, every project they describe was handed to them by a founder: -1, doubled to -2.

The total is -5 with scope at -1, so the loop goes one down. Now change one input. Suppose in the screen they explain how they turned a revenue goal into a cross-team migration plan. Scope moves to +1, doubled to +2, the total becomes -1, and the result is a bracket. Naming that kind of flip in advance is what the record is for.

The quickest sanity check on a translation is to find people who already made the same move and see where an employer with a public ladder placed them. Refolk returns that calibration set from one sentence:

Step-by-step: scoring one candidate before the loop is booked

Eight steps, split between the sourcer and the hiring manager, take one candidate from a title on a profile to a recorded loop level. My time estimates are unmeasured desk figures: about 10 to 15 minutes for each sourcer step and about 30 minutes for the screen.

Use this record for every candidate and keep it with the loop plan, so the debrief can see what the level was based on.

Candidate:
Current title and employer:
Date title granted:
Claimed level on our ladder:

Dimension                  Score (-1 / 0 / +1)   Evidence and source
1 Ladder visibility
2 Headcount at grant
3 Senior-title density
4 Time-to-title
5 Evidenced scope (x2)
6 Posted pay band
Total (-7 to +7):

Loop level: Claimed / Bracket (claimed and one down) / One down
Evidence that would move it up:
Evidence that would move it down:
Recorded by and date:

The screen questions below cover dimension 5 and fill gaps in dimensions 1 and 2. Ask them in this order so the candidate describes the work before you ask them to label it.

1. Walk me through the largest piece of work you led in your current role.
2. Who decided that work needed doing? Was the problem already defined when it reached you, or did you define it from a business goal?
3. How many teams had to change what they were doing because of it?
4. Over what time horizon did the plan run?
5. Did you decide what to build, how to build it, or both?
6. Roughly how many engineers did the company have when you were given your current title?
7. Does your company have a written ladder? How does it describe your level?

How the read goes wrong

The read usually fails by trusting a signal that looks rigorous: a public ladder, a current headcount, a raw title count, a fast or slow climb, a pay median, a Tech Lead story, or a narrow loop. Each one has a specific check.

1. Ladder visibility gives a false match. A public ladder looks rigorous, but GitLab's Staff is team-scoped and Dropbox's is multi-team. Matching titles across them gives a false positive. Check: compare the scope sentences, not the titles.
2. Headcount is taken today, not at grant. A Staff title granted at 20 engineers looks legitimate once the company is large. Check: date the grant against funding rounds or archived team pages.
3. Density counts include noise. Index counts include stale and drifted titles, and a substring search for "Staff Software Engineer" can also match "Senior Staff". Check: hand-sample the profiles before trusting the ratio.
4. Time-to-title is read without the employer's tier. Big-tech under-titling, such as Amazon's L6 being titled "Senior", makes a slow climb look like a weak record. A fast title at a small company is not inflation by default. Check: place the employer's tier before scoring the climb.
5. The pay band separates the wrong thing. Medians invert between levels, as with Visa's L3 at $128K against its L4 at $122K. Wide ranges overlap, and pay tiers differ by 3 to 5 times. Check: compare base pay only, at the same employer and in the same metro.
6. Tech Lead scope reads as Staff. Tech Lead work is the most accessible route to a first Staff role, and it sounds like Staff in a screen. Check: ask whether the candidate defined the problem or was handed it.
7. The narrow loop locks the level. A loop booked one level down cannot show the higher level, and a cautious debrief keeps the lower one. Mai describes the default as "What if we extend them an offer at a level that we have more evidence for?" Check: use a bracket loop whenever the evidence is split.

The seventh failure deserves a picture, because it is the one the debrief cannot fix.

Policy shifts are a related trap. Pragmatic Engineer coverage of the interview market reported "candidates routinely receiving offers a level below their current position, particularly at the senior and staff levels". It also reported one Meta senior offer that was withdrawn and replaced with a mid-level offer under "a new policy requiring candidates to have at least six years of experience for senior positions". When you read a candidate's past down-level or up-level at another employer, ask whether a policy drove it rather than the person.

Translate the employer's ladder before you judge the person, because a title is written in someone else's grammar.

What the evidence does not establish

The framework rests on some thin ground, and you should know where before you defend a level with it.

• How often downleveling happens. No source gives a rate, and I found no published account of upleveling rates either. My thresholds cannot be tuned against a public baseline.
• Senior-title density by employer size. It is not published, and Refolk's index cannot filter by employer size. The 5.5:1 and 3.6:1 ratios are market-wide benchmarks, not size-band norms.
• Time-to-title at small startups. No median is published. The 4+4 benchmark comes from large employers and is derived from years at the current level, not from observed promotions.
• Whether posted ranges separate levels. That is not established publicly. Treat a posted range as evidence of tier first.
• The size of the pay spread across tiers. One source says 3 to 5 times and a later secondary write-up says 2 to 4 times. Either way it dwarfs the 19% Senior-to-Staff gap, which is the point that matters here.
• The worked thresholds. The -1/0/+1 cut-offs, the doubled scope score, and the +4 and -3 boundaries are my judgement. Keep your own outcome log to test them locally: pre-loop level, final level, and whether the higher-level session changed the result.

How do I keep the read current?

Re-check the inputs that move, not the framework. Ladders get rewritten, pay-law coverage changes, title distributions drift, and your own outcomes should reset the thresholds.

• Ladders: re-open the primary ladder page each time you cite it. Do not rely on a copy saved months ago or on a third-party summary.
• Pay-law coverage: before relying on a state's postings, check its current employee threshold and what counts as a compliant range. The California clarification on placeholder ranges shows that the rules tighten over time.
• Density benchmarks: re-count the Senior and Staff totals for your market periodically. The US figure of 5.5:1 and the UK Staff count of 2,182 are snapshots of Refolk's index, not constants.
• Your thresholds: review your outcome log each quarter. If brackets keep landing at the claimed level, lower the claimed-level cut-off. If they keep landing one down, look at whether your screens are thin before you change anything.