# MotherDuck Interview Guide 2026: DuckDB-Based Serverless Analytics, Hybrid Execution, and Jordan Tigani Heritage Source: https://www.techinterview.org/companies/motherduck/ Updated: 2026-07-12 · techinterview.org **TL;DR —** MotherDuck interviews test your grasp of DuckDB-based analytics and its hybrid execution model, which splits query work between the local client and the cloud, so expect deep questions on columnar OLAP engines, SQL performance, and single-node versus distributed tradeoffs. Founder Jordan Tigani's BigQuery background shapes a culture that rewards candidates who can argue why "big data is dead" and reason about serverless data warehousing from first principles. Rounds typically blend systems design, hands-on SQL depth, and product thinking about developer-facing analytics tools. ## MotherDuck Interview Process: Complete 2026 Guide ### Overview MotherDuck is the serverless data-warehouse company built on DuckDB — the open-source analytical database that runs embedded in applications and laptops alongside traditional server-side execution. Founded 2022 by Jordan Tigani (ex-Google BigQuery founding engineer and *The Big Data Problem* author) and Tino Tereshko (ex-Firebolt, Google BigQuery), private with a Series B in 2024. ~90 employees in 2026, deliberately small relative to product scope. Headquartered in Seattle with distributed engineering across the US and Europe. MotherDuck's distinctive technical position: hybrid execution between DuckDB running on the user's laptop / application and MotherDuck's cloud service, with the query optimizer deciding where to run each operation. This architecture addresses the observation that most analytical workloads fit on a single modern machine, while cloud execution handles the rare cases that don't. Engineering stack is C++ / Rust for DuckDB core, Go / TypeScript for cloud orchestration, Python / [SQL](/post/3233474463/sql-interview-questions-2025-window-functions-cte-joins-subqueries-indexing-query-optimization-transactions-normalization/) for the data-processing layer. Interviews reflect the database-systems heritage of the founders — genuine depth expected, pragmatic engineering culture. ### Interview Structure **Recruiter screen (30 min):** background, why MotherDuck, team interest. The engineering surface is compact: DuckDB core / extensions contribution, MotherDuck cloud platform, hybrid-execution query optimizer, developer experience (SDK, CLI, web console), and AI-adjacent features (MotherDuck AI / text-to-SQL). The small team size means broader scope per engineer. **Technical phone screen (60 min):** one coding problem, medium-hard. C++ for DuckDB-core contributions; Go / Rust for cloud platform; TypeScript for web; Python for data. Problems tilt systems-y — parse a SQL expression, implement a columnar operation, build a small query-plan node. **Take-home (many senior / staff roles):** 4–8 hours on a realistic systems or database-engineering problem. **Onsite / virtual onsite (3–5 rounds):** - **Coding (1–2 rounds):** one algorithms round, one applied database / systems round. - **[System design](/category/system-design/) (1 round):** analytics-platform prompts. "Design the hybrid-execution query planner deciding client vs cloud execution for each operation." "Design the data-sharing mechanism between DuckDB clients and MotherDuck cloud." "Design the text-to-SQL pipeline with MotherDuck AI grounded in the user's schema." - **Database / systems deep-dive (1 round):** DuckDB internals, columnar execution, vectorized processing, OLAP vs OLTP, extension ecosystem. Genuinely deep for core-DB roles. - **[Behavioral](/post/3233460379/behavioral-interview-questions-2026-star-method-amazon-leadership-principles-and-winning-answers/) / hiring manager:** past projects, small-team fit, database-systems passion. ### Technical Focus Areas **Coding:** C++ for DuckDB-core (modern C++17/20, template depth for the vector / type system); Go / Rust for cloud platform; TypeScript for front-of-platform; Python / SQL for analytics pipelines. **DuckDB internals:** vectorized columnar execution, type system (logical types, physical types, chunking), query optimization (Cascades-adjacent rules), extension mechanism, CSV / Parquet / JSON / Arrow integration, in-memory and single-node execution model, recent work on larger-than-memory processing. **Hybrid execution:** MotherDuck's core differentiation. Understanding how the optimizer decides operations' execution location, how data flows between client and cloud, consistency trade-offs, and performance implications is central. **Columnar / analytical databases:** vectorized execution, compression schemes (RLE, dictionary, bit-packing), predicate pushdown, projection pushdown, partition pruning, zone maps. **Cloud platform:** multi-tenant orchestration, storage for MotherDuck-hosted data, compute isolation, cost-aware execution, billing / metering per query execution. **Data-source integration:** Parquet, Arrow, Iceberg, Delta Lake, live-query integrations with Snowflake, BigQuery, Postgres. The philosophy is "meet users where their data is." **MotherDuck AI:** text-to-SQL grounded in user schemas, query explanation, anomaly surfacing. Practical applied AI rather than frontier research. ### Coding Interview Details Two coding rounds, 60 minutes each. Difficulty is medium-hard for core-database roles, medium for platform roles. Comparable to Snowflake / DuckDB open-source contribution standards. Typical problem shapes: - Parse and evaluate a SQL-like expression tree with typing rules — expect to walk a tree of operators and literals, propagate types up from the leaves, and reject mismatches like adding a string to an integer. Interviewers watch how you handle nulls and implicit casts, not just the happy path. - Implement a columnar operation (hash aggregation, sort, filter) with vectorization — you process values in batches of roughly a couple thousand rows rather than one row at a time, so interviewers look for tight inner loops and an understanding of why batching helps CPU cache and branch prediction. A hash-aggregation prompt probes how you build and probe the hash table across chunks. - Query routing: given a query, determine optimal execution location — be ready to name the signals you would weigh, such as where the bytes already live, how much data a scan touches, and the network cost of shipping intermediate results between client and cloud. - Data-format conversion (Parquet read / Arrow interop) — reading Parquet means handling row groups, column chunks, and encodings, while Arrow interop is about zero-copy handoff between engines. Show you understand the columnar layout instead of treating these as opaque file readers. - [Classic algorithm problems](/algorithm-patterns-cheat-sheet/) (trees, graphs, DP) with database-applied twists — think join ordering as a search over trees or a dependency graph for query planning. Solve the algorithm cleanly first, then connect it to the database framing. ### System Design Interview One round, 60 minutes. Prompts focus on analytics-platform realities: - "Design the hybrid-execution query planner deciding what operations run client-side vs cloud-side." - "Design data-sharing between local DuckDB clients and MotherDuck cloud with consistency guarantees." - "Design the extension-distribution system letting community-authored extensions load safely." - "Design MotherDuck AI's text-to-SQL pipeline with schema-grounded prompts and evaluation." What works: database-engineering-aware reasoning (query optimization, execution locality, consistency), practical cost-awareness (compute-seconds are expensive), engagement with DuckDB's specific architecture (embedded vs server execution, extension model). What doesn't: generic "build a SaaS" responses ignoring what makes MotherDuck's approach technically distinctive. ### Database / Systems Deep-Dive Distinctive for core-DB and hybrid-execution teams. Sample topics: - Walk through DuckDB's vectorized execution model. A strong answer covers how operators pass column batches to each other, why this beats row-at-a-time interpretation, and where the CPU time goes; mention morsel-driven parallelism if you know it. - Discuss columnar compression schemes and their trade-offs. Name specific schemes — RLE, dictionary, bit-packing, frame-of-reference — and say when each wins; the trade-off interviewers probe is compression ratio versus the decode cost paid on every scan. - Reason about hybrid-execution decisions for specific query shapes (TPC-H-like queries). Take a concrete query, such as a large fact-table scan joined to a small dimension, and argue which side runs where, weighing data movement against compute rather than defaulting everything to the cloud. - Explain how predicate pushdown interacts with partition pruning. Pushing a filter down lets the scan skip whole partitions or row groups whose min/max ranges cannot match, so fewer bytes are read; a good answer ties zone maps and min-max statistics to the pruning decision. - Describe what happens when a DuckDB query exceeds single-node memory. Talk through spilling to disk — hash tables and sorts that outgrow RAM get partitioned and streamed through temporary storage — and distinguish operations that stream from those that must fully materialize. Candidates with real database-engine background (especially columnar / analytical) have a clear edge. Strong database generalists from OLTP-only backgrounds (Postgres, MySQL) need some analytics-focus prep. ### Behavioral Interview Key themes: - **Small-team comfort:** "How do you operate when owning broad scope with limited infrastructure?" - **Database-engineering passion:** "What drew you to database systems specifically?" - **Pragmatic shipping:** "Describe a trade-off between theoretical correctness and practical shipping." - **Customer empathy:** "Tell me about engaging with a data-analyst or application-developer user." ### Preparation Strategy **Weeks 3-6 out:** C++ [LeetCode medium/medium-hard](/problems-by-difficulty/) for core-DB roles; Go / Python for platform. *Database Internals* by Alex Petrov for context. **Weeks 2-4 out:** install DuckDB and use it for real analytical work — run queries on Parquet files, try the Python / Node.js bindings. Try MotherDuck for a real project. Read DuckDB's architecture documentation and papers. MotherDuck's blog has specific technical posts. **Weeks 1-2 out:** mock system design with analytics-platform prompts. Prepare database-passion stories. Jordan Tigani's writings (including the famous "Big Data is Dead" essay) are context for the company's thesis. **Day before:** review DuckDB execution basics; prepare behavioral stories; refresh columnar-database fundamentals. ### Difficulty: 7.5/10 Solidly hard for the smaller company size. Database-engineering rigor is real. The hybrid-execution specialty creates distinctive interview challenges without clean analogs at other companies. Small-team dynamic filters candidates seeking larger-company structure. ### Compensation (2025 data, US engineering roles) - **Software Engineer:** $180k–$225k base, $150k–$280k equity (4 years), modest bonus. Total: ~$280k–$440k / year. - **Senior Software Engineer:** $230k–$290k base, $300k–$550k equity. Total: ~$380k–$600k / year. - **Staff Engineer:** $295k–$360k base, $600k–$1.1M equity. Total: ~$550k–$870k / year. Private-company equity valued at recent Series B marks. 4-year vest with 1-year cliff. Expected value is meaningful given the analytics-platform trajectory and the high-quality team. [Cash comp](/total-comp-calculator/) is competitive with top private-company database-platform bands. ### Culture & Work Environment Database-systems-serious culture with pragmatic-shipping orientation. Jordan Tigani's "Big Data is Dead" thesis (most workloads fit on one machine) shapes the product philosophy. The founders bring Google BigQuery engineering heritage; the team includes genuine database engineers. Remote-friendly with Seattle HQ presence. Pace is deliberate for core-database work, faster for product / platform surfaces. Small team means broad scope and visible impact per engineer. ### Things That Surprise People - The database-engineering depth is substantial for company size. The team includes real database experts. - DuckDB itself is a significant open-source project that MotherDuck contributes to and benefits from. - The hybrid-execution thesis (most workloads fit on a laptop) is a genuine technical-strategic bet. - AI / text-to-SQL features are shipping but the company remains grounded in analytical-database engineering. ### Red Flags to Watch - Weak database / SQL knowledge for core-DB roles. - Treating MotherDuck as "Snowflake but smaller." The architecture is genuinely different. - Dismissing the "single-machine is enough" thesis without engaging with it. - Not having used DuckDB for real analytical work. ### Tips for Success - **Use DuckDB seriously.** Run analytical queries on real data. Understand the performance characteristics. - **Try MotherDuck's free tier.** Understand the hybrid-execution product experience. - **Read Jordan Tigani's writings.** "Big Data is Dead" and related essays frame the company thesis. - **Engage with database-systems literature.** Columnar execution, vectorization, query optimization — foundational vocabulary. - **Be authentic about database-systems interest.** This isn't a company that rewards generalist thinking alone. ### Resources That Help - MotherDuck engineering blog and Jordan Tigani's essays — read these for the company's framing of hybrid execution and the "Big Data is Dead" thesis, and be ready to reference the reasoning rather than just the headline in behavioral and design rounds. - DuckDB architecture documentation and academic papers (the DuckDB team has published several) — the papers explain the vectorized engine and its design choices, so read at least the main DuckDB paper to discuss the execution model from first principles. - *Database Internals* by Alex Petrov — covers storage engines, B-trees and LSM trees, and the building blocks of distributed databases; use it to shore up fundamentals if your background is application code rather than engine internals. - *The Red Book* (Readings in Database Systems) for database-systems literature — a curated set of classic papers with editor commentary; skim the query-processing and column-store sections to build the vocabulary interviewers expect. - DuckDB itself — install locally, run queries on Parquet / CSV, try the Python API. Watch the EXPLAIN output and notice how it handles data larger than your laptop's RAM; nothing substitutes for running real queries. - MotherDuck free tier for hybrid-execution experience — run a query that starts locally and reaches into the cloud so you can speak from experience about the hybrid flow, not just the concept. ## Frequently Asked Questions ### What's the "Big Data is Dead" thesis? Jordan Tigani's observation (from his time at BigQuery) that most analytical workloads are small enough to fit on a single modern machine — typically under 100GB of compressed data. The industry's emphasis on "big data" solutions has outlasted the reality of most workloads. MotherDuck's hybrid architecture applies this insight: run on the laptop when you can, in the cloud when you must. This thesis is more nuanced than a slogan; candidates interviewing at MotherDuck benefit from engaging with it seriously. ### Is DuckDB the same as MotherDuck? No, but related. DuckDB is the open-source analytical database (contributed to by DuckDB Labs in the Netherlands). MotherDuck is a separate commercial company building a serverless cloud data warehouse based on DuckDB plus its own hybrid-execution layer. MotherDuck contributes to DuckDB and has close relationships with DuckDB Labs, but they're distinct organizations. Candidates can contribute to DuckDB as open-source regardless of MotherDuck interview paths. ### How does MotherDuck compare to Snowflake / BigQuery on interviews? Different emphasis. Snowflake and BigQuery are cloud-first, larger-scale-oriented database platforms with more rigorous interview loops for infrastructure roles. MotherDuck's interviews focus more on analytics-specific execution, hybrid-architecture reasoning, and smaller-team broad scope. Compensation at MotherDuck is competitive but typically below Snowflake / BigQuery in dollar terms; Snowflake / BigQuery have more predictable public-company equity. ### What's the opportunity in DuckDB contributions? MotherDuck engineers regularly contribute to DuckDB as part of their work. This is genuine open-source engagement, not a marketing side effort. Candidates who've contributed to open-source analytical databases or shown interest have an edge; candidates who haven't can grow into the open-source-contribution rhythm post-hire. The dual benefit (MotherDuck product + DuckDB open-source community) is distinctive. ### Is remote work supported? Yes for most roles. Seattle HQ has some in-person presence; remote US and limited international hiring happens. Timezone overlap with US business hours is generally expected. The small-team distributed-engineering model means async practices are mature. See also: [Snowflake Interview Guide](/companies/snowflake/) • [Databricks Interview Guide](/companies/databricks/) • [PlanetScale Interview Guide](/companies/planetscale/)