# Technical Interview Kit: [Role title, level]

> Structured interview kit for hiring software engineers and engineering managers: the competencies assessed and their mapping to career-ladder levels, the interview loop, a question bank with probes per competency, an anchored 1 to 4 rating scale with behavioural anchors, the interviewer scorecard, the calibration and debrief protocol, bias and legal-compliance controls (job-relatedness, consistency, accommodations), candidate experience and data retention. There is no formal standard for technical interviews; the kit follows widely published structured-interview good practice and fair-selection guidance such as UK Acas recruitment guidance and the US Uniform Guidelines on Employee Selection Procedures (1978). All questions and anchors are original text. Replace every `[bracketed]` value and every row marked *Example*. This is a documentation format, not legal advice.

<!--
Guidance: How to use this template
- Create one kit per role and level band (for example "Backend Engineer, L2 to L3"). Reuse the question bank across kits, but fix the competencies and loop per role before the first candidate is interviewed.
- The kit quotes level and competency IDs from the Engineering Career Ladder (`career/engineering-career-ladder`). Write or adopt the ladder first.
- Every question must trace to a competency, and every competency to a job requirement in the Job Description (`career/job-description`). Questions that trace to nothing are removed.
- Have the kit reviewed by People (or HR) and, where required, by legal counsel or an employee representative before use.
- Candidates prepare with Interview Prep (`career/interview-prep`); new hires continue with the 90-Day Plan (`career/ninety-day-plan`) and the Onboarding Guide (`dev/onboarding-guide`).
-->

## Document control

<!-- Guidance: Record the role, the ladder version the kit maps to and the requisition it serves, so that every scorecard can be traced to the kit version used. -->

| Field | Value |
|---|---|
| Document ID | [IKT-001] |
| Version | [1.0] |
| Status | [Draft / Approved / In use / Retired] |
| Owner | [@hiring-manager] |
| Approvers/reviewers | [@head-of-engineering], [@talent-acquisition-lead], [@people-partner], [@legal-counsel] |
| Role and family | [Backend Engineer, software engineering family] |
| Target levels | [L2 to L3] |
| Career ladder version | [LAD-001 v1.0] |
| Requisition IDs | [REQ-2026-031] |
| Locations and jurisdictions | [Countries where candidates are hired] |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
| Classification | [Internal; question bank Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Hiring manager | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Head of Engineering | [@name] | [Decision] | YYYY-MM-DD |
| Talent acquisition lead | [@name] | [Decision] | YYYY-MM-DD |
| People partner or legal reviewer | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for Corvid Commerce backend hiring after a mock-loop pilot |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Retired question Q-TEC-004 after it appeared on a public forum; added Q-TEC-006 |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Purpose, scope and principles](#1-purpose-scope-and-principles)
2. [Roles and responsibilities](#2-roles-and-responsibilities)
3. [Competencies and level mapping](#3-competencies-and-level-mapping)
4. [Interview loop design](#4-interview-loop-design)
5. [Question bank](#5-question-bank)
6. [Rating scale and behavioural anchors](#6-rating-scale-and-behavioural-anchors)
7. [Interviewer scorecard](#7-interviewer-scorecard)
8. [Calibration and debrief protocol](#8-calibration-and-debrief-protocol)
9. [Bias and legal-compliance controls](#9-bias-and-legal-compliance-controls)
10. [Candidate experience](#10-candidate-experience)
11. [Data protection and retention](#11-data-protection-and-retention)
12. [Interviewer training and kit quality](#12-interviewer-training-and-kit-quality)
13. [Glossary and references](#13-glossary-and-references)

## 1. Purpose, scope and principles

<!-- Guidance: State what decision the kit supports and the principles interviewers must follow. Questions to answer: which roles and levels, which stages, and what is out of scope (for example reference checks)? Common pitfall: an unstructured "chat" stage that later outweighs the structured evidence. -->

### 1.1 Purpose

This kit makes hiring decisions for [Role title] consistent, job-related and defensible. Every candidate for the role meets the same stages, is asked questions drawn from the same bank, and is rated on the same anchored scale by trained interviewers who write evidence before they discuss the candidate.

### 1.2 Scope

In scope: all interview stages from the technical screen to the debrief, levelling within the target band, and the records produced. Out of scope: sourcing, the offer and negotiation, background checks and reference checks, which follow [linked People procedures].

### 1.3 Principles

| ID | Principle |
|---|---|
| INT-P01 | **Job-related.** Assess only what the role needs, as written in the job description and the ladder level. |
| INT-P02 | **Consistent.** Same competencies, same stage order, same question set per stage and same scale for every candidate for the same kit. |
| INT-P03 | **Evidence before opinion.** Interviewers record what the candidate said and did, then rate, then discuss. |
| INT-P04 | **Independent ratings.** No interviewer sees another's ratings before submitting their own. |
| INT-P05 | **Accessible.** Every candidate is asked about adjustments and receives them where reasonable. |
| INT-P06 | **Respectful.** Candidates are treated as future colleagues; time is limited and candidates are never asked to do unpaid work that resembles real product work. |
| INT-P07 | **Proportionate data.** Collect only what the decision needs and keep it only as long as stated (section 11). |

## 2. Roles and responsibilities

<!-- Guidance: Name who designs, runs and decides. Questions to answer: who owns the decision, who can veto, who checks fairness? Common pitfall: the hiring manager deciding alone after the debrief, which turns the panel into advisers whose evidence can be ignored. -->

| Activity | Hiring manager | Recruiter | Interviewers | Debrief facilitator | People partner | Head of Engineering |
|---|---|---|---|---|---|---|
| Define competencies and loop | A | C | C | C | C | I |
| Approve question bank | A | I | R | C | C | I |
| Schedule and brief candidate, ask about adjustments | I | R | I | I | C | I |
| Conduct interview and submit scorecard | I | I | R | I | I | I |
| Run debrief | C | C | C | R | I | I |
| Hiring and level decision | A | C | C | C | C | I (escalations) |
| Adverse-impact and quality review | C | R | I | C | A | I |

R = Responsible, A = Accountable, C = Consulted, I = Informed.

**Debrief facilitator.** A trained interviewer who is not the hiring manager, ideally from another team (sometimes called a bar raiser). The facilitator enforces the protocol in section 8 and may block a decision that is not supported by the written evidence, escalating to the Head of Engineering.

## 3. Competencies and level mapping

<!-- Guidance: Select the ladder competencies this role needs and say what "meets the bar" means at each target level. Questions to answer: which competencies are must-have, which stage covers each, and does each competency have at least two independent observations? Common pitfall: assessing a competency in every stage, which wastes time and rewards first impressions. -->

### 3.1 Competencies assessed

| Competency (ladder ID) | Requirement for this role *(Example)* | Must-have | L2 bar | L3 bar |
|---|---|---|---|---|
| CMP-01 Technical skill: coding | Writes correct, tested, readable code in [language] | Yes | Solves a scoped problem with clean structure and tests | Also handles edge cases unprompted and explains trade-offs |
| CMP-01 Technical skill: design | Designs services with data model, interfaces and failure handling | Yes (L3), No (L2) | Designs a single component with guidance | Designs a service end to end and defends trade-offs |
| CMP-02 Delivery | Breaks work into increments, manages risk | Yes | Describes delivering a feature in safe steps | Describes leading a multi-person project to completion |
| CMP-04 Collaboration and communication | Explains reasoning, gives and receives feedback | Yes | Communicates clearly when prompted | Drives a discussion to a decision, handles disagreement |
| CMP-05 Leadership and mentoring | Helps others grow | No (L2), Yes (L3) | Has helped a peer | Has mentored with visible results |
| CMP-06 Operational and security ownership | Owns services in production, secure design | Yes | Debugs systematically; knows basic secure coding | Has led incident response; considers threats in design |

CMP-03 Impact and scope is inferred from the evidence of the other areas and from the experience interview; it is not scored separately for L2 and L3 roles.

### 3.2 Coverage matrix (traceability)

| Competency | Technical screen | Coding exercise | System design | Debugging and operations | Experience interview | Observations |
|---|---|---|---|---|---|---|
| CMP-01 coding | X | X | | | | 2 |
| CMP-01 design | | | X | | X | 2 |
| CMP-02 | | | | | X | 1 + design follow-up |
| CMP-04 | | X | X | | X | 3 |
| CMP-05 | | | | | X | 1 (L3: add design probe) |
| CMP-06 | | | X | X | | 2 |

Every must-have competency needs at least two observations by different interviewers. Where the matrix shows one, the kit adds a follow-up probe in another stage (CMP-02 and CMP-05 in this *Example*).

## 4. Interview loop design

<!-- Guidance: Design the loop around the competencies, then size it. Questions to answer: how long is the whole loop, which stages can be remote, what is the policy on take-home work and on AI coding assistants? Common pitfall: adding stages for every concern, so the loop exceeds what strong candidates will tolerate. -->

### 4.1 Stages

```mermaid
flowchart LR
    A["Application review against written criteria"] --> B["Recruiter conversation (30 min)"]
    B --> C["Technical screen (60 min)"]
    C --> D{"Screen decision"}
    D -- "Advance" --> E["Interview loop: coding, system design, debugging and operations, experience (4 x 60 min)"]
    D -- "Decline" --> X["Decline with feedback offer"]
    E --> F["Scorecards submitted independently"]
    F --> G["Debrief and level decision"]
    G --> H["Offer or decline"]
```

| Stage ID | Stage | Length | Format | Interviewer level | Competencies |
|---|---|---|---|---|---|
| STG-1 | Recruiter conversation | 30 min | Video | Recruiter | Logistics, adjustments, motivation (not scored on the rubric) |
| STG-2 | Technical screen | 60 min | Video, shared editor | L3 or above | CMP-01 coding |
| STG-3 | Coding exercise | 60 min | Pair programming in candidate's chosen language from an allowed list | L3 or above | CMP-01 coding, CMP-04 |
| STG-4 | System design | 60 min | Whiteboard or diagram tool | L4 or above (L3 for L2 roles) | CMP-01 design, CMP-04, CMP-06 |
| STG-5 | Debugging and operations | 60 min | Prepared broken service with logs and dashboards | L3 or above with on-call experience | CMP-06 |
| STG-6 | Experience interview | 60 min | Structured behavioural questions | Hiring manager or M3+ | CMP-02, CMP-04, CMP-05, CMP-01 design |

Total candidate time after the recruiter conversation: 5 hours (*Example*). Offer the loop on one day or split across two, at the candidate's choice.

### 4.2 Level variations

| Target level | Change to the loop |
|---|---|
| L1 | Replace STG-4 with a guided design discussion; STG-6 focuses on learning and collaboration |
| L4 and above | Add a technical leadership interview (cross-team influence, CMP-03 and CMP-05); system design uses an ambiguous multi-team scenario |
| Manager track (M3) | Replace STG-3 with a code and design review exercise; add a people leadership interview and a delivery and operations interview |

### 4.3 Exercise policies

- **Take-home work.** Optional alternative to STG-3 only, time-boxed to **[two hours]**, with the same rubric. Never ask for work that resembles real product work, and never use candidate output in production.
- **AI coding assistants.** State the policy to the candidate in advance: *Example:* "Allowed in STG-3 for syntax and documentation look-ups; explain any generated code you keep." Interviewers assess understanding and judgement, not typing speed.
- **Languages and tools.** Candidates choose from [list]. Do not penalise unfamiliarity with internal tools.
- **Recording.** Interviews are not recorded unless the candidate agrees in writing in advance and there is a stated purpose (section 11).

## 5. Question bank

<!-- Guidance: Write original questions, each tied to one competency, with probes and the signals that separate rating levels. Questions to answer: is the question job-related, can it be answered without insider knowledge, and do strong and weak answers differ visibly? Common pitfall: trivia and puzzle questions that measure preparation for interviews rather than ability to do the job. -->

### 5.1 Rules for questions

1. Each question has an ID (Q-AREA-NNN), a competency, the levels it suits, a main prompt, two to four probes and signals.
2. Interviewers ask the main prompt as written and use only listed probes or neutral follow-ups ("tell me more", "what happened next").
3. Questions about protected characteristics, family plans, health, age, nationality beyond right to work, religion or political views are never asked (section 9.2).
4. A question is retired when it leaks publicly, when its pass rate shows it does not discriminate between levels, or when it shows unexplained adverse impact.

### 5.2 Technical skill: coding (CMP-01)

| ID | Levels | Main prompt | Probes | Strong signals | Weak signals |
|---|---|---|---|---|---|
| Q-TEC-001 *(Example)* | L1 to L3 | "Write a function that merges overlapping booking time slots for one warehouse and returns the free windows for a given day." | What inputs would break this? How would you test it? How does it scale with 10,000 slots? | Clarifies inputs, handles boundaries and time zones, writes tests, explains complexity | Starts coding without clarifying, misses overlaps at boundaries, no tests |
| Q-TEC-002 *(Example)* | L2 to L4 | "Here is a 60-line function that calculates order discounts. Refactor it so a new discount type can be added safely." | What would you change first? How do you know behaviour is preserved? | Adds characterisation tests first, small safe steps, names concepts clearly | Rewrites everything at once, changes behaviour silently |
| Q-TEC-003 *(Example)* | L2 to L3 | "Implement a rate limiter for an API client that allows N calls per rolling minute." | What happens with concurrent callers? How would you observe it in production? | Correct algorithm choice explained, concurrency considered, metrics suggested | Fixed-window bug unnoticed, no thought for concurrency |

### 5.3 Technical skill: design (CMP-01, CMP-06)

| ID | Levels | Main prompt | Probes | Strong signals | Weak signals |
|---|---|---|---|---|---|
| Q-DES-001 *(Example)* | L2 to L4 | "Design a service that sends order-status notifications by email and SMS to customers of an online shop." | Expected volume and peaks? What if the SMS provider is down for an hour? How do you avoid duplicate messages? Which data is sensitive? | Clarifies requirements, queues and retries with idempotency, considers failure and privacy, sketches data model | Single synchronous call chain, no failure handling, no requirements questions |
| Q-DES-002 *(Example)* | L3 to L5 | "Our product catalogue search is slow at peak and the team disagrees on whether to add a cache or a search engine. Walk me through how you would decide." | What data would you gather? How would you roll the change out? What would make you reverse the decision? | Frames decision criteria, measures first, staged rollout, considers operational cost | Picks a technology by preference, no measurement or rollout plan |

### 5.4 Operational and security ownership (CMP-06)

| ID | Levels | Main prompt | Probes | Strong signals | Weak signals |
|---|---|---|---|---|---|
| Q-OPS-001 *(Example)* | L2 to L4 | "This checkout service returns errors for 5% of requests since the last deployment. Here are the logs and dashboards. Find out what is happening." | What do you check first? Would you roll back now? How would you prevent a repeat? | Hypothesis-driven, checks recent changes, weighs rollback early, proposes alert and test improvements | Random exploration, ignores the deployment, no prevention ideas |
| Q-OPS-002 *(Example)* | L2 to L4 | "A user-supplied file name is used to build a storage path in this code. What risks do you see and how would you fix them?" | How would you test the fix? Where else could this pattern appear? | Identifies path traversal, validates and normalises input, suggests tests and a search for similar code | Misses the issue or proposes a blocklist only |

### 5.5 Delivery, collaboration and leadership (CMP-02, CMP-04, CMP-05)

| ID | Competency | Levels | Main prompt | Probes | Strong signals | Weak signals |
|---|---|---|---|---|---|---|
| Q-DEL-001 *(Example)* | CMP-02 | L2 to L4 | "Tell me about a piece of work that turned out bigger than planned. What did you do?" | When did you notice? Who did you tell? What did you cut or change? | Early detection, transparent communication, scope trade-off with stakeholders, lessons applied | Blames others, notices late, no change in approach |
| Q-COL-001 *(Example)* | CMP-04 | All | "Describe a technical disagreement with a colleague. How was it resolved?" | What was their strongest argument? What did you learn? | States the other view fairly, uses evidence, commits to the decision | Describes winning, cannot state the other view |
| Q-LEA-001 *(Example)* | CMP-05 | L3 to L5 | "Tell me about someone you helped become more effective at their job." | What did you do specifically? How did you know it worked? | Concrete actions over time, measurable growth of the other person | Generic advice, no evidence of outcome |
| Q-LEA-002 *(Example)* | CMP-05 | M3 | "Tell me about a time a team member's performance dropped. What did you do?" | How did you find out? What support did you offer? What was the outcome? | Early conversation, clear expectations, support and documentation, fair outcome | Avoids the conversation or escalates without support |

## 6. Rating scale and behavioural anchors

<!-- Guidance: Use an even-numbered scale so interviewers must decide whether the bar is met. Write anchors that describe observable behaviour for each point. Questions to answer: what does a 3 look like for this competency at this level? Common pitfall: rating the candidate's confidence or similarity to the interviewer rather than the evidence. -->

### 6.1 Scale

| Rating | Label | General anchor |
|---|---|---|
| 1 | Strong no | Clear evidence the candidate does not meet the bar, or a serious concern (for example dismissive of security or of colleagues) |
| 2 | Below bar | Some relevant evidence, but gaps that would need significant support at the target level |
| 3 | Meets bar | Evidence matches the ladder descriptor for the target level in this competency |
| 4 | Above bar | Evidence matches the next level's descriptor in this competency |

Ratings are relative to the **target level** stated on the scorecard. The same answer can be a 3 for L2 and a 2 for L3. "Not assessed" is recorded when the stage did not produce evidence; it is not a 2.

### 6.2 Behavioural anchors per competency (target level L3, *Example*)

| Competency | 1 Strong no | 2 Below bar | 3 Meets bar | 4 Above bar |
|---|---|---|---|---|
| CMP-01 coding | Cannot produce working code for the core case | Working core case; edge cases and tests only with heavy prompting | Correct solution with tests and edge cases; explains complexity and trade-offs | Also improves the problem framing, anticipates production concerns, code is exemplary |
| CMP-01 design | No coherent design | Plausible design for the happy path; failures and data handled only when prompted | Complete design with data model, interfaces, failure handling and rollout; defends trade-offs | Frames options for a multi-team context and shows when to revisit the decision |
| CMP-02 delivery | No example of owning delivery | Delivered own tasks; little planning or risk management | Led a multi-person project, managed scope and risk, communicated proactively | Led delivery across teams; changed how the group plans |
| CMP-04 collaboration | Dismissive or unclear | Clear when prompted; struggles with disagreement | Explains reasoning clearly, listens, resolves disagreement constructively | Aligns several parties and adapts message to audience |
| CMP-05 leadership | No example of helping others | Occasional help to peers | Mentored others with visible growth; contributes to hiring or standards | Grew senior people or leaders; shaped team practices |
| CMP-06 operations and security | No systematic debugging; ignores security | Finds the issue slowly; security only when prompted | Hypothesis-driven debugging, rollback judgement, threat awareness in design, prevention actions | Improves systems and teams so the class of problem does not recur |

## 7. Interviewer scorecard

<!-- Guidance: The scorecard is the evidence record. Questions to answer: are notes factual, is every rating supported by at least one quoted or described observation, and was it submitted before the debrief? Common pitfall: one-word notes ("smart", "not senior") that cannot support a decision or a later review. -->

### 7.1 Scorecard fields

| Field | Content |
|---|---|
| Candidate ID | [CAN-NNNN] (pseudonymous ID; no name in the rating file) |
| Kit and version | [IKT-001 v1.0] |
| Stage and question IDs | [STG-4, Q-DES-001] |
| Interviewer and date | [@interviewer], YYYY-MM-DD |
| Target level | [L3] |
| Evidence notes per competency | What the candidate said and did, with short quotes or descriptions |
| Rating per competency | 1 to 4 or "Not assessed" |
| Overall recommendation | Strong no / No / Yes / Strong yes, for the target level |
| Level signal | [Below / At / Above target level] |
| Adjustments provided | [None / description, no health details] |
| Submitted | Within **[24 hours]** and before the debrief |

### 7.2 Worked example

| Field | Entry |
|---|---|
| Candidate ID | CAN-0187 *(Example)* |
| Stage and question | STG-4, Q-DES-001 |
| Target level | L3 |
| CMP-01 design: evidence | Asked about volume (peak 40 messages per second at sale events), proposed a queue with per-channel workers and idempotency keys, sketched message table and status transitions |
| CMP-01 design: rating | 3 |
| CMP-06: evidence | On SMS outage: retries with backoff, dead-letter queue, alert on queue age; flagged phone numbers as personal data with restricted logging |
| CMP-06: rating | 3 |
| CMP-04: evidence | Summarised trade-offs before choosing; adapted when I challenged cost of the second provider |
| CMP-04: rating | 3 |
| Overall | Yes, at L3 |

## 8. Calibration and debrief protocol

<!-- Guidance: The debrief turns independent evidence into one decision. Questions to answer: who speaks in what order, what is the decision rule, how are levels decided and disagreements recorded? Common pitfall: the most senior person speaks first and others anchor on their view. -->

### 8.1 Interviewer calibration

New interviewers shadow two interviews and reverse-shadow two more before interviewing alone. Every **[quarter]**, interviewers rate the same recorded mock interview (with consenting actors) and compare scores; a spread of more than one point on the same competency triggers a calibration discussion of the anchors.

### 8.2 Debrief sequence

The facilitator runs the debrief in the order below so that the hiring manager and senior interviewers do not anchor the discussion.

```mermaid
sequenceDiagram
    participant F as Facilitator
    participant I as Interviewers
    participant H as Hiring manager
    F->>I: Confirm all scorecards submitted and read
    F->>I: Restate target level, competencies and decision rule
    loop Each competency
        I->>F: Evidence and rating, junior interviewers first
        F->>I: Probe gaps and conflicting evidence
    end
    H->>F: Hiring manager view last
    F->>H: Decision and level recorded against the rule
```

### 8.3 Debrief rules

1. Hold the debrief within **[two working days]** of the last interview. Nobody discusses the candidate before submitting a scorecard.
2. Discuss evidence by competency, not by interviewer. Ratings may change only with a stated reason recorded in the notes.
3. Comments not tied to evidence on the scorecard, or not job-related (accent, appearance, school name, "culture fit", career gaps without job relevance), are stopped by the facilitator.
4. **Decision rule** (*Example*): hire when every must-have competency has a calibrated rating of 3 or 4, no competency is rated 1, and at least half of the overall recommendations are Yes or Strong yes. Any rating of 1 must be discussed and either upheld with evidence or revised with a reason.
5. **Level decision.** Level is set by the profile of calibrated ratings against the ladder's expectations matrix. When evidence sits between two levels, offer the lower level and record the evidence that supports an early review.
6. Record the decision, level, rationale and any dissent in the applicant tracking system within one working day.

### 8.4 Worked debrief outcome

| Competency | STG-2 | STG-3 | STG-4 | STG-5 | STG-6 | Calibrated |
|---|---|---|---|---|---|---|
| CMP-01 coding | 3 | 4 | | | | 3 |
| CMP-01 design | | | 3 | | 3 | 3 |
| CMP-02 | | | 3 | | 3 | 3 |
| CMP-04 | | 3 | 3 | | 2 | 3 |
| CMP-05 | | | 3 | | 3 | 3 |
| CMP-06 | | | 3 | 3 | | 3 |

*Example* for candidate CAN-0187 at target L3. The CMP-04 rating of 2 in STG-6 was discussed; the interviewer noted short answers but no negative evidence, and the panel calibrated to 3 based on stronger evidence in two other stages. The STG-4 ratings for CMP-02 and CMP-05 come from the follow-up probes required by section 3.2 (rollout plan and how the candidate would guide a less experienced engineer through the design), so every must-have has two observations by different interviewers. Overall recommendations: 4 Yes and 1 Strong yes (5 of 5 at Yes or above). All must-haves are at 3 or above and no rating is 1: hire at L3.

## 9. Bias and legal-compliance controls

<!-- Guidance: List concrete controls and who checks them. Questions to answer: is every assessment job-related, is the process the same for everyone, are adjustments offered, and are outcomes monitored? Common pitfall: assuming a structured format alone removes bias; monitor outcomes as well. -->

### 9.1 Controls

| ID | Control | Owner | Evidence |
|---|---|---|---|
| BIA-001 | Job-relatedness: every competency traces to the job description and ladder; every question traces to a competency (section 3.2) | Hiring manager | Coverage matrix |
| BIA-002 | Consistency: same stages, question sets and scale for all candidates on a kit version; deviations recorded with reason | Recruiter | Applicant tracking records |
| BIA-003 | Adjustments: every candidate is asked before the loop whether they need adjustments, and reasonable requests are met (for example extra time, captioning, a different exercise format, breaks) | Recruiter | Adjustment log without health details |
| BIA-004 | Independent scoring before discussion | Facilitator | Scorecard timestamps |
| BIA-005 | Diverse panels where possible, at least two interviewers per must-have competency | Recruiter | Panel list |
| BIA-006 | Interviewer training on structured interviewing, anchors and common biases before first interview and annually | People partner | Training records |
| BIA-007 | Prohibited topics list (9.2) briefed to every interviewer | People partner | Briefing record |
| BIA-008 | Stage pass-through rates monitored by group where lawful; investigate when a group's impact ratio (selection-rate ratio) is below **[0.8]** (*Example* screening threshold); in small samples ratios are unstable, so combine several periods or use a statistical test before concluding | People partner | Quarterly report |
| BIA-009 | Automated or AI tools used in screening or scoring are approved by People and legal, disclosed to candidates and never the sole decision maker. Never use tools that infer emotions from candidates' face, voice or other biometric data (prohibited in the EU workplace context under AI Act Art. 5(1)(f) since 2 February 2025) | Talent acquisition lead | Tool register |

### 9.2 Prohibited and restricted topics

Interviewers do not ask about or record: age, marital or family status, pregnancy or plans for children, religion or belief, sexual orientation, gender identity, race, ethnicity or national origin, disability or health, trade union membership or political opinions. Right-to-work questions are asked by the recruiter, of every candidate in the same way, at the stage set by local law. If a candidate volunteers such information, do not record it or discuss it in the debrief.

### 9.3 Legal context (check local law)

- **UK:** the Equality Act 2010 protects nine characteristics and requires reasonable adjustments for disabled applicants; section 60 restricts questions about health and disability before a job offer, with limited exceptions (such as asking about adjustments needed for the assessment). Acas guidance recommends asking all applicants the same questions and using more than one interviewer where possible.
- **US:** federal law (including Title VII, the ADA and the ADEA, enforced by the EEOC) prohibits discriminatory selection procedures; procedures with adverse impact must be job-related and consistent with business necessity. The Uniform Guidelines on Employee Selection Procedures (29 CFR Part 1607) describe impact monitoring and validation. As of October 2026 the EEOC has announced plans to rescind the Uniform Guidelines and a June 2026 Department of Justice opinion questions parts of them; they remain codified and private Title VII disparate-impact claims remain available. Check their current status.
- **EU:** AI systems intended for recruitment or selection are listed as high-risk under the AI Act (Regulation (EU) 2024/1689, Annex III point 4, employment, workers' management and access to self-employment). After amendment by Regulation (EU) 2026/1744, the high-risk obligations for Annex III systems apply from 2 December 2027; check the consolidated text. Separately, Article 5(1)(f) has prohibited AI systems that infer emotions of people in the workplace (except for medical or safety reasons) since 2 February 2025, which rules out emotion-analysing video-interview tools. The GDPR applies to all candidate data (section 11).

This section is orientation only. Take advice from qualified counsel for each hiring jurisdiction.

## 10. Candidate experience

<!-- Guidance: Treat the process as part of the employer brand and as a fairness control. Questions to answer: does the candidate know what to expect, how long each step takes, and how to ask for help? Common pitfall: long silences after the loop, which candidates read as rejection. -->

| Commitment | Target *(Example)* |
|---|---|
| Acknowledge application | Within 3 working days |
| Share loop outline, stage lengths, allowed languages, AI-assistant policy and preparation notes | At invitation to the technical screen |
| Ask about adjustments | At every scheduling message, in neutral wording |
| Decision after technical screen | Within 5 working days |
| Decision after loop | Within 5 working days of the last interview |
| Feedback offer to declined candidates after the loop | Short written summary of strengths and gaps by competency, where local policy allows |
| Candidate survey | Sent after every loop, results reviewed quarterly |

Interviewers start each stage by introducing themselves, stating the format and time, and leaving at least five minutes for the candidate's questions. Do not ask candidates to repeat a stage because of interviewer no-shows; reschedule promptly and apologise.

**Communication template for the loop invitation.** "You will meet [number] interviewers over [total time]. Each session covers one area: [list]. You may use [languages] and [AI-assistant policy]. If you need any adjustments for any part of the process, tell us at [contact] and we will arrange them. You do not need to tell us why."

## 11. Data protection and retention

<!-- Guidance: Say what data is created, where it lives, who can see it and when it is deleted. Questions to answer: what is the lawful basis, how long are scorecards kept, and how do candidates exercise their rights? Common pitfall: interview notes kept in personal documents and chat threads outside the applicant tracking system. -->

### 11.1 Data inventory

| Data | Location | Access | Retention *(Example)* |
|---|---|---|---|
| Application and CV | Applicant tracking system (ATS) | Recruiter, hiring manager, panel | [6 months] after the final decision for unsuccessful candidates, unless the candidate consents to longer talent-pool retention |
| Scorecards and debrief notes | ATS only | Panel, facilitator, People | Same as above; moved to the employee file for hires per People policy |
| Exercise code and diagrams | ATS attachment or a time-limited repository | Panel | Same as above |
| Adjustment requests | ATS restricted field | Recruiter, People | Same as above, no medical details recorded |
| Recordings (only with consent) | [Approved storage] | Named reviewers | [30 days] or end of the stated purpose |
| Aggregated fairness data | People analytics | People team | Aggregates only, groups under [5] suppressed |

Retention periods are *Example* values. Set them with People and legal counsel to cover the period in which a selection decision can be challenged in each jurisdiction, and no longer (GDPR Article 5(1)(e) storage limitation, where it applies).

### 11.2 Rules

1. Notes are written only in the ATS scorecard. Personal notebooks, chat messages and private documents are not used for candidate evaluation.
2. Notes are factual and professional, written on the assumption that the candidate may request a copy.
3. Candidates are told in the privacy notice what is collected, why, for how long and how to request access or deletion.
4. Requests for access, correction or deletion are routed to [privacy contact] and answered within the legal deadline.
5. No candidate data is entered into external AI tools unless the tool is approved under BIA-009 and the privacy notice covers it.

## 12. Interviewer training and kit quality

<!-- Guidance: Measure whether the kit predicts job success and treats candidates fairly, then improve it. Questions to answer: which metrics show the kit works, how often is the question bank refreshed, and who acts on the results? Common pitfall: never reviewing the kit, so leaked questions and drifting anchors persist. -->

### 12.1 Interviewer readiness

| Step | Requirement |
|---|---|
| Training | Structured interviewing, this kit's anchors, prohibited topics, adjustments and data rules |
| Shadowing | Two shadow and two reverse-shadow interviews with an experienced interviewer |
| Sign-off | Hiring manager or facilitator confirms readiness |
| Refresh | Annual refresher and quarterly calibration exercise |

### 12.2 Quality metrics

| Metric | Formula | Target *(Example)* |
|---|---|---|
| Scorecard timeliness | scorecards submitted within 24 hours / all scorecards | ≥ 95% |
| Inter-rater spread | share of competencies where panel ratings differ by more than one point | ≤ 10% |
| Stage pass-through | candidates advancing from a stage / candidates entering it | Tracked per stage; review sudden changes |
| Offer acceptance | offers accepted / offers made | Tracked trend |
| Candidate satisfaction | mean survey score (1 to 5) | ≥ 4.0 |
| Early hire success | hires rated "meets" or better at the first performance review / all hires reviewed | ≥ 85%; compare by stage rating to test predictiveness |
| Impact ratio by group | pass rate of group / highest group pass rate, per stage | Investigate below 0.8; in small samples combine periods or use a statistical test |

### 12.3 Review cadence

Review the kit every **[six months]** or after **[20]** completed loops, whichever is sooner: retire leaked or non-discriminating questions, add new ones with IDs, check anchors against recent debriefs, and update the revision history. Major changes (competencies, decision rule, stage list) are approved again by the approvers in Document control and apply only to candidates who start the process after the change.

## 13. Glossary and references

<!-- Guidance: Define the terms used in debriefs and cite the sources consulted. -->

### 13.1 Glossary

| Term | Definition |
|---|---|
| Adverse impact | A substantially lower selection rate for one group than for another, which should trigger investigation |
| Impact ratio | One group's selection rate divided by the highest group's rate (four-fifths screening signal) |
| Anchor | A written description of observable behaviour for one point on the rating scale |
| ATS | Applicant tracking system |
| Debrief | Meeting where the panel turns independent evidence into a decision |
| Facilitator | Trained interviewer who runs the debrief and enforces the protocol |
| Reasonable adjustment (accommodation) | A change to the process that removes a disadvantage for a disabled candidate |
| Reverse shadow | A new interviewer leads while an experienced interviewer observes |
| Structured interview | An interview with predetermined, job-related questions, consistent administration and anchored scoring |

### 13.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| Acas, *Interviewing job applicants*, acas.org.uk/hiring-someone/interviewing-job-applicants | Page updated 2026-06-30 | Same questions where possible, more than one interviewer, adjustments, secure notes |
| Equality Act 2010 (UK), sections 20 and 60, legislation.gov.uk | Current consolidated text | Reasonable adjustments and pre-offer health questions |
| Uniform Guidelines on Employee Selection Procedures (1978), 29 CFR Part 1607 | Checked 2026-10-24; EEOC rescission planned and June 2026 DOJ opinion questions parts: check current status | Impact information (1607.4), validity (1607.5), documentation (1607.15) |
| US EEOC, *Employment Tests and Selection Procedures* fact sheet, eeoc.gov | Fact sheet first issued 2007; check current page | Job-relatedness and business necessity, less discriminatory alternatives |
| Regulation (EU) 2016/679 (GDPR), Article 5(1)(e), eur-lex.europa.eu | Current text | Storage limitation for candidate data |
| Regulation (EU) 2024/1689 (AI Act), Article 5(1)(f) and Annex III point 4, as amended by Regulation (EU) 2026/1744, eur-lex.europa.eu | Art. 5 applies since 2025-02-02; Annex III obligations from 2027-12-02; check consolidated text | Emotion-recognition prohibition and high-risk classification of recruitment AI |
| Engineering Career Ladder (`career/engineering-career-ladder`) | This collection | Level and competency IDs |

## Standard and licence note

Structure aligned with widely published structured-interview good practice and with fair-selection guidance from UK Acas and the US Uniform Guidelines on Employee Selection Procedures (29 CFR Part 1607, a US government publication, whose rescission the EEOC has announced it plans), with legal orientation from the UK Equality Act 2010, the GDPR and the EU AI Act. These sources are cited for context only; no text is reproduced. All questions, anchors and examples are original text written for this collection. Check the current official versions and the law of each hiring jurisdiction before use. This is a documentation format, not legal advice. Template licence: MIT.