Stories about the people around your work, as reported from real data engineering loops: a disagreement with your manager, a stakeholder who pushed, two deadlines in one week, and requirements nobody could explain.
With a colleague, a manager, a whole team or another team. Scored on Have Backbone; Disagree and Commit: evidence over volume, and full commitment once the call is made.
Stakeholders and influence
6
The people who want something from your data, and the people you need something from. Scored on Earn Trust, and on changing what others do without authority over them.
When there was not enough time
5
Conflicting priorities, a missed deadline, a last-minute push, and speed against accuracy. Scored on Deliver Results: what you cut, what you protected, and who heard it from you first.
Ambiguity and teamwork
3
Requirements nobody could explain, and projects you only finished together. Scored on whether you create clarity instead of waiting for it, and on naming your own part.
Evergreen · the HR round
5
The questions HR asks word for word about the move itself: why you are leaving, why here, where you are headed, and what you are bad at.
01 / 25
Reported · 2Disagreement & conflict
Tell me about a time you disagreed with someone and how you resolved it.
What they are scoring
One of the most frequently submitted prompts on Exponent — tagged at Amazon, Apple, Google, Meta and Snap, including for data engineers. It is Amazon’s Have Backbone; Disagree and Commit: the interviewer scores whether you disagreed with evidence rather than opinion, listened, and reached an outcome both sides could commit to.
A strong answer, in two sentences
Choose a disagreement about something that mattered — a design, a metric, a deadline — and show your evidence, how you tested the other view, and how it was decided. Whether you won matters less than how you disagreed and what you did after the decision.
The reasoning
Pick a technical or business disagreement, not a personality clash. For data engineers the strong ones are about a data model, a tool choice, a metric definition, or whether something was ready to ship. The more the other person had a point, the better the story — it shows you engaged with it.
**A worked example, to replace with yours.** *Situation:* an analytics lead wanted our core orders fact table rebuilt nightly with each customer’s current segment, so dashboards could filter on it. *Task:* I owned the model, and I thought it would restate closed quarters every time a customer changed segment. *Action:* rather than argue in the thread, I built both options on a copy with three months of data and showed her the difference: stamped with the current segment, last quarter’s revenue by segment changed on every rebuild; stamped with the segment as at order time, it did not. She pointed out that her analysts also needed to slice by the current segment, which I had not considered, so we shipped both — the segment as at order time on the fact, and the current segment on the customer dimension as a Type 1 attribute. *Result:* shipped in a week, and closed quarters have not shifted since. *Lesson:* a demo on real data settles in an hour what a thread argues for a week.
Show the other side fairly. Interviewers are wary of stories where the other person was simply wrong; a disagreement in which both people improved the outcome is the strongest version.
The weak answer
“I disagreed with my colleague, explained why I was right, and they agreed.” No evidence, no listening, no sign the other view had merit — and a candidate who always wins the story may not notice when they are wrong.
They’ll ask next
What would you have done if the decision had gone the other way?
Reported · 3Disagreement & conflictInfluence without authority
Tell me about a time you disagreed with your manager or team lead and how you resolved it.
What they are scoring
Reported by Meta data engineering candidates, and asked of data engineers at Apple and Microsoft as “a time you had a conflict with your manager”. Disagreeing upwards is harder and more telling: the interviewer scores whether you raised it directly and respectfully, backed it with evidence, and committed once the decision was made.
A strong answer, in two sentences
Tell a story where you disagreed with your manager’s decision, raised it one to one with evidence and a proposal, and then either changed the decision or committed to it fully. Show the relationship was intact afterwards.
The reasoning
The failure modes are going around your manager, complaining to the team, or quietly doing it your own way. The strong pattern is private, early and specific, with an alternative, and a clear point at which you commit.
**A worked example, to replace with yours.** *Situation:* my manager committed to delivering a new revenue dashboard for sales leadership in two weeks, and decided to ship it on the raw CRM data and clean up duplicates afterwards. *Task:* I was building its data, and I disagreed: the CRM had duplicated accounts that would inflate pipeline value in the very first meeting. *Action:* I asked for fifteen minutes, showed him a query with 4% of accounts duplicated and its effect — pipeline overstated by about $2 million — and proposed shipping on time with a deduplication rule and a flag on unresolved matches. He changed the plan, but disagreed with the flag, which he felt would undermine trust in the dashboard, so we agreed to show it only in the detail view. *Result:* shipped on day thirteen, and sales operations used the flagged list to merge 900 duplicate accounts in the CRM over the next month. *Lesson:* bring the number and a way to still hit the date; a problem without a proposal is just bad news.
If you lost the argument, that can be the stronger story: show that you committed fully and what happened next. “Disagree and commit” is half the principle’s name.
The weak answer
“My manager was wrong, so I did it my way and it worked out.” That is insubordination with a happy ending. Just as weak: “I never disagree with my manager”, which reads as having no backbone.
They’ll ask next
What did you do after the decision went against you — and would you raise it the same way again?
Was there any situation of conflict with the team or any colleague? How did you resolve it?
What they are scoring
Reported word for word from Paytm’s managerial round for a data engineer — the follow-up was “How did you resolve and confront such a situation” — and asked of DoorDash data engineers as “a time you had a conflict with a colleague”. The interviewer scores maturity: whether you addressed it directly, separated the person from the problem, and whether it stayed resolved.
A strong answer, in two sentences
Pick a real friction with a colleague over how work was done — not a personality clash — and show you raised it directly and privately, understood their side, and agreed a concrete change. End with how you worked together afterwards.
The reasoning
Conflict questions are scored on how you behaved, not on who was right. Show that you went to the person first, asked what was going on from their side, and turned it into a specific agreement — a process, a boundary, a way of reviewing — rather than a vague truce.
**A worked example, to replace with yours.** *Situation:* a colleague on the analytics team kept changing shared dbt models in our production project without review, and twice broke my pipeline’s downstream tests the night before a release. *Task:* it was hurting my deliveries, and complaining to our managers would have made it political. *Action:* I asked him for a coffee and described what I had seen, with the two broken runs. It turned out he was under pressure from his own stakeholders and our review queue took two days. We agreed that changes to shared models would get a same-day review from whoever was on rotation, and I added a CI check that ran the downstream tests on every pull request, so neither of us had to rely on memory. *Result:* no broken runs from shared-model changes in the next quarter, and review time dropped to under four hours. *Lesson:* the behaviour that annoyed me was a symptom of a slow process I also owned.
Avoid stories that end with a manager stepping in unless you tried directly first. And never describe the colleague unkindly — interviewers notice.
The weak answer
“I have never had a conflict,” which is not believed, or a story where the colleague was difficult and you escalated to your manager. Both skip the part being scored: what you did, directly, to fix it.
They’ll ask next
How did you confront it — what did you actually say in that first conversation?
Reported from Expedia Group’s HR and managerial round, and from a Morgan Stanley executive-director round as “How you can overcome challenges faced in the team”. It asks for your method as much as a story: how a group of engineers reaches a decision without the loudest voice winning.
A strong answer, in two sentences
Describe how you get a group to a decision: make the options and their costs explicit, agree who decides and by when, and then commit together. Prove it with one time you did exactly that.
The reasoning
A good method has three parts. Make the disagreement concrete — write the options down with their trade-offs, ideally with data. Agree on the decision-maker and a deadline, because many team arguments are really about who decides. And once it is decided, everyone commits, including the people who argued against it.
**A worked example, to replace with yours.** *Situation:* our team of five split over whether to move our batch jobs from a self-managed Spark cluster to a managed service. *Action:* I wrote a two-page comparison — monthly cost, migration effort, what we would lose (custom tuning) and gain (no cluster on-call) — and asked the two most opposed engineers to each correct the other side’s section. We agreed our lead would decide at the next planning meeting. *Result:* the managed service won on cost and on-call load; the engineer who had argued hardest against it led the migration of the heaviest job; and cluster pages went from about six a month to none. *Lesson:* letting each side correct the other’s case took the heat out — people argued with the document instead of with each other.
Mention what you do when a decision is reversible: try it for a fixed period and measure, rather than debating it.
The weak answer
“We vote,” or “I explain my view until they understand.” Voting ignores who carries the cost, and persuading people until they give up is not agreement. The interviewer is listening for a way to decide and to commit.
They’ll ask next
And if the decision-maker picks the option you think is wrong?
Reported · 1Disagreement & conflictInfluence without authority
Tell me about a time you disagreed with a decision and weren’t able to persuade others. How did you voice the disagreement, and why didn’t the outcome go your way?
What they are scoring
Reported by Netflix engineering candidates, and the purest test of Disagree and Commit. Anyone can tell a story where they won. The interviewer scores how you argued, whether you understand why you lost, and whether you committed fully afterwards.
A strong answer, in two sentences
Tell a story where you made your case clearly and lost, explain honestly why the others decided differently, and show that you then committed and helped the chosen option succeed. Say what you learned about when to push and when to let go.
The reasoning
The last clause of the question is the test: why didn’t it go your way? A strong answer credits the other side’s reasoning — they weighed something you did not, or had context you lacked. A weak one implies they were wrong and you were overruled.
**A worked example, to replace with yours.** *Situation:* our team was choosing an orchestrator for a new platform, and I argued for Dagster because its asset model fitted our dbt-heavy work. *Voicing it:* I wrote the comparison and presented it at the design review. *Why I lost:* three other teams already ran Airflow, the platform team supported it on call, and our lead judged that one orchestrator across the company was worth more than a better fit for us. That was a fair call I had underweighted. *Committing:* I built our first fifteen DAGs on Airflow, used its data-aware scheduling (Datasets, renamed Assets in Airflow 3) to get closest to what I had wanted, and wrote the team’s guide to it. *Result:* the platform shipped on schedule and we shared on-call with the platform team, which roughly halved our pages. *Lesson:* I now ask what a decision costs the rest of the organisation, not only my team.
Do not re-argue the decision in the interview. “In hindsight they were right” or “it worked out fine” is stronger than a story that is still a grievance.
The weak answer
A story that is really a complaint — the team made the wrong call and you were proved right later. It fails the commit half of the principle, and it tells the interviewer you hold on to lost arguments.
They’ll ask next
Looking back, was the decision right? What would have changed your mind at the time?
Tell me about a time you had to work out a conflict cross-functionally across teams.
What they are scoring
Reported first-hand by a Fanatics Data Engineer II candidate. Data engineers sit between the teams that produce data and the teams that consume it, so cross-team conflict is the job: a product team changes an event, analytics wants it back, the platform team wants it standardised. The interviewer scores whether you found the shared goal and a mechanism, not a one-off favour.
A strong answer, in two sentences
Name the two teams and what each needed, show how you made the conflict about a shared outcome rather than about the teams, and describe the mechanism you put in place — a contract, a process, an owner — so it did not recur.
The reasoning
Cross-team conflicts in data are usually about who pays for a change. The producing team wants to move fast; the consuming teams want nothing to break. A strong answer names that tension and turns it into an agreement with a mechanism behind it.
**A worked example, to replace with yours.** *Situation:* the mobile team renamed and restructured several tracking events in a release, and three analytics teams lost two weeks of funnel data. Both sides were blaming each other in a shared channel. *Task:* I owned the events pipeline in between. *Action:* I got one person from mobile and one from analytics into a room and started from the shared goal — launches that could be measured. We agreed a lightweight contract: the 30 events used in company metrics would be listed in a schema registry, mobile’s CI would warn on changes to them, and my team would provide a mapping for any rename given a week’s notice. *Result:* the next two releases changed eight tracked events with no data lost, and the analytics teams stopped building their own workarounds. *Lesson:* the conflict was never about the rename; it was that nobody knew which events mattered.
Mention the escalation you avoided. Solving it between the teams, with a mechanism, is the signal; getting two directors to rule on it is not.
The weak answer
“I asked the other team to stop changing things, and they agreed.” That is a favour, not a resolution: nothing stops it recurring, and it treats the other team as the problem.
They’ll ask next
What happened the first time someone broke the agreement?
Tell me about a time when you handled a difficult stakeholder.
What they are scoring
One of the most widely reported behavioral prompts — submitted by candidates at Amazon, Google, Meta, Microsoft, Stripe, DoorDash and Capital One. For a data engineer the stakeholder is usually someone who depends on your data and has lost patience with it. The interviewer scores empathy, candour, and whether you changed the relationship with something concrete.
A strong answer, in two sentences
Describe what made the stakeholder difficult from their side, not just yours — usually a history of late or wrong data — and the specific thing you did to rebuild trust. End with a measurable change in the relationship.
The reasoning
The trap is describing the stakeholder as unreasonable. Most difficult stakeholders have a reason: they have been burned before. A strong answer finds that reason and addresses it with something they can see — a status page, an SLA, an early warning.
**A worked example, to replace with yours.** *Situation:* the head of finance planning escalated to my director every time the daily revenue table was late — about twice a month — and her team had started building their own extracts from the source system. *Task:* I owned the pipeline. *Action:* I met her and asked what a late table actually cost her: it was the 9am forecast meeting. I committed to an 8am SLA, added an alert that told her team by 7:30 if we would miss it and when the data would land, and fixed the two causes of lateness — an upstream export that ran late at month-end and a job that retried too slowly. *Result:* the table missed its SLA once in the next six months, the escalations stopped, and her team retired their shadow extracts. *Lesson:* people are rarely angry that data is late; they are angry about finding out at 9am.
Show where you held a line. Being responsive does not mean doing everything you are asked; a good story may include one request you declined, with reasons.
The weak answer
A story that spends most of its time on how unreasonable the stakeholder was, or one where you gave them everything they asked for. The first lacks empathy; the second lacks judgement.
Describe a time you pushed back on a stakeholder request.
What they are scoring
Reported by DoorDash data engineering candidates, and asked at Amazon as “a time you pushed back against an unreasonable customer request”. Saying no is part of owning a platform. The interviewer scores whether you said no with reasons and an alternative, and whether the relationship survived.
A strong answer, in two sentences
Pick a request that would have cost something real — correctness, reliability, another team’s time — and show how you said no: the reason in their terms, and an alternative that met their actual need. End with what they got and how they felt about it.
The reasoning
A good no has three parts: understand the need behind the request, explain the cost of doing it as asked in the stakeholder’s own terms, and offer something that meets the need. “No, but” is a skill; a plain “no” is a wall.
**A worked example, to replace with yours.** *Situation:* a marketing manager asked for direct write access to our production customer table so her team could fix segment labels themselves. *Task:* I owned the table, which fed billing and six other pipelines. *Action:* I asked what the fixes were — about 50 customers a week put in the wrong segment by a rule nobody had updated. I explained that direct writes would be overwritten by the nightly load and could break billing, and offered instead a small override table her team could edit from a spreadsheet, applied by the pipeline with an audit log. *Result:* live in four days; her team made about 200 overrides in the first month with none lost, and the override history was later used to fix the rule itself. *Lesson:* the request was for access; the need was for control over 50 rows.
Say how you delivered the no. In person or on a call, with the alternative ready, lands very differently from a comment on a ticket.
The weak answer
“I told them it wasn’t possible because of policy.” No understanding of the need, no alternative, and hiding behind a rule. Or the opposite: a story in which you never push back at all.
They’ll ask next
What would you have done if they had escalated to your manager?
Reported · 3Influence without authorityStakeholder management
How do you influence without authority?
What they are scoring
Among the most cross-company prompts on Exponent — tagged at Salesforce, Google, American Express, JPMorgan and more, including for data engineers — and put to a Rakuten data engineer as “How do you convince your colleagues or the business to adopt a new technology?”. Data engineers rarely own the teams they need to change, so this is scored as a core skill.
A strong answer, in two sentences
Influence comes from making the other team’s problem smaller: learn what they care about, show evidence on their own data, make the first step cheap, and give them the credit. Prove it with one time you changed what another team did.
The reasoning
A method that works: find what the other team is measured on, show how your proposal moves that measure using their own data, remove the effort of the first step by doing the pilot for them, and let them present the result. Authority gets compliance; this gets adoption.
**A worked example, to replace with yours.** *Situation:* our platform supported data-quality tests, but the four product-analytics teams publishing into it rarely wrote any, and bad data reached dashboards every week. *Task:* I had no authority over those teams. *Action:* I found the team with the most incidents and offered to write the first ten tests on their three most-used tables myself. Within two weeks the tests caught an upstream bug before it reached their dashboard, and I asked their lead to show that at the analytics all-hands. Then I turned what I had written into a template any team could copy in ten minutes. *Result:* within a quarter all four teams had tests on their key tables — about 180 in total — and weekly data incidents fell from around five to one. *Lesson:* one team’s success, told by that team, was worth more than any standard I could have written.
Mention the people who did not come along, and what you did about them. Influence stories in which everyone agreed immediately sound invented.
The weak answer
“I explain the benefits clearly and people usually agree,” or “I escalate to their manager.” The first has no method and no evidence; the second is authority borrowed from someone else.
They’ll ask next
Tell me about a time you tried to influence a team and it did not work.
Reported · 1Explaining to non-engineersStakeholder management
How would you explain a technical concept to a non-technical person?
What they are scoring
Submitted by candidates at Meta, Google and others, and a staple of the hiring-manager round for data roles, whose stakeholders are finance, product and operations. The interviewer often hands you a concept on the spot — a pipeline, a late partition, why a number changed — and scores whether you can explain it without jargon and check that it landed.
A strong answer, in two sentences
Start from what the listener needs to decide, use one analogy from their world, and give them the consequence rather than the mechanism. Then check understanding by asking what they would do with it.
The reasoning
Three moves. Anchor on their decision: “you want to know whether you can trust Monday’s number.” Use one analogy from their world, not a stack of them. And stop at the level of detail that changes what they do — the mechanism is useful only if they ask for it.
**A demonstration, for a finance audience: why was yesterday’s revenue revised?** “Think of the revenue table as a till count at closing time. Most sales are counted by midnight, but card refunds and late payments keep arriving for another two days, like cheques that come in after close. So yesterday’s number is a first count, and it settles by Thursday. For decisions that need to be exact, use days that are more than three days old; for trends, yesterday’s is fine.” No mention of late-arriving data, watermarks or backfills — but that is exactly what it describes.
Back it with a story if you have one: “I explained this to our CFO’s team after they saw revenue change between two meetings. We added a ‘provisional’ label to the last three days, and the questions stopped.” That turns a claimed skill into evidence.
The weak answer
Defining terms — “a pipeline is an ETL process that extracts, transforms and loads data” — which is jargon explaining jargon. Or talking at length without ever checking whether the listener followed.
They’ll ask next
Explain to me, as if I ran the finance team, why our dashboard and the source system show different numbers for yesterday.
Tell me about a relevant complex program you’ve managed. How did you handle stakeholder and team management, and escalating issues while prioritizing work?
What they are scoring
Crowdsourced from Amazon data engineering loops. It is four questions in one, so structure is scored: how you kept many people aligned, what you escalated and when, and how you decided what came first when everything was urgent.
A strong answer, in two sentences
Pick a program with several teams and a hard date — a migration is ideal — and answer each part in turn: how you kept stakeholders informed, how you split the work, what you escalated and why, and how you prioritised. Close with delivery against the date.
The reasoning
Answer the parts in the order they were asked, and signpost them — “on stakeholders… on the team… on escalation… on priorities”. It shows you listened, and it is how the interviewer will score it.
**A worked example, to replace with yours.** *The program:* migrating 120 reporting tables from an on-premise warehouse to Snowflake before the data-centre contract ended, with four consuming teams and three engineers. *Stakeholders:* one page listing every table, its owner, its migration week and its status, updated every Friday, and each consuming team signed off a reconciliation of its own tables. *Team:* we migrated in waves ordered by dependency, so no table moved before its sources. *Escalation:* in week six one team could not validate in time because of its own release. I escalated to my manager with two options — slip that team by two weeks, or keep the old warehouse one extra month for about $12,000 — and she chose the extension. *Priorities:* anything feeding finance close went first. *Result:* all 120 tables moved, 118 of them on schedule, with no reconciliation differences in finance reporting.
Say what you escalated and why at that moment. Escalating early, with options, is a strength; the interviewer is checking you know the difference between escalating and giving up.
The weak answer
A narrative with no structure that answers one of the four parts, or a program where you were a participant rather than the person running it. With a multi-part question, missing parts reads as not listening.
They’ll ask next
What is the one thing you would have escalated earlier?
How do you encourage collaboration among cross-functional teams?
What they are scoring
Submitted by data engineering candidates at Amazon and Microsoft. A data engineer’s work is only useful when product, analytics and engineering agree on what the data means, so the interviewer scores whether you have practical habits for getting them to work together — and one example.
A strong answer, in two sentences
Give two or three concrete habits — shared definitions, one place for requests and status, consumers involved early in design — and prove one of them with a result. Practices beat principles.
The reasoning
Useful habits for data teams: write the metric or table definition with its consumer before building it; keep one visible intake and status board instead of requests in private messages; invite the consuming analyst to the design review; and credit other teams publicly when their input made the result better.
**A worked example, to replace with yours.** *Situation:* product, analytics and data engineering each defined “active user” differently, and every quarterly review opened with an argument about whose number was right. *Action:* I proposed a one-hour session with one person from each team and a shared document showing three candidate definitions and what each would have reported for last quarter. We picked one, recorded it in our semantic layer with an owner, and I built a comparison view so each team could see how its old number mapped to the new one. *Result:* one definition in every dashboard within a month, and the next quarterly review spent no time on reconciliation. *Lesson:* people collaborate when there is one artefact to argue with.
Keep it concrete. An answer built from words like “alignment” and “communication”, with no practice and no example, scores low.
The weak answer
“I believe in open communication and regular syncs.” Principles without practice, and nothing the interviewer could check.
They’ll ask next
Tell me about a time a cross-functional project went badly. What would you do differently?
How do you handle conflicting priorities and tight deadlines?
What they are scoring
Submitted by candidates at LinkedIn; asked in Paytm’s managerial round for a data engineer as “In these jobs we deal with deadlines, so how did you manage your time?”, and at Expedia as “Handling tight deadlines / pressure work?”. The interviewer scores your rule for deciding what comes first, and whether people hear about a slip before it happens.
A strong answer, in two sentences
State your rule — what blocks others, business impact, how hard each deadline really is — and that you make the trade-off visible to the people affected instead of choosing silently. Prove it with one week in which you did exactly that.
The reasoning
A credible rule: finish what blocks other people first; within that, rank by business impact and by how hard the deadline really is — a regulatory filing is hard, an internal demo usually is not; and when two things cannot both be done, take the choice to whoever set the priorities, with a recommendation.
**A worked example, to replace with yours.** *Situation:* in one week I had a finance month-end data fix, a new dashboard feed for a product launch, and a migration task for my own team. *Action:* month-end was a hard date and blocked finance, so it went first; the launch feed had a fixed date, so it went second. On Monday I told my lead the migration task would slip a week and why, and asked the product manager whether a manual extract would cover launch day if I ran late — it would. *Result:* month-end closed on time, the launch feed shipped on day two of the launch with the manual extract covering day one, and the migration task landed the following Wednesday. *Lesson:* telling people on Monday is what made Thursday calm.
Mention how you protect focus under pressure — batching interruptions, one person on a support rotation — if you can back it with an example.
The weak answer
“I work extra hours to get everything done.” That is not prioritisation and it does not scale. Also weak: a rule with no example, or an example in which you quietly dropped something and nobody knew.
They’ll ask next
What do you do when two senior stakeholders both say theirs is the top priority?
Tell me about a time when you had two deadlines at the same time. How did you manage the situation?
What they are scoring
A Bar Raiser prompt for Deliver Results. Unlike the general “how do you prioritise”, it asks for a specific collision, so the interviewer can score what you actually did: what you chose, who you told, and what it cost.
A strong answer, in two sentences
Tell the specific collision, the information you used to choose, and the conversation you had with the owner of the deadline you moved. Give the outcome for both deadlines, including the one that slipped.
The reasoning
This is a story, not a philosophy. The interviewer wants the moment you realised both could not be done, who you went to, what you proposed — and what happened to the one you deprioritised.
**A worked example, to replace with yours.** *Situation:* a data feed for a partner integration and an internal reporting migration were both due on the same Friday, and a production incident had eaten two of my days. *Action:* on Tuesday I asked both owners what their date was attached to. The partner date was in a contract; the migration date had been chosen to fit a sprint. I proposed moving the migration by a week, with a note to the three analysts who would keep using the old tables, and my lead agreed. I also cut scope on the partner feed: I shipped the four fields in the contract and deferred two nice-to-haves. *Result:* the partner feed went live on Friday and passed their validation first time; the migration finished the following Thursday with no reporting gap. *Lesson:* ask what a date is attached to before deciding which one moves.
Name the cost. Something always gives; saying what, and that you told the people affected, is what makes the story credible.
The weak answer
“I managed my time well and delivered both on time.” Possibly true, but it leaves nothing to score — no choice, no trade-off, no conversation. If both were easy to hit, it is not the story they asked for.
They’ll ask next
How did the owner of the deadline you moved react, and what would you have done if they had refused?
Was there any situation where you missed deadlines? What did you do then?
What they are scoring
Reported word for word from Paytm’s managerial round for a data engineer, and asked at Amazon as “Give an example of a tough deadline you missed. How did you communicate it?”. The interviewer scores honesty and timing: did you see it coming, and did people hear it from you early.
A strong answer, in two sentences
Admit a real missed deadline, say when you knew it would slip and when you told people — ideally the same day — and what you did to limit the impact. End on what you changed about how you estimate or report progress.
The reasoning
Everyone misses deadlines; the scoring is on when you raised it. The strongest stories have a clear moment — “on the Tuesday I could see we would miss Friday” — followed by telling the people affected that day, with a new date and what they would get in the meantime.
**A worked example, to replace with yours.** *Situation:* I committed to delivering a customer lifetime-value table for a marketing campaign in three weeks. *What happened:* in week two I found that refund data from the payments provider arrived with a ten-day lag, so any value computed for recent customers would be wrong. *Action:* I told the marketing lead that day, explained the lag in one paragraph, and offered two options: a table on time that excluded customers from the last ten days, or the full table a week late, with an estimate of pending refunds for recent customers built from their historical refund rate. She chose the partial table for the campaign’s first wave. *Result:* the first wave launched on time covering 94% of customers; the full table landed six days later for the second wave. *Lesson:* I now check the latency of every source in the first two days of a project, not when I reach it.
Do not blame the source, the team or the requirements, even if they were part of the cause. Own the part that was yours — here, not checking data latency early.
The weak answer
“I have never missed a deadline,” which interviewers do not believe, or a story in which you told people on the day of the deadline. Both suggest a candidate who would surprise their manager.
They’ll ask next
When exactly did you know you would miss it, and how long was it before you told anyone?
Reported · 1Prioritisation & deadlinesBias for action
Any project you did at the last moment? What did you do?
What they are scoring
Reported from an Amazon data engineer loop, where the interviewer followed with “What problem did you face?” and, in the next round, “How did you solve it?”. It checks how you work on a compressed timeline — what you cut, what you kept, and whether the result held up.
A strong answer, in two sentences
Tell a real last-minute delivery honestly, including why it was last-minute, then walk through the problem you hit and how you solved it against the clock. Finish with whether it held up and what you would do to avoid the rush next time.
The reasoning
Be honest about the cause. A project that was last-minute because the request arrived late is a different story from one you left too late, and interviewers can tell which. Either is fine if you own it and show what you learned.
**A worked example, to replace with yours.** *Situation:* two days before a board meeting, the CFO asked for a cohort retention analysis that did not exist in any table. *The problem:* after a billing migration, subscription start dates lived in two systems, and about 8% of customers appeared in both with different dates. *How I solved it:* I agreed a rule with the finance analyst — the earliest paid date wins — wrote a deduplicating view, and checked it by reproducing last quarter’s published retention figure to within 0.3% before building the cohorts. *Result:* the analysis was ready the evening before the meeting, and its numbers were never questioned. *Next time:* I turned the view into a proper cleaned table the following week, so the next request like it would take hours rather than two days.
Expect the chained follow-ups. The interviewer in the reported loop drilled into the problem and the solution across two rounds, so know your story’s technical detail.
The weak answer
A story about an all-nighter where the effort is the point, or one with no problem in it. The reported follow-ups — what problem did you face, how did you solve it — show the interviewer wants the problem-solving, not the hours.
Share an example of when you had to balance speed with accuracy in your deliverables.
What they are scoring
Asked by the hiring manager in a first-hand Amazon BI Engineer loop, and it sets two principles against each other: Bias for Action and Insist on the Highest Standards. Data work gives it a sharp edge — a fast wrong number can be worse than a late right one — and the interviewer scores how you decided which this was.
A strong answer, in two sentences
Show the rule you decided by: what the number would be used for, how reversible a wrong answer was, and what “accurate enough” meant for that decision. Then say how you delivered fast without hiding the uncertainty.
The reasoning
The best answers refuse the false choice. Often you can ship something fast and label it: a preliminary figure with a stated margin, a subset of data that is fully validated, a date by which the final number lands. What you must never do is ship a fast number that looks final.
**A worked example, to replace with yours.** *Situation:* on a Monday the CFO asked how much a pricing change the previous Friday had moved revenue, for a board call on Wednesday. *Task:* the full attribution model needed a week. *Action:* I agreed a two-stage answer with finance — a directional estimate by Tuesday from order-level data with a stated margin of plus or minus half a percentage point, and the full reconciled figure the following Monday. I checked the method against the previous two pricing changes, where it had landed within 0.3 points of the final number. *Result:* the board saw “+4.1%, final figure Monday”; the final number was +3.8%, inside the stated margin. *Lesson:* stating the margin up front is what made the fast number safe to use.
Say which way you lean for which kind of decision. A reversible operational call can take a rough number; anything financial, regulatory or customer-facing waits for the reconciled one.
The weak answer
“Accuracy always comes first for me.” That fails Bias for Action and ignores that the business sometimes needs a direction today. Just as weak: shipping a fast number without saying it was provisional.
They’ll ask next
What would you have done if the final number had landed outside the margin you gave?
Describe a situation where project requirements seemed unclear or unnecessary. How did you handle it?
What they are scoring
Reported first-hand from an Amazon BI Engineer loop. Data requests usually arrive as a solution (“add this column”) rather than a need, and the interviewer scores whether you went back to the need, challenged what did not make sense, and still delivered.
A strong answer, in two sentences
Show how you turned an unclear requirement into a clear one — by asking what decision the data would feed and by showing a draft early — and how you raised a requirement you thought was unnecessary. End with what was actually built and how it was used.
The reasoning
Two moves score well. Ask for the decision the request serves — “what will you do differently depending on this number?” — and show something small early, such as a sample table or a mock of the dashboard, because people react to examples far better than to specifications.
**A worked example, to replace with yours.** *Situation:* a request asked for “a real-time dashboard of all orders”. *Task:* real-time would have meant a streaming pipeline and several weeks of work. *Action:* I asked the operations manager what she would do with it. She wanted to spot restaurants with more than ten late orders in an hour so she could call them, and hourly figures refreshed every fifteen minutes would do that. I showed her a mock built on yesterday’s data within two days, and she changed two of the columns. *Result:* it shipped in a week on the existing batch pipeline with a fifteen-minute refresh; her team cut late-order escalations by about 20% in the first month, and the streaming project was never needed. *Lesson:* “real-time” usually means “sooner than now” — ask how soon.
If you thought a requirement was unnecessary, say how you raised it — with its cost and an alternative — and what the stakeholder decided. Dropping it silently is not the answer.
The weak answer
“I built exactly what was specified,” or “I waited for clearer requirements.” The first can ship the wrong thing; the second ships nothing. The interviewer wants you to create the clarity.
They’ll ask next
What did you do when the stakeholder insisted on a requirement you thought was unnecessary?
A Bar Raiser prompt, filed by IGotAnOffer under Are Right, A Lot. The interviewer wants a method for acting before everything is known, and evidence that your judgement under uncertainty turns out well.
A strong answer, in two sentences
Describe how you reduce ambiguity rather than wait it out: write down what you know and what you are assuming, test the riskiest assumption first, choose a reversible first step, and share the plan so others can correct it. Then prove it with one story.
The reasoning
A strong method, stated briefly: separate facts from assumptions, find the assumption that would hurt most if it were wrong and check it first, choose the step that keeps options open, and make your plan visible so people who know more can correct you.
**A worked example, to replace with yours.** *Situation:* I was asked to “build the data foundation” for a new marketplace product with no defined metrics, no final schema from the application team, and a launch in eight weeks. *Action:* I wrote a one-page list of assumptions — the core entities (buyers, sellers, listings, orders) and the likely first metrics (listings live, orders per day, time to first sale) — and reviewed it with the product manager, who corrected two of them. The riskiest assumption was the order data model, so I agreed an events contract with the application team first and built the raw layer against it, leaving the reporting models for the final two weeks, when the metrics had settled. *Result:* the launch dashboard was ready on day one with six agreed metrics, and only one model needed rework after launch. *Lesson:* ambiguity shrinks fastest when you write your assumptions down where someone can disagree with them.
Avoid “I’m comfortable with ambiguity” as a trait claim. The question asks how you deal with it: answer with a method and a result.
The weak answer
“I thrive in ambiguous environments” — a trait claim with no method and no evidence. The opposite is weak too: “I ask my manager for clear requirements,” which shows no judgement of your own.
They’ll ask next
Tell me about a time your assumption turned out to be wrong. What did it cost?
Can you describe a situation where you had to work closely with a team to overcome a challenging project? What was your role, and how did you contribute to the team’s success?
What they are scoring
Reported from Atlan’s HR round for a data engineer. It is a teamwork question with a trap in it: the interviewer asks “what was your role” because team stories drift into “we”. They are scoring whether you can describe collaboration and still name what you personally did.
A strong answer, in two sentences
Set up the team and the challenge in a sentence, then be precise about your role and two or three things you personally did that moved the team forward. Name how you helped others, not just your own tasks, and give the team’s result.
The reasoning
Balance is the skill. Too much “I” in a team story sounds like taking the credit; too much “we” and nothing can be scored. Say “we” for the goal and the result, and “I” for your actions.
**A worked example, to replace with yours.** *Situation:* our team of four had six weeks to replace a vendor’s reporting feed that was being switched off, covering 30 reports used by customer success. *My role:* I owned the data model and the reconciliation. *What I did:* I proposed splitting the 30 reports by source system so two people could build in parallel without colliding; I wrote the reconciliation queries comparing each new report with the vendor’s for the previous three months; and when a teammate got stuck on the vendor’s undocumented currency logic, I paired with him for a day and we reverse-engineered it from the reconciliation differences. *Result:* all 30 reports were live a week before the switch-off, matching the vendor’s within 0.5%, and customer success saw no gap. *Lesson:* the reconciliation was not only a check — it became the team’s shared definition of done.
Mention one thing you did for someone else on the team. Unblocking a teammate is evidence of teamwork an interviewer can actually score.
The weak answer
A story told entirely in “we”, so the interviewer cannot tell your part from anyone else’s — exactly what the question’s second half asks for. Or a story in which the team is only a backdrop to your solo effort.
They’ll ask next
What would your teammates say was your biggest contribution — and your biggest weakness on that project?
Asked in nearly every HR round — reported from Expedia Group’s managerial round (“Why do you want to leave your current Org/job?”), Innovaccer’s HR round (“why am I looking for a switch”) and Flipkart’s managerial round. It is scored on whether your reason moves towards something, and whether you speak fairly of your current employer.
A strong answer, in two sentences
Give a forward-looking reason tied to this role — scale, a domain, a kind of work you cannot get where you are — and say something fair about your current job. Keep it to three sentences.
The reasoning
**Pull, not push.** “I’ve learned a lot running batch pipelines for a mid-size retailer, and I want to work on streaming at a much larger scale, which is most of what this team does.” That is a reason to join them, not an escape.
**Stay fair to your employer.** Interviewers assume you will one day talk about them the way you talk about your current company. Even if the real reason is a bad manager or no growth, frame it as what you are looking for: ownership of a larger system, a stronger engineering culture, a domain you care about.
**Be consistent.** HR compares this answer with what you told the recruiter and the hiring manager. If money is part of it, that is fine to say plainly once, in the compensation conversation — not as the headline here.
The weak answer
Criticising your manager or company, or giving money as the only reason. Both raise questions about how you will one day leave this job, and neither says why you want this one.
They’ll ask next
What would have to change at your current company for you to stay?
Why do you want to join our company, and how do you think you can contribute?
What they are scoring
Reported, with the company’s name in it, from the HR rounds of Booking.com, Walmart Global Tech (“What inspires you to join Walmart?”), Tiger Analytics (“Why Tiger Analytics and Data Engineering?”) and Atlan. It tests whether you did your homework, and whether your reasons would survive the first difficult month.
A strong answer, in two sentences
Name something specific about their data — the scale, the product, a problem they have written about — and connect it to what you want to do and what you bring. One specific reason beats three generic ones.
The reasoning
**Research one real thing.** Their engineering blog, a talk by their data team, the stack in the job description, or the product itself. “Your post on moving your events platform to Kafka is exactly the kind of problem I’ve been working towards” is specific and checkable.
**Connect it to you.** The reason should explain why this role is your next step and what you bring to it: “I’ve built CDC pipelines into a warehouse at a smaller scale; you’re doing it across thousands of tables.”
**For services and consulting firms,** the honest answer is often breadth — different clients, domains and stacks within a few years. Say that, and name the kind of client work you want.
The weak answer
“It’s a great brand with a good culture and growth opportunities.” True of many companies and specific to none; it tells the interviewer you have not looked.
They’ll ask next
What do you know about our data platform, and what would you want to change about it?
What are your long-term career aspirations, and how does this role align with them?
What they are scoring
Reported word for word from Atlan’s HR round for a data engineer. The interviewer is checking that this role is a step on your path rather than a detour you will leave in a year, and whether your ambition is concrete.
A strong answer, in two sentences
Name a direction, not a title — deeper technical ownership, or a move towards leading teams — and show how this role’s work builds it over the next two or three years. Keep it honest and specific.
The reasoning
**A direction with a next step.** “In five years I want to be the engineer who designs a company’s data platform, not just pipelines on it. This role gets me there, because I’d own ingestion end to end and work with the platform team on the lakehouse migration.”
**Match the level to the role.** For a two-to-four-year role, a staff-engineer or management goal is fine long-term, but the near-term part should be about getting excellent at the job they are hiring for.
**Avoid a plan that leaves the role.** “I want to move into data science” or “start my own company” may be true, but it tells the interviewer you are passing through.
The weak answer
“I want to be in a leadership position,” with no idea what that means or how this role helps — or a goal that points away from the job on offer.
They’ll ask next
What will you need to learn in the next two years to get there, and how will this role help?
What are your weaknesses, and what are you doing about them?
What they are scoring
Submitted by data engineering candidates at Accenture and Google as “What are your weaknesses?”, and a staple of HR rounds everywhere. Scored on self-awareness: a real weakness, relevant but not disqualifying, and evidence you are working on it.
A strong answer, in two sentences
Name one real weakness that matters in the job but does not disqualify you, give an example of it costing something, and describe what you are doing about it and how you know it is improving.
The reasoning
**A real one, relevant but not fatal.** For a data engineer: over-engineering early designs, saying yes to too many requests, going quiet when blocked, or under-investing in documentation. Not “I can’t write SQL” for a SQL-heavy role, and not a disguised strength.
**Evidence and a fix.** “I tend to take on every stakeholder request myself. Last year it meant two deliveries slipped in the same month. Now every request goes through our team’s intake board, and I review my commitments with my lead every Monday — I haven’t missed one since.”
**Keep it short.** Thirty seconds, then stop. Dwelling on it turns a self-awareness answer into a confession.
The weak answer
“I’m a perfectionist” or “I work too hard.” Interviewers hear these every day as humblebrags, and they score as a lack of self-awareness.
They’ll ask next
Tell me about a time that weakness actually cost you something.
What types of team members do you find difficult to work with?
What they are scoring
Submitted by a data engineering candidate at Visa. It sounds like an invitation to complain and is scored on the opposite: whether you can name a working style that challenges you, describe it without contempt, and show how you work with it.
A strong answer, in two sentences
Name a behaviour, not a type of person — changes made without telling anyone, say — explain why it is hard for you, and show how you work well with people like that anyway.
The reasoning
**Describe a behaviour.** “I find it hard when people change shared data or definitions without telling anyone” is a behaviour; “lazy people” is a judgement. Pick something that genuinely makes data work harder, so it rings true.
**Show the adjustment.** “When I’ve worked with someone like that, it was usually because our process made telling people slow. I set up a CI check that flags changes to shared models and asked them to add me as a reviewer. After that we worked well together.”
**Stay generous.** The interviewer is picturing you describing their team to someone else. End on how you get the best out of people who work differently from you.
The weak answer
A list of personality types you dislike, or a story about a specific colleague that turns into a complaint. Both suggest you will be hard to work with.
They’ll ask next
Tell me about the last time you worked with someone like that. What did you do?
