Senior Data Engineer Interview Questions cheat sheet
Judgment, ownership, and system design for senior loops — the questions that test whether you can be the person other engineers ask.
Scope and judgment
What is the difference between a mid-level and a senior data engineer on your team?- A mid-level ships a well-tested model. A senior notices the model should not exist, or that three models should be one, and gets the organization there. Seniors reduce the surface area. If your stories are only 'I wrote a complex DAG', you are answering as a mid-level.
How do you decide a problem is not worth solving with data infrastructure?- When the decision is one-off, the volume is small, or the consumer will not use the result. A spreadsheet, a notebook, or a one-shot query is allowed. Building a medallion pipeline for a 2,000-row quarterly extract is how seniors waste a team.
Tell me about a time you killed a project.- Name the sunk cost and the reason. We had four weeks in a streaming rewrite for a report checked daily; I stopped it, kept the batch job, and spent the time on a data contract the source team would actually run. Killing work is a senior skill. Never having killed anything is a signal.
How do you introduce a new tool to a stack that already works?- A written problem statement, a time-boxed spike, a rollback, and an owner after the spike. 'It is the modern default' is not a reason. I have said no to a second orchestrator, a second warehouse, and a feature store that had no feature consumers.
Design at the next scale
Design a ingestion platform for 80 source systems.- Metadata-driven: a table of sources, a generic extractor, contracts at the boundary, bronze as raw, and per-domain silver owned by domain teams. Do not design 80 bespoke DAGs. Talk about onboarding time as the SLO, not just throughput. The follow-up is how a new source goes from request to production without you in the loop.
How do you organize ownership so you are not the bus factor?- Domain teams own gold for their domain. A platform team owns warehouses, roles, and the shared extractor. meta.owner on every model, CODEOWNERS on every directory, and an on-call that pages the owner, not you. If every incident still pages you, the design failed.
What do you standardize, and what do you let teams choose?- Standardize identity, landing zone, orchestration interface, and how tests fail a deploy. Let teams choose model style inside their domain and, within reason, transform dialect. Standardizing pandas versus SQL for every team is how you get shadow pipelines.
How do you plan a warehouse migration without a two-year rewrite?- Strangle: new sources land in the new warehouse, clones or shares for read-heavy marts, dual-write only where you must. Move consumers by contract, not by table count. A big-bang cutover of 400 models is a career souvenir, not a plan.
When do you recommend a lakehouse over a warehouse, or the reverse?- Warehouse when the consumers are SQL and the team is small. Lakehouse when multiple engines must write, when ML feature pipelines share storage, or when you are already in object storage at scale. 'Iceberg is the future' without a consumer that needs it is not a recommendation.
Quality and trust
A number on an exec dashboard is wrong. You have 30 minutes. What do you do?- Communicate that it is under investigation, revert or hide the tile if you can, then bisect layers from gold to source. Do not start rewriting the model. Afterward, a short written note to the exec with the cause and the prevention. Seniors manage the room, not just the SQL.
How do you know the platform is healthy without reading Slack?- A weekly page: freshness SLO compliance, failed tests older than a day, credit burn versus budget, and models with no owner. If the only signal is complaints, you are running a helpdesk. Build the page before you need it.
How do you handle two teams that publish different 'revenue' numbers?- Do not pick a winner in Slack. Get both in a room, write one definition, put it in one model, and give the other a deprecation date. The senior move is a single owner for the metric, not a more sophisticated reconciliation job that papers over the fork.
What is your bar for 'production-ready'?- Declared grain, unique and not_null on the key, an idempotent write, an owner, and a freshness SLO. Dashboards can exist before this; they should be labeled accordingly. Shipping without a key test is not an MVP, it is a future incident.
People and process
How do you review a junior engineer's first incremental model?- Grain, lookback window for late data, uniqueness of the merge key, and what a rerun does. Compliment the structure, then make the late-data case concrete with a fixture. A review that only nits formatting teaches the wrong lesson.
How do you say no to a director without becoming 'the blocker'?- Restate the outcome they want, name the cheapest path that achieves it, and the risk of the path they asked for. Offer a date for the thin slice. Document the decision. No without an alternative is obstruction; yes without a risk statement is negligence.
What do you do in the first 90 days on a new data team?- Read ACCOUNT_USAGE or the equivalent, map the ten most expensive and the ten most consumed models, find the unowned ones, and fix one visible reliability issue. Do not rewrite the stack. Seniors earn the right to redesign after they have been on call.
How do you measure whether your team is getting better?- Time from source request to a tested mart, percentage of models with owners and key tests, incident count that pages after hours, and how often Slim CI is enough. Story points and 'number of DAGs' are vanity. Pick two metrics and publish them.
Hard tradeoffs
Streaming or batch for a fraud feature that 'must be real-time'?- Ask the decision latency. If the model scores at authorization time, you need a feature store and a streaming path. If analysts review cases every hour, a 15-minute batch is the system you can staff. I have shipped both and regretted the streaming one we could not operate.
Build a semantic layer or keep metrics in dbt marts?- A semantic layer earns its keep when many tools need the same metric and the marts are already forking. It is overhead when you have one BI tool and ten marts. I would rather have one well-owned fct_revenue than a half-adopted metrics layer.
How much platform should a 6-person data team run?- One warehouse, one orchestrator, one transform tool, managed if possible. No homegrown framework. The senior failure mode at this size is building a platform for the company you wish you were. Buy Composer or Astro; write models.
When is it acceptable to break a backward-compatible schema?- When you have a contract, a version or a dual-publish window, and a named consumer migration. Breaking it because the new name is cleaner is not acceptable. Compatibility is a promise to people who are not in the PR.
Closing
What should we be afraid of in our current design, having heard it?- Answer with something specific you heard: a single owner, an untested incremental, a warehouse with no monitor, a streaming job with no watermark. Generic 'scale' and 'culture' answers waste the question. This is how seniors show they were listening.
What do you want this role to look like in a year?- Name a platform outcome (onboarding time, SLO, cost) and a people outcome (others can ship without you). 'I want to learn Spark' is a mid-level answer. Seniors grow the system and the team, not just their resume.
What is a senior-level mistake you have made recently?- Be recent and specific. I over-indexed on warehouse-native pipelines and under-invested in tests, and a Dynamic Table refresh succeeded on bad grain. The lesson was that new features do not replace contracts. A mistake from 2019 that you have fully processed is too safe.
Why should we trust you with production?- Because you have been on call, you have rolled back, you write the grain down, and you have already told them a story where you were wrong. Trust is a track record of boring reliability, not a list of tools. Then stop talking.
From DataLane — tutorials at/blog, practice SQL live in theplayground.