What to Ask Your Interviewer (and the Red Flags to Listen For)
Every interview guide tells you to prepare questions. Almost none of them tell you what the answers mean, which is the part that actually protects you from a bad job.
Most candidate questions fail because they’re too easy to answer well. “What’s the tech stack?” gets you a list. “What are the growth opportunities?” gets you a rehearsed paragraph. Neither tells you whether the team has monitoring, whether anyone owns data quality, or why the last person left.
The questions worth asking are the ones where a vague answer is itself the information.
Key Points
- Ask about specific recent events, not general policies recent events can’t be rehearsed.
- Listen for specificity and hesitation more than for content.
- The strongest single question is what happens when a pipeline fails overnight.
- The most reliable red flag is nobody being able to describe how quality is monitored.
- Your questions are also being evaluated, so the good ones do double duty.
Quick summary: A team that runs well can describe concrete details instantly what broke, who was paged, what changed afterward. A team in trouble answers in generalities. You’re testing for that difference, not collecting facts.
Key takeaway: Replace “how do you handle data quality?” with “how did you find out about the last data quality issue?” The first invites a policy. The second requires a story, and stories are hard to invent under pressure.
Quick promise: This guide gives you the questions that reveal how a data team actually operates, what good and bad answers sound like for each, the red flags ranked by how much they should worry you, and how to ask without
Why Most Candidate Questions Fail
1. Generic questions get rehearsed answers
Any hiring manager has answered “what’s the culture like?” a hundred times. The response is polished, positive, and completely uninformative. You’ve learned nothing except that they’ve been asked before.
Specific questions about recent events don’t have prepared answers. “What broke last quarter?” requires actual recall. The interviewer either has a ready example which tells you they run incident reviews and remember them or they pause and struggle, which tells you something else entirely.
2. The signal is specificity, not content
This is the part most people miss. You’re not primarily collecting facts. You’re testing whether the person can produce concrete detail on demand.
A hiring manager who says “our last incident was a schema change in the billing service that broke three downstream models we caught it in about forty minutes because the freshness check fired” is describing a functioning team, whatever the details. One who says “we have monitoring in place and we take quality seriously” may also be describing a functioning team, but they haven’t given you any evidence of it.
Listen for names, numbers, dates, and specific systems. Their absence is the finding.
3. Your questions are being evaluated too
Worth remembering: this is still an interview. Good questions signal seniority they show you understand what makes data teams work and fail. Asking what happens when a pipeline fails overnight tells a hiring manager you’ve been on the receiving end of that, which is a stronger credential than most résumé lines.
So the questions below do double duty. They protect you, and they make you look like someone who’s operated real systems.
The Questions That Reveal Something
Organized by what they diagnose. You won’t ask all of these pick three or four per conversation.
Team maturity and operations
| Question | What it reveals | Green flag | Red flag |
| “What happens when a pipeline fails at 3 a.m.?” | Whether operations are real or improvised | Specific: who’s paged, what the runbook says, what the SLA is | “It doesn’t happen often” or a long pause |
| “How do you find out data is wrong before a stakeholder tells you?” | Whether monitoring exists | Named checks freshness, volume, reconciliation | “Users usually let us know” |
| “Walk me through how a change gets to production.” | Engineering discipline | Git, review, tests, staging, deploy | Manual steps, direct production edits, no review |
| “Who owns data quality?” | Whether accountability is defined | A named team or role, with a mechanism | “Everyone owns it” which means nobody does |
The 3 a.m. question is the single most efficient one on this list. It touches monitoring, on-call, documentation, and culture at once, and it’s very hard to answer well without a functioning practice behind it.
The actual job you’d be doing
| Question | What it reveals | Green flag | Red flag |
| “What did the person in this role work on last?” | Why the role is open | A clear story promotion, growth, a specific project | Evasion, or criticism of the previous person |
| “Roughly what share of the team’s time goes to new work versus maintenance?” | The reality of your week | An honest number, even an unflattering one | “Mostly building new things” with no maintenance mentioned |
| “What’s the biggest piece of technical debt you’d want help with?” | Honesty and self-awareness | A specific, named system with a plan | “We’re pretty clean” nobody is |
That second question matters more than most candidates realize, because it’s the difference between the job as advertised and the job as lived. A team spending 70% of its time on maintenance is not doing anything wrong, but you should know before you accept. Our breakdown of what data engineers actually do all day covers what a normal split looks like.
Team health
| Question | What it reveals | Green flag | Red flag |
| “How long have people on the team been here?” | Turnover, without asking about turnover | A mix of tenures | Everyone joined in the last year |
| “What broke last quarter, and what changed afterward?” | Whether the team learns | A real incident and a concrete change | No examples, or the fix was “we’re being more careful” |
| “How often does someone get paged, and who?” | On-call load | A specific frequency and a rotation | Vagueness, or one name mentioned repeatedly |
If the same person’s name comes up as the one who fixes things, you’ve found a team with a single point of failure and if you’re hired, you may be expected to become the second one.
Your growth and your manager
| Question | What it reveals | Green flag | Red flag |
| “What would I need to demonstrate to be promoted?” | Whether a path exists | A levelling framework or specific criteria | “It depends” or discomfort with the question |
| “What would someone on your team say about working for you?” | Self-awareness | A thoughtful answer including a weakness | Pure self-praise, or deflection |
| “How do you handle it when someone on your team is struggling?” | Management substance | A specific example with a supportive outcome | Generic performance-management language |
The promotion question is the one that pays off later. If nobody can articulate criteria at the interview stage, they won’t be able to articulate them in your review either and getting promoted internally depends heavily on those criteria existing.
Business context
| Question | What it reveals | Green flag | Red flag |
| “Who uses what this team builds, and do they trust it?” | Whether the team has credibility | Named consumers, honest about trust gaps | “Everyone uses our data” with no specifics |
| “Who’s the executive sponsor for the data team?” | Political safety | A named executive with a stated interest | Nobody, or an org chart answer |
The second question is the one most candidates never ask and the one that predicts layoffs best. A data team without an executive sponsor is a cost center waiting for a budget cycle.
The Red Flags, Ranked
Not all warning signs carry the same weight. In rough order of how much they should worry you:
1. Nobody can describe the on-call reality. If the answer to “what happens when something fails overnight” is vague, either nothing is monitored or someone is quietly absorbing the pain. You’ll find out which in your first month.
2. Everyone on the team is new. Tenure of under a year across the board means people are leaving faster than they’re being replaced. There’s always a reason, and you won’t be told what it is.
3. Data quality is owned by “everyone.” In practice this means quality issues are found by stakeholders, and you’ll spend your time proving your pipelines aren’t at fault.
4. Criticism of the previous person in the role. A manager who blames their departed employee to a stranger in an interview will do the same to you. This is the most reliable single-signal red flag on the list.
5. No answer on promotion criteria. If the path can’t be described, it isn’t a path.
6. The hiring manager can’t describe the technical stack. Non-technical managers of technical teams can work, but only when they’re honest about it and have technical leads. Someone who bluffs their way through architecture questions will also misjudge how long your work should take.
7. Pressure to decide quickly. Exploding offers and urgency about signing are almost always about the company’s problem, not your opportunity. This is also true in salary negotiations artificial deadlines are a pressure tactic, not a constraint.
8. Chaotic interview process. Rescheduled interviews, interviewers who haven’t read your résumé, no clear next steps. How a company treats candidates is a preview of how it treats employees, when it’s trying its hardest to impress.
The one that’s often misread
“We’re building the data platform from scratch” gets treated as a red flag, and it isn’t necessarily one. It can be the best job you’ll ever have greenfield work, real ownership, fast growth.
The follow-up determines which it is: “What’s the timeline and who’s the sponsor?” Greenfield with executive backing and a realistic timeline is an opportunity. Greenfield with no sponsor, an aggressive deadline, and a team of one is a job you’ll leave in eight months.
Green Flags People Underweight
Warning signs get all the attention, so here are the positives worth noticing:
- They tell you something bad unprompted. A hiring manager who volunteers a real weakness is being honest about everything else too.
- The interviewers seem to like each other. Hard to fake across four conversations.
- They ask you good questions. A rigorous, well-designed interview usually means a team with standards.
- Someone mentions a mistake they made. Blameless culture shows up in how casually people describe their own errors.
- The technical interviewer is curious about your reasoning, not just your answer. That’s the same person who’ll be a good reviewer of your code.
How to Ask Without Sounding Adversarial
The framing matters more than the question.
Pick three or four, not fifteen. You’re not conducting an audit. Choose based on what you most need to know for this specific role.
Attach a reason. “I’ve been on teams where quality issues surfaced through stakeholders rather than monitoring, and I’d love to understand how you handle that” lands very differently from the bare question. It reads as experience rather than suspicion.
Save the hardest ones for the hiring manager. Recruiters can’t answer them, and peer interviewers may feel put on the spot. On-call, technical debt, and promotion criteria belong in the hiring manager conversation.
Ask peers the honest version. The most useful question for a future teammate is: “What’s the most frustrating part of working here?” Almost everyone answers it honestly, because it’s phrased as an invitation rather than an accusation.
Watch the reaction, not just the words. A hiring manager who welcomes the question about failures is signaling something. One who becomes defensive is signaling more.
Walk Away, or Negotiate Around It?
Not every red flag is disqualifying. A rough guide:
Negotiable: heavy maintenance load, significant technical debt, no monitoring yet, an immature stack. These are problems you might be paid to solve and if so, get the scope and the level in writing.
Harder to fix: no executive sponsor, high turnover, a manager who blames people, no promotion criteria. These are organizational, not technical, and one engineer doesn’t change them.
A rule that holds up: technical problems are opportunities; people and political problems are traps. A messy stack with a good manager is a good job. A clean stack with a bad manager is not.
Essential Terms
- On-call rotation: The schedule determining who responds to production incidents.
- Runbook: Documentation for operating and recovering a system.
- Blameless postmortem: An incident review focused on systems rather than individual fault.
- SLA: A committed standard for availability or freshness.
- Executive sponsor: The senior leader who advocates for a team’s budget and priorities.
- Levelling framework: A company’s written definition of expectations at each level.
- Technical debt: Accumulated shortcuts that raise the cost of future change.
- Freshness check: Monitoring that alerts when data hasn’t updated as expected.
Final Thoughts
An interview is the only point where you have leverage and access at the same time. Once you accept, you’ll learn all of this anyway just slowly, expensively, and without the option to decline.
The technique is simple enough to remember under pressure: ask about specific recent events rather than general policies, and pay more attention to whether the answer is concrete than to what it contains. Teams that operate well can tell you exactly what broke last quarter. Teams that don’t will tell you they take reliability seriously.
And when you’ve done the work to get an offer after the applications, the screens, the system design rounds it’s worth spending twenty minutes making sure you actually want the job. The cost of asking is nothing. The cost of not asking is a year.
Frequently Asked Questions
How many questions should I ask?
Three or four per conversation, chosen for that specific interviewer. Prepare more than you’ll use, since some get answered naturally as you talk.
Will asking about failures make me look negative?
Done well, the opposite. Asking what happens when a pipeline fails overnight signals that you’ve operated production systems. Attach a brief reason to the question and it reads as experience rather than suspicion.
What should I ask a recruiter versus a hiring manager?
Recruiters: compensation band, process, timeline, team size, why the role is open. Hiring managers: on-call, technical debt, promotion criteria, what broke recently. Peers: what’s frustrating, what they wish they’d known.
Is it appropriate to ask about salary in the first call?
Yes, and it saves everyone time. Asking for the band early is standard practice and increasingly required by pay transparency laws. A company that refuses to share a range is telling you something.
What if I have no questions because they covered everything?
Say that, then ask one anyway “you covered most of what I wanted to know, but I’d like to hear what broke last quarter and what changed after.” Having nothing to ask reads as disinterest, however genuinely satisfied you are.
How do I ask about work-life balance without seeming lazy?
Ask about mechanics rather than hours: how often someone is paged, whether there’s a rotation, how deadlines are set. The answers tell you what you need without framing it as a question about your commitment.
Should I ask why the role is open?
Yes, always. It’s a completely standard question and the answer is unusually informative. Growth, backfill, and a departure all mean different things, and the way the answer is delivered matters as much as its content.
What if I get a bad answer but need the job?
Take the job if you need it that’s a legitimate decision, not a failure. But knowing the specific weakness lets you plan for it: negotiate scope, set expectations, and decide up front how long you’ll give it. Going in informed is better than going in hopeful.
P.S. Pick one question and make it your default: “What broke last quarter, and what changed afterward?” Ask it in every interview you do from now on. Over a few loops you’ll develop a feel for the difference between a team that answers immediately with specifics and one that has to reach for something. That calibration is worth more than any list and you can only build it by asking the same question enough times to hear the range.
