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.

Ace Your Tech Interview As A Software Engineer [Part 10] - Order Matters

We all want to speed run our way into FAANG. The bad news is that this is almost never pans out for software engineers, and aggressively pursuing this strategy can easily lead to your downfall. This lesson teaches you:

- The true way to actually get better at interviewing and why it can't be avoided (no matter how painful it is)
- How to properly structure your job search when Big Tech is one of your goals
- The general approach you should take when it comes to applying to jobs and sequencing your interviews

Ace Your Tech Interview As A Software Engineer [Part 34] - Don’t Be Weird

It is easy for software engineers to get desperate when looking for a job, and this can lead to things getting weird. The danger here is that if you're too weird, you can get automatically rejected. This lesson teaches you:

- How to send Thank You notes properly and how doing it incorrectly can lead to you failing the interview
- What to do if you were able to complete the interview problem just a couple minutes after the round ended
- The general framework to follow when it comes to post-interview communication

Here's Why You're Doing Interview Prep WRONG

Most people do very shallow interview prep that doesn't actually help them learn. Lists like Blind 75 and Leetcode 75 are not enough to truly master the technical interview for Big Tech companies. 

In this video, Daniel proposes the "proper" way to master the coding / DSA interview so that you can walk into interviews and feel more confident. There are no shortcuts and no memorization -- instead, it's about going beyond the solution for a problem, and then understanding the nuances and process to get the right answer.

- Connect with Daniel on [LinkedIn](https://www.linkedin.com/in/danieltomko/)
- Checkout Formation as part of [Taro Perks](https://www.jointaro.com/perks/)

Relevant Taro content: 
- [Effectively Learning Data Structures And Algorithms (DSA)](https://www.jointaro.com/lesson/XwpMMY3ss97zOrXJQ7Xr/effectively-learning-data-structures-and-algorithms-dsa/)
- [Struggling With DSA? Don't Worry, That's Healthy!](https://www.jointaro.com/lesson/SPWYdMAu5XQX8ds9MxXc/struggling-with-dsa-dont-worry-thats-healthy/)
- [Masterclass on DSA interviews](https://www.jointaro.com/lesson/V4sTACzfOh22nMVcUV3w/how-to-ace-your-big-tech-interview-data-structures-and-algorithms-7172021/)

Course Introduction: The Ultimate Guide To Navigating A Performance Improvement Plan (PIP)

You’ve probably heard about a PIP, a Performance Improvement Plan. You might be in danger of one, you’re going through one right now, or you’re about to join a company with a widespread PIP culture.

There’s no getting around it: **PIPs are scary.** Receiving a PIP means that there is a perceived deficiency in your performance, and something needs to change. It’s obvious why you might feel tremendous anxiety or fear around a PIP: your job is at stake.

Simply put, **a PIP is one of the most stressful things you can go through as a tech employee**. 

A quick online search reveals tons of discussion in forums about PIPs. It’s easy to get the impression that a PIP is a hopeless situation, and anyone who is unfortunate enough to receive one should simply give up. This is simply not true: whether you’re on a PIP or not, there is a path forward.

The objective for this course is to provide a structured way for you to identify what you can (and should) do to get the best outcome for yourself.

I’m Rahul, the course instructor. I’ve been an engineer at various-sized companies for a decade before I left to start Taro. I was an Engineering Manager and Staff Engineer at Meta (Facebook for the OGs), and before that I worked on Android at Pinterest. I graduated from Stanford with a Bachelor’s and Master’s degree in Computer Science, and my first job after graduation was founding engineer at a failed startup. 

In researching this course, I talked to dozens of engineers who have received PIPs, along with several managers who have delivered PIPs to their reports. You’ll hear some of their stories in the section dedicated to case studies (from companies like Amazon, Meta, Pinterest, MassMutual, and MongoDB). What became clear from chatting with so many employees is (1) there’s far too much stigma around a PIP and (2) there’s not enough support for people who have received one. This course aims to change that.

In addition, we’ve combined our own personal experience with dozens of hours of online research (we mostly ignored anonymous trolls in forums…).

I’ll occasionally refer to engineers throughout this course, but pretty much all the content is applicable to any type of tech worker (Product Manager, Data Scientist, Designer, etc). Software Engineers are not the only job function that must deal with a PIP!

Final note: my goal with this course it to be hyper-practical; this should be useful to you. I’ll be sharing best practices that have worked for many tech workers, but we can’t cover exact details across all companies in all geographies. I’m not an employment lawyer and I have never worked in Human Resources. You may want to get consultative help if your situation is unique. 

Connect with Rahul: 

- [Taro](https://www.jointaro.com/p/rahul-pandey/)
- [LinkedIn](https://www.linkedin.com/in/rpandey1234/)
- [YouTube](https://youtube.com/rpandey1234)

Read more about PIPs: 

- <https://jointaro.com/topic/performance-improvement-plan>
- <https://www.jointaro.com/blog/breaking-down-the-tech-company-mark-of-death-the-pip/>

Maximize Your Productivity As A Software Engineer [Part 7] - Get Good Sleep

Sleep is one of the first things to go when software engineers are faced with daunting workloads. Unfortunately, this is a tradeoff with disastrous consequences which doesn't even solve the problem. This lesson teaches you:

- Why most software engineers get sleep completely wrong in every possible way
- The correct perspective to have with sleep
- The many benefits of getting 8+ hours of consistent sleep every day
- How sacrificing sleep actually makes you less productive, not more

Strategies To Stop Procrastination

Procrastination: We all become masters of it in school, and for almost all of it, this terrible habit will continue long into our careers. This video covers how you can combat procrastination and maximize your work productivity.

Here are the key points from the video:

- Break down your overall goal into smaller pieces and strive to do just 1-2 pieces of it per day.
- Write things down! Clarity leads to action.
- After every week, reflect on how you spent your time.
- Find an accountability partner. Pair with someone else and commit to sharing progress updates with one another every single day. This social pressure will motivate you to do work as you don't want to be the person going into that meeting with no progress.
- Introspect and ask yourself if you're truly excited about the thing you're doing. If you're not, you might need to find that true passion.

Related resources:

- [\[Masterclass\] How To Manage Your Time Optimally In Tech And Achieve More Results](https://www.jointaro.com/lesson/rnX9EKpzc43TgGW9MozG/how-to-manage-your-time-optimally-in-tech-and-achieve-more-results-792021/) 
- [A Powerful Tool For Software Engineer Productivity - Focus Blocks](https://www.jointaro.com/lesson/uGdn2AiDfn3B07FkpIVR/a-powerful-tool-for-software-engineer-productivity-focus-blocks/)
- ["How do I optimize my sacred hour at work?"](https://www.jointaro.com/question/l8dzUVTu99CahofQsYAi/how-do-i-optimize-my-sacred-hour-at-work/)

Grow From Junior To Mid-Level Engineer [Part 4] - Structuring Your Growth

Even though junior engineer to mid-level engineer is the 1st and easiest promotion, it's still a meaningful evolution with many parts. This lesson teaches you:

- The 3 core areas of improvement to grow from junior -&gt; mid-level
- The most important area to improve to make the junior -&gt; mid-level promotion
- How you should process the advice from this course

The Key To Avoiding The Performance Improvement Plan (PIP)

Getting hit with a performance improvement plan (otherwise known as a "PIP") is one of the worst things that can happen to you as a software engineer. This makes avoiding a performance improvement plan one of the most important things for you to do, especially in the currently layoff-rich economy.

Here's the core points from the video.

- Your performance review rating should never be a surprise: Regularly check in with your manager to figure out how you're trending to avoid the dreaded PIP.
- On top of asking for constructive feedback regularly, you shouldn't be afraid to ask every 2-3 months if you're on track to get the rating you want once the formal performance review happens. The clearest way this manifests is a hypothetical rating: *"Would you give me at least a \[Meets Expectations\] for my performance so far?"* This is the most powerful way you can stay in sync with your manager.
- Make it clear with your manager that you'll take any hypothetical rating with a grain of salt, so they're more comfortable giving it to you. If you're brave enough, you can even ask them to err towards the lower-end so you don't overset expectations.
- Keep your eye on the ball: Keep referencing the expectations plan you made at the beginning of the cycle and evolving it as necessary.
- Turn it up at the later end of the cycle. Humans have bad memory: It's unfair, but recency bias is huge. Try to land your bigger wins just a few weeks or months before the formal performance review process starts.

Related resources:

- ["What's the difference between a low performer software engineer and a high performer?"](https://link.jointaro.com/QHkWNXoJV5Y9VYvH9)
- ["How do I help my manager (who is also my mentor) be a better manager and mentor?"](https://link.jointaro.com/eG5c6usaJNY9wopP8)

Write A Stellar Resume As A Software Engineer [Part 22] - Go Deeper: Follow Through

Download Alex's resume here: [Alexander Chiou Resume.docx](https://docs.google.com/document/d/1NnAx2jYkRTMCQwbdDPPqSj1Fwxkahda-/edit?usp=sharing&ouid=109380646850979301783&rtpof=true&sd=true)

If you have any questions about the content of this course or about your career overall, start a discussion in the Taro forum here: <https://www.jointaro.com/questions/create/>

Come to Taro events and join a resume review meetup: <https://www.jointaro.com/events/>

Join Alex for his Group Office Hours: <https://www.jointaro.com/p/alex-chiou/>

**UPDATE:** We have shut down Taro Networking as a feature. Sorry for the inconvenience 🙏

[Case Study] Effective Communication: Leading A Multi-Org Re-architecture At Meta

Here are [the presentation slides](https://docs.google.com/presentation/d/184dP9pi41lO5TlME4cn4fRblCPtKFdet7d5WmrpnbGc/edit?usp=sharing) and the [polished chat log](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/tps_chats%2Ftaro_premium_session_4_chat_notes.txt?alt=media&token=ca1a199d-fe36-42bc-8d2e-fc91371e691f) from the session.

As an IC, you don't have authority over engineers in the way a manager might. So your impact is defined by your ability to have **influence without authority**. Influence comes from consensus + collaboration, which comes down to communication. Said another way: Communication is the foundation for trust. 

Rahul talked about 3 parts to effective communication in this presentation: 
- **Start with the audience**
  - Understand how much context your audience has, and connect the dots for them.
  - Your communication should be as short as possible.
  - Bad news should never be a surprise.
- **Choose the right medium**
  - Do some reflection on what your objective is: build relationships or efficiently communicating some info? Be clear the difference between verbal and written communication.
  - Evaluate the current processes for communication in your org: standups, team meetings, email updates, cross-org communication. 
- **Be consistent**
  - You should have a regular drumbeat of posts for your projects. If you feel like nothing happened, you should explain why nothing happened.
  - For long-running processes like brainstorms or architecture reviews, you should consistently message the timeline and milestones.

Related resources:
- ["How can I come up with big initiatives, especially those at a Staff level?"](https://link.jointaro.com/sm57uikgXJ3RRpTv8)
- [Writing is thinking](https://medium.learningbyshipping.com/writing-is-thinking-an-annotated-twitter-thread-2a75fe07fade) - by Steven Sinofsky (Former President @ Microsoft)
- [Be plainspoken](https://boz.com/articles/be-plainspoken) - by Andrew Bosworth (VP of Eng @ Meta)

Asking Questions Is NOT A Sign Of Weakness

Believing that asking questions and requesting help is a sign of weakness is easily one of the biggest misconceptions among onboarding software engineers and just people in general. If you believe this, you are simply holding back your career.

Here are the core points from the video:

- **Nobody knows everything** - And because of this, asking questions is a fundamentally human experience. There will always be some corner of the ecosystem that you don't know, and this is especially true when you work at FAANG / Big Tech, even if you're very tenured there.
- **Liberally pursue support** - This is especially true when you're earlier-in-career or new to a team or company. As long as you're polite, humble, and empathetic when seeking help, you'll be surprised at how much support you can get and how happy your team is to give it to you. Follow the advice here to learn how to ask questions in this way: ["How do you overcome the fear of asking stupid questions / bothering people when you need help?"](https://www.jointaro.com/question/vNE8kgpx2zdI1wACg9jA/how-do-you-overcome-the-fear-of-asking-stupid-questions-bothering-people-when-you-need-help/)
- **Minimize the time that you're a n00b** - Let's say perception is a problem and people think you're annoying when you're asking for help as a new team member. It's much better to ask a *bunch* of questions in a short period of time and become very independent afterwards instead of asking a few questions here and there and prolonging the period where you're an inefficient newbie for 3-6 months and dragging down the team. The latter would be *much* more annoying.

Related resources:

- ["How do I not bother people when asking for help?"](https://www.jointaro.com/question/0Im1Kcgso1fJ8eAX3oOO/how-do-i-not-bother-people-when-asking-for-help/)
- ["How do I balance being more independent and asking questions?"](https://www.jointaro.com/question/cLsgiARaD5kVmV1BvdUi/how-do-i-balance-being-more-independent-and-asking-questions/)

The Rare Insight Top Tech Companies Have About Engineering Managers

Most engineering managers [EMs] are bad and aren't much more than glorified, overpaid whip-crackers. Here's what the world's best tech companies realize about engineering management that other companies don't.

Here are the core points:
- **Good EMs think long-term** - It's really easy to burn out the team for short-term gains, just working them harder and harder so everything ships quickly. However, this isn't hard to do and sacrifices the future of the team. Teams run this way eventually reach a state of weak productivity due to high turnover and completely drained engineers. Good EMs strive to operate their teams in a sustainable way, taking care of their engineers while also pushing for velocity.
- **Good tech companies hold EMs accountable** - In particular, EMs are expected to uphold the overall health and integrity of their teams. Companies like Meta explicitly score managers on how well they are able to give their engineers growth opportunities, preserve their work-life balance, and shield them from thrash so they have the focus to execute.

Related resources:
- [[Masterclass] What Software Engineers Should Look For In Their Engineering Manager](https://www.jointaro.com/lesson/oeY7ncZhzJ5NO6dij5e7/masterclass-what-software-engineers-should-look-for-in-their-engineering-manager/) - The full video where this clip was taken from
- [How Do Effective Engineering Leaders Help Their Teams Achieve More?](https://www.jointaro.com/lesson/xGJDCG7VL4hcZaq5XL92/how-do-effective-engineering-leaders-help-their-teams-achieve-more/)
- ["How do I figure out whether I should stay as an IC engineer or explore management as an EM?"](https://www.jointaro.com/question/Y6qIop9wpOlCYUL0nGs0/how-do-i-figure-out-whether-i-should-stay-as-an-ic-engineer-or-explore-management-as-an-em/)
- ["What are the commonalities and differences between tech leads and engineering managers?"](https://www.jointaro.com/question/c3MLGlkQgOQ6OUHANAxT/what-are-the-commonalities-and-differences-between-tech-leads-and-engineering-managers/)

Write A Stellar Resume As A Software Engineer [Part 14] - Show, Don't Tell

In order to write a great resume, you need to frame your experience as best as possible, getting maximum juice from the fruit. This lesson teaches you:

- The bar you need to clear in order to show that you have meaningful mastery of a technical area
- How to get metrics to describe the impact of your actions
- What showing looks like vs. telling, broken down through an in-depth example
- The difference between strong verbs and weak verbs
- How the recruiter and hiring manager perception of you drastically shifts depending on whether you used a strong verb or a weak verb

English Communication Is The Most Important Skill For Immigrant Engineers

The field of engineering is filled with immigrants. Silicon Valley is famously built from the creativity and hard work of immigrants around the world (China, India, Israel, and much more).

If English is your 2nd (or 3rd) language, only or mostly speaking your native language at work will hold back your career. Rachel talks about her misconception that communication skills weren't that important, and how to improve your speaking + writing.

If you want to get better at communication, check out our course: [\[Course\] Clear Communication For Software Engineers](https://www.jointaro.com/course/clear-communication-for-software-engineers/)

This thread is helpful too: ["How to improve my communication?"](https://www.jointaro.com/question/omak9oOT4NJE9dhKeMZi/how-to-improve-my-communication/)

Write A Stellar Resume As A Software Engineer [Part 21] - The REAL Secret For A Top Tier Resume

Unfortunately, it's possible to optimize your resume to the teeth and still not get results. This will be incredibly common for more junior engineers. This lesson teaches you:

- A simple 2-step process to understand how to make an incredible resume
- What to do if you have perfected your resume and you still aren't getting enough interview calls
- Why you are far more powerful than you realize the second you learn how to code and deploy software to production
- How to build impressive side projects that are meaningful on a resume and get you interviews
- How to make impressive open-source contributions that are meaningful on a resume and get you interviews

To dive deeper into building impressive side projects: [\[Taro Top 10\] Building Impressive Side Projects](https://www.jointaro.com/playlist/vKUWMgmmaEvzcYUXZs4B/)

To dive deeper into making impressive open-source contributions: [\[Course\] Become An Open Source Master](https://www.jointaro.com/course/become-an-open-source-master/)

Level Up Your Code Quality As A Software Engineer [Part 26] - Side Projects & Open-Source

You don't need to work at some fancy FAANG company to learn how to write truly good, high-quality code. Code quality is something that can be improved upon outside of your job and even if you don't have a job! This lesson will teach you:

- The power of **side projects** and **open-source contributions** when it comes to leveling up your technical skills
- How to build side projects that get a ton of users so you can maximize your learning (and your resume strength 💪)
- How to make meaningful open-source contributions that can even get the attention of Big Tech companies

To dig deeper into this topic, go through this thread: ["How to Learn/Practice Clean Code, particularly by oneself?"](https://www.jointaro.com/question/6DcTkiS9UJhDkQz1HIAL/how-to-learnpractice-clean-code-particularly-by-oneself/)

Ace Your Tech Interview As A Software Engineer [Part 8] - Interviewing While Employed

Finding a job as a software engineer is, in and of itself, practically a full-time job. But should you quit to actually treat it like an entire job? This video teaches you:

- Why currently being employed is usually the best time to find a new job
- The counterintuitive way that having a job boosts your interview performance when searching for another job
- How to find the time to do interview preparation when you're juggling a current job, including emergency levers
- The framework you should apply to determine if you should quit your current job for the job search grind

DSA Crash Course [Part 36] - Want To Learn More DSA With Alvin?

If you need additional support taking these DSA skills and actually applying them, take [**Alvin's**](https://www.linkedin.com/in/alvin-zablan-b73a92117/) *complete* data structures and algorithms course on [**Structy**](https://structy.net/?utm_source=taro). You can try out the concepts yourself in their interactive code editor and learn advanced DSA patterns like stack exhaustive recursion.

Use [**this link to get 20% off**](https://structy.net/purchase?promo_code=taro20) the entire Structy DSA learning experience.

Follow Alvin on LinkedIn: <https://www.linkedin.com/in/alvin-zablan-b73a92117/>

15 SWE Years In 1.5 Hours [Part 4] - Debugging

No matter how careful you are as a software engineer, your code will always have bugs. On top of that, you will also need to spend time fixing bugs in code written by other people. This lesson teaches you:

- Why debugging is always a valuable skill (while feature development often isn't)
- How debugging forces you to develop a deeper understanding of the system
- The framework and process you need to understand in order to fix any bug

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.