# What the dbt Labs interview looks like after the merger

Source: https://www.techinterview.org/post/3233476181/dbt-labs-interview/
Updated: 2026-07-12 · techinterview.org

dbt Labs runs a pairing-heavy loop, and the technical rounds look almost nothing like a LeetCode grind. You spend most of a screen sitting next to an engineer, reading a function someone else wrote, working out why it returns the wrong numbers, and making it faster without breaking the tests. Months of dynamic-programming drilling transfer a little, but the thing they watch is how you reason about unfamiliar code while someone talks to you.

The company you are interviewing at in 2026 is not quite the one from a year ago. Fivetran and dbt Labs closed an all-stock merger on June 1, 2026, after announcing it the previous October. George Fraser, who founded Fivetran, is CEO of the combined company; Tristan Handy, who created dbt, is President. The dbt brand, the open-source project, and dbt Cloud all continue. What shifted is the pitch: ingestion from Fivetran and transformation from dbt under one roof, aimed at feeding governed data to AI agents. Expect at least one interviewer to ask where your work would sit along that ingestion-to-transformation-to-serving path, so have a real answer instead of a shrug.

## The loop, round by round

Candidates describe a fast, transparent process, usually four to six touchpoints from first call to offer. The exact rounds depend on whether you are going for an analytics engineering, data platform, or product engineering role, but the shape stays consistent.

| Stage | Format and typical length | What the interviewer is scoring |
| --- | --- | --- |
| Recruiter screen | About 30 minutes, often after a LinkedIn message | Motivation, rough level, comp expectations, whether you understand what dbt does |
| Technical pairing | 60 minutes, live, debug and optimize an existing function or model | How you read unfamiliar code, test-first instincts, how you communicate while stuck |
| Code review and behavioral | 45 to 60 minutes, review a diff or discuss past projects | Judgment about correctness and readability, depth of your past work |
| Onsite (virtual) | Three to four back-to-back rounds: technical, dbt or systems depth, behavioral, project walkthrough | Domain depth, collaboration, ownership |
| Final leadership | 30 to 45 minutes with a hiring manager or exec, not always included | Values fit, how you think about the product and its users |

The process tends to move quickly once it starts. That cuts both ways: you get answers fast, and you have less time between rounds to cram.

## The pairing round is the one that matters

This is where offers are won and lost. You get a working, or nearly working, piece of code and a problem statement: a function that computes the wrong aggregate, a model that double-counts after a backfill, a query that times out on a large table. The interviewer pairs with you, which means they expect you to talk. Sitting in silence for four minutes while you think reads worse here than a wrong guess you explain out loud.

A few habits help. Write or run a failing test before you touch the logic, so you can prove the bug exists and later prove it is gone. Reproduce first, theorize second. State your hypothesis before you change anything ("I think the join fans out because there are duplicate keys on the right side, let me check the grain"). And when the interviewer nudges you, treat it as information, not as a trap. They are simulating a real pairing session with a coworker, and part of what they are scoring is whether working with you all day would be pleasant.

Common shapes of the exercise:

- A Python or SQL function that produces subtly wrong output on edge cases like nulls, empty input, or duplicate keys

- An inefficient transformation you need to speed up without changing its result

- A code-review prompt where you read a diff and call out correctness and readability problems

## The dbt knowledge they actually probe

If the role touches analytics engineering or the dbt product, expect questions that assume you have shipped real dbt projects, not just read the docs. They are checking for scars.

Materializations come up early. Know cold when you would pick a view over a table, when an incremental model earns its extra complexity, and what ephemeral actually does (it inlines as a CTE and never lands in the warehouse). A strong answer ties the choice to cost and freshness: views are cheap to build and always current but push compute to read time, tables are the reverse, and incremental models trade some correctness risk for build speed on large, append-mostly data.

Incremental models are the richest vein. A classic prompt: "Your incremental model started double-counting rows after someone ran a backfill. Why?" Good answers reach for the `unique_key` config, the difference between append and merge or delete-and-insert strategies, late-arriving data landing outside your `is_incremental()` filter window, and the fact that a full refresh would have hidden the problem. If you can sketch the `is_incremental()` block and explain what a lookback window protects against, you are ahead of most candidates.

Snapshots and slowly changing dimensions show up when the role leans toward modeling. Be ready to explain how dbt snapshots implement Type 2 history with `dbt_valid_from` and `dbt_valid_to`, and why that beats hand-rolling change tracking. Tests are the other staple: the built-in `unique`, `not_null`, `relationships`, and `accepted_values`, plus when you would write a custom generic test versus a singular test. Someone will ask why `ref()` matters, and the answer they want is that it builds the DAG so dbt can work out build order and lineage, which hardcoded table names throw away.

The newer material is the dbt Fusion engine. It is a Rust rewrite of dbt's parser and compiler, out of the SDF acquisition, that understands SQL instead of treating it as text, which enables faster parsing and real-time error checking. It shipped as part of dbt Core v2.0 under the Apache 2.0 license. You do not need to have run it in production, but knowing what it is and why a compiled, SQL-aware engine matters for large projects signals that you are paying attention to where the tool is going.

## For platform and backend roles

dbt Cloud is a real product with scheduling, a metadata API, the semantic layer, and multi-tenant infrastructure, so platform interviews lean toward practical systems work. Expect design discussion about running untrusted user SQL safely, orchestrating thousands of scheduled jobs, caching and serving metadata, and API design for the discovery and semantic layers. The bar is pragmatic engineering rather than distributed-systems trivia. Bring a project where you owned the reliability or performance of something with real users, because the round where you walk through a past project rewards specifics: the metric you moved, the tradeoff you later regretted, the incident you caused and then fixed.

## Behavioral rounds and what they listen for

dbt Labs is a community company as much as a software company, and the culture questions reflect that. They ask about times you disagreed with a decision, how you handle ambiguous ownership, and how you have helped people outside your team use your work. The dbt community (the Slack, the Coalesce conference, thousands of open-source contributors) is a big part of how the company grows, so evidence that you can write clearly and teach carries weight. Vague answers hurt. Bring three or four stories with concrete stakes and outcomes, and be ready to say what you would do differently.

## Comp and what the merger did to your equity

dbt Labs pays competitively for a data-infrastructure company, with total compensation built from base salary, a bonus or variable component for some roles, and equity. The equity is the part that changed. Before June 2026, offers included private dbt Labs shares. After the merger, grants are tied to the combined Fivetran and dbt Labs entity, which is still private. Your equity is illiquid, and its value rests on assumptions about a future exit rather than a public share price you can look up.

Do not accept a headline number without asking how the grant is structured: how many units, over what vesting schedule, at what current preferred or 409A valuation, and how the merger converted any dbt equity discussed earlier. For current base and total-comp bands by level, check levels.fyi and ask the recruiter directly, since the numbers move and post-merger leveling is still settling. Anyone quoting you a precise, confident total-comp figure for the merged company right now is guessing.

## How to prep in the week before

Rebuild your pairing reflexes on real code rather than puzzles. Take a small open-source repo, introduce a bug, and practice finding it while narrating out loud, ideally with a friend playing interviewer. If the role is dbt-adjacent, spin up a tiny dbt project against DuckDB or a warehouse trial, build a staging model and a mart, add tests, and convert one model to incremental so you have felt the failure modes rather than memorized them. Read the merger announcement so you can speak to the ingestion-plus-transformation story without getting caught flat. Then line up your behavioral stories, because the fast loop leaves little room to improvise them.

The people who get offers have usually broken a production model at 2 a.m., worked out why, and can walk through it calmly. Practice being that person out loud, and the loop stops feeling like an exam.