My Experience of Moving up the Career Ladder in Software Engineering

Recently, I got promoted to Senior Software Engineer at iFood. This got me thinking about how things changed for me, in the sense of how expectations shift. I've decided to recall what I have learned and how I've changed to figure the way forward.

I’ll make it clear that this article is not a tutorial or a collection of tips and tricks on how to get promoted. This article is about my experience and what I learned from it. And I hope that this experience is valuable to you, so you can avoid my mistakes, learn from my success, and grow even faster.

Without further ado, let's see the three lessons learned.

1- Don't be afraid to speak up

When I first joined iFood, I didn't hit the ground running. My first evaluation cycle feedback was pretty bad: besides the overall low score, I've received one very tough feedback that I was omissive in feature refinements and problem-solving gatherings. My manager at the time read it as a lack of engagement and motivation.

I was very motivated and excited about my job. The truth was that I was afraid to share my thoughts, make suggestions, or disagree. I thought that I didn't have much to contribute, and instead, I would listen to my teammates, who were way more experienced than me.

At the time, I had the wrong idea that as a junior, my job was to just execute whatever my leaders would assign to me. And Senior engineers or tech leads were the ones that should call the shots on what to do and how.

💡 The advice I wished to have received at the time was: Don't be afraid to share your ideas. You don't have to have X years of experience to have a good idea.

Your seniority level isn't really relevant to any discussion. The only thing that matters is your idea. After I started being more participative in those discussions, I have never been looked down on by anyone, and I have never been dismissed when challenging the opinion of people who were "ranks above me". My questions were answered respectfully, and my ideas were seriously considered and sometimes accepted.

Furthermore, different opinions enrich any discussion, resulting in well-thought features and more rounded-up designs. When you ask why a decision was taken or suggest alternative ways to solve the problem, you are forcing everyone else to review their thought process and glance at the problem with different lenses. You are helping yourself and everyone around you to have a better understanding of the idea. So even if your input doesn't get to be implemented, you are still doing great.

💡 Remember that writing code and closing Jira tickets are just a piece of the job, you are expected to solve problems.

2- Find mentors and talk about your career with them

Having mentorship early in your career as a software engineer is super helpful to help you understand the career, the company, and to speed up learning in general. I had no idea that this was important at the time, but I got pretty lucky to have a great manager to mentor me. I had a more experienced teammate that always loved sharing knowledge.

Looking back, I see all this mentorship that I had yielded great results for my rapid growth. If you don't have a mentor yet, I strongly recommend you pair up with someone.

The first focus that I had at mentorship was truly understanding the company values. Understanding this is super important because it regards the expectations that the company has on you are. If you are pursuing a promotion in a lot of companies, a committee will consider those values in your case assessment, so it's important to be on top of that.

Most likely, someone will explain the company values to you on onboarding, but a lot of the meaning is up to interpretation, and it isn't always obvious how to apply those on the day-to-day. Having some time at the company, a mentor could help you make those grey shades clearer. In my mentorship meetings, we would look back at each month to review whether my actions were aligned with the company values or not. This process has helped me understand iFood's culture in practice.

Moreover, I highly recommend you create a learning plan with your mentor. A learning plan is a guide tailored specifically to you where you map the gaps you have as a software engineer and the subjects you want to be excellent at. This plan will contain details on what you are effectively going to do to learn each subject (read a book, create an app...) and when you'll do it.

Sharing my learning plan with my mentor and taping into their experience helped me find opportunities at work to learn and apply the knowledge I wanted, share my learning with the community, and even recommend me excellent sources like articles, books, and WWDC sessions.

💡 Although you can make your learning plan by yourself, the quality of the plan increases dramatically when you share it with someone else and get their feedback.

3- Become a reference on some subject

Last but surely not least, becoming a reference on a subject was a great deal for me to be highly regarded by my colleagues and manager. When I talk about becoming a reference on a subject, I mean to deeply understand a subject and get involved with it as much as I possibly can. And in time, people will realize how good you are at it, and every time they need help with that, they will come to you.

Put in an abstract way like that, the concept may seem weird, but it is rather common. When you have a pretty nasty UI bug that you are having a really hard time understanding, who do you ask for help? Maybe your closest colleague at first, but if even the two of you can't solve it, you probably call that one UI magician who seems to have UIKit under their command. This person is your reference for UI. Maybe you know people who reference architecture, git, tests, giving presentations, automating stuff, and so on.

Likewise, people can be references on product features or businesses units by having end-to-end knowledge of the feature. Knowing a feature end-to-end includes understanding things like what services they depend on, what are the OKRs, who's the target user, how it is implemented on mobile, what the plan is to evolve this feature in the future.

When you are developing a feature, you can seize the opportunity to become a reference on that feature. Talk to everyone involved in it - product managers, developers from different platforms, managers - and try to absorb their knowledge. Understanding the bigger picture on a project not only can make you the reference on it, but also can help you make better decisions throughout the development, so this is always a good practice.

Beyond that, you should keep your eyes peeled for hidden gems that you can come across. One hidden gem that I found was the Reorder feature at iFood. The feature was pretty cool conceptually, it allowed the user to order the same items at the same restaurant that they ordered in the past. But there weren't plans to evolve the feature any further, and it had an outdated implementation and depended on a legacy service, so everyone avoided editing any code there.

I started to bring it up on team strategy meetings and sprint plannings, and eventually, it got some traction.

Some teammates engaged in the discussion, and after a while, people were excited to have more Reorder access points in the app and to improve its experience as a whole. I got a couple of weeks to refactor it on the iOS app, and later the Android developers refactored it as well. Finally, the Backend team had a pristine service for Reorder. Suddenly, we had a brand new feature ready to be evolved and scaled in a way that was impossible before.

I paired up with the Android and Backend developers, and I was on top of the analytics events, logs, error handling, and design of the feature. At some point along the way, I became the reference on the Reorder feature, and people would always invite me to discuss it.

A broader way to think about that is that having deep knowledge on a specific subject makes you very valuable to the company, as you can be the one to lead innovation in that field and to be able to support the teams that need that skill. Valve's new employee handbook has a great take on that. They call it the T-shaped model, where the employee is both a broad-range generalist and an expert in a single area.

💡 Find something that interests you, and be really good at it. The results will follow.

Takeaways

• 📢 Don't be afraid to participate in discussions. Ask questions, disagree, add more to it.
• ⚙️ Writing code and closing Jira tickets are just a piece of the job. You are expected to solve problems.
• 🧠 Talk about your career goals with your mentors. They could help you achieve them.
• 👀 Seize the opportunities to be the reference in a business context.
• 🆃 Choose an area that you like, and be an expert in it. Remember the T-shaped model.

Beyond this article

Gergely Orosz wrote two great articles that complement the content discussed here.

• First, this in-depth article about mentoring is a good starting point if you are interested in the subject.
• The second article is called The product minded engineer, and for me, it's a must-read for every Software Engineer working in product development. It will explain in great detail how you could be more business-oriented.

Thanks for reading!

Liked this content? Follow me on Twitter and be the first to know about new articles. Suggestions, feedback, and corrections are always welcome.

Previously published here.