IT Interviews Have Become Exams That Even Experienced Developers Struggle to Pass

I hire people all the time. For all kinds of positions and roles. I also need to grow people within my team, helping them try themselves in roles completely unfamiliar to them. Perhaps I'm just lucky, and things work out for me 9 times out of 10. There are failures, which can almost always be explained by at least two factors: the person's unaccounted-for background and their plain burnout.

I'm well-versed in observing people and their behavior in teams. I'd guess that besides luck, I have some innate ability to see potential in people. All of this helps me build reliable teams capable of solving a wide variety of problems.

So, this article is about hiring people for a team. About my past beliefs and my updated beliefs in the present. I hope my article will help someone reconsider their views. Even if it's just a couple of people.

Anyway, it so happened that about 10 years ago I unknowingly became a team lead for the first time and started participating in hiring alongside the CTO at the time. The CTO was very strict and demanded from candidates not just confident knowledge, but an understanding of Computer Science fundamentals. It seemed logical. Besides simple questions about technologies and tools, he asked questions about algorithms, various brain-teaser problems. Sometimes we even gave test assignments and held live coding sessions back then. It's important to note that live coding 10 years ago wasn't a Zoom call — it was a situation where they handed you a laptop and you actually typed code. Writing on a whiteboard or paper wasn't typical, although it did happen a couple of times. It might sound cringeworthy now, but 10 years ago it was perfectly real: you could be asked to explain a one-liner bash script handwritten on a sheet of A4 paper.

Hiring usually consisted of 1 or at most 2 stages. HR would call candidates, and they'd come in and interview one after another. Most of the time (at least in our company), candidates didn't even cross paths with each other. HR would pop into the room and say, "Petrov is waiting for you" — and we'd go interview him. By the way, I don't remember there being any problem scheduling 3–5 interviews in a single day. People showed up. We saw them, they saw us. They immediately saw the office and how everything was set up. They saw the atmosphere. Some were surprised by the multi-story profanity coming from the account managers' office (yes, you need to blow off steam after talking to clients — what did you expect), while others noted the cozy coffee area. Back then, few people expected to see private offices for a doctor, psychologist, or massage therapist in the workplace. Unlimited coffee and cookies? Already awesome. Desks and chairs in good shape? Bliss. If anyone reading this is under 25–27, trust me: things used to be all over the place. What's considered the norm now used to be a huge plus for an employer. Although, probably not all offices are cozy even now. But that's beside the point.

Hiring was a process built like taking an exam. The "professor" sits there, asking questions. You try to answer more or less adequately. Success depended heavily on how well the candidate could navigate the dialogue and ask for the question to be rephrased for better understanding. I saw many people who turned red and froze up from the tension. These were different people from 20 to 40 years old. For the first 5 minutes they were energetic, ready for battle, but after a couple of questions from the "examiner" they deflated, and the interview devolved from an "adult–adult" dynamic into a "parent–child" one, where the "child," naturally, was the candidate. I didn't like this even back then. Around the same time, I read a piece by Tatyana Tolstaya about "machismo," where the "cool macho professor" mumbles something under his breath, none of it making sense, but through his demeanor and words he signals that he's superior to everyone present. I didn't like it, but it seemed important to "probe" the candidate that way. To understand their strengths and weaknesses. To determine the boundaries of their knowledge.

A few years later, working at a different company where I could structure the interview and its requirements however I wanted, HR still did the initial profiling (or screening) and passed resumes to me. I don't remember why (maybe because I showed up to the interview after a very wild night and hadn't prepared any questions), but I didn't conduct it the way I used to: with academic interrogation and "grilling." No olympiad problems, "round manhole covers," or intellectual ping-pong with a person who wasn't even given a racket. I started asking about what interested them. I told them about the tasks we were hiring for. I talked more than the candidate. I shared information, asked for opinions. It wasn't a test or an exam. Yes, I made short notes on a sheet of A4, but when I saw the person getting tense about it, I'd say directly: "My memory isn't great, there are many more interviews ahead, I just want to remember our conversation." I communicated the way I'd want someone to communicate with me. Of course, I noted the important points the candidate mentioned. In a relaxed environment, a person opened up better. They themselves talked about their shortcomings and gaps. This turned out to be very useful: the interview didn't turn into idle chatter, but it still made it clear whether the candidate was a fit. Using this approach, I assembled excellent teams.

Later I read a note about how in negotiations it's best to maintain a "I'm OK — you're OK" position. Even later I realized: most "grilling interviews" are conducted where there are fears of losing your position to more skilled candidates. The IT industry has changed dramatically over the last 10–15 years. It used to be far from ultra-popular. All sorts of people ended up there, most often simply out of curiosity. There were best practices, frameworks, patterns, and algorithms even back then. Fundamentally, nothing has changed. Tools got better in some ways, worse in others. New roles appeared (for example, instead of a sysadmin there are now various Ops roles). That's normal. What became abnormal is something else: the requirements and "exams" at interviews have gotten more complex and are no longer comparable to actual tasks.

Recently I was talking with a former colleague whom I once hired. He complained that with his level of experience, it had become hard to pass the formal parts of interviews. I don't want to name brands — you already know who I'm talking about. "In open combat" he would calmly outperform and crush all interviewers with their live coding and olympiad problems. But almost nobody gave feedback and nobody ever asked about his real projects. He didn't understand why HRs ask about RPS and architectural decisions, listen to his case studies — and then none of it is taken into account at subsequent stages. Yes, sometimes he wasn't ready to break down a problem on the spot. That's how the brain works: you can't always answer instantly. You need to think, look something up. An interview is not an exam, but over the last 10 years that's exactly what "effective managers" have turned it into. You can spend 10–15 years building massive systems, be a generalist, but if during the technical interview you can't instantly write a brute-force hash algorithm or solve a LeetCode problem, everything gets zeroed out. It's incredibly demotivating. My colleague said: "It's as if they're deliberately protecting themselves from experienced specialists, so they don't accidentally create a sort of vendor lock-in on a developer."

Of course, fundamental knowledge is important. It's great when a candidate for an engineering position has excellent math skills, knows algorithms, and can write any code in the target language without an IDE, let alone an LLM. But that's not as important as having a sharp mind and real results behind you, which an adequate interviewer can evaluate by asking a few targeted questions — if they're willing to do so. Without live coding, without dunking a candidate with 10+ years of real production experience into problems that have nothing to do with real business cases, where 90% of the time is spent far from actual code, algorithms, or anything of the sort. From the modern employer's perspective, everything must be solved on camera, in the shortest time possible, without even the right to open your own wiki that you've been building all these years while accumulating experience. One mistake and you've made a mistake, as they say.

— Unfortunately, we're not ready to invite you to the next stage at this time, as we've decided to go with another candidate. We wish you the best of luck in your job search and career.
— Well, thanks for the feedback. You know best — after all, you're experienced developers and people-savvy HRs.
— Who told you that?
— Well, you're the ones conducting the interview, watching how I write code, and asking smart questions. You came up with such problems — I wouldn't even have guessed you could make a question so complicated with such a simple answer.
— Developers like me got into the company before HRs invented career ladders and annual assessments. You're a gullible donkey, Mr. Pepperdyne. The fact that I'm on the other side of the screen asking you questions doesn't make me an experienced engineer. You haven't even seen my code. I'm a fraud, and you're a fool.

As you've gathered, my opinion about multi-stage hiring processes and requirements has changed. Of course, there are tasks that require complex interviews and specialized skills. Hiring a programmer who has only written WordPress plugins (which, by the way, deserves separate respect for their patience) for a position developing high-load applications would be, to put it mildly, wrong. Such requirements can be specified in the job listing upfront. People know how to evaluate themselves, and when they see that a job listing explicitly states specific things rather than abstract "experience with asyncio/threading and ability to work with Redis/ClickHouse," they'll think twice before applying "just to try their luck." Write explicitly: "We have this many RPS, these are our challenges, so we want this kind of specialist." All of this can and should be detailed. At the same time, anything more than two meetings is overkill and a blatant waste of time. No IT company is worth spending that much time and nerves on, only to get a demotivation kick in return. Pouring fuel on the fire are young HRs who don't understand technology and only react to trigger words, but that's a whole other story.

Honestly, I don't really expect the situation to change. Most likely, corporations will keep tightening the screws, creating additional hurdles, and inflating their own value with exams — no less difficult than admission to the toughest math department at a university — so that afterward the candidate feels greater value from having overcome all those obstacles and doesn't bail after the first meetings with somewhat inadequate management, a toxic team, and absolutely idiotic tasks like recoloring buttons in an application written on a framework by people who simply found it interesting to build, and who very likely would never have passed such interviews themselves.