Scenario rounds give you a situation and watch how you think. A dashboard disagrees with the finance report, three teams define 'active customer' three different ways, a data migration comes up short on go-live weekend, a workshop gets taken over by the most senior person in the room. There is rarely one right answer. The interviewer wants to hear what you check first, who you would talk to, and what would change your mind. It suits every level, from a first BA job to a lead. Each question shows what is being tested, the shape of a good answer and a sample that thinks out loud. Practice saying your first two checks out loud before you jump to a fix.
Search all questions by round, difficulty and level, or save the ones you want to practice.
Definitions: confirm what each number counts: booked or invoiced, before or after refunds, with or without tax.
Cut-off: check the date each side uses and the time zone, since orders near midnight on the last day can land in different months.
Reconcile: pick one small slice, such as one region or one day, and match it line by line until the gap is explained.
Agree: write down the agreed definition and label the dashboard with it.
“My first guess is that they're counting different things, not that someone's broken. So I'd sit with both teams and ask what exactly goes into their number. Is sales counting orders when they're placed, while finance counts them when they're invoiced? Are refunds and cancellations taken out? Is tax in or out? Then I'd check the date logic, because a dashboard running on server time can push late orders on the last day into the wrong month. After that I'd pick one small slice, maybe one region for one day, and match the two sources line by line. Once the gap is explained, I'd get both sides to agree on a definition and put it right on the dashboard. If the slice matched perfectly, that would change my mind, and I'd look for missing or duplicated rows in the dashboard's data feed instead.”
Declaring finance's number correct without checking, or adjusting the dashboard until it matches without knowing why it differed.
Spot it: the order total sits on the order row, and the join repeats that row once for every matching Garden item.
Prove it: count rows per order after the join; an order with three Garden items shows up three times.
Fix: filter with EXISTS so each order is counted once, or aggregate items before joining.
Check: compare one customer's result with their orders by hand.
“The giveaway is that it's too high by roughly the number of Garden items per order. The order total lives on the orders table, but I joined to order_items to filter on category, so an order with three Garden items appears as three rows and its total gets summed three times. To prove it, I'd count rows per order after the join and see the repeats. The fix is to stop the join from multiplying rows. I'd move the category check into an EXISTS, so the query only asks whether the order has at least one Garden item, and each order is counted once. Then I'd spot check one customer by adding up their qualifying orders by hand. If the numbers were still off after that, I'd look for duplicate orders in the source table itself.”
-- Inflated: order_total repeats once per matching item row
SELECT o.customer_id, SUM(o.order_total) AS revenue
FROM orders o
JOIN order_items i ON i.order_id = o.order_id
WHERE i.category = 'Garden'
GROUP BY o.customer_id;
-- Fixed: each order counted once
SELECT o.customer_id, SUM(o.order_total) AS revenue
FROM orders o
WHERE EXISTS (
SELECT 1 FROM order_items i
WHERE i.order_id = o.order_id AND i.category = 'Garden'
)
GROUP BY o.customer_id;Adding DISTINCT inside the SUM, which silently merges two different orders that happen to have the same total.
Freshness: check whether last night's data load ran fully or stopped part way.
Changes: ask whether anything changed in the report, its filters or the source system in the last day.
Compare: find which customers dropped out and look for what they have in common.
Reply: give the sales head a short holding answer, then the cause once confirmed.
“A sharp overnight drop with no business reason usually means the data, not the customers. First I'd check the load: did last night's refresh finish, or did it pull only part of the records? Next I'd ask whether anything changed yesterday, like a new filter on the report, a release to the source system, or a change in how 'active' is worked out. Then I'd compare today's list with last week's and look at the customers who disappeared. If they're all from one region or one product, that points straight at the cause. Meanwhile I'd reply to the sales head quickly, saying I'm looking into it and it looks like a data issue, so they don't act on the number. If the missing customers really had stopped buying, I'd change my mind and treat it as a business signal.”
Forwarding the number as a real drop, or going quiet for a day while investigating.
Define new: a customer whose first ever order falls in the campaign window, not just anyone who ordered.
Count: first orders per month, so the campaign months sit next to the months around them.
Baseline: compare with the same months last year to allow for seasonal patterns.
Attribute carefully: use campaign codes or source tracking where they exist, and say what the data can't prove.
“The first thing is to define 'new'. I'd use customers whose very first order is in the campaign window, because returning customers who happened to buy that spring don't count. So I'd find each customer's first order date and count those by month. That shows whether spring really stands out from the months around it. Then I'd compare with the same months last year, since plenty of businesses get a spring bump anyway. If there's a campaign code or a traffic source on the order, I'd split new customers by that too. I'd be careful in how I present it. A rise lines up with the campaign, but unless there's tracking or a held-back group, I can say the timing fits, not that the campaign caused it. If last year's spring looked the same, that would make me doubt the claim.”
-- PostgreSQL: new customers by month of their first order
WITH first_orders AS (
SELECT customer_id, MIN(order_date) AS first_order_date
FROM orders
GROUP BY customer_id
)
SELECT DATE_TRUNC('month', first_order_date) AS order_month,
COUNT(*) AS new_customers
FROM first_orders
GROUP BY DATE_TRUNC('month', first_order_date)
ORDER BY order_month;Counting every order in the campaign months as proof of new customers, or claiming the campaign caused the rise with no comparison.
Collect: write each team's definition side by side and what decisions they use it for.
Quantify: run all three against the same data so everyone sees how far apart they are.
Decide: take it to the person who owns the metric, with a recommendation.
Label: publish the chosen definition, and keep the others as named measures if they're still needed.
“I wouldn't try to force one definition straight away, because each team probably has a good reason for theirs. Sales might count anyone who ordered in the last 90 days, finance anyone with an open account, support anyone who logged in. So first I'd write the three side by side, with what each team uses the number for. Then I'd run all three against the same data, because seeing the actual gap makes the talk much more concrete. Often it turns out they need different measures, not one. I'd take it to whoever owns company metrics, maybe the head of operations, with a recommendation for the headline number. Then I'd publish that definition clearly and keep the others as separately named measures, like 'recently purchasing customers', so nobody mixes them up again.”
Choosing a definition yourself and shipping the report without anyone who owns the metric agreeing to it.
Source: get the exact obligation in writing from legal or compliance, not second hand.
Minimum: work out the smallest change that meets the rule by the deadline, and what can follow later.
Impact: map every place marketing is sent or consent is collected, including third parties.
Trade-off: show the sponsor what moves out of the backlog to make room, and get that agreed.
“I'd start with compliance, because I don't want to build on someone's summary of the rule. I'd ask them what exactly we must do by the deadline, and what counts as proof of consent. Then I'd map where it touches us: the sign-up form, the marketing email tool, any partner we share lists with, and the existing customer base. Rules like this differ by country too, so I'd check which markets are in scope. Next I'd separate the minimum, like capturing and storing consent and stopping sends to anyone without it, from the nice to haves, like a full preference centre. With a full backlog, something has to move, so I'd show the sponsor the options and let them choose what slips. If compliance told me the existing base was covered already, the scope would shrink a lot.”
Interpreting the law yourself, or quietly squeezing it into the sprint without telling anyone what else slips.
Clarify: understand exactly when this can happen and how often.
Options: lay out the possible rules and their effect on the customer and on finance.
Decide: get the answer from the business owner, fast, so the developer isn't blocked.
Sweep: look for related edge cases and add the rules and test cases.
“I'd thank them, because that's exactly the kind of question that turns into a production bug later. First I'd understand whether it can actually happen in the current flow. Maybe codes can only be applied at checkout, and then the answer is it can't. If it can, I'd sketch the options: block codes on refunded orders, apply the discount to what's left, or recalculate the whole order. Each one affects the customer and the accounts differently, so it's a business call, not mine or the developer's. I'd take it to the product owner and finance and try to get an answer the same day. Then I'd update the acceptance criteria and ask the tester to add cases. I'd also look for cousins of this case, like codes on exchanged or cancelled orders, since one gap usually means a few more.”
Telling the developer to do whatever seems sensible, then finding out in production that finance disagrees.
Need: ask what decisions the report supports and what each recipient does with it.
Minimise: propose only the fields and people needed, summaries where possible.
Safer delivery: a secured dashboard with access control instead of an email attachment.
Check: involve the data protection or security contact before building.
“I'd start by asking what the report is for. What do the twenty people do with it each week? Often the real need is something like 'which customers haven't bought in a while', and most people only need counts, not names and phone numbers. Then I'd suggest trimming it: personal details only for the people who contact customers, summaries for everyone else. I'd also suggest a secured dashboard instead of an email attachment, since emailed files get forwarded and stored everywhere, and nobody can take them back. Privacy law differs by country, but most places expect you to use only the personal data you need, so I'd bring in our data protection contact before building. If the manager's team genuinely calls every customer weekly, they may need the details, but through controlled access.”
Building the report exactly as asked because a manager requested it.
Expected gaps: check the migration rules first: were inactive, duplicate or test records meant to be left out or merged?
Reject logs: look at what the load rejected and why.
Break down: compare counts by type, status or region to see where the gap sits.
Decide: bring the cutover call a clear picture: explained, fixable in time, or a reason to delay.
“First I'd stay calm and check whether the gap is intended. Migration rules often drop closed accounts or merge duplicates, so I'd pull the mapping document and see if the numbers explain the thousand. Next I'd look at the rejection log, because records that failed validation, like a missing postcode, usually land there with a reason. Then I'd compare counts by status and region between old and new, so I can see if the gap sits in one bucket. With three hours, I'd give the team updates every hour, not just at the end. At the cutover call I'd say plainly what's explained, what's not, and the risk. If it's a few hundred rejects we can reload, we might go ahead with a fix plan. If it's unexplained active customers, I'd recommend holding, because active customers locked out on Monday would be worse than a delay.”
Going live and promising to fix it later without knowing whether active customers are missing.
Options: shift UAT by a few days, split it around month-end, or cut it to the highest-risk scenarios.
Make it easy: prepare scripts, test data and a quick way to log issues so their time goes further.
Escalate risk: tell the sponsor what going live with thin testing means.
Plan ahead: put business events like month-end into the project calendar next time.
“I'd first look at the calendar with the testers and the project manager. Maybe we can start UAT a few days late, right after close, or have them test the riskiest scenarios in short slots during month-end and the rest afterwards. To make their time count, I'd have everything ready: step-by-step scripts, test data loaded, and a simple form for issues, so they're not wasting an hour figuring out how to log in. If none of that gives enough coverage, I'd tell the sponsor plainly: going live without proper user testing risks problems landing on customers, and they need to choose between a short delay and that risk. I wouldn't let UAT shrink without someone owning that decision. Next project, I'd put month-end and other busy periods into the plan from day one.”
Having the project team run UAT and reporting it as business-approved.
Pause the guess: ask the developer to park that piece rather than pick a side.
Understand: read both stories and find the exact rule where they clash.
Decide: take the conflict to the product owner the same day with the options and the impact of each.
Learn: add a check against existing behaviour when writing or refining stories.
“First I'd thank the developer and ask them to hold that bit, so nobody codes their own guess. Then I'd read both stories and pin down exactly where they clash. Maybe last month's story lets managers edit an approved request, and this one locks it once approved. I'd take that to the product owner the same day with the two options and what each would mean, including whether changing last month's behaviour affects live users. Once they decide, I'd update whichever story needs it and tell testers so their cases match. Afterwards I'd look at why it slipped through. Usually it's that new stories get written without checking what the system already does, so I'd add that question to refinement. If the product owner said both were right in different situations, I'd write the rule that tells them apart.”
Telling the developer to just follow the newer story because it's newer.
Who decides: agree with the sponsor who owns priority calls until a new product owner arrives.
Release goal: confirm what the release has to achieve and any date-bound promises.
Triage: sort items into needed for the release, later and close, starting with in-progress work.
Keep the team moving: make sure the next sprint has enough ready stories.
“First I'd go to the sponsor and ask who makes priority decisions now. I can prepare and recommend, but someone with authority has to own the calls, or I'll get overruled later. Next I'd confirm what this release must deliver: any promises to customers, contracts or deadlines. With that goal, I'd triage the backlog. Anything in progress comes first. Then I'd mark each item as needed for this release, later, or close. In a backlog of two hundred, a lot will be old ideas nobody remembers, and closing them is a relief. I'd review my cut with the sponsor and the tech lead. Meanwhile I'd make sure the team has a sprint's worth of ready stories so nobody sits idle. If the sponsor told me to act as product owner, I'd ask for that to be made official.”
Making all the priority calls yourself with no one's authority, or waiting for a new product owner while the team runs out of work.
Map both: document each region's current steps, approvals and handoffs.
Find the why: ask what drives each difference: local rules, volume, tools or habit.
Compare: measure time, errors and complaints for each, then design the to-be from the best parts.
Adopt: agree the design with both leads and plan the switch, allowing true local rules to stay.
“I'd start by mapping both processes as they really run, with the people who do the work, not just the managers. Then for every difference I'd ask why. Some differences exist for a reason, like a local consumer law or much higher volume. Others are just habit. Next I'd compare how each performs: how long a refund takes, how often it's reworked, how many complaints come in. That gives a fair basis instead of 'our way is better'. I'd draft a to-be that takes the stronger steps from each, keeps the differences that are legally required, and drops the rest. I'd review it with both regional leads together so neither feels overruled. If one region's process was clearly better on every measure, I'd say so, but still let the other team help plan the switch.”
Picking the region that sits closest to head office and making the other one copy it.
Timeline: trace a sample of invoices and record the time spent at each step and between steps.
Waiting: separate time someone is working on it from time it sits in a queue or inbox.
Causes: look at the biggest waits: missing purchase orders, unclear approvers, invoices sent back.
Target: fix the biggest wait first and measure again before bigger changes.
“I'd start by following real invoices, maybe thirty from last month, and noting the date at each step: received, matched to a purchase order, sent for approval, approved, paid. In my experience the work itself takes minutes and the days are spent waiting. So I'd look for where invoices sit longest. It might be that many arrive without a purchase order number and bounce back to the supplier, or that approvers don't know it's their turn because it goes by email. Once I know the biggest wait, I'd fix that first, maybe by setting approval rules by amount and sending reminders, and measure again. If the timeline showed approvals were fast and the delay was in data entry, I'd change course and look at scanning or supplier portals instead.”
Recommending a new workflow tool before knowing where the twelve days actually go.
Pattern: check whether it's all agents and all call types, or some, and whether it's improving week by week.
Observe: sit with agents and watch where the time goes on screen.
Classify: training gap, clunky screen flow, slow system, or a new required step.
Act: fix the top cause and track the trend with the manager.
“I'd start with the data before taking a side. Is it every agent and every call type, or mostly new starters, or one kind of call? And is it getting better each week? If it's steadily improving, part of it is just people learning a new system. Then I'd sit next to a few agents for an afternoon and watch. Often you'll see the real thing: an agent clicking through four screens to find an address that used to be on one, or waiting for a search to load, or a new mandatory field nobody asked for. I'd sort what I find into training, screen design, performance and new steps, then take the biggest one to the manager and the CRM team. If the fastest agents were as slow as everyone else, I'd lean towards a system problem, not training.”
Agreeing the system is the problem, or dismissing it as a training issue, before watching anyone use it.
Purpose: ask operations what decision or task each field supports.
Sort: which fields are needed at order time, which can come later, which can be filled automatically.
Options: propose a smaller mandatory set, defaults and lookups, or a later step for the rest.
Agree: get both leads to sign off on the list together.
“I'd go through the fourteen fields with operations one at a time and ask what each one is used for. Usually some are really needed when the order is taken, like delivery date, and others could be filled later, or worked out automatically from the customer record. Then I'd take the list to sales and ask which fields are genuinely hard for a rep to know on a call. With that, I'd propose something like five mandatory at entry, a few defaulted from the account, and the rest completed by operations afterwards. I'd get both leads in the same room to agree the final list, so it's not me picking a winner. If operations showed me that orders without a field actually get shipped wrong, I'd push harder for that one being mandatory.”
Adding all fourteen because operations asked first, or dropping them all because sales complained loudest.
Brief: show the new owner why the requirement was agreed and what problem it solved.
Listen: understand their objection; they may know something that's changed.
Cost of change: work out with the team what changing course now means for time and scope.
Decide and record: get a decision, update the requirement, and log the reason.
“I'd meet the new stakeholder soon, before more is built. I'd walk them through why the requirement was agreed: the problem, the options that were rejected and who else signed off. That's not to defend it, but so they're deciding with the full picture. Then I'd listen properly, because they might know something new, like a change in strategy or a problem they saw in their last role. I'd ask the tech lead what switching now would cost: how much is thrown away and the effect on the release date. With that, the new owner can make an informed call, and I'd involve the sponsor if the cost is big. Whatever they decide, I'd update the stories and log the change and the reason. If their objection turned out to be a misunderstanding, the briefing alone might settle it.”
Telling the new stakeholder it's already signed off so it can't change.
In the room: switch to methods that give everyone a voice: silent sticky notes, round-robin, walking through a real example.
Direct questions: ask specific people about their own part of the process.
Outside the room: follow up with smaller sessions or job shadowing.
Reconcile: bring differences back as observations, not as people contradicting their boss.
“In the room, I'd change the format rather than confront anyone. I might say 'let's all write the three biggest problems on sticky notes before we discuss', so everyone's view lands on the wall before the senior person speaks. I'd also ask specific people about their own step, like 'Sam, when an order comes in missing details, what do you actually do?' because that's hard to answer for someone else. Afterwards I'd set up short one-to-ones or sit with users while they work, where people are more open. If I find the day-to-day process differs from what the senior person described, I'd present it as 'here's what we saw in practice', not 'your team disagrees with you'. If the users' view matched the senior person's, fine, I'd have more confidence in the requirements.”
Writing down only what the senior person said and calling the requirements complete.
Confirm: check with more observation or data that it's a pattern, not one busy day.
Understand why: ask the team what stops the second check: time, tools, unclear rules.
Raise carefully: share it with the manager as a process gap, not blame.
Design: base the to-be on the real process and decide with the manager whether the second check is needed.
“First I'd make sure it's a real pattern. I'd watch a bit longer or look at the system records to see how many requests have two approvals logged. If it's consistent, I'd ask the team, without judgement, what usually happens with the second check. Maybe they're short-staffed, or the tool doesn't prompt for it, or people think it's only needed above a certain amount. Then I'd talk to the manager privately and describe what I saw as a gap between the written process and practice, and the reasons behind it. That matters for the new system, because if we design around a process nobody follows, we'll get it wrong. Together we'd decide whether the second check should be enforced, limited to risky cases or dropped. If it turns out to be a legal control, it's a risk to flag, not just a design detail.”
Ignoring what you saw and modeling the process the manager described, or reporting the team to senior management.
Question the rule: find out why the two-level approval exists and what risk it controls.
Options: adapt the process to the product, use configuration or a workaround, or customise.
Cost over time: include upgrade pain, testing and vendor support, not just the build.
Recommend: give the sponsor the options side by side with a recommendation.
“I'd start by asking why the rule exists. If two approvals are there because large discounts once got abused, the real need is control over big discounts, and there may be other ways to get it. Then I'd look at options. Can the product's standard approval be set up with a threshold, so one approver handles small discounts and a senior person handles large ones? Could a report of big discounts reviewed weekly do the job? Only then would I look at customising. Customisations tend to cost more than the build: every upgrade needs retesting, and the vendor may not support it. I'd lay the options out for the sponsor with cost, risk and effort. If the rule turned out to be a legal or audit requirement the product can't meet, I'd lean towards customising, and I'd push to keep it small.”
Agreeing to customise straight away because the business asked, without checking why the rule exists or what it costs later.
Check the scoring: were the weightings agreed up front, and do they reflect what matters most?
Unpack the preference: ask users what exactly won them over; demos are polished.
Test it: run scripted scenarios with real data on both, with users hands-on.
Recommend: present the evidence and a clear view, including risks, to the decision maker.
“I'd treat it as a sign that either the scoring or the demo is missing something. First I'd look at the matrix again: were the weightings agreed with the business before we scored, or did usability get a small weight when it matters a lot to them? Then I'd ask the users what they liked. If it's 'it looked slick', that's weak, because vendors pick their best screens for a demo. If it's 'it handles our month-end in three clicks instead of ten', that's a real requirement we may have underweighted. To settle it, I'd ask both vendors to run our own scenarios with our data, with users at the keyboard. Then I'd bring the results, costs and risks to the sponsor with my view. If the users' favourite held up in the hands-on test, I'd happily change my recommendation.”
Insisting the higher score wins because the matrix says so, or dropping the matrix because users are excited.
Baseline: measure how long the task takes today, how often, and how many errors it produces.
Benefits: hours freed, fewer errors and rework, faster turnaround, plus any risk reduced.
Costs: build, licences, testing, change and ongoing support.
Present: a simple comparison with a cautious and a likely case, and the assumptions stated.
“I'd start with real numbers for today. I'd time the task with the people who do it, count how many are done each week, and pull how often errors are caught and fixed later, since rework is often a hidden cost. Then I'd list the benefits: hours freed, fewer errors, faster turnaround, and maybe less risk if errors reach customers. On the other side, I'd get estimates for building it, licences, testing, training and support each year. I'd show the sponsor a cautious case and a likely case, with every assumption written down, so they can challenge any of them. I'd also be honest that freed hours only matter if the team does something useful with them. If the baseline showed the task took far less time than people thought, I'd tell the sponsor the case is weak.”
Taking the team's rough guess of time spent and multiplying it out into a big, confident figure.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It stays out of screen share on every plan, including Free; only you can see it.