Where candidates fail IT interviews: data from interview reviews
From 20.6 thousand interview reviews: success rate by interview type and the topics most often rated weak. Kubernetes, SQL, message brokers and answer structure.
After a bad interview it feels like everything went wrong at once. In practice, weak spots repeat from person to person, and the list is fairly short. It helps to know it in advance: you can test yourself on these topics before the call and not after the rejection.
We put together anonymized statistics from interview reviews in Sobes. The most common weakness turned out to be non-technical: the structure and clarity of answers. Among technical topics, Kubernetes sags most often. It was rated weak in half of the reviews where it came up.
Where the data comes from and how we counted
After a meeting, Sobes produces an AI review: it identifies the interview type, extracts the questions asked, scores the candidate's answers for correctness, completeness and clarity, and builds a competency map where each topic touched is marked strong or weak. We took 20.6 thousand such reviews and computed aggregates: the average success rate by interview type, and for each topic the number of reviews where it was assessed and the share where it was rated weak. The statistics contain no personal data and no individual interviews. Keep the limitations in mind. These are a model's scores, not decisions by hiring teams. A topic gets into a review only if it was asked about, so the weak share is counted from reviews with that topic, not from all of them. The model words topic names itself, and one topic is recorded in several variants ("Kafka", "Kafka and RabbitMQ", "message brokers"), so the sums below are approximate. And the sample leans toward people who use the service, most of them interviewing on the Russian market.
Success rate by interview type
| Interview type | Average success rate |
|---|---|
| HR screening | 83% |
| Behavioral | 73% |
| Mixed | 71% |
| Technical | 61% |
| System design | 52% |
The fewer ready-made answers a conversation allows, the lower the result. An HR screening is made of predictable questions, and people get through it confidently. In system design you have to drive the reasoning yourself for forty minutes, and the average success rate there is barely above half.
Communication and answer structure
This is the most common weakness in the whole sample. The topic is recorded in five wordings ("communication and structured answers", "structuring answers", "clarity of answers" and similar). Together they were assessed in about 1.2 thousand reviews and rated weak in roughly a third of them. The share varies a lot between wordings, so it can't be stated more precisely.
It usually looks like this: the person knows the answer but starts from far away, lists everything they remember and never gets to the point. The fix is order: the conclusion in one sentence first, then two or three supporting facts, then an offer to go deeper.
Yes, I have, two years in production. I set up a cluster from scratch and handled version upgrades. Happy to go into detail on either part.
In ten seconds the interviewer has an answer and chooses where to dig. A recording is a good way to practice: turn on a voice recorder, answer five questions, and listen for the second at which the main point arrives. How to review answers like these after a bad call is covered in Failed a job interview? What to do next.
Infrastructure
| Topic | Reviews where assessed | Rated weak |
|---|---|---|
| Kubernetes | 323 | 51% |
| Linux | 59 | 51% |
| CI/CD | 193 | 39% |
| Docker | 195 | 35% |
| Docker and Kubernetes | 116 | 28% |
| Ansible | 159 | 21% |
Kubernetes has the most reviews with a weak rating of any technical topic: 166. A likely reason shows in the bank's questions, which are about operations: experience deploying and running clusters and how resource limits work. If you deploy through a ready-made pipeline, questions like these quickly reach the edge of your experience.
What to do: walk your own service's path by hand. What happens between a commit and a pod, where the limits come from, what happens when a readiness probe fails, how to read logs and events. Self-check questions are in the DevOps section.
Databases
| Topic | Reviews where assessed | Rated weak |
|---|---|---|
| Normalization | 44 | 57% |
| SQL window functions | 78 | 40% |
| SQL and JOIN | 75 | 39% |
| Transaction isolation levels | 152 | 34% |
| SQL in general | 334 | 33% |
| Transactions and ACID | 160 | 26% |
| Indexes | 125 | 26% |
| PostgreSQL indexes | 154 | 24% |
By number of weak ratings, SQL comes right after Kubernetes. There is a visible gap between explaining and writing: general questions on transactions and ACID and indexes go better than window functions and JOINs, where you have to compose a query. Isolation levels are weak in every third review: names are not enough here, since the interviewer usually asks you to show an anomaly with two transactions.
What to do: write queries by hand. The SQL trainer has tasks for that. For isolation levels, open two consoles and reproduce a non-repeatable read and a phantom read yourself.
Message brokers
Kafka, RabbitMQ and brokers in general are recorded in five wordings. Together that is about 700 reviews, with a weak rating in roughly a third. For individual wordings the share runs from 27% for "Kafka and RabbitMQ" to 49% for RabbitMQ.
Test yourself on delivery guarantees: what happens on redelivery, how to keep ordering, what to do with a message that failed to process. Related topics sit nearby in the data: idempotency of HTTP methods (weak in 48% of reviews, example question) and the transactional outbox (29%). Prepare one example from your own work: what the failure scenario was and how you made processing safe to retry.
System design
This interview type has the lowest average success rate, 52%. At the same time the topic "microservice architecture" is rated weak in only 15% of 318 reviews, while "architectural design" is weak in 53% of 36. Most people can talk about microservices in general. Designing a specific system under constraints is noticeably harder. How to split the 45 minutes is described in the post on system design answer structure, and you can practice in the trainer with a canvas.
Non-technical topics
| Topic | Reviews where assessed | Rated weak |
|---|---|---|
| Knowledge of the company and motivation | 42 | 69% |
| Career planning | 38 | 68% |
| Preparing questions for the employer | 42 | 57% |
| Motivation and fit for the vacancy | 53 | 42% |
| Salary expectations | 191 | 16% |
| Self-presentation and describing experience | 172 | 16% |
The top three rows rest on a small number of reviews, about forty each, but the picture is telling. Most people handle the story about themselves and the salary question. What fails are the questions that need preparation for a specific company: what it does and why you want to join it, what you want to be doing in a couple of years, what you want to ask. General "motivation and career goals" is weak in only 17% of 346 reviews: talking about yourself is easier than talking about someone else's company.
These are the cheapest topics to fix. One evening is enough:
- twenty minutes on the company's site, product and vacancy, and one sentence about what caught your attention. Examples are in Why do you want to work here;
- an answer about your plans for two or three years, tied to this role: Where do you see yourself in three years;
- three questions for the employer, written down in advance: Questions to ask the employer.
How to test yourself
- Go through the tables above and mark the topics that are in your stack and in the vacancy. For each, answer out loud one "how does it work" question and one "what did you do with it" question.
- Do a mock interview for your stack: the final review shows which answers sagged.
- If you already take interviews with Sobes, open the Progress screen. It shows the same thing for your own reviews: success rate over time and topics that were weak in two or more reviews. You can start a mock on those gaps from there.