Analytics Engineer interview questions and how to answer them
An analytics engineer interview tests two things at once: whether your SQL and modelling hold up under pressure, and whether you can talk a finance lead out of a bad metric definition. Expect a live SQL round, a modelling exercise, and at least one conversation that's really about stakeholders. Here's what gets asked and what the panel is listening for.
What happens in each round
- 1
Recruiter screen
What happens
Which warehouse and transformation tools you've used for real, whether you've worked in git with pull requests, and whether you understand this is a modelling role rather than a dashboard role.
- 2
Live SQL exercise
What happens
Window functions, joins that don't fan out, handling nulls and duplicates, and whether you check your row counts before calling a query done. Talking through your reasoning counts as much as the final answer.
- 3
Take-home or modelling round
What happens
How you'd turn a pile of raw source tables into staging and mart models: grain, naming, keys, tests and documentation. Some teams send a small dbt project to extend; others ask you to sketch it on a whiteboard.
- 4
Stakeholder or case interview
What happens
How you handle conflicting definitions, vague requests and a broken dashboard with an executive waiting. Usually run by an analytics manager or a senior analyst who'd be your main customer.
- 5
Hiring manager conversation
What happens
How you prioritise a request queue, what you'd fix first in their current setup, and whether you'd raise the bar on code review and testing without slowing everyone down.
Questions you're likely to get
1.Walk me through how you'd structure a dbt project from raw sources to marts.
Why they ask
This is the core of the job. They want to see whether you have a consistent layering approach or just pile SQL files into one folder.
How to answer
- Staging models that rename, cast and lightly clean each source table, one to one with the source
- Intermediate models for reusable joins and business logic that several marts share
- Mart models built around a clear grain, split into facts and dimensions
- Tests and docs at every layer, with sources declared and freshness checked
2.What's the grain of a table, and how do you decide it?
Why they ask
Wrong grain is the root of most double-counted revenue. They want to hear you think about it before writing a join.
How to answer
- Define grain as what one row represents, stated in a sentence
- Choose it from the questions the business asks, not from the source table's shape
- Enforce it with a unique test on the primary key
- Give an example where you split a table because two grains were mixed together
3.Here's an orders table and an order items table. Write a query for revenue by customer by month.
Why they ask
It's a live check for join fan-out. Joining at the wrong level and then summing inflates the number, and many candidates walk straight into it.
How to answer
- Ask which table holds the amount and whether discounts or refunds apply
- Aggregate items to the order level before joining, or sum at the item level only
- Truncate the date consistently and state which time zone you assumed
- Sanity-check the total against a simple sum on the source table
4.How would you model a customer whose plan or address changes over time?
Why they ask
They're checking whether you know slowly changing dimensions and dbt snapshots, and when history is worth keeping.
How to answer
- Name the options: overwrite, or keep history with valid-from and valid-to columns
- Explain dbt snapshots as the usual way to capture history from a source that updates in place
- Say how you'd join a fact to the version of the customer that was true at the time
- Admit the cost: bigger tables and trickier joins, so only track the fields people report on
5.Finance and sales each have a different number for monthly revenue. What do you do?
Why they ask
Metric disputes land on the analytics engineer's desk. They want to see whether you can find the real difference and get a decision made.
How to answer
- Reconcile first: trace both numbers to their logic and find exactly where they diverge
- Put the difference in plain terms, such as booked versus recognised, or gross versus net of refunds
- Get the metric owner to decide, then encode it once in a model or semantic layer
- Keep both if both are legitimate, with clear names so nobody confuses them again
6.Which tests do you put on a model, and how do you decide?
Why they ask
Testing is what separates this role from an analyst's. They want judgement, not a list of every test in the package.
How to answer
- Unique and not null on every primary key as the baseline
- Relationships and accepted values where a bad join or new status code would break reports
- Source freshness so stale loads get caught before a stakeholder does
- Keep tests that have caught something and cut noisy ones people learn to ignore
7.The main dashboard is wrong and an executive is asking why. Talk me through your first half hour.
Why they ask
Incidents happen often in this job. They're watching for a calm, ordered process and good communication.
How to answer
- Acknowledge fast and tell people which numbers to avoid until it's fixed
- Check the latest dbt run, test failures and source freshness before touching any SQL
- Trace upward through the lineage graph to the first model where the numbers go wrong
- Fix, rerun, confirm, then write a short note and add a test so the same break is caught next time
8.A dbt model takes too long and the warehouse bill is climbing. How would you speed it up?
Why they ask
Cost and runtime become your problem once the project grows. They want practical warehouse knowledge.
How to answer
- Look at the query profile to find the expensive step before guessing
- Switch large, append-heavy tables to incremental models with a sensible unique key
- Filter early, avoid selecting every column, and cluster or partition on the common filter
- Question whether the model needs to run as often as it does
9.How do you handle review on someone else's pull request?
Why they ask
Analytics engineers often set the code standards for a team of analysts. They want to know if you'll raise quality without becoming a bottleneck.
How to answer
- Check the grain, joins and tests first, style second
- Run the model or read the CI output instead of reviewing SQL in the abstract
- Explain the why in comments so the author learns, not just fixes
- Use a linter like SQLFluff for style so reviews don't turn into formatting fights
10.An analyst asks you to add one more column to a core mart for a single report. What do you say?
Why they ask
Request pressure bloats models. They want to see whether you protect the shared layer while still helping.
How to answer
- Ask what decision the report supports and who else would use the field
- Add it if it fits the model's grain and has broad use
- Otherwise suggest a report-specific model built on top of the mart
- Keep the conversation friendly: the goal is getting them the answer, not guarding a table
11.Tell me about a model you built that people actually relied on.
Why they ask
A behavioural check on impact. They want evidence your work changed how people made decisions.
How to answer
- Name the business question and who asked it
- Describe the modelling choices you made and one you'd change now
- Say how you knew it was trusted, such as the old spreadsheet being retired
- Mention how it was tested and documented so others could maintain it
12.Why analytics engineering rather than analyst or data engineer?
Why they ask
They want to know you understand the role and won't drift back to dashboards or pipelines within a few months.
How to answer
- Point to a moment when you fixed the same data problem for many people at once
- Say you like both the business side and engineering habits like tests and review
- Be honest about which side you're stronger on and how you're closing the gap
Mistakes that sink good candidates
Writing SQL in the live round without saying anything, then presenting a number you haven't sanity-checked
Talking about dashboards you built as if they were the modelling work
Dismissing stakeholder questions as the analysts' job
Claiming dbt experience you can't back up when they ask about macros, sources or incremental models
Need more Analytics Engineer interviews to prep for?
HeroApply applies to Analytics Engineer jobs that match you, every day. 998 jobs are open today.