▸ INTERVIEW SKILLS · what tanks a hire
Interview red flags.
These are the specific behaviors and answers that appear in No Hire and Strong No Hire scorecards. Not vague advice — specific patterns, why they flag, and what to do instead.
Communication red flags
HOW YOU SPEAK MATTERS AS MUCH AS WHAT YOU SAY
Going quiet for 60+ seconds while thinking. The interviewer can't grade what they can't observe. They're writing "unclear thought process" in their notes.
*silence for 90 seconds* "...okay I think I'd use a window function."
"Let me think through this out loud — the challenge here is partitioning by customer while keeping the time window consistent. I'm considering ROW_NUMBER vs RANK depending on how we handle ties…"
Behavioral answers that go 5+ minutes and jump between timelines, roles, and topics. The interviewer can't extract a signal from noise. They stop taking notes.
"So this was at my second job, actually my third — wait, no, my second — anyway we had this issue where the pipeline was breaking and also at the same time we were dealing with a migration, and my manager at the time, who was actually a data scientist not an engineer, said we should…"
Start with one crisp sentence (the situation). Name your role. Walk the action in order. State the result in numbers. Under 2.5 minutes total.
Immediately changing your answer when the interviewer questions it — without explaining why you changed. This signals you don't have conviction in your reasoning. Interviewers often push back specifically to test how you hold your ground.
Interviewer: "Are you sure that's the right approach?" Candidate: "Actually, maybe not — I think we could also do it differently."
"I'm confident in this approach because [reason]. If there's a constraint I'm missing that makes it wrong, I'd want to understand that — what are you thinking?" If they give a valid point, update with: "That's a good constraint I hadn't considered — that changes my answer to…"
Technical red flags
WHAT RAISES A NO HIRE IN TECHNICAL ROUNDS
"I'd use Kafka" or "We'd put this on Spark" without explaining why, what the tradeoffs are, or what would make you choose something different. Tool-naming is not engineering thinking.
"I'd ingest this with Kafka into S3, process with Spark, and serve from Snowflake."
"Given that the events need sub-5-minute freshness and the schema is relatively stable, I'd lean toward Kafka for the ingestion layer because replay is a requirement. If this were batch-only, Kinesis Data Firehose would be simpler to operate. For the query layer, the access pattern is analytical — full scans with aggregations — so columnar storage makes sense. Snowflake or BigQuery both work; I'd pick based on existing org tooling and multi-cluster concurrency needs."
Starting to write SQL or a system design immediately without asking any clarifying questions. The requirements you assume are almost always wrong. This signals you'll build the wrong thing confidently in production too.
Interviewer gives a design prompt. Candidate starts drawing boxes immediately.
Ask 3–5 questions: scale (rows/day, users), latency (real-time vs. batch), access patterns, consistency requirements, existing stack. Then design.
Claiming you built or owned something on your resume but unable to answer basic questions about it. This is the fastest path to a Strong No Hire. Interviewers write this up as a credibility issue.
Resume says "Architected real-time pipeline processing 10M events/day." Interviewer asks "What was the consumer lag SLA?" Candidate: "I don't remember, someone else handled that part."
Only put things on your resume you can talk about at depth. If you contributed to a system you didn't design, say "I contributed to" not "I architected." Own your actual scope.
Describing solutions without any awareness of the scale they operate at — or applying enterprise patterns to 1M-row problems, or applying startup patterns to 100B-row problems. Shows you don't think in orders of magnitude.
"I'd use a full table scan and then join in Python." (for a 50B-row table)
Always anchor on scale before proposing a solution. "At 50B rows, a full scan is $$$. I'd push the filter to the partition pruning layer, pre-aggregate in Spark, and only join on the reduced result set."
Behavioral red flags
WHAT TANKS BEHAVIORAL SCORES
Using "we" for everything in a behavioral answer obscures your individual contribution. Interviewers are trying to grade you. If they can't isolate your role, they default to "unclear ownership."
"We built this pipeline, we ran into latency issues, and we fixed it by migrating to Flink."
"I designed the pipeline. The team built it together, but the Flink migration decision was mine — I ran the benchmarks, made the proposal, and drove the migration. My manager handled the stakeholder communication."
Using a failure story to implicitly or explicitly blame someone else. This signals low ownership, low self-awareness, and predicts future toxic behavior on the team. It shows up in scorecards as "not owning outcomes."
"The project failed because my manager gave us an unrealistic deadline and the QA team wasn't thorough enough."
"The project missed its deadline. Looking back, I underestimated the schema complexity during my scoping — I should have spiked the migration earlier. I've since added a mandatory spike phase to my project plans for anything involving third-party schema changes."
Behavioral answers with no quantification. "I improved the pipeline" — by how much? "We had a lot of users" — how many? "It took a while" — how long? Vague answers make it impossible to calibrate level.
"I improved our data pipeline significantly and it made a big impact on the business."
"I reduced our ETL runtime from 6 hours to 40 minutes by replacing the row-by-row Python loop with a vectorized Pandas operation and pushing the deduplication step to a pre-stage Spark job. This unblocked the 7am dashboard refresh that 200 analysts depended on."
Character red flags
THESE ARE OFTEN VETO-LEVEL
"My last company had terrible engineering culture." "My manager was clueless." "The team didn't know what they were doing." Every interviewer hears this and thinks: this is how they'll talk about us.
"I left because the leadership didn't know what they were doing and kept making bad technical decisions."
"The company was moving toward a different technical direction than I wanted to grow in — more batch-oriented work — and I wanted to go deeper on streaming infrastructure. It was a good place to learn, and I'm glad I was there."
Bringing up compensation in the middle of a technical or behavioral interview signals misaligned priorities. Save it for the recruiter screen or final offer stage. One interviewer mentioning it in a debrief can shift the room's vibe.
"Before we start — can you tell me what the comp band looks like for this role?"
Save all comp discussion for the recruiter. In the technical interview, your only job is to show you can do the work.
Red flag questions you ask
YOUR QUESTIONS REVEAL YOUR PRIORS
| Red flag question | What it signals | Better alternative |
|---|
| "Do you have any concerns about my background?" | Insecurity, fishing for reassurance | Don't ask this. Ever. |
| "What does a typical day look like?" | Didn't do research; thinking about comfort, not impact | "What does the team's current biggest technical challenge look like?" |
| "How many hours do people work?" | Work-life balance as the primary filter (fine priority, wrong moment) | Ask the recruiter, not the engineer |
| "Can I work remotely full-time?" | Same — ask the recruiter | Ask the recruiter at the start of the process |
| "What's the tech stack?" (if it's in the JD) | You didn't read the job description | Ask something that shows you read it: "I saw you use dbt — are you on the semantic layer yet?" |
← Interviewer's Mind ·
Resume Bullets →