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

[Masterclass] How To Build Deep Relationships Quickly In Tech

Professional networking is vital for a healthy career, especially as a software engineer. However, many tech workers struggle with building relationships, especially introverts. In this masterclass, we teach you how to improve your interpersonal communication and build meaningful professional connections quickly, which might even make you some work friends along the way.

There were a ton of important points from this masterclass, so here's our Top 5 (in no particular order):
- **You're going to get burned, and that's okay** - Professional networking is just like making friends or dating: You will meet people where it just doesn't work out. Don't let that tear you down and make you cloister up. Move on from those relationships and continue investing in new people.
- **Make them feel special** - Asking someone for a huge favor with some copy-paste message isn't networking: It's begging. The classic example is cold messaging random people for referrals into their FAANG company. If you want any chance of success with a reach out, make sure to deeply explain your background and credibility alongside why you reached out to that specific person in particular - Put them on a pedestal.
- **Understand their incentives** - One of the biggest reasons people fail with networking is that they're entirely caught up in what *they're* looking for, reducing their networking to "*How can I get this other person to give me what I want?"*. Successful relationships are those where each party is able to provide lots of value to one another, and the first step to doing that is to understand what the *other* person wants and what motivates them. When it comes to networking within a company, this is usually tied to what they get rewarded for in performance review.
- **Lead with kindness** - Only helping others when they have already helped you is a recipe for weak, slow-growing professional networks. Kindness is 10x more valuable in building up a relationship when it's unexpected, making the pleasant surprise of helping someone who's never helped you before especially powerful. For a deep dive into this concept (including a story about how Taro cofounders Alex and Rahul met), [check out this Taro discussion](https://link.jointaro.com/Hr1nr53D7sfQAEv3A).
- **Maximize 1 on 1 meetings** - 1 on 1s are the core engine behind deepening interpersonal communication, and that includes professional ones. Schedule a recurring 1 on 1 if possible with anybody you want to build a deep relationship with, and make sure to use that time well. Embrace [the art of the "Awkward 1 on 1"](https://link.jointaro.com/4SqyPg6hjNFFrGf57) to share honest feedback, talk about how you're feeling, and learn who they truly are as a person. To learn more about this, [check out our masterclass about impactful 1 on 1 meetings](https://link.jointaro.com/zPPhTmG213gptAkg9).

Related resources:
- [Alex's Guide To Effective Communication](https://link.jointaro.com/XXKqrQ9WgogHjXGG6)
- ["How do I lead without authority?"](https://link.jointaro.com/EMR9xJZXRC1kLyFr7)
- [What Makes A Truly Great Tech Lead](https://link.jointaro.com/wnqsTvXTUWtq11gG6)
- [Presentation slides](https://docs.google.com/presentation/d/1TDdBRQTGc66T35PzB5SwcJ3HQci_csdy8mzKxQu3law/edit?usp=sharing)

[Masterclass] How To Survive Tech Industry Layoffs

Layoffs: They will always be a part of the tech industry. 2022 was the first year of massive tech layoffs in the post-covid economy, and 2023 is sure to bear several more. Not even FAANG is safe with Meta, Microsoft, and Amazon all having layoffs in 2022.

There were a ton of important points from this masterclass, so here's our Top 5 (in no particular order):
- **Layoffs are effectively random for almost everyone** - Individual contributors (ICs) and more front-line managers are generally not privy to what happens behind the scenes with cut decisions. You can be a well-connected high-performer in a healthy revenue-generating org and still be laid off. It's crucial to recognize this reality and be at peace with it.
- **Stop freaking out** - Ironically, the worst way to deal with layoffs is to worry constantly and drastically alter your behavior to optimize for them. It's not healthy to go to places like Blind regularly to stay "up-to-date" with layoffs. The best way to deal with layoffs is to continue living your life as normal and double down on responsible software engineer behaviors. For more context on what those behaviors our, read [our expert discussion on tech fundamentals](https://link.jointaro.com/C2buzEzWFQH7abko9).
- **Be deliberate with your performance review** - So many software engineers, junior ones in particular, assume that if they do good work and don't see any red flags, they'll get a good performance rating. This is very much not the case, especially at high-performance tech companies like FAANG. Maintain a transparent dialog about your performance with your manager and create a concrete growth plan. Here's [our masterclass on how to optimally navigate your performance review in tech](https://link.jointaro.com/Tp93kAUNoPwmFcmc9) to help with that.
- **Build a stellar, wide professional network** - It is more important than ever to build meaningful, high-quality relationships in the workplace. Tech is an inherently collaborative space: You need a multitude of connections to help you grow, vouch for you in performance review, and provide warm referrals for your next opportunity if you are laid off. If you want to deepen your network, check out [our masterclass on how to build deep relationships quickly in tech](https://link.jointaro.com/MvHfGDSzxwboGqBB8).
- **Getting laid off isn't the end of the world** - There's nothing wrong with you if you're cut during a layoff. Don't dwell on how you messed up or what you could have better to avoid the layoff: Focus on your next step. The silver lining is that getting laid off opens the door to your next opportunity and likely comes with some time in the form of a severance package to allow you to seriously think about your future. Check out [our masterclass on how to find a great team and company](https://link.jointaro.com/F4DDyKfuo3hMhj868) to optimize your next move.

Related resources:
- ["How to survive potential layoffs?"](https://link.jointaro.com/zGwioWXPLe8xhuA89)
- ["What are the signs of an impending layoff in an organisation that can help an employee prepare themselves better?"](https://link.jointaro.com/tkUnst8KKBdktPQq5)
- ["Staying motivated among lay-offs?"](https://link.jointaro.com/g9462CQrqy1KGtqR8)
- [Presentation slides](https://docs.google.com/presentation/d/1Uyf04xDGTweN0ija_Z3nr9NZ_WsoDikh_54LR5AfZjU/)

[Masterclass] How To Learn Quickly In Tech

Related resources:
- ["How do I identify the core things to learn when picking up a new tech stack?"](https://link.jointaro.com/4AvrQzhAVbLuiLrY7)
- ["How can I pick up other tech stacks more quickly at Meta?"](https://link.jointaro.com/6Pt5dj5JnU3ESJQZ6)
- [Presentation slides](https://docs.google.com/presentation/d/1C0RYphpovijVp8s3JVjG9iYFT6hgPJNHabIeP8WF7V4/edit#slide=id.p)

[Masterclass] How To Ace Your Big Tech Interview - Data Structures And Algorithms

Data structures and algorithms (often abbreviated as "DSA") is an infamous staple of the software engineer interview experience. Data structures and algorithms problems are the most well-known for being part of the FAANG interview process, especially for Google.

Here are our Top 5 favorite points from this masterclass (in no particular order):
- **DSA prep is insanely high ROI** - In fact, the return on investment for time spent on DSA studying makes it one of the highest yield activities any human can do period. If you haven't worked at FAANG / Big Tech before, switching into it is likely to increase your pay by 50%+. If you're in the US, this will often mean a raise of $50k+. So the next time you're feeling burnt out from DSA studying, keep this very bright light at the end of the tunnel in mind.
- **Leetcode and Glassdoor are all you need** - DSA studying is a solved problem. You can use other, newer tools if you want, but the old-school ones still work just fine. Glassdoor in particular is naturally very effective given the "Big" nature of "Big Tech". Go through the recent data points from Glassdoor if you're interviewing for Big Tech and make sure you have a good grip on recurring recent problems.
- **Learning DSA is all about pattern recognition** - For 80%+ of DSA problems, there will be some 1-2 liner "trick" that represents the whole solution. For example, the "trick" to 2 sum is "Look for the difference and use a set/dictionary". It is not scalable to memorize solutions as code - Look for patterns and remember solutions as that high-level insight.
- **Communicate, communicate, communicate** - Since FAANG companies are so huge, there are naturally going to be far more stakeholders on every project, making alignment far more important. Because of this, Big Tech companies will often closely judge your communication skills during the interview. Don't just code in silence - Even if you get the right answer, you may still fail for not maintaining a dialogue with your interviewer.
- **Don't forget about space** - Most people are aware of big O run-time complexity, but candidates often forget about space complexity. Make sure to talk about both when you analyze your solution. As a side note, remember that a recursive solution will *not* be O(1) space.

Related resources:
- [How Alex Got Into Meta With 0 Prior Leetcode Experience](https://link.jointaro.com/SbNwqoPDmroJTsE37)
- ["How do I balance my time between studying DSA and fleshing out my portfolio?"](https://link.jointaro.com/7dw5k5yheTK5qx2D7)
- ["Should I quit to prep for interviews?"](https://link.jointaro.com/xgiQFNmwS7QgBUdV7)
- [Presentation slides](https://docs.google.com/presentation/d/13uLUHDvZifjp2aVClGsW29nfuVpQYvrkGLP8cej0R_k/edit#slide=id.p)

[Masterclass] How To Ace Your Big Tech Interview - System Design

System design is a crucial software engineer interview skill, especially for FAANG and Big Tech in general. It is effectively a requirement to be leveled at a senior software engineer or higher and will show up in mid-level engineer interviews as well (with the occasional appearance in even junior engineer interviews). The cool thing about system design (unlike data structures and algorithms) is that it's something you actually need to do on the job.

Here are our Top 5 points from the session (in no particular order):
- **Leverage engineering blogs of top companies** - And if you're applying to one of these companies, definitely read their blog. This will help you understand their high-level design and gives you a real-world example to anchor off of, as opposed to something more abstract and high-level that you would get from a traditional book.
- **Do NOT write code** - System design is a *high-level* exercise meant to gauge seniority. Writing raw code is the mark of a more junior software engineer, which is why you should never be writing code in a system design interview. Instead, draw boxes with arrows where the boxes represent components and the arrows represent how they interact.
- **There is no right answer** - One of the main reasons software is hard is because of how open it is. For any complex technical problem, there will be several good solutions, each with varying tradeoffs. System design is not like school or DSA where there is a singular right answer.
- **Understand the problem requirements** - System design problems are, by design, very open-ended. For example, if you get "Build the Twitter feed", there are so many features that make it up: There is no way you can design the entire thing in 1 interview round. Work with your interviewer to understand the scope of the problem and which parts should be prioritized.
- **Follow mature software principles** - The 5 covered in this presentation are robustness, scalability, performance, extensibility, and resiliency. Don't just get the happy flow working - Think about how your system will react when edge cases are hit and things go wrong.

Related resources:
- [How To Ace Your Big Tech Interview [Data Structures & Algorithms]](https://link.jointaro.com/iTNxPCvkdGite4wT9)
- [System Design Series: Taro Playlists [Part 1] - What REAL System Design Looks Like](https://link.jointaro.com/4obaFizTZAdAcStY6)
- [Presentation slides](https://docs.google.com/presentation/d/1z4yX5LiiSxbHiNrBOTPIiDfhBL5qmwRUrDojT71OROY/edit)

[Masterclass] How To Have Impactful 1 on 1 Meetings

[Masterclass] What Software Engineers Should Look For In Their Engineering Manager

[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://link.jointaro.com/GYQgKaaKCmbbLCiCA)
- ["How to review code in another language/ from another team?"](https://link.jointaro.com/DZPAxtJr4pbrjaUY8)
- [Presentation slides](https://docs.google.com/presentation/d/1koyIR9K_CtESD7Vnh3GQOE-svFW-ngrQeEAduSAoH0w/edit)

[Masterclass] Understanding And Optimizing Your Pay In Tech

[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://link.jointaro.com/srjCLNGyF9HYEbEA6)
- ["How do I optimize my sacred hour at work?"](https://link.jointaro.com/KwV4QQCGNRziXnNe9)
- [Presentation slides](https://docs.google.com/presentation/d/1MCEx7X592VfvdWlFi4JrhSffiDIeNyc1FsqDJMy8hvI/edit?usp=sharing)

[Masterclass] How To Write A Stellar Tech Resume That Gets You More Job Opportunities

Writing an effective resume is crucial for succeeding within the tech industry, especially for software engineers. It's the primary step you need to clear before getting a chance with an interview opportunity. Unfortunately, there is a lot of misinformation around how to write a good resume: For 80%+ of junior software engineers struggling to break into tech, a poorly written resume is one of the main causes.

All that being said, here are our Top 5 points from the sessions (in no particular order):
- *Remember that a recruiter is reading your resume and will, on average, only spend ~10 seconds on it*
  - They are almost certainly non-technical. Make things very accessible and easy to understand: Avoid jargon!
  - Be ruthlessly concise. For the vast majority of cases, your resume should only be 1 page.
- Having a spelling or grammar mistake is the easiest way to get your resume thrown out
  - You have an effectively infinite amount of time to polish your resume. If you can't even catch basic mistakes like these, it shows that you have poor attention to detail or bad prioritization.
- Show, don't tell
  - Don't just say that you're great, prove it
  - Example: Talking about the Android apps you've built with 100k+ users is much more effective than just saying you're a great Android engineer
- Traps to avoid:
  - Having a summary section at the top
  - Self-rating yourself across skills
- In the end, your resume needs to be approved by a human, not just an ATS
  - Making your resume very weird to "optimize" for the ATS is the epitome of winning a battle to lose the war. It's pointless

For an effective example + template you can use, [check out Alex's resume here.](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/articles%2FAlex%20Chiou%20Resume%20-%20FINAL%20FOR%20SHARING.docx?alt=media&token=3a75b8b2-09e8-4b68-b80d-22761055c3b2) You can import it into Microsoft Word online and swap out all of his content with yours.

Related resources:
-  [Presentation slides](https://docs.google.com/presentation/d/15eLqE_WmePLA--lYTG0ZJVcHhpEld2qNTck_w0t_E9k/edit?usp=sharing)
- [In-depth session on acing your DSA interview](https://link.jointaro.com/cponWycMZZfkRNBW8)
- [In-depth session on acing your system design interview](https://link.jointaro.com/FWp3fithS4xzp3dx7)

[Masterclass] How To Get Promoted Faster In Tech

[Masterclass] How To Navigate Your Performance Review In Tech

The slides provide a great high-level overview of the entire session for your notes, so here's our Top 5 thoughts that aren't entirely in the slides:
- Not deeply understanding your company's performance review cycle is job suicide, especially in the current age of layoffs and stack-rank (the latter being perennial).
- If you're truly working at a top company, you shouldn't be promoted to the next level unless you have been functioning there for at least 3-6 months. Companies that don't do this tend to promote due to raw experience and have many incompetent people at senior+ levels.
- Always have a plan for your performance review, even if your goal is just to be average and survive. Work with your manager at the beginning of every cycle to create a clear and living expectations document.
- Be very deliberate about the peers you want leaving feedback for you on your performance review. Assemble that cast at the beginning of the cycle and start building those deep 1 on 1 relationships once you have done that.
- When you are asked to leave constructive feedback for a peer, flip the question from *"What did they do poorly?"* to *"How can they expand their scope?"*. This will become easier as you reach an L5 (senior) level and more deeply understand what each engineering level means.

Related resources:
- [What Software Engineers Should Look For In Their Engineering Manager](https://link.jointaro.com/ubiwMigf48higbEV7)
- [How To Get Promoted Faster In Tech](https://link.jointaro.com/JMnqQ8CppMGjroFB8)
- [How To Have Impactful 1:1 Meetings](https://link.jointaro.com/NBcaK9TKAQ67e5Sc8)
- [Presentation slides](https://docs.google.com/presentation/d/142PsWRJ-fmdP42CrFpR0VD64L1qFP-6nPTmjk5g1DKM/edit?usp=sharing)

[Masterclass] How To Build And Grow Tech Products To 500k+ Users For Free

Here are our Top 5 points from this session:
- **Side projects are incredibly powerful** - They improve your portfolio, increase your coding velocity, and give you holistic experience around building products end-to-end.
- **Care deeply about quality** - Users notice when your app or website is buggy. Strive to cover all edge cases and provide a truly polished experience.
- **Eat your own dogfood** - The best way to know how to improve your product is to use it yourself. This was a staple of Meta's engineering culture.
- **Least clicks design** - At the end of the day, it doesn't matter how "pretty" your product looks if it isn't efficient. Think about how you can have your "hero flow" take as few clicks as possible.
- **Understand SEO** - Work backwards from what people will be searching for when they need a product like yours. Then have those words in your product title and relevant metadata.

Related resources:
- [Presentation Slides](https://docs.google.com/presentation/d/1lfSCWI_OUtchWpIEKwG8JkII8IUvBeACRqEJlnTErjU/edit?usp=sharing)
- [How To Come Up With Product Ideas That Get 100k+ Users](https://link.jointaro.com/7Q8cDrda23zv2omU9)
- [How Side Projects Make Recruiters Come To You](https://link.jointaro.com/rxqDDu4sgMQbP6LT8)
- [Why Side Projects Are So Powerful For Junior Engineers](https://link.jointaro.com/cFo3doiWDeE5dpa67)
- [How To Split Your Time Properly Between Work & Side Projects](https://link.jointaro.com/YFCmNrsdqhuMSeUw5)

[Masterclass] How To Be An Amazing Interviewer In Tech

For all the core points, you can find them in the slides below. For this video summary, we're going to share our Top 5 insights from the session:
- The tension of being a great interviewer is that you need to balance getting signal of the candidate's ability while maximizing candidate experience.
  - Can you make it so that the candidate had a good time even if they failed?
- Getting signal happens when the candidate has to figure out a challenge. *This means that you need to be very careful giving hints*. If you give too many hints, you are solving the problem for them.
- **Never ever end an interview early due to poor candidate performance, especially an onsite round**. Turn the interview into a fun pair programming exercise where you build cool stuff and help them become a better engineer.
- If you're the candidate, communicate as much as possible and don't fish for hints. This gives the interviewer more opportunities to help you out. Doing the opposite can doom your chances.
- At the end of the day, the interview process is made up of people on both sides, interviewee and interviewer. Let's all make the world a little better by striving to be good interviewers!

Related resources:
-  [Presentation slides](https://docs.google.com/presentation/d/1oBNstU-3TJlPGc8Rc5K7AfUUdr7OUo1ADT3JPa4ecSk/edit?usp=sharing)
- [In-depth session on acing your DSA interview](https://link.jointaro.com/cponWycMZZfkRNBW8)
- [In-depth session on acing your system design interview](https://link.jointaro.com/FWp3fithS4xzp3dx7)

[Masterclass] How To Choose A Good Company And Team As A Software Engineer

Choosing the right company (or team) is one of the highest leverage decisions you'll make in your career, so it's worth doing some reflection!

It’s all about your priorities
- Figure out what’s important to you and what’s not. Create a stack-ranked list of all of these and work backwards from the top 2-3 to figure out the best opportunities for you
- People don’t realize how many angles there are to this. Here’s all the ones from the presentation: *Compensation, work-life balance, company prestige, supportiveness of team, growth opportunities, stability, maximum outcome (risk), remote work, product space, company ethics, technical space, level/title, benefits, location*

Supportiveness and overall quality of the team are often underrated
- It’s really hard to grow and have a healthy work life without this
- If you like your manager/teammates and you feel like you’re regularly learning/being challenged by them, deeply cherish that. People underestimate how hard it is to find an environment like this. Even in a prestigious company like Big Tech, this is difficult to find.

Big Tech vs. Startups
- At the end of the day, it’s all about your risk tolerance - Startups can have insane monetary/promotion outcomes, but they also might collapse the next year.
- In a vacuum: Start off at a Big Tech company to build a good foundation and then switch into smaller companies to have more scope/ownership

Some things you should NOT spend time on: 

❌ Don't focus on how much you liked (or did not like) the people in the interview process. The recruiter/interviewer is NOT representative of your life at the company. Instead, focus on trends of the people joining the company, rather than individual data points.

❌ Don't spend time looking at the financials of the company. Even if you do decide to dig into the numbers, there's a good chance you'll screw up the interpretation -- humans have a really hard time with exponential growth. 

Learning the quality of a team
- Talk to engineers/ICs if you can - The manager will inherently be biased towards their own team as they are often goaled on hiring
- Make sure that the team has a healthy oncall process and fast code review iteration

Related resources:
- [Full 1.5 hour session on finding a great engineering manager who will support you](https://link.jointaro.com/r6A67w77hYobJge79)
- [“How can you tell if a large public company is going in the right direction?”](https://link.jointaro.com/qqwNf65YZJsiU5JY9)
- [“What does it mean to not have enough scope to be promoted?”](https://link.jointaro.com/NEqz7SCR63g4kN2eA)
- [“What should I look for in a new team in terms of growth?”](https://link.jointaro.com/vd3HM4Zaju8Zeun57)

[Masterclass] How To Write Better Code Faster As A Software Engineer

Code: It's the main thing software engineers care about. However, as we all know, writing code quickly while keeping it clean can be extremely difficult. This is what this masterclass will help you with: We want to empower you to not only write more code, but write higher-quality code as well.

There were a ton of important points from this masterclass, so here's our Top 5 (in no particular order):
- **Go deep, not wide** - One of the most common mistakes junior software engineers make is not focusing on just 1 stack, often captured by being a "full-stack engineer". When you go ultra-deep on just 1 stack, you will start developing software engineering fundamentals and "muscle memory" that allows you to write code a lot faster. It will generally take 2-4 years of focus on just 1 stack to start getting really good at it. For more information about this point, [check out our video on how software engineers should initially learn](https://link.jointaro.com/hoL4o29S3YsGsR9i7).
- **Build side projects** - There's no magic to getting better at coding: The more you do it, the stronger your skill. This is why side projects are so powerful: They allow you to write more code without overworking yourself. To learn more about this, check out ]this expert career advice on how side projects can really level up your performance on the job](https://link.jointaro.com/ox9ae9Vbi7k3zWAf6).
- **Submit polished pull requests** - There's more to code than the raw lines you put into commits; how you submit it for review is a huge factor as well. If you take the time to make atomic PRs, add context, and attach a thorough test plan, your code will be landed much faster (and your team will love you for it). For concrete examples on what this looks like, [check out our video on "One Diff, "One Thesis"](https://link.jointaro.com/5Ehehxt6jBR42ui1A).
- **Really absorb code review feedback** - The main way you will learn as a junior engineer or as an onboarding team member is by getting feedback on your code. Make sure to respond to code review feedback in a timely manner (<4 hours) and really soak it in: Strive to never make the same code quality mistake twice. [Here's our in-depth advice on how to get high-quality code review faster](https://link.jointaro.com/qyG7Yw6EqJ8DGNad7).
- **Modularize your code** - Split your code up into focused components with single responsibilities and thoughtful names. When you do this, your code will be much more flexible, reusable, and easier to read. [Here's our advice on how to break down large projects into more digestible chunks](https://link.jointaro.com/LcgMPkVFebuJus7QA).

Related resources:
- [[Masterclass] How To Manage Your Time Optimally In Tech And Achieve More Results](https://link.jointaro.com/8D6Y6BnYm8696RtC9)
- [[Masterclass] How To Do Amazing Code Review](https://link.jointaro.com/8D6Y6BnYm8696RtC9)
- ["What can I do to quickly build my reputation as a junior engineer?"](https://link.jointaro.com/hxCTvumsQhUqRAbn6)
- [Presentation slides](https://docs.google.com/presentation/d/17o6XlEjiYbkV1FMrhOoFwcM1O59NmdAOfZ3AXol7daY/edit?usp=sharing)

[Masterclass] How To Succeed At A New Team Or Company As A Software Engineer

There are **ton** of great points in this presentation, so to prevent this summary from being a 10 page essay, we're only including our Top 5 points:
1. **Asking for help != weakness** - In fact, it's quite the opposite: Trying to figure out everything on your own and not asking questions is what makes you weak. Being comfortable with your cluelessness and putting yourself out there aggressively to get all the help you need is what makes you strong. You can [learn more about this dynamic here](https://link.jointaro.com/NfLv7hrkxd6wdEVZ8).
2. **Get maximum value from questions** - Ask high-quality questions and ask follow-up questions to really understand the answers your teammates give you and the systems they followed to arrive at those answers. Your goal is to learn skills in a sustainable way that makes you more independent as opposed to needing hand-holding all the time. [You can learn more about what it means to not require hand-holding anymore here](https://link.jointaro.com/JBFXjwnoyq1iiRt76).
3. **Don't get trapped reading the code and documentation** - The only real way to learn a codebase is to just hop in, start changing code and seeing what happens. Software is all about learning via doing. You can [learn more about how to learn a codebase faster here](https://link.jointaro.com/WsN6429SYUhsdTps8).
4. **Thanking people is a skill** - When you're onboarding especially, it is crucial for you to show your gratitude effectively: Don't just do the basic, boring "Thanks for the help!" DM over Slack/Teams after you have been helped. Send the helper a heartfelt note, tell them in person, or let their manager know about their great deed. You can [learn more about "deep thanks" here](https://link.jointaro.com/RcRpQT7ns5YggLTW7).
5. **Be empowered to help others, even when you're new** - Anyone can help others, even the newbie. In fact, newbies are equipped to add unique value by having a fresh pair of eyes, particularly around improving the onboarding process for others. If you're onboarding, make it one of your priorities to earn respect as that will make the entire onboarding process smoother for you.

For more premier resources on onboarding:
- [How Alex became a tech again in just 1 month after switching into Robinhood from Meta](https://link.jointaro.com/vfgfDhbKMymQPGPo7)
- ["How do you overcome the fear of asking stupid questions / bothering people when you need help?"](https://link.jointaro.com/DqoCYkqncsEtUGDt9)
- ["How can I become more independent and better at unblocking myself with tricky technical issues?"](https://link.jointaro.com/xE8oMpCaDYjuMhCg7)
- [Presentation slides](https://docs.google.com/presentation/d/1MTs7GIklpVnYrA_JRlgcpKu1reeTLto1kYEsa6M8UqI/edit?usp=sharing)

Explore Full Session Recording on Taro