Profile picture

Mid-level Engineer Career Development Videos, Forum, and Q&A

How A Mid-level Engineer Can Grow Their Career

Mid-level engineers have very strong technical proficiency, able to execute on small to medium-sized projects with minimal hand-holding, leveling up from junior engineers.

How to deal with internal team "level" jealousy?

Mid-Level Software Engineer at Taro Community profile pic
Mid-Level Software Engineer at Taro Community

In a previous team and organisation I had 3 different reports.

Lvl 5, lvl 4 & a lvl 2

I was the only remote member of the team, so at times it was difficult to fully understand the social and team dynamics within their office. I initially was unaware of any jealousy within the team until I was asked to fly out for a week for an unrelated reason. When on the ground, it become very clear to me there was a strong level of tension between some of the employees.

  • The lvl 5 was jealous of 2 of their friends who were now lvl 6 because they joined the organisation at the same time.
  • The lvl 4 was a strong performer who was happy with their current position.
  • However the lvl 2 who was an apprentice, was an outstanding performer (approx lvl 6) and it was close to witnessing a savant, especially at their age (18).

However there was no possible way for them to go up any higher as their role was tied to the completion of a certain stint of education.

This, alongside that the lvl 5 had aspirations of becoming a lvl 6 but was severely under performing which was especially noticeable by the lvl 2 - made things very awkward and difficult to navigate.

The outcome of this in the end was that I would support the lvl 2 in finding another role in a different organisation and with the lvl 5, we had a long discussion alongside my director to work out a plan of how they can start adding more value and improving their position within the team.

How could I have gone about this differently to create a more positive environment for the team?

Show more
75 Views
1 Comment

Should I join an important project with difficult team mates or a not so important project with great team mates?

Mid-Level Software Engineer at Taro Community profile pic
Mid-Level Software Engineer at Taro Community

I was lucky to join a very competent and lovely platform team when I joined my current company. I have been working in the same team for 18 months but due to re-orgs people have moved out and we are currently 3 people and we were 9 people when we started out.

We have been doing mostly maintenance work for the past 3 months after re-orgs and recently we were given a choice to work on two projects.

There is one project, lets call it Project Hero which my skip level manager wants me to join. I would be the main PIC for this project and it will involve a lot of integration work and system design. This project is with new team mates and a new manager with whom I have not worked but they don't have the best reputation. However, going by FAANG level, they should be good enough to get the job done. Only downside is work-life balance might be skewed if I join here. However, if the project is a success, it sets me up for Senior level promotion.

There is another project, lets call it Project Nero. This will be with my existing team but from a company perspective, it's not a very important project. But I will be working with my existing team mates who are both capable of delivering a solid project and a joy to work with. However, my work here will be overshadowed by other Senior engineers on the project.

Which project should I join? I personally want to do Project Hero but not with the people present there. Also it will be challenging.
Project Nero will be challenging also but more up my comfort zone.
Given the current economic climate, I feel being in more important teams will help keep my job.

Show more
135 Views
3 Comments

What would a roadmap to make a transition from Junior to Mid-level look like?

Associate Member of Technical Staff at Taro Community profile pic
Associate Member of Technical Staff at Taro Community

Hi Taro Community!

I am in a very similar position as mentioned by someone here: and from the responses it is evident that switching teams/companies will be an unavoidable step soon. I am currently at an entry-level position (will be completing 6 months at current company soon) and wish to look for roles at the next level of hierarchy (for instance my current role is equivalent to SDE 1, I wish to look for roles similar to SDE 2 or equivalent next). Few points:

  • I am planning to complete 1 year at my current company, so by the time I switch I shall have ~1 yr of experience as an entry-level software engineer (apart from other experiences as internships/side projects/etc.)
  • Firstly, is it realistic to prepare for mid-level at the current position? Do companies hire entry-level SWE's with at most 1 yr of experience for mid-level?
  • If yes, is it advisable to apply now (or 6 months down the line)? I do not wish to work as an SDE-1 (entry-level) in another company by leaving my current one as it will only lead to further delays in promotions (I believe it takes at least a few months to set a good impression in a new team that you are capable for a promotion)
  • How can I best utilize the next 6 months before I aggressively start applying to companies? I understood the point related to side projects - is it advisable to build side projects in the tech stack my team is using, or should I expand my scope to include new technologies I am interested (but not actively working on right now)?

Any insights/suggestions/interview tips will be really appreciated. I have very less workload right now and really want to make the best use of time to switch further.

Thank you!

Show more
322 Views
3 Comments

How to write wiki type documents effectively?

Mid-Level Software Engineer [SDE 2] at Amazon profile pic
Mid-Level Software Engineer [SDE 2] at Amazon

Background:

Being pressured to deliver at high speed all the time, my team doesn't seem to value wiki type documentation a lot.

When starting a project/feature, we often have a high level design doc & design meeting to talk about high level infrastructure, and we make key trade-off decisions together as a team. If we are lucky, we get another low level design doc & meeting focused on sequencing of actions & interaction between class level objects.

We rarely seem to go back to our initial design doc after initial design phase of a project to update them and explain the actual final product we built and maybe some additional design decisions we made during implementation.

As a result, documentations are kind of dead after facilitating the initial design review. For legacy projects, high quality docs are extremely hard to come by and most just rely on reading large amount of code to understand how things work (nothing wrong with this but I think high quality documentation can save lots of time here).

I understand we don't want to boil the ocean and write everything in painstaking details, but we should at least have enough to help people understand responsibility of services and contract between them.

Questions:

  • Could you share your view on this topic and how you find your balance?
  • Do you believe it's always worth it to go back to documenting after finishing a project/feature and update it as if you are explaining it to someone new to the team/project?
  • Could you share any resources we might already have on this topic as well?
Show more
203 Views
3 Comments

Fear of picking a specialization/niche: Is focusing on front-end okay?

Mid-Level Software Engineer at Taro Community profile pic
Mid-Level Software Engineer at Taro Community

Hello Taro Community

I want to pick a specialization now due to the market and the lessons I’ve learnt being in the group.

A little context on the issue:

I had a mindset that more technologies I know the more options I’ll have and also working as a full stack dev in my last position I got a lot of hands on experience on different stacks. More like breadth of knowledge but not depth.

I was applying to jobs like Database, UI/UX, Front End, Back End, Software and DevOps couldn’t land any interview in the last job hunt.

Last month I let everything go and I told myself I’ll specialize in “Full Stack”. I have been also working on side projects for my portfolio.

However, a lot of senior devs told me Full stack is too broad and 2 and 1/2 years of experience that won’t cut it.

I want to specialize in Front End with React and go very deep in that. Build projects pertaining to React Front End for my portfolio.

My fears:

  • I’m closing down my options, and limiting myself to Front End
  • Also being a foreign student where you kinda have to “work in tech” since that’s my major a lot of fear is coming up. In case the time I go back in the industry there is lack of front end openings
  • A lot of family friends in the industry telling me that Front-End specialization will be a waste of time since the industry is very saturated with it

Deep down I have realized specializing will really make my portfolio, knowledge and resume stronger. Plus Front-End is something I genuinely am drawn to and enjoy doing.

Would love to know your input on this.

Show more
603 Views
5 Comments

Learn About Mid-level Engineer

A mid-level software engineer has all of the foundational technical skills, industry knowledge, and practical experience that allows them to contribute to software projects. They can collaborate with cross-functional teams, handle complex tasks, and demonstrate a deep understanding of the technologies they work with.
A mid-level software engineer can demonstrate a certain level of technical proficiency and independence. They should be able to handle most bugs without needing constant guidance. They should also be able to independently implement features with medium complexity. It is the level where one becomes less reactive and more proactive. Proactivity means anticipating where bugs may show up as well as suggesting improvements in the codebase. They should have a high standard of code quality and high velocity of code velocity.
The journey from a junior to a mid-level engineer is a significant step in one’s career. It’s important to focus on developing the skills necessary for the next level. This shift involves being able to write code to being able to write better code faster. One should be able to understand systems, plan out projects, meet deadlines, and occasionally function as a lead to make the transition. They should also be improving their communication skills during this period and seek feedback on their work from more experienced software engineers.
The transition from a mid-level engineer to a senior engineer involves a deeper mastery of technical skills, leadership capabilities, and a complete understanding of the software development lifecycle. Senior engineers are responsible for making high-level architectural decisions, guide the technical direction of a project, and mentor junior and mid-level team members. Collaborate with your manager to develop a formal growth plan. Take the initiative to write the document yourself and discuss it with your manager. One should be able to recognize gaps that a mid-level engineer has so they can improve them: writing more code rather than reviewing code, not being available to help out during big incidents, or only dealing with one’s own code. By focusing on these issues, you will be able to exert your influence more broadly across your team and company. You should also consider mentoring some of the more junior members on your team to help them grow and develop their skills.
The journey from a junior engineer to a mid-level engineer or a mid-level engineer to a senior engineer involves a continuous process of learning and refining one’s technical, communication, and leadership abilities. One should strive to have more and more impact and influence across their company to have a successful career progression.
Show more