Here's our masterclass on writing great code fast.

Be A Code Machine

Learn how FAANG tech leads scope out big projects.

System Design Series

Learn from the world's best senior engineers.

FAANG Case Studies

Don't miss our event on forging deep work connections.

Build Relationships

Here's our masterclass on achieving more every day.

Time Management

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.
- **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.

This clip is from our masterclass on how to succeed at a new team or company as a software engineer. [Click here to watch the full thing.](https://link.jointaro.com/9sJzfDeH3JdWzZRg9)

Related resources:
- ["How do I not bother people when asking for help?"](https://link.jointaro.com/YUXCdqG6mxPJn3Uf7)
- ["How do I balance being more independent and asking questions?"](https://link.jointaro.com/RvjcSyXKbVR6FAt56)

How To Write Better Code Faster As A Software Engineer - 11/19/2022

Code: It's the main thing software engineers care about. However, as we all know, writing code quickly while keeping it clean can be extremely difficult. This is what this masterclass will help you with: We want to empower you to not only write more code, but write higher-quality code as well.

There were a ton of important points from this masterclass, so here's our Top 5 (in no particular order):
- **Go deep, not wide** - One of the most common mistakes junior software engineers make is not focusing on just 1 stack, often captured by being a "full-stack engineer". When you go ultra-deep on just 1 stack, you will start developing software engineering fundamentals and "muscle memory" that allows you to write code a lot faster. It will generally take 2-4 years of focus on just 1 stack to start getting really good at it. For more information about this point, [check out our video on how software engineers should initially learn](https://link.jointaro.com/hoL4o29S3YsGsR9i7).
- **Build side projects** - There's no magic to getting better at coding: The more you do it, the stronger your skill. This is why side projects are so powerful: They allow you to write more code without overworking yourself. To learn more about this, check out ]this expert career advice on how side projects can really level up your performance on the job](https://link.jointaro.com/ox9ae9Vbi7k3zWAf6).
- **Submit polished pull requests** - There's more to code than the raw lines you put into commits; how you submit it for review is a huge factor as well. If you take the time to make atomic PRs, add context, and attach a thorough test plan, your code will be landed much faster (and your team will love you for it). For concrete examples on what this looks like, [check out our video on "One Diff, "One Thesis"](https://link.jointaro.com/5Ehehxt6jBR42ui1A).
- **Really absorb code review feedback** - The main way you will learn as a junior engineer or as an onboarding team member is by getting feedback on your code. Make sure to respond to code review feedback in a timely manner (<4 hours) and really soak it in: Strive to never make the same code quality mistake twice. [Here's our in-depth advice on how to get high-quality code review faster](https://link.jointaro.com/qyG7Yw6EqJ8DGNad7).
- **Modularize your code** - Split your code up into focused components with single responsibilities and thoughtful names. When you do this, your code will be much more flexible, reusable, and easier to read. [Here's our advice on how to break down large projects into more digestible chunks](https://link.jointaro.com/LcgMPkVFebuJus7QA).

Related resources:
- [[Masterclass] How To Manage Your Time Optimally In Tech And Achieve More Results](https://link.jointaro.com/8D6Y6BnYm8696RtC9)
- [[Masterclass] How To Do Amazing Code Review](https://link.jointaro.com/8D6Y6BnYm8696RtC9)
- ["What can I do to quickly build my reputation as a junior engineer?"](https://link.jointaro.com/hxCTvumsQhUqRAbn6)
- [Presentation slides](https://docs.google.com/presentation/d/17o6XlEjiYbkV1FMrhOoFwcM1O59NmdAOfZ3AXol7daY/edit?usp=sharing)

The First Thing You Need To Do Before Figuring Out Your Next Company And Team

Choosing the right company and team for you as a software engineer is one of the most important decisions you'll make, and given the high turnover in the tech industry, is a decision that you will have to make multiple times. This is why having the right mentality here is so crucial, which is what this video covers.

Here are the core points:
- Everyone is different - There is simply no "one size fits all" career path for everyone. FAANG companies are great overall of course, but there are going to *many* people and situations where it doesn't make sense to go there.
- Before thinking about your next move, have an honest conversation with yourself and those close to you about your priorities. *Your goal is to create a stack-ranked lists of your priorities.*
- Prioritization is a much harder exercise than people realize as there's simply so many angles to it. Here the ones mentioned in the video:
  - Compensation
  - Work-life balance
  - Company prestige
  - Supportiveness of team
  - Growth opportunities
  - Stability
  - Maximum outcome (risk tolerance)
  - Remote work
  - Product space
  - Company ethics
  - Technical space
  - Level/title
  - Benefits
  - Location

This clip was taken from our [1.5 hour masterclass on finding the best company/team for you, which you can click here to watch](https://link.jointaro.com/F4DDyKfuo3hMhj868).

Related resources:
- ["How do I know when it's time to leave a team/company?"](https://link.jointaro.com/XjqqgzbCGfRXagYC7) - This is the Q&A that Rahul mentioned in this video.
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://link.jointaro.com/n57gbTWERveGTQuM9)

How To Succeed At A New Team Or Company As A Software Engineer - 10/29/2022

There are **ton** of great points in this presentation, so to prevent this summary from being a 10 page essay, we're only including our Top 5 points:
1. **Asking for help != weakness** - In fact, it's quite the opposite: Trying to figure out everything on your own and not asking questions is what makes you weak. Being comfortable with your cluelessness and putting yourself out there aggressively to get all the help you need is what makes you strong. You can [learn more about this dynamic here](https://link.jointaro.com/NfLv7hrkxd6wdEVZ8).
2. **Get maximum value from questions** - Ask high-quality questions and ask follow-up questions to really understand the answers your teammates give you and the systems they followed to arrive at those answers. Your goal is to learn skills in a sustainable way that makes you more independent as opposed to needing hand-holding all the time. [You can learn more about what it means to not require hand-holding anymore here](https://link.jointaro.com/JBFXjwnoyq1iiRt76).
3. **Don't get trapped reading the code and documentation** - The only real way to learn a codebase is to just hop in, start changing code and seeing what happens. Software is all about learning via doing. You can [learn more about how to learn a codebase faster here](https://link.jointaro.com/WsN6429SYUhsdTps8).
4. **Thanking people is a skill** - When you're onboarding especially, it is crucial for you to show your gratitude effectively: Don't just do the basic, boring "Thanks for the help!" DM over Slack/Teams after you have been helped. Send the helper a heartfelt note, tell them in person, or let their manager know about their great deed. You can [learn more about "deep thanks" here](https://link.jointaro.com/RcRpQT7ns5YggLTW7).
5. **Be empowered to help others, even when you're new** - Anyone can help others, even the newbie. In fact, newbies are equipped to add unique value by having a fresh pair of eyes, particularly around improving the onboarding process for others. If you're onboarding, make it one of your priorities to earn respect as that will make the entire onboarding process smoother for you.

For more premier resources on onboarding:
- [How Alex became a tech again in just 1 month after switching into Robinhood from Meta](https://link.jointaro.com/vfgfDhbKMymQPGPo7)
- ["How do you overcome the fear of asking stupid questions / bothering people when you need help?"](https://link.jointaro.com/DqoCYkqncsEtUGDt9)
- ["How can I become more independent and better at unblocking myself with tricky technical issues?"](https://link.jointaro.com/xE8oMpCaDYjuMhCg7)
- [Presentation slides](https://docs.google.com/presentation/d/1MTs7GIklpVnYrA_JRlgcpKu1reeTLto1kYEsa6M8UqI/edit?usp=sharing)

System Design Series: Taro Playlists [Part 7] - How Can Things REALLY Break?

Proactively talk about potential incidents when you are going through your **system design**. 

[Click here for Part 8, "Breaking Down The Work And Timeline".](https://link.jointaro.com/v8kxu9yzQkTYAr84A)

You can [find the full system design doc here](https://docs.google.com/document/d/15WaM8Ojan82g0m2mtz6kC2Hiyj0Q6VbjfqRmVNDI3qw/edit?usp=sharing) - Feel free to use it as a template for when you're designing systems at your job!

The tactics are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:
- You should *always* think about "How can we cause a SEV?" when you're planning out any substantial project or task.
  - **Context:** SEV = Severity, which is the term Meta, Robinhood, and many other companies use to describe a really bad product event.
  - This is one of the purest and most critical manifestations of proactive thinking, which is one of the trademark attributes of a competent senior+ engineer and tech lead. SEVs are events that seriously set back your organization or even your entire company if they're something you have to react to as opposed to catching them early.
- This "anti-SEV" thinking is *especially* relevant for Big Tech where the stakes are much holder due to regulatory constraints, increased media presence, and a massive scale of users.
  - It's also far harder to do this well at Big Tech due to a greater range of ways things can break.
  - However, if you can do this well, you will add a tremendous amount of value to your team. This is why pretty much all senior and staff engineers at FAANG and FAANG-equivalent companies have really developed this skill.
- Here are the ways a SEV can happen from the video (these are all vectors Alex dealt with at Meta as well):
  - **Users not playing nice** - You should never assume that users will put in proper inputs or even not want to harm other users. Most major tech products have some sort of multiplayer component, so it's important to be vigilant here.
  - **Bad auth context** - This means that users are able to carry out actions on behalf of other users. This can happen either intentionally (i.e. the acting user is malicious) or accidentally (e.g. the user has multiple accounts on your service and switching between them cleanly is broken).
  - **Incorrect backporting** - "Backporting" is the process of making things work on older builds of your software. This is *very* relevant for mobile engineers as there will always be a good amount of users on older builds, especially if your product is used by people in regions with lower internet.

System Design Series: Taro Playlists [Part 1] - What REAL System Design Looks Like

This video is the introduction to our **system design interview** series.

Core points from the video:
- **System design interviews** are more analogous to your actual job than **data structures and algorithms**, but there are two big gaps:
  - **Overly grandiose exercises** - You will never get a technical problem on the scale of "Build all of Netflix", especially if you work at a Big Tech where you will get something much more local as most of the biggest problems at these companies are already solved.
  - **Time constraint** - Because interviews are time-boxed to 45 to 60 minutes, you have to do very broad strokes. In real life, **system design** should be much more thorough and has more steps and technical writing.
- To make this series as authentic as possible, we are going to breaking down an actual upcoming feature within Taro: Playlists! On top of this:
  - This **system design** is exactly how Alex would design a system if he were still at Meta/Robinhood as a tech lead. While Taro doesn't need something this granular as a startup, this series simulates many aspects of a more mature company.
  - Alex has made a very thorough 9-page **system design** doc going through every aspect of the system.

[Click here for Part 2, "Sharing The Context".](https://link.jointaro.com/XN7Hvsa2273RB1iB8)

For the full **system design** doc, you can get it by [becoming a Taro Premium member](https://www.jointaro.com/membership).

Session #7 - Building XFN Alignment Across Multiple Orgs (w/ Staff Engineer Cat Chen)

[Cat Chen](https://catchen.me/) talked about his success building alignment across multiple orgs. 

Cat was working at Facebook as a Staff Engineer on the growth team. His charter to get the Android apps on app stores beyond the Play Store. (There were 10+ non-Google stores where Android apps get downloaded with some level of traffic.

Getting an app listed on a 3rd-party platform is simple – sign up as a developer on that platform; upload the Android app for review; wait for approval and launch it. Just as simple as publishing to Google Play.

**BUT it's not that simple at a company like Facebook.** Facebook lawyers wouldn’t allow Cat to accept the Terms of Service on behalf of Facebook the company. Cat didn’t have the privilege to bind Facebook into this contract and even if he did, the lawyers would certainly advise against that.

Instead of simply handing this problem to another person or org, Cat met with a director-level lawyer. Given he was on a different time zone, and in a different job function altogether, this took some legwork. The director explained the risk profile (Facebook could have unlimited downside by blindly accepting an agreement). Eventually Cat discovered a workable solution by using a contracting company to sign the legal agreement, which limits the damages that Facebook may face.

Impact of this work: 
- Successful launch of the existing Android apps
- Ability to launch other apps in the future
- Deep and positive relationship with the legal team, and Cat owned that relationship (which made him indispensable)
- **Almost zero lines of code written!**

[Connect with Cat](https://www.linkedin.com/in/catchen/)

For more resources on how to communicate, build alignment, and operate as a Staff Engineer:
- ["How do I sell the vision behind a large, org-level project?"](https://link.jointaro.com/NGCrB2ifkkpDaDe69)
- ["What's the Difference Between A Senior And Staff Engineer?"](https://link.jointaro.com/BEM2RAjPFe8Pv7826)
- [Guide to Effective Communication](https://link.jointaro.com/mP3WEd4zt5ecnupX6)

"What can Taro Premium do for me?" - 10/7/2022

If you're looking for a job, [check out our video on how Taro can help you with that](https://link.jointaro.com/e5Swdksn8886KrQs9).

**Intro Chat**
- Every new Taro Premium member gets to chat 1 on 1 with a Taro cofounder for 30 minutes. This is something we can do at this stage since we're so early!
- The point of the call is to help you immediately with any questions and job issues you have and get an understanding of your longer-term career goals in general. From there, we can provide a personalized collection of relevant career resources just for you.

**Group Office Hours**
- We love helping people directly, so after the initial 1 on 1 call, we have group office hours every week.
- Each group office hours is led by a Taro cofounder, and it's meant to be a flexible, intimate, and communal way for you to get the help you need and just learn from other talented software engineers and their problems.
- You can drop in and out whenever, and if you want to stay anonymous, just join with an online name, video off, and share your question in chat. These sessions are not recorded to protect everyone's privacy.

**Taro Premium Sessions**
- These happen ~2 weeks and are exclusive live sessions where senior+ engineers come in and give a case study of some way they were able to find success in their careers.
- Given that they're specific and concrete, it is easy to use them as an example to come up with ways you can currently level yourself up at your current job.
- Here's a couple of them:
  - [How Rahul Built An Internal Tool Used By 100s Of Engineers To Get To Staff At Meta](https://link.jointaro.com/XsdHNht9bmBpzXeTA) - This one has been made free for all users of Taro!
  - [Mentoring Junior SWEs [E3] to Senior [E5] In Just 2.5 Years At Meta](https://link.jointaro.com/pEz7ZKsgpp3VBMAY7) - This premium session goes through how Alex grew software engineers at light speed at Meta, which he's now doing at scale with Taro Premium members and the entire Taro community as a whole.
  - [Becoming A Tech Lead In ~1 Month After Switching From Meta To Robinhood](https://link.jointaro.com/C99mq85ivCWyTbAM8) - A lot of Taro users are starting new jobs or are about to, so this is a great example of how to hit the ground running and deliver impact quickly, which is a hard requirement for senior+ engineers at companies like FAANG.

**Q&A Platform**
- As a Taro Premium member, you can ask any amount of questions and always get a guaranteed credible, in-depth, actionable response that is much higher quality than 99% of content you'll find on more public forums like Blind and Reddit.
- You can also view all other questions asked by the Taro Premium community. Questions are indexed by company and level, so you can find the career advice that's most relevant for you.
- Free question examples:
  - ["How to survive potential layoffs?"](https://link.jointaro.com/Z6yrx1fcjYheCTKW8)
  - ["How can I become more independent and better at unblocking myself with tricky technical issues?"](https://link.jointaro.com/xE8oMpCaDYjuMhCg7)
- Premium question examples:
  - ["How can I write great code faster?"](https://link.jointaro.com/7dMeqXwrGceNM3kr6)
  - ["How to identify projects that are more suitable for senior engineers?"](https://link.jointaro.com/PTs28oYaYUNk7Ba17)

**Masterclasses And Courses**
- Every ~1.5 months, we give an *extremely* in-depth 1 hour+ session going deep on specific topics. All of these are free to attend, but the recording and text insights are for Taro Premium members only.
- Example masterclasses:
  - [How To Choose A Good Team And Company As A Software Engineer](https://link.jointaro.com/RMfMmsJVnVhTfFQo8)
  - [How To Do Amazing Code Reviews And Write Clean Code](https://link.jointaro.com/29jyjjRiaUBZ1htQ9)
- Also every month or so, we will release an in-depth course by industry experts on a specific topic. The initial parts are free, and the full course is exclusive to Taro Premium members. As an example, [here's our course on effective communication](https://link.jointaro.com/VReQtMPn7rPa3gUB7).

**Taro Premium Community**
- All Taro Premium members are invited to an exclusive Slack space, which we're proud to say is one of the most talented, ambitious, and helpful group of software engineers and people in tech in the world.
- Here you can network with other ambitious folks in the tech industry and learn from one other, pair up for mock interviews, and share referrals.
- Rahul and Alex are always 1 Slack DM away from helping you!

If all this sounds good to you, [you can get Taro Premium here](https://www.jointaro.com/membership). If you have a learning & development (L&D)/education budget, you can expense Taro Premium and get it for free! [Here's the template you can use to get Taro Premium expensed.](https://docs.google.com/document/d/1xpY2XBKTpiMN-o7U2c1pvqai5afQSVIuGMgQZiB-_Rg/edit)

How To Choose A Good Company + Team As A Software Engineer - 10/1/2022

Choosing the right company (or team) is one of the highest leverage decisions you'll make in your career, so it's worth doing some reflection!

It’s all about your priorities
- Figure out what’s important to you and what’s not. Create a stack-ranked list of all of these and work backwards from the top 2-3 to figure out the best opportunities for you
- People don’t realize how many angles there are to this. Here’s all the ones from the presentation: *Compensation, work-life balance, company prestige, supportiveness of team, growth opportunities, stability, maximum outcome (risk), remote work, product space, company ethics, technical space, level/title, benefits, location*

Supportiveness and overall quality of the team are often underrated
- It’s really hard to grow and have a healthy work life without this
- If you like your manager/teammates and you feel like you’re regularly learning/being challenged by them, deeply cherish that. People underestimate how hard it is to find an environment like this. Even in a prestigious company like Big Tech, this is difficult to find.

Big Tech vs. Startups
- At the end of the day, it’s all about your risk tolerance - Startups can have insane monetary/promotion outcomes, but they also might collapse the next year.
- In a vacuum: Start off at a Big Tech company to build a good foundation and then switch into smaller companies to have more scope/ownership

Some things you should NOT spend time on: 

❌ Don't focus on how much you liked (or did not like) the people in the interview process. The recruiter/interviewer is NOT representative of your life at the company. Instead, focus on trends of the people joining the company, rather than individual data points.

❌ Don't spend time looking at the financials of the company. Even if you do decide to dig into the numbers, there's a good chance you'll screw up the interpretation -- humans have a really hard time with exponential growth. 

Learning the quality of a team
- Talk to engineers/ICs if you can - The manager will inherently be biased towards their own team as they are often goaled on hiring
- Make sure that the team has a healthy oncall process and fast code review iteration

Related resources:
- [Full 1.5 hour session on finding a great engineering manager who will support you](https://link.jointaro.com/r6A67w77hYobJge79)
- [“How can you tell if a large public company is going in the right direction?”](https://link.jointaro.com/qqwNf65YZJsiU5JY9)
- [“What does it mean to not have enough scope to be promoted?”](https://link.jointaro.com/NEqz7SCR63g4kN2eA)
- [“What should I look for in a new team in terms of growth?”](https://link.jointaro.com/vd3HM4Zaju8Zeun57)

"How can Taro help me find a job?" - 9/27/2022

The answer to this question is "in many, many ways", whether you're on the free or paid version of Taro. If you're aiming to get into a high-performance tech company like a hyper-growth startup or Big Tech, we would love to help you on Taro Premium and be your long-term career guide. *We firmly believe that succeeding on the job is much more important (and more difficult!) than figuring out how to switch jobs.* You can [join Taro Premium here](https://app.jointaro.com/membership).

That being said, here's just some of the best resources we have in Taro to help you with your job search:

**Resume**
- Free resources:
  - [Explaining Your Experience In A Meaningful Way On A Resume](https://link.jointaro.com/3Nu3PiC1KYGiqaX36)
  - [Creating A Portfolio That Makes Recruiters Come To You](https://link.jointaro.com/AzorekUXa4uMdGHM9)
  - ["How do I balance my time between studying DSA and fleshing out my portfolio?"](https://link.jointaro.com/zeiTZK1fSSax6o3f9)
- Premium resources:
  - [Full in-depth 1 hour+ session on writing an effective resume](https://link.jointaro.com/qWzEyejk7AxRxr3GA) - This includes a link to Alex's current resume, which uses the format that got him into Facebook. It's a template, so you can use it to model your resume as well!
  - Get your resume personally reviewed by Alex/Rahul

**Interviewing**
- Free resources:
  - [Effectively Learning Data Structures And Algorithms (DSA)](https://link.jointaro.com/ZaPBLyhXXqYCJS2J8)
  - [Having The Proper Mindset For Interviews](https://link.jointaro.com/q39YYZjoe7euqF749)
  - [Truly Mastering A DSA Problem - 2 Sum Example](https://link.jointaro.com/pRXTapy99BEKdiz6A)
- Premium resources:
  - [Full 1 hour+ Masterclass On Acing Your Big Tech DSA Interview](https://link.jointaro.com/VfSeuUFiXNtKa5if7)
  - [Full 1.3 hour Masterclass On Acing Your Big Tech System Design Interview](https://link.jointaro.com/Tmqs62Lw7WV4qDw59)
  - [How Alex Got Into Meta With 0 Prior Leetcode Experience](https://link.jointaro.com/vaNH1hjRUhmF8ibSA)
  - Pair with other engineers in the exclusive Taro Premium community for mock interviews in the #member-matching channel

**Finding The Best Job For You**
- Free resources:
  - ["How do I know when it's time to leave a team/company?"](https://link.jointaro.com/7EqTrhgW9c8bwFc98)
  - [Questions You Can Ask To Evaluate An Engineering Manager](https://link.jointaro.com/tmKfeBDgLvByGYCB8)
  - ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://link.jointaro.com/19uVnq9GMFPMbg4d9)
- Premium resources:
  - [1.5 hour masterclass on finding a great team/company for you](https://link.jointaro.com/RMfMmsJVnVhTfFQo8)
  - Personalized offer evaluation help from Alex/Rahul
  - Learn about other companies in the Taro Premium network, comprised of engineers from the world's best tech companies
  - Learn through company-specific Q&A what each company and its culture is like

What's the Difference Between A Senior And Staff Engineer?

The mark of someone who is NOT ready to be a staff engineer: Asking what needs to happen to get to staff. 

A staff engineer should identify problems worth solving, and then get buy-in across the org to solve the problem. 

- Despite each staff engineer's journey being different, there's still an opportunity to learn from the examples of other promotion cases. Here's an example from Rachel's days at Yelp with a talented staff engineer:
  - Google announced an algorithm change for SEO ranking, which would favor websites with better mobile friendliness.
  - An engineer on a feature team recognized that this would hurt Yelp and brought it up very proactively.
  - They drove a proposal and broke down the problem with several domain experts in the organization.
  - It took a while, but they were able to ship a quality, long-term solution.
- Instead of just looking at "what" new problem to solve, there's also opportunity for very senior engineers to breakdown the "how" to accomplish a large, ambiguous problem and get to staff.

If you enjoyed this video, [use this link to see the rest of Rachel's awesome career advice on Taro](https://link.jointaro.com/Cm5rJk4RJTkWhhnq7).

For more resources on getting to staff:
- ["How can I come up with big initiatives, especially those at a Staff level?"](https://link.jointaro.com/sm57uikgXJ3RRpTv8)
- ["For a Staff engineer at a Big Tech company, what should their first 3-6 months look like?"](https://link.jointaro.com/rm74iUg3NnHcXQdX6)
- ["How do I come up with innovative, impactful ideas and bring them to my team?"](https://link.jointaro.com/g7KqPeywyBXQ5VvZ6)

Effective Communication Guide [Part 3] - Building Relationships

- **Relationships are all about trust** - The more someone trusts you, the more they will share with you, and the more effective your collaboration can become. The 1 on 1 meeting is the most mechanism to earn this trust.
- **Trust by default** - Trust is extremely hard to earn and very easy to lose. The best way to earn someone's trust is to give them a lot of your trust. This will trigger a response where they will strive to follow The Golden Rule, giving you more of their trust to make things balanced. For an example of trusting by default and earning trust lightning fast, check out [our deep dive into great mentorship here](https://link.jointaro.com/YdUM4JP89Sjh7ruv5).
- **Make small talk** - 2-5 minutes of small talk per 1 on 1 can go a long way. By talking about things outside of work, you are showing that you truly care about them as a person.
- **Be honest** - Tell it to people straight, and don't mince words. By showing that you're comfortable sharing what you're genuinely thinking, people will want to do the same. This is especially powerful when talking about problems.
- **Use humor and self-deprecation** - Everyone likes to laugh: It's a very human thing to do. Crack a joke here and there when you can. Self-deprecation is effective as it's safe (you are poking fun at yourself instead of someone else) and shows your humility.
- **Show thanks** - Don't take your colleagues doing great work for granted: Doing great work is always hard. There is really no such thing as giving too much thanks and making people feel too appreciated. *This is a severely under-utilized technique*. Giving heartfelt thanks is supremely powerful - You can turn someone's bad day into a good one.

Effective Communication Guide [Part 2] - Basic Tactics

For the full 9-part "Effective Communication" course, [you can find it here](https://link.jointaro.com/kWQkRyRhLqbTWBty7).

- **Use tentative language** - You can always be wrong, and you should acknowledge that in how you communicate:
  - Bad: "Your code isn't performant."
  - Good: "I think this code may have performance issues."
- **Body language matters** - Communication isn't only the words you say or write, it's also how you express with your face and body. This is something that is biologically wired into humans: Put your entire self into it when you are communicating, especially when you're listening! This is covered more in [the part of this course about deep listening](https://link.jointaro.com/spQ5v1HSmVQv73De8).
- **No leading "hello" for digital communication** - When asking for help digitally, don't do a greeting and then wait for a response greeting before jumping into your ask: Just attach your ask from the get-go. Software is all about efficiency and waiting for this round trip makes things less efficient. For more advice around asking for help effectively, [here's our in-depth video about it](https://link.jointaro.com/CbnsszpprQSiwbJd9).
- **Lead with the core point** - Think of a "tldr" when it comes to long articles. This also applies to how you talk: Start with the main idea, and then go into the details. When you start by going into the weeds (very common for earlier-in-career engineers), it's very easy for people to be uninterested or get lost in what you're saying. For an example of how this applies to technical writing, [check out this Q&A from a Meta engineer about it](https://link.jointaro.com/a4tQFqmT6cB37QE46).

Effective Communication Guide [Part 1] - Core High-level Principles

For the full 9-part "Effective Communication" course, [you can find it here](https://link.jointaro.com/kWQkRyRhLqbTWBty7).

- **Communication is fundamentally an exercise in empathy** - The entire goal of communication is to align with or win over another human being in some way.
  - Strive to put yourself in the shoes of the person you're communicating with. Try to see the world through their eyes.
  - What are their values? What makes them happy? What are they struggling with? What do they care about? What's their background?
- **Understand others' incentives** - This is especially important in a corporate environment where every employee has some incentives they're pursuing. This will often times manifest as what are the values of the other person's org and even more concretely, *what they get rewarded for in performance review*.
- **Over-communication >>> Under-communication** - Under-communication's downside is that people are not aligned, which usually leads to lots of thrash and wasted work. That is much, much worse than the failure mode of over-communication, which is that you're a bit annoying (and this can be easily toned down and fixed). If you're trying to get better at communication, push for the over-communication extreme: Chances are, you will never reach it. It is *very rare* for someone to be communicating too much - Most people will appreciate the increased availability of information.

Session #5 - Mentoring Junior SWEs [E3] to Senior [E5] In Just 2.5 Years At Meta

For the key points, you can find them in the slides (linked below), so the summary will be framed more as action items.

**If You're Pushing For Senior/Are Senior+ Already**
- Mentorship is a core part of healthy senior engineer behavior, so invest in it if you aren't already.
- Now you need to find good mentees. *The main thing to look for is their coachability, which largely depends on how smoothly they process feedback*.
- How can you tell if someone is coachable?
  - They go the extra mile making sure their code is clean.
  - They respond to code review comments (particularly yours) with enthusiasm and speed. They're hungry to learn more and go deeper into feedback on their code.
  - They go out of their way to help others as opposed to many people who just help reactively (or not at all).
  - They have a good cadence with you when you spend time with them (e.g. it's easy to have a fun conversation with them over lunch).

**If You're Mentoring Other Engineers**
- *If the extent of your mentorship is that you answer a lot of your mentee's question, you're not truly a mentor.*
  - True mentorship is being proactive and having a clear vision for what your mentee will become. Create a growth plan for them to get to the next level and outline deltas to make it clear.
- If you haven't already make sure that your manager and the manager of your mentee (if they're on a separate team) are aware of your involvement. This is vital for getting proper credit and not growing them incorrectly.
- Your mentality should be that you serve your mentee, not the other way around.
- To build a ton of trust quickly, tell your mentee this: *"No matter what happens, I'll do whatever extra work is necessary to make sure that you're okay."* You are majorly responsible for your mentee's well-being.
- Always call out when your mentee does good work, even if it's something small like a well-written commit. Do it in your 1:1 where it has more gravity. Showing appreciation as a trust/morale building technique is *severely* underutilized.

**If You're A Mentee Looking For A Mentor**
- Show strong gratitude for code review comments on your commits. Don't just give them a thumbs up or worse, silently make the change. For deeper feedback (often times coming from senior engineers who you want to mentor you), go the extra mile giving thanks.
- Put yourself out there: Don't be a hermit. Go to team lunch, offsites, coworking - Become known as a friendly face within your team. Strike up conversations with engineers more senior than you just to get to know them.
- Strive to write good code. It can scary as a junior engineer in particular and default to churning out tickets as fast as possible with bare minimum quality; avoid that instinct and try to spend an extra 30 minutes to 1 hour trying to build things out properly (and then talk about your thought process on your pull requests). You want to show senior+ engineers that your hunger to be an actually good software engineer instead of a commodity coder is there.

Related Resources:
- [Presentation Slides](https://docs.google.com/presentation/d/12OelIHF08oBZwe-TzVlz8fqp4WiOTem_e9KsGe7X8XA/edit?usp=sharing)
- [Meta E4 To E5 Growth Plan (Pretty Applicable To Any Large Company)](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/articles%2Fmeta_e4_to_e5_growth_plan.pdf?alt=media&token=e13d88fd-9356-4c20-a229-cf0cad78a9af)
- [How To Get The Most Out Of Mentorship](https://link.jointaro.com/sobZVTxh3nvUFTnb9)

The Silent Killer Of Too Many Software Engineer Careers: Burnout

Burnout is a form of exhaustion caused by constantly feeling like you have too much to do. Most software engineers will encounter burnout at some point in their career. Four reasons you may hit burnout, and how to mitigate: 

1. **You can do your job anytime + anywhere.** Try to create some separation between work and home, or set deadlines for yourself. 
2. **Unlimited complexity.** A typical codebase will have too much complexity for one person to understand all of it. Instead, share with coworkers where you feel lost, and start small.
3. **Unclear roles.** There’s often ambiguity around things like handling support requests or maintenance. Try to create structure around this, and acknowledge that this work does exist. 
4. **Unclear communication.** For your work, over-communicate the bad news and refer to [this Taro session about communication](https://link.jointaro.com/6jdUd3ucPprEEVog6).

The Hardest Part Of Peer Feedback: Giving Them Constructive Criticism

- When the feedback prompt asks you for what your peer can improve on, it is *not* asking you what your peer is doing poorly. If you see your peer doing something toxic/negative, you should give them that feedback *immediately*. Don't wait 6-12 months until performance review season to drop this giant ball on them.
- The *real* question behind this prompt is: "How can your peer expand their scope?". This often times involves something they're already doing well that they can do even better and expand to achieve even greater impact.
- This question will be much easier to answer once you have a deep understanding of engineer levels as a lot of this feedback will be around what you think your peers can do to reach the next level.
- Example: Your peer is very passionate about automated testing and always pairs their landed code with robust test coverage. You suggest that they push to spread this behavior across the entire team with an overall testing initiative.

Making The BEST Case For Yourself In Performance Review: The Self Review

- Your self-review is the most important feedback for you come performance review season: Ignore the weirdness you may feel hyping yourself up and take it very seriously.
- The onus for representing yourself well falls mainly on you, not your manager or peers. Nobody knows you better than you. It's your job to make sure that none of your awesome achievements fall through the cracks.
- Start your self-review early and refine it across several iterations with your manager.
- Use your brag journal to seed the self-review.
- Show the impact. Attach links to proof as much as you can (e.g. linking a dashboard with positive metrics to show that the project you launched added business value).

360 Feedback: The BEST Performance Review System Top Companies Use

- The goal of 360 feedback is to generate as holistic and fair a picture of employee performance as possible.
- It does this by getting feedback from all directions:
  - Within (yourself)
  - Above (your manager)
  - Below (your reports if you are a manager)
  - Laterally (your teammates)
- This system prevents employee performance from reducing down to sucking up to the manager, which is the case in more traditional companies that aren't using this system.
- Also makes the power dynamic between manager and report more equal. A manager will have a bad feedback packet if their reports all share bad feedback about them.

Session #3 - Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta

[Here's the presentation slides](https://docs.google.com/presentation/d/1j5Lj_IGrtCRUpobj0f8k9egrBAej9apzikGp_V_iTCk/edit?usp=sharing).

- The expectations for an L5+ (senior+ at a FAANG or similar company) engineer are high. You won't get 12 months or even 6 months to fully onboard: You need to start having huge impact and showing your depth within 1-2 months.
- After starting, Alex told his managers that he was happy to offload any responsibilities they had so they could focus on higher-level issues and expand their scope. As a tech lead, you need to view your manager as a partner, not just a boss. "Treat me as a resource."
- The project that Alex was first put on was to make settings more server-driven within Robinhood
- The most impactful thing to do was to add color to the project:
  - Stabilize and then drive the workstream meetings
  - Create a thorough tech spec
  - Align XFN to figure out how to treat each settings section properly, especially in places where there were inconsistencies
- How Alex added his depth:
  - Wrote a 5+ page Android spec for his portion
  - Manually audited all of settings and compiled a detailed spreadsheet of inconsistencies to fully capture impact
  - Thorough data analysis spec, doing complicated SQL queries himself
  - Mentored an L4 engineer in the process, giving them L5 scope
- Recap (how you can incorporate the learnings here into your work):
  - Earn trust quickly: Be "aggressively" nice. Find out how you can add value to others and be very sincere and upfront about it.
  - Fill in the gaps: View your projects holistically and figure out what's missing to move the project forward. This will often times be "less flashy" non-coding work.
  - Bring people together: Don't be paralyzed by your lack of knowledge. Especially if you're new to a company, you will be clueless in a lot of scenarios. If you're in a cutting edge company like Meta/Robinhood, there will be a smart person(s) somewhere out there with the answer: You just need to bring them together in a healthy way.
  - Go deep: There's far more to a senior engineer than their ability to code. If you're a new L5+ engineer, even the tenured L3/L4s at the company will code circles around you in the beginning. If you're an L5+ engineer, figure out what behaviors and fundamentals you have that more junior engineers don't and show those as much as you can. This generally involves shipping software in a much more holistic way.

This Is What Most Companies Get WRONG About Promotion

- 2 types of promotion:
  - Strong companies: Already functioning at the next level
  - Weak companies: Mastery of current level + long tenure
- In the best tech companies, each level is fundamentally different from the previous one. This is why promotion is lagging there: You need to be functioning at the next level consistently for 3-6 months before getting promotion.
- The goal is to avoid the Peter Principle: Getting promoted to higher and higher levels until you are completely incompetent. When levels are truly meaningful, it's really easy to be doing great at your current level and then be struggling to survive at the next one.

How Alex Got Into Meta With 0 Prior Leetcode Experience

How To Ace Your Big Tech Interview [System Design] - 11/6/2021

System design is a crucial software engineer interview skill, especially for FAANG and Big Tech in general. It is effectively a requirement to be leveled at a senior software engineer or higher and will show up in mid-level engineer interviews as well (with the occasional appearance in even junior engineer interviews). The cool thing about system design (unlike data structures and algorithms) is that it's something you actually need to do on the job.

Here are our Top 5 points from the session (in no particular order):
- **Leverage engineering blogs of top companies** - And if you're applying to one of these companies, definitely read their blog. This will help you understand their high-level design and gives you a real-world example to anchor off of, as opposed to something more abstract and high-level that you would get from a traditional book.
- **Do NOT write code** - System design is a *high-level* exercise meant to gauge seniority. Writing raw code is the mark of a more junior software engineer, which is why you should never be writing code in a system design interview. Instead, draw boxes with arrows where the boxes represent components and the arrows represent how they interact.
- **There is no right answer** - One of the main reasons software is hard is because of how open it is. For any complex technical problem, there will be several good solutions, each with varying tradeoffs. System design is not like school or DSA where there is a singular right answer.
- **Understand the problem requirements** - System design problems are, by design, very open-ended. For example, if you get "Build the Twitter feed", there are so many features that make it up: There is no way you can design the entire thing in 1 interview round. Work with your interviewer to understand the scope of the problem and which parts should be prioritized.
- **Follow mature software principles** - The 5 covered in this presentation are robustness, scalability, performance, extensibility, and resiliency. Don't just get the happy flow working - Think about how your system will react when edge cases are hit and things go wrong.

Related resources:
- [How To Ace Your Big Tech Interview [Data Structures & Algorithms]](https://link.jointaro.com/iTNxPCvkdGite4wT9)
- [System Design Series: Taro Playlists [Part 1] - What REAL System Design Looks Like](https://link.jointaro.com/4obaFizTZAdAcStY6)
- [Presentation slides](https://docs.google.com/presentation/d/1z4yX5LiiSxbHiNrBOTPIiDfhBL5qmwRUrDojT71OROY/edit)

How To Ace Your Big Tech Interview [Data Structures & Algorithms] - 7/17/2021

Data structures and algorithms (often abbreviated as "DSA") is an infamous staple of the software engineer interview experience. Data structures and algorithms problems are the most well-known for being part of the FAANG interview process, especially for Google.

Here are our Top 5 favorite points from this masterclass (in no particular order):
- **DSA prep is insanely high ROI** - In fact, the return on investment for time spent on DSA studying makes it one of the highest yield activities any human can do period. If you haven't worked at FAANG / Big Tech before, switching into it is likely to increase your pay by 50%+. If you're in the US, this will often mean a raise of $50k+. So the next time you're feeling burnt out from DSA studying, keep this very bright light at the end of the tunnel in mind.
- **Leetcode and Glassdoor are all you need** - DSA studying is a solved problem. You can use other, newer tools if you want, but the old-school ones still work just fine. Glassdoor in particular is naturally very effective given the "Big" nature of "Big Tech". Go through the recent data points from Glassdoor if you're interviewing for Big Tech and make sure you have a good grip on recurring recent problems.
- **Learning DSA is all about pattern recognition** - For 80%+ of DSA problems, there will be some 1-2 liner "trick" that represents the whole solution. For example, the "trick" to 2 sum is "Look for the difference and use a set/dictionary". It is not scalable to memorize solutions as code - Look for patterns and remember solutions as that high-level insight.
- **Communicate, communicate, communicate** - Since FAANG companies are so huge, there are naturally going to be far more stakeholders on every project, making alignment far more important. Because of this, Big Tech companies will often closely judge your communication skills during the interview. Don't just code in silence - Even if you get the right answer, you may still fail for not maintaining a dialogue with your interviewer.
- **Don't forget about space** - Most people are aware of big O run-time complexity, but candidates often forget about space complexity. Make sure to talk about both when you analyze your solution. As a side note, remember that a recursive solution will *not* be O(1) space.

Related resources:
- [How Alex Got Into Meta With 0 Prior Leetcode Experience](https://link.jointaro.com/SbNwqoPDmroJTsE37)
- ["How do I balance my time between studying DSA and fleshing out my portfolio?"](https://link.jointaro.com/7dw5k5yheTK5qx2D7)
- ["Should I quit to prep for interviews?"](https://link.jointaro.com/xgiQFNmwS7QgBUdV7)
- [Presentation slides](https://docs.google.com/presentation/d/13uLUHDvZifjp2aVClGsW29nfuVpQYvrkGLP8cej0R_k/edit#slide=id.p)

The Best Managers Acquire Power To Give It Away

- Even though the manager is an authority figure, the best engineering managers *acquire power to give it away*.
- What this means is they will establish ownership over a space and then give control of it to an engineer on their team to help them grow. This is especially important growing engineers to senior levels and beyond.
- By making the engineers on the team share authority, the team becomes more resilient, so that it doesn't collapse when the manager is out.
- Alex's Instagram example:
  - The oncall in his org was very weak and unhealthy.
  - His manager got the ball rolling and collected a working group of senior+ engineers and managers to align on the problem and agree to solving it.
  - After his manager established a sphere of influence here, they handed it over to Alex to lead the entire effort and successfully revamp the oncall system for ~25 mobile engineers.
  - Manager easily could have led this effort themselves but chose to delegate to Alex, so that he could build authority in this area.

This Is How Software Engineers Should Initially Learn

- Learn depth-wise initially, and then you can go breadth-wise after you become a very established senior engineer.
- If you don't know what you're passionate about, try a bunch of things out (go for breadth) until you find that passion.
- After finding your passion, go deep on it.
- You need to commit a long period of time to just 1 thing initially, so you start learning fundamentals as opposed to tech stack-specific tactical pieces.
- *You will eventually realize that all tech stacks are the same in many ways* - All languages and tech stacks share a common set of fundamentals. You will not get to this state if you switch stacks every year.

Related resources:
- ["How can I write great code faster?"](https://link.jointaro.com/7dMeqXwrGceNM3kr6)
- ["How do you get more independent?"](https://link.jointaro.com/VNhUNm6VZAezd3XN9)

Rockstar Software Engineer Story: SW2 -> Principal In Just 4 Years

- An engineer joined Mixpanel as a level 2 Software Engineer, and received 4 promotions in 4 years to become a Principal Tech Lead Manager (TLM). 
- Key to his success was the ability to make rapid progress on one of the company's top priorities: reduce infrastructure spend.
- He had a hypothesis that the majority of the cost incurred came from a few customers where the economics were backward for Mixpanel.
- Rather than solving a gnarly technical problem, the engineer worked with these customers to change their use of compute resources, resulting in massive savings for the company.

For more resources about becoming a rockstar engineer:
- [Mentoring Junior SWEs [E3] to Senior [E5] In Just 2.5 Years At Meta](https://link.jointaro.com/cpnvkDTC9daXMC9Y8)
- ["How do you get the most out of mentorship?"](https://link.jointaro.com/deNuMCdtRz5t9fEF9)
- ["How do I find a proper mentor within my company?" ](https://link.jointaro.com/3dVSLgYprZAtPJoh9)

What Makes A Truly Great Tech Lead

- **Overview:** Tech leads are extremely valuable. They allow a team to multi-thread and execute on multiple projects at once, not requiring the engineering manager to babysit everything.
- **Understands the business context:** Great TLs have strong product understanding and realize that software needs to be built in different ways based on the situation.
- **Project risk shrinks over time:** Great TLs are constantly looking for ways to de-risk their projects over time. As things get closer to the ship date, the project actually becomes less scary!
- **Level up the team along the way:** Great TLs figure out ways to leave the team in a better place than it was before the project.
- **If you're looking to become a great TL**: Get to know your PM, assess risk proactively and tackle the hardest items first, find opportunities to level up your teammates.

If you want to learn more about becoming a great tech lead, check out the following resources:
- ["How can I hit the ground running as a tech lead?" - Senior Engineer at Amazon](https://link.jointaro.com/GF5bSUF3yiS1wtCU7)
- ["How do I lead without authority?" - Staff Engineer at Meta](https://link.jointaro.com/hQzz7xC5JhGfUwxD7)
- [Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta - Case Study From Alex](https://link.jointaro.com/mQVZ9Qs8DQW8ANiN6)

The #1 Rule Of Negotiation - How To Avoid Giving A Number

- Negotiation is a dance: Know your role within it and have a script.
- There's an asymmetry here:
  - Recruiters are talking to candidates and negotiating every day. They come in very prepared and have a script.
  - You will change jobs every 2-3 year - It's a rare event for you to have this conversation. To level the playing field, you should have a script too.
- If they ask for a number or range, say *"I'm more concerned with understanding if this opportunity is right for me."* This is polite while positioning yourself in a mutual respect scenario.
- If they refuse to move forward within a number, you can try:
  - "What are typical compensation bands for this role?"
  - "I'm a strong performer in my current role and expect to be promoted soon, so I'm not sure what's fair."
- If they require a number, put a placeholder and say you'll get back to it later
- Asking for a number is generally a predatory way for companies to take advantage of candidates and lowball them.
  - This is why in California, it is illegal for employers to ask your prior compensation information

Related resources:
- [3 Quick, Powerful Negotiation Tips](https://link.jointaro.com/9AFWASDPJcu4aHac6)
- [How To Negotiate A Raise At Your Current Job](https://link.jointaro.com/Pe3nTz8cwBh7yYPE9)

Why You Should Start Your Career At A Big Tech Company

- **There's no universal right answer to which company works best for you** - At the end of the day, you should figure out what you care about and what your goals are and work backwards from there. It's entirely possible that Big Tech isn't a good fit for you.
- However, in a vacuum, you should start your career at a Big Tech company if you can. The main reason is that Big Tech is generally quite good at adding a layer of consistency to your career.
- You will probably learn a lot about writing good, scalable code as these companies know how to build massive systems and hire smart people.
- Your compensation will be very competitive, making it easier to negotiate proper pay and level at future jobs.
- You will probably develop a decent suite of fundamental soft skills as you need to learn how to work with many stakeholders to succeed at Big Tech.

Promotion Is Underrated And The True Foundation Of Your Pay And Career

Here's [the full 2 hour masterclass on maximizing your pay in tech](https://link.jointaro.com/hhDAeiDnEXHG8yEfA), which is where this clip is taken from.

Core points from the video:
- In a lot of companies, promotion isn't meaningful, both in terms of growth and pay increase. *However, promotion is extremely powerful when you're working at a top-tier company like FAANG.*
- In a good environment, promotion is the most organic option to increase your total compensation as it means that your actual skill and increased pay are actually correlated with one another.
  - If you get promoted at a FAANG/Big Tech company, this sets the foundation for future opportunities as you will now be put at this level at least 95%+ of the time. For example, if you become a senior engineer [L5] at Google, it is very unlikely that your next company will put you below senior.
  - It's also crucial to remember that at FAANG/Big Tech, the expectations are quite real and quite high. By getting promoted to your level, this means that you are actually able to perform at this level, as opposed to the scenario where you negotiated an up-level via a job switch where you might be dangerously over-leveling yourself.
- *The problem with doing the interview prep and job switching grind is that you're not actually growing as a software engineer during that time.* There is a huge disconnect between interview skill and actual skill, especially with data structures & algorithms (DSA).

If you're having trouble with your promotion, [we can offer you personalized support with Taro Premium](https://www.jointaro.com/membership). We have gotten software engineers promoted at lightning speeds from L3 (junior) to L6 (staff) at top companies like Meta, Robinhood, and Pinterest.

For additional promotion resources:
- [What's the Difference Between A Senior And Staff Engineer?](https://link.jointaro.com/BEM2RAjPFe8Pv7826)
- [What are the expectations of a strong senior engineer?](https://link.jointaro.com/9sBxwnftk3iLdond6)
- [Expectations at different levels? (Junior vs Mid)](https://link.jointaro.com/j8AGiasKACp7m7jM8)

How To Get Real Feedback So You Can Actually Improve

Here's the [full 1 hour 20 minute masterclass on how to grow quickly in tech](https://link.jointaro.com/8G8o98FrspUYQePE9).

Core points:
- Let the other person know that you treat all feedback as a gift and really appreciate constructive criticism.
- Schedule a 1:1 with crucial people in your org/team to get feedback. It can be every 1 to 3 months. Make it clear that it's a feedback meeting.
- It's important to understand the feedback giver's perspective. Nice people, those you are (hopefully) working with, are going to hold back often by default to shield you. This is why you need to make it clear that you really appreciate honesty and transparency.
- Feedback is crucial towards promotion.

Related resources:
- [How To Sharpen Unspecific Feedback On Your Code](https://link.jointaro.com/WuBN14cMA9Jgr5ru5)
- [How To Get Feedback In A Company With No Performance Review](https://link.jointaro.com/fTMCFiKTRoJsXvRW6)
- ["How do I find a proper mentor within my company?"](https://link.jointaro.com/3dVSLgYprZAtPJoh9)

A Huge, Often Unused Way Your Manager Can Help With Promotion

- Your manager is critical to your promotion. More specifically, if your manager is not supportive of your promotion case, it is near impossible for you to get promoted.
- You need to create a plan with your manager as soon as the performance review cycle starts to set expectations on what you need in order to be a good candidate for promotion. It should be modal and detail the following:
  - What it means to meet expectations
  - What it means to exceed expectations
  - What it means to totally crush expectations
- Regularly work with your manager to get feedback and understand your progress for this plan

Effectively Learning Data Structures And Algorithms (DSA)

Which of these is the core building block of data structures and algorithms problems?

True or false: The most effective way to be prepared for data structures and algorithms interview problems is to memorize the code of each problem's solution line by line.

Why should you comment your solutions to data structures and algorithms problems?

True or false: When you are completely stuck, you should just look at the entire solution in order to learn it.

Why is it healthy to struggle on data structures and algorithms problems?

- The key to mastering DSA is to learn patterns and not memorize code. The "drill and kill" style of studying is really badly suited for DSA
- 80% of asked DSA problems will use 1 of ~15 different patterns
- Examples of patterns: Binary search, sliding window, tails-end recursion
- Extensively comment your solutions, primarily with the key pattern behind the problem
- When you can't figure out a problem, read 10-20% of the solution and see if you can come up with the entire solution from there. Build the muscle of converting high-level points into fleshed out solutions

Related resources:
- [Full 1 hour+ Masterclass On Acing Your Big Tech DSA Interview](https://link.jointaro.com/VfSeuUFiXNtKa5if7)
- [Full 1.3 hour Masterclass On Acing Your Big Tech System Design Interview](https://link.jointaro.com/Tmqs62Lw7WV4qDw59)
- [How Alex Got Into Meta With 0 Prior Leetcode Experience](https://link.jointaro.com/vaNH1hjRUhmF8ibSA)

Having The Proper Mindset For Interviews

True or false: You need to care a lot about your Big Tech interview, because passing it will drastically improve your life. The more prominent it is in your brain, the more likely you are to pass.

True or false: Your input is much more important than the output and results you achieve.

Why should you not view interviews as a test?

True or false: You shouldn't take any breaks when studying for interviews, because the relentless focus will help you learn the material better.

- *The more you care about your interview, the less likely you are to pass it.*
- Interviews are all about maintaining a nimble, flexible state of mind, so you can react gracefully when hit with a problem you haven't prepared for. This will almost always happen on interviews with tougher companies.
- If you view your interview as a "make or break" opportunity (which it admittedly very well may be) and go into it with a lot of anxiety, you will not have that healthy state of mind. When your interviewer goes off-script, your mental state will likely shatter.
- View interviews as a chance for you to go in and learn from some very smart people, and if you happen to get a job offer, that's a nice bonus. This much more relaxed and positive mentality will reduce your anxiety.

Related resources:
- [In-depth 1 hour masterclass on acing your Big Tech DSA interview](https://link.jointaro.com/iTNxPCvkdGite4wT9)
- [In-depth 1.3 hour masterclass on acing your Big Tech System Design interview](https://link.jointaro.com/9ZJQZ1eSxhKWt89Y6)

Struggling With DSA? Don't Worry, That's Healthy!

True or false: Interviewing is all about how much you know. As long as you study a lot and understand enough material, you will pass the interview.

For almost everyone, what does the learning curve look like for data structures and algorithms?

True or false: It's completely normal and even a good sign when you feel dumb while studying data structures and algorithms.

What's the most important piece when you're learning data structures and algorithms material?

True or false: If you aren't making progress on data structures and algorithms after 2 months, your mind probably just isn't geared to understand them. At that point, you should be practical and just look for interviews that don't have these kinds of problems.

- DSA learning is an exponential process. You are going to be terrible initially, and eventually things will start to "click" once you hit the inflection point.
- When you feel dumb, understand that this is completely natural: This is almost a good thing as it's entirely expected.
- DSA is very much an input-driven exercise. Build a good process around studying it regularly and commit to it. With constant persistence, you will eventually get to where you want to be!

What A Test Plan Is And Why Every Code Review Needs One

[Here's the full masterclass session on code review](https://link.jointaro.com/29jyjjRiaUBZ1htQ9), which is where this clip was taken from.

Core points:
- Actually show that your code works when you submit your code for review. You do this with something called a "test plan".
- Be visual if you can. The best thing to attach is a video or a .gif. A step down is attaching a screenshot.
  - If you're working on APIs, you can attach a screenshot of a curl or Postman
  - Whatever you're doing to verify that your code works, capture that in your test plan
- Benefits of having a test plan:
  - Basic trust token showing your teammates that your code works, at least in the core flow
  - Turns your code review into a much more informative and self-documented piece of codebase history
  - Makes it far easier for people not to break whatever is in your code review when they work with it in the future
- Show a repeatable way to test your change
  - If you're adding automated tests, include the command to run it
  - With a video, show the full process of triggering the flow altered by the commit (e.g. tapping into a certain screen on a website)

Related resources:
- [Concrete example of what a good test plan looks like (with GitHub link)](https://link.jointaro.com/uV87V62LbbBF9MVy8)
- [One Diff, One Thesis - What Every Code Review Should Be Like](https://link.jointaro.com/5Ehehxt6jBR42ui1A)
- ["How can I write great code faster?"](https://link.jointaro.com/7dMeqXwrGceNM3kr6)
- [Avoid These Junior Engineer Mistakes With Code Review](https://link.jointaro.com/agkYrLH8uuCv4UcPA)

You Should Be Vulnerable With Your Manager

You are feeling burnt out at work. Should you share this with your manager?

You feel like you are slower than your other teammates and are afraid that you look bad amongst the team. Should you share this with your manager?

Your dog just died, and you are having a really tough time concentrating at work because of this. Should you share this with your manager?

Here's [the full 1 hour masterclass on having impactful 1 on 1 meetings](https://link.jointaro.com/hPYW2KY3jW6vgpm97) (where this video was clipped from).

Core points:
- Your manager is responsible for your performance at work. Therefore, it's in their best interest to help you resolve anything that is negatively affecting your work performance, even if it's something non-tactical.
- If you are having a deeper issue (e.g. you have imposter syndrome), this is something you should talk with your manager about. You shouldn't expect them to act as a full psychologist, but they should at least be receptive of your problem and lend an understanding ear.
- Venting and complaining are very natural and can act as a therapeutic exercise. Don't be afraid to do this with your manager once you have a good enough relationship.
- This gets easier over time. Once you start being honest and more transparent in your manager meetings, the trust between you two increases, making it smoother to continue being open in the future.

Related resources:
- [1.5 hour masterclass on how to find a good engineering manager](https://link.jointaro.com/ce4aACc9MJhfaVfQ6)
- [1 on 1s are the time to be awkward](https://link.jointaro.com/4SqyPg6hjNFFrGf57)

Having The Proper Mentality For Manager 1 on 1s

True or false: Your manager is your superior, so it is on them to ask the right questions and figure out what you need in your 1 on 1 meetings. You just need to show up on time.

Why is the burden on you to set the agenda and overall plan with your manager 1 on 1s?

True or false: It is better for your career growth to view your manager as being a resource for you instead of you being a resource for your manager.

True or false: A good manager 1 on 1 involves you giving status updates and then waiting for instruction on what to do next.

- *Your manager is a resource for you.*
- Don't just see your manager as a source of authority that gives you work. While this is true to some extent, having this mentality really holds back your growth.
- Go into your manager 1 on 1s with a plan on how you can extract the most value from them.
  - This onus is on you to set the agenda for this meeting, so you can get insights from your manager on how to best improve yourself. Let them know about this agenda beforehand, so they can think about how to best help you with each point.
  - Another way of seeing this is how can you make your manager's life easier. By setting the stage for your manager, you lower the barrier for them helping you as they don't need to figure out exactly what your work life looks like and what problems you have.
- A common failure mode for earlier-in-career engineers going into manager 1 on 1s is they go in, give a status update on what they're doing, and wait for more work to be given to them.

Related resources:
- [Full In-Depth Session On Impactful 1:1 Meetings](https://link.jointaro.com/QXfRvm5jJGwsrif26)
- [Effective Communication Guide](https://link.jointaro.com/kWQkRyRhLqbTWBty7)

1 on 1s Are The Time To Be Awkward

Why should you be awkward and even a little bit uncomfortable in 1 on 1 meetings?

True or false: 1 on 1 meetings are great for staying in sync, so status updates are one of the best things you can talk about during them.

Which of the following are good things to talk about in 1 on 1 meetings?

- 1:1 meetings are the most inefficient way to communicate anything that is non-controversial
  - The main culprit here is detailed status updates. If you're using the majority of the time to share these and talk tactics, you are doing 1:1s wrong.
- The most effective way to leverage 1:1s is to talk about things that are *awkward and maybe even make you uncomfortable*. Here are some examples of "awkward" topics:
  - Feedback to improve
  - Emotions (both positive and negative)

Related resources:
- [The Art of the Awkward 1:1](https://medium.com/@mrabkin/the-art-of-the-awkward-1-1-f4e1dcbd1c5c)
- [Effective Communication Guide](https://link.jointaro.com/kWQkRyRhLqbTWBty7)
- [Having The Proper Mentality For Manager 1 on 1s](https://link.jointaro.com/p8ysLGYUj7KhoGND7)

2 Ways To 100x Your Productivity That Nobody Does

What are the 2 underutilized but straightforward ways of becoming far more productive?

True or false: Often times you should sacrifice sleep and exercise in order to get more hours, thereby becoming more productive.

Why is it absolutely necessary to get in good sleep and regular exercise no matter what?

- The 2 core pillars of productivity are a consistent, good night's sleep and regular exercise (3-5 times a week).
- "I don't have time for that" is not a real excuse. There are thing you *make* time for. Nobody says they stopped brushing their teeth to become more productive: That is an example of something everyone makes time for. Sleep and exercise are the same way.
- The math doesn't check out for sacrificing these. It doesn't matter if you have more hours in a day from doing this if your rate of getting things done is very low. And it will be low if you are constantly sleep deprived and not physically fit.

How The Best Software Engineers Learn - The Lego Model

- "The Lego Model" is a way to view the world and understand your learning journey as a software engineer.
  - Technical components (e.g. rendering a list of items) are the individual legos
  - Complete products (e.g. a food delivery app) are the full lego creations
- There are 3 axes to evaluate your legos:
  - **Quantity:** How many you have
  - **Quality:** How good and sturdy your legos are
  - **Commonality:** How "in demand" your legos are (i.e. how many creations they can fit into)
- Most earlier-in-career engineers understand the 1st axis of quantity and incorrectly spend a lot of time learning different tech stacks and frameworks.
- Those same engineers often don't even realize the 2nd and 3rd axes exist:
  - When they learn a component, they will build it out with very low quality.
  - They will learn "flashier" components that aren't even used by most products/companies.

For examples on how to excel at the 2nd and 3rd axes, check out the related resources below!

Related resources:
- [Full session on learning quickly in tech (where this clip came from)](https://link.jointaro.com/cUYywrw8o6j5q5T58)
- [This Is How Software Engineers Should Initially Learn](https://link.jointaro.com/iVBpCaB6pAHivhdi6)
- [Building Software For Optimal Learning Example - Login Flow](https://link.jointaro.com/oEkTB3pskKH6JHCX6)

Suppress Your Instincts And Treat All Feedback As A Gift

True or false: If you get a piece of feedback, you should initially assume good intent and that it is correct.

What should be your immediate reaction when you get a piece of constructive feedback?

True or false: If you get feedback that you do not believe is 100% correct, you should just ignore it.

Which of the following are good things you can do when you get a piece of feedback that you genuinely believe is not constructive and is phrased in a harmful way?

True or false: One of the most straightforward ways to grow in tech is to just immediately incorporate every piece of feedback you get.

- **Don't be defensive at all when receiving feedback unless it is entirely incorrect.**
- If you have taken the time to find a supportive team, the vast majority of feedback you receive (95%+) will be correct and have value.
- Feedback is a gift and arguably the greatest gift you can possibly receive for your career. *One of the most common attributes among top performer engineers is that they take and apply feedback extremely well.*
- Have empathy for the feedback giver. They probably feel a bit awkward as they're unsure how you're going to receive the feedback. Make them feel comfortable after they share the feedback by thanking them immediately and earnestly.
- Write down all great feedback you receive and try to convert it into action items:
  - Example: "I feel like you could be more active in meetings." -> I will try to say at least 1 thing in every team meeting from now on.
- If you get feedback you genuinely believe is incorrect and hurtful:
  - Talk to your manager if you don't have a good relationship with that person.
  - If you feel comfortable enough to talk with that person directly, have a crucial conversation.

Related resources:
- ["How can I find more opportunities to grow when I'm getting very little real feedback?"](https://link.jointaro.com/TzKmgN5nLnLyXJ5G6)
- ["Everyone's telling me I'm doing great - How do I get actionable, constructive feedback?"](https://link.jointaro.com/ng6MUQy2yUfS8w4e8)
- [Effective Communication Guide - Giving Feedback](https://link.jointaro.com/VsQvnzsnJbbXUQDy6)
- [Suppress Your Instincts And Treat All Feedback As A Gift](https://link.jointaro.com/oi5cJu7ZCXYPQBRk7)

Explaining Your Experience In A Meaningful Way On A Resume

Is this a good resume snippet: Worked on the SIVAD system, using Room, AndroidX, Activities, and Java

How do you make the experience portions of your resume stand out?

Is this a good resume snippet: Champion for unit test coverage for Cool Company's iOS app, increasing it by 20% and reducing the amount of new iOS user issues by 10%

What is the main way people struggle with their resumes?

Is this a good resume snippet: Led the JavaScript migration effort with strong communication, architectural, and code quality skills

- The most common way resumes struggle is that they tell instead of show
- Here's an example:
  - Telling: Added unit tests to the Android app with JUnit and Java
  - Showing: Increased test coverage of the Android app by 80%, which reduced bug tickets from users by 50%
- In a nutshell, don't just say what you did - Adding an adjective like "great" doesn't automatically make your feat impressive. Prove that you did something great by talking about how you did it and the actual result (which is ideally business impact).
- This method of communication is especially important for resumes as their audience is mainly non-technical: Recruiters. They aren't going to understand the more specific tech buzzwords. You need to write things in more "plain English", so that your accomplishments can be understood as impressive by almost anyone.

Asking Effective Questions That Get Great Answers Quickly

What are some things you can do to improve your question?

True or false: Ideally, your question takes less time to answer than it took for you to ask the question.

What is the core operating principle behind asking and answering questions?

True or false: In order to be polite, you should preface your question with a simple greeting like "Hello". After the potential answerer responds, then you can ask your question.

Why do you need to attach a lot of context and be as specific as possible asking questions in tech?

- **Core principle**: Questions are an exchange of time. You put some time to write your question and the answerers take some time to respond. Your goal is to make the amount of time necessary to answer your question smaller than the amount of time you spent asking it.
- Have empathy for the people answering the question. Thank them pre-emptively!
- Avoid leading "hi". Just ask them your question directly!
- Google your question and go through the initial results prior to asking your question. Inline that context in your question.
- Attach as much relevant context as possible. You want to prevent back-and-forth where answerers need to ask you questions to clarify your initial question.

Related resources:
- [Bad Question vs. Good Question Example](https://link.jointaro.com/fiY293kj2ewPwMqB8)
- ["How do you overcome the fear of asking stupid questions / bothering people when you need help?"](https://link.jointaro.com/37FJnTAX1BN2e5wt6)

The #1 Thing To Remember With Meetings

Which is the core principle you have to remember with meetings?

True or false: It is safer to just keep attending a meeting series, even if you are not clear exactly what value you are getting from it.

You have a meeting series where there is always action, but there is usually an awkward portion at the end where people run out of topics. What should you do?

True or false: When in doubt of a meeting's value prop, just delete it. You can always bring it back later.

You have a 1 on 1 meeting series, and by the time of the meeting, you feel like there are a lot of issues that you two are getting to too late. What should you do?

Key points:
- Meetings are *extremely* expensive as it's the most valuable resource people have: Time.
  - This is why you need to be very aware of how productive meetings are for you. Don't just go to them blindly, because you are invited - This is a common failure mode for earlier-in-career  engineers.
- If a meeting has value but isn't fully efficient, consider lowering the frequency or length of the meeting.
- Reflect on the value of every meeting, especially team meetings since they take up the most time.
- *Lean towards deleting meetings or not attending them* - If you're unsure what value you got from a meeting, there's a good chance the meeting isn't actually helping you.
  - You can always run an "experiment" here. Remove the meeting from your calendar for a week and see if anything breaks - If the lack of alignment gets bad, you can put the meeting back.

Here's the [full 1-hour masterclass on having impactful 1:1 meetings](https://link.jointaro.com/qrBzkp1s8Yfscc2p9), which is where this clip was taken from.

Related resources:
- [Effective Communication Course](https://link.jointaro.com/kWQkRyRhLqbTWBty7)
- ["How can I be more active in meetings and earn the respect of senior engineers?"](https://link.jointaro.com/eUdmzZqZUaJLugGV6)
- ["I have anxiety when speaking up in meetings - how do I overcome this?"](https://link.jointaro.com/1hfsgVf8EgmuBYbG7)

The #1 Thing You Need To Know About Promotion In Tech

True or false: To get to very senior engineering levels, you need to write thousands of lines of code per day.

Why is output not as important for promotion?

- *Promotion is about behavior, not output*
- Raw output doesn't scale. You only have so many hours in a day, and your hands can only physically type so many lines of code per minute.
- Senior engineers can have 10x to 100x the impact of a junior engineer. In order for them to do this, they need to add deeper types of value to the business.
- That deeper type of value comes from behaving in a fundamentally different way to more junior levels. In particular, engineers at these very senior levels add multiplicative value instead of additive value. An example of this is a senior engineer empowering many others to write code instead of just writing the code themselves.

Forward Deployed Software Engineer at Palantir

Hi everyone!
I will join Palantir as a Forward Deployed Software Engineer(FDSE). I need advice on tackling the first 2-3 months at the company to gain team respect and trust. I am excited about this opportunity and want to grow but do it efficiently, if that is even a thing😅.
Jokes aside, All I want is to have a great career at Palantir.

YOE: over 2.5years(including just over 1year of internship).

Stack Experience: Ruby on Rails, Python, some Java

Current Work: Backend Engineer. Building and maintaining APIs

Advice for someone joining big tech from a non big tech background?

Across my career, I've felt bad about my skills sometimes because I'll have teammates, who are also at my level, doing as much as 2x more than me. This has led to me feeling like an imposter many times - Any thoughts on how to process all this?

I've felt imposter syndrome from seeing super talented peers - How do I deal with this?

Entry-Level Software Engineer [E3] at Meta

In particular, I'm having trouble figuring out really complex bugs. For example, on my current project, we're auditing a lot of the existing feature set to see what issues they have so we can fix them as we revamp them. I'm happy to find lots of issues, but I have no idea how to fix them, even after finding a code pointer.

I talked with a senior engineer on my team for help, and they were able to get more color on the situation. However, they mainly were able to do this as they have been in the org for a while and knew who to go to for what: I can't replicate that deep knowledge they have as I'm fairly new to the company. How can I create a systemic process I can follow to figure out these situations?

How can I become more independent and better at unblocking myself with tricky technical issues?

Grow your tech career with the help of industry experts

Pave a foundational path towards quicker promotion and higher compensation

Be A Code Machine

System Design Series

FAANG Case Studies

Build Relationships

Time Management

Get Expert Mentorship

Top Videos

What Makes A Truly Great Tech Lead

This Is How Software Engineers Should Initially Learn

Having The Proper Mentality For Manager 1 on 1s

Top Questions

Editor's Choice