Middle vs senior developer: the difference in an interview

You apply for a senior role, get through the technical round with no obvious mistakes, and the offer says middle (mid-level). Or the rejection says "not enough depth". It usually means your answers were correct but sounded like an executor's: you said what you did and left out why you did it that way and what came of it.

In an interview, the grade is set by how you reason, and years of experience come second. The interviewer asks the same questions you can find in the Sobes question bank, such as "What was the hardest task you had recently, what was it about, and how did you solve it?" or "Tell me about your role in the team. Do you mentor anyone, delegate tasks, or do tasks get delegated to you?", and from the answer works out how large a problem you can be trusted with.

Five signals that set the grade

Knowledge of technology is not in the table, and that is deliberate. A middle developer with five years of experience may know the framework better than a senior. The difference is that a senior answers "why" before being asked.

How it sounds in answers

A challenging task

Middle answer:

We had a slow report, it took about forty seconds to load. I looked at the query plan, added a composite index, rewrote a couple of subqueries as JOINs. It went down to four seconds.

Senior answer:

Our report for managers took forty seconds to load, so they were exporting data to Excel and working with stale numbers there. First I found out how they use it: it turned out they almost always look at the last month. There were two paths: optimize the query or precompute aggregates. Precomputing would give under a second, but it added an hour of data delay and one more job to maintain. We agreed with the product manager that an hour mattered to them, so I went with the index and the query rewrite, which gave four seconds. A month later I checked: Excel exports had dropped to a third.

The technical solution is the same. The second answer has the reason the task matters at all, a rejected option with its cost, alignment with the stakeholder, and a check of the outcome. How to pick and build a story like this is covered in the post on the challenging task question.

Cache or no cache

The question: "The endpoint is slow. Would you add a cache?"

Middle answer:

Yes, you can put the response in Redis with a TTL of about five minutes, that will take a lot of load off the database.

Senior answer:

First I'd look at where the time goes and how often the data changes. If it's reference data, a cache fits and the only question is invalidation. If it's a user's balance, five stale minutes cost more than a slow response, and I'd rather optimize the query. A cache also adds a new point of failure, so we need to decide what we return when Redis is down.

The interviewer is not waiting for you to reject the cache. They are waiting for the conditions under which the decision is right, and its cost. That is the "depth" missing in those rejections.

You won't make the deadline

The bank question "What do you do when you realize you won't finish a task on time?" was asked at 6 companies.

Middle answer:

I tell my team lead as soon as I realize I won't make it, and explain why.

Senior answer:

I say so right away, but I come with options. For example: by the deadline I can deliver the main scenario without export, or everything three days later. And I say what exactly ate the time, so the next estimate accounts for it.

The middle answer is correct, and for a middle role it is enough. The senior adds options and a lesson for next time, which takes part of the work off the manager.

How to show seniority without the years

Years cannot be verified, while a way of reasoning is audible in the first minutes. What you can do in your very next conversation:

• Open an answer with one sentence of context: who the task was for and what hurt.
• Name the option you rejected and the reason. One sentence, "I considered X, but Y", is enough.
• Talk about the cost of the decision: what got harder to maintain, what you gave up.
• End with a result that has a number, or at least an observation: "support stopped getting complaints about it".
• On tasks with incomplete requirements, ask questions first. In system design that is half the score, see the post on structuring a system design answer.
• Prepare one story about influencing the team: you introduced a review rule, wrote a guide, grew a junior. The scale can be small.

The same goes for your introduction. A senior lists problems and their scale instead of a stack. There are examples in "Tell me about yourself": examples for developers.

What not to do: act senior through terminology. Talking about the CAP theorem when asked about an index has the opposite effect. And don't claim decisions you didn't make: the follow-up "why did you reject the other option?" exposes it within a minute.

Junior to middle

The boundary here is different and simpler. A junior is expected to finish a task with help. A middle developer is expected to finish it alone, without someone rechecking everything. In an interview it shows in three things:

• You can explain how the things you use work, at least one level down: beyond "I use an index", why it speeds up a lookup.
• Your task stories include "I figured it out myself" and "I found the cause", and not only "I was told to do it".
• You know what to do when you're stuck: how long you dig on your own, when you go for help and what you bring.

There is no need to demand senior answers from yourself at this stage. It is enough to show that you can be handed a task and return it done.

What is at stake

In job postings from Russian Telegram channels since August 2026, the median for a middle developer is about 200,000 ₽ per month (half of the ranges fall between 150,000 and 250,000), and for a senior about 260,000 ₽ (216,000 to 315,000). These are postings, not hh.ru (the main job board in Russia) and not actual pay, and only a third of postings state a range, so treat the numbers as a reference point. The breakdown by stack and skill is in the post on IT salaries and skills in 2026 and on the job market analytics page.

How to rehearse

Take three of your own task stories and rewrite each along this outline: why it was needed, what the options were, why you chose this one, what it cost, what came of it. Tell each out loud in under two minutes.

Then check how it holds up under follow-up questions. In the mock interview the interviewer digs into the details of your answers, and the review shows where you answered on substance and where you stayed at "did it, it worked". If your next step is leadership, look at what gets asked in a team lead interview: expectations of a senior carry over there almost unchanged.