Behavioral Interview Questions: Communication Practice Quiz
Reviewed by Mark Dickie · Last updated
5 questions on this page you can answer and see marked on the spot. Go to the first one
Behavioral interview questions are prompts that ask you to describe something you did in a real past situation, and interviewers use that account to predict how you will work on their team. Most candidates have the stories but lose points in the telling, because the answer never makes clear which decisions were theirs. Structure each answer as Situation, Task, Action, Result, spend most of the time on Action, and say "I" for what you personally decided. Keep the whole answer near two minutes.
What do interviewers listen for in a behavioral answer?
| Answer part | What the interviewer listens for | Common failure |
|---|---|---|
| Situation and Task | Enough context to judge scope, given in two sentences | A ten-minute backstory before any action appears |
| Action | Your own decisions, named with "I" | Saying "we" so your part cannot be identified |
| Result | A measurable outcome and what you changed afterward | Ending on "it went well" |
| Conflict story | How you disagreed with a peer and what you did next | Describing the other person as the problem |
| Failure story | What broke, what you owned, and the fix you shipped | Choosing a fake weakness such as working too hard |
How do you practice behavioral answers before the interview?
- Write five stories from past work, each tagged with the competency it proves, such as ownership, conflict, ambiguity, influence, or a missed deadline.
- Time each story out loud and cut anything before the Action step that does not help the interviewer judge your role.
- Record one answer on your phone and count the "we" statements and filler words in the Action section.
- Ask yourself "what would you do differently?" and answer in one sentence, since a follow-up like this is common.
Key facts
- Tarmac has 36 Behavioral interview questions on this topic, 10 of them on this page, at difficulty 1–4 of 5.
- Tarmac tracked 323 job postings asking for Behavioral in October 2026.
- Roles asking for Behavioral advertise a median base salary of £85,000, across 106 job postings as of October 2026.
- Tarmac last reviewed these Behavioral interview questions on 9 November 2026.
At a glance
| Questions | 10 shown · 36 in the bank |
|---|---|
| Difficulty | 1–4 of 5 |
| Formats | Multiple choice, Flashcard, Multiple answer, Ordering, Behavioral, Short answer, True / false, Design exercise |
What you'll review
- explaining to nontechnical
- stakeholder updates
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
You need to tell a non-technical VP that a planned database migration will slow feature delivery for the next six weeks. Which opening best sets up the conversation?#
Options
Show answer
Leading with the business impact — the roadmap slipping six weeks — before the technical rationale is the strongest opening, because a VP needs the takeaway up front to make a resourcing or expectations decision. Leading with implementation detail, offering false reassurance, or burying the ask behind background all delay or hide the one thing the VP actually needs to hear first.
This follows the Pyramid Principle / BLUF (bottom-line-up-front): lead with the conclusion the VP actually needs — the schedule impact and the tradeoff — before any supporting detail, because that's what lets them make a resourcing or expectations decision immediately. Leading with the sharded-cluster migration detail leads with implementation the VP has no use for and buries the one fact that matters. The reassurance that it'll be smooth is false reassurance: it asserts an outcome with no information behind it, which erodes trust the moment reality gets bumpy. Walking through the current data architecture first buries the ask behind unrequested background, forcing the VP to sit through architecture before learning why the conversation is happening at all.
In written stakeholder status updates, what does the acronym BLUF stand for, and what goes in the first line of an update that uses it?#
Show answer
BLUF stands for "Bottom Line Up Front." The first line states the bottom line: the current status, the key conclusion, or the decision you need from the reader. Supporting detail comes after it, so a busy stakeholder gets the main message immediately.
BLUF is a standard military and business writing convention. It puts the conclusion or required action at the top so readers who only skim the first line still get the key message. The rest of the update supplies context and evidence for those who want it.
You are the engineer leading a feature whose release date is slipping. You need to send a written status update to non-technical stakeholders (product, sales, and finance leads). Which of the following practices make that update effective? Select all that apply.#
Options
Pick every one that applies.
Show answer
Effective stakeholder status updates lead with the current status and any risk to the committed date, name the next action with an owner and a time for the next update, and call out any decision needed from the reader with a deadline. Raw stack traces and delaying the message until resolution both reduce clarity and leave stakeholders unable to plan around a possible delay.
Effective stakeholder updates lead with the status and any risk to the commitment so readers get the key fact first, state the next concrete action with an owner and a time for the next update so they know progress is being managed, and make any needed decision or input explicit with a deadline so they can act. Pasting raw stack traces and failing test names buries the message for a non-technical audience, and waiting until the issue is resolved withholds information that stakeholders need to plan around a possible slip.
A team dependency you rely on has slipped by about two weeks, and your stakeholders are waiting on a delivery date. Put these steps in the order they must be carried out, from first to last.#
Put these in order
Show answer
The correct order is: confirm the slip and obtain the owner's revised timeline, then recalculate your delivery date using that timeline, then send stakeholders the update containing the recalculated date. Each step's output is the next step's required input — you cannot recalculate without the owner's timeline, and you cannot send a message containing a date that has not yet been calculated.
Each step consumes the output of the one before it, so only one order is workable. Confirming the slip produces the dependency owner's revised completion timeline — the input needed to recalculate your delivery date. The recalculation produces the new date, and the stakeholder update explicitly contains that date, so it cannot be sent until the date exists. Reversing any pair is impossible: recalculating without the owner's timeline has no basis, and sending an update that contains a date before it is calculated would publish a number that does not yet exist.
Mid-level. Tell me about a time you had to explain a technical problem or decision to a non-technical audience (a product manager, an executive, or a customer).#
Show answer
Situation. Our checkout was timing out under load and the VP of Sales wanted to know why we couldn't 'just add servers' before a big demo. Task. I had to explain a database connection-pool bottleneck without losing him in the weeds. Action. I dropped the jargon and used a toll-booth analogy: more lanes (servers) don't help if every car still funnels through one booth (the pool). I drew it on a whiteboard, then tied it to the demo risk in his terms: '20% of checkouts would hang.' I checked in by asking him to restate the tradeoff back to me. Result. He approved the two-day fix over the quick patch, and the demo ran clean. He later used my toll-booth framing with the customer himself. Reflection. Asking him to restate the tradeoff back to me — rather than trusting a nod — is how I now confirm an explanation has actually landed.
Probes whether an engineer can translate technical complexity into the listener's frame of reference. Strong answers show deliberate audience adaptation and a confirmed understanding; weak answers just recount what they said without evidence it landed.
A checkout page's p95 latency has regressed from 800ms to 2.1 seconds. You need a non-technical product stakeholder to prioritize the fix over other roadmap items. Which framing best makes the case?#
Options
Show answer
Translating the latency regression into an estimated revenue loss is the strongest framing, because it gives a non-technical stakeholder the same unit — money — they use to prioritize everything else on the roadmap. An SLO/error-budget framing stays in engineering jargon, a vague 'feels sluggish' claim isn't quantified enough to compete for prioritization, and framing it as a reflection on engineering standards misses the business stakes entirely.
Translating latency into an estimated revenue figure gives the stakeholder the same unit — money — they already use to rank every other item on the roadmap, so the fix competes for priority on equal footing. Citing the SLO violation and error budget stays inside reliability jargon that means nothing to someone outside engineering. Saying the page 'just feels sluggish' is unquantified: 'probably notice' gives the stakeholder nothing to weigh against a competing feature with a known revenue number. Framing the fix as reflecting poorly on the team's engineering standards frames it as a reflection on the team rather than a business outcome, which is the wrong lever for a prioritization decision.
A non-technical product manager wants to know why you're asking to spend two sprints paying down technical debt instead of shipping the next two features on the roadmap. How would you explain the cost of the debt and the tradeoff in terms they'll weigh seriously?#
Show answer
I'd translate the debt into the cost it's already imposing in their terms: the last three features in this area each took roughly 40% longer than estimated because of the tangled code, and we've shipped two production bugs from it this quarter that cost support tickets and an on-call page. I'd frame the two sprints as an investment with a payback period — after this, delivery in this area should return to a normal estimate and the bug rate should drop — rather than asking them to trust an abstract 'the code is messy' claim. I'd also offer a scoped fallback (one sprint on the worst offender) if they can't accept the full ask, so it's a negotiation, not an ultimatum.
The strongest explanations quantify the debt's existing cost in terms a PM already tracks — missed estimates, bug or incident counts, review overhead — rather than asserting code quality as an intrinsic good. Framing the ask as an investment with a measurable payback, and offering a scoped fallback, turns an abstract engineering preference into a business tradeoff the PM can actually weigh and negotiate.
True or false: when a project's delivery date is at risk, the right move for stakeholder communication is to raise the risk as soon as the team knows about it, rather than waiting until the date has actually been missed.#
Options
Show answer
Flagging an at-risk deadline as soon as the risk is known is the right approach for stakeholder communication. Early notice gives stakeholders time to re-plan scope, staffing, or dependent work, while waiting until the date is already missed removes most of those options.
Stakeholders can only adjust scope, staffing, or dependent plans if they hear about a risk while there are still options. Raising an at-risk date as soon as it is known gives them that window. Waiting until the deadline is already missed turns a planning decision into a surprise and removes most of the choices they could have made, so the statement is true.
You are the tech lead for a six-engineer team migrating a customer-billing service to a new database. The project was planned to finish in six weeks and is now tracking to roughly ten weeks because of a data-consistency issue found during testing. Three groups depend on your status: the VP of Engineering (who funds the project and cares about the launch date and budget), the product manager (who has committed a launch date to two enterprise customers), and the customer support lead (who must prepare agents and scripts for the cutover and needs to know when behaviour will change). Design the stakeholder update plan you would run for the next eight weeks. Specify: who gets which information, what each update contains and how it is structured, how often updates go out and what event would trigger an extra one, and how you confirm that each audience understood the update and that commitments and decisions are tracked. Be concrete about formats and examples of what you would actually write.#
Show answer
I would segment the audiences because they decide different things. The VP of Engineering funds the work and needs the date, the budget impact, and the options: for example, hold the ten-week plan, cut scope to hit eight weeks, or add one contractor. The product manager needs to know which enterprise commitments are at risk and by how much, so they can renegotiate with customers early. The support lead needs the cutover window and exactly which billing behaviours change, so scripts can be ready. Each gets a version of the same facts, tailored to those needs.
Every written update uses the same structure, leading with status: 'Billing migration: amber. Current estimate is ten weeks (range nine to eleven), confidence medium. Change since last update: the consistency fix moved testing back one week.' Then it lists the decision needed with a deadline, such as 'Decision needed by Thursday: approve the scope cut in section two or accept ten weeks.' Risks and actions follow, each with an owner.
The cadence is weekly for the VP and product manager, with a 20-minute sync every second week, and biweekly for support, plus an immediate update whenever the end-date estimate moves by more than a week, a customer commitment is at risk, or a new production-impacting defect is found. For comprehension, I ask the VP to restate the decision in one sentence during the sync, and I ask the product manager to name the customer messaging they will send before the update is closed. Support confirms the cutover behaviour list back in writing.
To track commitments, I keep a shared decision and date-change log, with each entry dated, stating what changed, who decided, and the source. Any later disagreement about what was promised is resolved by that log. When the product manager asks to remove the customer risk, I keep it in the written update, explain in the sync why it is there, and record that they disagreed and that the risk was retained by my decision with their input noted. The plan is working if decisions arrive by their deadlines, date changes are not surprises to anyone, and support has no cutover questions I could have answered earlier; if decisions are late, I shorten the cadence or add a decision meeting.
This is an open communication-design problem, so the rubric grades whether the answer covers each concrete element: audience-specific content, a status-first structure with asks, a defined cadence plus triggers, and both a comprehension check and a written record of decisions and changes. The sample answer covers each criterion with concrete formats and example wording.
Senior-level. Describe how you keep stakeholders informed on a project you're leading, especially when things aren't going to plan. Give me a specific time a status update changed the course of the work.#
Show answer
Situation. I was leading a payments migration with a hard regulatory deadline, and three weeks in we discovered the legacy data was dirtier than scoped. Task. I owned keeping the steering group and our partner bank aligned. Action. Rather than bury it in a green status, I sent a same-day update flagging the slip, with a one-page breakdown of options: descope two countries to hit the date, or move the date two weeks. I gave a clear recommendation (descope) and the data behind it. I kept a weekly written update plus a Slack channel for fast questions. Result. Leadership chose the descope within 24 hours, we hit the regulatory date, and the two countries shipped a fortnight later cleanly. The bank's PM told us the early honesty was why they trusted the replan.
Tests proactive, structured stakeholder communication under pressure, especially the willingness to deliver bad news early with options. Strong answers surface risk proactively with a recommendation; weak answers describe routine status emails with no consequence.
Related interview questions
Job market
See behavioral salaries and hiring demand from live job postings.
The other 26 questions
This page shows 10 and marks what you pick. That's as far as a page can go. A free account opens the other 26 and keeps every answer. What you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 answers per 30 days, each marked with written feedback