The Defining Trait Of Mediocre Software Engineers With Debugging

One of the main differences between a low-performing software engineer and a high-performing software engineer is that the high-performer looks for true solutions to bugs instead of hacky ones like the low-performer does. Don't suppress the symptoms when fixing bugs - Treat the root cause as well.

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 would you do, if you get a better solution purpose after PR?"](https://www.jointaro.com/question/PqxeNMxwHKsWYyWVyEbZ/what-would-you-do-if-you-get-a-better-solution-purpose-after-pr/)

360 Feedback: The BEST Performance Review System Top Companies Use

- The goal of 360 feedback is to generate as holistic and fair a picture of employee performance as possible.
- It does this by getting feedback from all directions:
  - Within (yourself)
  - Above (your manager)
  - Below (your reports if you are a manager)
  - Laterally (your teammates)
- This system prevents employee performance from reducing down to sucking up to the manager, which is the case in more traditional companies that aren't using this system.
- 360 feedback also makes the power dynamic between manager and report more equal. A manager will have a bad feedback packet if their reports all share bad feedback about them. This holds bad managers accountable.

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>

Ask Questions Well

What makes a high-quality question?

- You get the help you need
- You build trust with the person/group that you're asking the question to

Question asking is a deep skill that requires you to add sufficient context (but not too much) so people can easily help you.

- Prefer to ask in public forums
- Realize that your question may help others beyond you
- Your questions are a valuable signal to the team 

When you are asking a question, please don't just say hello and wait for them to respond: <https://nohello.net/en/>

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

[Masterclass] How To Work Better With Your Engineering Manager

Your engineering manager (EM) is easily the most important figure in your professional life, and how you manage your engineer &lt;-&gt; EM relationships across your various teams and companies will largely dictate how much career growth you have. The tricky part is that all of this is very hard, and if you don't do it properly, you can end up working against your manager instead of with them.

As always, the masterclass covers a *ton* of ground, so here's the Top 5 points:

- **Engineering management is a very hard job** - EMs are completely slammed with meetings and are constantly making hard decisions (e.g. *"Who do I hire and fire?"*). The first step towards fostering a healthy relationship here is having empathy for the natural difficulty behind their role.
- **It's up to YOU to leverage your manager** - Don't expect your manager to solo-carry you by proactively identifying all your issues and handing you the perfect growth plan on a silver platter. Nobody can read minds, and nobody cares about your personal growth more than you. Treat your manager as a resource, similar to how a front-end application treats an API. The API will never come to you - It's up to you to call it with the proper parameters to achieve the result you want.
- **Be extremely visible** - Be default, assume that your EM has 0 clue what you're doing, not out of malice but because they're swamped most of the time. cc your manager on important communications to keep them up-to-date with your biggest accomplishments and blockers. Add them as optional on meetings. Use your 1 on 1 to share crucial wins and status updates.
- **Maintain an ongoing dialog about performance** - Your performance review rating should never be a (negative) surprise. Ask every couple months for your manager to give you a hypothetical rating (make it clear that you will take it with a massive grain of salt). Don't let your fear of these awkward, transparent conversations lead to you getting put on an unexpected PIP.
- **Frame promotion as a mutual benefit** - It is not the manager's job to grow their engineers and get them all promoted; this is actually literally impossible in the current economy. It's the manager's job to make sure that their engineers are consistently shipping impact. This means that you must be extremely careful framing your promotion in a way where it's clear that your goal is to expand your impact and further empower the team, not to get more money and a higher title (it's totally fine to want these, they just have to be very far away from front and center).

Related resources:

- [Having The Proper Mentality For Manager 1 on 1s](https://www.jointaro.com/lesson/sIm7s54ILdBQmpCtKFtb/having-the-proper-mentality-for-manager-1-on-1s/)
- [1 on 1s Are The Time To Be Awkward](https://www.jointaro.com/lesson/xjeFRpp5YHxG9TTK8wjn/1-on-1s-are-the-time-to-be-awkward/)
- ["How do I create a growth plan with my manager/mentor and what should it include?"](https://www.jointaro.com/question/BG4rWlnWQamBFI9ujCni/how-do-i-create-a-growth-plan-with-my-managermentor-and-what-should-it-include/)
- ["How do I give critical feedback to my manager?"](https://www.jointaro.com/question/VeGFF3JbpstS3Av5jpHB/how-do-i-give-critical-feedback-to-my-manager/)
- [\[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/)
- [Presentation Slides](https://docs.google.com/presentation/d/1zS7GJQmpZRS-fo-ZiiV5cHjdat9gHStPFVnA0awlFM0/edit?usp=sharing)

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.

[Masterclass] How To Stop Writing Messy Code As A Software Engineer

It's 10x easier to write messy code instead of good, clean code. The hard part is that unless you have good role models, it's extremely difficult to learn how to write quality code. If you're a software engineer going through this struggle, this masterclass is for you.

Here are the core points from the video:
- **There's no such thing as objectively "clean" code** - A lot of engineers treat code quality as something to "solve" where after they learn the best tech stack/database/framework, they can just plug that in everywhere and win. That's simply not how software works. The reason why writing truly great code is hard is because it's all about the context and nuance. Code that's good in one codebase can be horrible in another.
- **It's all about the user experience (UX)** - At the end of the day, the end-user doesn't care about your code quality. Most end-users have never read a single line of code in their life. The end-user simply wants a good UX, which means that if you need to write code that's a little messy to uphold good UX, you should do that.
- **Feel the pain of your bad code** - True learning comes from struggle, and if you really want to stop writing messy code, you need to see your own code break and struggle. Go outside of the happy flow and dogfood your own products and features aggressively. Read your old code every once in a while and see how horrible it was - If you groan then, that's a good sign of growth.
- **Break down your tasks** - A marquee trait of bad software engineers is that they jump straight into the coding, write a gigantic messy commit, and get demolished in code review. To prevent that, proactively decompose your tasks into smaller ones where each one is ideally 1-3 commits or a few days of work. This lets you come up with an actual plan for the task and invite your teammates' feedback at an earlier stage in development (i.e. before you write much or any code). For an in-depth guide on software decomposition, check out the discussion here: ["How do I make software less overwhelming?"](https://www.jointaro.com/question/YseMPDw538jhyS1MWlTs/how-do-i-make-software-less-overwhelming/)
- **Write clean pull requests (PRs)** - It doesn't matter if the code in your PR is bad as long as it's "dressed" well and optimized for your teammates to leave good feedback (which will make your code good!). Write atomic commits, have a real PR title, attach a thorough context section + test plan, and proactively call out tricky areas. Learn how to do all that with the following video and its related resources: [One Diff, One Thesis - What Every Code Review Should Be Like](https://www.jointaro.com/lesson/3NAbmgiaY3IpvayNIoVl/one-diff-one-thesis-what-every-code-review-should-be-like/)

Related resources:
- ["How to Learn/Practice Clean Code, particularly by oneself?"](https://www.jointaro.com/question/6DcTkiS9UJhDkQz1HIAL/how-to-learnpractice-clean-code-particularly-by-oneself/)
- ["How to upskill effectively, especially with the software design aspect?"](https://www.jointaro.com/question/JALOyWIOCo7UXIMLlUz3/how-to-upskill-effectively-especially-with-the-software-design-aspect/)
- [[Masterclass] How To Write Better Code Faster As A Software Engineer](https://www.jointaro.com/lesson/iYpRj8XfyzCSaTYnce3y/masterclass-how-to-write-better-code-faster-as-a-software-engineer/)
- [[Masterclass] How To Do Amazing Code Review](https://www.jointaro.com/lesson/rhRFh49oouaUDhWUvkQb/masterclass-how-to-do-amazing-code-review/)
- [Presentation slides](https://docs.google.com/presentation/d/106NsN9Z9QNvZR_-LMaiVu2rT8Kro_4YwXS44j-rNLXk/edit?usp=sharing)

Ace Your Tech Interview As A Software Engineer [Part 23] - Data Structures And Algorithms (DSA)

Data structures and algorithms (otherwise known as DSA) - We've all heard of them before. For many software engineers on the job hunt, it is the bane of their existence (and for good reason). This lesson teaches you:

- When to expect DSA problems during the interview loop
- How DSA problems came to take over the software engineer interview
- Why FAANG and Big Tech companies overall use DSA interviews so aggressively (hint: it's not because they're stupid)

To master the data structures and algorithms interview, check out these resources:

- [\[Course\] Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)
- [\[Taro Top 10\] Effective Interview Prep](https://www.jointaro.com/playlist/HLBYxJI7D1j8STolrwum/)

You Should Be Vulnerable With Your Manager

You are feeling burnt out at work. Should you share this with your manager?

You feel like you are slower than your other teammates and are afraid that you look bad amongst the team. Should you share this with your manager?

Your dog just died, and you are having a really tough time concentrating at work because of this. Should you share this with your manager?

Here are the core points from the lesson:

- Your manager is responsible for your performance at work. Therefore, it's in their best interest to help you resolve anything that is negatively affecting your work performance, even if it's something non-tactical.
- If you are having a deeper issue (e.g. you have imposter syndrome), this is something you should talk with your manager about. You shouldn't expect them to act as a full psychologist, but they should at least be receptive of your problem and lend an understanding ear.
- Venting and complaining are very natural and can act as a therapeutic exercise. Don't be afraid to do this with your manager once you have a good enough relationship.
- This gets easier over time. Once you start being honest and more transparent in your manager meetings, the trust between you two increases, making it smoother to continue being open in the future.

Related resources:

- [\[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/)
- [\[Course\] Networking Guide: Build Deep Relationships Quickly In Tech](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/)

Maximize Your Productivity As A Software Engineer [Part 11] - Not Every Meeting Needs You

Meetings are everywhere at tech companies, especially massive ones like FAANG. The unfortunate reality is that so many of these meetings are wasteful, especially for more junior engineers. This lesson teaches you:

- The huge mistake many n00b engineers make with meetings
- The most powerful tactic you can use to take control of your calendar
- How to figure out which meetings you can skip
- Tactics to safely delete meetings from your calendar

Distinguished Engineer (L9) Describes Most Important Skill - Andrew Zhai

Andrew became a Distinguished Engineer at Pinterest through his 9+ year tenure at the company. He was one of 4 Distinguished Engineers in the whole company (1200 engineers).

- **Most important skill**: a deep understanding of people, business, and tech. That understanding is required to build trust from your team and the entire company to lead large-scale initiatives.
- **Advice**: Aggressively pursue impact. Being a Distinguished Engineer means that the company trusts you to tackle some of the hardest and most existential problems. Defining what those problems and getting the right functions involved is critical.

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:

- [Senior Director shares his perspective on role evolution at the executive level](https://www.jointaro.com/lesson/Tr3bHl6mIVsmZZ6BAQLc/case-study-how-to-become-a-data-guru-as-an-engineer-w-senior-director-of-ds-mo-shahangian/)
- [How to write better code faster](https://www.jointaro.com/lesson/iYpRj8XfyzCSaTYnce3y/masterclass-how-to-write-better-code-faster-as-a-software-engineer/)
- [The story of SWE2 --&gt; 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/)
- [Andrew Zhai on Twitter (X)](https://x.com/ZhaiAndrew)

SWE Internship Survival Guide [Part 1] - How This Course Works

Are the projects on your resume not helping you at all when it comes to impressing hiring managers and getting job opportunities? Let's fix that. Here are the core parts of the lesson:

- Your instructor [**Rahul Pandey**](https://www.linkedin.com/in/rpandey1234/) walks you through his extensive 10+ year Silicon Valley background with rapid career advancement, ending up as a high-performing Staff Engineer \[E6\]/Engineering Manager \[M1\] at Meta. Most importantly, he goes through how he's mentored interns at top companies like Pinterest and Meta
- Rahul breaks down his extensive personal internship journey featuring 4 (!!!) internships, ranging from a small startup (Shop It To Me) to a mid-sized company (Marin Software) to a historical giant (Walmart) to FAANG (Meta)
- We walk you through the course objectives. By the end of the course, you will understand:
  - ⛰️ Understand how internships work at top companies
  - 🧠 Establish the right mindset to succeed
  - ⚙️ Clarify technical skill expectations
  - 🗣️ Know the critical, underappreciated soft skills interns need
  - 💪 Generate a list of concrete action items to prepare and improve

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)

Code Review Is NOT For Catching Bugs

In this follow-up video, we dive deeper into the **true purpose of code review**, challenging the misconception that its main goal is to catch bugs. Instead, we emphasize how code review plays a central role in shaping team culture, accountability, and knowledge sharing.

### Key Takeaways:

- **We see code review as a cultural engine**: It’s a key mechanism for how our team communicates, transfers norms, and builds a shared understanding of quality and standards.
- **We’ve learned that code reviews aren’t about bug-hunting**: Studies—including from Microsoft Research—show that code reviews are not effective at finding bugs, even with multiple reviewers or approval layers.
- **We hold ourselves accountable for our code**: The responsibility for quality and testing lies with the author—not the reviewer. Code review isn’t a safety net for catching functionality issues.
- **We avoid over-reviewing**: Adding more layers of review slows us down without meaningfully reducing bugs. Instead, we focus on meaningful reviews that support learning and alignment.
- **We use code reviews for knowledge and culture transfer**: Through thoughtful feedback and shared context, we reinforce how we build, think, and collaborate—making code review a vital part of team growth.

[Case Study] Building An App With 1,000,000+ Users To Get Into Facebook

If you want to hear an in-depth \~30 minute breakdown of Alex's entire journey getting the Facebook offer, watch our video here: [How Alex Got Into Meta With 0 Prior LeetCode Experience](https://www.jointaro.com/lesson/ZYiTbN21FsqFxFdpwt5a/how-alex-got-into-meta-with-0-prior-leetcode-experience/)

To learn more about how to build effective side projects, check out these resources:
- [[Masterclass] How To Come Up With 100k+ Users App Ideas You Can Build For Free](https://www.jointaro.com/lesson/AI4zi759PSGn6RwIFT6f/masterclass-how-to-come-up-with-100k-users-app-ideas-you-can-build-for-free/)
- [[Masterclass] How To Build And Grow Tech Products To 500k+ Users For Free](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/)
- ["How Long to Crank Out a Decent Side Project?"](https://www.jointaro.com/question/QA6lCGdPpwAd3xRrpjZ7/how-long-to-crank-out-a-decent-side-project/)
- [How Alex Made An App That Got 80k+ Users In 1 Month](https://www.jointaro.com/lesson/GlSjjLhuUdHt5drq3l5F/how-alex-made-an-app-that-got-80k-users-in-1-month/)
- [Presentation slides](https://docs.google.com/presentation/d/1MJU_LPnfc_QEu7386eSFvIbopG2VVUE3lTzkA458bYU/edit?usp=sharing)

If you want to dive deeper into the Random Name Picker app:
- [Download it on Google Play](https://play.google.com/store/apps/details?id=com.randomappsinc.studentpicker)
- [GitHub Source Code](https://github.com/Gear61/Random-Name-Picker)

[Part 1] Software Engineer Onboarding: Embrace Your Lack of Knowledge

Don't be afraid to NOT know something. Ask questions.

When you first join a team, there's a lot that you don't know, and that's ok!! No one expects you to know the codebase, the context, and the structure within your new role. Your goal is to gain context through your questions. 

- [Asking Questions Is NOT A Sign Of Weakness](https://www.jointaro.com/lesson/YIL3iK8fmSwhWP0PASqe/asking-questions-is-not-a-sign-of-weakness/)
- [Overcoming Imposter Syndrome - You Have Much More Value Than You Realize](https://www.jointaro.com/lesson/dTSdd4ozp298jH3glvnx/overcoming-imposter-syndrome-you-have-much-more-value-than-you-realize/)
- [How To Find A Good Team With Career Growth Opportunities](https://www.jointaro.com/lesson/UGIUC9zaGccK0tOarBri/how-to-find-a-good-team-with-career-growth-opportunities/)
- [Alex's Guide to Effective Communication](https://www.jointaro.com/playlist/hVdLQQzfslaYarLSCmmy/)

This is part 1 of a 4 part series from Daniel about how to **most efficiently** and **most effectively** onboard into a new team or company. What should you spend your time doing in the first few months of joining, and how should that change based on your level? 

This masterclass covers this topic from the perspective of Daniel Tomko, a 20 year Big Tech veteran. Daniel spent 11 years at Microsoft and 8 years at Meta in various senior IC and management positions. 

- [Go to part 2 of the masterclass here](https://www.jointaro.com/lesson/jr0iHuUCGW5lCdBndEpO/part-2-software-engineer-onboarding-learn-the-workflow/)
- Connect with Daniel Tomko on [LinkedIn](https://www.linkedin.com/in/danieltomko/)
- Check out the [Formation.dev discount](https://www.jointaro.com/perks/) for Taro Premium members

Maximize Your Productivity As A Software Engineer [Part 5] - Focus On The System

Many software engineers simply tell themselves *"I'll do better next time"* when they have an unproductive period - This almost never works. This lesson teaches you:

- Why relying on sheer willpower to be productive is a terrible idea and what you should do instead
- What it means to have a true system around your productivity
- The objectives of a productivity system

Working With Your Manager

Your manager is the most important person for your career progression. If they don't support you, you will not get promoted. This means you should allocate sufficient time and attention to this relationship when you first join.

Rahul's suggestion for the bare minimum interaction during the first few months at the company:

- Weekly (or biweekly) recurring 1:1 meeting
- 30+ minutes

Two tips to ensure you get sufficient value out of the manager relationship:

- Let them know you’re eager for feedback
- Add structure to the interaction by writing things down and following a template for each meeting

If your manager frequently cancels 1:1s with you, use the running 1:1 doc with an agenda as a defense mechanism. People will think twice about canceling something if they know it's important to you.

Signs Of A Healthy Manager 1 on 1 Meeting

- **Golden standard**: Weekly 30-45 minute meeting
  - Bi-weekly can be okay, but weekly is ideal. Anything less frequent than bi-weekly is a red flag.
  - This should be recurring and scheduled, not ad-hoc.
- The meeting should feel proactive instead of reactive.
  - Reactive 1 on 1s happen when the meeting has no agenda beforehand.
  - The discussion should be focused and talking about future themes for you and your career like growth and career goals.
- The meeting isn't purely tactical: This is a time for you and your manager to build trust and get to know one another.
- The time should feel "awkward". Some "awkward" areas include:
  - Honest feedback
  - Emotions 

Related resources:
- [1 on 1s Are The Time To Be Awkward](https://link.jointaro.com/kuS9keFuUwRJk9rSA)
- ["How do I help my manager (who is also my mentor) be a better manager and mentor?"](https://link.jointaro.com/72SzjBb9HW1S46Dx8)
- ["How do I create a growth plan with my manager/mentor and what should it include?"](https://link.jointaro.com/fude3eS1nJwcMSp9A)

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.