Final interview with the hiring manager or CTO: what to expect

The technical round is behind you, and the recruiter writes: "Only the final with the head of the department is left, it's more of an introduction." You relax and show up unprepared. Forty minutes later you realize you've been answering questions you didn't expect: why the project you're proud of was needed by the company at all, which task you would turn down, and what you'd do if the team disagreed with your decision.

In the interview reports in the Sobes bank, a final interview averages 11 to 14 questions, with more for seniors than for middles. Few of them are technical. Most are about results and choices: "Tell us about your professional achievements and results at your previous company" was asked at 56 companies, "Which factors are decisive for you when choosing your next job?" at 19, "Do you currently have other job offers?" at 21.

How the final differs from the technical round

The technical round checks whether you can do the work. In the final, the manager decides whether they want to do it with you. Your knowledge has already been confirmed, so they look at other things:

• How you think. Whether you see the goal behind a task and can explain a decision to someone outside your team.
• How you prioritize. What you'd do first when everything is on fire, and what you'd drop.
• How compatible you are with the team and with them personally. How you argue, how you take a no, how you talk about former colleagues.
• Whether you'll stay. Whether what you want matches what they can give you in the coming year.

The manager or CTO has a goal of their own on this call: to sell you the position. So the conversation goes both ways, and your questions carry more weight here than at any other stage.

Typical questions

The set repeats from company to company:

• Tell me about a project you're proud of. What was the result.
• Tell me about a decision that turned out to be wrong.
• What do you do when you disagree with your manager's decision.
• What matters to you at work, and which task would you turn down.
• What other processes do you have, and when are you ready to decide.
• What do you expect from the first three months.

For some of these it's better to have stories ready. How to build a story about a mistake or a dispute is covered in the article on conflict and mistake stories with STAR, and plans for the next few years have their own article.

How to talk about business results

Hearing what you built isn't enough for a manager. They need to understand what changed for the product or the company. The test is simple: remove the technology names from your story, and something meaningful should remain.

The weak version: "I rewrote the notification service in Go and introduced Kafka." The strong one:

Our order status push arrived with a delay of up to ten minutes, and a noticeable share of support tickets came from that. I proposed moving notifications into a separate service with a queue. We did it in two months, the delay dropped to a few seconds, and "where is my order" tickets went down by about a third.

The answer has a problem that makes sense without technical context, your role ("I proposed"), and a result in units the business counts. Only name a number you can explain: how it was measured and over what period. If you don't have exact data, give the order of magnitude and say where it comes from. Invented percentages fall apart in the final after one follow-up question.

If your work is far from money, find another unit: release time, number of incidents, hours of manual work your colleagues no longer spend.

The disagreement question

It's asked almost every time, in different forms. The manager is checking for two extremes: whether you'll silently do what you think is wrong, and whether you'll sabotage a decision you don't like.

I'll say it directly and with arguments, ideally with numbers or an example. If the decision stays the same after that, I'll do it as decided: my manager may have context I don't. If it's a serious risk, I'll ask to put it in writing and agree on the signs that would tell us it's time to revisit.

The answer shows both qualities at once: you object openly, and you carry out the decision that was made.

What to ask the manager

The final gives you access to the person who knows what neither the recruiter nor your future teammates know: plans, budget, the reasons for hiring. Ask about those.

What problem do you want this hire to solve? What should change in six months for you to say it was the right call?

What's slowing the team down the most right now?

How do you make decisions when the team disagrees with you?

How does growth work here: what gets a person promoted, and who decides?

Questions about reviews, on-call, and first tasks are better asked of the team. They're collected in Questions to ask the interviewer as a developer.

Mistakes in the final

• Relaxing. "It's a formality" is sometimes true, but you can't know in advance. A rejection after the final is possible, and the cause is usually the conversation itself, not your knowledge.
• Starting to negotiate. If you answer the expectations question with a number higher than the one from the screening call, it looks like changing the terms midway. Name the same range and leave negotiation for the offer. How to handle it is covered in the article on negotiating an offer and a counteroffer.
• Answering the manager as if they were the technical interviewer: five minutes on internals, not a word on why it was needed.
• Saying something different from earlier stages. Your reason for leaving, start date, and the status of other offers are already written down.
• Asking no questions. To a manager that signals you don't care where you end up.
• Criticizing their product uninvited. If they ask what you'd improve, answer, but start by asking why it was built that way.

How to prepare

Collect three stories: about a result, about a mistake, and about a dispute. Fit each into a minute and a half to two minutes and check that it has a problem, your action, and an outcome in understandable units. Reread your notes from earlier stages so that the numbers and reasons match.

Then say it all out loud. The mock interview has a "finals" mode: the interviewer asks about motivation, priorities, and decisions, digs into details, and shows a review at the end. One run is usually enough to notice where a story gets blurry and where you drift into technical details and lose the result.