I just started my first engineering job. Help 😬!

Top tips for junior engineers or engineers starting a new job

Starting your first engineering job is a scary thing.

You’re probably getting paid a lot of money thinking, “How does this make sense? I don’t even know that much.”

While it may seem like I know what I'm doing now, when I started my first job 4 years ago, I was scared.

• I didn't know if I'd be able to do the tasks I was assigned.

• I didn't know if I'd have what it takes to not get fired.

• I didn't know if my teammates would like me.

I’m sure you’re familiar with what this is called: “Imposter syndrome.”

Obligatory impostor syndrome meme I thought was both funny and cute below:

However, this isn’t your usual imposter syndrome article. But, I would recommend Richard Donovan’s impostor syndrome article alongside this one if you are experiencing it.

If you’re here, you are likely the type who beats impostor syndrome by taking actions that show you and the people around you, “This person knows what they are doing.”

This article is for that. You’ll hopefully walk away with tons of actionable tips that will have your team wondering where you were all their life 😂.

In seriousness, here’s what you can expect:

⭐️ Main takeaways

• The 3 categories to ace to succeed at your first or new job

• Actionable takeaways for each category that most juniors aren’t doing

• For Seniors: There are some takeaways for you at the bottom :)

(1) Relationships 👩‍💻 🧑‍💻

The first and most important category is relationships. This is because your relationships funnel into everything you do. And it’s incredibly important for your teammates to see you as a positive contribution to the team.

So here’s how to ace this category:

Get a mentor

Hopefully, one is assigned to you. But if not, you should ask your manager for a dedicated mentor.

Your mentor will be able to give you more detailed, dedicated feedback and be a safety net for you on your projects you can fall back on for assistance.

But make sure you are adding value to them and not draining them.

One commonly missed thing is giving recognition and kudos to your mentor. Be sure to proactively help your mentor reach the next level by sharing positive feedback with your manager or on projects they helped on. This will make your mentor want to help you more since they directly see the impact on them of helping you.

Pair with teammates

One of the best ways to learn and grow at the same time is to pair program with your teammates. Here’s how you can approach it:

1. Start by scheduling an intro 1:1 with each of your teammates. Get to know them and ask questions about their life.

2. At the end of the 1:1, say, “I’d love to learn more about your day-to-day. Would you be open to me shadowing you or us working on a feature together at some point?”

3. They should say yes to (2). Schedule a pairing session with them. Use it as an opportunity to ask insightful questions, learn from them, and build a better relationship. If it goes well, you could ask to do it on a recurring basis (like monthly). You could also present it as a “catch up 1-1” or pairing if there’s nothing to talk about.

Be a participating member

One trap engineers fall into early on is being too quiet and not participating in discussions or activities.

Remember: You’re a member of the team now. You just need to slowly grow into it.

Very early on, it’s totally ok to be a bit more quiet while you understand the culture and dynamics. However, after a few weeks, try to be a part of team discussions like the other members are. Start by asking questions and over time jump in to add your opinion. Hopefully, the meeting facilitator will also call on you to ask for your opinion directly.

(2) Code 💻

The second category, Code, has a lot of things people miss early on. To be fair, you usually pick these up through mentorship. However, by reading here, you’re getting a head start 😉

I’ll mainly focus on advice for your “pull requests” (PRs) since code proficiency will come over time and pull requests are what your teammates see.

1. Comment on your own pull request. The general idea behind this is to do the work for the reviewer. For me, I call out areas I need more feedback on, areas that don’t need to be reviewed because there are no changes (maybe it was a file move), or explain why a particular change is needed if it’s not obvious.

   1. Example: “This part got a bit complex. Jared, would you be willing to provide feedback on the approach here?”

2. For UI changes, add screenshots and videos to your PRs

   1. If you’re working on front-end code, this is a hugely impactful way to increase the readability of your pull request. It also shows an additional level of polish that often gets missed.

3. Avoid large pull requests of 500+ lines. You want to do the minimal amount of code changes to achieve the desired end result.

   1. I remember a time when a senior developer joined our team and started making changes to an area of the code he hadn’t worked in before. It was amazing to see how he was able to make impactful changes in 100 lines or less, only making the smallest change needed for the end goal.

   2. Bonus tip: Iron out details that could lead to a larger pull request ahead of time. It can be frustrating on both ends to write ~500 lines of code only to realize there was something existing that could solve the problem or a much easier way of solving it. Run your approach by your mentor first on anything a bit more time-consuming.

4. Add links to any relevant context, like a JIRA / linear ticket, Figma URL, Slack threads, documentation pages, etc.

   1. Depending on your workplace, these may not be built into the process by default. So you can make yourself stand out by adding context most people aren’t adding.

5. Don’t just “do” comment feedback. Learn from them.

   1. It’s been amazing seeing a comment I wrote on one pull request leading to improvements in a future pull request. Conversely, it can be frustrating needing to leave the same type of comment multiple times. Be sure to learn from the underlying concern in any feedback you receive.

The general goal behind each of these is to work toward getting your pull requests approved right away, with fewer feedback loops, and minimal comments.

If you can get to that point, you’ll be seen as more independent and much more ready for a promotion to the next level.

(3) Mentality 🧠

The “junior” trap

While you might be “called” a junior, don’t think of yourself as that. You are a Software Engineer whose goal is to over time become more independent.

One thing that was nice about Gusto was that I was never called a “junior.” If it’s easier, you could think of yourself as “entry-level.” It helps with the mentality a bit.

The way I think of it is like affirmations. If you call yourself a junior every day, you’ll end up behaving more like a junior (being too dependent on team members, not trying things for yourself, waiting to receive work, etc.).

Optimize for growth

Early on, you have SO much to learn. Each week, assess that you’re actually learning.

In particular, don’t be afraid of taking on tasks outside of your comfort zone. Generally, you’ll have the safety net of a mentor or developers around you so it’s not as risky as you might think. If that safety net isn’t built in, hopefully, the mentor you got from step (1) helps with this.

Additionally, if you realize you aren’t growing from the work you’re doing:

1. Speak to your manager and ask about tasks you’re interested in and if you can help

2. Come up with ideas to improve the team that would optimize for growth better and propose them to your manager

3. Ask your teammates if you can “shadow” them. Being earlier in your career, your teammates will love this. It will show them you really care about growing.

Asking questions 💡

I’d argue this is the most important section of the article.

Here is the best advice I could give about asking questions:

1. Take advantage of your first few weeks on the job. Asking questions will be the most expected here. If you’re not asking any, it will raise suspicion.

2. Attempt to spend 20 minutes - 45 minutes on the problem before asking. If the question seems based on historical context, lean toward asking earlier. The lower time you’ve been at the company, lean toward asking on the earlier end of the range (shoutout to Principal Engineer James Willet for sharing this tip recently)

3. After you ask and get the answer, try to understand the full context. Ask, “How would I be able to find the answer on my own in the future?” Or “Are there resources you would recommend I check out on this?”

Number 3 is the most commonly missed step but also the most important for growth. Using classic phrases, by doing step 3 you “learn how to fish” rather than just “asking for a fish.”

I’m more senior, what about me?

So, you’re a Senior or you took the advice above and it got you promoted. Well, I promised to not leave you out.

So here are a few tips in case you knew the above ones already:

• Reach out to junior engineers to mentor them

  • Now that you’re at the senior level, it’s time to pay it forward! A common thing I’ve seen at the senior level is waiting for mentees to reach out to you. Well, remember how you felt early on. Make it easier for your future mentee and offer mentorship toward the end of your intro 1:1. “By the way, if you’d like to meet on a recurring basis for mentorship I’d love to help in any way I can. Let me know and I can set something up for us.”

• Improve team processes and developer productivity based on what issues juniors run into.

  • A lot of times as junior engineers onboard, they will do a team process or workflow exactly as it is right now. One opportunity you have as a senior is to make it easier for them, either through code or organizing a team process update. Example: I saw our existing process to add translated text to the app was very manual and involved a lot of copy-pasting. It was very tedious for our engineers. I spent 1-2 hours writing a script that automated the process to a CLI.

• Sponsor your engineers

  • Whether you’re a mentor or not, you can help your engineers get to where you are by sponsoring them. Advocate for them to take on interesting projects and offer your support throughout the process. When it comes to performance review time, explain to your manager what you saw that makes them ready for the next level.

A shoutout for job-seekers

(Not sponsored) For those interested in jobs at startups, I wanted to share the “Startups and Devs” Substack, as it may be of interest to you. There are postings roughly every week with URLs to apply:

Startup Dev Jobs of The Week [20th July, 2023]

📖 TL;DR

• Relationships: Ensure you have a mentor, meet with your teammates on a recurring basis, and become an active, participating member of the team.

• Code: Actively work toward having your pull requests approved with minimal comments and rounds of feedback.

• Mindset: Avoid thinking of yourself as a “junior,” but as an engineer whose goal it is to become more independent over time. Take on challenging opportunities and optimize for growth in your day-to-day. Lastly, learn how and when to ask questions.

• As a senior: Offer mentorship, make life easier for the engineers around you, and sponsor juniors for interesting projects and promotions.

---

As always, thank you for reading.

- Jordan

P.S. You can reply to this email; it will get to me, and I will read it even if I can’t always reply in a timely manner.

Did you find this issue valuable? If so, there are two ways you can help:

You can also hit the like ❤️ button at the bottom of this email to help support me. It really helps!