Setting Up Your Engineering Mindset For Long-Term Success

What separates the top senior engineers from everyone else?

True or false: One of the reasons top tech companies are so strong is because they are so well organized. Every project is neatly defined, so when engineers take them on, they can just execute quickly and easily.

Which one of these is the enemy of productivity?

True or false: A lot of senior engineers write very little code, adding value in other ways.

Why is it important to break problems down?

- A core expectation of engineers at top tech companies like FAANG is that they're able to take large, ambiguous tasks and smoothly execute on them. This is effectively a requirement reaching senior levels at these places.
- The trick to these projects *is to break them down*. Breaking down large projects into smaller and smaller sub-tasks makes the overall body of work clearer and less scary. Clarity is one of the main ingredients that leads to action.
- This decomposition is also vital for your mentality. By defining these smaller and more reasonable milestones, you are setting up your brain to register a win more frequently and consistently. This does wonders for your confidence and self-worth, which allows you to do good work sustainably over a long period of time and eventually ship these large tasks and massive projects.
- The gained clarity also enables you to ask for help more easily and delegate work, the latter being a staple behavior of senior+ engineers at top companies.

Related resources:
- ["How can I get better at estimating long-term projects?"](https://link.jointaro.com/bcc3PgBTWCoaKqDD7)
- ["How do I make software less overwhelming?"](https://link.jointaro.com/j3itbssZN9XUdq998)

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

- Learn how to blame the code (i.e. know who wrote each line of code)
- A lot of people don't realize that when it comes to big companies, there are huge swaths of the codebase where nobody really knows how they work
- When absorbing the codebase on a new team/stack, go through the various classes/files in your ecosystem, and use blame to understand the hotspots, the code that's been changed frequently and recently by people. Don't just try to understand the entire codebase straight up.
  - Use the test plans of connected commits/code reviews to better understand how to run the code and what it does
  - Maintain the system: This is another reason why *you* should have great test plans on your diffs/commits, so you can keep your team's codebase well-documented and easy to learn

Making The BEST Case For Yourself In Performance Review: The Self Review

- Your self-review is the most important feedback for you come performance review season: Ignore the weirdness you may feel hyping yourself up and take it very seriously.
- The onus for representing yourself well falls mainly on you, not your manager or peers. Nobody knows you better than you. It's your job to make sure that none of your awesome achievements fall through the cracks.
- Start your self-review early and refine it across several iterations with your manager.
- Use [your brag journal](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/brag-journal/) to seed the self-review.
- Show the impact. Attach links to proof as much as you can (e.g. linking a dashboard with positive metrics to show that the project you launched added business value).

Related resources:

- ["How can I most effectively talk about my projects?"](https://www.jointaro.com/question/c0CDYi5VCRXz0gHHLiGP/how-can-i-most-effectively-talk-about-my-projects/)
- ["How to figure out what the most important projects are?"](https://www.jointaro.com/question/CgCPA60bDDHoOteN7Lmb/how-to-figure-out-what-the-most-important-projects-are/)

How To Learn A New Codebase Fast

What is the best way to learn a codebase?

True or false: In software, experimenting and making changes is cheap, so a great way to learn is by trying a lot of things and seeing what happens, even if you do not fully understand the overall codebase yet.

Why is structured learning like tutorials and courses not effective for actually learning a codebase?

True or false: Before you jump into a codebase, you should ideally get a certificate in that tech stack before working with it.

Which of these is a good way to learn a codebase with your first code changes within it?

True or false: Breaking something locally is an effective way to learn a codebase.

- The best way to learn a new codebase is to learn by doing.
- Don't get paralyzed reading documentation or getting a certificate before jumping into a codebase.
- Start tinkering ASAP. It doesn't matter if you don't fully understand the codebase - Just do small changes like deleting a line or flipping a variable and then see what happens after you build the code.
- Alex's standard: Put out a commit/pull request for a new codebase within 2 days.
- You want to get code into review as soon as possible, because the feedback you get on your pull request is where the real learning happens. Don't worry about the quality; it's going to be bad in the beginning like with any newbie - The important thing is that you submit something out there into the world so your teammates can tell you how to get better.

Related resources:
- [How To Figure Out Which Parts Of A Codebase Matter](https://link.jointaro.com/PdpWBjAzU7NVTamf6)
- [Learning A New Codebase Fast As An Intern](https://link.jointaro.com/SMaLvqCVeoH9MmvV7)

Don't Learn Code In This Way - How Software Engineers Waste Time

So many software engineers mess up when they're trying to learn code by bringing over a bad habit from school: Studying. This is simply not how software works, and this video's here to explain why.

Here are the core points:
- **Reading code and documentation is ineffective** - You can't purely read your way towards a good understanding of a codebase; it will get you 10-15% of the way tops. Software is fundamentally about doing - The actual learning begins when you jump in and start playing with the code. On top of all this, it's much better to get a high-level understanding of the codebase by asking your teammates for it instead of trying to infer it yourself from raw reading.
- **Documentation gets worse the better the company is** - Good software companies are fast-moving. This is a big reason why FAANG is successful: They are able to still move quickly despite their immense size. Because of this, documentation is rarely kept up to date due to how fast the codebase evolves. In fact, excessive reading of documentation may actively harm you if it contains legacy patterns that aren't accepted at your company anymore.

This clip is from our masterclass on how to succeed at a new team or company as a software engineer. You can watch it here: [[Masterclass] How To Succeed At A New Team Or Company As A Software Engineer](https://www.jointaro.com/lesson/n384HdJuDgulSHbHQLnf/masterclass-how-to-succeed-at-a-new-team-or-company-as-a-software-engineer/)

So now that you know how NOT to learn a codebase, here's some resources on how to actually learn a codebase:
- [How To Learn A New Codebase Fast](https://www.jointaro.com/lesson/DX27hiXPJ4G7Czk2mwLL/how-to-learn-a-new-codebase-fast/)
- [Learning A New Codebase? Here's How To Figure Out What Matters](https://www.jointaro.com/lesson/dQXKZNqivtoByEHV9V17/learning-a-new-codebase-heres-how-to-figure-out-what-matters/)
- ["How can I learn a large codebase fast as an intern?"](https://www.jointaro.com/question/F2rJZgdUBxdGZilFTR6k/how-can-i-learn-a-large-codebase-fast-as-an-intern/)

[Masterclass] How To Come Up With 100k+ Users App Ideas You Can Build For Free

Start with a simple side project and keep iterating on it to separate your side project from the rest.

Related resources:
- [[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 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/)
- ["Finding a mobile app idea - How to do it?"](https://www.jointaro.com/question/KJ4VXh6rUhKbWeiJoRDe/finding-a-mobile-app-idea-how-to-do-it/)
- ["What are some of the side income or passive income sources you can suggest?"](https://www.jointaro.com/question/URhejS9m02tEFM9WLZsd/what-are-some-of-the-side-income-or-passive-income-sources-you-can-suggest/)
- [Presentation Slides](https://docs.google.com/presentation/d/1ai8lxU1B-bH35iiSFf5hvk6NjAHpUyF2rshjyDipvaY/edit?usp=sharing)

Make Sure To Do This To Get Full Credit For Your Work

On top of doing the work, what else do you need to do in order to get full credit for what you are doing?

True or false: It is bad to give more public status updates for your project as it will come across as looking for attention.

Why should you not feel icky when you are properly broadcasting the status of your project?

Core points:
- *You don't get credit automatically for doing good work, especially if you work in a large company.*
- It is vital that you bring visibility to your work and claim credit for jobs well done in project updates, meetings, and other more public avenues.
- You may feel "icky" for sharing status updates - Don't! If your work is truly important, than it's worth sharing about and keeping the team in the loop. If you don't feel like your work is important, then you have a separate problem you need to address.
- Use project updates to thank others! Treat it as a mechanism to build social capital.

Related resources on how to write concise, impressive project updates:
- ["How can a painfully introverted person increase their visibility and promote themselves?"](https://link.jointaro.com/3XHsUifABjyN3Tq98) - From a SWE intern at Google
- ["How to get more visibility on work?"](https://link.jointaro.com/aQUHxnsNAJVcRgth6) - From a junior engineer [E3] at Meta

DSA Crash Course [Part 1] - Course Welcome

Welcome to our crash course for data structures and algorithms! This incredibly in-depth course will help you master core data structures and algorithms concepts, even if you're a complete beginner with the topic. This course is exactly for you if:

- You want to be efficient with your study time
- You don't enjoy solely grinding LeetCode because it's slow and frustrating
- You want to actually understand the concepts instead of merely memorizing patterns

This course is special because it's carefully engineered to be a smooth and effective ride:

- Problems are specifically chosen to be a progressive sequence, building on top of one another
- The overall difficulty of the problems you'll solve will gradually increase
- You will be able to visualize the underlying data structures and algorithms with animated explanations
- Learn the implementation with concrete code walkthroughs

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

System Design Series: Taro Playlists [Part 2] - Sharing The Context

Core points from the video:

- Weak organizations will have product and engineering be incredibly siloed. It is far more effective when product managers and engineers work very closely together. Meta in particular has seen a lot of success by having this harmonious culture.
  - This means that software engineers should also understand why they are building something and not purely be responsible for implementation.
  - Software engineers should have an opinion on the product and work with their PMs to optimize vision and direction.
- A master spec should also have the context behind the "why" of a product and not only contain technical details.
  - The product details will often live in a separate document called a PRD (Product Requirements Document). In this scenario, you should link it in your technical spec and maybe have a paragraph summary of its contents as well.
- Capture any existing context that will affect how you build your system. This will often means that there's components that are already around in your company's ecosystem that you need to build on top of - This scenario is extremely common when building projects in Big Tech.
- Attach visual aides if you can (images, videos, gifs): It makes it far easier for project stakeholders to grok the information.
- **Context behind Taro playlists:**
  - One of the most requested feature within Taro
  - Think of it as being similar to YouTube playlists
  - We have already shipped a read-only version of playlists

For the full system design doc, you can get it by [becoming a Taro Premium member](https://www.jointaro.com/membership).

[Case Study] Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta

- The expectations for an L5+ (senior+ at a FAANG or similar company) engineer are high. You won't get 12 months or even 6 months to fully onboard: You need to start having huge impact and showing your depth within 1-2 months.
- After starting, Alex told his managers that he was happy to offload any responsibilities they had so they could focus on higher-level issues and expand their scope. As a tech lead, you need to view your manager as a partner, not just a boss. "Treat me as a resource."
- The project that Alex was first put on was to make settings more server-driven within Robinhood
- The most impactful thing to do was to add color to the project:
  - Stabilize and then drive the workstream meetings
  - Create a thorough tech spec
  - Align XFN to figure out how to treat each settings section properly, especially in places where there were inconsistencies
- How Alex added his depth:
  - Wrote a 5+ page Android spec for his portion
  - Manually audited all of settings and compiled a detailed spreadsheet of inconsistencies to fully capture impact
  - Thorough data analysis spec, doing complicated SQL queries himself
  - Mentored an L4 engineer in the process, giving them L5 scope
- Recap (how you can incorporate the learnings here into your work):
  - Earn trust quickly: Be "aggressively" nice. Find out how you can add value to others and be very sincere and upfront about it.
  - Fill in the gaps: View your projects holistically and figure out what's missing to move the project forward. This will often times be "less flashy" non-coding work.
  - Bring people together: Don't be paralyzed by your lack of knowledge. Especially if you're new to a company, you will be clueless in a lot of scenarios. If you're in a cutting edge company like Meta/Robinhood, there will be a smart person(s) somewhere out there with the answer: You just need to bring them together in a healthy way.
  - Go deep: There's far more to a senior engineer than their ability to code. If you're a new L5+ engineer, even the tenured L3/L4s at the company will code circles around you in the beginning. If you're an L5+ engineer, figure out what behaviors and fundamentals you have that more junior engineers don't and show those as much as you can. This generally involves shipping software in a much more holistic way.

Related resources:
- [Presentation slides](https://docs.google.com/presentation/d/1j5Lj_IGrtCRUpobj0f8k9egrBAej9apzikGp_V_iTCk/edit?usp=sharing)

Strategies To Stop Procrastination

Procrastination: We all become masters of it in school, and for almost all of it, this terrible habit will continue long into our careers. This video covers how you can combat procrastination and maximize your work productivity.

Here are the key points from the video:

- Break down your overall goal into smaller pieces and strive to do just 1-2 pieces of it per day.
- Write things down! Clarity leads to action.
- After every week, reflect on how you spent your time.
- Find an accountability partner. Pair with someone else and commit to sharing progress updates with one another every single day. This social pressure will motivate you to do work as you don't want to be the person going into that meeting with no progress.
- Introspect and ask yourself if you're truly excited about the thing you're doing. If you're not, you might need to find that true passion.

Related resources:

- [\[Masterclass\] How To Manage Your Time Optimally In Tech And Achieve More Results](https://www.jointaro.com/lesson/rnX9EKpzc43TgGW9MozG/how-to-manage-your-time-optimally-in-tech-and-achieve-more-results-792021/) 
- [A Powerful Tool For Software Engineer Productivity - Focus Blocks](https://www.jointaro.com/lesson/uGdn2AiDfn3B07FkpIVR/a-powerful-tool-for-software-engineer-productivity-focus-blocks/)
- ["How do I optimize my sacred hour at work?"](https://www.jointaro.com/question/l8dzUVTu99CahofQsYAi/how-do-i-optimize-my-sacred-hour-at-work/)

How To Build Work Relationships Faster - Giving Deeper Thanks

If you want to build work relationships efficiently and effectively network in general, it's vital to master the art of giving thanks and showing gratitude.

Here are the core points from the video:
- **Giving thanks is a skill** - Don't just send a cookie-cutter 1 sentence thanks over DM after someone helps you: It's very soulless and takes you almost 0 time to write. Helping someone out with their work performance is one of the most high-impact ways you can add value to their lives; you should respond in kind when you receive this help. Some basic tactics to "level up" your thanks is to send a heartfelt paragraph and to thank them in person, either through a video call or actually in-person if you're physically coworking.
- **Thank teammates via their manager** - This is especially true at a high-performance tech company like FAANG where so much of the engineering culture revolves around performance review. If someone goes above and beyond helping you, make sure to let their manager know. If they're a recurring helper, you can even tell their manager that you deeply believe that this altruistic behavior should be rewarded in their performance review: When the helper hears this from their manager, they will *really* value you as a teammate and know that their efforts have truly been rewarded.
- **Thank publicly** - This adds more weight to your gratitude and also acts as an artifact to help out the other person during performance review.
- **Recurring thanks** - There's no reason why you can't thank someone multiple times for the same thing. Alex had a mentee who was really good at doing this: They would be very thankful on the initial unblock, and after the full project finished, they would thank the helper again (i.e. *"I just shipped this project, and it wouldn't have been possible if you didn't help me on X"*).

Related resources:
- [Effective Communication Guide [Part 3.1] - The Power Of Thanks](https://www.jointaro.com/lesson/noWZaoGWlrYQxX2Vhigd/effective-communication-guide-part-31-the-power-of-thanks/)
- [Don't Waste Your 1 on 1s. Build The Relationship](https://www.jointaro.com/lesson/wcFrGc53iHzbWh0Ssw1j/dont-waste-your-1-on-1s-build-the-relationship/)

Once You Get This, You Will Be Able To Fix Any Software Bug

The foundation for debugging and just getting software as a whole is understanding the end-to-end flow. This is a mental framework that can be applied to any language and any stack, even if you have never worked on it before.

For most of you, you're working with something like this:

1. The client sends an API call to the back-end
2. The server receives the request and parses out the model
3. The server queries the database for the appropriate data
4. The server returns the data in a formatted JSON response
5. The client receives the response and parses it
6. The client translates the models into UI and renders it

Once you figure out what steps are necessary for the flow you're debugging, you can systematically go through them one-by-one until you identify which one is breaking.

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/)
- ["How can I root cause bugs faster?"](https://www.jointaro.com/question/PSv7aYI70VwaDsoRgMyW/how-can-i-root-cause-bugs-faster/)

Use Code Review Feedback For Hypergrowth - Meta Prodigy Engineer Story

As a junior software engineer, one of the main ways you're going to grow is through feedback on your code review. Because of this, it's vital that you get the maximum value from code review feedback.

Here are the core points from the video:
- **Respond quickly and with appreciation** - Be thankful of good code review feedback, and try to respond to code review comments within 1 to 4 hours. Don't be defensive when it comes to code review feedback.
- **Don't make the same mistake twice** - Take the time to really understand and absorb the feedback: Don't just make the suggested change. If you don't understand the principles behind some feedback on your code, just ask! [Here's our in-depth advice on how to really not forget code review feedback](https://link.jointaro.com/7wjo6DcDcJmxDVYB9).
- **Alex's mentee prodigy story** - Alex had a Meta mentee who was able to grow from junior [E3] to senior [E5] in just 2 years. A big part of this was their incredible code velocity:
  - This mentee really nailed learning from code review feedback. Their initial commits were a bit messy, but they quickly got to a point where they stopped making mistakes.
  - They were also very meticulous about their pull request quality. They always had very thorough summaries alongside very complete test plans. For more complicated commits, they would have up to 5 videos walking through every case.
  - After 1 half, this engineer was writing almost 500 commits a half, making them the #1 code committer in the entire organization. This was largely because their stellar code quality and code review learning allowed them to land their pull requests on the very first try 90%+ of the time.

This highlight is from our masterclass on "How To Write Better Code Faster As A Software Engineer". [Click here to watch it.](https://link.jointaro.com/v6zEgUfQTxoSj33Z7)

Related resources:
- [Quick Tips To Get Higher Quality Code Reviews Faster](https://link.jointaro.com/dE4U41RAVtZKLhxJ7)
- [Avoid These Junior Engineer Mistakes With Code Review](https://link.jointaro.com/agkYrLH8uuCv4UcPA)
- [Code Review MUST Be Fast, Otherwise The Team Is Unhealthy](https://link.jointaro.com/oxK55E1bkX8nMeNGA)

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

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

How Big Tech Judges Interview Performance Differently

What is the main extra axis that Big Tech companies will grade interview candidates on?

As long as you get a correct, optimal solution, that is enough to pass a Big Tech interview round.

Why is communication so important in Big Tech companies?

True or false: Big Tech companies don't really care about what specific technologies and programming languages you have worked with.

What's the core high-level asset Big Tech interviewers look for?

- At a lot of companies, you can just get the right solution and pass. This will often not be the case with Big Tech interviews.
- Communication is much more important at Big Tech companies as there's more stakeholders on everything
- Try not to be silent for 5+ minutes at a time during the interview. Regularly be explaining your thought process
- Massive companies like Meta and Microsoft will have very custom technology, so it doesn't really matter what you're currently experienced in
  - Because of this, Big Tech companies generally let you code in whatever language you want
- It's possible to get the sub-optimal solution or a slightly incomplete solution and still pass the interview if your communication is very strong

Related resources:
- [[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/) - The video this clip was taken from
- [Alex's Guide To Effective Communication](https://www.jointaro.com/playlist/hVdLQQzfslaYarLSCmmy/)
- [[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/)
- [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/)

How To Find Your Path Among The Countless Paths In Tech

As an early-career engineer, it can be overwhelming to figure out what technology to learn and which domain to dive into. In this video, Airbnb Director of Engineering [Rachel Zhao](https://www.linkedin.com/in/rachelzhao/) walks through the framework you can use to find your path.

The key to finding your passion is: 
1. Explore and refine. Give yourself some time + space to try adjacent areas.
2. Reflect on the various activities you do: What sparks joy? Think about both technical and non-technical activities.

If you want to learn more about this topic:
- [Figuring Out The Best Company To Join As A Software Engineer](https://www.jointaro.com/lesson/Nqs0U6rt2qFyXKSZurTh/figuring-out-the-best-company-to-join-as-a-software-engineer/) - The former VP of Engineering of unicorn startup Mixpanel shares his thoughts here.
- [This Is How Software Engineers Should Initially Learn](https://www.jointaro.com/lesson/wUl3hc2wr1ms493bd23b/this-is-how-software-engineers-should-initially-learn/) - This video covers how earlier-in-career engineers mess up their learning.

Creating A Portfolio That Makes Recruiters Come To You

Building a personal portfolio looks nice and feels good, but it *rarely* helps engineers find jobs. In this video, we cover how you can truly stand out as a software engineer and make the jobs come to you (instead of the other way around).

Here are the core points:
- Building a portfolio website can be a nice exercise, but don't spend too much time on it. *Don't expect to get any inbound recruiter reach outs due to your portfolio site*. There is no real central repository of them that recruiters browse.
- In terms of what recruiters do browse, it's primarily LinkedIn. If you have this portfolio energy, it's much better spent polishing your LinkedIn profile instead.
- At the end of the day, a portfolio website is resume++. This means that your foundation is still your resume: Make sure your resume is *extremely* sharp before you even consider building a portfolio website.
- Alex found a lot of success having his Google Play developer page be a portfolio as it hosted real, verifiable products on it. Since his side projects got millions of installs combined, he's gotten reach outs from top companies like Uber, Square, and Instacart through his Google Play developer email.

Related resources:
- ["What technologies or stacks should I create a project to add in my resume for entry level software jobs?"](https://www.jointaro.com/question/c0DiG5ureLbkZ1mKD9Rf/what-technologies-or-stacks-should-i-create-a-project-to-add-in-my-resume-for-entry-level-software-jobs/)
- ["I want to land a job in a big tech as a SWE - How to do it?"](https://www.jointaro.com/question/MWJfUBnnUr8CKYFCO8bp/i-want-to-land-a-job-in-a-big-tech-as-a-swe-how-to-do-it/)
- ["Can Github stars grab big tech recruiters' attention?"](https://www.jointaro.com/question/XaUn4XuIBMSmrr5fcHIT/can-github-stars-grab-big-tech-recruiters-attention/)

Junior Engineers, Avoid This Fake Growth Trap

What's the main change in expectations when growing into senior engineering levels?

True or false: Hustling (i.e. working extremely hard) is a common, healthy way to get promoted.

Why is it bad if you are able to get promoted to senior levels through sheer ultra-hard work and very high raw productivity?

- A lot of earlier-in-career engineers believe that being a better software engineer is all about coding: If you can write more good code faster, then you are growing.
- This is generally mostly true in the beginning, but then it quickly becomes a toxic way of perceiving growth.
- You will hit walls. There are only so many hours in a day, and you can only type so many lines of code per hour.
- As a senior engineer, you need to focus on multiplicative and deeper behaviors.
- If you are able to have the impact of a senior engineer but are working extremely long hours, you are essentially "faking" the appearance of a senior engineer. This working model is not sustainable, and once you burn out, it's a terrible situation for everyone.

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.