Ace Your Tech Interview As A Software Engineer [Part 25] - Practical Coding

Practical interview coding rounds are the purest form of software engineering and what software engineers generally hope the interviews are (at least when they complain about data structures and algorithms problems online). This lesson teaches you:

- What a practical coding round is and when to expect it
- What kinds of companies give practical coding rounds
- How to prepare for practical coding rounds

To get the absolute best practice for practical coding rounds, check out our side projects playlist: [\[Taro Top 10\] Building Impressive Side Projects](https://www.jointaro.com/playlist/vKUWMgmmaEvzcYUXZs4B/)

Maximize Your Productivity As A Software Engineer [Part 21] - Verify Your Foundation

Work and life are deeply interconnected, despite how much we want this to not be the case. If your personal foundation isn't there, it's hard to get anything done working a mentally-intensive job like software engineer. This lesson teaches you:

- How it's possible to implement literally all the advice from this course and still not be productive
- What to do if you're stuck in a productivity rut that you just can't get out of
- The ingredients behind a healthy personal foundation

Learn more about how to have good work-life balance here: [\[Taro Top 10\] Work-Life Balance](https://www.jointaro.com/playlist/JNCZ1vbRF3NwsOQCqblt/)

Quick Tips To Get Higher Quality Code Reviews Faster

In this segment, we focus on how to **ramp up effectively and build trust through proactive code review habits**. By learning from past diffs, referencing previous work, and anticipating reviewer questions, we strengthen both our code and our relationships with teammates.

### Key Takeaways:

- **We study past code reviews to ramp up faster**: Reviewing recent diffs helps us identify codebase hotspots and learn how experienced teammates structure context, write test plans, and address feedback.
- **We reference prior diffs to preempt questions**: When making similar changes, we compare our approach to earlier ones (especially from tech leads) and explain why we took a different route—saving reviewers from needing to ask.
- **We proactively comment on our own code**: By flagging areas we’re unsure about and inviting feedback up front (e.g., naming choices or design alternatives), we guide reviewers toward the most relevant parts and show that we care about quality and collaboration.
- **We show respect for reviewer input**: Code review isn’t just about getting approval—it’s about listening. Ignoring thoughtful feedback undermines trust. We strive to acknowledge and incorporate suggestions to create a positive, team-first review culture.
- **We demonstrate maturity through initiative**: These habits—referencing historical context, asking for help, and valuing reviewer input—aren’t just tactical. They signal leadership and self-awareness, accelerating our growth and reputation on the team.

Grow From Mid-Level To Senior Engineer [Part 15] - What's The Plan?

The best engineers act proactively instead of reactively, and this is critical for successful project execution. This lesson teaches you:

- The evolution in ownership of a project when it comes to a mid-level engineer vs. a senior engineer
- What a good project plan looks like

Check out the system design course for an excellent example of a master spec document: [\[Course\] Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

15 SWE Years In 1.5 Hours [Part 5] - Succeeding In School

Most software engineers start off their journey in tech by getting a university degree. However, most students don't leverage their time in school optimally. This lesson teaches you:

- The most valuable asset you get from school (hint: it's not good grades)
- Why school isn't very effective at teaching you how to do software engineering in the real world
- What you should do instead to enhance your technical skills instead of purely focusing on getting good grades

DSA Crash Course [Part 41] - Breadth First Values Approach

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

> Write a function, *breadth_first_values*, that takes in the root of a binary tree. The function should return a list containing all values of the tree in breadth-first order.

```
a = Node('a')
b = Node('b')
c = Node('c')
d = Node('d')
e = Node('e')
f = Node('f')
a.left = b
a.right = c
b.left = d
b.right = e
c.right = f

#      a
#    /   \
#   b     c
#  / \     \
# d   e     f

breadth_first_values(a)
#    -> ['a', 'b', 'c', 'd', 'e', 'f']
```

```
a = Node('a')
b = Node('b')
c = Node('c')
d = Node('d')
e = Node('e')
f = Node('f')
g = Node('g')
h = Node('h')
a.left = b
a.right = c
b.left = d
b.right = e
c.right = f
e.left = g
f.right = h

#      a
#    /   \
#   b     c
#  / \     \
# d   e     f
#    /       \
#   g         h

breadth_first_values(a)
#   -> ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h']
```

```
a = Node('a')
#      a

breadth_first_values(a)
#    -> ['a']
```

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

Master The Behavioral Interview [Part 9] - The Interviewer Isn’t You

One of the biggest mistakes software engineers make during behavioral interviews is not having empathy. This lesson teaches you:

- A crucial way to understand the goal of a behavioral interview
- How a lack of empathy leads to immediate tactical failure in behavioral interviews
- How you can use empathy to take in a non-confusing way

CRUCIAL Ingredient For Senior Engineer Performance: Assembling A Feedback Team

Here are the core points from the lesson:

- Be deliberate about who you request performance review feedback from: Don't just go through your half or year without a plan here and just request feedback from those you happened to work closely with at the end.
- Work backwards from how you want to be perceived at the end of the performance review cycle. Figure out the picture of your performance you want to paint and come up with the bench of peers who can paint that picture for you. From there, strive to build deep relationships with those peers (for advice on how to do that, here's [our course on Effective Communication](https://www.jointaro.com/course/effective-communication-for-engineers/)).
- Make sure that feedback isn't duplicated: You don't want to waste your peers' time by having them write effectively the same thing about you.

Manager 1 on 1s Are A Litmus Test For Seniority

True or false: In tech, operating at senior levels means that you are driving more, if not most, of the conversation in your manager 1 on 1s.

Why do senior employees tend to drive more of the conversation in manager 1 on 1 meetings?

One-on-one meetings evolve as career levels advance. A key sign of professional growth is taking ownership of these conversations and using them to drive impact.

- **Initiative reflects seniority**: If recent one-on-ones are led primarily by a manager with direction and feedback, it's likely an early-career dynamic. As experience grows, the expectation shifts toward independently setting priorities.
- **Ownership of agenda is critical**: A senior-level contributor brings a clear agenda to one-on-ones, proactively using the time to align on strategy, surface blockers, or present ideas—not just receive instructions.
- **Setting direction is the goal**: Defining one’s own work and outlining what to focus on next are hallmarks of operating at a senior level. The more someone guides the conversation, the more they demonstrate leadership and self-management.

Level Up Your Code Quality As A Software Engineer [Part 24] - Infinite Layers Of Nesting

Nesting is great for birds, but terrible for code. Having too much nesting is one of the easiest ways to make code terrible. This lesson will teach you:

- Why deeply nested code is literally hard to read
- The early-return pattern to unfurl nested code
- How to compress conditionals properly (this includes how not to mess them up)

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.

Related resources:
- ["Why would a senior make themselves replaceable?"](https://www.jointaro.com/question/b5eUTVq4m9ANQ5QCUc3q/why-would-a-senior-make-themselves-replaceable/)
- [Why Great Engineering Managers Are Like Captain America](https://www.jointaro.com/lesson/a9s0fUXIWxm8sPigvXnL/why-great-engineering-managers-are-like-captain-america/)
- [What Makes A Truly Great Tech Lead - A VP of Engineering's Perspective](https://www.jointaro.com/lesson/uHqZZ15SK19MatEvLSO6/what-makes-a-truly-great-tech-lead-a-vp-of-engineerings-perspective/)

Structuring Your Manager 1 on 1

If you are working in a strong, high-growth tech company, what is a good frequency to meet with your manager?

True or false: Managers are extremely busy, so it is best to have ad-hoc 1 on 1 meetings with them based on whenever they are able to find a sliver of free time.

Weekly one-on-ones with your manager are essential for staying aligned, especially in high-growth tech environments where priorities shift quickly.

- **Weekly cadence is ideal**: Aim to meet with your manager every week; bi-weekly is acceptable at most. Anything less frequent than that is considered a red flag for team communication and alignment.
- **30-minute standard**: A 30-minute weekly meeting strikes the right balance—long enough to discuss key topics, but short enough to stay focused and avoid bloat.
- **Avoid reactive scheduling**: Don’t wait until problems arise to schedule one-on-ones. Recurring meetings prevent misalignment and build a strong, consistent feedback loop.
- **Proactive relationship management**: Regular one-on-ones foster stronger relationships, clearer communication, and better support between you and your manager.

Grow From Mid-Level To Senior Engineer [Part 14] - Work Towards The Team Goal

Software engineers aren't paid to write code; they're paid to solve problems. However, this mindset often takes years for engineers to truly internalize, often at the senior level. This lesson teaches you:

- How mid-level engineers and senior engineers react different when given a project
- The questions every senior engineer needs to ask when given a project
- What needs to be done in order to understand the true impact of a project

Don’t Do THIS Kind of Code Review - Healthy vs Unhealthy Comment Example

In this segment, we explore a crucial cultural principle in code review: **“You are not your code.”** The way we give feedback deeply influences team trust, learning, and psychological safety. Our goal isn’t to be “right”—it’s to help each other grow and to build a healthy, collaborative engineering culture.

### Key Takeaways:

- **We critique code, not people**: Everyone—from interns to staff engineers—writes imperfect code. We give feedback without attacking the author, always assuming good intent and shared goals.
- **We use empathy-driven language**: Ending comments with a question mark (“Have you considered…?”) or using tentative language (“This might miss an edge case…”) keeps feedback constructive and opens the door to discussion, not defensiveness.
- **We avoid destructive comments**: Terse feedback like “Did you even test this?” not only fails to help—it can demoralize authors and harm team culture. Being “right” is meaningless if it alienates collaborators.
- **We model humility, especially as senior engineers**: Seniority should amplify empathy, not authority. Even if we're confident, we acknowledge the possibility we're wrong and focus on dialogue, not dominance.
- **We prioritize helpfulness over harshness**: Great reviewers point to specific issues, offer reasoning, and invite collaboration. They focus on moving the work forward—not “winning” a debate.

By reviewing with empathy, humility, and clarity, we turn every code review into an opportunity to strengthen our team and elevate everyone’s craft.

Master The DSA Interview [Part 15] - Edge Cases

Too many engineers only care about the happy flow, but it is the easy thing to do. This lesson teaches you:

- Why handling edge cases is so important as an engineer, especially at FAANG
- The mindset you need to have to tease out edge cases systematically
- Common edge case scenarios for data structures and algorithms problems
- What a great edge case analysis looks like, explained with an in-depth example

Take the code quality 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/)

How to Crack System Design Interviews - Part 10: Preparation Resources

This video outlines resources and strategies to prepare for system design interviews. We can improve our performance by:

- **Building a strong vocabulary:** Familiarizing ourselves with key technologies and concepts (e.g., Amazon S3, Apache Kafka) helps us communicate ideas effectively and demonstrate practical understanding.

- **Developing theoretical knowledge:** We can gain a solid theoretical foundation through courses like Interview Ready, which covers high-level and low-level design concepts, design trade-offs, and other essential topics.

- **Gaining practical experience:** Mock interviews provide invaluable practice and build confidence for the real interview. Consider using free platforms or seeking discounts if available.

- **Utilizing online assessment tools:** If time is limited, leverage automated online judges to assess and reinforce understanding of system design components and their placement.

- **Prioritizing human interaction:** While online tools are helpful, prioritize mock interviews with experienced individuals for the most effective preparation and feedback.

A few tools mentioned: 

- Mock Interviews: [joinTaro.com/perks](https://www.jointaro.com/perks/)
- [Automated Design Judge](https://interviewready.io/question-list/system-design-judge/?_aff=JOINTARO)
- [General Resources for SD](https://interviewready.io/resources)

[Gaurav Sen](https://www.linkedin.com/in/gkcs/) has conducted 1000s of system design interviews while working at Uber and building his [YouTube channel](https://www.youtube.com/@gkcs) to 500K+ subscribers. His platform [InterviewReady](https://interviewready.io/?_aff=JOINTARO) combines video explainers, live Zoom classes, and an automated System Design Judge.

Master The Behavioral Interview [Part 18] - How To Get The Level You Want

If you don't play your cards right, it is easy to get down-leveled, which means getting a level lower than what you were at before. This is very common in bad markets and for engineers breaking into FAANG. It's also common if you don't give an amazing behavioral interview performance. This lesson teaches you:

- The overall strategy to not get down-leveled
- Tips you should follow to maximize your level

To better understand the expectations at each level, go through this: [\[Taro Top 10\] Understanding Engineering Levels](https://www.jointaro.com/playlist/e9rjATPbSyvRPsukXiHn/)

For resources on becoming a better engineer:

- [\[Course\] Nail Your Promotion As A Software Engineer](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/)
- ["What are software engineering fundamentals?"](https://www.jointaro.com/question/3VNPK7wol76s89EkgFeW/what-are-software-engineering-fundamentals/)

Grow From Junior To Mid-Level Engineer [Part 6] - Code Quality

In order to survive as a junior engineer, you need to learn how to code fast. The next step is to learn how to code *well*. This lesson teaches you:

- The 2 core components behind code quality
- The differences between junior and mid-level engineers when it comes to their pull request quality
- The many ingredients behind a clean pull request and which ones matter the most
- What a clean pull request looks like, one showing strong mid-level engineer behavior
- The differences between junior and mid-level engineers when it comes to their technical decision making
- Why communication is so important when it comes to technical decisions and how mid-level engineers do it better than junior engineers
- How to understand seniority from fresh junior to strong mid-level through the lens of technical decision making
- A simple metric to measure your code quality and see if you're making good progress to mid-level

Take the code quality 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/)

Write A Stellar Resume As A Software Engineer [Part 7] - It's Too Long

Having a resume that's too long is one of the easiest ways software engineers get their resume (and their job candidacy) immediately thrown out. This lesson teaches you:

- The optimal length for a resume
- Why shorter is better when it comes to resumes (and why very long resumes make 0 sense)
- How to convert your years of experience to a resume length
- Tactics to trim down your resume and make it more concise

DSA Crash Course [Part 87] - Outro

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

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.