As a junior engineer, one of the most valuable ways you can spend your time is relationship building. When I was getting up to speed, I spent a significant amount of time talking with my teammates to understand what they were working on and what they thought would be good areas to grow into. In my spare cycles, I’d pick up a ticket from someone else’s OKR to help them deliver on time.

I first started with my on boarding buddy who introduced me to other people on the team. My first OKR was joint with another senior engineer and I spent a lot of time just learning from that engineer. After \~9 months on the team, I understood the most critical pain points on the team and began pitching ideas on how to solve them. This knowledge was built over time by talking to my teammates, getting involved with site-up / GCNs outside of my oncall (aka immediate fires affecting prod), and getting my hands dirty on things outside my immediate scope.

I only have context on Infra at LinkedIn, but everyone on my team always has more tickets than they can actually physically do in their backlog. And people are more than happy to get you started as long as you actually have time to do the ticket (NOTE: do not commit to something you don’t have time for. It’s a bad look and people don’t like their time being wasted).

If you do this correctly, you will naturally gain the trust of both your teammates and manager to be given high impact tasks and you will never have the problem of too little work to do. Your teammates will vouch for you during perf review, and will want you on their projects. In a healthy team environment, your teammates will even be invested in your growth (after all, senior+ is evaluated on their ability to grow juniors)

Senior Software Engineer at LinkedIn

Matthew Ho

It's worth noting that the Senior promotion at LinkedIn does not depend heavily on your ability to review docs. Doing well in the Leadership category is about disambiguating requirements from a vague OKR by asking the right people who will give you good feedback on your design. Challenges usually come from operational overhead when dealing with multiple teams. And you will get a lot of recognition for aligning the correct stakeholders and being able to call out roadblocks early.

After a few reps of this, you will gradually become more comfortable and pick up on the common pitfalls in your domain. Over time, you'll learn who are the upstream and downstream and how your design may affect them. Make sure to ask questions to understand the direction of the team so that you're able to call out if an OKR or design is either redundant or shortsighted. There are rules of thumb that Jonathan mentioned which can be generalized, but becoming a good reviewer is a bit niche to your domain because it requires understanding upstream and downstream consumers well.

Take advantage of that invincibility you have from being junior. You can be fearless when asking questions and in my experience you'll often get an answer. And asking questions in a doc or even by PM is very valuable even for the person answering your question. I often notice flaws in my original design when answering questions from people on the team.