What to Ask a Data Engineer Before Hiring Them

Most interviews for data engineers are designed by engineers, for engineers. Technical screens, take-home assignments, coding challenges. If you're a founder or a non-technical hiring manager, you're at a disadvantage. You can read about what dbt and Airflow are. But you can't assess whether the person in front of you actually knows how to use them well, or whether they've only ever extended what someone else built.

These questions won't make you a technical expert. But they'll help you understand whether this person has the experience your situation actually requires.

Ask About Building, Not Just Using

The most important distinction to surface early: have they built data infrastructure from scratch, or have they maintained systems that already existed?

Ask directly: "Walk me through a time you built a data platform or data stack from the beginning. What decisions did you make and why?"

Listen for: specific tool choices with reasoning behind them, not just a list of tools. What did they consider? What did they rule out and why? If the answer is vague ("we used the standard stack"), probe further. A person who has actually made these decisions from zero will have opinions.

If they can't describe a greenfield build, ask how they would approach one for a company at your stage. The quality of the thinking matters more than whether they've done it before, but experienced engineers will have concrete frameworks. Less experienced ones will give you generalities.

Ask About What Broke

Good engineers have stories about things going wrong. Ask: "Tell me about a time a pipeline broke in production. How did you find out, what caused it, and what did you change so it wouldn't happen again?"

What you're listening for: did they find out before or after someone else noticed? That tells you how they think about monitoring. Was the fix a patch or a structural change? That tells you how they think about root causes. Did they document what happened? That tells you whether they're thinking about the next engineer or just solving the immediate problem.

Engineers who've never dealt with production failures at scale either haven't worked in production enough or don't remember what they learned. Either is worth noting.

Ask About Documentation

This is one most people skip. It shouldn't be.

Ask: "How do you document the systems you build? Can you show me an example or describe what that looks like in practice?"

Documentation is the thing that determines whether your infrastructure survives the engineer. If they hand-wave this ("I document when I have time" or "I write comments in the code"), that's a signal. If they have a clear approach and can describe it concretely, that's a much better signal.

The best engineers treat documentation as part of the work, not a courtesy they get around to later.

Ask About Decisions They Disagreed With

Ask: "Have you ever pushed back on a technical decision at work? What was the situation?"

You're not looking for conflict. You're looking for someone who has opinions and knows how to advocate for them without being precious about the outcome. Data engineers at small companies need to tell a founder or a non-technical manager when a request will create technical debt, when a timeline isn't realistic, or when the approach being asked for is the wrong one. An engineer who just executes requests without this kind of judgment is an expensive executor.

Ask How They'd Approach Your Specific Situation

Before the interview, prepare a brief description of where you are: what data sources you have, how many, what the current state of your infrastructure is, what you're trying to achieve. Then ask: "If you joined us next Monday, what would you want to understand in the first two weeks, and what would you prioritize building first?"

This tells you several things at once. Whether they ask clarifying questions before jumping to answers (good sign). Whether their priorities make sense for your stage. Whether they're pattern-matching to a default setup without engaging with your specific situation.

The best answer involves asking you more questions. The worst answer is a confident prescription delivered before they understand the problem.

Ask About Tools They've Chosen to Not Use

Ask: "Is there a tool or technology that's popular right now that you think is overhyped or misused? What's your take?"

Technical opinions reveal depth. Someone who has only worked with tools they were handed tends to have neutral views on everything. Someone who has made real decisions and seen the consequences tends to have strong, reasoned views. You don't need to know if they're right. You need to know they can think.

What Good Answers Look Like

Across all of these, you're looking for the same underlying qualities: specificity over generality, reasoning over answers, and evidence of thinking about who comes after them. The engineers who make good hires for startups are not the most technically advanced ones. They're the ones who can build pragmatically, communicate clearly, document as they go, and tell you when you're asking for the wrong thing.

That combination is rarer than it should be. These questions help you find it.