--- slug: red-flags-technical-interviews-candidate-bluffing title: "Red Flags in Technical Interviews: 12 Signs a Candidate Is Bluffing" description: "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." publishedAt: "Jul 21, 2026" updatedAt: "Jul 21, 2026" author: "Denys Muzyka" readingTime: 11 tags: - Interview Red Flags - Technical Screening - Recruiter Training - Hiring - Bluffing canonical: https://www.hireduce.cloud/blog/red-flags-technical-interviews-candidate-bluffing --- 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](/blog/silent-candidate-problem) - 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 1. Pick one resume claim (tool, project, or metric) 2. Ask for a concrete walkthrough with their personal role 3. Change one constraint (“what if traffic 10x?” / “what failed in v1?”) 4. Listen for mechanism, not vocabulary 5. 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](/blog/how-to-screen-senior-python-developer-without-coding): the first answer markets; the follow-up measures. ## Related reading - [How to screen a senior Python developer without coding](/blog/how-to-screen-senior-python-developer-without-coding) - [Follow-up questions that reveal weak candidates](/blog/follow-up-questions-reveal-weak-candidate-five-minutes) - [The silent candidate problem](/blog/silent-candidate-problem) - [Screening DevOps engineers playbook](/blog/screening-devops-engineers-non-technical-recruiter) If you want help generating those second-layer probes live, [Hireduce](https://www.hireduce.cloud/) 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.