Mid-level means you can take a well-defined feature from ticket to production without close supervision. Find out what your company actually expects at the next level, show that behaviour for a few months, keep written evidence of it, and ask your manager directly what is missing instead of waiting to be noticed.
What people tell me
I have been working as a junior developer for over a year. I close my tickets, my code reviews are mostly fine and my manager says I am doing well, but nobody has mentioned a promotion. Some people who joined around the same time have already moved up. I do not know what I am supposed to be doing differently, and I feel awkward bringing it up because I do not want to sound impatient or entitled.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Mid-level is mostly about independence: you own a feature end to end and need less direction, not just more technical knowledge.
- Ask for the written expectations for the next level. If none exist, ask your manager to describe them and write them down together.
- Promotions go to people who are already working at the next level, so start doing the mid-level job before the title arrives.
- Keep a running record of your work with links and outcomes. Managers forget, and promotion cases are built from evidence.
- Have one direct conversation: what is missing, and what would it look like in three months if I closed that gap?
What actually changes between junior and mid-level
Most people think the jump from junior to mid-level is about knowing more technology. It is mostly about how much support you need. A junior developer is given a well-scoped task and some guidance. A mid-level developer is given a problem and trusted to turn it into working software with little supervision.
That difference shows up in small, visible ways:
| Area | Junior | Mid-level |
|---|---|---|
| Scope | Single tickets, often pre-broken down | A whole feature, including breaking it into tasks |
| Direction | Asks what to do next | Proposes what to do next and checks it |
| Unknowns | Waits or asks early for every gap | Investigates first, then asks precise questions |
| Code review | Receives mostly corrective comments | Receives mostly small comments, gives useful reviews |
| Delivery | Code merged | Feature working in production, monitored, documented |
| Estimates | Rarely gives them | Gives rough ones and updates them when they slip |
If you read that table and recognise yourself in the left column in two or three rows, that is your gap. It is rarely all of them.
Why good work alone does not get you promoted
"Doing well" at your current level is not the same as being ready for the next one. Many managers promote people who are already working at the next level for a few months. They need to defend that decision to their own manager or a promotion committee, and they can only do that with examples.
That means two things. First, you have to do the mid-level work before you get the title. Second, someone has to be able to point at it.
Step 1: find out what the bar is
- Ask if your company has a career ladder or levelling document. Many do, even small ones, and many juniors never read it.
- If there is one, pick the three or four expectations for the next level that feel least like you today.
- If there is none, ask your manager: "What would you need to see from me to feel confident putting me forward for mid-level?" Write the answer down and send it back to them in a short message so you both agree.
The Your first tech job cheat sheet summarises the habits that usually separate an early-career engineer from someone who is trusted with more.
Step 2: start doing the next-level work
Pick behaviours you can show within weeks, not years:
- Own one feature end to end. Ask for something slightly bigger than usual. Break it into tasks yourself, share the plan, deliver it, then check it in production.
- Investigate before asking. When you are stuck, spend a fixed amount of time (say, 30 to 45 minutes) digging, then ask with what you tried. How do I ask for help at work without making people think I am incompetent? covers how to phrase it.
- Review other people's code properly. Leave comments that catch real problems, not only style.
- Give estimates and update them. "I think three days; I will tell you by Wednesday if that changes" is a mid-level sentence.
- Write things down. A short design note or a README update after a tricky change shows judgement.
Step 3: keep evidence as you go
Keep a private document, sometimes called a brag document. Every week, add a line with what you did, a link and the outcome. The guide Get Your Work Recognized: Write a Brag Document is a good template. When your review comes up, you will not be relying on memory, yours or your manager's.
Useful entries look like this: "Led the export feature: split into five tasks, shipped in two weeks, reduced support tickets about exports." Weak entries look like "worked on exports".
Step 4: have the conversation
You are not being entitled by asking about your growth. Managers generally prefer a direct question to silent frustration. Try:
"I would like to work towards mid-level in the next review cycle. Based on what you have seen, what are the one or two things I would need to show more of? Could we check in on them monthly?"
Then actually check in. A short monthly update against the gaps you agreed on makes the promotion conversation almost a formality.
A 90-day plan
| Weeks | Focus | Output |
|---|---|---|
| 1 to 2 | Read the ladder, talk to your manager, agree two or three gaps | Written list of gaps, shared with manager |
| 3 to 6 | Take one larger feature and own it end to end | Task breakdown, shipped feature, short write-up |
| 7 to 9 | Increase review quality and investigate before asking | Five to ten meaningful review comments a week |
| 10 to 12 | Pull together evidence, ask for feedback against the gaps | Brag document with dated examples |
Common mistakes
- Learning a new framework instead of changing behaviour. Extra technology rarely closes the gap. Independence does.
- Comparing with the person who got promoted. Different teams, managers and timing. It tells you little about your own case.
- Waiting for the annual review to raise it. By then decisions are often already made.
- Taking only safe tickets. You cannot show ownership if you never take anything uncertain.
- Keeping your wins invisible. If nobody knows you fixed the flaky pipeline, it does not count in the conversation.
What if the answer is "not yet" for too long?
If you have done the work for two cycles, you have evidence and the answer is still vague, it may be a company problem, not a you problem: no budget, no process, or no one advocating. At that point, your evidence becomes the basis of a strong application elsewhere. Why do some developers progress much faster than others? looks at the other side of this.
If you are still stuck
Read What Actually Changes in Your First Two Years as an Engineer for a longer view of this stage. If you want a structured path, join Sefism: it is free to learn, you get credits when you join and your first roadmap is free. As a member you can ask your own question about your specific team, or book a 1:1 session to plan your promotion case together.
Was this answer helpful?
Read next
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.