Career strategy
They said you passed. Then they downlevelled you.
The interview feedback can be positive and still fail to support the scope of the role you applied for.
By Mike Salari. Staff mobile engineer · 500+ technical interviews from the hiring side.
5 min read
You complete the interview loop. The recruiter calls with good news. The team liked you, the technical feedback was positive, and they want to make an offer.
Then comes the part you weren't expecting: the offer is for the level below the one you applied for.
People often interpret this as a judgement that they aren't as good as they thought. That can be part of the story, but there are several different decisions hiding behind one lower title.
From the hiring side, the most useful question is not whether the candidate is a good engineer. It's what the interviewers saw that supports the level under discussion.
The committee has evidence, not your career
I've conducted more than 500 technical interviews from the hiring side. In an interview, nobody sees your entire working life. We hear selected examples, watch how you approach a problem, and write feedback based on a limited period of time.
You may have spent two years owning a migration that affected several teams. If your answer focuses on how you wrote the iOS implementation, the interviewer may see evidence of strong individual delivery but little evidence of influence beyond your own code.
This is why the same project can support different impressions.
I implemented offline sync for the mobile app.
That tells me what you built. It does not tell me who decided the consistency rules, how failures were handled, how the backend and client teams agreed on the contract, or whether you changed how the wider organisation worked.
Now consider a different account of the same project, assuming it is true:
I owned the offline synchronisation contract across iOS, Android and backend. I drove the decision about conflict resolution, managed old-client compatibility and led the rollout across three teams.
There is considerably more evidence of scope in the second account. The language alone doesn't earn a staff title. The interviewer still needs to ask what you personally decided and what happened as a result.
But it gives them something meaningful to investigate.
Where seniority can disappear during a loop
The first place is the CV. A collection of delivery verbs can hide the decisions behind the delivery. Worked on payments, migrated the app, improved CI. Those claims may describe substantial work, but they don't show how much authority you had or who depended on the outcome.
The second place is the behavioural round. You spend ten minutes explaining the project, then ninety seconds on the part you personally owned. Interviewers need the opposite ratio. Tell them where the decision was yours, where someone challenged you, what you changed, and what the consequences were.
The third place is system design. Drawing a sensible architecture demonstrates technical knowledge. Senior and staff evaluations may also explore how you handle ambiguity, competing team requirements, migration costs, operational responsibility and decisions that remain expensive to reverse.
The distinction is not a universal senior versus staff checklist. Companies define levels differently. What matters is matching the evidence you give to the scope the company is hiring for.
A lower level is not always an interview failure
Sometimes a company has a narrower staff definition than your current employer. Sometimes the open position was changed. Sometimes the team wants your skills but the budget or headcount approval supports a different title.
And sometimes the feedback is about a real gap. You demonstrated strong implementation and local design, but the committee didn't see enough examples of decisions affecting other teams.
Those situations require different responses.
If you are offered a lower level, ask the recruiter what changed. Was the original role re-scoped? Which competencies were assessed below the target level? Would the responsibilities also be reduced? Is the compensation tied to the new level, and how do the growth expectations work in practice?
A vague promise to promote you soon is not the same as a documented plan. A lower title with stronger compensation and an excellent team can still be the better decision. The important point is to understand the role you are accepting.
Don't use the offer call to argue that your previous title proves the new level. Ask for the concrete difference between the scope you demonstrated and the scope they require.
Prepare evidence before anyone has to infer it
Take three substantial projects from the last two years and answer five questions for each.
What decision was mine? Who else was affected? Which alternative did I reject? How did we know whether it worked? What would have happened if the decision failed?
Keep it factual. If you participated in a team decision, say that. If you led it, explain how. If you don't know the metric, don't invent one.
Your CV should give a reader enough evidence to ask a better question. Your behavioural interview should supply the missing context. Your system design discussion should show that you can make and defend decisions at the scope of the job.
You do not need to recite a larger job title. You need to make the work you did understandable to someone who wasn't there.
This is the kind of evidence I work on in Engineer Career Rebuild: shaping CV and LinkedIn positioning around a target role, with claims grounded in work the engineer can defend.
The lesson I keep returning to is that a company cannot evaluate the experience you don't make visible. And if the company changes the role after evaluating you, you deserve to understand that too.
