How To Actually Learn Software Engineer Skills

A very common trap among software engineers is that they end up merely acquiring knowledge instead of actually learning software engineer skills. This is especially true when you're onboarding into a new team or company.

Here are the core points from the video:
- **Learn how to fish** - If you are growing as a software engineer, you want to make sure that you're actually learning the systems underneath instead of just acquiring surface-level solutions to your problems. "Receiving fish" is knowing that solution X solves your problem Y. "Learning how to fish" is understanding how solution X was crafted.
- **Get maximum value per answer** - Learning is largely absorbing support from other software engineers. When this happens, make sure to deeply understand how they arrived at their support. This can be when they give you an answer to your question or leave a comment on your pull request. *Ask follow-up questions to "download" their thought process.* It's much better to take full advantage of each interaction all in one go, so you don't need to ask them other simple questions in the future.
- **Example:** A teammate helps you debug. You can ask them the following:
  - How did you identify the breaking code?
  - Why did you choose this approach for the fix vs. others?
  - If you couldn't understand the code immediately, how did you figure out who to ask to get this understanding?

This clip is from our masterclass on how to succeed at a new team or company as a software engineer. [Click here to watch the full thing.](https://link.jointaro.com/9sJzfDeH3JdWzZRg9)

Related resources:
- [This Is How Software Engineers Should Initially Learn](https://link.jointaro.com/hoL4o29S3YsGsR9i7)
- [Building Software For Optimal Learning Example - Login Flow](https://link.jointaro.com/BjyeKesdaZt7SrwJ8)

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!

Senior Staff Engineer (L7) Describes Most Important Skill - Rahul Malik

Rahul is a Senior Staff Engineer at Meta.

- **Most important skill**: dealing with ambiguity and working through others. Senior Staff Engineers operate in a broad space, so they have to be independent enough to make impact without a specific problem.
- **Advice**: figure out how decisions are made. Who makes the decisions, and what is the underlying value system?

Here's the full playlist asking engineers what the most important skill is for their level: [Asking 7 Levels Of Engineers The Most Important Skill](https://www.jointaro.com/playlist/J9Io5lDGaYUpI8vGrUyI/)

Helpful links:
- [SWE2 --> Principal Eng in 4 years](https://www.jointaro.com/lesson/Lvf1TDKt1R4ZJSCr9BVv/rockstar-software-engineer-story-sw2-greater-principal-in-just-4-years/)
- Taro's top 10 to get promoted from [senior to staff engineer](https://www.jointaro.com/playlist/YD8LMCSlE71VUGUbNAWM/)
- [David Pan on what makes a great tech lead](https://www.jointaro.com/lesson/uHqZZ15SK19MatEvLSO6/what-makes-a-truly-great-tech-lead-a-vp-of-engineerings-perspective/)
- [Rahul on LinkedIn](https://www.linkedin.com/in/rahulbmalik/)

Meta Case Study - Debugging A Massive Production Issue

Here we go through an example bug at Meta. Given the information, we need to figure out what kind of root cause is behind the issue. This case study shows:
- Why it's important to understand the blast radius of a bug
- How knowing the context behind a bug can help you locate the problem area
- The value of having robust analytics

This video is a clip from our debugging masterclass. You can watch it here: [[Masterclass] How To Become A Debugging Master And Fix Issues Faster](https://www.jointaro.com/lesson/ioR6WzamAIUTpySLAr7o/masterclass-how-to-become-a-debugging-master-and-fix-issues-faster/)

Related resources:
- [[Case Study] Solving A Multi-Million $$ Instagram Bug](https://www.jointaro.com/lesson/WYk4J05iBqOuPtD0CYKX/case-study-solving-a-multi-million-dollardollar-instagram-bug/)
- ["How can I become more independent and better at unblocking myself with tricky technical issues?"](https://www.jointaro.com/question/QhqQQGrDgFjZbqohpKe0/how-can-i-become-more-independent-and-better-at-unblocking-myself-with-tricky-technical-issues/)
- ["What is the effective way to understand new repository in order to make the required changes in that repo?"](https://www.jointaro.com/question/KoxB3UU2zWC9pdYU6Rx0/what-is-the-effective-way-to-understand-new-repository-in-order-to-make-the-required-changes-in-that-repo/)

Onboarding Tips For Senior+ Engineers

As a Senior Engineer (or Staff or Principal) coming into a new company, there will be some expectation that you are bringing in domain knowledge. Your opinion can be valuable. A few ways to have immediate impact:

- Contrast how your current company operates compared to past companies
- Ask questions about why certain processes exist or don't exist

As you ramp up, remember to "**respect what came before.**" You don't want to disparage existing systems without realizing that it was best designed at the time of construction with the constraints and knowledge *at the time*.

As a senior engineer, you also need to lay the foundation for team and org-level impact. This means you invest extra time in building relationships and meeting other senior/staff/principal engineers.

Senior Engineer video from krazam: <https://www.youtube.com/watch?v=eSqexFg74F8>

Get Maximum Value Per Answer

You should "Learn how to fish" instead of "receiving fish" — your goal in onboarding is to become a self-sufficient, productive engineer as quickly as possible. 

The way you do that is to ask follow-up questions when you get help and understand how you would have arrived at the solution on your own.

Bias toward asking for help earlier when you're new to a company, since you don't know what you don't know. It's better to be more annoying for the first month on the job rather than somewhat annoying for 6 months.

Maximizing a Severance Package 3/9 - Termination Circumstances

Let's talk about the different circumstances where you may need a package or to try and get a severance from a company.

- 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 4] - Debugging

No matter how careful you are as a software engineer, your code will always have bugs. On top of that, you will also need to spend time fixing bugs in code written by other people. This lesson teaches you:

- Why debugging is always a valuable skill (while feature development often isn't)
- How debugging forces you to develop a deeper understanding of the system
- The framework and process you need to understand in order to fix any bug

Level Up Your Code Quality As A Software Engineer [Part 19] - Code Review Feedback

If you want to grow lightning fast as a software engineer, you need code quality feedback. This is the primary goal the entire "Pull Requests" section of this course is building up towards. This lesson will teach you:

- The algorithm for leveling up incredibly quickly as an engineer, especially for junior and mid-level engineers
- How NOT to respond to code review feedback
- How to gracefully respond to code review feedback to maximize your learning and deepen relationships with your teammates by going through an in-depth example

If you want to dive even deeper into code review, check out our masterclass: [\[Masterclass\] How To Do Amazing Code Review](https://www.jointaro.com/lesson/rhRFh49oouaUDhWUvkQb/masterclass-how-to-do-amazing-code-review/)

The Key To Avoiding The Performance Improvement Plan (PIP)

Getting hit with a performance improvement plan (otherwise known as a "PIP") is one of the worst things that can happen to you as a software engineer. This makes avoiding a performance improvement plan one of the most important things for you to do, especially in the currently layoff-rich economy.

Here's the core points from the video.

- Your performance review rating should never be a surprise: Regularly check in with your manager to figure out how you're trending to avoid the dreaded PIP.
- On top of asking for constructive feedback regularly, you shouldn't be afraid to ask every 2-3 months if you're on track to get the rating you want once the formal performance review happens. The clearest way this manifests is a hypothetical rating: *"Would you give me at least a \[Meets Expectations\] for my performance so far?"* This is the most powerful way you can stay in sync with your manager.
- Make it clear with your manager that you'll take any hypothetical rating with a grain of salt, so they're more comfortable giving it to you. If you're brave enough, you can even ask them to err towards the lower-end so you don't overset expectations.
- Keep your eye on the ball: Keep referencing the expectations plan you made at the beginning of the cycle and evolving it as necessary.
- Turn it up at the later end of the cycle. Humans have bad memory: It's unfair, but recency bias is huge. Try to land your bigger wins just a few weeks or months before the formal performance review process starts.

Related resources:

- ["What's the difference between a low performer software engineer and a high performer?"](https://link.jointaro.com/QHkWNXoJV5Y9VYvH9)
- ["How do I help my manager (who is also my mentor) be a better manager and mentor?"](https://link.jointaro.com/eG5c6usaJNY9wopP8)

The #1 Principle To Remember When Authoring A Code Review

In this video, we discuss the most important mindset shift for code authors: **writing code with empathy for reviewers**. Code review is a collaborative act, and how we prepare and present our diffs directly impacts team productivity, trust, and code quality.

### Key Takeaways:

- **We write diffs with empathy**: The most valuable thing we can do as authors is consider how to make the review experience smoother for others. Clear, concise diffs help teammates help us faster and more effectively.
- **We respect reviewers’ time**: Reviewers choose to help us—they’re not obligated. Reviewing interrupts their own deep work and requires mental context-switching, so we express appreciation by submitting clean, readable diffs.
- **We build trust and social capital through quality**: Writing thoughtful diffs with summaries and test plans helps us gain faster approvals and earns the trust of teammates and tech leads.
- **We know we’ll be reviewers too**: As we grow in our careers, we’ll spend more time reviewing others’ code. We want our teammates to be just as thoughtful when submitting their diffs to us.
- **We lead by example**: High-quality, empathetic diffs set the cultural tone for our team. We improve the entire engineering environment by holding ourselves to the same standards we hope to receive.

Maximize Your Productivity As A Software Engineer [Part 7] - Get Good Sleep

Sleep is one of the first things to go when software engineers are faced with daunting workloads. Unfortunately, this is a tradeoff with disastrous consequences which doesn't even solve the problem. This lesson teaches you:

- Why most software engineers get sleep completely wrong in every possible way
- The correct perspective to have with sleep
- The many benefits of getting 8+ hours of consistent sleep every day
- How sacrificing sleep actually makes you less productive, not more

Grow From Junior To Mid-Level Engineer [Part 4] - Structuring Your Growth

Even though junior engineer to mid-level engineer is the 1st and easiest promotion, it's still a meaningful evolution with many parts. This lesson teaches you:

- The 3 core areas of improvement to grow from junior -&gt; mid-level
- The most important area to improve to make the junior -&gt; mid-level promotion
- How you should process the advice from this course

Ace Your Tech Interview As A Software Engineer [Part 10] - Order Matters

We all want to speed run our way into FAANG. The bad news is that this is almost never pans out for software engineers, and aggressively pursuing this strategy can easily lead to your downfall. This lesson teaches you:

- The true way to actually get better at interviewing and why it can't be avoided (no matter how painful it is)
- How to properly structure your job search when Big Tech is one of your goals
- The general approach you should take when it comes to applying to jobs and sequencing your interviews

How To Be An Effective Tech Lead [Part 3] - What Makes A Good Tech Lead

Good tech leads provide immense value to their teams through a large collection of ways. This lesson teaches you:

- What it means from a technical skills perspective to be a good tech lead
- How good tech leads exercise effective leadership
- The mindset tech leads must champion

Why YOU Suck At Coding Interviews - From a Senior Engineer at Uber

[Edbert Chan](https://www.linkedin.com/in/edbert-chan-18a96950/) is a senior Android engineer at Uber. He wrote the popular guide “Welcome To The Coding Interview - You Suck” freely [available here](https://docs.google.com/document/u/1/d/1eKirumpmwDWTtKCJKn2HuoQ2NavEfR41whmTyaQcio4/mobilebasic) (and [here are the slides](https://docs.google.com/presentation/d/1vce04LepxDbu7K1ZyhtjVaSXC6Z0YYS9cAjNNztbEr4/edit#slide=id.p) presented).

If you want advice from Edbert, check out his AMA here: ["I'm Edbert, Ex-Apple current Uber Infra Android Engineer. AMA!"](https://www.jointaro.com/question/ftzODE689WYHw0FHGcl1/im-edbert-ex-apple-current-uber-infra-android-engineer-ama/)

This is a presentation about the common mistakes he has observed, and what you should do instead. Edbert believes that software engineers focus too much on the code and information during interview prep, and not enough on the engineering part of software **engineering**. Engineering is more than just coding, and a good interview process will be able to judge that.

The extensive guide is filled with practical tips for job seekers to pass the modern interview process at tech companies. Edbert covers the 9 mistakes that hold people back from passing technical interviews:

- Mistake 1: Not Putting Enough Time
- Mistake 2: Interview Approach Is Inconsistent
- Mistake 3: Your Interview Practicing Is Inconsistent
- Mistake 4: Not Fixing Your Own Mistakes
- Mistake 5: Not seeing how one decision or mistake leads to another
- Mistake 6: Not Understanding Your Own Solution Before Coding
- Mistake 7: Magic Bullets
- Mistake 8: Not Being Fast Enough
- Mistake 9: Being Full of Shit

Additional resources:

- [Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)
- [\[Taro Top 10\] Effective Interview Prep](https://www.jointaro.com/playlist/HLBYxJI7D1j8STolrwum/)
- [\[Masterclass\] How To Ace Your Big Tech Interview - Data Structures And Algorithms](https://www.jointaro.com/lesson/V4sTACzfOh22nMVcUV3w/masterclass-how-to-ace-your-big-tech-interview-data-structures-and-algorithms/)
- [\[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/)

English Communication Is The Most Important Skill For Immigrant Engineers

The field of engineering is filled with immigrants. Silicon Valley is famously built from the creativity and hard work of immigrants around the world (China, India, Israel, and much more).

If English is your 2nd (or 3rd) language, only or mostly speaking your native language at work will hold back your career. Rachel talks about her misconception that communication skills weren't that important, and how to improve your speaking + writing.

If you want to get better at communication, check out our course: [\[Course\] Clear Communication For Software Engineers](https://www.jointaro.com/course/clear-communication-for-software-engineers/)

This thread is helpful too: ["How to improve my communication?"](https://www.jointaro.com/question/omak9oOT4NJE9dhKeMZi/how-to-improve-my-communication/)

Intro To Input Metrics

In this lesson, we explore what input metrics are, why they matter, and how shifting our focus from outputs to controllable inputs transformed the way we operated at Amazon. We learned—sometimes the hard way—that sustainable success comes not from chasing end results, but from rigorously managing the elements we directly control.

### Key Takeaways:

- **We learned to distinguish between input and output metrics**: Outputs like revenue or share price are lagging indicators and largely outside our direct control. In contrast, input metrics—customer-facing and operational—are controllable levers that drive those outputs.
- **We saw the importance of focusing on controllable inputs**: By investing resources in areas like software, marketing, operations, or process improvements, we influenced outcomes in a predictable and sustainable way. Examples include inventory record accuracy and marketing spend.
- **We realized the limitations of reactive output chasing**: Trying to salvage quarterly financials with last-minute promotions often distracted us from what truly mattered—improving the customer experience.
- **We began managing our business as a system of processes**: We stopped reacting to fire drills and started proactively measuring and optimizing the activities (inputs) that lead to better long-term results.
- **We gained a competitive edge through disciplined input tracking**: While most teams naturally measure outputs, few rigorously track inputs. By doing so, we developed a significant operational advantage that helped Amazon scale sustainably.

To dive deeper into Input Metrics Mastery and learn more from Bill and Colin, follow these links:

- Take the full course at their website: <https://workingbackwards.com/>
- Buy the book: <https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595>
- Bill's LinkedIn: <https://www.linkedin.com/in/bill-carr/>
- Colin's LinkedIn: <https://www.linkedin.com/in/colinbryar/>

Here's Why You're Doing Interview Prep WRONG

Most people do very shallow interview prep that doesn't actually help them learn. Lists like Blind 75 and Leetcode 75 are not enough to truly master the technical interview for Big Tech companies. 

In this video, Daniel proposes the "proper" way to master the coding / DSA interview so that you can walk into interviews and feel more confident. There are no shortcuts and no memorization -- instead, it's about going beyond the solution for a problem, and then understanding the nuances and process to get the right answer.

- Connect with Daniel on [LinkedIn](https://www.linkedin.com/in/danieltomko/)
- Checkout Formation as part of [Taro Perks](https://www.jointaro.com/perks/)

Relevant Taro content: 
- [Effectively Learning Data Structures And Algorithms (DSA)](https://www.jointaro.com/lesson/XwpMMY3ss97zOrXJQ7Xr/effectively-learning-data-structures-and-algorithms-dsa/)
- [Struggling With DSA? Don't Worry, That's Healthy!](https://www.jointaro.com/lesson/SPWYdMAu5XQX8ds9MxXc/struggling-with-dsa-dont-worry-thats-healthy/)
- [Masterclass on DSA interviews](https://www.jointaro.com/lesson/V4sTACzfOh22nMVcUV3w/how-to-ace-your-big-tech-interview-data-structures-and-algorithms-7172021/)

System Design Series: Taro Playlists [Part 5] - Data Model

You can [find the full system design doc here](https://docs.google.com/document/d/15WaM8Ojan82g0m2mtz6kC2Hiyj0Q6VbjfqRmVNDI3qw/edit?usp=sharing) - Feel free to use it as a template for when you're designing systems at your job!

The concrete details are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:

- Always define the data model if applicable. It is the "core operating unit" of your system - Everything revolves around it. That's pretty much what CRUD is: You have some data model and the entire ecosystem revolves around manipulating it properly.
- Define the table/collection(s):
  - What is its name?
  - What does it represent? If you can include a visual aide on how it's actually rendered for the user, that makes things a lot clearer.
- Define the fields on your model:
  - What is its name/key?
  - What is its type?
  - Is it required?
  - What does it represent? This should include information on what kind of key it is (e.g. primary key) if applicable.
- Illustrate the model to make it really clear. JSON is really good at doing this as it's very readable. There are many free incredible JSON formatters online (Alex used them all the time to make project specs).

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.