The #1 Tried And True Tool For DSA Interviews

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

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:

- [\[Taro Top 10\] Finding A Tech Job](https://www.jointaro.com/playlist/E6R0wVJ5EyCfVnVrlfno/)
- [\[Masterclass\] How To Ace Your Big Tech Interview - System Design](https://www.jointaro.com/lesson/J3I9fTW9ulr6T9KjxpqY/masterclass-how-to-ace-your-big-tech-interview-system-design/)

Avoid This Common Bad Habit That Fails You Interviews

You should allocate enough time to prepare for your data structures and algorithms interview to avoid cramming at the last minute.

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

Hate Data Structures And Algorithms? Turn It Into A Habit

Set aside 30 minutes, 2-3 times a week, to build a regular habit out of learning data structures and algorithms.

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

Interview Preparation Is Way Better With Others

Here are the core points from the video:
- Social accountability is a good way to motivate yourself to work hard when studying data structures and algorithms, especially given how miserable studying them can be. Peer pressure works!
- Doing a mock interview with a friend can help you prepare for interviews because you are forced to explain yourself out loud. This process will be more akin to the actual interview process, far more than grinding LeetCode at your computer all day.

If you're looking for a mock interview partner, find one with [Taro Networking](https://www.jointaro.com/networking/): [https://www.jointaro.com/networking/?selectedServices=Mock+Interviews](https://www.jointaro.com/networking/?selectedServices=Mock+Interviews)

Related resources:
- [[Masterclass] How To Manage Your Time Optimally In Tech And Achieve More Results](https://www.jointaro.com/lesson/rnX9EKpzc43TgGW9MozG/masterclass-how-to-manage-your-time-optimally-in-tech-and-achieve-more-results/) - This is the time management session Rahul mentions
- [[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/)

The Amazing Non-Money Benefits Of Working At Big Tech

DSA Prep Is One Of The Highest ROI Activities On Earth

If you do a good job studying for your data structures and algorithms interview, you can set yourself up financially for the next few years.

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

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

How You Can Supercharge Your Team - Discovering Synergies

What Does A High Trust Team Mean For Code Review?

In this closing section, we focus on the importance of **building and operating within a high-trust engineering team**. Trust is not just a feel-good concept—it directly affects our productivity and velocity when shipping code.

- **We prioritize speed and trust in code review.** When we trust our teammates, we don’t block diffs unnecessarily. Instead, we approve with minor suggestions, knowing the author will follow through responsibly.
- **We use “accept with nits” to keep things moving.** For small, straightforward changes—like renaming variables—we leave a “nit” comment but still approve the diff to avoid introducing unnecessary delay.
- **We avoid slowing each other down over trivial issues.** Each extra cycle of “request changes” can delay code by 1–2 days. We conserve team momentum by trusting competent authors to resolve minor feedback themselves.
- **We treat time as our most precious resource.** Code review should add value without becoming a bottleneck. High-trust practices help us operate with both quality and speed.
- **We maintain expectations through communication.** Even when approving with nits, we clarify, *“Please address before landing,”* so everyone stays aligned on expectations without blocking forward motion.

Code Review MUST Be Fast, Otherwise The Team Is Unhealthy

In this final segment of the video, the speakers reflect on the crucial role that **code review turnaround time** plays in engineering culture, team productivity, and developer happiness. Timely reviews are not just a technical necessity—they reflect the team’s values and operational discipline.

- **We treat code review turnaround time seriously.** Our standard should be to review diffs within *one day*, two at most. Slow feedback cycles—especially taking 4–5 days—compound and slow down overall delivery velocity.
- **We recognize code review as a gatekeeper with real power.** Since all production code must pass through this step, bottlenecks here can deeply affect morale, productivity, and team trust.
- **We advocate for clear team expectations.** When reviews consistently lag, we push for a shared SLA (Service Level Agreement) around review times, ensuring accountability and smoother planning.
- **We balance urgency with respect.** While prompt reviews are key, we also avoid pestering reviewers within minutes of submitting. Giving at least 6 hours (unless it’s urgent) is a sign of maturity and respect.
- **We proactively build good habits.** Many of us block time at the end of our day to batch and respond to review requests, which helps us maintain velocity without excessive context-switching.

Avoid These Junior Engineer Mistakes With Code Review

In this video segment, we reflect on common mistakes and best practices around code submissions, especially relevant to early-career engineers. The discussion centers around how to be thoughtful and intentional in code reviews to earn trust and increase velocity over time.

- **We don’t treat code review as a speed game.** Moving fast at the cost of quality—like deferring fixes or separating tests from the initial diff—often backfires. We strive to bundle fully thought-out changes with tests as one atomic, reviewable unit.
- **We use RFC diffs to gather early feedback.** When we're unsure of direction, we create “Request for Comment” diffs clearly labeled as such. This helps reviewers give high-level input without getting stuck on minor details.
- **We always show proof of testing, even for small changes.** Even if our change is minimal (e.g., a refactor or doc update), we still confirm it compiles and passes existing tests to signal due diligence.
- **We think like reviewers.** Providing context, test signals, and clarity up front not only earns trust but speeds up the feedback loop and helps us land code more efficiently.

3 Ways To Write Deeper, More Impactful Code Review Comments

In this video, we explore how to give more impactful code reviews by moving beyond surface-level feedback and investing in deeper understanding and learning from experienced peers. The focus is on practical habits that help us become more thoughtful, effective reviewers.

- **We rely on automation for style and formatting.** It's not our job to catch syntax or stylistic issues—those should be handled by IDEs and CI systems with pre-agreed style rules.
- **We review code with a clear perspective.** Before reading the diff, we mentally plan how *we* would solve the same problem, which helps us offer more meaningful, constructive feedback beyond just approving what “looks fine.”
- **We learn by watching the best.** One of the fastest ways to improve as reviewers is to observe how senior engineers reject code—what they flag, how they communicate, and the patterns they look for.
- **We replicate good habits.** By studying thoughtful reviewers—like those who consistently flag performance issues like mobile frame drops—we can develop our own review instincts and level up faster.
- **We treat reviewing as an intentional skill.** There are no shortcuts; it takes practice, pattern recognition, and curiosity to become great at it. But by mimicking smart peers, we shortcut years of trial and error.

Don't Forget: Code Review Is Public And Has Huge Consequences

In this final segment, we emphasize how **code review is not just a technical exercise—it’s a public, cultural signal**. Especially for tech leads and senior engineers, the way feedback is delivered in code review has real consequences for team morale, inclusion, and career development.

### Key Takeaways:

- **We treat code review as a public cultural forum**: Comments are visible to others on the team and can impact how engineers—especially juniors or new hires—are perceived. Feedback that embarrasses someone publicly can harm confidence and even affect performance reviews.
- **We avoid harsh criticism in public threads**: If we’re truly concerned about someone’s patterns (e.g., lack of testing mindset or carelessness), we give that feedback in private, not in a code review. We follow the rule: *Praise in public, critique in private.*
- **We understand the leadership signal we send**: As tech leads, our tone sets the bar. If we leave demoralizing or curt comments, we implicitly encourage others to do the same—fostering a negative or toxic culture.
- **We handle serious feedback face-to-face**: When needed, we schedule a quick 15-minute conversation to deliver constructive criticism with nuance and care—ensuring it’s received in the spirit of growth, not shame.
- **We use code reviews to build people up, not tear them down**: Every interaction is a chance to create a safer, stronger engineering culture. We remember that what we say—and how we say it—has lasting impact.

Ultimately, we believe that **code review is leadership in action**—and great leaders use it to uplift their teams, not diminish them.

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.

The “Do No Harm” Principle In Coding

In this segment, we discuss the principle of **"Do No Harm"**—a foundational mindset for writing safe, reliable code. While it's great to break large features into smaller diffs, it's essential that each individual diff **stands alone** as non-destructive and does not degrade the product or infrastructure if applied independently.

### Key Takeaways:

- **We ensure every diff is safe in isolation**: Even in stacked diffs, each change must not break functionality or expose incomplete features. Every diff should be self-contained and ideally improve (or at least preserve) the integrity of the codebase.
- **We avoid relying on future diffs to patch behavior**: It's risky to land an unstable or unfinished diff assuming a follow-up will fix it. If that follow-up is delayed or rolled back (e.g., due to a production issue), the earlier diff could introduce bugs or break the app.
- **We use feature gates wisely and early**: When launching features behind flags, we gate the feature at the very beginning—not in later diffs—to avoid exposing half-baked functionality in production.
- **We’re cautious with shared infrastructure**: If a diff touches a shared module or critical system, we proactively reach out to other teams to confirm our changes won’t unintentionally break their workflows or apps.
- **We understand our code lives in a larger system**: Like parts of a giant elephant, changes in one place can affect parts we can’t see. Practicing empathy and caution helps us prevent cascading issues in complex, multi-team environments.

The “Do No Harm” principle reminds us that good engineering isn’t just about adding features—it’s about protecting trust, stability, and the broader system our code lives in.

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.

One Diff, One Thesis - What Every Code Review Should Be Like

In this segment, we focus on the powerful practice of **“One Diff, One Thesis”**, along with a recap of three foundational principles for writing high-quality diffs. These habits dramatically improve your velocity, code quality, and perceived maturity as an engineer—especially early in your career.

### Key Takeaways:

- **We follow the “One Diff, One Thesis” principle**: Each code change should focus on a single, clearly defined purpose. Large, unfocused diffs (e.g., 5,000+ lines) dilute review quality and lead to blind approvals or unclear feedback.
- **We break big features into smaller, stackable diffs**: By submitting changes in 50–250 line chunks with logical dependencies, we keep discussions focused, reduce cognitive load for reviewers, and maintain a clear project history.
- **We pay the “20-minute tax” for high-quality diffs**: Investing time in writing strong context, test plans, and clear, focused diffs pays off by dramatically speeding up approvals and reducing iteration cycles.
- **We see these habits as promotion-worthy**: The most common reason junior engineers struggle during performance reviews is neglecting these basics. Conversely, those who consistently apply them stand out and accelerate their growth.
- **We optimize for long-term velocity and trust**: Thoughtful, well-structured diffs help reviewers engage more quickly and confidently, enabling faster delivery and demonstrating leadership-level attention to detail.

These three practices—**providing strong context, writing solid test plans, and submitting focused diffs**—are low-effort, high-return habits that every engineer, especially early in their career, should master.

This Is What A Good Code Review Test Plan Looks Like

In this segment, we highlight a real-world example of an **exceptional test plan** that showcases how thoughtful demos not only validate functionality but also build confidence and trust before a single line of code is reviewed.

### Key Takeaways:

- **We use test plans to demonstrate functionality and edge cases**: In this example from the Random Name Picker app, the test plan includes both the core feature (removing images from names) and handling an edge case (screen rotation), showing completeness and attention to detail.
- **We treat test plans as trust tokens**: A strong demo assures reviewers that the author has thoroughly tested their changes, reducing fear or hesitation around approving the diff.
- **We provide a positive starting point for reviewers**: Watching the video demo first puts reviewers in the right mindset—making them feel confident that the code works as intended, even before reading the diff.
- **We recommend test plans for all product-facing diffs**: Especially when there’s a visual or user-facing component, attaching a video or GIF dramatically improves understanding and quality of collaboration.
- **We invest a few minutes to add a lot of value**: Creating a short demo takes just 5–10 minutes, but it adds context, transparency, and professionalism that elevate the entire code review experience.

Learning A New Codebase? Here's How To Figure Out What Matters

In this video, we explore how a strong **test plan** benefits not just the immediate code review process but also long-term codebase understanding and team efficiency. As engineers join new teams or revisit legacy code, test plans become invaluable guides for understanding and validating past changes.

### Key Takeaways:

- **We use test plans to unlock team knowledge**: In large codebases, no one fully understands every part of the system. A clear test plan helps future engineers (and our future selves) grasp what a change does and why it was made.

- **We prioritize hotspots over ancient code**: When onboarding to a team, we focus on recent changes in active areas of the codebase—not the 1,000 untouched lines at the top. Test plans tied to recent diffs help us make sense of these hotspots quickly.

- **We support testability with repeatable artifacts**: Whether it’s a video, screenshot, or command-line script, we include a way to replicate and verify our changes. This ensures others can validate functionality easily and efficiently.

- **We aim for speed and clarity**: For front-end work, visual demos (videos or GIFs) help reviewers instantly see the impact. For backend or logic-heavy changes, unit tests and integration scripts are more scalable and maintainable.

- **We build infrastructure for long-term velocity**: Investing early in test infrastructure—like command-line test runners—makes it easier to validate changes quickly and helps teams move faster as the codebase grows.

Ultimately, we think of test plans not just as review aids, but as **living documentation** and a **key onboarding tool** for future engineers working in our code.

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.