5 Things I Did to Stop Being a Junior Engineer
Here are the small things I did to get promoted.
I recently got promoted at my company from Software Engineer 1 to Software Engineer 2. This could be considered equivalent to Junior and Intermediate at other companies.
As a disclaimer, a job title is just that — a job title. Besides compensation, it doesn’t really mean much.
One company’s evaluation of an engineer could differ from another. I may be considered intermediate or even senior at some companies, but still be considered a junior at others.
Nonetheless, here are the things I did to stop being a junior at my company.
1. Stop Worrying About Not Knowing Everything
The less questions you ask, the smarter you look, right? Not exactly.
When I first joined the industry, I thought engineers would be easily transplant-able between teams and between companies. However, the reality is that all engineers, even the great ones, need time to ramp up on a new team.
I didn’t understand this at the time. I thought I was supposed to hit the ground running.
And so, I tried to be as self-sustaining as possible. Instead of interrupting meetings to ask about things I didn’t understand, I’d make a note of it and google it later. And if it was company-specific, I would comb through documentation.
The issue with this, however, is that tribal knowledge is real. Poor documentation is rampant in even the top tech companies, and my company was no exception.
Not surprisingly, my plan at looking smart backfired. Instead of looking smart by being self-sustaining, I looked stupid by not knowing concepts that I would’ve known if I just asked from day 1.
The next time a teammate mentions something you don’t understand, make sure to ask him or her about it, because it’s likely that you wont be able to find the answer elsewhere.
Even the smartest and most capable people need to constantly ask questions. No one can be expected to know everything.
2. Say Yes to Everything
Be eager to learn. The fastest way to learn is to throw yourself into the fire.
Whenever someone asked me if I was up for a task or project, no matter the difficulty, I always said yes.
I’ve always received praise for this in performance reviews. Teammates appreciated that I could help with any task. My manager appreciated that I could be put on any project. I appreciated the opportunity to learn. Everyone wins.
On a cautionary note, this may not be sustainable in the long run as you advance in your career. It’s easy to get burnt out by always saying yes.
It’s just a good way to jump start your career.
3. Work On High-Visibility Projects
Working on an internal tools team isn’t the most exciting work. Maintaining a mature product curbs learning and exposure. And absolutely nobody likes owning legacy tools.
The first team I joined as a new grad gave me a taste of all three.
I worked on this team for about a year until I realized that it wasn’t a good fit for me. I wasn’t learning as much as I would’ve liked and I didn’t receive much recognition or exposure.
I took an internal transfer to a team that used newer technologies and had just started a greenfield project.
It’s no secret that senior leadership loves sexy, new projects.
Compared to my old team, we received way more recognition. I learned a ton. I was able to make more of an impact, and ultimately got promoted in half a year.
4. Slow Down a Little Bit
This may sound counter-intuitive, but speed isn’t everything. I’ve noticed a trend with interns and new grads thinking that the faster you are as an engineer, the better.
Although clearing 30 JIRA tickets a sprint looks impressive, it’s better to take a step back and focus on code quality and operational readiness.
I learned this the hard way.
When I first started, I would do the bare minimum to close out a JIRA ticket — look for the easiest way to complete a feature and write unit tests just for the sake of meeting the code coverage
I thought I was a prodigy, closing tickets left and right…until things started breaking in production. Oops.
The moral of the story is slow down and do things right. Write clean code. Write tests with purpose. Have good automation in place. Put logs in your code. Set up alerts and dashboards to monitor. The whole shebang.
Again, speed isn’t everything.
5. Speak Up
In meetings, discussions, or even casual conversations, you should speak up.
It could be anything.
Give your opinion on something, or ask a question. Take up your space so people recognize your presence.
It’s easy to fall into the trap of “I’m a junior so I should stay quiet. If I say something, I will sound stupid”.
Don’t let that be you.
I definitely fell into this trap at first. I, like many other people, experienced impostor syndrome. I silenced myself, believing that if I said something stupid, they would realize that I had no idea what I was doing.
It wasn’t easy to snap out of this mindset. I only started opening up after realizing that the opinions I had often aligned with what the team agreed upon.
Regardless, in any respectable team, no one will try to make you feel stupid. You won’t know if your opinion is valid or not until you tell people about it.
And even if it’s not valid, you walk out with a better understanding of the subject matter.
Every company has its own expectations. Whatever worked for me may not work for everyone.
If all else fails, keep learning and stay confident.
