Red Flags in Hiring: A Lead's Perspective

When You Start Hearing People, Not Words

Several hundred interviews over the course of a career. I started like everyone — with design patterns and SQL joins. I was convinced: find a technically strong person, and everything else will follow.

The turning point — a project building an event-driven platform. I hired a developer who, during the technical interview, laid out microservices architecture so brilliantly you wanted to give a standing ovation. Deep knowledge of Kafka, Flink, understanding of distributed systems at a level you rarely encounter. We made the offer the same day.

Three months later, the team was in a state of cold war. The person sabotaged any decision made without him. He turned code reviews into public executions. Junior developers were afraid to commit. One quit. Technically — a brilliant specialist. For the team — a cancer cell.

Since then, I listen not to answers, but to patterns. Not what the candidate says, but how.

An important caveat: a red flag is not a verdict. It’s a signal of a possible values mismatch. The same person can be toxic in one team and a star in another. But if you’re building a specific culture — you need to recognize what won’t fit.

Archetype 1: The Wounded Hero

You recognize them by how much they talk about their previous workplace — and how little of it is positive. The last manager was incompetent, the team didn’t understand their ideas, the company didn’t appreciate their contribution.

The problem isn’t negative experience — that happens. The problem is the stance. The Wounded Hero doesn’t reflect: they blame. Ask “what would you have done differently?” — the answer boils down to “well, if they’d listened to me…”

Why this is dangerous for the team. The Wounded Hero brings their resentment along. Every conflict is interpreted through the lens of the past. Manager made a decision without a meeting — must mean they don’t value them again. A colleague disagreed with an approach — must mean nobody listens again. You get an employee who’s fighting not current problems, but ghosts from their previous job.

How to spot it. Ask them to describe their most challenging project. Listen not to the facts, but to the emotional coloring. If eighty percent of the story is about obstacles created by other people, rather than solutions the candidate found — that’s a signal.

Archetype 2: The Lone Coder

“I’d just like to write code. Standups, retros, planning sessions — all that stuff gets in the way of real work.” Sounds like healthy pragmatism. In practice — a ticking time bomb.

The Lone Coder doesn’t want to be part of a team. They want to be a contractor: give me a task — don’t bother me until the deadline. In a three-person startup, this works. In enterprise development with dozens of interdependent services and multiple adjacent teams — it doesn’t.

I had one like this. Strong, fast, solved tasks twice as quickly as everyone else. Over three months, he wrote a service that nobody on the team could maintain. Zero documentation. Tests — “this is obvious code, why would you need tests.” When he went on vacation and a bug was found in his service, the team spent a week understanding code that one person had written in a day. Negative ROI.

How to spot it. Ask about code review. If the person views reviews as a formality or, worse, as an attack on their competence — that’s a signal. A good team player sees review as a tool, not an evaluation.

Archetype 3: The Ethically Flexible

The hardest to spot, because at first glance — the ideal candidate. Proactive, results-oriented, ready to take responsibility.

The Ethically Flexible is someone who will skip testing to meet a deadline. Hide a bug from a client to avoid ruining a demo. Sign off on a load testing report without actually running the tests. In banking development, where the cost of a mistake is real money belonging to real people, this approach leads to incidents.

There was a case. A developer from an adjacent team signed off on load testing. The test was run — at ten percent of target load. The report said “testing passed successfully.” Technically — true. In substance — a lie. In production, the system went down in the first hour. The postmortem lasted longer than the outage itself.

How to spot it. A situational question: “Deadline is tomorrow, feature isn’t fully tested, the client is waiting. What do you do?” The right answer involves communication and expectation management. “Ship it, fix it later” — that’s a signal. “I’ll call the client and negotiate a delay” — that’s maturity.

Archetype 4: The Unfocused Star

Knows React, Vue, Angular, Svelte. Tried Rust, Go, Elixir. Pet project in Haskell. Previous job — implementing Kubernetes, before that — CI/CD, before that — databases. The resume is impressive. The depth — isn’t.

The Unfocused Star collects technologies. Every six months — a new stack. No topic has the depth needed for production decisions.

Why this is dangerous. Enterprise demands depth, not breadth. When Tarantool degrades under load — you need someone who knows the internals, not someone who “played with it at a hackathon.” When a Flink job doesn’t meet the SLA — you need an expert, not an enthusiast.

There was a specific case. A candidate for a senior developer position, resume listing Kubernetes, Terraform, Ansible, three clouds, two languages. When asked “tell me about your most complex deployment,” the answer was a story about configuring a Helm chart for a simple CRUD service. Okay, I dig deeper: “What issues did you have with liveness/readiness probes?” — “Well, we configured the standard ones, seemed to work.” “And if a pod doesn’t come up after deployment — how do you debug it?” — a long pause, then a pivot to talking about how he’s currently learning Rust. The person had assembled an impressive collection of tools and didn’t command any of them at the level needed to solve real production problems. In six months, he’ll switch stacks again and add another line to his resume.

How to spot it. Take any technology from the resume and dig two levels deep. Not “what is Kafka,” but “how does consumer group rebalancing work and when does it become a problem.” The Unfocused Star starts drifting after the first follow-up question.

Archetype 5: The Results Phantom

The most dangerous, because the most elusive. A presentation master. Beautifully narrates large-scale projects, hits the right buzzwords, spins a narrative of personal heroism saving the day.

Start asking for specifics — “what was the SLA?”, “how many events per second?”, “what alternatives did you consider?” — and the answers melt away. “Well, it was a big project…”, “I don’t remember the exact numbers…”, “I was responsible for the overall direction…”

I once interviewed a candidate for a senior position. Resume — stellar: distributed systems, high-load services, architectural decisions. Twenty minutes of a brilliant narrative. Then I asked: “You mentioned you optimized database queries. Tell me about the hardest case — what was the query plan before and after?” Pause. “Well, we used indexes…” — “Which ones exactly?” — “B-tree…” — “And why not a partial index? The data had status filtering, as you described.” Another pause. It became clear: the person managed the project where all this happened. But he wasn’t the one who did it.

How to spot it. The STAR method — Situation, Task, Action, Result. Ask for specifics: numbers, metrics, timeline. A real expert remembers details of the projects they lived through. A Phantom doesn’t — because they participated at a different level.

Archetype 6: The Professional Interviewee

A separate breed I’ve identified recently. A person who treats interviews like a sport. Perfect answers. Flawless STAR structure for every question. Rehearsed stories for every question type.

The problem: behind the polished presentation, you can’t see the real person. Ask a non-standard question — a momentary confusion, then a switch to the nearest prepared answer. Like a chatbot that didn’t understand the prompt and responds to the closest match.

I once interviewed a candidate who answered so smoothly it made me uneasy. Every answer — like from a textbook. Perfect structure, deliberate pauses, even self-deprecation was pre-scripted and rehearsed. I asked: “Tell me about a time you screwed up on a project and couldn’t fix it.” He started telling a story — but “screwed up” smoothly transitioned into “made an unpopular decision that ultimately turned out to be right.” I pressed: “No, actually screwed up. No happy ending.” Fifteen seconds of silence. Then — “Well, there probably was a case like that, but I don’t remember the details.” A person who can’t remember their failures either has never made a mistake (impossible), or has rehearsed their self-presentation so thoroughly that real experience is hidden behind the facade.

The detection is simple: ask a question that isn’t on the standard lists. “Tell me about the dumbest decision you made on a project. Not a mistake — specifically a dumb decision that you’re embarrassed about.” A real engineer will think for a moment and tell you. A Professional Interviewee will start spinning the story so that the “dumb decision” turns into a demonstration of their resourcefulness.

A Reflective Approach

I don’t use archetypes as a blacklist. They’re a tool for self-reflection. Over years of hiring, I’ve learned: there’s no such thing as a perfect interview, just as there are no perfect candidates. Every interview is two people trying to figure out in an hour whether they can build something complex together.

Every time I see a red flag, I ask three questions:

1. Pattern or moment? Being nervous in an interview is normal.
2. Incompatible or unfamiliar? Diversity of approaches is a strength.
3. Can I work with this? Some patterns can be corrected through mentorship. Others are fundamental.

I’m not looking for perfect specialists. I’m looking for people who are willing to be co-owners of the outcome. Who see the team as a tool for a shared goal, not just a habitat. Who know how to reflect.

The ability to work as a team, take responsibility, and be honest about problems — you either have it or you don’t. Technologies can be learned. Character cannot.

And one last thing. The most useful question I ask myself after every interview: “Would I want this person making decisions when I’m not around?” Not “can they handle the tasks” — they can, if they’re technically strong. Specifically: do I trust their judgment? Am I comfortable with them talking to the client without my supervision? Mentoring a junior? At 3 AM during an incident, making a decision I’ll learn about in the morning? If the answer is “no” — the tech stack doesn’t matter.

Then again, I’ve been to interviews where I was the Wounded Hero myself. I just didn’t notice at the time.

---

Original article: Red Flags in Hiring: A Lead’s Perspective on Habr

— Vladimir Lovtsov