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

Get The Rating You Deserve [Part 1] - Course Outline

**In this course, we'll explore strategies, principles, and tactics to effectively convert the value you create into the rewards you deserve.**

- **Unleash Your Potential:** We'll address common pitfalls and biases that hinder career advancement, empowering you to overcome obstacles and achieve your goals.
- **Mindset Matters:** By shifting your mindset and adopting a positive, empowered perspective, you can accelerate your progress and achieve significant results.
- **Proven Strategies:** We'll delve into specific strategies and tactics that have been proven to be effective in maximizing your career potential.
- **Real-World Insights:** Through real-world examples and case studies, we'll illustrate how these principles can be applied to your specific career situation.

If you want to get personalized support from Yogi, you can reach out to him at [coaching@yogisharma.com](mailto:coaching@yogisharma.com) or schedule an introductory call to dive into your situation at <https://tinyurl.com/meetyogi>.

20 Years Of Fighting Procrastination [Part 3] - Build A System

Most people rely on fluctuating willpower to be productive—but the most effective creators use systems. Here are the core points from the lesson:

- Systems make good behavior automatic by reducing cognitive load and accounting for natural fluctuations in willpower, energy, and focus
- Structure your day around your strengths—use mornings for disciplined deep work, afternoons for accountability-based tasks, and evenings for creative exploration
- Focus on generating artifacts like notes, calendar blocks, or test plans to capture progress, clarify your thinking, and preserve valuable context
- Habit stacking and predefined triggers make consistent output easier and help you avoid relying on short-term motivation or memory

A Powerful Tool For Software Engineer Productivity - Focus Blocks

So many junior software engineers don't manage their calendar well, and this especially hurts their ability to write code and finish tickets efficiently. Don't blindly go into every meeting, especially as a junior software engineer who is often not relevant to the meeting. Be deliberate with your calendar and establish focus blocks.

Here are the core points from the video:

- **So what is a focus block?** - It's a long, uninterrupted period of time for you to focus on a singular track of work. A true focus block should be 4+ hours, ideally an entire work day.
- **Why are focus blocks important for coding?** - Humans are naturally bad at context switching, so focus blocks are just important for productivity in general. Having a focus block allows you to enter a "flow state" where you rate of work ramps up over time and you get more and more into the groove. When it comes to coding in particular, the focus time is crucial as context switching with code is especially painful. It takes a while to deep back into a codebase when you return to a coding task, and there's also practical reasons like rebasing your local and setting up your build environment again.
- **How can I set up a focus block?** - The main "culprit" behind hurting your focus blocks is meetings. Be aggressive about shaving meetings off your calendar where you aren't a core player, especially if you're earlier-in-career. Group the remaining meetings you have onto certain days with the goal of freeing up 1-2 days entirely for coding. 1 on 1 meetings will be the easiest to move. For the meetings you do end up going to, [follow this advice to really participate and get maximum value out of them](https://www.jointaro.com/question/3E3SBCa59z5oDb7AEciw/i-struggle-to-come-up-with-things-that-add-value-to-a-meeting-what-do-i-say/).

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/)
- ["How do I optimize my sacred hour at work?"](https://www.jointaro.com/question/l8dzUVTu99CahofQsYAi/how-do-i-optimize-my-sacred-hour-at-work/)

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)

How To Properly Learn To Code As A Software Engineer - Do The Simple Thing First

Software engineers are obsessed with using the most modern framework in pursuit of the best code. Ironically, this dogma leads to them writing terrible code.

Here's the core points:

- **Do the simple thing first** - When picking up a stack, use the most basic framework. If possible, don't use a framework at all. By starting with the primitive setup, you will understand its limitations. This means that when you move up to modern frameworks and libraries, you will truly understand the problems they are trying to solve, allowing them to use them properly.
- **You can't "cheat" advanced code understanding** - You can't jump straight to the cutting-edge tech. These abstractions are powerful for a reason: They are naturally complex and require a deep understanding of the overall stack to use. When you try to "skip to the end", you will write bad code. The most terrible code comes from more junior software engineers trying to be smart prematurely with "modern architecture".

Related resources:

- [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)
- [\[Course\] System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

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)

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

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

20 Years Of Fighting Procrastination [Part 2] - The Right Mentality For Productivity

Many engineers think their lack of productivity is a motivation issue, so they start off by focusing on that. However, this is usually not the right way to go. Here are the core points from the lesson:

- Action creates motivation, not the other way around—starting small builds momentum
- Progress triggers a positive spiral: productivity → feeling good → more productivity
- You only need discipline for the first 5 minutes—after that, the task usually becomes easier

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

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

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

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

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

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

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

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

Top System Design Interview Mistakes [Part 5] - Don't Over or Under-Engineer a System

In system design interviews, it's crucial to strike the right balance between complexity and simplicity in your solutions. This video highlights the importance of avoiding both over-engineering and under-engineering:

- Designing systems with unnecessary complexity can lead to wasted resources, higher risks of bugs, and an impractical solution
- While caching can improve performance, indiscriminately adding caches without careful consideration can introduce inconsistencies and unnecessary complexity
- Rather than adding complexity for its own sake, stay focused on the unique challenges of the problem at hand to identify the most effective solutions
- Thoughtfully evaluate where to apply caching or other optimizations by weighing the benefits against the potential downsides
- Ensure that your design decisions are driven by the specific needs of the problem, rather than trying to impress the interviewer with buzzwords or unnecessary tools

This approach helps create efficient and practical solutions tailored to the specific challenges of the interview prompt.

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>

Why Most Companies Suck At Onboarding

You should not expect a good onboarding process at your company. Helping new employees ramp up is a good example of something that is *important but not urgent*. Tenured employees likely don't remember what it's like to be new.

While many companies will have insufficient or non-existent onboarding, the other end of the spectrum is also unfortunate: larger bureaucratic companies will have excessive onboarding, with months of training before you can do anything productive.

Even if the company has good intentions, building a solid onboarding plan is a hard problem: the tech industry's rate of change is very high, with people, tools, and technologies changing every year. Naturally, documentation and processes around onboarding become outdated.

Despite the difficulties, poor onboarding can be seen as an opportunity for new employees to have an immediate impact.

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.