DataLane
← All cheat sheets

Behavioral Interview for Data Engineers cheat sheet

STAR answers for pipeline failures, cost incidents, stakeholder conflict, and the ownership stories data interviews actually probe.

Interview PrepBeginner5 sections

Failures and incidents

Tell me about a pipeline failure you caused.
Pick one you actually caused, not one you inherited. Situation: a MERGE without a source dedup loaded duplicate keys into a gold fact. Task: restore correct totals before the 9 a.m. exec dashboard. Action: stopped the DAG, cloned the table as of the last good Time Travel timestamp, added QUALIFY ROW_NUMBER, and a unique test. Result: dashboard recovered in 40 minutes, and the test has blocked two similar PRs since. The interviewer is listening for blame versus ownership.
Describe a time data was wrong and nobody noticed.
A fan-out join silently doubled revenue for eleven days. Situation and impact first — dollars, not row counts. Action: compared grain before and after the join, added a uniqueness test on the join key, backfilled, and told finance before they found it. Result: a reconciliation process, not just a code fix. Hiding the duration is the weak version of this answer.
A job has been failing for three nights and you are on call. Walk me through it.
Triage first: is it a data issue, a platform issue, or a code issue. Check the last successful run, the failing task log, and whether upstream landed. Communicate a status in the first fifteen minutes even if you have no fix. Rollback or skip with a documented gap if the SLA is already missed. Then a written postmortem with one prevention item, not ten.
Tell me about a time you had to rebuild history.
Logic bug in an incremental model meant six months of late-arriving rows never loaded. Action: ran a bounded backfill behind a clone, compared row counts and revenue, then swapped. Result: numbers moved and you told the stakeholders before they saw the chart jump. The point is that rebuilds are product events, not just engineering chores.
What is an incident you would handle differently now?
Be specific. I once restarted a failing load three times without checking whether it was idempotent, and created duplicates. Now I read the write path before I retry, and I would rather miss a freshness SLA than double-count. Interviewers prefer this over a story where you were already perfect.

Cost and tradeoffs

Tell me about a time you cut a warehouse bill.
Start with the number. We were spending 40k credits a month; one dashboard scanned an unclustered 12 TB table every refresh. Action: added a partition filter, converted the extract to a daily mart, and put a resource monitor on the BI warehouse. Result: that dashboard dropped 85 percent of its scan, monthly credits fell by about 30 percent, and nobody's query got slower. Cost stories without a number are forgettable.
Describe a time you chose the simpler, slower design on purpose.
A stakeholder wanted streaming for a report they checked once a day. I pushed a 15-minute micro-batch instead, documented the freshness contract, and saved a Flink job nobody was staffed to operate. The follow-up is whether you can also describe a time you correctly chose the harder path.
A VP wants real-time everything. What do you say?
Ask what decision changes if the number is two minutes old versus two hours old. Most 'real-time' requests are 'before standup'. Offer a freshness SLO they can live with, cost it, and only then design. Saying no without an alternative is the weak answer; saying yes to every latency request is the other weak answer.
Tell me about a tool you recommended against.
We evaluated a second orchestrator because a vendor pitch was exciting. I wrote a one-pager on what our current Airflow already did, the migration cost, and the two actual gaps. We stayed, and we spent the quarter on data quality instead. Interviewers want judgment, not tool enthusiasm.

Collaboration

Tell me about a disagreement with an analyst or analytics engineer.
A metric definition forked across three dbt models. I did not 'win' — I scheduled a 30-minute session, wrote the definition in one place, and deprecated the other two with a deprecation window. Result: one number, and the analyst still owned the definition. Framing the other person as the problem is the fail.
How do you say no to a stakeholder who wants a pipeline tomorrow?
Repeat the request in your own words, name the risk (untested grain, no late-arriving-data handling), and offer a thinner slice that can ship safely: a one-off extract this week, a proper model next. A naked no sounds unhelpful; a silent yes that ships bad data is worse.
Describe mentoring or raising the quality bar on a team.
I added a PR checklist: grain in the description, unique and not_null on the key, and no source refs outside staging. I reviewed the first dozen PRs myself so it was coaching, not a gate. Result: test coverage went from optional to default. Avoid stories that are only 'I wrote a style guide nobody used'.
Tell me about working with a software engineering team on an upstream schema change.
They wanted to rename a column in a week. I asked for a dual-write period, a data contract test in CI, and a date. We added the new column, migrated consumers, then dropped the old one. The story is about treating producers as partners and making the change reversible, not about blocking them.

Ownership and ambiguity

Tell me about a project with an unclear owner.
A CDC pipeline sat between platform and analytics with no on-call. I wrote a one-page RACI, volunteered the first rotation, and put the runbook in the repo. Result: the next slot lag incident paged a named person instead of a Slack channel. Interviewers hire people who close ownership gaps.
How do you prioritize when everything is on fire?
User-facing incorrect data first, then missed SLAs, then cost, then cleanup. I write the list down and show it to whoever is asking for the fourth thing. Priority without a shared list is just whoever pinged last.
Describe a time you were wrong in public.
I argued a table did not need clustering, then the profile showed 90 percent of partitions scanned. I posted the correction, added the key, and updated the runbook. The point is speed of update, not never being wrong.
Why this company and this data team?
Name a real data problem they have that you have already solved a version of — not 'I love data' and not a recitation of their blog. Two sentences on the domain, one on the stack, one on what you want to learn. Generic enthusiasm is the most common weak close.

STAR hygiene

How long should a behavioral answer be?
About 90 seconds. Situation in two sentences, action as the bulk, result as a number or a change in process. If the interviewer has not asked a follow-up, you went too long or too vague.
What do you do if you do not have a story that matches the question?
Say so, then offer the closest real one. Invented stories fall apart on follow-up. 'I have not owned a 50-person migration; here is a 4-person one and what I would do differently at that scale' is a strong answer.
What follow-up should you expect after any incident story?
'What did you change so it cannot happen again?' If your story ends at the fix, you are not done. Tests, alerts, runbooks, or a design change — pick one concrete prevention.
What is a red flag in your own answers you should edit out?
We, they, and the team as the actor in every sentence. Use I for what you did, we for what the group decided. Also edit out contempt for stakeholders, tools, or previous employers. The interviewer is deciding whether they want you in a Slack thread at 2 a.m.

From DataLane — tutorials at/blog, practice SQL live in theplayground.

↑↓ navigate openesc close