From Multiple Rejections to Landing Six Offers and Negotiating A $100K Raise

*Unlock all events and courses with Taro Premium. Join at a discount with Yogi's link: [**https://www.jointaro.com/r/yogi-sharma/**](https://www.jointaro.com/r/yogi-sharma/)*

In 2017, amidst the bustling innovation and relentless pace of Facebook, I encountered a pivotal moment in my career. The sting of receiving not one, not two, but three job rejections in as many weeks (and *first round rejections* at that) set the stage for a profound professional transformation. This period, marked by deep introspection and resilience, was not just about coping with disappointment; it became a launchpad for unprecedented growth and success.

But all that came after an initial period of dejection.

The journey from those initial rejections to eventually landing six coveted job offers, with negotiations exceeding $100k, is a testament to the power of strategic habit shifts and mindset realignment. The experience, while daunting, unfolded the essential principles of leveraging one’s time and energy efficiently, ensuring readiness for job transitions *without compromising current job performance*.

In this talk, I aim to demystify the path from setback to success. I will unveil the practical strategies and mental adjustments that not only helped me navigate the turbulent waters of job searching but also equipped me with the tools to excel beyond expectation, which I have used in my work with over 400 professionals in my coaching practice. This narrative is more than a personal victory; it's a blueprint for anyone facing the disheartenment of rejection, providing actionable insights to transform challenges into opportunities for substantial growth and achievement.

Join me as I dissect the critical principles, mindset shifts, and habit changes that can empower us all to turn job search woes into wins, illustrating that with the right approach, navigating the job market can be a journey of triumph even though tribulation are inevitable at times.

Negotiation content on Taro:

- [**\[Taro Top 10\] Pay Negotiation**](https://www.jointaro.com/playlist/uyWSc5q79zFw2Ei7w59d/)
- [**\[Masterclass\] Understanding And Optimizing Your Pay In Tech**](https://www.jointaro.com/lesson/gk408yBIV2fa5RjVR213/masterclass-understanding-and-optimizing-your-pay-in-tech/)

Yogi's next event about going from the PIP danger zone to a top performer: [**https://www.jointaro.com/event/behind-the-scene-from-meets-most-greatly-exceeds-in-3-months-at-facebook/**](https://www.jointaro.com/event/behind-the-scene-from-meets-most-greatly-exceeds-in-3-months-at-facebook/)

Yogi on LinkedIn: <https://www.linkedin.com/in/yogi1/>

What Happens After Onboarding Success?

Congratulations, you made it to the end of the course, [The Complete Onboarding Guide For Software Engineers](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)!

Here are the major takeaways we covered:

- Attack your onboarding with a plan
- Figure out your support channels
- Make it easy to receive help
- Get your hands on the keyboard

Send me feedback at [team+onboarding@jointaro.com](mailto:team+onboarding@jointaro.com)

Pass On Your Onboarding Knowledge

After you've completed onboarding, one immediate value you can create is making life easier for the next person. Improve the onboarding process, support more junior engineers, and continue building relationships.

Onboarding is fundamentally about building trust. (Remember the [trust meter from the beginning of the course](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/why-onboarding-matters/)?) Trust is the currency through which you grow your career, and you’re always gaining or losing trust. Trust is how you get influence, which is essential for further career growth.

Onboarding With A Probation Period

Because labor laws outside the US can make it difficult to fire someone, many companies will add more barriers before you are a full-time employee at the company with benefits. They will make employees work during a probation period before deciding to offer full-time employment. Contract-to-hire is another common way that this manifests ("try before you buy").

Here are some tips if you're working on this model:

- Chat with your manager early (ideally even before you join) so you can hit the ground running and make a good first impression.
- Information access may be limited, so call out when this happens. You don't want something outside your control to reflect poorly on you.
- Understand the criteria you’re being judged on, e.g. code commits, code reviews, design docs, etc. Track these metrics diligently, and you can even report on them regularly.

Relevant discussion: [I’m starting at Apple with a 3 month probation as a new grad. How should I think about the probation period?](https://www.jointaro.com/question/JtFLSdc1ShdaqiIyFcqe/im-starting-at-apple-with-a-3-month-probation-as-a-new-grad-how-should-i-think-about-the-probation-period/)

Onboarding Tips For Senior+ Engineers

As a Senior Engineer (or Staff or Principal) coming into a new company, there will be some expectation that you are bringing in domain knowledge. Your opinion can be valuable. A few ways to have immediate impact:

- Contrast how your current company operates compared to past companies
- Ask questions about why certain processes exist or don't exist

As you ramp up, remember to "**respect what came before.**" You don't want to disparage existing systems without realizing that it was best designed at the time of construction with the constraints and knowledge *at the time*.

As a senior engineer, you also need to lay the foundation for team and org-level impact. This means you invest extra time in building relationships and meeting other senior/staff/principal engineers.

Senior Engineer video from krazam: <https://www.youtube.com/watch?v=eSqexFg74F8>

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.

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.