Effectively Learning Data Structures And Algorithms (DSA) For Software Engineer Interviews

Which of these is the core building block of data structures and algorithms problems?

True or false: The most effective way to be prepared for data structures and algorithms interview problems is to memorize the code of each problem's solution line by line.

Why should you comment your solutions to data structures and algorithms problems?

True or false: When you are completely stuck, you should just look at the entire solution in order to learn it.

Why is it healthy to struggle on data structures and algorithms problems?

**Data Structure and Algorithm (DSA)** questions are a core part of the interview for most software engineering roles. These questions, sometimes called "Leetcode problems", are essential to master if you want a reasonable pass rate in your interviews. 

However, so many engineering candidates struggle to truly understand these questions, resulting in lower confidence and worse performance. Here are the best tips when it comes to passing these types of interviews:

- The key to mastering DSA is to learn patterns and not memorize code. The "drill and kill" style of studying is really badly suited for DSA.
- 80% of asked DSA problems will use 1 of ~15 different patterns. So rather than focusing on individual problems, your goal should be to connect the problem to a broader, recurring pattern.
- Examples of patterns: binary search, graph traversal, sliding window, tail recursion. Being able to understand problems of the same type is essential. Being able to *name the pattern* is even better. 
- Extensively comment your solutions, primarily with the key pattern behind the problem. When you get started, it will be painstakingly slow to understand each line of code, and potentially comment it. That's ok! You will feel frustrated, but your goal is to deeply understand the problem and solution, instead of simply solving as many problems as you can.
- When you can't figure out a problem, read 10-20% of the solution and see if you can come up with the entire solution from there. Build the muscle of converting high-level points into fleshed out solutions

Related resources:
- ["Mock Interviews vs. Leetcode?"](https://www.jointaro.com/question/U4kohSE8g5LR7GD9cqYH/mock-interviews-vs-leetcode/)
- [[Masterclass] How To Ace Your Big Tech Interview - Data Structures And Algorithms](https://www.jointaro.com/lesson/V4sTACzfOh22nMVcUV3w/masterclass-how-to-ace-your-big-tech-interview-data-structures-and-algorithms/)
- [[Masterclass] How To Ace Your Big Tech Interview - System Design](https://www.jointaro.com/lesson/J3I9fTW9ulr6T9KjxpqY/masterclass-how-to-ace-your-big-tech-interview-system-design/)
- [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/)

What Makes A Truly Great Tech Lead - A VP of Engineering's Perspective

Former Mixpanel VP of Engineering David Pan (also ex-Twitter, ex-Amazon, ex-Microsoft) shares his wisdom on what it really means to be a tech *lead*, shipping projects effectively and leaving the team in a better place in the process.

- **Overview:** Tech leads are extremely valuable. They allow a team to multi-thread and execute on multiple projects at once, not requiring the engineering manager to babysit everything.
- **Understands the business context:** Great tech leads have strong product understanding and realize that software needs to be built in different ways based on the situation.
- **Project risk shrinks over time:** Great tech leads are constantly looking for ways to de-risk their projects over time. As things get closer to the ship date, the project actually becomes less scary!
- **Level up the team along the way:** Great tech leads figure out ways to leave the team in a better place than it was before the project.
- **If you're looking to become a great tech lead**: Get to know your PM, assess risk proactively and tackle the hardest items first, and find opportunities to level up your teammates.

You can connect with David here: [David Pan's LinkedIn](https://www.linkedin.com/in/davepan/)

If you want to learn more about becoming a great tech lead, check out the following resources:

- [\[Course\] Tech Lead Blueprint: Role, Skills, and Strategies](https://www.jointaro.com/course/tech-lead-blueprint-role-skills-and-strategies/)
- [Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta - Case Study From Alex](https://www.jointaro.com/lesson/X8vpfJooDpsX915ouC00/case-study-becoming-a-tech-lead-again-in-just-1-month-after-joining-robinhood-from-meta/)
- ["How do I lead without authority?" - Staff Software Engineer \[E6\] at Meta](https://www.jointaro.com/question/BWv3hFSELbn59mXJbkNB/how-do-i-lead-without-authority/)
- ["How can I hit the ground running as a tech lead?" - Senior Software Engineer \[SDE 3\] at Amazon](https://www.jointaro.com/question/MiEPhSkzr8TRRSMRkrNQ/how-can-i-hit-the-ground-running-as-a-tech-lead/)

This Is How Software Engineers Should Initially Learn

- Learn depth-wise initially, and then you can go breadth-wise after you become a very established senior engineer.
- If you don't know what you're passionate about, try a bunch of things out (go for breadth) until you find that passion.
- After finding your passion, go deep on it.
- You need to commit a long period of time to just 1 thing initially, so you start learning fundamentals as opposed to tech stack-specific tactical pieces.
- *You will eventually realize that all tech stacks are the same in many ways* - All languages and tech stacks share a common set of fundamentals. You will not get to this state if you switch stacks every year.

Related resources:
- [How The Best Software Engineers Learn A Tech Stack - The Lego Model](https://www.jointaro.com/lesson/9cVK5zsAQstbTCc1wrWx/how-the-best-software-engineers-learn-a-tech-stack-the-lego-model/)
- ["How do you get more independent?"](https://www.jointaro.com/question/FUP3gHb7rv9CXc84LaKn/how-do-you-get-more-independent/)
- ["How can I write great code faster?"](https://www.jointaro.com/question/ciE9a2TZ7rZNyYP8HbeJ/how-can-i-write-great-code-faster/)

Rockstar Software Engineer Story: SW2 -> Principal In Just 4 Years

- An engineer joined Mixpanel as a level 2 Software Engineer, and received 4 promotions in 4 years to become a Principal Tech Lead Manager (TLM).
- Key to his success was the ability to make rapid progress on one of the company's top priorities: reduce infrastructure spend.
- He had a hypothesis that the majority of the cost incurred came from a few customers where the economics were backward for Mixpanel.
- Rather than solving a gnarly technical problem, the engineer worked with these customers to change their use of compute resources, resulting in massive savings for the company.

For more resources about becoming a rockstar engineer:

- ["What's the core insight behind quick growth?"](https://www.jointaro.com/question/nJ762p255cGyuth36H6w/whats-the-core-insight-behind-quick-growth/)
- ["What's the difference between a low performer software engineer and a high performer?"](https://www.jointaro.com/question/nMxx2EMVIlJbl1oK4SGu/whats-the-difference-between-a-low-performer-software-engineer-and-a-high-performer/)
- [Mentoring Junior SWEs \[E3\] to Senior \[E5\] In Just 2.5 Years At Meta](https://www.jointaro.com/lesson/EX9563YnxcJb62cCmetg/case-study-mentoring-junior-swes-e3-to-senior-e5-in-just-25-years-at-meta/)

System Design Series: Taro Playlists [Part 1] - What REAL System Design Looks Like

This video is the introduction to our system design series, a vital skill for senior software engineers to succeed, especially at FAANG and Big Tech in general.

**Update:** Playlist are now shipped within Taro! Try it out and see how the system design in this video brought this feature to life by visiting the full playlist for the series here: [System Design Masterclass: Taro Playlists](https://www.jointaro.com/playlist/dChIyTQcu2Ct5VC70lki/)

Core points from the video:

- System design interviews are more analogous to your actual job than data structures and algorithms, but there are two big gaps:
  - **Overly grandiose exercises** - You will never get a technical problem on the scale of "Build all of Netflix", especially if you work at a Big Tech where you will get something much more local. Most of the biggest problems at these companies are already solved due to their maturity and plethora of software engineering talent.
  - **Time constraint** - Because interviews are time-boxed to 45 to 60 minutes, you have to do very broad strokes. In real life, system design should be much more thorough and has more steps and technical writing.
- To make this series as authentic as possible, we are going to be breaking down an actual upcoming feature within Taro: Playlists! On top of this:
  - This system design is exactly how Alex would design a system if he were still at Meta/Robinhood as a tech lead. While Taro doesn't need something this granular as a startup, this series simulates many aspects of a more mature company.
  - Alex has made a very thorough 9-page system design doc going through every aspect of the system.

Having The Proper Mentality For Manager 1 on 1s

True or false: Your manager is your superior, so it is on them to ask the right questions and figure out what you need in your 1 on 1 meetings. You just need to show up on time.

Why is the burden on you to set the agenda and overall plan with your manager 1 on 1s?

True or false: It is better for your career growth to view your manager as being a resource for you instead of you being a resource for your manager.

True or false: A good manager 1 on 1 involves you giving status updates and then waiting for instruction on what to do next.

- *Your manager is a resource for you.*
- Don't just see your manager as a source of authority that gives you work. While this is true to some extent, having this mentality really holds back your growth.
- Go into your manager 1 on 1s with a plan on how you can extract the most value from them.
  - This onus is on you to set the agenda for this meeting, so you can get insights from your manager on how to best improve yourself. Let them know about this agenda beforehand, so they can think about how to best help you with each point.
  - Another way of seeing this is how can you make your manager's life easier. By setting the stage for your manager, you lower the barrier for them helping you as they don't need to figure out exactly what your work life looks like and what problems you have.
- A common failure mode for earlier-in-career engineers going into manager 1 on 1s is they go in, give a status update on what they're doing, and wait for more work to be given to them.

Related resources:

- [\[Masterclass\] How To Have Impactful 1 on 1 Meetings](https://www.jointaro.com/lesson/FEK6JZqW2Jg3rdN9yeGn/masterclass-how-to-have-impactful-1-on-1-meetings/)
- [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)

Struggling With DSA? Don't Worry, That's Healthy!

True or false: Interviewing is all about how much you know. As long as you study a lot and understand enough material, you will pass the interview.

For almost everyone, what does the learning curve look like for data structures and algorithms?

True or false: It's completely normal and even a good sign when you feel dumb while studying data structures and algorithms.

What's the most important piece when you're learning data structures and algorithms material?

True or false: If you aren't making progress on data structures and algorithms after 2 months, your mind probably just isn't geared to understand them. At that point, you should be practical and just look for interviews that don't have these kinds of problems.

Mastering data structures and algorithms (colloquially known as "DSA") is a frustrating experience: It requires such a different type of thinking and is rarely required on the actual software engineering job. This is why if you want to get good at DSA, you need the right mentality first.

Here are the core points from the video:
- DSA learning is an exponential process. You are going to be terrible initially, and eventually things will start to "click" once you hit the inflection point.
- When you feel dumb, understand that this is completely natural: This is almost a good thing as it's entirely expected.
- DSA is very much an input-driven exercise. Build a good process around studying it regularly and commit to it. With constant persistence, you will eventually get to where you want to be!

Related resources:
- [[Taro Top 10] Effective Interview Prep](https://www.jointaro.com/playlist/HLBYxJI7D1j8STolrwum/)
- [[Taro Top 10] Finding A Tech Job](https://www.jointaro.com/playlist/E6R0wVJ5EyCfVnVrlfno/)

Having The Proper Mindset For Interviews

True or false: You need to care a lot about your Big Tech interview, because passing it will drastically improve your life. The more prominent it is in your brain, the more likely you are to pass.

True or false: Your input is much more important than the output and results you achieve.

Why should you not view interviews as a test?

True or false: You shouldn't take any breaks when studying for interviews, because the relentless focus will help you learn the material better.

- *The more you care about your interview, the less likely you are to pass it.*
- Interviews are all about maintaining a nimble, flexible state of mind, so you can react gracefully when hit with a problem you haven't prepared for. This will almost always happen on interviews with tougher companies.
- If you view your interview as a "make or break" opportunity (which it admittedly very well may be) and go into it with a lot of anxiety, you will not have that healthy state of mind. When your interviewer goes off-script, your mental state will likely shatter.
- View interviews as a chance for you to go in and learn from some very smart people, and if you happen to get a job offer, that's a nice bonus. This much more relaxed and positive mentality will reduce your anxiety.

Related resources:

- [\[Taro Top 10\] Finding A Tech Job](https://www.jointaro.com/playlist/E6R0wVJ5EyCfVnVrlfno/)
- [\[Masterclass\] How To Ace Your Big Tech Interview - System Design](https://www.jointaro.com/lesson/J3I9fTW9ulr6T9KjxpqY/masterclass-how-to-ace-your-big-tech-interview-system-design/)

2 Ways To 100x Your Productivity That Nobody Does

What are the 2 underutilized but straightforward ways of becoming far more productive?

True or false: Often times you should sacrifice sleep and exercise in order to get more hours, thereby becoming more productive.

Why is it absolutely necessary to get in good sleep and regular exercise no matter what?

- The 2 core pillars of productivity are a consistent, good night's sleep and regular exercise (3-5 times a week).
- "I don't have time for that" is not a real excuse. There are thing you *make* time for. Nobody says they stopped brushing their teeth to become more productive: That is an example of something everyone makes time for. Sleep and exercise are the same way.
- The math doesn't check out for sacrificing these. It doesn't matter if you have more hours in a day from doing this if your rate of getting things done is very low. And it will be low if you are constantly sleep deprived and not physically fit.

Effective Communication Guide [Part 1] - Core High-level Principles

Software engineers are notorious for their poor soft skills, often thinking that being able to write decent code while isolated in a corner is all they need to succeed. This couldn't be further from the truth. Communication in particular is crucial for software engineer career development, especially to senior and staff level. This lesson teaches you:

- **Communication is fundamentally an exercise in empathy** - The entire goal of communication is to align with or win over another human being in some way.
  - Strive to put yourself in the shoes of the person you're communicating with. Try to see the world through their eyes.
  - What are their values? What makes them happy? What are they struggling with? What do they care about? What's their background?
- **Understand others' incentives** - This is especially important in a corporate environment where every employee has some incentives they're pursuing. This will often times manifest as what are the values of the other person's org and even more concretely, *what they get rewarded for in performance review*.
- **Over-communication &gt;&gt;&gt; Under-communication** - Under-communication's downside is that people are not aligned, which usually leads to lots of thrash and wasted work. That is much, much worse than the failure mode of over-communication, which is that you're a bit annoying (and this can be easily toned down and fixed). If you're trying to get better at communication, push for the over-communication extreme: Chances are, you will never reach it. It is *very rare* for someone to be communicating too much - Most people will appreciate the increased availability of information.

Related resources:

- [The Crucial First Step To Building Relationships That Everyone Misses](https://www.jointaro.com/lesson/YPniDFNQqoHEpYHC9JEq/the-crucial-first-step-to-building-relationships-that-everyone-misses/)
- [Stop Getting Ghosted With Your Reachouts - How To Write A Great Cold Message](https://www.jointaro.com/lesson/eZRHXEpxdJjcxK2aQTWl/stop-getting-ghosted-with-your-reachouts-how-to-write-a-great-cold-message/)
- [I Sucked At This For 25 Years As An Engineer – 8 Tips For Communication](https://www.jointaro.com/lesson/s0vZkFtwe3x4tALbdbEr/i-sucked-at-this-for-25-years-as-an-engineer-8-tips-for-communication/)

The #1 Thing You Need To Know About Promotion In Tech

True or false: To get to very senior engineering levels, you need to write thousands of lines of code per day.

Why is output not as important for promotion?

- *Promotion is about behavior, not output*
- Raw output doesn't scale. You only have so many hours in a day, and your hands can only physically type so many lines of code per minute.
- Senior engineers can have 10x to 100x the impact of a junior engineer. In order for them to do this, they need to add deeper types of value to the business.
- That deeper type of value comes from behaving in a fundamentally different way to more junior levels. In particular, engineers at these very senior levels add multiplicative value instead of additive value. An example of this is a senior engineer empowering many others to write code instead of just writing the code themselves.

Related resources:
- [[Taro Top 10] Time Management And Productivity](https://www.jointaro.com/playlist/5WA87nbbYJWLnQ60D826/)
- [[Masterclass] How To Get Promoted Faster In Tech](https://www.jointaro.com/lesson/W730BOdrfAIXAEVd8HUf/masterclass-how-to-get-promoted-faster-in-tech/?playlistId=eZOEUatYEe7BBAZByuha) - The full video where this clip is from
- ["How to improve at multi tasking at work?"](https://www.jointaro.com/question/ION8KZHyA8fNWOpHDhZI/how-to-improve-at-multi-tasking-at-work/)

What's the Difference Between A Senior And Staff Engineer?

The mark of someone who is NOT ready to be a staff engineer: Asking what needs to happen to get to staff.

A staff engineer should identify problems worth solving, and then get buy-in across the org to solve the problem.

- Despite each staff engineer's journey being different, there's still an opportunity to learn from the examples of other promotion cases. Here's an example from Rachel's days at Yelp with a talented staff engineer:
  - Google announced an algorithm change for SEO ranking, which would favor websites with better mobile friendliness.
  - An engineer on a feature team recognized that this would hurt Yelp and brought it up very proactively.
  - They drove a proposal and broke down the problem with several domain experts in the organization.
  - It took a while, but they were able to ship a quality, long-term solution.
- Instead of just looking at "what" new problem to solve, there's also opportunity for very senior engineers to breakdown the "how" to accomplish a large, ambiguous problem and get to staff.

If you enjoyed this video, you can watch all of Rachel's other Taro videos here: <https://www.jointaro.com/topic/rachel-zhao/>

For more resources on getting to staff:

- ["How can I come up with big initiatives, especially those at a Staff level?"](https://www.jointaro.com/question/c3LcBDXEcxA85y9jlFjz/how-can-i-come-up-with-big-initiatives-especially-those-at-a-staff-level/)
- ["For a Staff engineer at a Big Tech company, what should their first 3-6 months look like?"](https://www.jointaro.com/question/X8QYtxzD7SXdzMfcnBiX/for-a-staff-engineer-at-a-big-tech-company-what-should-their-first-3-6-months-look-like/)
- ["How do I come up with innovative, impactful ideas and bring them to my team?"](https://www.jointaro.com/question/3QIJhAT4loA7n1hSfCuw/how-do-i-come-up-with-innovative-impactful-ideas-and-bring-them-to-my-team/)

The #1 Rule Of Negotiation - How To Avoid Giving A Number

- Negotiation is a dance: Know your role within it and have a script.
- There's an asymmetry here:
  - Recruiters are talking to candidates and negotiating every day. They come in very prepared and have a script.
  - You will change jobs every 2-3 year - It's a rare event for you to have this conversation. To level the playing field, you should have a script too.
- If they ask for a number or range, say *"I'm more concerned with understanding if this opportunity is right for me."* This is polite while positioning yourself in a mutual respect scenario.
- If they refuse to move forward within a number, you can try:
  - "What are typical compensation bands for this role?"
  - "I'm a strong performer in my current role and expect to be promoted soon, so I'm not sure what's fair."
- If they require a number, put a placeholder and say you'll get back to it later
- Asking for a number is generally a predatory way for companies to take advantage of candidates and lowball them.
  - This is why in California, it is illegal for employers to ask your prior compensation information

Related resources:

- [\[Course\] The Insider's Guide To Negotiating Your Tech Salary And Compensation](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/)
- [3 Quick, Powerful Negotiation Tips](https://www.jointaro.com/lesson/8VeEnbxdbPKsZbTcCFm5/3-quick-powerful-negotiation-tips/)
- [How To Negotiate A Raise At Your Current Job](https://www.jointaro.com/lesson/wQ4o4UeSTu9oJDtdH75H/how-to-negotiate-a-raise-at-your-current-job/)

Asking Effective Questions That Get Great Answers Quickly

What are some things you can do to improve your question?

True or false: Ideally, your question takes less time to answer than it took for you to ask the question.

What is the core operating principle behind asking and answering questions?

True or false: In order to be polite, you should preface your question with a simple greeting like "Hello". After the potential answerer responds, then you can ask your question.

Why do you need to attach a lot of context and be as specific as possible asking questions in tech?

- **Core principle**: Questions are an exchange of time. You put some time to write your question and the answerers take some time to respond. Your goal is to make the amount of time necessary to answer your question smaller than the amount of time you spent asking it.
- Have empathy for the people answering the question. Thank them pre-emptively!
- Avoid leading "hi". Just ask them your question directly!
- Google your question and go through the initial results prior to asking your question. Inline that context in your question.
- Attach as much relevant context as possible. You want to prevent back-and-forth where answerers need to ask you questions to clarify your initial question.

Related resources:
- [Bad Question vs. Good Question Example](https://link.jointaro.com/fiY293kj2ewPwMqB8)
- ["How do you overcome the fear of asking stupid questions / bothering people when you need help?"](https://link.jointaro.com/37FJnTAX1BN2e5wt6)

Explaining Your Experience In A Meaningful Way On A Resume

Is this a good resume snippet: Worked on the SIVAD system, using Room, AndroidX, Activities, and Java

How do you make the experience portions of your resume stand out?

Is this a good resume snippet: Champion for unit test coverage for Cool Company's iOS app, increasing it by 20% and reducing the amount of new iOS user issues by 10%

What is the main way people struggle with their resumes?

Is this a good resume snippet: Led the JavaScript migration effort with strong communication, architectural, and code quality skills

- The most common way resumes struggle is that they tell instead of show
- Here's an example:
  - **Telling:** Added unit tests to the Android app with JUnit and Java
  - **Showing:** Increased test coverage of the Android app by 80%, which reduced bug tickets from users by 50%
- In a nutshell, don't just say what you did - Adding an adjective like "great" doesn't automatically make your feat impressive. Prove that you did something great by talking about how you did it and the actual result (which is ideally business impact).
- This method of communication is especially important for resumes as their audience is mainly non-technical: Recruiters. They aren't going to understand the more specific tech buzzwords. You need to write things in more "plain English", so that your accomplishments can be understood as impressive by almost anyone.

Related resources:

- [\[Course\] Get More Interviews: Write A Stellar Resume As A Software Engineer](https://www.jointaro.com/course/get-more-interviews-write-a-stellar-resume-as-a-software-engineer/) - By taking the course, you get access to Alex's most recent resume!
- [Your Tech Resume Should Look Boring](https://www.jointaro.com/lesson/WFJYebwJW2rhviTrQrB3/your-tech-resume-should-look-boring/)
- ["What high-impact achievements should a full-stack engineering intern target for a stronger resume?"](https://www.jointaro.com/question/cnEgJuQMKI3G4rqhEkp4/what-high-impact-achievements-should-a-full-stack-engineering-intern-target-for-a-stronger-resume/)

[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 this video: [This Is How Software Engineers Should Initially Learn](https://www.jointaro.com/lesson/wUl3hc2wr1ms493bd23b/this-is-how-software-engineers-should-initially-learn/)
- **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 as we talk about in this discussion: ["How will side projects enhance my skills as a software engineer on the job?"](https://www.jointaro.com/question/KORArGLRW6mNn47ddC1S/how-will-side-projects-enhance-my-skills-as-a-software-engineer-on-the-job/)
- **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, watch this: [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/)
- **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. If you're having trouble getting your code reviewed fast, follow the advice here: [Quick Tips To Get Higher Quality Code Reviews Faster](https://www.jointaro.com/lesson/QgDk2yWlfWzgLjh56bSq/quick-tips-to-get-higher-quality-code-reviews-faster/)
- **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: ["How can I be better at executing on my work when it comes to coding and breaking down ambiguity?"](https://www.jointaro.com/question/6lfyIKgkoclcDNKWq9o3/how-can-i-be-better-at-executing-on-my-work-when-it-comes-to-coding-and-breaking-down-ambiguity/)

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)

How To Get Real Feedback So You Can Actually Improve

Core points:

- Let the other person know that you treat all feedback as a gift and really appreciate constructive criticism.
- Schedule a 1:1 with crucial people in your org/team to get feedback. It can be every 1 to 3 months. Make it clear that it's a feedback meeting.
- It's important to understand the feedback giver's perspective. Nice people, those you are (hopefully) working with, are going to hold back often by default to shield you. This is why you need to make it clear that you really appreciate honesty and transparency.
- Feedback is crucial towards promotion.

Related resources:

- ["I got some pretty "unspecific" feedback. How can I sharpen it to make more actionable?"](https://www.jointaro.com/question/gKsY3J4x5rz2zdG2OXYJ/i-got-some-pretty-unspecific-feedback-how-can-i-sharpen-it-to-make-more-actionable/)
- ["I work in a small company with no formal perf review system - How can I get feedback to improve?"](https://www.jointaro.com/question/ZkjOqjW2ou4LhJ0HyIIK/i-work-in-a-small-company-with-no-formal-perf-review-system-how-can-i-get-feedback-to-improve/)
- ["How do I find a proper mentor within my company?"](https://www.jointaro.com/question/53nM0O5iemQD5K5ZQkYE/how-do-i-find-a-proper-mentor-within-my-company/)

Noob Software Engineer vs. Pro Software Engineer

The best software engineers proactively front-load the work to write clean code. They do this by planning ahead to find the best approach and taking the time to "dress up" their code review really well.

Here are the core points from the video:
- **Noob Engineer** - Their goal is just to get the code to work. As soon as they get the happy flow functional, they submit the code for review. Their pull request doesn't have good context attached, and the test plan isn't thorough at all. They have to go through many revisions of teammates rejecting their code before they can finally land the commit. After it's landed, there's a high chance it breaks, and now they have to go back to their code to patch it up (or hard revert it).
- **Pro Engineer** - They come up with a plan to implement the best approach and vet it with their teammates. They make sure the code is polished and covers edge cases thoroughly before submitting the pull request. Their PR clearly explains the purpose of the code and has a very detailed test plan demonstrating what it does. Their teammates quickly and smoothly read their code and accept it on the first try. The pro engineer is able to land their commit shortly after submission, and the entire process was smooth for everyone. The pro engineer's reputation within the team grows with every masterful commit they push to production.

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:
- [One Diff, One Thesis - What Every Code Review Should Be Like](https://link.jointaro.com/5Ehehxt6jBR42ui1A)
- ["What can I do to quickly build my reputation as a junior engineer?"](https://link.jointaro.com/hxCTvumsQhUqRAbn6)

How The Best Software Engineers Learn A Tech Stack - The Lego Model

- "The Lego Model" is a way to view the world and understand your learning journey as a software engineer.
  - Technical components (e.g. rendering a list of items) are the individual legos
  - Complete products (e.g. a food delivery app) are the full lego creations
- There are 3 axes to evaluate your legos:
  - **Quantity:** How many you have
  - **Quality:** How good and sturdy your legos are
  - **Commonality:** How "in demand" your legos are (i.e. how many creations they can fit into)
- Most earlier-in-career engineers understand the 1st axis of quantity and incorrectly spend a lot of time learning different tech stacks and frameworks.
- Those same engineers often don't even realize the 2nd and 3rd axes exist:
  - When they learn a component, they will build it out with very low quality.
  - They will learn "flashier" components that aren't even used by most products/companies.

For examples on how to excel at the 2nd and 3rd axes, check out the related resources below!

Related resources:
- [[Masterclass] How To Learn Quickly In Tech](https://www.jointaro.com/lesson/u9ldIvrTvV1wfWExccDR/masterclass-how-to-learn-quickly-in-tech/) - The full video this clip came from
- [This Is How Software Engineers Should Initially Learn](https://link.jointaro.com/iVBpCaB6pAHivhdi6)
- [Building Software For Optimal Learning Example - Login Flow](https://link.jointaro.com/oEkTB3pskKH6JHCX6)

1 on 1s Are The Time To Be Awkward

Why should you be awkward and even a little bit uncomfortable in 1 on 1 meetings?

True or false: 1 on 1 meetings are great for staying in sync, so status updates are one of the best things you can talk about during them.

Which of the following are good things to talk about in 1 on 1 meetings?

The 1 on 1 meeting is one of the most important usages of time in the workplace. Even the most junior engineer will generally have at least a 1 on 1 meeting series with their engineering manager. However, 1 on 1 meetings are often completely wasted by software engineers - Here's how to avoid that.

Here are the core points from the video:
- 1 on 1 meetings are the most inefficient way to communicate anything that is non-controversial
  - The main culprit here is detailed status updates. If you're using the majority of the time to share these and talk tactics, you are doing 1:1s wrong.
- The most effective way to leverage 1:1s is to talk about things that are *awkward and maybe even make you uncomfortable*. Here are some examples of "awkward" topics:
  - Feedback to improve
  - Emotions (both positive and negative)

Related resources:
- [Having The Proper Mentality For Manager 1 on 1s](https://link.jointaro.com/p8ysLGYUj7KhoGND7)
- [Effective Communication Guide](https://link.jointaro.com/kWQkRyRhLqbTWBty7)
- [The Art of the Awkward 1:1](https://medium.com/@mrabkin/the-art-of-the-awkward-1-1-f4e1dcbd1c5c)

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.