Red Flags in Hiring, Through a Lead's Eyes

When You Start Hearing People, Not Words

Several hundred interviews over a career. I started out like everyone else — with design patterns and SQL joins. I was sure of it: find a technically strong person, and the rest will take care of itself.

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

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

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

An important caveat: a red flag isn't a verdict. It's a signal of a possible values mismatch. The same person can be toxic on one team and a star on another. But if you're building a specific culture, you need to be able to recognize what won't fit into it.

Archetype 1: The Wounded Hero

You recognize him by how much he talks about his previous job — and how little of it is good. The old manager was incompetent, the team didn't get his ideas, the company didn't value his contribution.

The problem isn't the negative experience — that happens. The problem is the stance. The Wounded Hero doesn't reflect; he blames. Ask him "and what would you have done differently?" and the answer boils down to "well, if only they'd listened to me...".

Why it's dangerous for the team. The Wounded Hero brings his grievance with him. He interprets any conflict through the lens of the past. The manager made a decision without a meeting — that means they don't value him, again. A colleague disagreed with his approach — that means they're not listening, again. You end up with an employee who's at war not with the current problems but with the ghosts of his previous job.

How to spot it. Ask him to tell you about his hardest project. Listen not to the facts but to the emotional coloring. If eighty percent of the story is a description of obstacles created by other people, rather than solutions the candidate found — that's a signal.

Archetype 2: The Lone Coder

"I just want to write code. Calls, retros, planning sessions — all of it gets in the way of the work." Sounds like healthy pragmatism. In practice — a time bomb.

The Lone Coder doesn't want to be part of a team. He wants to be a hired contractor: give me a task and don't touch me until the deadline. In a three-person startup, that works. In enterprise development with dozens of dependent services and several adjacent teams — it doesn't.

I had one. Strong, fast, solved tasks twice as quickly as everyone else. In three months he wrote a service that no one on the team could maintain. Documentation: zero. Tests — "it's obvious code, why bother with tests." When he went on vacation and a bug turned up in his service, the team spent a week untangling code that one person had written in a day. The economics were negative.

How to spot it. Ask about code review. If the person treats review as a formality or, worse, as an attack on his competence — that's a signal. A good team player sees review as a tool, not a grade.

Archetype 3: The Ethically Flexible

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

The Ethically Flexible is the person who'll skip testing to make a deadline. Who'll hide a bug from the client so as not to spoil the demo. Who'll sign off on a test report without having run 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 a load-testing report. The testing had been done — at ten percent of the target load. The report said "testing passed successfully." Formally, true. In substance, a lie. In production the system went down within the first hour. The post-mortem lasted longer than the outage itself.

How to spot it. A situational question: "The deadline is tomorrow, the feature isn't fully tested, the client is waiting. What do you do?" The right answer involves communication and managing expectations. "We'll ship it and fix it later" is a signal. "I'll call the client and negotiate a slip" is maturity.

Archetype 4: The Unfocused Star

Knows React, Vue, Angular, Svelte. Has tried Rust, Go, Elixir. A pet project in Haskell. At his last job he rolled out Kubernetes, before that CI/CD, and before that databases. The résumé is impressive. The depth is not.

The Unfocused Star collects technologies. A new stack every six months. In not a single area is there enough depth for production-grade decisions.

Why it's dangerous. Enterprise demands depth, not breadth. When Tarantool degrades under load, you need someone who knows its internals, not someone who "poked at it during a hackathon." When a Flink job blows past its SLA, you need an expert, not an enthusiast.

There was a specific case. A candidate for a senior-developer role, an imposing list on the résumé: Kubernetes, Terraform, Ansible, three clouds, two languages. Asked to "tell me about your hardest deployment," he answered with a story about configuring a Helm chart for a simple CRUD service. Okay, I dig deeper: "What problems did you have with liveness/readiness probes?" — "Well, we set up the standard ones, seemed to work." "And if a pod won't come up after a deploy — how do you debug it?" — a long pause and a pivot into how he's learning Rust on the side. The guy had assembled an impressive collection of tools and didn't command a single one at the level needed to solve real production problems. In six months he'll switch stacks again and add one more line to his résumé.

How to spot it. Take any technology from the résumé and dig two levels down. Not "what is Kafka," but "how does consumer-group rebalancing work and when does it become a problem." The Unfocused Star starts floundering after the first follow-up question.

Archetype 5: The Results Phantom

The most dangerous one, because he's the most covert. A master of presentation. He tells beautiful stories about large-scale projects, the right buzzwords, a narrative of personally saving the day.

You 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 role. The résumé was out of this world: distributed systems, high-load services, architectural decisions. Twenty minutes of a brilliant account. Then I asked: "You mentioned you optimized database queries. Tell me about the hardest case — what was the query plan before and after?" A pause. "Well, we used indexes..." — "Which ones exactly?" — "B-tree..." — "And why not a partial index? The data was filtered by status, like you described." Another pause. It became clear: the person had led a project where all of this happened. But he wasn't the one doing it.

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

Archetype 6: The Professional Interviewee

A separate species I singled out recently. A person who does interviews as a sport. Perfect answers. Proper STAR structure for every question. Pre-canned stories for every type of question.

The problem: behind the polished presentation you can't see the real person. Ask a non-standard question and there's a split second of confusion, then a switch to the nearest prepared answer. Like a chatbot that didn't understand the prompt and answers the closest similar one.

I once interviewed a candidate who answered so smoothly it made me uneasy. Every answer straight out of a textbook. Perfect structure, well-placed pauses, even the self-deprecation was pre-written 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 in it "screwed up" smoothly morphed into "made an unpopular decision that turned out to be the right one in the end." I pressed: "No, actually screwed up. No happy ending." Fifteen seconds of silence. Then — "Well, there was probably something like that at some point, but I don't remember the details." A person who doesn't remember his own failures either never made a mistake (impossible) or has rehearsed his self-presentation so thoroughly that the real experience is hidden behind the façade.

Easy to spot: ask a question that isn't on the standard lists. "Tell me about the dumbest decision you made on a project. Not a mistake — a genuinely dumb decision you're embarrassed about afterward." A real engineer will think for a moment and tell you. The Professional Interviewee will start spinning the story so that the "dumb decision" turns into a demonstration of his resourcefulness.

Archetype 7: The External Locus

The most inconspicuous, because on the surface he often looks like a reasonable person. Calm, no grudges, no aggression — he just always has an explanation. And the explanation is always on the outside.

"The manager didn't explain the task." "Your processes are poorly set up." "I would have done it, but that's not how things are done here." "Everything was already broken before I got there." Sounds like constructive criticism. But the pattern is the same: there's no zone of personal control. Not because the person is lazy — his internal model is simply such that events happen to him, not by his will.

The difference from the Wounded Hero: the Hero relives specific grievances with an emotional charge, whereas for the External Locus it's just his picture of the world, calm and stable. He can work for years without creating conflicts, but every mistake will be routed to the system, to a colleague, to circumstances — never to himself.

Why it's a problem. In banking development, where an incident requires a root cause analysis and a specific responsible party, this kind of person paralyzes the investigation. Not maliciously — he sincerely describes events as they "happened." The problem is that the team can't learn and change based on an analysis that has no subject.

How to spot it. Ask him to tell you about a failed project. Listen to who the subject of the sentences is. "We didn't make it in time" is fine. "We weren't warned, the deadlines were set unrealistically, the architecture was wrong from the start" — every sentence without an "I" and without an action. Once is a situation. Three times in a row is a pattern.

A Reflective Approach

I don't use these archetypes as a blacklist. They're a tool for reflection — for myself. Over years of hiring I've realized: there's no such thing as a perfect interview, just as there's no such thing as a perfect candidate. Every interview is two people trying, in the space of an hour, to figure out whether they can build something complex together.

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

1. A pattern or a moment? Someone being nervous in an interview is normal.
2. Incompatible or just unfamiliar? A diversity of approaches is a strength.
3. Can I work with this? Some patterns can be corrected with mentoring. Others are fundamental.

I'm not looking for perfect specialists. I'm looking for people who are ready to be co-owners of the result. Who see the team as an instrument for a shared goal, not as a habitat. Who are capable of self-reflection.

The ability to work in a team, to take responsibility, and to talk honestly about problems is something you either have or you don't. Technologies can be learned. Character can't.

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 "will he handle the tasks" — he will, if he's technically strong. But specifically: do I trust his judgment? Am I ready for him to talk to a client without my supervision? To mentor a junior? To make a decision at three in the morning during an incident, one I'll only find out about the next day? If the answer is "no," it doesn't matter what his stack is.

Then again, I've sat through interviews where I was the Wounded Hero myself. I just didn't notice.

If the topic of hiring and managing teams resonates with you, I run mentoring for aspiring tech leads, where we cover hiring, retention, and building culture, among other things. And if you're the kind of person who wants to build teams on the principles of co-ownership, take a look at how Digital Artel is set up.

---

Original article: Red Flags in Hiring, Through a Lead's Eyes — on Habr

Yours, DPUPP