Tech Interview Preparation Module 1 – How tech hiring works
How interviews are scored: signals and rubrics
What a structured interview is, the signals coding, design and behavioural rubrics share, how interviewers record evidence and how feedback becomes a decision.
What you will learn
- Explain what a structured interview is and why employers use rubrics
- List the signal families most technical rubrics share
- Translate each signal into behaviours an interviewer can observe and record
- Assess an answer against a four-signal practice rubric, naming the evidence behind each score
- Describe how written feedback becomes a hire, no-hire or level decision
Before you start
What you’ll learn · Before you start
What you will learn
- Explain what a structured interview is and why employers use rubrics
- List the signal families most technical rubrics share
- Translate each signal into behaviours an interviewer can observe and record
- Assess an answer against a four-signal practice rubric, naming the evidence behind each score
- Describe how written feedback becomes a hire, no-hire or level decision
Before you start
On this page
Two candidates can write the same correct code and leave with very different scores. On this track’s practice rubric, the one who works in silence scores 1 on two of its four signals, while the one who thinks aloud and finds a bug by tracing scores at least 3 on all four, because an interviewer can score only what you show. In a structured interview: An interview in which every candidate for a role meets the same kind of questions and follow-up probes, and the answers are scored against written descriptions of each score., every candidate for a role meets the same kind of questions, and the answers are rated against written descriptions of each score, called a rubric: Written descriptions of the evidence that earns each score on each signal of an interview, so that different interviewers score the same answer the same way..
Technical rubrics score a few separate signal: One separate quality that an interview rubric scores, such as communication, approach, code or verification in a coding round. Each signal needs evidence of its own. rather than one verdict: in a coding round, how you understand and communicate the problem, how you choose an approach, the code itself and how you check it. Each interviewer writes down the moments that show each signal, scores them and adds a recommendation, and the panel’s written feedback is then read together and turned into a decision.
Not affiliated
MySmartCoPilot is independent of the employers named in this lesson. What they say about their own interviews comes from their careers pages and guides, listed under References. The rubric you practise with here is this track’s own; it describes no employer’s internal rubric.
Structured interviews ask the same questions and score against written benchmarks
The U.S. Office of Personnel Management, which publishes hiring guidance for federal agencies, describes structure as a set of rules for how answers are asked for, observed and evaluated, rules that raise agreement between interviewers by limiting how much each one decides on their own. The table sets an interview left to each interviewer beside the most structured kind that OPM describes:
| Part of the interview | Left to each interviewer | At the most structured end |
|---|---|---|
| Questions | Whatever the interviewer thinks of on the day | The same predefined questions for every candidate |
| Follow-ups | Improvised as the answer goes | The same follow-up probes for every candidate |
| Scoring | One overall impression | Each answer scored against written benchmarks of proficiency |
| A panel’s ratings | No set rule | Each member rates alone, then the panel resolves large differences |
OPM reports that more structure goes with higher validity: In hiring research, how well the scores of a selection method predict later job performance, usually reported as a correlation from 0 to 1., more reliable and more consistent ratings, and less adverse impact. The research behind that advice is unusually strong. Sackett, Zhang, Berry and Lievens re-examined decades of studies of how well selection methods predict job performance and argued that earlier corrections had overstated them. In their revised estimates the methods that had ranked highest stayed near the top with values .10 to .20 lower, and structured interviews came out as the top-ranked procedure. Levashina, Hartwell, Morgeson and Campion review what structure means in practice, among other things the definition of structure, rating scales and the rules for probing and following up.
Employers say the same about their own rounds. Google says every candidate is assessed with clear rubrics, the same ones for everyone considered for a role, and that it stopped asking brainteasers because its data showed they did not predict how well someone would do on the job. Amazon avoids brain teasers for the same reason, and Microsoft says that structured interviews and a consistent framework help it evaluate real skills against what the role requires.
Checkpoint
Check: What makes an interview structured
Rubrics score separate signals, not one verdict
Few employers publish their scoring, so Meta’s software engineer guide is a useful public example. It names the focus areas each interviewer assesses:
| Round | Focus areas in Meta’s guide |
|---|---|
| Coding | Communication, problem solving, coding, verification |
| Design | Problem navigation, solution design, technical excellence, technical communication |
| Behavioural | Resolving conflict, growing continuously, embracing ambiguity, driving results, communicating effectively |
Other employers group the same ideas under other names. Amazon’s SDE II page says interviewers are each assigned a set of competencies to evaluate, some technical and some based on its Leadership Principles, and its coding competencies are problem solving, logical and maintainable code, and data structures and algorithms. Atlassian designs its questions to “ladder”: the follow-ups get harder or easier as you go, so the interviewer also sees how you adjust to a new trade-off.
This track’s practice rubric for a coding round keeps four signals, each scored from 1 to 4. A score of 1 means the round left no evidence for that signal; each higher score names the behaviour that earns it:
| Signal | Score 2 | Score 3 | Score 4 |
|---|---|---|---|
| Communication | Restates the problem or asks one question | Asks the questions that change the solution and states assumptions | Plans aloud and checks in at each decision |
| Approach | Names one working approach | Compares two approaches with their time and space costs | Chooses from the constraints and says what would change the choice |
| Code | Code that handles the main case | Correct, readable code with clear names | Correct code shaped so that a change of rule is a one-line edit |
| Verification | Walks one example by hand | Traces a normal case and the edge cases before saying done | Finds and fixes their own bug by tracing |
Read each row from left to right: every step up asks for more evidence of the same signal, never for a different skill. Use the rubric for practice, and use an employer’s own guide for what that employer looks for.
Checkpoint
Check: The signals a rubric scores
Each signal is scored from behaviours written in the notes
An interviewer cannot write “good problem solver” in the notes; they write what happened, and the score comes from those lines. So prepare behaviours, not adjectives. Each signal has a few behaviours that turn into evidence:
| Signal | Behaviours an interviewer can write down |
|---|---|
| Communication | States an assumption aloud (“I’ll assume the list fits in memory”); asks about input sizes or edge cases before coding; says which step comes next |
| Approach | Names the simple solution and its cost; compares two approaches by time and space; explains why the chosen one suits the constraints |
| Code | Uses names that say what a variable holds; moves a block that does a second job into a helper; handles the empty input in the code, not only in conversation |
| Verification | Walks a normal input through the code, writing the values down; tries the smallest and the boundary inputs; finds a bug before the interviewer does |
Behavioural rounds work the same way. “Resolving conflict”, one of Meta’s focus areas, becomes a story in which you name the disagreement, what each side wanted, what you did and what changed. Amazon asks for complete stories with the context, the task, the actions you took yourself and the outcome, including what you learnt.
Read the diagram from the top. Only what you say and do reaches the notes, and every box below the notes is built from them alone:
From what you show in the room to a decision and a level
Text description of the diagram
The diagram is a column of six boxes joined by arrows, from top to bottom:
1. What you say and do: your questions, your plans, your code and your tests. 2. An arrow labelled "only what is shown" leads to the interviewer's notes: what happened, minute by minute. 3. A score for each signal, given against written descriptions of each score. 4. Written feedback: the scores, the evidence behind them and a recommendation. 5. An arrow labelled "one from each interviewer" leads to the debrief or committee, which reads the whole panel's feedback together. 6. The decision and the level: whether to hire, and at which level.
Checkpoint
Check: Behaviours that become evidence
Silence leaves signals empty: one answer, scored twice
The problem, an original one: a shop keeps one sales figure a day; find how many days the longest stretch lasts in which sales go up from each day to the next, where a day with the same sales as the day before ends the stretch. The same candidate solves it twice, silently and then aloud, and both versions end with correct code. The program holds the interviewer’s notes for each version and scores them on the practice rubric. Press Edit, change a note’s signal or score, and run it again to see the profile move:
// One coding answer, given twice: the same candidate, the same problem and correct code at the end of both. The
// interviewer can score only what the notes show, so the two versions score very differently.
//
// The problem: a shop keeps one sales figure a day; find how many days the longest stretch lasts in which sales go
// up from each day to the next. A day with the same sales as the day before ends the stretch.
// This track's practice rubric for a coding round: four signals, scored 1 to 4. A score needs a note that shows its
// behaviour; a signal with no note scores 1.
const RUBRIC = {
communication: {
2: 'restates the problem or asks one question',
3: 'asks the questions that change the solution and states assumptions',
4: 'plans aloud and checks in at each decision',
},
approach: {
2: 'names one working approach',
3: 'compares two approaches with their time and space costs',
4: 'chooses from the constraints and says what would change the choice',
},
code: {
2: 'code that handles the main case',
3: 'correct, readable code with clear names',
4: 'correct code shaped so that a change of rule is a one-line edit',
},
verification: {
2: 'walks one example by hand',
3: 'traces a normal case and the edge cases before saying done',
4: 'finds and fixes their own bug by tracing',
},
};
const SIGNALS = Object.keys(RUBRIC);
// The interviewer's notes: [minute, what happened, the signal it is evidence for, the score it supports].
const silent = [
[2, 'starts typing at once; no questions', null, 0],
[9, 'a correct single-pass loop with clear names', 'code', 3],
[10, 'says "done"; when asked about speed: "it is linear"', 'approach', 2],
];
const narrated = [
[1, 'asks whether the list can be empty and whether an equal day counts as a rise', 'communication', 3],
[3, 'checking every start day is O(n^2); one pass that keeps the current run is O(n) time and O(1) space', 'approach', 3],
[4, '"Shall I code the one-pass version?"', 'communication', 4],
[11, 'readable loop with clear names, first draft finished', 'code', 3],
[12, 'traces [5, 7, 7, 8, 9], sees 5 where 3 is right: equal days kept the run going; fixes it', 'verification', 4],
[14, 'checks an empty list and a single day', 'verification', 3],
];
/** The score of each signal: the highest score its notes support, 1 without a note. */
function score(notes) {
const out = Object.fromEntries(SIGNALS.map((s) => [s, 1]));
for (const [, , signal, level] of notes) if (signal) out[signal] = Math.max(out[signal], level);
return out;
}
function report(title, notes) {
console.log(title);
for (const [minute, text] of notes) console.log(` minute ${String(minute).padStart(2)}: ${text}`);
const scores = score(notes);
for (const s of SIGNALS) {
const why = scores[s] > 1 ? RUBRIC[s][scores[s]] : 'no note shows it';
console.log(` ${s.padEnd(14)} ${scores[s]} ${why}`);
}
const missing = SIGNALS.filter((s) => scores[s] === 1);
console.log(` lowest signal: ${Math.min(...Object.values(scores))}; no evidence for: ${missing.join(', ') || 'none'}`);
console.log();
}
report('Version 1, silent', silent);
report('Version 2, narrated', narrated);
// The bug that version 2 found by tracing, and the fix: the first draft reset the run only when sales fell.
function firstDraft(sales) {
let best = 0;
let run = 0;
for (let i = 0; i < sales.length; i++) {
run = i > 0 && sales[i] < sales[i - 1] ? 1 : run + 1;
best = Math.max(best, run);
}
return best;
}
function fixed(sales) {
let best = 0;
let run = 0;
for (let i = 0; i < sales.length; i++) {
run = i > 0 && sales[i] > sales[i - 1] ? run + 1 : 1;
best = Math.max(best, run);
}
return best;
}
for (const sales of [[5, 7, 7, 8, 9], [], [4]]) {
console.log(`[${sales.join(', ')}]: first draft ${firstDraft(sales)}, fixed ${fixed(sales)}`);
}Output
Version 1, silent minute 2: starts typing at once; no questions minute 9: a correct single-pass loop with clear names minute 10: says "done"; when asked about speed: "it is linear" communication 1 no note shows it approach 2 names one working approach code 3 correct, readable code with clear names verification 1 no note shows it lowest signal: 1; no evidence for: communication, verification Version 2, narrated minute 1: asks whether the list can be empty and whether an equal day counts as a rise minute 3: checking every start day is O(n^2); one pass that keeps the current run is O(n) time and O(1) space minute 4: "Shall I code the one-pass version?" minute 11: readable loop with clear names, first draft finished minute 12: traces [5, 7, 7, 8, 9], sees 5 where 3 is right: equal days kept the run going; fixes it minute 14: checks an empty list and a single day communication 4 plans aloud and checks in at each decision approach 3 compares two approaches with their time and space costs code 3 correct, readable code with clear names verification 4 finds and fixes their own bug by tracing lowest signal: 3; no evidence for: none [5, 7, 7, 8, 9]: first draft 5, fixed 3 []: first draft 0, fixed 0 [4]: first draft 1, fixed 1
Recorded with Node.js 24.21.0 on macOS 26 arm64. To run it yourself: mise exec node@24.21.0 -- node score_versions.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
- The code scores 3 in both. Correct code with clear names earns the same on that line whether or not you speak.
- Silence leaves two signals empty. The silent version gives no evidence of communication or verification at all, and its approach is one phrase, given only when asked. Its lowest signal is a 1.
- A bug found aloud is the best evidence of verification. The narrated first draft kept a run going through an equal day and printed 5 where 3 is right, as the last lines of the output show; tracing found it. Meta’s guide says the same about bugs: finding and catching them in your own code is a positive sign.
Narrating does not mean describing every keystroke. Say the plan, each decision and why, and what you are checking; then type in silence if you need to.
Key idea
Correct code fills one line of a rubric. The questions you ask, the choice you explain and the trace you walk aloud fill the other three, and a signal nobody saw scores 1.
Checkpoint
Check: Scoring only what is shown
Feedback is written alone and read together
The notes are the start of a paper trail. Step through two rounds of one loop, from the interviewers’ write-ups to the decision, and watch what the committee has in front of it:
The drawing shows the whole scene; its 6 steps are listed below.
Every step as text
- Each round is written up. The coding interviewer turns the notes into a write-up, a score for each signal of the rubric with the evidence behind it, and a recommendation. Nobody else's view is in it yet.
- The second write-up. The design interviewer does the same for the design round, on that round's own signals, such as problem navigation and solution design.
- A large difference. The coding write-up recommends a hire and the design one does not. On a structured panel each member rated alone, so the difference is real information, and the two talk it through from the evidence in their notes.
- The feedback goes on. Both write-ups go to the committee, which works independently of the interviewers. It has the interview feedback and the candidate's CV, and nothing else.
- What the committee cannot see. A strong answer that no interviewer wrote down is not in front of the committee. A question the candidate asked, a trade-off they named or a bug they found counts only if a note records it.
- The decision and the level. The committee decides whether to hire and, where the level is open, reads it from the same notes. The recruiter then shares the outcome with the candidate.
The employers’ pages describe the same three steps:
- Each interviewer writes feedback alone. Amazon’s interviewers take detailed notes to share with the rest of the team, and Google expects its interviewers to analyse each conversation and give structured, thoughtful feedback.
- The feedback is read together. Atlassian’s interviewers consolidate their feedback and hold a debrief, and a hiring committee that works independently of them, with access only to the interview feedback and your CV, makes the decision. Google applies internal reviews after the interviews. OPM describes structured interviews scored by a panel in which each member rates the answers alone, and the panel then talks through large differences.
- The decision rests on what was written. A committee that sees only feedback and a CV can decide only from what the interviewers wrote down. When the panel also considers the level you join at, it reads it from the same notes: another reason to show the scope of your work in every round, which the next lesson covers.
Checkpoint
Check: From feedback to a decision
Scoring a round signal by signal shows where its points went
Each transcript below comes from a different 45-minute round on the same original problem: a co-working space stores the day’s room bookings as pairs of start and end minutes; return true when no two bookings overlap, where a booking that ends at minute 600 and one that starts at minute 600 do not overlap. Score each one on the four signals of the practice rubric before you open its checkpoint. Each answer’s feedback gives the reference score and the evidence behind it.
Transcript 1
- Minute 1. Reads the prompt and starts typing at once.
- Minute 6. Two nested loops that compare every pair of bookings, with the names
i,j,aandb. The code is correct. - Minute 7. “That should work.” Asked how fast it is: “It’s fine for one day’s bookings.”
- Minute 8. Stops, without running an example.
Checkpoint
Check: Scoring a round yourself
Transcript 2
- Minute 1. “Do a booking ending at 600 and one starting at 600 clash? The prompt says no, so touching is fine. Are the bookings sorted?” They are not.
- Minute 3. “Comparing every pair is O(n²). If I sort by start time, I only compare neighbours: O(n log n) for the sort and constant extra space if I sort in place.”
- Minute 4. “I’ll go with sorting. Does that sound reasonable?”
- Minute 10. Sorted bookings, a loop over neighbours with the names
previousandcurrent, and a test ofprevious.end >= current.start. - Minute 11. Traces two bookings, minutes 540 to 600 and 600 to 660, sees that they are reported as a clash,
says the comparison breaks the touching rule and changes
>=to>. - Minute 13. Checks an empty list and a single booking.
Checkpoint
Check: Scoring a round yourself
Transcript 3
- Minute 2. “Can a booking cross midnight?” It cannot. “Then every time fits in one day’s 1,440 minutes.”
- Minute 4. “One option: sort by start and compare neighbours, O(n log n). Another: mark the minutes in an array of 1,440 slots, O(n + 1,440) time and fixed memory, faster for many bookings, but it breaks if the times become seconds. I’ll sort, because it does not depend on the unit.”
- Minutes 6 to 34. Writes a sorting function by hand, in silence, and gets stuck in it. At minute 34 the interviewer suggests the language’s built-in sort, and the candidate takes the hint.
- Minute 42. The loop over neighbours handles the usual case, but skips the comparison of the last pair.
- Minute 44. Time runs out before any example is traced.
Checkpoint
Check: Scoring a round yourself
The three rounds lose their points in different places, and five habits explain most of them:
| Habit | The signal it leaves empty | Do this instead |
|---|---|---|
| Treating correctness as the score | Every signal but code | Give each signal its own evidence: questions, a comparison, a trace |
| Staying quiet to look confident | Communication | Ask the question that changes the solution, then say your plan |
| Saying “done” without a trace | Verification | Walk one normal input and one edge case aloud; it takes two minutes |
| Hiding a bug | Verification, which then counts against you | Name the bug you found by tracing, and fix it |
| Building what the language gives you | Code and verification, through lost minutes | Use the built-in sort and spend the time on the tests |
Practise: score from the evidence
Six ideas are covered here, from what structure fixes to scoring a whole round. The questions come one at a time and each answer is explained at once; the idea you know least is asked about first:
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
Why do interviewers ask you to think aloud? (warm-up)
Because they can score only what they see and hear. A coding rubric gives points for understanding the problem, comparing approaches, writing correct code and checking it, and three of those four happen in your head unless you say them. Meta’s guide puts it plainly: interviewers can assess only what you show them during the interview. Thinking aloud turns your questions, assumptions and trade-offs into evidence the interviewer can write down, lets them redirect you early when you head the wrong way, and shows how you would work with a colleague. It does not mean narrating every keystroke: say your plan, your decisions and what you are checking. A good answer adds that a silent minute is fine, as long as you say first that you are taking it to think.
An interviewer who asks this often follows it up. Two likely follow-ups are below: choose the reply that would leave the most evidence in the notes, then see what the weaker replies miss:
Checkpoint
Interview round: two follow-up questions
Two situations from this module’s question bank test the same idea under time pressure:
Model answers open with any pass: ₹79 for 1 week ($2.99), one payment that never renews.
-
Fresher to mid
You solved the coding problem with correct code, yet you did not pass the round. What might the interviewer's notes have been missing, and what will you change for the next round?
-
Fresher to senior
With five minutes left, you notice a bug in your solution that the interviewer has not mentioned. What do you do, and how does it affect how you are scored?
Key takeaways
- A structured interview asks every candidate for a role the same kind of questions and scores the answers against written descriptions, and the research quoted here ranks it first among selection procedures.
- Technical rubrics score separate signals, such as communication, approach, code and verification in a coding round, with sets of their own for design and behavioural rounds.
- An interviewer writes down behaviours, not impressions, so prepare behaviours: questions, comparisons and traces.
- Correct code in silence can score below a narrated answer whose bug you find yourself, because silence leaves signals without evidence.
- Each interviewer writes feedback alone, and a debrief or a committee reads it together and decides, the level included, from what was written.
- Scoring a round signal by signal shows where its points went: the third transcript’s strong approach could not make up for code and checks left without time.
Terms in this lesson
- rubric
- Written descriptions of the evidence that earns each score on each signal of an interview, so that different interviewers score the same answer the same way.
- signal
- One separate quality that an interview rubric scores, such as communication, approach, code or verification in a coding round. Each signal needs evidence of its own.
- structured interview
- An interview in which every candidate for a role meets the same kind of questions and follow-up probes, and the answers are scored against written descriptions of each score.
- validity
- In hiring research, how well the scores of a selection method predict later job performance, usually reported as a correlation from 0 to 1.
References
- Our hiring process (How we hire) (Google Careers)
- Interviewing at Google: best practices, advice and tips (Google Careers)
- Software Engineer Full Loop Interview Guide (linked from the onsite prep page) (Meta Careers)
- How we hire (hiring tips) (Microsoft Careers)
- Interview loop (Amazon Jobs)
- SDE II Interview Prep (Amazon Jobs)
- Atlassian engineering interview handbook (Atlassian)
- Structured interviews (U.S. Office of Personnel Management)
- Revisiting meta-analytic estimates of validity in personnel selection: addressing systematic overcorrection for restriction of range (Sackett, Zhang, Berry and Lievens) (Journal of Applied Psychology (American Psychological Association))
- The structured employment interview: narrative and quantitative review of the research literature (Levashina, Hartwell, Morgeson and Campion) (Personnel Psychology (Wiley))
Related tools
Report a problem with this lesson
Kept only in this browser. Your Learn progress