Tech Interview Preparation Module 1 – How tech hiring works
Levels, titles and role families
How engineering ladders describe levels, why titles do not transfer between employers, how loops grow with level, and how role families change the rounds.
What you will learn
- Read a public engineering ladder and place your experience on it
- Translate a title from one employer into scope that another employer can compare
- Explain how the target level changes the number and depth of rounds
- Recognise down-levelling and discuss level with a recruiter
- Compare how front-end, security and other role-family loops differ from a generalist loop
Before you start
What you’ll learn · Before you start
What you will learn
- Read a public engineering ladder and place your experience on it
- Translate a title from one employer into scope that another employer can compare
- Explain how the target level changes the number and depth of rounds
- Recognise down-levelling and discuss level with a recruiter
- Compare how front-end, security and other role-family loops differ from a generalist loop
Before you start
On this page
Amazon’s SDE II loop has four 55-minute interviews, and its senior SDE III loop has five, after a 60-minute phone screen with a senior leader: the level you are interviewed for changes the rounds. A level is an employer’s measure of the scope you are trusted with: how large and how open-ended your problems are, how much guidance you need, and how far your influence reaches.
Titles are labels on top of levels, and employers name their levels differently, so a title from one company says little at another: compare scope, never titles. Public career ladder: An employer's description of what is expected of an engineer at each level, also called a career framework. It describes each level by the scope of the work, the guidance needed and how far its influence reaches. make this concrete, and role family: A group of related roles that share a ladder and the same interview foundations, such as front-end, security or reliability engineering, each adding rounds of its own. such as front-end or security engineering add rounds of their own. What follows shows how to read a ladder, place yourself on it, and talk about level with a recruiter.
Not affiliated
MySmartCoPilot is independent of Dropbox, GitLab, Amazon, Meta and Atlassian. What this lesson says about their ladders and interviews comes from their own public pages, listed under References. The six-level ladder used for practice here is this track’s own synthesis, not any employer’s.
A ladder describes each level by scope, guidance and reach
A career ladder, or career framework, describes what is expected of an engineer at each level. Dropbox publishes its framework, and says what separates the levels: level expectations define the scope, the collaborative reach and the levers for impact at each level, while core and craft responsibilities describe the behaviours that deliver it. It also warns that the framework is not a promotion checklist. Read from the bottom, the summary lines of its software engineer levels tell one story of growing scope:
- IC1 delivers high-quality production code for defined tasks, with direction from the team.
- IC2 carries defined projects to team goals, with high-level guidance, and may mentor new hires and interns.
- IC3 independently finds and delivers solutions across a product area or a system of several components, solves ambiguous, open-ended problems and helps less experienced engineers grow.
- IC4 delivers ongoing impact across a team, a product capability or a technical system, with an influence that begins to reach other teams.
- IC5 Staff sets technical strategy across several teams over several years.
- IC6 Principal delivers results against a company-level objective.
GitLab’s job family for backend engineers grows the same way in fewer words: problems of moderate scope and complexity, then of high scope and complexity at Senior, then of the highest scope and complexity for the team at Staff, with mentoring that widens from the engineers below you to everyone on the team.
This track uses a generic six-level ladder for practice. It loosely follows the public ladders above, and it is the ladder the program further down rates you on. Read the diagram from the bottom up; each arrow names what grows from one level to the next:
This track's generic six-level ladder, from the bottom up
Text description of the diagram
The diagram is a column of six boxes joined by arrows, from the bottom to the top:
- L1 Entry: defined tasks, done with guidance.
- An arrow labelled "more scope" leads to L2 Engineer: features and defined problems, done alone.
- An arrow labelled "less guidance" leads to L3 Senior: ambiguous projects, and mentoring others.
- An arrow labelled "reach beyond the team" leads to L4 Senior lead: a team's goals or a whole system.
- An arrow labelled "several teams, longer horizons" leads to L5 Staff: direction across several teams.
- An arrow labelled "the whole organisation" leads to L6 Principal: an organisation's objectives.
The ladder is a study aid that loosely follows public engineering ladders; every employer has its own levels and names.
| Level | The work you own | How much guidance | How far your influence reaches |
|---|---|---|---|
| L1 Entry | Defined tasks | Direction from the team | Your own work |
| L2 Engineer | Features and defined problems | High-level guidance | Your team |
| L3 Senior | Projects with milestones, open-ended problems | You work independently and mentor others | Your team and the partners of your projects |
| L4 Senior lead | A team’s yearly goals, a product capability or a system | You set direction for the team | Beginning to reach other teams |
| L5 Staff | Technical direction across several teams | You define what is done as well as how | The roadmaps of other teams |
| L6 Principal | An organisation’s objectives | You set direction for a group of teams | The whole organisation |
Checkpoint
Check: What a ladder describes
Titles do not transfer between employers
Every employer names its levels in its own way, and the same word can sit at different heights on two ladders:
| Employer | How its pages name the levels | Where “senior” sits |
|---|---|---|
| Amazon | Numbered roles such as SDE II and SDE III | Its hiring pages describe SDE III as a senior software development engineer role |
| Dropbox | IC1 to IC7, with IC1 to IC4 all titled Software Engineer, then Staff, Principal and Senior Principal | No level carries the word: the title first changes at IC5, Staff |
| GitLab | Names such as Intermediate, Senior and Staff in its backend job family | A level of its own, and the one it prefers to hire into before Staff |
Each employer’s pages describe only its own levels, so a title on your current offer letter tells a new employer little. Two Dropbox engineers at IC2 and IC4 share one title, and a “senior” at one company may own less than a plain “software engineer” at another.
Compare scope instead. Before applying, read the job description and, where the employer publishes one, its ladder, and describe your own work in the same terms: the size of the problems you owned, how much of the design was yours, and who changed what they did because of your work. Then ask the recruiter which level the role is hired at and what that level is expected to show.
Checkpoint
Check: Titles across employers
The target level changes the loop
The clearest public example of level changing a loop is one job family at Amazon, from new graduate to senior:
| Role | Before the loop | The loop |
|---|---|---|
| New-graduate SDE (and interns) | The first step is an online assessment: two coding problems in about 70 minutes on average, then work-style questions for everyone; full-time roles add a work simulation outside a few countries, and interns need about 90 minutes in all | An email after each section says whether you move to the next step |
| SDE II | An online assessment: 90 minutes for two coding questions, 20 minutes of system design scenarios and an 8-minute work style survey | Four 55-minute interviews, with at least one question on software system design |
| SDE III, a senior role | A 60-minute technical phone screen with a senior leader, half on the Leadership Principles and half on coding and system design | Five 55-minute interviews |
The design questions change with the level as well. The SDE II page asks candidates to clarify requirements, plan for twice and ten times the growth and justify trade-offs; the SDE III page frames system design as an ambiguous problem given in a single line, to be split into five to seven high-level blocks.
This track sums up the pattern of the public ladders and prep pages in four steps, from entry level to staff. It is a study aid, and an employer’s page for your role always overrides it. Walk through the levels and watch the weight move from the coding round to the design and behavioural rounds:
- Entry level
Coding decides most of the outcome coding first
Coding is the main signal, with the weight on fundamentals, correctness and testing. Design questions are few or none. Behavioural questions are about learning and teamwork, told from school or internship projects or a first job.
- Mid level
Coding stays central, and design begins
Coding is still central, and cleaner design of the code is expected. A design round on a well-scoped system is common. Behavioural questions ask how you delivered features and owned your work.
- Senior
Open-ended design, and leading others scope probed
Coding is expected to be solid, gets less of the time and meets a higher bar. Design rounds bring open-ended problems, trade-offs with numbers and failure modes. Behavioural questions probe leading projects, mentoring and handling disagreement.
- Staff
Several systems, and influence across teams
Coding is expected to be solid but rarely decides the outcome alone. Design covers several systems, their cost, how they are run and how the design will change. Behavioural questions probe influence across teams and long-term technical direction.
The timeline has 4 events, from Entry level to Staff.
Prepare the behavioural round as carefully as the other two: at senior and staff level the behavioural questions probe scope, and a story about a task you were given answers a question about a lower level. Some employers are careful at the top of the ladder: GitLab says its Staff and higher positions are more of a role than a level, and that it prefers to hire people as Senior and let the team raise them to Staff on the strength of their work at GitLab.
Checkpoint
Check: How the loop changes with level
Place yourself on the ladder by evidence, never by an average
Rate yourself on twelve descriptors, each from 1 to 6, against the levels of this track’s ladder. Rate only work you have actually done and can describe with an example, never work you think you could do. The table gives the L1, L3 and L5 descriptions of each descriptor; use 2 and 4 for work between two columns, and 6 for work beyond L5.
| Descriptor | L1 | L3 | L5 |
|---|---|---|---|
| Scope | A task inside a feature | A project with milestones | Work that spans several teams for a year or more |
| Ambiguity | The problem and the solution are given | You define the solution to an open problem | You define the problem as well as the solution |
| Autonomy | Daily guidance | Independent, asking for help at the right moments | You set direction for others |
| Design | You implement designs | You design a component or system and defend it | You shape the architecture of several systems |
| Code | Correct code, with help in code review | Code others learn from | Patterns and standards other teams adopt |
| Testing | The tests you are asked to write | You decide what must be tested, and how | You set testing practice across teams |
| Operations | You follow the runbook | You own a service in production, alerts included | You change how several teams run their services |
| Delivery | Your tasks, on time | A project to its milestones | A programme of work across teams |
| Trade-offs | You follow decisions | You choose between designs and their costs | You decide with long-term costs to several teams |
| Mentoring | You learn from others | You mentor engineers on your team | You grow senior engineers and leads |
| Influence | Inside your team | The partner teams of your projects | The roadmaps of other teams |
| Communication | Clear updates on your work | Design documents and reviews | Strategy that leaders act on |
The program reads the ratings by one rule: a level is supported when at least 9 of the 12 ratings reach it and none is more than one level below it, and the band stretches one level higher when at least 6 ratings are already there. It never averages, because an average lets a strong descriptor hide a weak one, and the weak one is what an interviewer at the next level will probe. Here it rates three invented candidates:
// A practice estimate of the level band your evidence supports on this track's generic six-level ladder, L1 to L6
// (the lesson describes each level). Rate each descriptor from 1 to 6: the highest level whose description matches
// work you have actually done, with an example you could tell in an interview. Put your own ratings in a new
// show(...) line and press Run. This is a study aid; every employer levels candidates by its own ladder and loop.
const ROUNDS = ['coding rounds', 'design rounds', 'behavioural and hiring-manager rounds', 'every round'];
const DESCRIPTORS = [
// [name, the round where interviewers see it most (an index into ROUNDS)]
['scope', 2],
['ambiguity', 1],
['autonomy', 2],
['design', 1],
['code', 0],
['testing', 0],
['operations', 1],
['delivery', 2],
['trade-offs', 1],
['mentoring', 2],
['influence', 2],
['communication', 3],
];
// A level is supported when at least 9 of the 12 ratings reach it and none is more than one level below it. The band
// reaches one level higher when at least 6 ratings are already there.
const NEEDED = 9;
const STRETCH = 6;
function supports(ratings, level) {
return ratings.filter((r) => r >= level).length >= NEEDED && ratings.every((r) => r >= level - 1);
}
function band(ratings) {
let floor = 1;
for (let level = 2; level <= 6; level++) if (supports(ratings, level)) floor = level;
const top = floor < 6 && ratings.filter((r) => r >= floor + 1).length >= STRETCH ? floor + 1 : floor;
return { floor, top };
}
function show(who, ratings) {
if (ratings.length !== DESCRIPTORS.length || ratings.some((r) => !Number.isInteger(r) || r < 1 || r > 6)) {
console.log(`${who}: give 12 whole ratings from 1 to 6`);
return;
}
const { floor, top } = band(ratings);
console.log(who);
console.log(` band: ${floor === top ? `L${floor}` : `L${floor} to L${top}`}`);
if (floor === 6) {
console.log(' L6 is the top of the ladder');
return;
}
// The next level, and what stands between the ratings and it.
const next = floor + 1;
const reached = ratings.filter((r) => r >= next).length;
const tooLow = DESCRIPTORS.filter((d, i) => ratings[i] < next - 1).map(([name]) => name);
const floorNote = tooLow.length ? `, and ${tooLow.join(', ')} ${tooLow.length === 1 ? 'is' : 'are'} below L${next - 1}` : '';
console.log(` L${next} as a firm target: ${reached} of 12 ratings there (${NEEDED} needed)${floorNote}`);
// The descriptors below that level, grouped by round: the round with the largest total gap comes first (then the
// one with the lowest rating), so the first line is where to put most practice and most stories.
const groups = ROUNDS.map((round, r) => {
const items = DESCRIPTORS.map(([name, at], i) => ({ name, at, rating: ratings[i] })).filter((d) => d.at === r && d.rating < next);
const gap = items.reduce((sum, d) => sum + (next - d.rating), 0);
const lowest = Math.min(...items.map((d) => d.rating));
return { round, r, items, gap, lowest };
}).filter((g) => g.items.length);
groups.sort((a, b) => b.gap - a.gap || a.lowest - b.lowest || a.r - b.r);
console.log(` below L${next}, by round:`);
for (const g of groups) console.log(` ${g.round}: ${g.items.map((d) => `${d.name} L${d.rating}`).join(', ')}`);
}
// Ratings in the order of DESCRIPTORS: scope, ambiguity, autonomy, design, code, testing, operations, delivery,
// trade-offs, mentoring, influence, communication.
show('Meera, final-year student', [1, 1, 1, 1, 2, 1, 1, 2, 1, 1, 1, 2]);
show('Karan, backend engineer, 3 years', [3, 2, 3, 2, 3, 3, 3, 3, 2, 2, 1, 3]);
show('Ananya, tech lead, 8 years', [4, 4, 5, 4, 4, 4, 5, 5, 4, 5, 3, 4]);Output
Meera, final-year student
band: L1
L2 as a firm target: 3 of 12 ratings there (9 needed)
below L2, by round:
design rounds: ambiguity L1, design L1, operations L1, trade-offs L1
behavioural and hiring-manager rounds: scope L1, autonomy L1, mentoring L1, influence L1
coding rounds: testing L1
Karan, backend engineer, 3 years
band: L2 to L3
L3 as a firm target: 7 of 12 ratings there (9 needed), and influence is below L2
below L3, by round:
behavioural and hiring-manager rounds: mentoring L2, influence L1
design rounds: ambiguity L2, design L2, trade-offs L2
Ananya, tech lead, 8 years
band: L4
L5 as a firm target: 4 of 12 ratings there (9 needed), and influence is below L4
below L5, by round:
behavioural and hiring-manager rounds: scope L4, influence L3
design rounds: ambiguity L4, design L4, trade-offs L4
coding rounds: code L4, testing L4
every round: communication L4
Recorded with Node.js 24.21.0 on macOS 26 arm64. To run it yourself: mise exec node@24.21.0 -- node level_band.mjs
Runs on this device, in your browser. The first run downloads JavaScript (about 0.6 MB), which is kept for the next runs.
Your run, in this browser
- Meera, a final-year student, lands at L1, which is where roles for new graduates hire. Her gaps are normal for a student and say what L2 will ask of her after she joins; for her interviews the one that matters most is testing, because her loop will be coding rounds, starting with an online assessment.
- Karan, a backend engineer with three years of experience, has a band of L2 to L3. He can apply for senior roles, but L3 is not yet firm: influence is below L2, and design, trade-offs, ambiguity and mentoring are at L2. For a senior loop he should prepare one design story with real trade-offs and one story in which his work changed what another team did.
- Ananya, a tech lead with eight years of experience, is a firm L4. Staff would need influence beyond her team, and more of her descriptors at L5; until then, a staff loop would hear mostly team-level stories.
Press Edit, put your own ratings in a new show(...) line and run it, then read the lines below your band: they say
which rounds to prepare most, and which stories you still need.
Key idea
Rate only work you have done, and read your band from its weakest descriptor: an average would let a strong line hide the weak one that an interviewer at the next level will probe.
Checkpoint
Check: Placing yourself on the ladder
Down-levelling is a conversation about evidence
Ask about level early, when nothing is at stake yet: which level the role is hired at, what that level is expected to show in the loop, and whether the panel can consider a level above or below it. Describe your work in scope terms, as in the tables above, and give one example for each claim. Step through one candidate’s conversations about level, from the first call to an offer one level lower:
The drawing shows the whole scene; its 7 steps are listed below.
Every step as text
- Ask while nothing is at stake. At the first call Karan asks which level the role is hired at, what that level is expected to show in the loop, and whether the panel can consider the level above or below it.
- The level and its bar. The recruiter names a senior role and says the loop will look for designs he owned and work that reached beyond his team. Now Karan knows which evidence each round must show.
- Scope in every round. In the loop he describes his work in scope terms, with one example for each claim, such as the size of the problems he owned and the designs that were his.
- Where the evidence was thin. The notes support most of the senior expectations, but his stories of influence stayed inside his own team. The panel decides to hire, one level lower.
- The offer, one level lower. The recruiter calls with an offer at the level below the one he interviewed for. This is down-levelling, and the call is not the place to decide.
- Three questions. Karan thanks the recruiter and asks, as far as the recruiter can share, which signals fell below the bar, whether more evidence could change the level, and how promotion works after joining.
- Decide on the job. A few days later he decides on the job itself, the scope and the pay at the offered level and how soon the next level is realistic, weighed against his other options.
If an offer names a lower level than the role you applied for, a change usually called down-levelling: An offer at a lower level than the role a candidate interviewed for, usually because the panel saw evidence for some of that level's expectations but not all of them., do not decide on the call. Ask, as far as the recruiter can share, which signals the panel saw below the bar, whether the level can be revisited with more evidence, and how promotion works after joining: how long it usually takes and what it is based on. Then decide on the job itself, the scope and the pay at that level, against your other options. Say that you will walk away only if you mean it.
Checkpoint
Check: Talking about level and down-levelling
Role families add rounds of their own
Front-end, security, reliability, machine learning and data engineers are interviewed on the same foundations as generalist software engineers, plus the work of their own family. The table lists what each family adds, with a published example of each:
| Role family | What its loop adds | A published example |
|---|---|---|
| Front-end | Accessibility in the coding questions, and the design of a web-scale application | Amazon’s front-end page adds accessibility to coding, down to whether the application works without a mouse, and gives a type-ahead widget, infinite scrolling or a carousel as design examples; its loop is four 55-minute interviews after an online assessment and a 60-minute phone screen |
| Security | A secure code review, depending on the role | Amazon’s security engineer page lists one or two 60-minute technical phone screens with a senior leader, which may include the code review, and a loop of five 60-minute interviews |
| Reliability | A ladder and sample prompts of its own | Dropbox has a separate reliability engineer ladder, from IC1 to IC7; Atlassian publishes sample coding prompts for SRE roles separately, as it does for front-end, back-end and full-stack roles |
| Machine learning and data | Ladders of their own | Dropbox’s machine learning and data engineer ladders each run from IC1 to IC5, and its security engineer ladder from IC2 to IC6 |
| Design rounds by position | Systems design or product architecture | Meta’s design interview is one or the other, depending on the position, and candidates who are unsure which to prepare are asked to check with the recruiter |
The practical step is the same for every family: find the employer’s page for your role, not only the general one, and prepare for the rounds it adds.
Checkpoint
Check: Rounds that role families add
Practise: ladders, loops and offers
The questions cover the six ideas of this lesson, from reading a ladder to the rounds a role family adds. Each one is explained as soon as you answer, and the next question goes to the idea your answers have shown to be weakest:
Practice that adapts to you
Practise this lesson
16 questions about 6 ideas of this lesson. Each answer is explained at once, and what you get right is kept in this browser.
Interview questions
What separates a senior engineer from a mid-level engineer? (warm-up)
Scope and independence, more than skill at any single task. A mid-level engineer delivers well-defined features and projects on their own, with guidance on the open-ended parts. A senior engineer owns problems that are not yet defined: they turn an open goal into milestones, choose between designs with their trade-offs, see the work through production and help the people around them grow. Public ladders say this in their own words: Dropbox’s framework moves from executing defined projects at IC2 to independently solving ambiguous, open-ended problems at IC3, where mentoring turns from something an engineer may do into actively helping less experienced teammates grow, and GitLab’s backend ladder moves from problems of moderate scope to high scope and complexity at Senior. A good answer adds one piece of your own work as an example of each.
The interviewer may push on the warm-up with two more questions. For each, decide which reply shows your level best; every reply explains what it proves about your scope, or why it proves nothing:
Checkpoint
Interview round: two follow-up questions
Two questions of this module’s bank ask for your own scope, and for a decision about level:
Model answers open with any pass: ₹79 for 1 week ($2.99), one payment that never renews.
-
Mid to staff
Tell me about the largest piece of work you owned from start to finish. How far did its effect reach beyond your own team?
-
Mid to senior
You interviewed for a senior role, and the offer comes one level lower. How do you respond on the call, and what do you weigh before you decide?
Key takeaways
- A level measures scope: the size and openness of your problems, how much guidance you need and how far your influence reaches.
- Titles do not transfer between employers, and Dropbox even gives four levels one title, so compare the scope a role’s description or ladder expects.
- The target level changes the loop: more interviews, deeper and more open design, and behavioural questions about scope and influence.
- Rate yourself only on work you have done, never by averaging, because the weakest descriptor is what the next level probes.
- If an offer comes at a lower level, ask which signals were missing and how the level could be revisited, then decide on the job, the scope and the pay.
- Role families add rounds, such as front-end design or a secure code review, so read the employer’s page for your own role.
Terms in this lesson
- career ladder
- An employer's description of what is expected of an engineer at each level, also called a career framework. It describes each level by the scope of the work, the guidance needed and how far its influence reaches.
- down-levelling
- An offer at a lower level than the role a candidate interviewed for, usually because the panel saw evidence for some of that level's expectations but not all of them.
- role family
- A group of related roles that share a ladder and the same interview foundations, such as front-end, security or reliability engineering, each adding rounds of its own.
References
- Dropbox Engineering Career Framework (Dropbox)
- IC3 Software Engineer (Dropbox Engineering Career Framework) (Dropbox)
- IC5 Staff Software Engineer (Dropbox Engineering Career Framework) (Dropbox)
- Backend Engineer job family (GitLab Handbook)
- How we hire (Amazon Jobs)
- SDE Online Assessment (students and recent graduates) (Amazon Jobs)
- SDE II Interview Prep (Amazon Jobs)
- SDE III Interview Prep (Amazon Jobs)
- Front End Engineer Interview Prep (Amazon Jobs)
- Security Engineer Interview Prep (Amazon Jobs)
- Software Engineer Full Loop Interview Guide (linked from the onsite prep page) (Meta Careers)
- Atlassian engineering interview handbook (Atlassian)
Related tools
Report a problem with this lesson
Kept only in this browser. Your Learn progress