Red Flags in Technical Interviews: 12 Signs a Candidate Is Bluffing
12 red flags that a candidate is bluffing in a technical interview — with short examples and a simple anti-bluff follow-up routine for recruiters.
Most recruiters are trained to spot soft red flags: rudeness, ghosting, wild salary swings. Technical bluffing is different. It sounds polished. It flatters the job description. It burns specialist rounds.
Here are 12 concrete signs a candidate may be bluffing on a technical screen — with a short example for each. One sign is a prompt to dig. A cluster of signs is a reason to protect engineering time.
“Bluffing usually fails the second question, not the first. Your job is to ask the second question.”
How to use this list
- Do not reject on nerves, accent, or short answers alone — see silent candidates
- Do treat inconsistency + emptiness after follow-up as high risk
- Do write the evidence you heard, not the vibe you felt
- Do ask one depth probe per claim on the resume
1. Buzzwords without implementation
Says “we used microservices and event-driven architecture.” Follow-up: “What was the message contract, and what failed at retry?” Blank stare or more slogans.
2. Vague ownership on past projects
Every story is “we shipped.” Ask “What did you personally decide?” If they cannot name a decision, the resume may be team-adjacent.
3. Cannot explain a tool they listed
CV says Kubernetes. Ask how a rolling update differs from a recreate strategy in their last cluster. They retreat to “the DevOps team handled that.”
4. Answers only in abstractions
“It depends on the use case” forever, with no example from their work. Seniors use “it depends,” then pick a branch and justify it.
5. Story changes under light pressure
First: they led the migration. Follow-up on rollback: suddenly they “supported the lead.” Inconsistency is a louder signal than nervousness.
6. No metrics, no verification
Claims a 10x improvement with no before/after measure, dashboard, or customer outcome. Ask “How did you know it worked?”
7. Blames everything on others
All failures are PMs, legacy, or “bad juniors.” No learning, no personal miss. Interview athletes externalize; strong ICs own a slice.
8. Refuses to go one layer deeper
Happy to talk architecture slides; hostile or evasive when asked about one function, query, or config they touched.
9. Name-drops companies instead of work
“At FAANG we did X” without describing their role. Prestige is not evidence. Ask for their commit-level or ticket-level contribution.
10. Overconfident on unknowns
Never says “I don’t know.” Invents APIs, flags, or incident details. Strong candidates mark uncertainty and describe how they would find out.
11. Prep that sounds like ChatGPT polish
Perfect paragraph answers that collapse when you change one constraint (“What if the table is 2TB?”). Rehearsal without adaptable judgment.
12. Cannot describe failure — only success
No incident, no bad migration, no wrong abstraction. Either junior scope or curated fiction. Ask “What would you undo from the last year?”
Bluff vs silence vs weak skill
| Pattern | What you hear | What to do |
|---|---|---|
| Bluff | Fluent, shallow, collapses on follow-up | One more probe; if empty, do not advance |
| Silent / reserved | Short, then deeper when prompted | Protect pause; narrow the question |
| Truly weak | Thin even after concrete prompts | Reject with clear evidence notes |
| Strong senior | Tradeoffs, ownership, “I don’t know” with a plan | Advance |
A 60-second anti-bluff routine
- Pick one resume claim (tool, project, or metric)
- Ask for a concrete walkthrough with their personal role
- Change one constraint (“what if traffic 10x?” / “what failed in v1?”)
- Listen for mechanism, not vocabulary
- Score the follow-up, not the opening monologue
When one flag is noise — and when a cluster is decisive
A single buzzword is not a crime. Senior people speak in shorthand under time pressure. The pattern that costs companies money is fluency without mechanism across multiple claims: resume tools they cannot unpack, metrics they cannot defend, and ownership that dissolves when you ask for a personal decision.
Use a simple rule: one soft flag → probe. Two hard flags after follow-ups → protect the specialist calendar. Three or more → reject with notes a hiring manager can audit. Your credibility with engineering rises when you send fewer “nice talkers” and more people who survive depth.
Phrases that should trigger an automatic follow-up
- “We built a scalable architecture…” → “What was your part of the scaling limit you hit?”
- “I’m strong in Kubernetes…” → “Walk me through the last cluster incident you touched.”
- “I improved performance a lot…” → “What was the before/after measurement?”
- “I own the backend…” → “Name one decision you made that others disagreed with.”
- “I use best practices…” → “Which practice, and what happens if you skip it?”
This is the same muscle as screening senior Python developers without coding: the first answer markets; the follow-up measures.
Related reading
- How to screen a senior Python developer without coding
- Follow-up questions that reveal weak candidates
- The silent candidate problem
- Screening DevOps engineers playbook
If you want help generating those second-layer probes live, Hireduce suggests follow-ups against your criteria while you stay on the call — useful when fluency is high and evidence is thin.
FAQ
Is using buzzwords always a red flag?
No. It is a red flag when they cannot unpack one implementation detail they claim to own.
What if English is their second language?
Allow pauses and simpler prompts. Judge the technical content of the follow-up, not accent or speed.
Should I accuse someone of bluffing on the call?
No. Stay curious: “Help me understand your part in that.” Document evidence. Decide after.