My standard advice for junior software engineers in their first job

I wrote about getting a first dev job a while ago… but what about after you start? Here are a few pieces of advice that often crop up when I’m mentoring junior software engineers, which I’ve found myself doing a lot in the last 3 years!

1. Feel free to look ignorant.

Being a junior software engineer is an extremely liberating spot to be, because others expect you not to know things. So take advantage! Ask silly questions, be open about you’re struggling with a task. It saves everyone time, people usually like to help, and again, it’s expected.

As a bonus, once you need less help, it will be all the more apparent that you’ve grown into the role.

2. Give PR reviews

We often talk about how getting PR reviews helps improve our code, but also, IMO, giving PR reviews is an extremely underrated way to grow when you’re a junior. Reviewing more senior teammates’ pull requests pushed me to:

• understand what others were working on
• formulate questions I might have, and try to find the answer by myself
• figure out cultural norms
• see myself a contributor to the team (!)

3. Communicate regularly and openly

Regular 1-1s are super important, especially at large companies and especially remotely. You should use them to discuss anything but day-to-day tasks: career goals, chit-chat, and the larger context of work (i.e. reorgs, new leadership, priorities, pain points everyone’s experiencing, ideas, etc.) I try to always come in with a loose agenda of things I want to discuss.

As an example, in my jr dev job, I’d set up 1-1s monthly with my skip-level manager, twice a month with my manager, and twice a month or monthly with teammates I’d onboarded.

4. Keep track of what you are doing

It’s ridiculously easy for me to forget what I’ve worked on. Tracking it in a document helps me fact-check my impressions and frame them better.

For instance, “I feel like I’m stagnating” is vague and sad, but “For the last 2 months, I’ve done mostly small chore and bug-fix tickets, so I want to pick up a larger project to learn more” is specific and actionable.

Also, this documentation is useful for the next point, promotions.

5. Make a plan to get to the next level

Junior software engineer is, by definition, a pit stop. Getting to the next level is less about fairness or time than it is about becoming a mid-level software engineer… whatever that means in your context.

IMO, the basic recipe is to:

• Find out the expectations for the next level. They’re sometimes explicitly written down somewhere, but either way, you should also ask your manager, and someone who is at that level. You can also ask them where they think you should focus your efforts.
• Make and accomplish 3, 6, and 12-month goals with your manager’s input (I have a blog post on that.)
• Super crucial: figure out the actual IRL process to get promoted (committee review? once or twice a year? when? who has the final say? is it important to have other higher-ups vouch for you?) Then make sure you and your manager are moving accordingly.

6. Build side projects

If you don’t want to code outside of work because you have a life, I completely understand: I’ve at various points had a life too, plus I’m not a freaking nerrrd.

But in a junior job, you’re typically dealing with only a small subset of tools and tasks. In side projects, you start from scratch, and get to do the things your senior teammates usually do, like make architecture decisions or deal with gnarly build errors. You can play with packages or languages that aren’t in your corporate codebase, and test out your weird ideas, without any consequences.

Plus, it doesn’t have to be a lot! 2 or 3 small side projects over my first year had a huge impact on my confidence and skill.

7. Think about your place on the team

Finally, for me, the mark of non-juniorship was when I saw a problem common to the team - say, inconsistent linting, or a pain point in the deployment process. While, as a junior, my reaction would be “I should discuss it with everyone,” at some point, I started to just go “I’ll come up with a fix, and present it at standup.” In other word(s), I took ownership.

When you feel like you’re a full contributor, not just to the codebase, but to the team, pay attention to that feeling; I think it’s a good sign.

Conclusion

If you clarify your expectations, use them to set a good framework, and keep checking in with yourself and others, I’m pretty sure you’ll do great in your new job. Dogspeed! And keep me updated!