Build Deep Relationships Quickly In Tech [Part 2] - Why A Strong Network Isn't Optional

No engineer is an island. And if they are, they're going to have a bad time. This lesson teaches you:

- How a strong network helps with job searching
- How a strong network helps with promotion and overall on-the-job performance
- How a strong network helps with general learning
- Why you need to start networking *now*, and how starting "early" actually makes the networking way easier

To better understand the difference between a strong referral vs. a weak referral: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/referrals/>

Level Up Your Code Quality As A Software Engineer [Part 5] - Fake "Clean Code" Shortcuts

A lot of software engineers want shortcuts: They want to find the optimal tech stack, programming language, and framework to slot into their code so it's automatically the best and they have conquered code quality. Unfortunately, that's just not how code quality works. This lesson will teach you:

- Why having truly good code quality is so, so hard and more about building up fundamental technical skills
- How to have a proper senior engineer mentality around "clean code" and how to extend a codebase
- Common fake "clean code" shortcuts that engineers desperately want to believe but ultimately aren't true (often stemming from obsession with FAANG and Big Tech)

Ship & Grow 500k+ User Side Projects [Part 3] - Crafting The MVP

You should launch the initial version of your side project as fast as possible. So what exactly should it have? This lesson teaches you:

- The only thing your side project MVP (minimum viable product) needs to have
- How a piece of software can still deliver value despite having incredibly few features (or even just 1 feature)
- What a good MVP looks like, explained with an in-depth example
- A common mistake engineers make when it comes to shipping their MVP, explained with an in-depth example

If you're curious to learn why building a good auth flow is 5x harder than engineers think: <https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/case-study-signup-form-edge-cases/>

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?

The 1 on 1 meeting is one of the most important usages of time in the workplace. Even the most junior engineer will generally have at least a 1 on 1 meeting series with their engineering manager. However, 1 on 1 meetings are often completely wasted by software engineers - Here's how to avoid that.

Here are the core points from the video:

- 1 on 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:

- [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)
- [The Art of the Awkward 1:1](https://medium.com/@mrabkin/the-art-of-the-awkward-1-1-f4e1dcbd1c5c)

[Masterclass] How To Do Amazing Code Review

Code review is one of the most effective ways to learn as a software engineer, especially for those earlier-in-career. Unfortunately, way too many engineering teams get it wrong with slow review speed and low quality comments.

There is a mountain of information in this presentation, so here's our 5 favorite points (in no particular order):
- **Code review is NOT for catching bugs** - Of course, if you find a bug in a PR (pull request), you should call it out, but that's not the primary purpose of code review. The core benefit of code review is to build up engineering culture, propagating best practices amongst the team and growing newer and more junior engineers.
- **Add deep context to your PRs** - Explain what your pull request does and the reasoning behind your approach. Also, *include a test plan.* A test plan is a demo showcasing what your code changes do; try to make it a video/gif, which is especially powerful if you work on front-end (Android/iOS/web). If you can't do a video, try attaching a screenshot or a set of commands to run tests.
- **One diff, one thesis** - Every PR should be focused and atomic: Don't jam the entire new feature you just coded up in a single 1,000+ line PR. Huge commits are hard to review, and your teammates will hate you for it. For the vast majority of cases, you can break down your PRs to 25-250 lines of code.
- **Read others' code reviews** - Similar to so many other things in tech, stand on the shoulders of giants where you can. With code review, this means looking at how senior+ engineers on your team comment on reviews. Try to find patterns in the issues they're finding and incorporate it into how you review code. Revisions that have been rejected with changes requested are a gold mine for this learning.
- **Code review MUST be fast** - When we say fast, we mean that feedback should arrive in <24 hours. What a lot of engineers don't realize is that code review delay is multiplicative: Sometimes commit will need 3-5 revisions before they're able to be merged. If turnaround is 2+ days, this can easily lead to commits taking weeks to land, which is far too slow.

A lot of the terminology in this video is Meta specific. If you're more used to GitHub:
- Diff review = Pull request
- Diff = Commit

Related resources:
- ["How to give better code reviews without full business context?"](https://www.jointaro.com/question/vio35mw1SYWM8AYojB2w/how-to-give-better-code-reviews-without-full-business-context/)
- ["How to review code in another language/ from another team?"](https://www.jointaro.com/question/B79W3aWc8xMB8cCULFdJ/how-to-review-code-in-another-language-from-another-team/)
- [Presentation Slides](https://docs.google.com/presentation/d/1koyIR9K_CtESD7Vnh3GQOE-svFW-ngrQeEAduSAoH0w/edit)

[Part 1] Meta Intern Success Series - Internship Program Overview

- The Meta software engineer internship program is very legit. It resembles the experience of working as a full-time Meta engineer as closely as possible, complete with calibrations and a formal manager.
- The program is also hard. The pass rates that got mentioned around the company were 50 to 75%. It's one of the harder software engineer internships to get a return offer from as the goal is to perform at E3 MA. If this is your first software engineer internship or you have only interned at companies weaker than Meta prior, the high bar can be overwhelming.
- However, the reward is tremendous. Meta is an incredible company to work at and amazing as a career starter. Meta is also one of the highest paying companies for the entry-level band (E3), and the signing bonus for return offer interns is sky-high (60k to 100k).
- 4 outcomes for Meta software engineer interns:
  - No offer: As mentioned before, many interns will unfortunately be here. The numbers after this correspond to the percentage of the "surviving" pool.
  - MA (70%): "Meets All Expectations", which is a regular return offer. The vast majority of successful software engineer interns get this. 
  - EE (25%): "Exceeds Expectations", which is given to very strong interns.
  - Rockstar (5%): For interns that completely crush it and are very close to functioning as a mid-level engineer (E4).
- Internship schedule (assuming standard 12 week length):
  - Weeks 1-3: Onboarding
  - Weeks 5-6: Mid-cycle review
  - Weeks 10-11: Final calibrations (return offer is decided here)
  - Weeks 11-12: Relax and have fun. Only your performance from Weeks 1 - 10 is counted towards your final review
- As a software engineer intern, you formally report to an intern manager (IM), which is shown on the org chart. On top of the IM, you will have 1-3 other peers who will review your diffs and help you. During calibrations, feedback from your IM and these peers will determine your final rating.

For more expert internship advice: [Full SWE Intern Advice Playlist](https://www.jointaro.com/topic/software-engineering-intern/)

An Autistic Journey To Google Staff Engineer [L6] From Software Analyst - By Lee McKeeman

[Lee McKeeman](https://www.linkedin.com/in/lmckeeman/) is an autistic software engineer with quite an incredible journey: Across a whopping ~20 years of experience, Lee has worked at Amazon (where he was an engineering manager and bar raiser), Meta, and now Google.

Lee's career story is super long (watch the video to get the full picture), so instead, we're sharing some of the great learnings from Lee here:
- **School doesn't actually teach you software** - University is generally rooted in theory and overly abstract exercises, leaving you with a very basic raw coding foundation. While that certainly has value, it's not enough to make you capable of doing actual software engineering, especially in a team environment.
- **Debugging is a critical skill** - Lee started off as a software analyst, which was a role that was much more focused on diving deep and fixing issues as opposed to churning out new features. The experience Lee got here was extremely valuable and continued paying dividends across his career, even after he transitioned to SWE.
- **Help others and keep an open mind** - Everyone works in different ways and will be comfortable/uncomfortable in situations that don't match that of others. This includes the neurodivergent population like autistic people, those with ADHD, and more. Be a true teammate by being understanding and accepting of these differences. Assume good intent, and if you aren't sure how you can best support a teammate, just ask them!

To learn more from Lee, you should 100% connect with him on LinkedIn where he writes some of the best posts (and comments) on the entire platform: [Lee's LinkedIn](https://www.linkedin.com/in/lmckeeman/)

Here's some of the incredible wisdom Lee has shared on Taro:
- ["What does it mean to not require handholding anymore?"](https://www.jointaro.com/question/5vEWajcZlSi7nlohTGtJ/what-does-it-mean-to-not-require-handholding-anymore/)
- ["How to Balance Responsibilities: Prioritizing Personal Work vs. 'Glue Work' in a New Team Environment."](https://www.jointaro.com/question/9NL4LP40xHy5sgGMvsmB/how-to-balance-responsibilities-prioritizing-personal-work-vs-glue-work-in-a-new-team-environment/)
- ["Can someone elaborate on "always treating feedback as a gift"?"](https://www.jointaro.com/question/4DoEnMIq2ISadfAJuwp9/can-someone-elaborate-on-always-treating-feedback-as-a-gift/)
- ["What do career levels structure in big tech company look like? What are the responsibilities for each level?"](https://www.jointaro.com/question/qV5oikdcgs4GWmGeousX/what-do-career-levels-structure-in-big-tech-company-look-like-what-are-the-responsibilities-for-each-level/)

Master The Behavioral Interview [Part 17] - Staff Engineer

Staff engineer is a level that most engineers never reach (when using the expectations and compensation that FAANG/FAANG-adjacent companies have of Staff). This lesson teaches you:

- The expectations from a staff engineer overall and how that reflects in behavioral interviews
- The kinds of stories staff engineers tell in behavioral interviews

You can learn about Staff Engineer archetypes in our senior -&gt; staff course here: <https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/why-have-archetypes/>

[Masterclass] How To Manage Your Time Optimally In Tech And Achieve More Results

Ever wondered what separates software engineers at FAANG and top startups from the rest? One of the big reasons is their ability to manage their time well to supercharge their productivity. At the end of the day, how hard you work and how naturally talented you may be aren't relevant if you aren't able to use your time efficiently.

Here are our Top 5 points from this masterclass (in no particular order):
- **Focus on just 1 thing** - Have a goal for every single work day. Make it more concrete by writing it down. Humans are naturally bad at multi-tasking; narrowing everything on your plate to a single task brings clarity which leads to action.
- **Break things down** - By decomposing big projects into smaller and smaller sub-tasks, you are making it more digestible and actionable. This is an especially important skill for more senior engineers and tech leads as they will need to take in huge problems and split them up into smaller chunks to delegate to others. How good a software engineer is at this is a key attribute of their seniority.
- **Move your phone out of arm's reach** - Modern-day smart phones are great, but they are also super-effective distraction machines. Relying on raw self-will to resist checking your phone every 5 minutes is overrated and often ineffective. Introduce that extra friction.
- **Find an accountability partner** - Humans are a social species, so we naturally don't want to let others down. Peer pressure is some of the most effective pressure there is and finding someone who you care about and is counting on you is often more powerful than any collection of time management tactics (including the ones in this masterclass).
- **Get consistent sleep and exercise** - Software engineers in particular will claim that they "don't have enough time" to do these. Sacrificing sleep and exercise is the classic mistake of getting a short-term gain with huge sacrifices in long-term value. These 2 things are activities you *make* time for. Get ~8 hours of sleep each day and do ~30 minutes of exercise 3-5 times a week. After a few weeks/month, you will see a huge boost in your energy and mental clarity from doing these.

Related resources:
- [Strategies To Stop Procrastination](https://www.jointaro.com/lesson/90PJpQEWVdVK47yh6IiB/strategies-to-stop-procrastination/)
- ["How do I optimize my sacred hour at work?"](https://www.jointaro.com/question/l8dzUVTu99CahofQsYAi/how-do-i-optimize-my-sacred-hour-at-work/)
- [Presentation Slides](https://docs.google.com/presentation/d/1MCEx7X592VfvdWlFi4JrhSffiDIeNyc1FsqDJMy8hvI/edit?usp=sharing)

How To Get Real Feedback So You Can Actually Improve

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:

- ["I got some pretty "unspecific" feedback. How can I sharpen it to make more actionable?"](https://www.jointaro.com/question/gKsY3J4x5rz2zdG2OXYJ/i-got-some-pretty-unspecific-feedback-how-can-i-sharpen-it-to-make-more-actionable/)
- ["I work in a small company with no formal perf review system - How can I get feedback to improve?"](https://www.jointaro.com/question/ZkjOqjW2ou4LhJ0HyIIK/i-work-in-a-small-company-with-no-formal-perf-review-system-how-can-i-get-feedback-to-improve/)
- ["How do I find a proper mentor within my company?"](https://www.jointaro.com/question/53nM0O5iemQD5K5ZQkYE/how-do-i-find-a-proper-mentor-within-my-company/)

Master The DSA Interview [Part 3] - Struggling? That's Completely Normal

You are smarter than you think. Yes, this is even true if you're struggling with LeetCode easy problems. This lesson teaches you:

- Why engineers often underestimate their ability when it comes to data structures and algorithms
- How the learning progression curve for data structures and algorithms works for 90%+ of engineers
- How to set up your mentality and goals when it comes to studying data structures and algorithms

[Masterclass] How To Come Up With 100k+ Users App Ideas You Can Build For Free

Start with a simple side project and keep iterating on it to separate your side project from the rest.

Related resources:
- [[Masterclass] How To Build And Grow Tech Products To 500k+ Users For Free](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/)
- [How Alex Made An App That Got 80k+ Users In 1 Month](https://www.jointaro.com/lesson/GlSjjLhuUdHt5drq3l5F/how-alex-made-an-app-that-got-80k-users-in-1-month/)
- ["Finding a mobile app idea - How to do it?"](https://www.jointaro.com/question/KJ4VXh6rUhKbWeiJoRDe/finding-a-mobile-app-idea-how-to-do-it/)
- ["What are some of the side income or passive income sources you can suggest?"](https://www.jointaro.com/question/URhejS9m02tEFM9WLZsd/what-are-some-of-the-side-income-or-passive-income-sources-you-can-suggest/)
- [Presentation Slides](https://docs.google.com/presentation/d/1ai8lxU1B-bH35iiSFf5hvk6NjAHpUyF2rshjyDipvaY/edit?usp=sharing)

[Masterclass] How To Have Impactful 1 on 1 Meetings

Related resources:
- [[Taro Top 10] Communicating Effectively As An Engineer](https://www.jointaro.com/playlist/yJ6oybePeu93sDSZ1GiQ/)
- [How To Effectively Leverage Skip Level 1:1s](https://www.jointaro.com/lesson/TToehFEc738PBhJcALwL/how-to-effectively-leverage-skip-level-11s/)
- ["Coffee Chat Questions With a Tech Lead - What to ask?"](https://www.jointaro.com/question/jGNZthqhvzYPiMckPEl1/coffee-chat-questions-with-a-tech-lead-what-to-ask/)
- [Presentation Slides](https://docs.google.com/presentation/d/1O1bUrK1NgyfYoMkIqCFJ0SvXv-IQlPhP1gYzBp95abU/edit?usp=sharing)

Questions You Can Ask To Evaluate An Engineering Manager

Here are some questions you can ask to engineers on a team to evaluate the engineering manager:
1. How has the manager been able to grow you? How clear is their advice? 
2. Is the team more on the stable or thrashy side? 
3. What has the team struggled with historically? 
4. What has the manager done to uphold work / life balance (WLB) and minimize burnout?

Here are some questions you can ask directly of the manager: 
1. How do you prioritize tasks and projects within your team? Can you walk me through your process for making those decisions?
2. How do you handle conflicts or disagreements among team members? Can you provide an example of a time when you successfully resolved a conflict within your team?
3. How do you ensure that your team members are growing and developing in their roles? Do you have a process for providing feedback and setting goals with team members?
4. How do you measure the success of your team and your individual team members? What metrics do you use?
5. How do you balance the needs of your team with the needs of the company? Can you provide an example of a time when you had to make a difficult decision that balanced those competing interests?
6. How do you stay up-to-date with new technologies and industry developments? Do you encourage your team members to do the same?
7. How do you foster a culture of collaboration and communication within your team? Can you provide an example of a successful collaboration within your team?
8. How do you handle failure or setbacks within your team? Can you provide an example of a time when your team faced a setback and how you supported your team through it?
9. How do you ensure that your team is delivering high-quality work on time? Do you have a process for reviewing and testing code?
10. How do you prioritize work-life balance for your team members? Do you encourage them to take breaks and disconnect from work outside of working hours?

This video is a clip from our masterclass about how to find a good engineering manager. You can watch it here: [[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/)

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.

Mastering data structures and algorithms (colloquially known as "DSA") is a frustrating experience: It requires such a different type of thinking and is rarely required on the actual software engineering job. This is why if you want to get good at DSA, you need the right mentality first.

Here are the core points from the video:
- 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!

Related resources:
- [[Taro Top 10] Effective Interview Prep](https://www.jointaro.com/playlist/HLBYxJI7D1j8STolrwum/)
- [[Taro Top 10] Finding A Tech Job](https://www.jointaro.com/playlist/E6R0wVJ5EyCfVnVrlfno/)

Amazon Behavioral Interview [Part 1] - Intro

This video introduces a mini-course designed to help viewers master behavioral-based interview questions, commonly used by top companies like Google and Amazon.

- **Focus:** The course emphasizes a framework and process to effectively answer these questions, drawing on the instructors' extensive experience (one was a Google interviewer, the other an Amazon Barraiser).
- **Benefits:** By learning this approach, viewers can confidently handle any interview, reduce stress, and significantly increase their chances of landing their desired job.
- **Content:** The course includes downloadable worksheets and other resources to guide viewers through the process of mastering the "STAR" method (Situation, Task, Action, Result) for answering behavioral questions.
- **Instructors:** The instructors have a combined wealth of experience in interviewing and being interviewed at top companies, ensuring the course provides valuable and practical insights.
- **Goal:** The ultimate goal is not just to teach the STAR method, but to boost viewer confidence and significantly improve their chances of success in job interviews.

Learn more about Alan's job search program, Kadima Careers, using this [discount link](https://signup.kadimacareers.com/mQBsDvu).

How To NOT Learn A Codebase

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

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

Instead, just dig in and start coding!

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

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

Break Into Tech And Become A Software Engineer [Part 1] - Intro

In this lesson, we explore how anyone can transition into a tech career, regardless of their background.

This lesson covers:

- Brian's journey from a troubled past to becoming an engineering manager and business owner
- How his late start in tech, at age 30, began with small interactions while driving for Uber
- The decision to attend a coding bootcamp, where his passion for coding took off
- The importance of support from friends and community in learning to code and landing a first job
- The idea that people from all kinds of backgrounds, including those with difficult pasts, can break into the tech industry

If you need extra help breaking into tech, join Brian's exclusive, cohort-based bootcamp (just 10 students per batch). Use this link for Taro users for $800 off: <https://www.parsity.io/taro>

Connect with Brian on LinkedIn: <https://www.linkedin.com/in/brianjenney/>

DSA Crash Course [Part 7] - Big-O Examples Lecture

In this lecture, Alvin shows examples of code with different Big-O complexities.

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/>

Level Up Your Code Quality As A Software Engineer [Part 10] - Sweat The Details, Call Out Edge Cases

Building software that "works" is easy. Building software that truly works in all viable scenarios is hard and what separates the great engineers from the mediocre ones, especially at Big Tech. This lesson will teach you: 

- Why mistakes are extremely punishing in software
- The relationship between the happy flow and edge cases
- Why being detail-oriented is an extremely valuable asset in tech, especially for your code quality
- The mental framework to have as a software engineer to proactively call out edge cases in a systematic way

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.