Building Software For Optimal Learning Example - Login Flow

A lot of junior engineers wonder why they have working software projects on their resume but aren't able to get a job. 99% of the time, it's because the projects they have built aren't anywhere near production quality.

This video covers an in-depth, concrete example of how you can level up a feature to be truly impressive in a portfolio:
- Bad login flow (bare minimum only):
  - Email input
  - Password input
  - Submit button which probably stores inputs on the server
- Good login flow (additional components on top of the above)
  - Ability to view the password in plaintext
  - Confirm password
  - Validate email
  - Password strength protections
  - "Forgot your password?" flow
  - Password hashing
  - Login attempt throttling

Related resources:
- [[Masterclass] How To Learn Quickly In Tech](https://www.jointaro.com/lesson/u9ldIvrTvV1wfWExccDR/masterclass-how-to-learn-quickly-in-tech/) - The full video this clip was taken from
- [How The Best Software Engineers Learn - The Lego Model](https://www.jointaro.com/lesson/9cVK5zsAQstbTCc1wrWx/how-the-best-software-engineers-learn-the-lego-model/)

The Most Dangerous Thing People Don't Realize About FAANG

So many engineers focus on just the interview when it comes to breaking into Big Tech. However, cracking the FAANG interview isn't the main thing you should worry about: *Surviving at Big Tech is what's truly hard.*

Here are the core point from the video:
- **Big Tech expectations are very high** - In exchange for world-class pay, you are expected to have world-class productivity. For most engineers coming from non-Big Tech backgrounds, they're going to have to put out more work that's also higher quality compared to what they've normally done.
- **It can be hard to adjust** - This is especially relevant if you spent a very long time (10+ years) working at companies that weren't as cutting edge as Big Tech prior to going there. It is very difficult to do things in a completely different way to what you're very used to.
- **Performance review is stressful** - Since these companies are so big and have so much process, performance reviews are incredibly thorough and take a long time. It often takes months to write and collect all the feedback necessary to compute the final rating. Couple this with fear of PIP and stack ranking and you have an environment that really puts engineers on edge.

Related resources:
- [[Masterclass] How To Navigate Your Performance Review In Tech](https://www.jointaro.com/lesson/b0B8uqIAUnBLE10jJHJG/masterclass-how-to-navigate-your-performance-review-in-tech/)
- ["What's the difference between a low performer software engineer and a high performer?"](https://www.jointaro.com/question/nMxx2EMVIlJbl1oK4SGu/whats-the-difference-between-a-low-performer-software-engineer-and-a-high-performer/)

Ace Your Tech Interview As A Software Engineer [Part 5] - Dynamic State vs. Prepared State

The overwhelming majority of software engineers went to college and grew up in a very academically-inclined environment. Bringing the mentality cultivated from that experience to the job search often unfortunately has bad consequences. This lesson teaches you:

- Why traditional learning methods don't translate well to software engineering
- The difference between *prepared state* (how you grew up learning) and *dynamic state* (how you should actually learn)
- A defining trait of the most successful interviewers, which most candidates don't have
- How to train yourself properly when it comes to your interview preparation and overall learning

I Sucked At This For 25 Years As An Engineer – 8 Tips For Communication

Communication is the skill that separates the best engineers from the mediocre ones. 

**Nothing great is built alone**, so even if you’re the best coder in the world, at some point in your career you will have to work with others. When you get to that point, communication is how you get things done. 

Here are 6 tactical communication tips for engineers (and there are two more in the video!)

**1. Learn how to say no. If your PM or manager comes to you with a request, don't just say no.**

Instead, say "not right now" and explain why you're choosing to do other high-priority work. This approach lets you acknowledge the request or the idea, but you’re able to firmly/politely say no by explaining why you want to stay the course. 

**2. Use tentative language**

Especially for critical feedback, leave room for discussion. One way this manifests is during code review: some of the best engineers at Meta actually ended their feedback with a question mark:

"Crash with negative input" ➡️ "Crash with negative input?" One character makes a big difference!

**3. Make people feel heard**

In 1:1s, I’ll literally say "Let me say that back to you" and repeat back what they said to me. This works magically well.

Even if you disagree, this strategy lets you start from a place of agreement -- the person was heard.

**4. Say thank you**

*Proper* thank yous are about more than sending a one-line message. A proper thank you involved thanking them in your launch post or sending them a thank you when you hit a milestone. That's how you build deep relationships.

**5. Advance the conversation**

This is a personal pet peeve for Rahul. If we're talking about where to get lunch, and I propose Indian food, don't just say "I don't like Indian." You need to propose some alternatives in that response. Also, google the ["no hello"](https://nohello.net/) philosophy.

**6. Know your audience**

Many engineers either provide too much or too little context. Communication is an exercise in empathy. You have to figure out what your audience cares about and deliver value to them.

Related links:
- [Taro's communication guide](https://www.jointaro.com/playlist/hVdLQQzfslaYarLSCmmy/)
- ["When should you offer to help a colleague?"](https://www.jointaro.com/question/u4GMlmLOuaU4Olhh2XAy/when-should-you-offer-to-help-a-colleague/)

Getting To The Top 1% Of Amazon Engineers - Productivity Tips From A Life Engineered

Steve Huynh, from the popular channel A Life Engineered, talks about the 3 parts of his productivity system. After spending more than 17 years at Amazon and obtaining the coveted Principal Engineer title, Steve spends a lot of time thinking about peak productivity. 

Timestamps:
- 0:00 - Intro to Steve
- 0:40 - Why invest in a system for time management?
- 2:30 - Have a healthy relationship with notifications
- 6:02 - Optimize your schedule
- 9:00 - Optimize for impact (not comfort)
- 11:25 - How Steve organizes his time

Related questions:
- [When to check email to maximize productivity?
](https://www.jointaro.com/question/aBmMAXWqsQ8gYxyAJcpq/when-to-check-email-to-maximize-productivity/)
- [Is typing speed important as an engineer?](https://www.jointaro.com/question/JeBsvDeGQf01ritm98W0/is-typing-speed-important-and-what-speed-is-acceptable-for-a-dev-looking-to-work-at-faang/)
- [How do I estimate my sprint tasks better?](https://www.jointaro.com/question/3R6yRStSzDMmvLRCiMVV/how-do-i-estimate-my-sprint-tasks-better/)

Connect with Steve: 
- [Taro](https://www.jointaro.com/profile/aZJL3ucq9dQnscO09F4JDRkgPo72/)
- [YouTube](https://www.youtube.com/@ALifeEngineered)

Properly Learning From Software Engineers More Senior Than You

True or false: What is built by a very senior engineer is more important than how they built it.

When observing very senior engineers, what should you look for to properly learn from them?

True or false: At the top tech companies, the very senior engineers make 5-10x more than their very junior counterparts because they work 5-10x harder than they do.

Which are good examples of questions you can ask when understanding a very senior engineer's behavior?

True or false: At the top tech companies, you are told less and less what to do as you grow more senior, working on more ambiguous projects while having greater freedom to choose what you work on.

As a junior software engineer, it can be daunting understanding the senior and staff engineers on your team. This video covers the mindset shift to make to start leveling yourself from properly observing them, achieving career growth without these engineers having to formally mentor you.

Here's the core points:
- **Observe more senior teammates' behavior** - Principal engineers will usually have 10x the impact of a junior engineer. They don't get there by working 10x as hard - We all have the same 24 hours in a day. Instead of asking yourself *what* these great engineers are getting done, ask yourself, "*How* do these engineers get stuff done?". Marveling over their much larger impact won't get you anywhere - You start really learning from these engineers when you start breaking down the path they took to achieve that impact.
- Here are more specific axes to observe:
  - **Communication** - How do these engineers share status updates and rally the team around their ideas?
  - **Direction** - How do they prioritize projects and select the best ones?
  - **Quality** - How do these engineers protect the sanctity of launches? What kind of feedback are they leaving in code review? What good habits do they have when they submit code? How do they facilitate system design discussions?

Related resources:
- ["What's the core insight behind quick growth?"](https://www.jointaro.com/question/nJ762p255cGyuth36H6w/whats-the-core-insight-behind-quick-growth/)
- ["How do you get the most out of mentorship?"](https://www.jointaro.com/question/IbuZydz0QzsVVqESVaxQ/how-do-you-get-the-most-out-of-mentorship/)

Level Up Your Code Quality As A Software Engineer [Part 18] - Have A Test Plan

Test plans are something many tech companies don't do, and it's a shame. Pull request test plans are one of the easiest things you can do as a software engineer to really level up your code review experience and ultimately the quality of your code. This lesson will teach you:

- What a test plan is and the many, many benefits it provides. There's a reason Meta requires engineers to have a test plan in their diffs (pull requests)
- How to creative with your test plans when your code is hard to demo (very applicable for back-end facing engineers)
- The many benefits of having a thorough test plan and the many downsides of not having a test plan
- What the ideal test plan looks like, which we'll cover through a couple in-depth examples

Ace Your Tech Interview As A Software Engineer [Part 30] - Talk To Your Recruiter

Too many software engineers see the tech recruiter as the enemy when they really shouldn't be. In reality, one of the core keys behind a successful interview loop is leveraging your recruiter optimally. This lesson teaches you:

- How to understand the world through the eyes of a recruiter, particularly when they have given you a chance and let you into their company's interview process
- Why software engineers usually fail to collaborate with their recruiter properly to maximize their chances of passing the interview
- The true cost of interviewing a software engineer (it's probably higher than you realize)
- How you can reach out optimally to recruiters to figure out what's going to be on your upcoming interview with an in-depth message example

Top System Design Interview Mistakes [Part 11] - Don't Assume the Happy Path

In this segment, we focus on a common issue often seen with more junior engineers - Only considering the happy path when designing systems. Here’s the core points from the video:

- As engineers, our goal is to design systems that work reliably even when things go wrong. A system that fails 1% of the time is often unacceptable

- We need to anticipate and design for potential issues, not just ideal scenarios

- Proactively identifying weaknesses and planning solutions demonstrates strong engineering skills and foresight

- Documenting our design and potential problems as we go helps manage complexity and ensures we address edge cases effectively

- We go through a detailed example of all this with a ride-sharing system design problem

If you need extra help with your system design interview, [Formation.dev](https://formation.dev/partners/taro) can provide you hands-on, personalized support. Join us here: <https://formation.dev/partners/taro>

How To Learn A New Codebase Fast

What is the best way to learn a codebase?

True or false: In software, experimenting and making changes is cheap, so a great way to learn is by trying a lot of things and seeing what happens, even if you do not fully understand the overall codebase yet.

Why is structured learning like tutorials and courses not effective for actually learning a codebase?

True or false: Before you jump into a codebase, you should ideally get a certificate in that tech stack before working with it.

Which of these is a good way to learn a codebase with your first code changes within it?

True or false: Breaking something locally is an effective way to learn a codebase.

- The best way to learn a new codebase is to learn by doing.
- Don't get paralyzed reading documentation or getting a certificate before jumping into a codebase.
- Start tinkering ASAP. It doesn't matter if you don't fully understand the codebase - Just do small changes like deleting a line or flipping a variable and then see what happens after you build the code.
- Alex's standard: Put out a commit/pull request for a new codebase within 2 days.
- You want to get code into review as soon as possible, because the feedback you get on your pull request is where the real learning happens. Don't worry about the quality; it's going to be bad in the beginning like with any newbie - The important thing is that you submit something out there into the world so your teammates can tell you how to get better.

Related resources:
- [How To Figure Out Which Parts Of A Codebase Matter](https://link.jointaro.com/PdpWBjAzU7NVTamf6)
- [Learning A New Codebase Fast As An Intern](https://link.jointaro.com/SMaLvqCVeoH9MmvV7)

Maximize Your Productivity As A Software Engineer [Part 13] - Decomposition

When you get a huge project as a software engineer, it's easy to get overwhelmed and just sort of... do nothing (or close to it). This lesson teaches you:

- What a well-decomposed project looks like with a concrete example
- How decomposing projects hacks your brain to make it more motivated and productive

To dive deep into tactics on decomposing projects, check out our in-depth explainer: ["How do I make software less overwhelming?"](https://www.jointaro.com/question/YseMPDw538jhyS1MWlTs/how-do-i-make-software-less-overwhelming/)

Learn from the code quality course here: [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

Effective Communication Guide [Part 7] - Finale + How You Can Learn More

- Zooming out, good communication is about *building positive energy*. Sharing feedback to help someone improve, empathizing with people's struggles, giving heartfelt thanks - These all generate positive energy.
- If you're feeling angry or frustrated, take some time to calm down and collect your thoughts, especially if you want to share that in a more public setting. After you've done this, then you can share your problems in a constructive way.
- This series just barely scratches the surface when it comes to communication. Just keep practicing and you'll get better!

Top System Design Interview Mistakes [Part 14] - Don't Save the Hardest for Last

In this lesson, we focus on the importance of addressing the most challenging aspects of a system design problem early on:

- We often make the mistake of delaying the hardest parts of the problem. While starting with simpler tasks might seem productive, it can lead to incorrect design choices and suggest we're unaware of the core challenges

- We should immediately focus on the most complex parts of the problem. Tackling these challenges first demonstrates our understanding and prevents us from getting sidetracked by less critical aspects

- In our interview example, we show how the candidate misses the core problem behind the messaging app, tackling the simpler pieces instead

- Effective problem solving involves working through strategies for the hardest issues, like the message-to-notification fan-out, and evaluating their pros and cons

- By focusing on the toughest problem first, we show strong judgment and prioritization skills. This approach ensures that we manage our time well and address the most critical aspects of the design effectively

If you need extra help with your system design interview, [Formation.dev](https://formation.dev/partners/taro) can provide you hands-on, personalized support. Join us here: <https://formation.dev/partners/taro>

Creating A Portfolio That Makes Recruiters Come To You

Building a personal portfolio looks nice and feels good, but it *rarely* helps engineers find jobs. In this video, we cover how you can truly stand out as a software engineer and make the jobs come to you (instead of the other way around).

Here are the core points:
- Building a portfolio website can be a nice exercise, but don't spend too much time on it. *Don't expect to get any inbound recruiter reach outs due to your portfolio site*. There is no real central repository of them that recruiters browse.
- In terms of what recruiters do browse, it's primarily LinkedIn. If you have this portfolio energy, it's much better spent polishing your LinkedIn profile instead.
- At the end of the day, a portfolio website is resume++. This means that your foundation is still your resume: Make sure your resume is *extremely* sharp before you even consider building a portfolio website.
- Alex found a lot of success having his Google Play developer page be a portfolio as it hosted real, verifiable products on it. Since his side projects got millions of installs combined, he's gotten reach outs from top companies like Uber, Square, and Instacart through his Google Play developer email.

Related resources:
- ["What technologies or stacks should I create a project to add in my resume for entry level software jobs?"](https://www.jointaro.com/question/c0DiG5ureLbkZ1mKD9Rf/what-technologies-or-stacks-should-i-create-a-project-to-add-in-my-resume-for-entry-level-software-jobs/)
- ["I want to land a job in a big tech as a SWE - How to do it?"](https://www.jointaro.com/question/MWJfUBnnUr8CKYFCO8bp/i-want-to-land-a-job-in-a-big-tech-as-a-swe-how-to-do-it/)
- ["Can Github stars grab big tech recruiters' attention?"](https://www.jointaro.com/question/XaUn4XuIBMSmrr5fcHIT/can-github-stars-grab-big-tech-recruiters-attention/)

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

DSA Crash Course [Part 14] - Pair Product Approach

In this lesson, Alvin explores the strategy to solving the following interview problem:

> Write a function, *pair_product*, that takes in a list and a target product as arguments. The function should return a tuple containing a pair of indices whose elements multiply to the given target. The indices returned must be unique.
>
> Be sure to return the indices, not the elements themselves.
>
> There is guaranteed to be one such pair whose product is the target.

```
pair_product([3, 2, 5, 4, 1], 8) # -> (1, 3)
```

```
pair_product([3, 2, 5, 4, 1], 10) # -> (1, 2)
```

```
pair_product([4, 7, 9, 2, 5, 1], 5) # -> (4, 5)
```

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

Understanding Performance Review Ratings

- The end goal of a performance review is to assign every employee a rating, which is like a grade in school.
- Know what ratings are good
  - What's average?
  - What puts you in the "danger zone" or on a formal performance improvement plan (PIP)?
  - Which rating is great?
- Understand which rating is necessary for promotion

Ace The ML System Design Interview [Part 2] - Why You Need A System

The machine learning system design interview can be daunting, but understanding common pitfalls can help you succeed. Here are the core points from this lesson:

- Align with the interviewer on the problem statement before diving into design to ensure the right problem is being solved
- Use a structured approach: start with big-picture system design, then address data considerations and modeling, only discussing deployment and operations if time allows
- Clearly articulate reasoning by explaining the "why" behind design choices and considering trade-offs between different techniques
- Take control of the interview by making assumptions, validating them with the interviewer, and simplifying the problem to fit within the given time
- Write down key assumptions and decisions to maintain clarity and provide a reference for both yourself and the interviewer

If you like what Ilya has to say, subscribe to his YouTube for more high-quality ML/AI career guidance: [MLEpath - YouTube](https://go.mlepath.com/taro-youtube-mlepath)

If you want hands-on support from Ilya to crack the FAANG ML interview, join his coaching program: [MLEpath - Coaching Program](https://go.mlepath.com/taro-march-25)

Maximizing a Severance Package 2/9 - The Law

There are lots of laws around termination of employment, and they vary widely by country. Let's talk about what companies must (or must not) do when doing a Reduction in Force (RIF) or layoff.

- Connect with [**Ethan on LinkedIn**](https://www.linkedin.com/in/ethanevansvp/)
- Taro members get a discount to join [**Ethan's Level Up community**](https://levelupwithethanevans.substack.com/taro25)

15 SWE Years In 1.5 Hours [Part 3] - Writing Good Code

With the rise of helpful online resources like StackOverflow and especially genAI tools like ChatGPT, learning to write code is now easier to ever. Where engineers earn their stripes (and the right to be paid $100k+ per year) is with their *code quality*. This lesson teaches you:

- The only true way to learn how to write good code
- Why copy-pasting what FAANG engineers do isn't a shortcut to writing good code
- How to objectively measure the quality of your code

To dive deeper into code quality, take our course here: [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

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.