Behavioural Interviews

Interviewers probe because the first answer rarely contains all the evidence. Expect, and welcome, these:

• "What did you do, specifically?": your "we" hid your part. Answer with "I" and actions.
• "Why did you choose that?": they want your reasoning and the alternatives you rejected.
• "What was the result? How did you measure it?": give the number and how you know it.
• "What would you do differently?": a test of self-awareness; "nothing" is a weak answer.
• "What did the other person think?": a test of empathy in conflict stories.
• "Tell me more about…": something you said was interesting or unclear; go one level deeper.
• "Can you give me another example?": the first story didn't fit the competency, or they want to see a pattern.

Prepare each story so you can go three levels deep on its key decision: what you did, why, and what you knew at the time that made it the right call.

In a structured process each interviewer usually writes up their notes and a score before hearing anyone else's view, so the first strong opinion in the room doesn't anchor everyone. Then there's a debrief: interviewers compare evidence competency by competency, and the hiring manager (or a hiring committee) decides. Two things follow for you:

• Each interviewer is scoring only their competencies. The engineer asking about code review may not be assessing conflict at all. Answer the question asked, with the competency in mind, rather than squeezing your best story into every answer.
• Evidence is compared across interviewers. If you told one interviewer a migration took three months and another that it took six, someone will notice. Consistency comes from preparation: the same stories, the same numbers.

Lead roles blur the line. A system design or API design round often ends with "How would you get the team to build this?" or "The platform team disagrees with your design; what do you do?", and a coding round may ask how you'd review the code you just wrote. Treat these as short behavioural questions: a sentence of approach, then "for example, when I…" with a one-minute real story. Candidates who can design a good API and explain how they'd land it with two teams in two time zones are exactly what a lead loop is looking for.

The best way to feel how scoring works is to sit on the other side. Give a friend or colleague this sheet and a few questions from the question bank, and ask them to fill it in while you answer, exactly as an interviewer would.

## Mock interview: <date>    Interviewer: <name>    Competencies: <2–3 from the question bank>

Question 1: <question>
  Notes (what they said, close to their words):
  -
  Evidence for <competency A>:            Level: poor / borderline / solid / outstanding
  Evidence for <competency B>:            Level:
  Follow-ups asked and how they held up:
  Time taken: <min:s>     "We" vs "I":     Result had a number? yes / no

Overall: what was strongest, what was missing, which story to replace.

• Blaming others, or describing colleagues and clients with contempt.
• No personal action ("the team decided", "management wanted").
• No result, or a result that's only "we shipped it".
• Stories that are all from many years ago, or all from the same project.
• Sharing confidential details (client names under NDA, internal numbers, security issues).
• Inconsistency: a number that changes between the first answer and a follow-up.
• Answers that are obviously rehearsed scripts and fall apart at the first follow-up.

They're the same idea; pick one and practise it until the shape is automatic. For a lead role, STAR with a learning fits nearly every question.

Checking a draft before you rehearse it

Writing your story out first and then checking its proportions catches the common mistakes before you rehearse them into habit. This model checks two drafts of the same story. Both drafts are illustrative, not yours: they're invented to show what the checks catch.

// Checks a STAR draft before you rehearse it: length, speaking time, where the time goes, "I" vs "we" in the
// Action, and whether the Result has a number. 140 words a minute is a rule of thumb for calm speech; change it.
const WPM = 140;
const words = (t) => t.split(/\s+/).filter(Boolean);
const count = (t, re) => (t.match(re) || []).length;

function check(title, story) {
  const parts = Object.entries(story).map(([k, t]) => [k, words(t).length]);
  const all = parts.reduce((s, [, n]) => s + n, 0);
  const share = Object.fromEntries(parts.map(([k, n]) => [k, Math.round((100 * n) / all)]));
  const secs = Math.round((all / WPM) * 60);
  console.log(`${title}: ${all} words ≈ ${Math.floor(secs / 60)} min ${secs % 60} s`);
  console.log("  " + parts.map(([k]) => `${k} ${share[k]}%`).join("  "));
  const warn = [];
  if (secs > 150) warn.push("over 2½ minutes: cut the situation, keep the action");
  if (share.situation + share.task > 35) warn.push(`set-up is ${share.situation + share.task}% of the answer (aim for 20–30%)`);
  if (share.action < 45) warn.push(`action is only ${share.action}% (aim for about half)`);
  const i = count(story.action, /\b(I|I'm|I'd|my)\b/g), we = count(story.action, /\b(we|our|us)\b/gi);
  if (we > i) warn.push(`action says "we" ${we}× and "I" ${i}×: say what you did`);
  if (!/\d|\b(one|two|three|four|five|six|seven|eight|nine|ten|twice|half)\b/i.test(story.result)) warn.push("result has no number");
  console.log(warn.length ? warn.map((w) => `  ⚠ ${w}`).join("\n") : "  ✓ no warnings");
}

check("Draft 1", {
  situation: "We were a team of nine, six in Pune and three in Austin, building the web admin UI and the REST API for a device. The product had a long history, the codebase was large, the tests were slow, there were two release trains, and the client's team reviewed some of the pull requests too, which made things complicated for everyone.",
  task: "Reviews were slow and people were frustrated.",
  action: "We talked about it in a retro and we agreed to make pull requests smaller. We also set up some automation and our reviews got better.",
  result: "Reviews got a lot faster and the team was happier.",
});
check("Draft 2", {
  situation: "A nine-person team, six engineers in Pune and three in Austin, building a device's web admin UI and REST API.",
  task: "As the lead, I owned delivery, and pull requests were waiting about two days for a first review because the only overlap was ninety minutes a day.",
  action: "I pulled a month of pull request data and showed the team that the slow ones were the large ones. I proposed a 400-line soft limit and wrote the checklist for splitting changes. I moved my own review time to the start of the India day so their pull requests were reviewed before they logged off, and I paired two Pune seniors with me on reviews until they could approve on their own. I added lint and type checks to CI so humans stopped commenting on formatting.",
  result: "Within six weeks the median wait for a first review went from about two days to under four hours, and two more reviewers could approve. What I'd do sooner: share the data before proposing the rule.",
});

Draft 1: 104 words ≈ 0 min 45 s
  situation 59%  task 7%  action 25%  result 10%
  ⚠ set-up is 66% of the answer (aim for 20–30%)
  ⚠ action is only 25% (aim for about half)
  ⚠ action says "we" 4× and "I" 0×: say what you did
  ⚠ result has no number
Draft 2: 170 words ≈ 1 min 13 s
  situation 12%  task 16%  action 51%  result 21%
  ✓ no warnings

Three question types trip people up because the "result" isn't a win. They still use STAR, but the emphasis moves.

FAILURE ("Tell me about a time you failed / made a mistake")
  S/T   the situation and what was riding on it (short)
  A     what I did that caused or contributed to it: owned in the first person
  R     the real impact (don't minimise it), and what I did to fix it
  L     what I changed afterwards, and evidence that it stuck   ← most of the score

CONFLICT ("Tell me about a disagreement with a colleague / another team")
  S/T   what we disagreed about, and why it mattered
  A     how I understood their view (restate it fairly); how I made my case (evidence);
        how it was decided (who, how)
  R     the outcome AND the relationship afterwards
  L     what I'd do differently

FEEDBACK ("Tell me about critical feedback you received")
  S     the feedback, as specifically as I can quote it, and who gave it
  A     my honest first reaction, then what I did with it
  R     what I do differently now, with an example of it since

Results with numbers are easier to score, but only if they're true and you can say how you know them. Useful kinds of number for a lead full stack role:

• Time: build time, review wait, release cycle, time to onboard a new engineer, time to restore after an incident.
• Quality: escaped defects, flaky test rate, support tickets on a feature, crash or error rate.
• Scale: devices or users affected, number of endpoints or settings, team size, number of teams involved.
• People: engineers who can now approve PRs or own an area, promotions you supported, attrition on your team.
• Delivery: milestones hit, scope delivered against plan, slip reduced.

If you didn't measure it, say what you observed and how ("the stand-up stopped having review blockers most days"), or give an honest approximation ("roughly halved, from the PR timestamps"). Never invent a precise figure: the follow-up "how did you measure that?" is common, and an answer that falls apart there costs more than the number gained.

Some interviewers, especially hiring managers with a long list or a client stakeholder in a short slot, ask many quick questions. Every story in your bank should also have a 30-second version: the headline, the one or two actions that matter most, and the result. For the illustrative review story above: "I cut first-review waits on a US–India team from about two days to under four hours, mainly by showing the team the data on PR size and moving my review time to the start of the India day. Happy to go into how." That's about 40 words. If they want more, they'll ask, and you'll have the full version ready.

Practise moving between the two lengths on purpose. Being able to shorten a story without losing the evidence is the same skill as writing a good bottom line in a status update: lead with the result, keep only what supports it.

When the interviewer probes, answer the question asked in the first sentence, then give the detail. Using the illustrative review story: "Why did you choose a soft limit rather than a hard one?" → "Because a hard limit would have blocked generated files and migrations, and I didn't want people gaming it. In practice…". If you don't remember a detail, say so; "I don't remember the exact number, it was around…" is fine. If a follow-up reveals a mistake you made, own it plainly; that's often the evidence the interviewer was looking for.

Other openers to prepare, with what's behind them:

1. Technical leadership of the web UI and API workstreams

Likely follow-ups: "What did you delegate, and what did you keep?", "How did you know it was going off track?", "What would you do differently?"

Likely follow-ups: "How did you version it?", "How did you find out who was using it?", "What would you do differently for devices that stay on old firmware for years?"

3. Legacy migration and working with Android platform teams

Likely follow-ups: "How did you decide what 'parity' meant?", "How did you test on real devices?", "What did you do when the other team's priorities didn't match yours?"

Likely follow-ups: "How do you tell a blocker from a preference?", "How do you review AI-generated code?", "What did you automate?"

Likely follow-ups: "Revert or fix forward, and why?", "How did you keep main deployable?", "What gates did you require before merge?"

Likely follow-ups: "Unit or integration for that, and why?", "How did you test against a device or a dependency you couldn't run in CI?", "What's your view on coverage targets?"

Likely follow-ups: "How do you estimate work nobody has done before?", "What do you do when velocity is used as a target?", "Scrum or Kanban for a team like this, and why?"

Likely follow-ups: "How did you know they were stuck when they didn't say so?", "How do you keep quality consistent without reviewing everything yourself?", "What did you change in your own working hours?"

Likely follow-ups: "What did they think of you afterwards?", "What would you do if they'd refused?", "How did you keep your own team motivated through it?"

Likely follow-ups: "How did you decide what to stop doing?", "What did you write down for the next person?", "How did you know your assumptions were right?"

Likely follow-ups: "What do you never let it do?", "How do you review a large AI-generated PR?", "How would you measure whether it's helping?"

Expect some "What would you do if…" questions mixed in, especially about the role itself. Answer those with a plan and a short real example of when you did something similar: a plan backed by evidence scores higher than either alone. A shape that works for any scenario:

1. Clarify (one question, or state an assumption): "I'd first want to know whether …; assuming …"
2. First moves (what I'd do this week, in order, with why)
3. Who I'd involve (my team, the client's owner, my manager) and how
4. How I'd know it's working (a signal or a number), and when I'd change course
5. Evidence: "I did something similar when …" (a 30-second real example)

Scenarios this role makes likely, with what a strong answer covers (the outline of an answer, not a script):

Some questions test fit for the specific shape of the job: "You've been a hands-on full stack engineer; why do you want to lead?", "How will you lead a team in India from the US?", "You haven't worked on video-conferencing devices; how will you get up to speed?". They're fair questions, and the honest answer is usually the best one: what you've already done that's closest (with a story), what's genuinely new to you, and how you'd learn it quickly. The APIs & Devices course has a topic on framing full stack experience for a device platform; use it to prepare the technical half of that answer.

These are questions to ask yourself, one requirement at a time. Not every prompt will produce a story; you're looking for the ones that make you think "yes, that time…". Note every candidate in one rough list first, then write up the best 8–12 with the template.

1. Leading a workstream (lead)

• When were you the person others came to for a part of the system? What did you decide there that others followed?
• When did you turn a vague goal ("modernise the admin UI") into a plan with milestones? What did you leave out, and why?
• When did a project you led go off track? When did you first notice, and what did you do in the next 48 hours?
• When did you choose to do less (cut scope, delay a feature) to protect quality or a date? Who did you have to convince?
• What's something you built yourself as a lead because it was too risky to delegate, and something you handed off that you'd normally have done?

2. APIs (api)

• Which API you built had the most consumers you'd never met? How did you learn what they needed?
• When did you have to change an interface without breaking its users? What rules did you follow?
• When did an API or integration you owned break something in production? What did you change afterwards?
• When did you integrate with a badly documented system? How did you work out how it really behaved?
• Have you built anything that wasn't HTTP: sockets, a CLI, a command protocol, a device or hardware integration, an app talking to Bluetooth or USB? What was hard about it?

3. Migration and platform teams (migrate)

• When did you move something to a new framework, platform or OS version? How did you define "done" (parity)?
• When did a platform change (an OS update, a library major version, a cloud deprecation) break your work? How did you find out, and how fast?
• When did your delivery depend on another team's? What did you do to avoid waiting?
• When did you work closely with people in a different specialisation (mobile, firmware, infrastructure, hardware)? What did you have to learn about their constraints?
• If you've built and shipped Android apps yourself: when did an Android version change force you to rework something? What did you learn about planning for the next one?

4. Code review and standards (review)

• Which review you gave changed someone's design, not just their code? How did you raise it?
• Which practice or standard did you introduce that's still in use? How did you get people to adopt it?
• When did you give review feedback that was hard to give? How did you say it, and how did it land?
• When was a reviewer right about your code and you wrong at first?
• When did you replace a recurring review comment with a tool (a lint rule, a CI check, a template)?

5. Git, PRs and CI/CD (cicd)

• When did you make a build or a release faster or more reliable? What did you measure first?
• When did main break or a release go wrong on your watch? What did you do in the first hour?
• When did you set up or change a team's branching, PR or release process? Why that way?
• When did you track down a flaky test or pipeline problem properly instead of re-running it?

6. Testing (test)

• When did a test you (or your team) wrote catch something serious before users saw it?
• When did you add tests to code that had none? Where did you start?
• When did a bug escape despite tests? What test did you add, and what did you change about how the team tests?
• When did you have to test something that was hard to test (hardware, a third-party API, time, concurrency)? How?

7. Agile delivery (agile)

• When did a sprint or release miss its goal? What did you do in the retrospective?
• When did you push back on an estimate or a deadline? What evidence did you use?
• When did you break a big, vague piece of work into something deliverable in a sprint or two?
• When did a process change you proposed actually stick?

8. Mentoring and distributed teams (mentor)

• Who is better at something today partly because of you? What exactly did you do, and over how long?
• When did you work with a team many hours away? What did you change about how you communicated?
• When did you delegate something important and it went differently from how you'd have done it? What did you do?
• When did you give feedback to someone whose communication style or culture differed from yours?
• When did you onboard someone new? How long until their first real contribution, and what helped?

9. Client and stakeholder communication (client)

• When did you disagree with another team, a client or a senior person on a technical decision? What happened?
• When did you have to deliver bad news (a slip, a bug, a cost)? How early, and how did you say it?
• When did you explain a technical choice to someone non-technical, and they made a decision from it?
• When did you have to escalate? What had you tried first?
• When did you earn the trust of a team you didn't manage? What did you do that made the difference?

10. Ambiguity and shifting priorities (ambiguity)

• When did priorities change mid-stream? How did you handle it with your team?
• When did you deliver something with unclear requirements? What did you write down and confirm?
• When did you have to get productive in an unfamiliar codebase or domain quickly? What was your method?
• When did you make a decision without all the information you wanted? How did it turn out?

11. AI-assisted development (ai)

• Which concrete tasks do you use an AI coding assistant for today? Pick one and remember a specific instance.
• When did an assistant produce something plausible but wrong? How did you catch it?
• When did using an assistant make you noticeably faster on something, and how do you know?
• What have you built or tried while learning MCP? (Only what you've actually done; if nothing yet, this is the gap to close before the interview.)

Your memory is the worst index of your own work. Before writing, spend an hour skimming the records: your Git history and merged PRs (git log --author across the repos you worked in, and your PR list on the hosting service), old performance reviews and self-assessments (which already contain stories and numbers), release notes and changelogs you wrote, incident write-ups you were part of, design docs and ADRs with your name on them, messages where someone thanked you, and the apps and side projects you built and shipped yourself. Note dates and numbers as you go: they're much harder to recover later.

Checking the grid

Once you have a rough list, check coverage against the requirements. This model shows the idea with placeholder stories; replace them with the titles and tags from your own notes.

// Which job requirements does your story bank cover, and where is it thin? Replace the stories below with the titles
// and tags of the stories in your My notes page (the tags line of the template). Letters stand in for your titles.
const requirements = {
  lead: "Lead web UI + API work",
  api: "REST / Telnet APIs",
  migrate: "Legacy migration, Android teams",
  review: "Code review + standards",
  cicd: "Git, PRs, CI/CD",
  test: "Unit + integration tests",
  agile: "Agile / Scrum delivery",
  mentor: "Mentor India-based devs",
  client: "Client engineering team",
  ambiguity: "Shifting priorities, thin docs",
  ai: "Copilot / MCP",
};
const stories = [
  { title: "Story A", tags: ["lead", "migrate", "ambiguity"] },
  { title: "Story B", tags: ["review", "mentor", "cicd"] },
  { title: "Story C", tags: ["client", "lead"] },
  { title: "Story D", tags: ["api", "test"] },
  { title: "Story E", tags: ["mentor"] },
  { title: "Story F", tags: ["ambiguity", "agile", "client", "lead", "test"] },
];

for (const s of stories) for (const t of s.tags) if (!requirements[t]) throw new Error(`${s.title}: unknown tag ${t}`);
const width = Math.max(...Object.values(requirements).map((r) => r.length));
for (const [key, label] of Object.entries(requirements)) {
  const using = stories.filter((s) => s.tags.includes(key)).map((s) => s.title.replace("Story ", ""));
  const flag = using.length === 0 ? "GAP: write one" : using.length === 1 ? "thin: find a second" : "ok";
  console.log(`${label.padEnd(width)}  ${(using.join(" ") || "-").padEnd(7)} ${flag}`);
}
const heavy = stories.filter((s) => s.tags.length >= 5).map((s) => s.title);
if (heavy.length) console.log(`\nLeaning on one story for many answers: ${heavy.join(", ")}. Interviewers notice repeats.`);

Lead web UI + API work           A C F   ok
REST / Telnet APIs               D       thin: find a second
Legacy migration, Android teams  A       thin: find a second
Code review + standards          B       thin: find a second
Git, PRs, CI/CD                  B       thin: find a second
Unit + integration tests         D F     ok
Agile / Scrum delivery           F       thin: find a second
Mentor India-based devs          B E     ok
Client engineering team          C F     ok
Shifting priorities, thin docs   A F     ok
Copilot / MCP                    -       GAP: write one

Leaning on one story for many answers: Story F. Interviewers notice repeats.

Here is the template filled in, so you can see the level of detail to aim for. Illustrative, not yours: this is an invented engineer's story (the same one as Draft 2 in the STAR checker), not something to borrow. Your stories come from your own work.

## Story: Review turnaround across time zones        (ILLUSTRATIVE — invented example)
Tags: review, mentor, cicd, lead
When / where: <year>, a device web UI/API project, 9 engineers (6 Pune, 3 Austin)

**Headline:** I got first-review waits from about two days to under four hours by changing PR size,
review timing and who could approve.

**S:** Nine-person team across Pune and Austin; 90 minutes of overlap a day.
**T:** As lead I owned delivery; PRs waited ~2 days for a first review and work piled up.
**A:**
1. I pulled a month of PR data, because I suspected size, not people, was the problem: it was.
2. I proposed a 400-line soft limit and wrote a splitting checklist, because a rule needs a how-to.
3. I moved my review hour to the start of the India day, so their PRs were reviewed before they logged off.
4. I paired two Pune seniors with me on reviews until they could approve alone, to remove me as the bottleneck.
5. I added lint and type checks to CI, so reviewers stopped spending comments on formatting.
**R:** In six weeks the median first-review wait fell from ~2 days to under 4 hours (PR timestamps);
two more approvers.
**L:** I'd share the data before proposing the rule; the first proposal got pushback until people saw it.

**Follow-ups:** why a soft limit; what about generated files; how the seniors felt about being reviewers;
what happened to large refactors.
**Numbers:** ~2 days → <4 h median; 400 lines; 6 weeks; 2 new approvers. Source: PR timestamps.
**Careful:** don't name the client.
**Fits:** improved how the team works; mentoring; code review standards; working across time zones.

You'll often want to tell a story about a client, a product that isn't public, or an incident. Interviewers don't need names, and sharing confidential details is itself a red flag: it suggests you'd do the same with theirs. Decide in advance, in each story's "Careful" line, how you'll describe things:

• Clients and products: "a large device manufacturer", "a payments client", "an internal admin tool".
• Numbers: relative rather than absolute ("roughly halved", "from about two days to a few hours") when absolute figures are internal.
• Security issues: the class of problem and what you did ("an authorisation check missing on one endpoint"), never details that could still be exploited.
• People: roles, not names ("a senior engineer on the client's platform team").

If an interviewer presses for a detail you can't share, say so plainly: "I can't share the client's name, but the scale was about…". That's a good signal, not an evasion.

The morning of an interview, one page beats twenty notes. Make it a pinned note in My notes:

## Interview day: <company>, <date>, <interviewers and their focus if known>

Tell me about yourself: <3 headline phrases>
Why this role: <2 reasons, specific to the role>

Story headlines (title → tags → the number):
- <Story 1> → lead, client → <number>
- <Story 2> → review, mentor → <number>
- <…>

Failure story: <title>     Conflict story: <title>     Feedback story: <title>
Gap answer (MCP): <what I've done / what I know / how I'd close it>

Questions to ask: <3 for each interviewer>
Logistics: <link, time zone, phone number if the call drops>

Rehearsing

1. Say each story out loud, standing up if it helps, and time it. Aim for about two minutes.
2. Record yourself once (audio is enough). Listen for "we", for missing results, and for the bit where you rush.
3. Have someone ask you the follow-ups, or ask yourself the "Follow-ups I can answer" list. Answer the question asked in the first sentence.
4. Practise choosing: take a random question from the bank, pick a story in five seconds, say the headline. That's the skill on the day.
5. Don't memorise word for word. Memorise the headline, the action steps and the numbers; let the sentences be fresh each time. Scripts sound like scripts and break at the first interruption.
6. The night before, reread only the pinned notes: the headlines, the numbers, the "Careful" lines.

The answers to your questions are data about the job. Some patterns are worth noticing (they're not verdicts; ask a follow-up before concluding anything):

• Anything answered on their website or in the job description (it shows you didn't prepare).
• "What does the company do?" in any form.
• Questions that sound like you're already planning to leave the role ("How soon can I move to another team?").
• Salary, leave and perks in a technical round with engineers, unless they bring it up.
• Yes/no questions that end the conversation ("Do you use Agile?"). Ask "How does planning work for the team?" instead.