Behavioral Mock Question Bank

Scope — Twenty-five classic behavioral questions for mock practice, each with a complete sample answer at the entry level (L3 / new grad), the follow-ups an interviewer is likely to ask, and why the answer scores. The rubrics, answer patterns and story-bank method live in the two company guides; this file is the drill set. See also: googleyness.md — what Google’s round scores and the clarify → options → decide → follow-through pattern; amazon_leadership_principles.md — the sixteen principles each question maps to.

1. How to Run a Mock

1. Pick three to five questions from the index below, mixing themes. A real round asks four to six in 45 minutes.
2. Have a partner read the question aloud, or read it yourself and start a timer. Do not look at the sample answer first.
3. Answer in two to three minutes with your own story. Over three minutes means the situation is too long.
4. Take the follow-ups. The partner picks two from the question’s list and keeps asking “why?” until the story runs out of detail.
5. Score it with the table below, then read the sample answer and note one thing it does that yours did not.

Key point — The sample answers are a model of shape, not stories to memorise. An interviewer probes for detail you can only have if it happened to you, so a borrowed story collapses on the second “why?”.

2. Question Index

3. Openers

These open most rounds. They are not scored on a trait so much as they set the interviewer’s first impression and hand them topics to probe.

Q1. Tell me about yourself

Probes — Google: motivation · Amazon: none directly; it seeds the questions that follow

Sample answer

I’m a final-year computer science student. Most of what I’ve built has been on the backend: last summer I interned on a payments team, where I moved a reconciliation report from a nightly batch to an hourly job, which cut the time finance waited for numbers from a day to an hour. Before that I was a teaching assistant for our data structures course for two semesters, which is where I learned to explain an idea three different ways until one lands. Outside class I contribute to an open-source Python linter; I’ve had six pull requests merged, mostly new rules and their tests. What I’m looking for next is a team where I can work on systems that many people depend on, and get regular code review from engineers who are better than me.

Follow-ups to rehearse

• What was the hardest part of the reconciliation change?
• Why backend rather than frontend?
• What did teaching change about how you write code?

Why it scores — Ninety seconds, present → past → future, and every line is a hook the interviewer can pull on. It names results, not job titles.

Q2. Why this company?

Probes — Google: motivation · Amazon: Customer Obsession

Sample answer

Two reasons, both about the work. First, scale: the problems I enjoyed most in my internship were the ones where a small inefficiency mattered because it ran millions of times, and here that is the normal case rather than the exception. Second, the engineering culture I’ve seen from the outside — design docs, code review on every change, and a habit of writing up incidents without blame. I read the public postmortem on a storage outage last year and it was the first time I saw a team explain a failure that plainly. I want to learn in that environment early in my career, and I think my habit of writing tests and docs for my own changes fits it.

Follow-ups to rehearse

• Which team or product would you most want to join, and why?
• What would make you leave after a year?
• What do you know about how we build software that most candidates don’t?

Why it scores — Specific reasons tied to the work and to something the candidate has already done. No mention of perks, prestige or the brand.

Q3. Tell me about a project you are proud of

Probes — Google: motivation · Amazon: Deliver Results, Ownership

Sample answer

Situation — For our operating-systems course, teams of three built a small file system. Most teams passed the test suite and stopped.

Task — I owned the block allocator and the crash-recovery path, the part most teams skipped because the tests barely covered it.

Action — I wrote a test harness that killed the process at random points during a write and then checked the disk image for consistency. The first run corrupted the image in 14 of 200 trials. I traced it to writing the inode before the data block, reordered the writes and added a simple journal for metadata. I reran the harness after every change and kept a table of failure counts in our README so my teammates could see the trend.

Result — The final version survived all 1,000 trials. The professor used our harness as a reference for the next year’s course. I’m proud of it because nobody asked for it: the grade did not depend on it, and it was the first time I tested for a failure instead of for a feature.

Follow-ups to rehearse

• Why did writing the inode first corrupt the image?
• What would you build differently now?
• How did you split the work with your two teammates?

Why it scores — It shows ownership beyond the grade, a measurable before and after, and technical depth the interviewer can probe. The candidate also says why they are proud, which is the real question.

4. Collaboration and Conflict

Q4. Tell me about a time you disagreed with your manager

Probes — Google: challenging the status quo · Amazon: Have Backbone; Disagree and Commit

Sample answer

Situation — In my internship, my manager wanted my project, an internal admin page, to add a CSV export button that pulled every row in the table.

Task — I was building the feature, and I thought pulling every row would time out once the table grew.

Action — Rather than argue the point in the abstract, I measured it. I loaded a copy of production data into staging and timed the query: 40 seconds for the current 2 million rows, against a 30-second request limit. I brought the numbers to our one-to-one with two options: a paginated export, or a background job that emailed a file. My manager pointed out something I had missed — the users only ever wanted the last 30 days. So we agreed on a date-filtered export, which was simpler than both of my options.

Result — It shipped in a week and returns in under two seconds. I learned to bring data and an open question to a disagreement; my manager had context I didn’t, and the best answer came from combining the two.

Follow-ups to rehearse

• What would you have done if your manager had said “ship it as it is”?
• How did you raise it without it sounding like you were saying no?
• Was there anything you got wrong?

Why it scores — The disagreement is backed by a measurement, delivered with options rather than a veto, and the candidate gives the manager credit for the better idea. That is backbone without ego.

Q5. Tell me about a time you worked with someone difficult

Probes — Google: collaboration · Amazon: Earn Trust

Sample answer

Situation — In a semester-long software-engineering project, one teammate rejected most of the pull requests the rest of us opened, often with a one-line comment like “not how I’d do it”.

Task — I was the one opening the most pull requests, and our velocity had dropped to about two merged changes a week.

Action — I asked him for a coffee instead of replying in the review thread. It turned out he had been blamed for a broken build in an earlier course and was afraid of it happening again. I suggested we write down the standards he cared about — tests for every new function, no direct database calls from handlers — as a short checklist in the repo, and add a CI job that ran the tests on every pull request. I also asked him to pair with me on the next feature so he could see how I worked.

Result — Reviews went from “not how I’d do it” to specific comments against the checklist, and we merged nine changes the following week. He became our most useful reviewer. I learned that “difficult” behavior usually has a reason, and that it is faster to ask for it in person than to fight it in comments.

Follow-ups to rehearse

• What would you have done if the coffee had not helped?
• Did you involve the instructor or anyone else?
• What did you have to change about your own pull requests?

Why it scores — The candidate looks for the other person’s reason first, turns a personal friction into a shared process, and describes the relationship afterwards. The other person is not the villain of the story.

Q6. Tell me about a time a teammate was not pulling their weight

Probes — Google: collaboration · Amazon: Ownership, Earn Trust

Sample answer

Situation — During a four-week hackathon-style course project, one of our four members had not pushed any code by the end of week two.

Task — I was coordinating the board, and his part, the notification service, blocked our demo.

Action — I messaged him privately rather than raising it at stand-up. He told me he was working twenty hours a week at a part-time job and had underestimated the task. We split his work: he kept the email templates, which he could do in short blocks, and I took the queueing logic, which needed longer focus. I updated the board so the team saw the new split, without explaining his personal situation to everyone. I also moved our check-ins to evenings, when he was free.

Result — The service was done three days before the demo and he presented it. I learned to ask what is in the way before assuming it is effort, and to fix the plan rather than the person.

Follow-ups to rehearse

• At what point would you have gone to the instructor?
• How did the rest of the team feel about you taking on extra work?
• What would you do if he had not responded at all?

Why it scores — Private before public, a concrete re-plan, discretion about a teammate’s situation, and ownership of the outcome rather than of blame.

5. Failure, Mistakes and Feedback

Q7. Tell me about a time you failed

Probes — Google: feedback and growth · Amazon: Learn and Be Curious, Earn Trust

Sample answer

Situation — In my second year I led a team of three in a university app competition, building a study-group matching app.

Task — I set the scope and the timeline, so the plan was mine.

Action — I planned eight features, and we spent the first five weeks of eight building all of them half-way. I never asked a single student to try the app until week six. When we did, the five students we tested with only cared about one thing — finding people in the same course section — and that feature was the least finished.

Result — We placed outside the top ten, and the judges’ feedback was the same as the students’: too much, none of it finished. What I changed: on every project since, I put something in front of a user by the end of the second week and cut the scope to what they use. In my internship I demoed my first admin page to two users after six days, and one of their comments cut a whole screen from the plan.

Follow-ups to rehearse

• Why didn’t you test with users earlier?
• How did your teammates react to the result?
• What would you have cut, looking back?

Why it scores — A real failure with a real cost, owned by the candidate rather than the circumstances, and a later example proving the lesson stuck. It is not a disguised strength.

Q8. Tell me about a mistake that affected other people

Probes — Google: doing the right thing · Amazon: Earn Trust, Ownership

Sample answer

Situation — In my internship I wrote a database migration that added a column with a default value.

Task — The change was mine, and it had passed code review.

Action — When it ran in staging it locked the table for four minutes, and another team’s integration tests failed during that window. I saw their channel light up and realised the timing matched my migration. I posted in their channel within ten minutes: what I ran, when, and that it was the cause. I rolled it back, then rewrote it as three steps — add the column without a default, backfill in batches, then set the default — and asked the team’s database expert to review it. I also added a line to our migration checklist about defaults on large tables.

Result — The rewritten migration ran in production with no lock. The other team thanked me for telling them before they had spent time debugging. I learned that owning a mistake fast is cheaper for everyone than being right about whose fault it was.

Follow-ups to rehearse

• Why didn’t code review catch it?
• How did you feel about posting in another team’s channel?
• What does the checklist line say?

Why it scores — Fast, specific disclosure; a fix plus a guard against repetition; and no deflection to the reviewer who approved it.

Q9. Tell me about the most critical feedback you have received

Probes — Google: valuing feedback · Amazon: Earn Trust, Learn and Be Curious

Sample answer

Situation — Halfway through my internship, my mentor told me my pull requests were hard to review: they averaged around 600 lines and mixed refactoring with new behavior.

Task — I wanted my reviews to be fast, and he was spending an hour on each one.

Action — My first reaction was that the changes belonged together, but I asked him to show me one that he thought should have been split. Seeing it from his side made the problem obvious: he could not tell which lines changed behavior. From then on I split each change into a refactor-only pull request and a behavior pull request, and kept each under about 200 lines. I also started writing a two-line “what to look at” note at the top of each description.

Result — My review turnaround went from about two days to same-day, and at the end of the internship my mentor named reviewability as my biggest improvement. I still split refactors from behavior changes on every project.

Follow-ups to rehearse

• What was your first reaction, honestly?
• Have you ever received feedback you disagreed with?
• How do you ask for feedback now?

Why it scores — The feedback is specific and stings a little, the candidate admits their first reaction, and the change is concrete and measured. It ends with the habit still in use.

Q10. Tell me about a time you missed a deadline

Probes — Google: doing the right thing · Amazon: Deliver Results, Earn Trust

Sample answer

Situation — In my internship I was given two weeks to add search to an internal documentation tool.

Task — The estimate was mine, and I had said two weeks was comfortable.

Action — By the end of week one I knew it would take three: the search library did not support the tool’s access controls, so I had to filter results myself. I told my manager that day rather than at the deadline, with the reason and two options — ship search without the restricted pages in two weeks, or ship complete search in three. We chose the first, so users got most of the value on time. I filed the restricted-page work as a follow-up and finished it in the third week.

Result — Search shipped on the original date for 90% of pages, and the rest a week later. I missed my estimate, but no one was surprised by it. Since then I check my estimate against reality at the halfway point and say so the same day if it has moved.

Follow-ups to rehearse

• Why was the estimate wrong?
• How did your manager react?
• What do you do now to estimate better?

Why it scores — Early warning, options instead of excuses, a partial delivery that served users, and a changed habit. The candidate owns the estimate.

6. Ambiguity and Decisions

Q11. Tell me about a time the requirements were unclear

Probes — Google: thriving in ambiguity · Amazon: Bias for Action, Customer Obsession

Sample answer

Situation — As a teaching assistant, I was asked by the professor to “build something to help students practise recursion”.

Task — That was the whole brief, and I had three weeks before the recursion unit started.

Action — I wrote down the three things I did not know: who was struggling, what they struggled with, and what format they would use. I answered the first two from data I already had — last year’s exam scores showed the base-case questions were the weakest. For the third I asked five students in office hours, and four of them said they wanted short exercises with instant feedback, not videos. So I built the smallest version first: ten auto-graded exercises on base cases, and sent them to the professor after one week to check the direction before building more.

Result — The professor added the set to the course, and I expanded it to 30 exercises. Base-case questions on the midterm rose from 58% to 71% correct. I learned to turn a vague request into a list of unknowns and resolve the most important one first.

Follow-ups to rehearse

• Why did you check in after one week rather than three?
• What would you have done if the professor disliked the direction?
• How do you know the exercises caused the improvement?

Why it scores — It names the unknowns, reduces them with data and users, ships a small first version, and checks in early. The last follow-up tests honesty about causation, so prepare it.

Q12. Tell me about a decision you made without all the data

Probes — Google: bias to action · Amazon: Are Right, A Lot, Bias for Action

Sample answer

Situation — On a weekend hackathon team, six hours in, we had to choose between a hosted database and a local one for our prototype.

Task — I owned the backend, so the call was mine, and we had 18 hours left.

Action — I did not know whether the hosted service’s free tier would hold up during the demo, and there was no time to load-test it. I asked which choice would be cheaper to undo. Local storage could be swapped for the hosted service later through one interface; the reverse meant rewriting the queries. So I chose local storage behind a thin interface, and told the team the assumption: we would switch only if the demo needed multiple devices.

Result — The demo ran on one laptop, the switch was never needed, and we saved roughly three hours of setup that went into the feature the judges praised. I now ask “which choice is easiest to reverse?” whenever data is missing and time is short.

Follow-ups to rehearse

• What would have made you choose the hosted service?
• When is waiting for more data the right call?
• How did you communicate the assumption?

Why it scores — A reasoned framework (reversibility) instead of a guess, an assumption stated out loud, and a result tied to the decision.

Q13. Tell me about a time you had competing priorities

Probes — Google: thriving in ambiguity · Amazon: Deliver Results

Sample answer

Situation — In the last month of my internship, my manager asked me to finish my main project, and another team’s lead asked me to help them fix a bug in a library I had changed earlier.

Task — Both were reasonable, and I could not do both fully in the same week.

Action — I did not want to choose silently, so I wrote down what each request needed and its deadline. The other team’s bug blocked their release in four days; my project was due in three weeks. I estimated the bug at one day. I took both to my manager and proposed spending one day on the bug, then going back to my project, and asked if he saw it differently. He agreed and told the other lead himself.

Result — The bug fix shipped in a day and a half and their release went out on time; my project finished two days before the end of my internship. I learned to make the trade-off visible to the people who own the priorities instead of deciding it alone.

Follow-ups to rehearse

• What if your manager had said no?
• How do you prioritise when nobody is available to ask?
• What did the half-day overrun cost you?

Why it scores — Clear criteria (urgency, cost), a proposal rather than a question with no answer, and the right owner making the call. The candidate admits the estimate slipped by half a day.

Q14. Tell me about a time you had to learn something quickly

Probes — Google: feedback and growth · Amazon: Learn and Be Curious

Sample answer

Situation — On my second day at my internship, I was asked to fix a slow page in a service written in Go. I had never written Go.

Task — The fix was expected within the week.

Action — I did not try to learn the whole language first. I spent one evening on the official tour, only up to goroutines. Then I read the service’s code path for that one page end to end and wrote down each unfamiliar construct as a question. I batched the questions and asked my mentor in one fifteen-minute session rather than interrupting him all day. The slowness turned out to be a loop that made a database call per item, so I rewrote it as one batched query and added a benchmark test.

Result — The page went from 3.2 seconds to 0.4 and the fix shipped on day five. I used the same approach — learn just enough, read real code, batch the questions — for Terraform later in the internship.

Follow-ups to rehearse

• How did you decide what was “just enough” to learn?
• What did you get wrong at first?
• What Go idiom surprised you most?

Why it scores — A deliberate learning strategy, respect for the mentor’s time, a measured result, and evidence the method transfers.

7. Ownership and Results

Q15. Tell me about a time you took on something outside your role

Probes — Google: emergent leadership · Amazon: Ownership

Sample answer

Situation — During my internship, new interns spent most of their first two days getting the development environment to build; the setup guide was a year out of date.

Task — Nobody owned the guide. I had just been through it, so I knew every broken step.

Action — I asked my manager if I could spend a day on it, since it was not my project. I rewrote the guide from my notes, replaced six manual steps with a setup script, and asked the two interns who joined the next week to follow it while I watched without helping. Both got stuck at one step, which I fixed. Then I added the script to CI so it would fail if the setup broke again, and found a full-time engineer who agreed to own it after I left.

Result — Setup time for the next intern cohort went from about two days to under two hours. The handover mattered as much as the script: the guide is still maintained.

Follow-ups to rehearse

• Why did you ask permission first?
• How did you find someone to own it?
• What did you not get to?

Why it scores — Saw a gap, acted on it with the manager’s support, tested with real users, guarded it with CI, and handed it over. Ownership includes the handover.

Q16. Tell me about the hardest bug you have tracked down

Probes — Google: bias to action · Amazon: Dive Deep

Sample answer

Situation — In the open-source linter I contribute to, a user reported that one rule crashed on about 1 in 50 files in their codebase, but they could not share the code.

Task — The rule was one I had written, so I took the issue.

Action — I could not reproduce it on any of our test files. I asked the user to run the linter with a debug flag and send only the stack trace, which pointed to the rule’s handling of decorators. I wrote a small fuzzer that generated random decorated functions and ran the rule on each; within ten minutes it found a crash on a decorator that was itself a call with a keyword argument. My code assumed every decorator was a name. I fixed it, added the fuzzer’s failing case as a regression test, and ran the fuzzer for an hour on the fix.

Result — The user confirmed the crash was gone on all their files. The maintainers adopted the fuzzer for two other rules, and it found one more bug. I learned that when you cannot see the input, you can generate it.

Follow-ups to rehearse

• What did you try before the fuzzer?
• How did you keep the user engaged without their code?
• Why did the original tests miss it?

Why it scores — A methodical path from symptom to root cause, a creative technique under a real constraint, a regression test, and impact beyond the one bug.

Q17. Tell me about a time you delivered under a tight deadline

Probes — Google: bias to action · Amazon: Deliver Results, Bias for Action

Sample answer

Situation — Two days before our capstone demo to an external sponsor, the third-party mapping API we used changed its free tier and our map stopped loading.

Task — I owned the frontend, and the map was the centre of the demo.

Action — I listed what the sponsor actually needed to see: routes between three locations, not a fully interactive map. That cut the problem in half. I spent two hours testing two open-source mapping libraries against our data, picked the one that rendered our routes correctly, and told the team I would have a working map by the next evening and the extra features — search, zoom presets — only if time allowed. I worked through the core path first, then did a full rehearsal with the team the morning of the demo.

Result — The demo ran with the new map; the search feature did not make it and we said so. The sponsor signed on for a second semester. I learned to cut to what the audience needs before working longer hours.

Follow-ups to rehearse

• How did you decide what to cut?
• What risk did you take with the new library?
• How did the team split the remaining work?

Why it scores — Scope cut by the user’s need, a time-boxed evaluation, an honest promise, and transparency about what did not ship.

Q18. Tell me about a time you would not accept “good enough”

Probes — Google: doing the right thing · Amazon: Insist on the Highest Standards

Sample answer

Situation — In my internship, I finished a feature that passed all its tests and review, but I noticed our tests only covered the happy path for the currency conversion it used.

Task — The feature was done by the team’s definition, and I had another task waiting.

Action — I spent half a day writing tests for edge cases: zero amounts, negative refunds, and currencies with no minor unit, like the Japanese yen. The yen test failed: we were multiplying by 100 for every currency, so a ¥1,000 refund would have been recorded as ¥100,000. I fixed the conversion to read each currency’s minor-unit count from a table, and told my manager why the other task would be half a day late.

Result — The fix shipped before the feature reached Japanese users. My manager asked me to write the edge-case list up as a template for other money-handling code. The standard I hold myself to is that a test suite should try to break the code, not just confirm it works.

Follow-ups to rehearse

• How do you decide when extra testing is worth the time?
• When have you accepted “good enough” and been right to?
• How did the reviewer react?

Why it scores — A concrete bar raised beyond the team’s definition of done, a real defect found with a clear cost, and a reusable outcome. Prepare the second follow-up: high standards include knowing when to stop.

Q19. Tell me about a time you simplified a process

Probes — Google: challenging the status quo · Amazon: Invent and Simplify, Frugality

Sample answer

Situation — As a teaching assistant, grading programming assignments for 120 students took the four TAs about 12 hours a week, mostly running each submission by hand.

Task — No one asked me to change it, but I was one of the four people spending those hours.

Action — I proposed an autograder to the head TA, with a one-week trial on a single assignment so it would cost little if it failed. I wrote a script that ran each submission in a container against our test cases and produced a score sheet, and kept a manual step for style and comments, which the tests could not judge. I showed the other TAs the first output and asked what was missing; they asked for the failing test’s input to be included, so students could see why.

Result — Grading time dropped to about 4 hours a week across the four of us, and students got results in two days instead of seven. The course has used the autograder every semester since. I learned to propose a change as a cheap trial rather than as a big switch.

Follow-ups to rehearse

• What did you deliberately keep manual?
• How did you convince the head TA?
• What went wrong in the trial?

Why it scores — It removes work instead of adding a process, starts with a cheap reversible trial, keeps human judgment where it matters, and quantifies the saving.

8. Users and Integrity

Q20. Tell me about a time you went out of your way for a user

Probes — Google: putting the user first · Amazon: Customer Obsession

Sample answer

Situation — During a part-time job doing IT support for my university library, several students complained that the room-booking site logged them out when they switched between their phone and laptop.

Task — My job was to log tickets and reset passwords, not to fix the booking site.

Action — I noticed the complaints clustered around exam weeks, when people booked from several devices. I tracked them for two weeks in a shared sheet — 31 tickets — and found they all came from users booking on two devices within a few minutes. I wrote this up for the library’s developer with steps to reproduce and the sheet, and in the meantime added a short note to the booking page telling students to finish a booking on one device.

Result — The developer found the session conflict and fixed it before the next exam period; the related tickets dropped to zero. I learned that a support queue is user research if somebody reads it as a whole.

Follow-ups to rehearse

• How did you get the developer’s attention?
• Why the interim note rather than waiting for the fix?
• What would you have done if the developer had said no?

Why it scores — The user is named, the problem is quantified from a source the candidate already had, there is a workaround for users now and a fix later, and the candidate went beyond their role without overstepping it.

Q21. Tell me about a time you had to choose between shipping on time and doing it right

Probes — Google: doing the right thing · Amazon: Insist on the Highest Standards, Earn Trust

Sample answer

Situation — On the day before an internal tool’s launch, I found that its export endpoint returned rows from every team, not just the user’s own, if a query parameter was removed.

Task — I had not written the endpoint, nobody else had noticed, and the launch had been announced to 200 users.

Action — I reproduced it twice to be sure, then told my manager and the endpoint’s author together within the hour, with the exact request that showed the leak. I did not post it in the public channel. I proposed two options: delay the launch a day, or launch with the export button disabled. The author fixed the check that afternoon and I wrote a test that sent the request without the parameter. We launched with export disabled and turned it on the next morning, after the test passed.

Result — The tool launched on schedule and no data was exposed. My manager asked me to add the test to the team’s review checklist for every new endpoint. I learned that raising a problem quietly and quickly, with a fix in hand, makes it easy for people to do the right thing.

Follow-ups to rehearse

• Why not fix it yourself?
• Why not tell the whole team?
• What if your manager had said to launch as-is?

Why it scores — An uncomfortable truth raised early, to the right people, with a reproduction and options. The outcome protected users and the launch, and the candidate credits the author with the fix.

9. Leadership and Developing Others

Q22. Tell me about a time you led without being the lead

Probes — Google: emergent leadership · Amazon: Earn Trust, Ownership

Sample answer

Situation — Our five-person capstone team had a nominal lead who was strong technically but rarely ran meetings, and three weeks in we had no shared plan; two people had built overlapping login pages.

Task — I was not the lead, and I did not want to undercut him.

Action — I talked to him first and offered to run a planning session, with him presenting the architecture. He agreed. In the session I had each person list what they were working on, put it on one board, and we found the overlap and two features nobody owned. I suggested a fifteen-minute stand-up twice a week and volunteered to run the first two, then rotated the role.

Result — We cut the duplicated work, finished every planned feature a week before the deadline, and the lead ran the stand-ups himself after the first month. I learned that leading without authority often means giving someone else the stage while filling the gap they leave.

Follow-ups to rehearse

• Why did you go to the lead first?
• What did you do when someone resisted the stand-ups?
• What would you have done if the lead had said no?

Why it scores — Leadership as filling a gap, done with the formal lead’s support rather than around him, and handed back. This is the emergent-leadership signal the L3 bar asks for.

Q23. Tell me about a time you helped someone else succeed

Probes — Google: emergent leadership, collaboration · Amazon: Hire and Develop the Best

Sample answer

Situation — In my internship, a new intern joined three weeks after me and was assigned a bug in a part of the codebase I had just learned.

Task — I was not her mentor, but I knew that code and her mentor was on vacation that week.

Action — I offered an hour on her first afternoon. Instead of telling her the fix, I walked her through how I would find it: where the logs were, how to run the service locally, and how I traced requests through it. Then I let her drive while I watched, and only stepped in when she was stuck for more than ten minutes. I also shared the notes I had written for myself on the codebase.

Result — She fixed the bug herself in two days and opened her first pull request that week. Two weeks later she was answering questions from the next intern using the same notes. I learned that teaching how to find an answer scales further than giving it.

Follow-ups to rehearse

• How did you balance this with your own work?
• What do you do when someone wants the answer, not the method?
• How do you know it was your help that made the difference?

Why it scores — Help offered without being asked, a deliberate teaching approach, and evidence the help multiplied. The credit stays with the person who did the work.

10. Hypotheticals

Google asks these more often than Amazon. Use the pattern from the Google guide: clarify, options, decide, follow through — then anchor in a real story if you have one.

Q24. What would you do if your manager asked you to ship something you believed was not ready?

Probes — Google: doing the right thing · Amazon: Have Backbone; Disagree and Commit

Sample answer

Clarify — I would first ask what “not ready” means in this case, because it changes the answer. Is it a risk to users — data loss, security, a broken core flow — or a quality gap like missing polish or thin test coverage? And what is driving the date: a commitment to a customer, or an internal target?

Options — If it is a user-facing risk, I would say so plainly with the evidence, and propose a way to hit the date safely: ship behind a feature flag to a small group, cut the risky part, or delay a few days. If it is a quality gap, I would note it, file the follow-ups with owners, and ship.

Decide — The decision is my manager’s, but they should make it with the facts. I would put the risk in writing — two or three sentences — so it is clear, not to cover myself.

Follow through — If we ship, I commit fully: I would watch the metrics and errors after launch and be first to respond. In my internship I raised a data-exposure bug the day before launch; we shipped on time with the export disabled, and enabled it the next day.

Follow-ups to rehearse

• What if your manager still says ship, and you think users will be harmed?
• How do you disagree without damaging the relationship?
• When would you escalate above your manager?

Why it scores — It separates risk from preference, offers options that respect the date, commits once decided, and ends with a real story. Prepare the first follow-up: the line where you would escalate is part of the answer.

Q25. What would you do if two senior engineers gave you conflicting directions?

Probes — Google: thriving in ambiguity, collaboration · Amazon: Earn Trust

Sample answer

Clarify — I would check that I had understood both of them correctly, because the conflict is often in my summary rather than in their intent. I would also ask who owns the decision — the tech lead, my manager, or one of them.

Options — I could pick one direction myself, go back to each separately, or put both views side by side and ask them together. Picking one myself risks undoing work later; going back separately tends to repeat the conflict.

Decide — I would write a short note with both approaches, the trade-off of each as I understand it, and which one I would lean toward and why, and send it to both of them in the same thread, with the decision owner copied. That makes the disagreement about the approach, not about which senior I listen to.

Follow through — While they decide, I would work on the parts both approaches share, so I am not blocked. Once decided, I would note the decision in the design doc so it is not reopened. Something similar happened in my internship with a naming convention, and a five-line comparison settled it in one reply.

Follow-ups to rehearse

• What if they still cannot agree?
• What if the decision owner picks the option you think is worse?
• How do you avoid looking like you are taking sides?

Why it scores — It treats the conflict as an information problem, routes it to the owner, keeps the candidate productive while waiting, and records the decision.

11. After the Mock

• Count the "we"s. In any answer where “we” outnumbers “I”, rewrite the action section.
• Find the number. Every result should have one: time saved, error rate, users, grade, days.
• Check the lesson. Each story should end with what you changed and a later time you used it.
• Map your stories. After answering all 25 questions, you should be using six to ten stories in total. If one story answers more than four questions, a round will notice; if a question had no story, that is the gap to fill.
• Repeat the weak ones in a week, with a different partner, because a familiar listener stops asking the hard follow-ups.