Onboarding Tips For Junior Engineers

Your goal as an entry-level engineer is to show autonomy after you've completed onboarding. If you're an intern or new grad, you are not expected to know everything (or much of anything!).

- The most important trait for early career folks is to seek feedback and act on it! **Coachability** is an important criteria for you (this is, in fact, how many interns are judged).
- Don’t “solo carry” a project. Instead, create milestones to measure and show progress. 
- Pair programming is especially valuable for learning from coworkers and building relationships.

Onboarding Tips Within Larger Companies

In a large company, you should expect a more formal onboarding process. However, don’t let this be an excuse to move slowly. Your goal is (still) to set up your environment and land code within a week.

Big companies will have many teams which may have slightly competing priorities. That means you need to invest in relationships and understand how the work connects between teams. Disperse and collect knowledge from around the company.

Spend some time understanding the unique terminology and culture of the company. Companies like Amazon, Meta, Google, Microsoft are large enough that they have their own set of acronyms, languages, and cultures!

Onboarding Tips Within Smaller Companies

Some relevant tips if you're onboarding as an engineer in a smaller company:

- Smaller companies will have less process and, therefore, a less formal onboarding. This means it's more important to get stuff done quickly since you can't rely on a bunch of classes or hand-holding.
  - A good benchmark is to land code within a week
- In a smaller company, a lot of knowledge will be in the heads of a few people
  - Your goal is to find the tenured people and ensure you understand their worldview and prioritization.
- Don’t assume processes or people exist. Especially if you come from a larger company, you should not assume that there is a well-defined QA (Quality Assurance) team or design team.

How To Know If You’re Doing Well

Your goal while onboarding is to connect your work to the bigger picture of what your team/org/company is working on, and build your own ideas around priorities.

**Signs that you're helping people**:

- Are you adding value? Are you able to help people newer than you?

- Are you able to improve the onboarding process and get feedback from coworkers about the changes you're making?

- Are you able to understand and contribute to code reviews?

**Signs that you're not doing well**: 

- You're not engaging with people on the team
- You're not getting assigned any work of value, even when you propose ideas
- You need constant support for the work you're doing

Thank People (A Lot!)

Properly thanking people is how you build social capital. Social capital is how you advance your career, build influence, and get promoted.

**Noob way of saying thank you**: "Thanks for the pointer" ❌

**Better way of saying thank you**: "That was so helpful, you unblocked a critical milestone of this project" ✅

Some other tips: 

- Thank them  in-person or over a call
- Write a heartfelt thank you note (1 paragraph)
- Let their manager know
- Thank in public forums
- Give them recurring thanks, e.g. in standup, at the team meeting, and when the project finishes

Ask For Specific Feedback

Key to learning quickly is getting effective feedback. This is especially important while onboarding, so you are able to course correct rapidly. Instead of asking the lazy question "Do you have any feedback for me?" add structure around the question: 

- **Task-specific** - what’s one thing that would have made this stronger?
- **Behavioral** - what’s something I do well that I should do more of?
- **Meta-level** - what’s the best way for us to share feedback with one another

Once you've been working with someone for a few weeks, schedule a dedicated 1:1 for feedback and let them know you'd love their honest opinion.

Uplevel Your 1:1s

1:1s are the bedrock for the budding corporate relationships you are entering into:

Three principles for effective 1:1s (see [Rahul's YouTube video on the topic](https://www.youtube.com/watch?v=ADWkkJtZna4)):

- Pursue awkward 1:1s
- Go beyond status updates
- Write down takeaways

For important people, you should **never** run out of things to talk about. Here's a starting point for what to discuss: 

- Reflect on what’s going well and not going well for you
- Reflect on what’s going well and not going well for the team (and team priorities)
- Ask for opportunities or resources
- Give feedback or ask for feedback
- Brainstorm
- Career/performance review planning

Meet The Team

Software Engineering is a team sport, and therefore building strong relationships with your team is a prerequisite for your success. Book 1 on 1s with teammates proactively, and for key people, look into recurring meetings for the first month or two.

One useful thought exercise: think about **who can throw you under the bus?** By doing this pre-mortem (analysis *before* an issue has happened), you can take steps to make them like you and prevent an issue to begin with.

The other key component to building strong relationships with your team is to prioritize in-person interaction. 

- Trust is much, much easier built when you're in person compared to remote
- If you’re hybrid, try to come in as much as you can. Align on days when other people are in the office.

Working With Your Manager

Your manager is the most important person for your career progression. If they don't support you, you will not get promoted. This means you should allocate sufficient time and attention to this relationship when you first join.

Rahul's suggestion for the bare minimum interaction during the first few months at the company:

- Weekly (or biweekly) recurring 1:1 meeting
- 30+ minutes

Two tips to ensure you get sufficient value out of the manager relationship:

- Let them know you’re eager for feedback
- Add structure to the interaction by writing things down and following a template for each meeting

If your manager frequently cancels 1:1s with you, use the running 1:1 doc with an agenda as a defense mechanism. People will think twice about canceling something if they know it's important to you.

Failure Mode: Fake Learning

*Fake learning* is when an engineer wants feels good by consuming an endless barrage of:

- Tutorials
- Books
- Blogs

These resources (crutches) are addicting because it's easy to monitor progress (40% done with the book!), but they turn out to be terrible for you to retain anything.

Software engineering is about action, not theory. Your goal is to reduce the amount of time from reading about a concept to putting it into practice in front of the computer. This is usually best done within the company, not on a greenfield project or external book you found. Get your hands on the keyboard, and realize that growth comes from discomfort.

Rack Up Small Wins

A promising sign for a new employee is if they can have a quick win, no matter how small. This means you want to avoid ambiguous or complex projects.

Ideas for quick wins:

- Share something your learned
- Update docs and tell people about it (not to brag, but to invite feedback)
- Improve wikis by adding screenshots: e.g. a screenshot or video of the setup flow
- Fix a "papercut," e.g. a misspelling in the code or a minor bug

Notice that many of the ideas above don't even involve committing code!

Talk link: [Don't Walk Away from Complexity, Run! (Venkat Subramaniam)](https://www.youtube.com/watch?v=d6CYdTOLW8I)

Figuring Out What Matters In A Codebase

In a large codebase, the code will follow the Pareto Principle (the 80/20 rule): 20% of the components account for 80% of the impact. So your goal as the engineer is to spend most of your time on the 20% of code that matters to the business and matters to your coworkers.

How do you figure out where that 20% comes from?

- Talk to people
- Use blames to find hotspots
- Look for patterns in code reviews
- Look at past alerts and what triggered them

How To NOT Learn A Codebase

The biggest mistake engineers make when going into a new codebase is to excessively read through the code and documentation. This is a horrible way to learn. 

The problem is exacerbated because the supporting documentation of the code is usually out-of-date: the docs can't keep up in a fast-moving tech company.

Instead, just dig in and start coding!

- Break things
- Add all the print statements ever
- Get the debugger working
- Run the code and see what happens

The key takeaway is that you should **get your hands on the keyboard** (even if it's uncomfortable).

Failure Mode: Excessive Handholding

A common failure mode of onboarding is that, even 6 months into the job, the engineer still needs support to make code changes. Either with their workflow or a technical question about the code.

The sign of progress as you ramp up is if your questions and code reviews are evolving over time. The types and depth of interaction you have with coworkers should change.

The key to doing this is to reflect:

- Look at earlier code comments you received
- Write down questions you’ve had
- Don’t make the same mistake twice
- Ask your onboarding buddy to look for patterns

Reference question: [What does it mean to not require handholding anymore?](https://www.jointaro.com/question/5vEWajcZlSi7nlohTGtJ/what-does-it-mean-to-not-require-handholding-anymore/)

Case Study: Setting Up Your Environment

One of the first tasks for an engineer in a new company is to setup their environment. 

- Your goal is **not** to setup your environment

- Your goal is to **do something that the environment setup enables**, e.g. make a copy or color change

Abstraction is essential when you’re working in a large codebase. Don't try to understand everything you come across: there will surely be a guide or script that you'll blindly follow, and that's ok. Keep your focus on completing the setup so you can make progress.

If you get blocked (*you probably will...*), forecast ahead what's coming and check if there's something else you can do in parallel.

Get Maximum Value Per Answer

You should "Learn how to fish" instead of "receiving fish" — your goal in onboarding is to become a self-sufficient, productive engineer as quickly as possible. 

The way you do that is to ask follow-up questions when you get help and understand how you would have arrived at the solution on your own.

Bias toward asking for help earlier when you're new to a company, since you don't know what you don't know. It's better to be more annoying for the first month on the job rather than somewhat annoying for 6 months.

Ask Questions Well

What makes a high-quality question?

- You get the help you need
- You build trust with the person/group that you're asking the question to

Question asking is a deep skill that requires you to add sufficient context (but not too much) so people can easily help you.

- Prefer to ask in public forums
- Realize that your question may help others beyond you
- Your questions are a valuable signal to the team 

When you are asking a question, please don't just say hello and wait for them to respond: <https://nohello.net/en/>

Your Onboarding Buddy

An onboarding buddy is someone who can help you adjust to cultural norms and direct your questions as a "catch-all." In addition to answering basic technical questions around workflow or code, the onboarding buddy is effectively lending their social capital to you to get you started. They are the safety net when you don't know who else to turn to. 

Rahul recommends that the onboarding buddy and manager be two different people. Your manager relationship contains a power dynamic in that you're interacting your boss, so you may not be fully vulnerable with them. The onboarding buddy is closer to a peer, which means you can get the help you need.

One of the most important roles for the onboarding buddy is to help you **figure out your support channels.**

The Common Misconception With Help

When you're new, there's an overwhelming amount of information to absorb. You should plan to ask many, many questions, which means it's important to have the right framing of that interaction.

Obligatory Confucious quote:

> The man who asks a question is a fool for a minute, the man who does not ask is a fool for life

Myth #1:

- **Myth**: Asking for help is a sign of weakness ❌
- **Reality**: You’re expected to ask questions to gain knowledge and foster interaction ✅

Myth #2: 

- **Myth**: Everyone knows so much more than me, I’ll waste their time ❌
- **Reality**: Each person’s knowledge is incomplete ✅

Instead of thinking that building expertise in something is difficult or impossible, realize that **you can become more knowledgeable than anyone** as long as you narrow the scope appropriately. (e.g. "In one afternoon, I can go understand more about the flags to configure **git log** compared to anyone on my team of 10 people.")

Have The "Meta Conversation"

A "meta conversation" is a **conversation about conversation**. It's a conversation you should have with coworkers to discuss **how** you should communicate.

- How often do you want to meet?
- How often do you want feedback?
- What is your preference for written vs verbal updates, and the format?

You will be working with your manager and team for 100s of hours over the course of a year, so it's worth spending some time at the beginning of the relationship to understand how you can best work together.

Tech Career Growth Videos

Our instructional videos provide software engineers with insights needed for career growth. Masterclasses go incredibly in-depth on a specific tech topic while case studies are real examples from established engineering leaders.