Stories about your own work, as reported from real data engineering loops: the issue you traced to its root cause, the project you are proudest of, the cost you cut, the mistake that was yours.
Outages, wrong numbers and decisions at 11pm. Scored on Dive Deep and Bias for Action: how you found the cause, and how you acted before you had all of it.
What you owned
3
Problems outside your remit that you took on anyway, and the people downstream of your work. Scored on Ownership and Customer Obsession.
What moved because of you
5
The project, the process and the bill. Scored on Deliver Results, Invent and Simplify and Frugality — and always on the number at the end.
What went wrong, and what changed
6
Mistakes, ideas that failed, feedback that stung and skills you had to learn. Scored on Earn Trust and Learn and Be Curious: ownership without excuses, and proof you changed.
Evergreen · the HR openers
3
Asked word for word at the start or end of almost every loop, by HR and hiring managers alike. Not stories, but they set up the stories.
Walk me through a data quality or pipeline incident you owned end to end.
What they are scoring
Reported by DoorDash data engineering candidates, and the data engineer’s version of the ownership question every loop asks. “End to end” is the point: the interviewer scores detection, containment, communication, the fix, and what you changed so it could not recur — and whether each step was yours.
A strong answer, in two sentences
Tell it in the order an incident runs: how it was detected, how you stopped the damage, who you told and when, the root cause, the fix and the backfill, and the prevention. Put a number on the blast radius and on the recovery.
The reasoning
Structure beats drama. Interviewers listen for five phases in order — detect, contain, communicate, fix, prevent — and for the moment you chose containment over diagnosis. A candidate who starts debugging while bad data keeps flowing downstream loses the Ownership signal, however clever the fix.
**A worked example, to replace with yours.** *Situation:* a Monday alert showed yesterday’s orders in the warehouse were 30% above the source database, and finance reads them at 9am. *Task:* I was on call and owned the orders pipeline. *Action:* I paused the downstream dbt models so the finance and marketing dashboards kept showing Saturday’s validated data, and posted in the incident channel with the impact and the time of the next update. Then I traced the extra rows to a retry: the load had timed out mid-write, Airflow retried it, and the load appended instead of overwriting the partition — 1.1 million duplicate rows. I changed the load to overwrite the day’s partition so a retry is idempotent, reran Sunday, reconciled the day’s counts to the source, and unpaused. *Result:* dashboards were correct by 11am, and nobody had used the inflated numbers. *Prevention:* a post-load check that the warehouse count matches the source within 0.1%, which fails the run instead of publishing it.
Put the post-mortem in the story. One line — “I wrote a blameless post-mortem and we added two checks” — shows you close incidents rather than just ending them.
At senior level the same story is expected to carry the systemic fix: making every load on the platform idempotent, not only this one.
The weak answer
“Airflow failed, I restarted it and it worked.” Restarting is not owning: no blast radius, no containment, no root cause, and nothing stops it happening next week. Worse is a story where you fixed the code while bad numbers kept reaching dashboards.
They’ll ask next
How did you know which downstream tables and reports had consumed the bad data, and how did you tell their owners?
Tell me about a time you had to dive deep into a complex data issue to identify the root cause.
What they are scoring
Dive Deep, one of the two principles data engineers report being pressed on hardest at Amazon. The interviewer is scoring whether you stopped at the symptom or followed the number down to the row, the join or the partition that caused it — and whether you can say how you knew.
A strong answer, in two sentences
Name the symptom and who saw it, then walk the chain of evidence to one specific cause and the check that proved it. End on the number that was wrong, the number after the fix, and the test that now catches it.
The reasoning
The story has to be a trail, not a conclusion. Say what looked wrong and to whom, what you ruled out first and why, the comparison that narrowed it down, and the moment you found the cause. Interviewers score the method — a reconciliation between source and target, a count by partition, a diff between two runs. “I looked into it and found a bug” is a borderline answer, because the digging is the part being assessed.
**A worked example, to replace with yours.** *Situation:* daily active users on the growth dashboard dropped 9% overnight, and the product VP asked whether a release had broken sign-in. *Task:* I owned the events pipeline, so proving or clearing it was mine. *Action:* I counted raw events per hour in the landing bucket against the modelled table. The raw side was flat, so nothing was lost upstream; the drop appeared at the join to the users dimension. A mobile SDK release had started sending user ids in upper case, and the join was an inner join, so every event from the new app version silently fell out. *Result:* I normalised the key, changed the join to keep unmatched rows against an “unknown user” member, and backfilled the affected days — 38 million events. DAU came back to within 0.2% of a count computed directly from raw events. *Lesson:* I added an alert on the share of events that fail to match a user, at 1%. It has since caught two more upstream changes before anyone saw a dashboard.
Two details lift this from solid to strong. Say what you were sceptical of — the dashboard and the anecdote disagreed, and you trusted neither until you had counted. And say what you changed so the whole class of bug is caught next time, not only this instance.
At two to four years the scope is a pipeline you owned. At senior level interviewers expect the same trail plus the conversation you had with the upstream team so it did not recur.
The weak answer
“There was a data issue, I investigated it with my team and we fixed it.” No symptom, no method, no cause, no number — and “we” hides which part was yours. The next three questions will be what you did, how you knew and what changed, and the answer should already have contained all three.
They’ll ask next
How did you know that was the root cause and not another symptom? What would you check first if it happened again tomorrow?
If a critical business metric drops by 20%, walk me through your investigation process.
What they are scoring
Reported from the first round of an Amazon BI Engineer loop. A hypothetical, but scored like a behavioral answer: the interviewer wants an order of operations — is the data wrong or is the business different — and evidence you have done it before.
A strong answer, in two sentences
First decide whether the drop is real or an artifact: freshness, completeness, a changed definition, a broken join. Only when the data checks out do you cut the drop by time, platform, region and cohort to find where it lives — and you tell the metric’s owner what you know at each step.
The reasoning
**Is the number wrong, or is the world different?** Sudden 20% moves are often the pipeline, not the business. So check in this order: did every partition land (freshness and row counts against the usual), did anything change in the metric’s definition or code this week, did an upstream schema or id format change, and does the metric still reconcile to the source system. Each check takes minutes and each rules out a whole class of cause.
**If the data is right, localise it.** Cut the metric by hour to see whether it was a step or a slide, then by platform, region, app version, channel and new versus returning users. A real drop usually lives in one segment — one app version, one country, one payment method. A drop spread evenly across every segment at the same instant is more often an instrumentation or pipeline change than a change in behaviour.
**Tell people early, and say what you do not know yet.** The metric’s owner hears within the hour that you are on it, whether the data has been ruled in or out, and when the next update comes. Then make it a story of your own: “our checkout conversion fell 18% overnight; the events table was complete, but the drop was entirely one Android release that had shipped a broken payment button. The data was right and the app was wrong, and the product lead had the answer in two hours.”
Close with what you would put in place so the next 20% is triaged in minutes: an anomaly alert on the metric, a reconciliation between the metric and its source, and a changelog of definition changes.
The weak answer
Jumping straight to business explanations — seasonality, a competitor, a marketing change — without first proving the data is complete and correct. A large share of these investigations end at a late partition or a broken join, and a candidate who never checks the pipeline would have presented a wrong story to leadership.
They’ll ask next
Everything in the pipeline checks out, and the drop is spread evenly across every segment. What now?
Tell me about a time when you faced a challenging situation at work and how you handled it.
What they are scoring
The most open prompt in the loop — reported from Walmart Global Tech’s director round, and a close cousin of Paytm’s “What challenges you face in your project”. What you choose to call “challenging” is scored as much as how you handled it, so pick something with real stakes and a decision in it.
A strong answer, in two sentences
Pick a story where the challenge was real — a failing migration, an outage at month-end, a deadline that could not move — and spend most of the answer on the decisions you made. Finish with the result as a number and what you would do differently.
The reasoning
The choice of story is itself scored. A challenge that was only hard work (“we had a lot of tickets”) says little. A challenge with a decision in it says a lot: two bad options and you picked one, a risk you took, a person you had to persuade. For a data engineer the strong ones are a production failure at a bad moment, a migration that went wrong halfway, or data that could not be trusted on the day it was needed.
**A worked example, to replace with yours.** *Situation:* three days before the quarter closed, the finance reconciliation job started failing because the ERP vendor had changed an export format. *Task:* I owned the ingestion, and finance needed the numbers by Thursday. *Action:* I split the problem. A quick parser change got the new format loading, and I validated it against 1,200 invoices finance had already reconciled by hand; the proper fix — a schema contract with the vendor — went into a separate ticket. On day one I told the controller what was broken, what the workaround was and when she would have numbers. *Result:* the close finished on time with zero reconciliation breaks, and when the vendor changed the format again, the contract check failed the load on the first file instead of loading bad rows. *Lesson:* I now ask every vendor for a sample file before their release dates.
Keep the challenge to one sentence and give the handling most of the time. Interviewers follow up on the points where you chose — why the quick fix first, why that validation set, what you told the stakeholder — so make those choices visible.
The weak answer
A story about general busyness or a hard technology (“learning Spark was challenging”) with no decision in it. Or a challenge caused by someone else, told mostly by blaming them. Both leave the interviewer nothing to score.
They’ll ask next
What was the hardest decision in that, and what would have happened if you had chosen the other way?
Tell me about a time you had to make an urgent decision without data. What was the impact and would you do anything differently?
What they are scoring
Bias for Action: speed matters, and many decisions are reversible. The interviewer scores whether you can tell a reversible decision from an irreversible one, act on the first quickly, and say honestly what you would change.
A strong answer, in two sentences
Tell a story where waiting was the costly option, and say why the decision was reversible or how you made it so. Give the outcome with a number, then answer the second half properly: one specific thing you would do differently.
The reasoning
The interviewer is not looking for recklessness. They are listening for the reasoning that made acting fast safe: the decision could be undone, the cost of waiting was known, and you put a check in place to find out quickly if you were wrong.
**A worked example, to replace with yours.** *Situation:* at 11pm a vendor feed started delivering duplicate orders into our warehouse, and the morning revenue report went to the leadership team at 7am. *Task:* I was on call, and there was no time to find the root cause first. *Action:* I paused the load and let the report run on the previous day’s validated snapshot, with a banner saying the latest day was delayed. That was fully reversible — resuming the load was one command — where publishing duplicated revenue was not. *Result:* leadership saw correct numbers one day behind instead of revenue inflated by about 14%. The feed was fixed by 10am and the day backfilled by noon. *Differently:* I would have had the pause-and-banner step in the runbook already. I invented it at 11pm, and it took forty minutes a runbook would have saved.
The second half of the question is where most candidates lose marks. “Nothing, it went well” reads as a lack of reflection. Name one specific change and why.
The weak answer
“I trusted my gut and it worked out.” That is luck, not judgement. The interviewer wants the reasoning that made acting without full data safe — reversibility and a known cost of delay — and a real answer to “what would you do differently”.
They’ll ask next
How did you know the decision was reversible at the time, rather than in hindsight?
Reported · 1OwnershipBias for actionProduction incidents
Tell me about a time you moved fast and broke something.
What they are scoring
Reported by DoorDash data engineering candidates, where it is filed under ownership of a problem. It tests two things at once: that you do move fast, and that when speed costs something you own the damage completely and change how you ship.
A strong answer, in two sentences
Pick a real case where speed was the right instinct but you skipped a check, own what broke and who it hit, and describe the fix and how you told people. End on the guard-rail that keeps the speed but catches the break.
The reasoning
This is not a failure question in disguise; it is a judgement question. The best answers show the speed was worth it, the break was contained quickly, and the lesson was a guard-rail rather than “I slowed down”.
**A worked example, to replace with yours.** *Situation:* a product launch needed a new column in the events table by Friday, and I added it on Thursday evening, right after customer_id in the model’s SELECT, and rebuilt the table. *What broke:* a downstream export to the marketing platform selected columns by position, not by name, so the new column shifted every field one place to the right — 200,000 customer records sent with emails in the name field. *Action:* I disabled the export within 20 minutes of the marketing lead’s message, worked with her to delete the bad batch from the platform, changed the export to select by name, and re-sent. I wrote up what had happened the same day. *Result:* no customer email went out from the bad batch, and the launch still shipped on Friday. *Guard-rail:* schema changes to that table now run a contract check against its registered consumers in CI, which takes 40 seconds.
Say who was affected and how you told them. Owning the break is the Ownership signal; the guard-rail is the Insist on the Highest Standards signal.
The weak answer
A story that argues nothing really broke, or one that ends “so now I always double-check everything”. The first dodges ownership; the second is a promise, not a mechanism.
They’ll ask next
Would you make the same trade-off again, knowing what broke?
Tell me about a time when you went over and above your job responsibility in order to help the company.
What they are scoring
Ownership — the other principle data engineers report being probed on hardest. “Leaders are owners”: they act on behalf of the whole company, not just their team. The interviewer scores whether you saw a problem that was not yours, chose to fix it, and did it without dropping your own work.
A strong answer, in two sentences
Tell a story where the problem sat outside your remit, nobody owned it, and you took it on because of what it cost the business. Show that you told the right people, kept your own commitments, and left something durable behind.
The reasoning
The best version is one where the gap was visible to many people and nobody acted. For a data engineer that is often an orphaned pipeline, a table everyone reads that no one maintains, a flaky feed another team owns, or an on-call runbook that does not exist.
**A worked example, to replace with yours.** *Situation:* a shared customer table, fed by a job the previous platform team had built and nobody now owned, failed silently about once a week, and four analytics teams each patched their own reports around it. *Task:* not mine — I was on the payments pipeline. *Action:* I spent two afternoons tracing it to two jobs racing to write the same partition. I took the cost of the weekly failures to my manager — roughly six analyst-hours each time — ran the two jobs in sequence instead of in parallel, made the write atomic, added a freshness alert and wrote the table’s first runbook. Then I got the platform team to take ownership formally, runbook included. *Result:* no silent failures in the next two quarters, and the four teams deleted their workarounds. *Lesson:* fixing it was half the job; handing it to a real owner was the other half.
Two traps. Do not tell a story that is really about working late — hours are not ownership. And do not tell one where you quietly took over another team’s system without telling them; that is a trust problem, not initiative.
The weak answer
“I often stay late to help my team meet deadlines.” That is effort, not ownership, and it is inside your job. The interviewer wants a problem outside your remit, a decision to act, and a fix that lasted.
They’ll ask next
What did you stop doing, or push back on, to make time for it?
Tell me about a time you followed a customer-centric approach, even when it meant extra work or pushback from your team.
What they are scoring
Asked by the Bar Raiser in a first-hand Amazon BI Engineer loop. Customer Obsession for a data engineer means the people who use your data. The interviewer scores whether you worked backwards from what that person needed, and held the line when it cost you or your team something.
A strong answer, in two sentences
Name your customer concretely — the finance analyst, the support team, the model in production — and what they actually needed against what was asked or easiest. Show what it cost to do it their way, how you handled the pushback, and the measurable difference it made to them.
The reasoning
For a data engineer “the customer” is rarely the end user of the product. It is whoever reads your tables and makes a decision from them. A strong story makes that person specific and shows you learned what they really needed — usually by watching them use the data rather than by reading the ticket.
**A worked example, to replace with yours.** *Situation:* the support team asked for a daily export of open tickets. *Task:* the ticket was small, and my team wanted to ship it in a day. *Action:* I sat with two support leads for an hour and found they used the export to spot customers with three or more tickets in a week — by hand, in a spreadsheet, a morning’s work each day. In planning I argued for building that view directly. It would take four days instead of one, and my lead pushed back because it slipped another item, so I offered to ship the plain export on day one as well; support was not left waiting while we built the real thing. *Result:* the repeat-contact view replaced about 15 hours of manual work a week, and support’s escalation time went from two days to same-day. *Lesson:* a ticket describes a solution; ask for the decision it feeds.
Handle the pushback honestly. The interviewer is also scoring how you disagreed with your own team — with evidence and an offer, not by going around them.
The weak answer
“I always put the customer first,” followed by a story where you did exactly what the ticket said. Or one where you went around your team to deliver it. The first has no customer insight in it; the second trades Customer Obsession for a trust problem.
They’ll ask next
How did you find out what they really needed, and what did your team say when it took four times longer?
Tell me about a time when you made a decision which impacted the team or the company.
What they are scoring
IGotAnOffer’s Bar Raiser list files it under Success and Scale Bring Broad Responsibility. The interviewer scores whether you saw the second-order effects of a technical decision on people outside your own task, weighed them, and owned the outcome.
A strong answer, in two sentences
Choose a decision whose effects reached beyond you — a standard, a tool, a data model, a deprecation — and show you worked out who else it touched before you made it. Give the outcome for them, with a number, including anything that went wrong.
The reasoning
Scope matters here. At two to four years, a decision that changed how your team worked is right: adopting a testing framework, changing a table’s grain, retiring a job. The strength is in showing you asked who depended on it before acting.
**A worked example, to replace with yours.** *Situation:* our orders table was rebuilt every night by a full overwrite that took three hours and blocked every downstream job. *Task:* I proposed moving it to an incremental merge. *Action:* before changing anything I pulled the warehouse query logs and found eleven downstream consumers, two of which relied on deleted orders disappearing — something a merge would not do. I captured deletes from the source’s change log as a soft-delete flag, added a view that hid them to preserve the old behaviour, told each owner in advance with a date, and ran both versions side by side for a week comparing counts. *Result:* the nightly build went from three hours to 25 minutes, downstream jobs started two hours earlier, and no consumer broke. *Lesson:* the query log is the real list of stakeholders, not the wiki.
If the decision had a cost for someone, say so. Owning a trade-off honestly scores higher than claiming a decision was free.
The weak answer
A decision that affected only your own task (“I chose pandas over Spark for my script”), or a big decision told with no sign you considered who it touched. The principle is about responsibility for consequences, so the consequences have to be in the story.
They’ll ask next
Who was affected that you did not anticipate, and how did you find out?
One of the most widely reported openers — crowdsourced from Amazon, Uber, Stripe and LinkedIn data engineering loops, and asked at Amazon as “A project you are proud of — why?”. It is often the first story, so it anchors the loop: the interviewer scores its scope, your personal part in it, and whether you can say why it mattered.
A strong answer, in two sentences
Pick the project with the biggest real outcome that was substantially yours, say in one line why it mattered to the business, and spend the time on the hardest decision you made in it. Close with the before-and-after numbers and why you are proud of it specifically.
The reasoning
This question is really “show me your ceiling”. Choose a project where your part was large and clearly yours, the problem was hard, and the result can be counted. The “why” in Amazon’s phrasing matters: proud because of the outcome, because of something you learned, or because of a call others disagreed with that turned out right — say which.
**A worked example, to replace with yours.** *Situation:* marketing attribution ran as a 2,000-line SQL script on one warehouse node. It took nine hours and failed about twice a month, so the growth team often worked from two-day-old data. *Task:* I proposed and led the rebuild. *Action:* I broke it into eight dbt models with tests at each boundary, moved the heaviest join to an incremental model keyed on event date, and ran old and new in parallel for three weeks, explaining every difference to the cent before switching over. *Result:* runtime went from nine hours to 40 minutes, with no failed runs the following quarter, and the growth team moved from weekly to daily budget changes. *Why proud:* the parallel run caught two bugs in the old script that had been misattributing about 3% of spend for a year.
Expect a deep dive afterwards. Interviewers use this story as the base for questions on design, trade-offs and what went wrong, so choose one you know inside out.
The weak answer
A project chosen because it used impressive technology, told as a tour of the stack (“we used Kafka, Spark and Airflow”) with no problem, no personal decision and no outcome. Or a team project where you cannot separate your part from everyone else’s.
They’ll ask next
What would you design differently if you started it again today?
Can you share an example of a project you worked on that had a significant impact on your organisation?
What they are scoring
Reported from Walmart Global Tech’s techno-managerial round for a data engineer, and asked at Amazon as “your most impactful work at your previous organization”. Where “most proud” invites the story you love, this one is scored on impact alone: a business number, and your part in moving it.
A strong answer, in two sentences
Lead with the impact in the organisation’s terms — money, time, risk, customers — then the problem and what you personally did. If the impact was indirect, make the chain explicit: faster data led to which decision, which changed which number.
The reasoning
Data work is usually one step removed from revenue, so the strongest answers draw the line out loud. “The pipeline got faster” is not impact. “The pipeline got faster, so fraud rules ran every fifteen minutes instead of daily, so chargebacks fell 22%” is.
**A worked example, to replace with yours.** *Situation:* the risk team scored merchants for fraud once a day from a batch extract, and most fraud happened within hours of onboarding. *Task:* I built the data side of moving scoring to near real time. *Action:* I replaced the daily extract with change-data-capture from the merchants database into a streaming table, made the feature job idempotent so replays were safe, and worked with the risk analysts to prove the new features matched the daily ones over a four-week parallel run. *Result:* scoring latency went from 24 hours to 15 minutes, and the risk team reported chargeback losses from new merchants down 22% the next quarter. *Lesson:* I asked risk for the loss number before starting, which is the only reason I can quote it.
If you do not know the business number, say how you would have found it and what the proxy was. An invented figure is worse than an honest proxy, because interviewers probe numbers.
The weak answer
“It had a big impact on the whole organisation,” with no number and no chain from your work to the outcome. The follow-up the Walmart candidate reported — the specific strategy you implemented and its results — exists because this is the usual first answer.
They’ll ask next
How do you know the improvement came from your change and not from something else that shipped that quarter?
Tell me about a time when you improved a complex process.
What they are scoring
Crowdsourced from Amazon data engineering loops, and asked by Bar Raisers as “a time you re-designed a process and why”. It probes Invent and Simplify: the interviewer scores whether you understood why the process was complex before simplifying it, and whether the new one was genuinely simpler rather than just newer.
A strong answer, in two sentences
Describe the process as it was and what its complexity cost, then the one idea that made it simpler, and how you proved the new version was still correct. Give the before and after in time, failures or effort.
The reasoning
The trap is describing a rewrite. Replacing a tool with a newer one is not simplification unless something was removed. Strong answers name what disappeared — steps, handoffs, manual checks, special cases — and why it was safe to remove it.
**A worked example, to replace with yours.** *Situation:* onboarding a new data source took about three weeks — a ticket, a hand-written ingestion job, a hand-written schema and a manual review — repeated for each of 40 sources. *Task:* I proposed standardising it. *Action:* I found that 34 of the 40 sources were one of three shapes: a database table, a daily file drop, or a REST endpoint. I built one config-driven ingestion job per shape, with schema inference and a validation step, and deliberately left the other six hand-written. *Result:* a new source of a known shape now takes one config file and about two days end to end, and ingestion pages to on-call fell by about half, because three shared, well-tested jobs now covered 34 of the sources. *Lesson:* leaving the six odd ones alone is what made the other 34 simple.
Say how you checked the new process was correct before switching — a parallel run, a reconciliation, a pilot with one team. Simpler and wrong is not an improvement.
The weak answer
“I migrated our pipelines from cron to Airflow, which is much better.” That is a tool swap, not a simplification: it names no cost of the old process, no removed step and no measured improvement.
How did you contribute to cost optimisation initiatives while working with cloud technologies?
What they are scoring
Reported word for word from Walmart Global Tech’s techno-managerial round, followed by a request for one specific strategy and its results. Cloud spend is a data team’s biggest controllable cost, so this is Frugality with a number attached: one change, the mechanism, and the saving.
A strong answer, in two sentences
Give one specific change, not a list: where the money was going, how you found it, what you changed, and the monthly saving. Mention anything you traded away — latency, retention, convenience — and how you checked it was acceptable.
The reasoning
Start with how you found the cost, because that is the Dive Deep part: the billing export broken down by job, table or tag; the query history sorted by bytes scanned; the cluster utilisation graph. Candidates who say “we optimised costs” without saying where the money was going get the follow-up immediately.
**A worked example, to replace with yours.** *Situation:* our warehouse bill had grown 40% in two quarters. *Task:* I volunteered to find out why. *Action:* grouping the query history by table and user showed 60% of the bytes scanned came from three dashboards querying an unpartitioned events table for the last seven days. I partitioned the table by event date and clustered it by customer id, pointed the dashboards at a daily aggregate about 200 times smaller, and set a 90-day retention on raw events, with older data moved to cheaper object storage. *Result:* monthly warehouse spend fell by about $18,000 — roughly 35% — and the dashboards loaded in two seconds instead of forty. *Trade-off:* raw events older than 90 days now need a separate query, which I agreed in advance with the two teams that ever used them.
Levers worth having a story about: partition pruning and clustering, pre-aggregation, right-sizing or auto-scaling clusters, spot capacity for retryable batch work, storage tiering and retention — and switching off jobs nobody reads.
The weak answer
A list of generic techniques (“we used spot instances, auto-scaling and caching”) with no specific change, no finding and no number. The reported follow-up exists because this is what candidates usually say first.
They’ll ask next
Could you describe a specific cost optimisation strategy you implemented in the cloud and its results?
Tell me about a time when you had to deliver something with very limited resources or tight constraints.
What they are scoring
A standard Bar Raiser prompt at Amazon, close to Frugality: constraints breed resourcefulness. The interviewer scores what you cut, what you refused to cut, and whether the result was still correct.
A strong answer, in two sentences
Name the constraint precisely — people, money, time, access — and the choice it forced. The strong part is what you decided not to compromise, usually correctness, and how you delivered everything else with less.
The reasoning
Resourcefulness is what is scored: reusing what existed, narrowing scope to the part that mattered, or finding a cheaper route to the same outcome. Make the prioritisation explicit — you had this, needed that, and chose this because.
**A worked example, to replace with yours.** *Situation:* a regulator asked for twelve months of transaction history in a set format within ten working days, and our platform team was frozen on a migration. *Task:* I was the only engineer free. *Action:* rather than building a pipeline, I wrote the extract as three SQL views over tables we already had and used the existing export tool to write the files. I spent the time that saved on a reconciliation: totals by month against the ledger, and a sample of 500 transactions checked by the compliance analyst. *Result:* delivered in seven days, matching the ledger to the cent, at no extra cost. *What I refused to cut:* the reconciliation. A late submission would have been bad; a wrong one would have been worse.
End on the lesson — often that the constrained version was good enough to keep, or which corner you would never cut again.
The weak answer
“We were understaffed, so we all worked weekends and got it done.” That is endurance, not resourcefulness. It says nothing about what you chose to cut or to protect.
They’ll ask next
What did you deliberately leave out, and did anyone push back?
One of the most widely tagged behavioral questions in candidate submissions for data engineers — Amazon, Capital One, LinkedIn and Airbnb — and asked at Amazon as “A decision that caused failure — what did you learn?”. Scored on Earn Trust: a real mistake that was yours, owned without excuses, and a change that proves you learned.
A strong answer, in two sentences
Pick a real mistake with real consequences that was clearly yours, own it in the first sentence, and spend most of the answer on how you fixed it and who you told. Finish with the specific habit or check you added so it cannot happen the same way again.
The reasoning
The mistake has to be real and yours. A fake one (“I work too hard”) or someone else’s (“the requirements were wrong”) fails the question outright. The consequence should be concrete — wrong numbers, a failed job, a delay — and not so catastrophic that it raises doubts about your judgement.
**A worked example, to replace with yours.** *Situation:* I shipped a change to our subscriptions model that switched a join from the plan table to a new plan-history table. *The mistake:* I tested it on one sample month and never checked row counts across the full history. Subscriptions that had changed plan mid-month now joined twice, and monthly recurring revenue on the finance dashboard was overstated by 6% for four days before an analyst questioned it. *Action:* I rolled the change back within the hour, told the finance lead and my manager directly what had happened and which days were wrong, re-ran those days, and sent a note listing every report that had used them. *Result:* corrected within a day, before anyone had made a decision on the bad number. *Lesson:* I added a test that the model’s row count equals the number of active subscriptions, and I now diff the full history, not a sample, for any change to a join.
Notice the order: consequence contained, stakeholders told, then root cause, then prevention. Telling people before they found out for themselves is the Earn Trust part — do not skip it.
The weak answer
A humblebrag (“I cared too much about quality”), a mistake that was really a teammate’s, or a story that spends its time explaining why it was not your fault. The question scores ownership and learning, and each of these avoids both.
They’ll ask next
How did you tell your stakeholders, and what did you change so it cannot happen the same way again?
Tell me about the time when your idea did not work.
What they are scoring
Reported from Expedia Group’s HR and managerial round for a data engineer. Different from “a mistake”: here you proposed something, others backed it, and it failed anyway. The interviewer scores how you noticed, how quickly you called it, and what you salvaged.
A strong answer, in two sentences
Describe an idea you championed, the evidence that made it look good, and the signal that told you it was not working. Show you called it early, said so openly, and kept what was useful.
The reasoning
This question rewards people who experiment — an idea that did not work is evidence you propose ideas. The weakness is in how long you defended it after the evidence turned, so the moment you decided to stop is the centre of the story.
**A worked example, to replace with yours.** *Situation:* our nightly batch missed its 6am SLA about once a week. *The idea:* I proposed moving the heaviest transformation to a streaming job so it would finish continuously rather than overnight, and my lead agreed a four-week trial. *What happened:* by week two the streaming job was cheaper per record, but late-arriving updates meant we had to reprocess windows anyway, and the operational load — restarts, checkpoint problems — fell on one person. *Action:* I wrote up the numbers at the two-week review and recommended stopping. We kept one piece, an incremental read of the source that cut the batch’s input by 70%, and reverted the rest. *Result:* the batch then met its SLA every day for the next quarter, and the trial cost two weeks rather than a half-built system. *Lesson:* I now set the stop criteria before a trial starts.
Show honesty without drama: it was disappointing, you said so, and you moved on to what the evidence supported.
The weak answer
An idea that “didn’t work because the team didn’t support it” — which is blame — or one that secretly succeeded in the end. Both dodge the question, which is about your judgement when your own idea failed.
They’ll ask next
What would have had to be true for your idea to work, and could you have known that at the start?
Tell me about a project that you wish you had done better and how you would do it differently today.
What they are scoring
Insist on the Highest Standards, reported from Bar Raiser rounds and in Amazon data engineering prep. The interviewer scores whether your standards have risen since: can you look at your own shipped work and see specifically what is wrong with it.
A strong answer, in two sentences
Pick shipped work that met the bar at the time but not your bar now, say exactly what you would change and why, and connect it to what you have learned since. Specific design and process changes score; “I would communicate more” does not.
The reasoning
The shape is: what you built, what it cost later, and the concrete redesign. The cost-later part is what makes it credible — a table that became a bottleneck, a pipeline that could not be backfilled, a model that could not answer the second question the business asked.
**A worked example, to replace with yours.** *The project:* in my first year I built the product-usage pipeline as a nightly full rebuild of one wide table. *What it cost later:* within a year it took four hours, could not be rerun for a single day without rebuilding everything, and every new metric became another column that three teams defined differently. *What I would do today:* declare the grain up front — one row per user per day — build it incrementally by date partition so one day can be rerun safely, and keep metric definitions in a semantic layer rather than as columns. *Result, when I got to rebuild it:* runtime fell to 20 minutes and a one-day backfill became a single command.
Keep it honest but not self-punishing. The point is that you can critique your own work at the level of design, which is what the principle asks for.
The weak answer
“I would have started testing earlier and communicated more.” True of every project and specific to none. The interviewer wants the design or process decision you would change, and why.
Tell me a piece of difficult feedback you received and how you handled it.
What they are scoring
IGotAnOffer and Exponent file it under Earn Trust — Amazon’s leaders are “vocally self-critical”. The interviewer scores whether you can hear criticism without defending yourself, whether you acted on it, and whether anyone could see the change.
A strong answer, in two sentences
Choose feedback that stung and was fair, say honestly how you reacted in the moment, and then describe what you changed and the evidence it stuck. The best answers end with the person who gave the feedback noticing.
The reasoning
Pick feedback about how you work, not about a typo. For data engineers the common, credible ones are: your pull requests are too big to review, you go quiet when blocked, you over-engineer, your documentation leaves on-call guessing, or you say yes to every stakeholder.
**A worked example, to replace with yours.** *The feedback:* in a review my manager told me that two engineers found my pull requests impossible to review — often over a thousand lines — so they approved them without really reading, which was how a bug had reached production the month before. *My reaction:* my first instinct was that the changes were simply large; I said I would think about it rather than argue. *Action:* I split my next feature into five pull requests of under 300 lines each, each shippable behind a flag, and asked the same two reviewers whether it helped. *Result:* reviews of my changes went from days to hours, reviewers started leaving real comments again, and my next review noted it. *Lesson:* a review that is too big to read is not a review.
Admit the defensive first reaction if you had one. Claiming you welcomed it instantly sounds rehearsed; showing you got past it sounds real.
The weak answer
Feedback that is really a compliment (“I was told I take on too much”), or a story that ends at hearing the feedback, with no change and no evidence. Worst of all is explaining why the feedback was wrong.
They’ll ask next
Was there feedback you disagreed with? What did you do with that?
Crowdsourced from Amazon data engineering loops, and asked in Cognizant’s interview for its data engineering track as “What is the latest technology you learned?”. It probes Learn and Be Curious: the interviewer scores why you learned it, how, and whether it changed your work.
A strong answer, in two sentences
Name one skill, the reason you needed it, how you actually learned it, and something you built or fixed with it. A skill with a use and a result beats a certificate.
The reasoning
The reason matters more than the skill. “I learned dbt because it was trending” is weak; “I learned dbt because our SQL had no tests and I kept being paged for the same broken join” is strong, because it shows curiosity attached to a real problem.
**A worked example, to replace with yours.** *The skill:* reading Spark query plans. *Why:* a nightly job had slowed from 20 minutes to two hours, and my usual fix — more executors — had stopped helping. *How:* I read the physical plan in the Spark UI line by line against the documentation, reproduced the job on a sample, and compared plans before and after each change. *What it found:* two problems in two joins. A dimension join ran as a sort-merge join although the dimension was small enough to broadcast, and a join between two large tables had a skewed key sending 40% of rows to a single task. A broadcast hint on the first and salting the key on the second brought the job back to 18 minutes. *Since:* I read the plan before touching any configuration, and I ran a short session on it for my team.
Be ready for the depth probe. Whatever skill you name, the next question will test it.
The weak answer
A list of courses and certificates with no problem that needed the skill and no use of it. Or a skill you cannot then discuss in depth when the interviewer follows up.
They’ll ask next
How would you learn a technology you know nothing about, for a project starting next month?
Reported from Expedia Group’s managerial round and from an Amazon data engineer loop as “How would you learn anything new?”. Data stacks change every few years, so the interviewer scores whether you have a repeatable way of learning — and proof you have used it — not whether you already know their tools.
A strong answer, in two sentences
Describe your method briefly — the concepts and a small real build first, then the failure modes — and prove it with one time you used it against a deadline. Show how you checked your understanding rather than only reading.
The reasoning
This is half behavioral and half approach, so answer with a method and then an example. A credible method for data tools: read the concepts and the architecture, build the smallest end-to-end thing on real data, then deliberately break it — kill a job halfway, send a bad record, rerun a day — because the failure modes are what production will test.
**A worked example, to replace with yours.** *Situation:* my team adopted Apache Iceberg for a new lakehouse table with a three-week deadline, and none of us had used it. *Action:* I read the spec’s sections on snapshots and schema evolution, built a copy of one production table on a week of data, and tested the operations we would actually run: a late-arriving update, a new column, a rollback to an earlier snapshot, and compaction. I wrote a two-page note on what surprised me — mainly that small files piled up quickly without scheduled compaction. *Result:* we shipped on time, and the compaction job that came out of the test is why the table stayed fast at two billion rows.
Close by applying it to their stack. If they use a tool you do not know, say how you would be productive in it within the first month.
The weak answer
“I watch tutorials and take online courses.” That describes consumption, not learning, and gives no evidence it has ever worked against a real deadline.
They’ll ask next
How would you learn a language you know nothing about, starting today?
Tell me about yourself and your current role and responsibilities.
What they are scoring
The most reported question in the set — the opener of almost every HR, managerial and hiring-manager round, sometimes with a limit (“within 30 seconds” at Tiger Analytics). It is scored on relevance and structure: can you frame your experience around the job in front of you.
A strong answer, in two sentences
Present, past, future, in about a minute: what you do now and at what scale, the one or two things you have done that matter most for this role, and why this role is the next step. End on something they will want to ask about.
The reasoning
**Present.** Your role, your team and what you own, in data terms: “I’m a data engineer on the payments team at a fintech. I own the pipelines that feed finance and risk — about 400 million events a day into Snowflake, orchestrated in Airflow.” One sentence of scale is worth a paragraph of adjectives.
**Past.** Two highlights that match this job’s description, each with a number: a migration you led, a cost you cut, an SLA you fixed. Not your whole CV — the interviewer already has it.
**Future.** Why this role, in one sentence that connects to what they do: “I want to work on streaming at a larger scale, which is most of what this team does.” Then stop. A minute to ninety seconds is right; under pressure people talk for five.
Prepare a 30-second version too. Some HR rounds ask for it explicitly, and it doubles as your answer when a technical interviewer says “quickly introduce yourself”.
The weak answer
A chronological walk through your CV from college onwards, or a personal biography, running four minutes with no numbers and no link to the role. The interviewer stops listening before you reach the part that matters.
They’ll ask next
Tell me something which is not written in your resume.
Tell me something which is not written in the resume.
What they are scoring
Reported word for word from Paytm’s technical-plus-managerial round for a data engineer with two years’ experience. It tests whether there is a person and a motivation behind the CV — and whether you can pick something that still says something about how you work.
A strong answer, in two sentences
Choose one true thing that reveals how you work — something you built for yourself, taught, fixed or taught yourself — and tie it back to the role in a sentence. Keep it short and specific.
The reasoning
The best answers are side projects, teaching, or a small story about how you operate that did not fit the CV’s format: the internal tool you built that three teams now use, the data-quality checklist your team adopted, the open-source fix you contributed, the sessions you run for new joiners.
**For example:** “Something that isn’t on my CV: I wrote our team’s on-call runbook. In my first month on call I kept a list of every alert I got and what fixed it, and it grew into a 20-page document the next three joiners used. It’s why I care about alerts that tell you what to do.” It is true, it is specific, and it tells the interviewer something useful.
A hobby is fine if it says something — training for a long race shows persistence — but keep it to one sentence and bring it back to work.
The weak answer
“Not much, it’s all on the CV,” or a list of hobbies with no link to anything. Both waste an open invitation to show what makes you different.
They’ll ask next
Why did you start doing that, and what did it change for your team?
Why should we hire you for this data engineering role?
What they are scoring
Reported word for word from the HR rounds of Walmart Global Tech and Morgan Stanley data engineering loops. A closing question, scored on fit: can you name the two or three things this team needs and show you have already done them.
A strong answer, in two sentences
Match their needs to your evidence: two or three things the role requires, each with one line of proof from your own work. Finish with what you would take on first.
The reasoning
Use the job description and the earlier rounds to work out what they need — say, someone who can own ingestion end to end, work with finance, and cut cloud cost. Then answer each with evidence, not adjectives: “You need someone who can own pipelines end to end. I’ve owned our payments ingestion for two years, on-call included, and cut its failure rate by 80%.”
**A strong closing line** ties it to their situation: “From the design round, it sounds like freshness on the orders pipeline is your biggest gap. That’s the exact problem I solved last year, and it’s where I’d start.” It shows you listened during the loop.
Keep it under a minute, and do not compare yourself with candidates you have never met. Confidence comes from specifics, not superlatives.
The weak answer
“Because I’m hard-working, passionate and a quick learner.” Every candidate says it, none of it is evidence, and it ignores what this team actually needs.
