Nick Schrock built GraphQL at Facebook before he built an orchestrator. That one fact tells you more about a Dagster Labs interview than any leaked question bank. The people across the table have real opinions about API shape, data modeling, and where an abstraction leaks, down to the type signature. Wave your hands and they will notice inside a minute.
Dagster Labs was called Elementl until early 2023. It makes Dagster, an open-source orchestrator built around data assets instead of tasks. Where Airflow asks you to describe a graph of operations to run, Dagster asks you to declare the tables, files, and models you want to exist, then works out the execution order from how those assets depend on each other. The commercial side, Dagster+, wraps that idea with a hosted control plane, hybrid and serverless deployment options, and a GraphQL API that the web UI and tooling talk to. It is a Series B company, remote-first, and small enough that whoever interviews you probably owns the subsystem you would be working in.
So the loop rewards people who think like maintainers of a widely used Python library, not people who have memorized a stack of graph-traversal templates. Here is the structure most candidates run into.
| Round | Format | What it centers on | Rough length |
|---|---|---|---|
| Recruiter screen | Call | Background, why infrastructure and open source, logistics, comp expectations | 30 min |
| Technical phone screen | Live coding in a shared editor | Practical Python, reading and extending code you did not write | 60 min |
| Take-home or paired practical | Async task or live pairing | A small realistic problem: parse, model, or wire something end to end | 2-4 hrs, or 90 min live |
| API and system design | Discussion, some code | Designing a developer-facing API and the data model under it, failure modes | 60 min |
| Backend and platform round | Discussion with code | Python internals, concurrency, Postgres, orchestration semantics | 60 min |
| Values and collaboration | Conversation, often with a founder or hiring manager | How you handle ambiguity, open-source instincts, written communication | 45 min |
Not every candidate gets all six, and the order shifts. Product-engineering loops lean harder on the API design and the frontend contract; platform-engineering loops lean harder on databases, CI systems, and concurrency. The recruiter will usually tell you which track you are on, and it is worth asking so you prep the right muscle.
The phone screen is a coding round with the training wheels off
The first technical conversation is live, in a shared editor, and it stays practical. You will more often be handed code you did not write and asked to understand and change it than asked to invent an algorithm on a blank page. A typical shape: here is a function that walks a dependency graph or resolves a nested config, tell me what it does, now change its behavior or find the bug living inside it.
What they watch for is how you move through unfamiliar code. Do you read the types first? Do you write a quick failing case before you touch anything? Do you say out loud what you expect a line to do before you run it? Candidates who narrate their reasoning and check assumptions against the actual output do well here even when they do not finish. Candidates who go quiet and start guess-and-check editing do not, because that is the exact behavior that breaks a large typed codebase.
A few questions phrased close to how they land:
- “This function that resolves asset dependencies is quadratic. Where, and what would you change?”
- “A sensor is meant to fire once when an upstream file lands. It sometimes fires twice. Walk me through why that happens.”
- “How would you store partition metadata so that asking which partitions are stale stays fast at a hundred thousand partitions?”
- “Two runs try to materialize the same asset at the same time. What breaks, and what would you do about it?”
Those are not trivia. Each one has a real answer rooted in how orchestrators behave, and each one has a follow-up waiting if your first answer is shallow.
Where asset-based thinking shows up
You do not need to have shipped Dagster in production to pass, but you do need the mental model. The system revolves around a handful of ideas: assets are the things you want to exist, ops are units of computation, resources are the external systems an asset touches, and IO managers decide where an asset’s output actually gets written and read. Partitions slice an asset by date or region or customer. Sensors and schedules decide when work kicks off.
Interviewers probe whether you understand the properties those abstractions have to guarantee. Idempotency comes up a lot, because a backfill re-running a partition should not double-write. So does the difference between a task that ran and an asset that is up to date, which is the entire reason the asset model exists. If you can explain why re-running a stale asset is a different question than re-running a failed task, you are speaking their language.
A good way to build this fast: clone the repo, define three assets where B depends on A and C depends on B, run them, then break A on purpose and watch how the system reasons about what is now stale. Fifteen minutes of that teaches more than an afternoon of reading docs.
The design round is really an API design round
When Dagster Labs says system design, they often mean something narrower and more interesting than the usual whiteboard exercise about scaling a URL shortener. The question is frequently how you would design the interface a developer calls, and the data model sitting behind it. What does the decorator signature look like. What belongs in code versus config. What happens on the second call. How does the type checker help the user avoid a mistake before they run anything.
This is where the GraphQL heritage matters. The team cares a lot about API ergonomics, versioning, and backward compatibility, because their users write Python against these interfaces and get very unhappy when a minor release breaks them. If you have ever maintained a public API and had to keep an ugly parameter around for two years to avoid breaking downstream users, tell that story. It lands.
Failure modes are the other half. Expect to talk through what happens when a run is interrupted mid-materialization, how at-least-once delivery interacts with side effects, and how you would keep run state consistent when a worker dies. Concrete beats abstract every time. Naming Postgres row locks or an advisory lock to serialize competing runs will get you further than saying the word “scalable” three times.
What they actually screen for
Underneath the rounds, a few traits carry disproportionate weight. Typed Python is close to a hard requirement, not because they want to see fancy generics, but because their public surface is decorator-heavy and users get IDE autocomplete only if the annotations are correct. Comfort reading a large, layered codebase matters more than raw algorithm speed. And because the company is remote and open source, written communication is part of the job: they read your GitHub comments and your take-home writeup as work samples, not formalities.
Open-source instinct is a real signal here. If you have filed a good bug report, submitted a pull request that respected an existing convention, or joined a design discussion on a public tracker, bring it up. Dagster’s community lives on GitHub and in their Slack, and the team wants people who behave well in that arena, where every conversation is permanent and public.
Reading a Series B offer
Public compensation data specific to Dagster Labs is thin, so treat any single number you see with suspicion. What you can reason about is the shape of a US-based Series B infrastructure startup offer. Base salaries for senior engineers at that stage commonly land somewhere in the region of 170 to 220 thousand US dollars, moving with location and level, with the bigger variable being equity, which is meaningful on paper and completely illiquid until an exit that may never come. Verify the base against levels.fyi and Glassdoor before you anchor on anything.
Rather than fixate on a headline figure, ask the questions that make an equity grant legible. How many options, at what strike, against how many fully diluted shares. What was the preferred price at the last round and the most recent 409A valuation. What is the vesting schedule and the post-termination exercise window. A recruiter who answers those cleanly is a good sign about the company; one who dodges them is data too. Weigh the cash against your own tolerance for startup risk rather than against a FAANG total-comp screenshot, which is a different asset class entirely.
One more thing worth saying plainly: a small infrastructure startup pays partly in the work itself. You will touch systems that thousands of data teams depend on, ship to a public repo, and have your name on the commit. For some engineers that is worth a real discount on cash. For others it is not, and there is nothing wrong with knowing which one you are before you sit down to negotiate.
A week of prep that pays off
Skip the algorithm grind. Spend the time inside the actual product and its source. Read the concepts docs on assets, resources, IO managers, and partitions until you can explain each without notes. Skim enough of the codebase to see how they structure decorators and where the type annotations live. Write a tiny project that defines a few dependent assets, add a sensor, break something, and read the error the system hands back.
If you only do one thing, clone the repo, wire up three assets with real dependencies between them, and break one on purpose. The interview is a conversation about the kind of thing you just touched. Show up having touched it.
Practice the behavioral round:
