Preamble

Over the past few years, I have developed a clear feeling that recruitment in IT is broken for many reasons, one of them being the incompetence of the people involved. Technical interviews conducted by IT specialists themselves raise just as many questions, often for exactly the same reasons.

This is not particularly dangerous by itself. The system has worked this way for years, and there are currently no signs that it is about to collapse. That does not change the fact that almost everyone involved regularly shoots themselves in the foot. The system remains functional because the system itself is resilient, not because its individual participants are doing a good job.

A Small Clarification, Part 1

I will not discuss the problem of so-called “wolves”—a Russian IT term for candidates who game the hiring process, often by inflating or fabricating experience—for several reasons.

First, I do not really see them as a problem. I see them less as criminals breaking into someone else’s house and stealing money and more as penetration testers or white-hat hackers who explicitly expose holes in the system and loudly point them out. If you ignore those warnings, that is your problem, not theirs.

Second, these people are dealing with a completely different problem. They want to live well and earn money within a broken hiring system. I want to discuss the problem of finding a good specialist.

A “wolf” != a bad specialist, and a bad specialist != a “wolf.” Putting labels on people has never led to anything good. Look at what a person can do, not at their worldview.

A Small Clarification, Part 2

I will discuss only technical interviews here. I have never had serious problems with soft-skill interviews.

Yes, there are strange questions that are painful and unpleasant to answer. For example: “Name your three biggest weaknesses.” You have to twist yourself into a pretzel to land in the category of candidates whose “vibe” the HR person likes.

But you can prepare for interviews like that. You can work through every question, even the stupidest ones, and eventually learn to pass these interviews through experience without too much trouble.

So HR interviews are not currently a major concern for me, and I do not think they are what breaks the interview process as a whole.

Why Is Everything So Bad?

This is a complex question. Every company runs interviews differently.

Some companies, such as Yandex, have a million stages where they try to wear you down so they can eventually offer you a below-market salary with an explanation like:

“You performed badly during stage 2,586, where you had to balance on a tightrope, juggle chainsaws, and recite War and Peace from memory. Therefore, we believe this offer is justified.”

I am not going to discuss this type of interview.

Other companies—something like 99%* of IT companies—interview you like a second-year university student taking an exam. They ask you to define terms that you learned specifically for this exam and may use once in your actual work if you are lucky.

This second type is what I want to discuss. It makes more sense to focus on it simply because these interviews are more common. The problems are also much easier to see.

That brings us to the main issue.

Companies Are Not Looking for Suitable Specialists

When you are hiring a specialist, you need to make compromises. You cannot hire someone who is cheap and competent while also hiring them quickly.

If your requirements are high, hiring cheaply and quickly becomes practically impossible. Some companies accept these trade-offs. Others shout to the entire world that everything is unfair, everyone is against them, and there is nothing they can do.

Technical interviews are complicated, and you need to understand what you are actually trying to evaluate.

My main argument is this: standardized questions do not filter out bad specialists, just as university exams do not filter out bad students.

Both can simply memorize the answers without understanding the meaning of the words they repeat during the interview or exam. They may even sound extremely convincing. But once real work begins, the probability of success becomes like the probability of meeting a living dinosaur in the street: fifty-fifty.

The other side of this is that companies often do not actually need someone capable of understanding an unfamiliar system independently, even if they have never worked with one before or have completely fabricated their experience.

It is relatively rare for a new developer to be forced to fix production during peak traffic at any cost. I would not say that even genuinely experienced specialists could always handle that without problems. There is no direct one-to-one relationship here.

If managers working on fairly ordinary projects still want to play it safe and hire someone one level stronger than the job actually requires, they need to accept that this person will cost more than an ordinary employee.

Naturally, if you are hiring an independent developer so you can leave them to build a service and return later to find a working product with solid architecture and few bugs, not everyone will be suitable for the role.

A beginner may be capable of writing the service itself but will probably struggle to maintain its architecture. In that case, the interview process needs to be different.

How exactly? I will explain that later.

Why Has Nobody Solved This?

Part of the answer was already covered in the preamble. The main reason is incompetence.

It is common for a developer to conduct a technical interview for the first time without having any existing list of questions. They have to invent and assemble the interview themselves. In most cases, they will find a question bank, copy questions from it, and continue using them in every future interview.

Incompetence creates more incompetence. People repeat bad practices because they have never seen another way.

It is similar to beginner programmers. They have no idea what good application architecture looks like. They do not even know that they do not know. So they move forward by instinct, build whatever they can, and may never reach a good architecture at all.

I do not blame developers for being bad at work that is NOT their actual job.

Ideally, a company should have a separate specialist responsible for conducting technical interviews. I understand that only top-tier companies can afford that.

But if you are a developer who has agreed to conduct interviews, be prepared to do the job well. Otherwise, you become part of the problem.

We should also look beyond the people conducting interviews and pay attention to the people deciding who needs to be hired.

“No clear specification, no clue what result you will get” describes hiring fairly well.

If the hiring process is not designed properly and the hiring manager simply wants everyone to do everything well and avoid doing anything badly, standardization, indifference, and ATS filters take over.

A fish rots from the head, and hiring inside a company rots from the hiring managers.

HR then writes abstract vacancies based on abstract descriptions. Hundreds or thousands of people apply. This is not only because the descriptions are generic. It is also a result of the broader hiring crisis and the market being heavily tilted toward employers.

The HR person, probably just as unqualified for this particular system—have you ever seen serious university programs dedicated to HR mastery? Neither have I—connects an ATS, enables automatic filters, and slowly works through the applications that the system happened to like.

Candidates are not idiots. They understand exactly what is happening and respond with similar systems that rewrite their résumés for ATS filters.

This toad-versus-viper fight will continue until someone breaks the cycle.

How? At this point, who the hell knows.

What Can Be Done?

By now, it should be clear that asking the same stupid questions in every interview is not a solution.

So what can be done instead?

You probably cannot avoid basic questions about the candidate’s current technology stack. There is one good reason for them: they allow you to quickly reject someone who does not know the fundamentals of their own stack.

The questions should progress from easy to medium difficulty. The closer they get to obscure or excessively difficult trivia, the less they reveal about the candidate’s practical knowledge. Usually, they only show that the candidate memorized these exact questions or has studied the language in unusual depth. In my experience, the second case is much less common.

This approach saves a lot of time for both you and the candidate. You can cover the fundamentals in 15–20 minutes and stop there if necessary instead of moving on to more practical questions.

In this context, practical questions come in two types:

1. Questions directly related to the work the candidate will do at the company.
2. Questions that help identify people who do not actually have the experience required for the role or described in their résumé.

These may look like the same point, but they are not.

In the first case, you ask questions related to your domain.

For example, if you are building a payment system, it may be critically important to know whether the candidate has worked with similar systems, what they know about transactional guarantees and two-phase commits, how two-phase commits can sometimes be avoided, and many other things.

Yes, I said earlier that a candidate does not necessarily need experience in your exact domain. What matters is whether they understand how to work.

These domain-specific questions are necessary when you need an expert in that particular field rather than someone who is generally capable of doing the work. Those are different things. Do not confuse them.

In the second case, you ask questions about the experience listed in the candidate’s résumé: their previous job, their role in the team, their achievements, and their failures.

This may sound like a soft-skill interview, but it is not.

The difference is that you need to go deep. Ask follow-up questions, clarifying questions, and questions with a catch.

Do not simply ask what the candidate generally did at work. Grab every detail you can.

Do not stop after hearing that they optimized database performance. Ask exactly how they did it, how they arrived at that solution, who helped them, and how they measured the result.

In my opinion, this second type of question is very difficult to ask when the interviewer has no genuine interest in the conversation.

This brings us back to incompetence, although the problem here is slightly different. It is more about the absence of motivation to ask these questions properly.

I have rarely been asked about my real experience during technical interviews. These questions usually ended with the HR stage and never went any further.

Even when technical interviewers asked about my experience, they rarely went beyond a single follow-up question: “How exactly did you do that?”

That is not enough to identify someone who cannot actually do the thing and merely added it to their résumé.

You need to dig deeper. If the candidate’s story begins to fall apart, that is a warning sign.

At the same time, you should not immediately declare that the candidate is a liar. Nervousness can play a major role.

Even experienced developers can become anxious during interviews despite having genuinely worked with everything listed in their résumé. These people do not spend their lives attending interviews and gliding effortlessly through every conversation.

This creates the possibility of a false negative.

At this point, however, it does not really matter whether the candidate memorized the answers or genuinely knows everything.

There is no reason to keep digging forever or uncover every piece of the candidate’s dirty laundry. If they can explain the experience consistently, avoid contradictions, and speak confidently about it, then they are already suitable for the role.

There remains a small chance that the candidate memorized the entire story but still lacks the intelligence or practical ability to do the job. I would argue that this risk is small enough to accept.

If you want to filter out every single “unworthy” candidate, be prepared to spend a lot of money.

The cost of dismissing one such “genius” after the probation period is probably lower than the cost of building an iron dome around your hiring process.

Afterword

I understand that everything described above may not apply in every situation.

The problem does not affect all of IT. Interviews based on standard questions do work. Services do not fail for millions or billions of rubles, dollars, yuan, or tugriks often enough for every company to rebuild its process. Dissatisfaction may not be high enough to force anyone to act.

This article is not a cry from the heart or a desperate attempt to overturn an established system. I am simply throwing an idea into the discussion.

Maybe some head of <something> will read it, think, “Damn, this really is a problem,” and raise the question of adjusting the hiring process inside their own company.

This may sound as though I am unwilling to stand behind my words and am trying to leave myself an escape route. Or, to put it differently: “Piss on me if you want, just do not hit me.”

But that is not what I mean.

I am only saying that this article does not present the complete picture of hiring. In some places, I simplified things. In others, there are clearly parts I do not fully understand myself, so I decided to leave them out.

I am not abandoning the central idea. I will continue defending the proposed solution unless I collapse under a barrage of genuinely good arguments.**

Notes

* The 99% figure is based on my own impression. The sample consists of interviews in which I personally participated and recorded interviews involving my students. No personal-data laws were violated: there was no video, and the voices were distorted.

** I know how rude and tactless programmers can be. Simply saying “the author is an idiot” is not an argument.

*** The original Russian text was written without the use of neural networks. If you see long dashes or strange phrasing, rest assured that I wrote all of it myself. Yes, I use both em dashes and en dashes. That is normal in professional writing. Do not attack people over perfectly ordinary punctuation.