DEV Community

Nadia Zhuk
Nadia Zhuk

Posted on

From Junior to Mid-level: My Top Five Tips on How To Make This Transition

Me at my first dev job
As a self-taught engineer, I know full well how difficult it can be for someone to transition from junior to mid-level developer. There is always so much to learn, and you constantly feel that you are falling behind. It might also seem like you will never be good enough, with so many technical and soft skills still left to master and the knowledge gap between you and more senior engineers ever so wide.

Yet, at some point, you will need to take that “junior” off your job title. In this article I’d like to share my learnings from making this transition myself and talk about what helped me get promoted from junior to mid-level at a big tech company.


Learn to play the game


In order to stop being junior, you need to understand what is making you junior in the first place, at least in the eyes of your employer.

Larger companies usually have a formal and structured approach to engineering levels, with clearly defined competencies and skills expected from an engineer at each level.

If your company doesn’t have a defined engineering ladder, ask your manager what it would take for you to be promoted to a mid-level engineer. You can then create a list of action items you need to complete and success metrics you need to meet in order to get promoted. Both you and your manager need to agree about the way forward.

Having this list will not only give you more structure and guidance, but will also help you keep your manager accountable and ensure you are not being kept in a junior role forever. The more concrete this plan is, the better, and you should also ensure there are clear time expectations around when you are supposed to make this transition.


Start making decisions


One thing that distinguishes a junior engineer is the need for guidance and a limited level of independence. This makes sense at the beginning of your career, but at a certain point, this might also hinder your growth.

Don’t wait until you are ready to start making decisions: you might never feel completely ready, so just start small:

  • Make your own decisions about building a feature assigned to you without getting an approval first.
  • Express your opinions and raise concerns during your team’s planning session (this is especially important if you don’t agree with more senior team members).
  • Challenge code review suggestions you don’t fully agree with.

With each independent decision you make, your confidence will grow, and making decisions will get easier and easier, until it becomes second nature.


Get used to making mistakes


This piece of advice naturally follows from the previous one. The only way to avoid mistakes is to never make any decisions, so once you start being more and more independent, you will start making more and more mistakes. This is unavoidable.

Senior engineers make mistakes all the time, and that’s fine as long as they own their failures in the same way they own their successes.

Yes, this will feel uncomfortable at first. Yes, you will feel bad about yourself. Yes, you will cause problems for others and might cause your team to miss some roadmap targets. But this too shall pass, and the sooner you learn to live with the discomfort of being wrong, the sooner you can switch off the “junior” mentality.


Understand what your job truly is


As a junior developer, you might think that your job is to write code and close Jira tickets. It isn’t.

Your job as a developer is to solve customers’ problems, in the way that makes most sense for them and for your company’s business.

Start with questioning the engineering tasks that get assigned to you. Why do you need to build this feature in the first place? Which customer problem does it solve? Is there a way to avoid building this altogether? Where does this fit in the overall strategy of your company? How will this feature help your company make money?

Asking these questions is uncomfortable, but this can be seen as the first step towards increasing your value to the company. As you grow as a developer, you will need to learn more about product management, design thinking, and customer development. You will also need to develop empathy for your users and think of them whenever designing or building features.

Juniors obsess about tools, seniors obsess about users. The sooner you learn to see yourself as a problem solver rather than a code pusher, the sooner you will take that “junior” label off your job title.


Start sharing knowledge


You might feel you don’t know anything that is worth sharing because you are the only junior developer on your team. I’ve been there. In reality though, any developer, no matter how junior, has things they know and understand better than others on their team, either because they have spent more time looking into these things or because they have a particular interest in a certain topic, that others don’t share.

Think of the parts of the codebase you understand well and volunteer to help others when they want to understand those areas better. The easiest way to do this is to help new engineers onboard. Remember that you don’t need to know everything in order to be a teacher: you just need to know a bit more than others and be willing to share your knowledge.

You can think of technical topics or tools that you find interesting and consider holding short learning sessions for your team. When I was still a junior, I led a team learning session about Object Oriented Design Patterns. Did I know those patterns beforehand? No, I didn’t, but I was interested enough to educate myself and then tell my teammates about what I’ve learned.

To my surprise, the session was sufficiently interesting even for the senior engineers, who were glad to be reminded of coding patterns they studied in college. The rest of the team was glad to learn something new as well, and the discussion we had afterwards improved our technical knowledge as well as helped us bond with each other.

Sharing your knowledge allows you to expand your influence as a team member, and a growing influence is a hallmark of a more senior engineer. This will help you go from being someone who needs help to someone who can help.


These are some of the behavior changes that helped me move from junior to mid-level engineer. I’m sure there are other things a junior engineer can work on to get promoted faster.

If you have made this transition, what else helped you? Please share below.

Top comments (11)

Collapse
 
stereoplegic profile image
Mike Bybee

Shared to my LinkedIn with the following commentary:

"Solid advice. Should you find yourself in a place that doesn't allow for such questioning, then seriously ask yourself whether you're at the right place."

Collapse
 
beetlehope profile image
Nadia Zhuk

Thank you for sharing! I'm glad you found it useful.

Collapse
 
dolapo_adebanjo profile image
Adebanjo Dolapo

Great insight. Thanks for sharing.

Collapse
 
beetlehope profile image
Nadia Zhuk

Thank you! I'm glad this post was useful.

Collapse
 
beetlehope profile image
Nadia Zhuk

If you have any follow-up questions, please let me know, I will be glad to tackle them in future posts or videos.

Collapse
 
drfcozapata profile image
Francisco Zapata

Great!!! I like your post. Thanks for sharing it.
Blessings from Venezuela.

Collapse
 
beetlehope profile image
Nadia Zhuk

Thank you! I'm glad you enjoyed this post.

Collapse
 
chadwinjdeysel profile image
Chadwin Deysel

Great post! Specifically the point you made about what a developer's job truly is. We get really caught up in code, code, code that we miss we point and that is solving problems.

Collapse
 
beetlehope profile image
Nadia Zhuk

Oh yes, so true! It took me a while to understand what my job truly was. I wish someone had told me this early on!

Collapse
 
renanpereira profile image
Renan Pereira

Thanks for sharing, it was a very nice read as a junior dev.

Collapse
 
beetlehope profile image
Nadia Zhuk

I'm glad it was helpful. Please let me know if you have any follow-up questions as a junior developer. I will be glad to answer them in a blog post or (more likely) on my channel youtube.com/user/beetlehope