Section A · Critical

The First-Data-Hire Mandate

Being employee-zero for data changes the meaning of every interview question. This chapter is the lens for the whole guide — read it before the technical chapters, and re-read it the morning of.

The reframe

At a big company, a DE is handed a roadmap and a stack and asked to execute. As the first data hire, you are the roadmap and the stack decision. The loop is therefore testing two things at once: can you do the work, and can you be trusted to decide what work to do with no one checking you. Most candidates only prep the first.

Why "first hire" changes everything

When you're the first data person, several things are true that aren't true elsewhere, and each one shows up as a different kind of interview question:

There is no platform. No warehouse, no dbt, maybe no orchestration. So they care how you'd choose and stand these up — not how you'd optimize an existing Airflow DAG.
There is no one to check your SQL. So correctness habits (declaring grain, handling NULLs, validating row counts) matter more than raw speed. A wrong number you ship is a wrong number the company acts on.
You set the conventions. Naming, layering, testing standards, what "done" means. They're evaluating taste, because your taste becomes the company's standard for years.
Everything is a tradeoff against time. You can't build the ideal system; you must build the right next thing. Sequencing judgement is the headline skill.
You're a one-person product team. You'll do discovery with stakeholders, prioritize, build, document, and support. Pure-IC answers undersell you.

What they're really testing (under each question)

The question they ask	What they're actually assessing
"Write a query to get X"	Do you confirm the grain and edge cases before coding, or guess?
"How would you build the ingestion pipeline?"	Do you design for re-runs and failure, or only the happy path?
"The revenue number looks wrong — what do you do?"	Can you debug trust calmly and communicate during an incident?
"How would you model this?"	Do you start from the question and the grain, or pattern-match to a star schema?
"What's your first 90 days?"	Can you sequence? Do you deliver trust early or boil the ocean?
"What would you build vs buy?"	Do you optimize for a one-person team's time, or resume-driven architecture?
"Tell me about a time you were given an ambiguous problem"	Can you operate without a manager handing you scope?

Trust is the deliverable

Say this explicitly in the loop, because it's the thing that separates a founding-hire mindset from an IC one: the product of a data team is trusted numbers, not dashboards. A dashboard nobody believes is worse than no dashboard — it costs meetings and credibility.

As the first hire, your first real win is not a fancy model; it's a single, correct, defended metric that leadership stops re-checking in spreadsheets. Frame your early roadmap around earning trust in a small number of metrics, then expanding coverage. This single idea will make your answers in 05 (quality) and 08 (roadmap) land.

Line to use

"My first 90 days are about earning trust in a few numbers leadership cares about — get them defined, instrumented, tested, and documented so the founders stop maintaining their own spreadsheets. Breadth comes after trust."

Sequencing over completeness

The most common failure in a founding-hire loop is answering as if you had a team and a year. When asked what you'd build, candidates list everything: warehouse, ingestion, dbt, BI, data quality, lineage, a streaming layer, ML features. That signals you can't prioritize.

Instead, sequence explicitly and justify the order by value and reversibility:

Centralize first. Get the critical source data into one warehouse (even crudely) so there's a single place to ask questions. Use managed ingestion to avoid burning your only engineer on connectors.
Model the few metrics that matter. Pick the 3-5 numbers leadership actually uses (revenue, active customers, utilization, gross margin) and model them correctly end-to-end.
Add tests and freshness around exactly those metrics so they don't silently break.
Expose them in a BI tool people already look at.
Then expand coverage, add lineage/observability, and consider streaming or ML only when a real need pulls them in.

The point isn't this exact list — it's that you have an order and can defend it. "I'd do the highest-value, hardest-to-get-wrong thing first" beats a feature dump every time.

The judgement to say no (and not yet)

A first hire who builds everything anyone asks for ends up with an unmaintainable pile and no trust. Show you can push back constructively:

"Not yet." "A real-time dashboard is reasonable, but until the daily numbers are trusted, real-time just makes us wrong faster. Let's nail batch first."
"What decision does this drive?" Tie every requested metric to a decision. Requests with no decision behind them get parked.
"The cheap version first." Offer a 1-day version of a 3-week ask and see if it's enough. Usually it is.

This is judgement, and judgement is the whole job. Interviewers light up when a candidate declines to build something for a good reason.

Founding-hire traps to avoid in the loop

Over-engineering. Proposing Kafka, a lakehouse, and a feature store for a company with three data sources. Match the architecture to the stage.
Tool-first answers. Leading with "I'd use Snowflake + dbt + Airflow + Fivetran" before understanding the questions the business needs answered. Tools are downstream of the problem.
Ignoring stakeholders. Forgetting that as the only data person you must do discovery, set expectations, and document. Pure-technical answers read as junior here.
Perfectionism. Refusing to ship until the model is "right." Early on, a documented 80% answer that's trusted beats a perfect one that's late.
No definition of done. Not mentioning tests, docs, or how you'd know the number is correct. As the only checker, you must build the checks.

How to phrase founding-hire answers

A simple structure that signals seniority on almost any open question:

Clarify the goal / decision ("Who uses this number and what do they do with it?").
State your sequencing principle ("highest-value, hardest-to-reverse first").
Give the staged plan (crawl → walk → run), naming the cheap first step.
Name the tradeoff you're making and what would change your mind.
Say how you'd know it worked (trust earned, decision enabled, test passing).

Carry this forward

Every technical chapter that follows is written to be answered in this register. When you read the SQL, pipeline, and modeling material, keep asking: what's the founding-hire version of this answer? Next: 02 — SQL Deep Dive.

✓ Check yourself

Answer from memory before opening each one.

A founder asks for a real-time revenue dashboard in your second week. The daily revenue figure still differs from the finance spreadsheet by 4%. What do you say, and why?

Show answer
Ask which decision needs sub-daily numbers, then close the 4% gap first. A real-time view of a number nobody believes only makes the company wrong faster. Offer a cheap version, such as an hourly refresh of the same model, once the daily figure reconciles. See the judgement to say no.
An interviewer says "write a query to get X" and you start typing at once. What signal did you give up, and what should come first?

Show answer
You gave up the chance to show that you check before you build. Confirm the grain of the result and the edge cases, such as customers with no activity, before the first line. When nobody reviews your work, that habit is the thing being graded. See what they are really testing.
Why does a first hire aim for trust in three to five metrics instead of coverage of every source? What does it cost to get this wrong?

Show answer
A dashboard nobody believes is worse than none, because it produces meetings, shadow spreadsheets and lost credibility that take months to rebuild. Breadth built on numbers people distrust spreads the distrust. One defended metric that leadership stops re-checking is the first real win. See trust is the deliverable.
Someone on the panel asks why you would not start with streaming, since it is more impressive. Defend your order using the two criteria the chapter names.

Show answer
Order work by value and by reversibility. Centralizing data and modelling the few metrics is the highest-value step and the hardest to get wrong later. Streaming adds operating cost, and no decision yet depends on sub-minute data. See sequencing over completeness.
One candidate answers "what would you build?" with eight components. Another gives three staged steps and one deliberate deferral. Which reads as stronger, and when would the first answer be the right one?

Show answer
The second, because it shows you can prioritize with no one to tell you the order. The long list is right only when the interviewer has stated that you have a funded team and a year, so breadth is the actual job. Even then, say which piece comes first and why. See founding-hire traps.

Takeaway

As the first data hire you are both the roadmap and the stack decision, so the loop tests your judgement as well as your skill.
Each question hides a check: declaring grain, designing for re-runs, staying calm when trust breaks, and putting work in order.
The product is trusted numbers, not dashboards, so earn trust in a few metrics before you widen coverage.
Sequence by value and reversibility: centralize, model the few metrics, test them, expose them, then expand.
"Not yet" and "the cheap version first", each tied to a decision, are the judgement the role is hiring for.
Shape an open answer in five moves: clarify the decision, state the principle, stage the plan, name the tradeoff, say how you will know it worked.

The first technical skill the loop checks is SQL, and the mandate says to declare the grain before you type. → SQL Deep Dive