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

How To REALLY Level Up Your Coding Ability With Side Projects

There is no secret to getting better at coding: As a software engineer, you will become faster at coding when you write more code. This is where side projects can really come in.

Here are the core points from the video:
- **Side projects are a productivity "hack"** - They allow you to write more code without overworking yourself. The self-guided, free nature of side projects essentially make them a hobby that also helps your performance at work.
- **When to consider side projects** - There are 2 factors that make this lever far more powerful:
  - You work at a startup: Startup code will be much more "vanilla" and closer to the code you find online. This means that it won't be too different from side project code.
  - You work on the front-end: If you're a web/iOS/Android developer and are working with pixels on screen, this puts you in a great position to do side projects as your work is inherently more sharable.
- **Side projects develop other important skills** - On top of raw coding, side projects also help you dabble in the skills of product managers, designers, data scientists, user researchers, and a whole lot more since you own the product entirely. These skills are also important for software engineers, especially those pursuing senior levels.

This highlight is from our masterclass about becoming a better coder. You can watch the full video here: [[Masterclass] How To Write Better Code Faster As A Software Engineer](https://www.jointaro.com/lesson/iYpRj8XfyzCSaTYnce3y/masterclass-how-to-write-better-code-faster-as-a-software-engineer/)

Related resources:
- [[Masterclass] How To Come Up With 100k+ Users App Ideas You Can Build For Free](https://www.jointaro.com/lesson/AI4zi759PSGn6RwIFT6f/masterclass-how-to-come-up-with-100k-users-app-ideas-you-can-build-for-free/)
- [[Masterclass] How To Build And Grow Tech Products To 500k+ Users For Free](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/)
- ["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/)

System Design Series: Taro Playlists [Part 4] - Covering Edge Cases

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

- You should *always* at least try to cover all the edge cases when building out a product, even if you're a small startup.
  - If you're at Big Tech in particular, you absolutely need to have amazing coverage on edge cases as even an issue affecting just 1% of users could be breaking the experience for 10 million+ people.
- A lot of edge cases are quite easy to cover and are low-hanging fruit. Bad engineers will be lazy and ignore these, supposedly in the name of velocity.
  - **Example:** You have a login form that takes in email. Instead of no-oping, throwing a generic error, or letting them login with an invalid email, validate the email upon submission and show an error message if it's invalid. This will almost always be a 5-10 minute change.
- There's many "playbooks" of edge cases, so coming up with edge cases isn't rocket science - It's largely a solved problem. Here are some examples:
  - **Generic edge cases that apply to any user input:**
    - Input is blank
    - Input is overly long
    - Input is very strong
  - **Generic edge cases that apply to any content collection:**
    - No content
    - A lot of content
    - Content fetch fails
- *Being very diligent around edge cases is also crucial for interviews, both DSA and system design, and is often how Big Tech interviewers differentiate the great candidates from the mediocre ones.*

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

Growing To Meta Tech Lead And Then Entrepreneurship - By Jocelin Ho

If you use WhatsApp web, level up your experience with the Cooby (the company Jocelin is cofounder and CTO of) plug-in: [Cooby: Best WhatsApp Extension for Work](https://chrome.google.com/webstore/detail/cooby-best-whatsapp-exten/hcikfoejbgdmajlbhadhfchoekcoablm)

To level up your software engineering knowledge, follow Jocelin on LinkedIn: [Jocelin Ho - LinkedIn](https://www.linkedin.com/in/jocelinho/)

Jocelin's presentation is **filled** with gems (including a fun video by Mark Zuckerberg), so we're just going to share her core learnings here:
1. **You need to be versatile to survive** - One of the biggest misconceptions about software engineering is that it's mostly about writing code: This couldn't be further from the truth. In order to be a genuinely stellar engineer, you need to have a vast array of skills on top of coding like communication, the ability to smoothly process feedback, multi-tasking, and much more. Jocelin excelled at developing these skills, which is why she was able to get promoted from E3 -> E4 at Meta (junior -> mid-level) in just 6 months, faster than 95% of FAANG engineers.
2. **Don't get emotionally attached to what you built** - Tech is always fast-moving and chaotic, and this is accentuated when you work at a top company like Meta. Organizational priorities change all the time, and this can mean that your hard work gets thrown out. Don't take it personally and continue striving to deliver impact and grow.
3. **Don't be afraid to take the leap** - You will literally never be ready for that big career or life change, whether it's taking your first FAANG interview, switching to management, or starting your own company. Once you have conviction in knowing what you want to do, make that jump and focus on growing and adapting as fast as possible. It's not about where you are now but rather where you can go in the future.
4. **Live up to your own expectations instead of others'** - While we should always try to add value to other people's lives and help one another, this doesn't mean we should derive our happiness from what they believe we should be. You own your own happiness - Set goals that are both feasible and exciting for you and ignore all the noise. This is especially relevant in tech where there's so many brilliant people, and it's tempting to compare yourself to others.

Related resources:
- ["What's the core insight behind quick growth?"](https://www.jointaro.com/question/nJ762p255cGyuth36H6w/whats-the-core-insight-behind-quick-growth/)
- [[Taro Top 10] Junior Engineer To Mid-Level Engineer (L3 To L4)](https://www.jointaro.com/playlist/iBKHYpkjd0BRWWLKQG2j/)
- [Presentation slides](https://docs.google.com/presentation/d/1BkaaiKQXXx6eUi5heaNiNmPgBriK9rr5UdTfHfd2K5k/edit?usp=sharing)

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)

What Software Engineers Don't Get About Clean Code

Back at Instagram, Alex was able to grow very quickly. This was largely due to his coding ability. In his 1st half at Instagram, he pushed \~125 commits to production. In his 2nd half, he pushed \~185 commits to production. In his 3rd half, he pushed \~275 commits to production, making him a Top 5 code committer within his org of 50+ software engineers.

Here are the core points from the video:

- **You don't need to sacrifice quality for velocity** - This is one of the biggest misconceptions about code. You can both write a lot of code while keeping the polish high. In fact, high code quality and velocity naturally go hand-in-hand.
- **Messy code is a defining trait of a weak SWE** - 99% of bad software engineers have poor code quality, and conversely, you will rarely meet a high-performing software engineer that puts out messy code. Optimizing your code quality is one of the most powerful ways to avoid being a low performer, especially if you work at FAANG or Big Tech in general where the scale and stakes are much higher for code.
- **80/20 rule applies to code quality** - It usually doesn't make sense to cover 100% of edge cases, but you can generally cover \~80% of them with \~20% of the maximum effort, even if you're a tiny startup. Don't make excuses for broken, unreadable code by saying "We have to move fast"; strive to find that 80/20 path.

Related resources:

- ["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/)
- ["How can I write great code faster?"](https://www.jointaro.com/question/ciE9a2TZ7rZNyYP8HbeJ/how-can-i-write-great-code-faster/)

The Real Pros And Cons Of Working At FAANG And Big Tech

Working at FAANG and Big Tech is general is put on a pedestal by the vast majority of the industry, but it's not all sunshine and roses. Here's the complete pictures:
- Pros:
  - **Prestige** - If you don't already have one of these names on your resume, adding one makes it 10x better automatically.
  - **Compensation** - This one is the most obvious: These companies pay extremely well.
  - **Consistent foundation** - The biggest one is the learning, especially for earlier-in-career software engineers. It is hard to go into these companies, do well there for a couple years, and not come out as a significantly better engineer. You will get more consistency by setting a baseline for your compensation and level.
- Cons:
  - **Hard to find scope** - In particular, growing to senior can be difficult. So many of the hard technical problems at these companies are already solved, and there are thousands of super talented software engineers looking for scope as well.
  - **You're just a cog in the machine** - At FAANG, you are one talented engineer out of literally 10,000+. The majority of engineers will be doing very incremental work that doesn't feel very fulfilling - There are literally engineers whose job it is to optimize a single button. This is all very connected to the aforementioned con of not being able to find scope.
  - **Work-life balance is dicey** - These companies pay you well for a reason: The bar is high. It can be stressful and tiring to meet expectations, especially if you're transitioning from a non-FAANG company.
- It's also important to remember that you need a much more holistic set of skills on top of coding most of the time to succeed at these companies. For many, this is a pro as it leads to more well-rounded growth, but for others who want to focus more on being builders, it can be incredibly draining.

For a deeper look into what life at FAANG is actually like, join us for our upcoming event: [Should You Work At FAANG? - What Big Tech Is Like For Software Engineers](https://www.jointaro.com/event/should-you-work-at-faang-what-big-tech-is-like-for-software-engineers/)

This clip was taken from our [1.5 hour masterclass on finding the best company/team for you, which you can click here to watch](https://link.jointaro.com/F4DDyKfuo3hMhj868).

Related resources:
- [Why You Should Start Your Career At A Big Tech Company](https://link.jointaro.com/9k3HkgfJsTp1Nd2w5)
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://link.jointaro.com/n57gbTWERveGTQuM9)

Grow From Senior To Staff Engineer [Part 2] - Why Is The Staff Promotion So Hard?

Countless senior engineers hit a wall as they push for staff. This lesson teaches you:

- How the Staff Engineer role in and of itself is special by being a relatively new career invention
- The easiest way to tell if a Senior Engineer isn't ready to become a Staff Engineer
- Why the Staff Engineer promotion is fundamentally different from prior promotions
- Why many teams can't support an additional Staff Engineer promotion
- How you can be performing as a Staff Engineer and still not get the promotion

[Become A Go-To Person 1/18] How This Course Works

A course by [Jordan Cutler](https://www.linkedin.com/in/jordancutler1/), Senior Software Engineer at Pinterest and Author of the [High Growth Engineer Newsletter](https://read.highgrowthengineer.com/)

DSA Crash Course [Part 5] - Is Prime Walkthrough

In this lesson, Alvin walks through the python implementation for the *is_prime* problem.

Code along and test your work in the following editor workspace: <https://structy.net/problems/is-prime?language=py>

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

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/)
- ["Negotiation - done via phone call or email? Modes and stating a number?"](https://www.jointaro.com/question/ggYVsodBllba5RmYrOtv/negotiation-done-via-phone-call-or-email-modes-and-stating-a-number/)

Become An Open Source Master [Part 2] - How This Course Works

We'll explore the benefits of open source and how to contribute to existing projects in this course.

- Understand the benefits of open source and the mindset needed to work effectively in the open source ecosystem
- Learn how to get involved in someone else's project, understand their codebase, and make meaningful contributions
- Explore how contributing to open source can benefit your career by showcasing your skills and building your professional profile.
- This course won't cover how to create your own open source project or what it's like to work on one from within a company.

Connect with James: 

- GitHub: <https://github.com/jamesgpearce>
- Twitter (X): <https://twitter.com/jamespearce>

One Diff, One Thesis - What Every Code Review Should Be Like

In this segment, we focus on the powerful practice of **“One Diff, One Thesis”**, along with a recap of three foundational principles for writing high-quality diffs. These habits dramatically improve your velocity, code quality, and perceived maturity as an engineer—especially early in your career.

### Key Takeaways:

- **We follow the “One Diff, One Thesis” principle**: Each code change should focus on a single, clearly defined purpose. Large, unfocused diffs (e.g., 5,000+ lines) dilute review quality and lead to blind approvals or unclear feedback.
- **We break big features into smaller, stackable diffs**: By submitting changes in 50–250 line chunks with logical dependencies, we keep discussions focused, reduce cognitive load for reviewers, and maintain a clear project history.
- **We pay the “20-minute tax” for high-quality diffs**: Investing time in writing strong context, test plans, and clear, focused diffs pays off by dramatically speeding up approvals and reducing iteration cycles.
- **We see these habits as promotion-worthy**: The most common reason junior engineers struggle during performance reviews is neglecting these basics. Conversely, those who consistently apply them stand out and accelerate their growth.
- **We optimize for long-term velocity and trust**: Thoughtful, well-structured diffs help reviewers engage more quickly and confidently, enabling faster delivery and demonstrating leadership-level attention to detail.

These three practices—**providing strong context, writing solid test plans, and submitting focused diffs**—are low-effort, high-return habits that every engineer, especially early in their career, should master.

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

Nail Your Promotion As A Software Engineer [Part 2] - You Can’t Job Hop To Success

A lot of software engineers give up way too easily when they're faced with substantial career resistance. You can't achieve that much genuine growth when you're constantly hopping around, and this reflects in both your level and compensation. This lesson teaches you:

- Why most engineers hit a wall when solely trying to job switch their way into higher levels, especially at senior and staff
- The defining trait of engineers who make it to incredibly senior engineering levels (Staff+)
- How to become a 10x engineer (i.e. Staff+ at a top company)
- Why it takes so long to truly settle into an organization and be able to demonstrate L6+ impact and behaviors

If you're interested in the 7 levels playlist, here it is: [Asking 7 Levels Of Engineers The Most Important Skill](https://www.jointaro.com/playlist/TnJFvWcvpUvFWLFjpY7X/) (here's the [combined YouTube video](https://www.youtube.com/watch?v=R1pg5kI0VI4))

Check out this discussion about the costs of being [perceived of being a "job hopper."](Perception of being a \"job hopper\"?)

Effective Communication Guide [Part 3] - Building Relationships

In order to succeed as a software engineer, you need people to like you. So how do you make that happen quickly? This lesson teaches you:

- **Relationships are all about trust** - The more someone trusts you, the more they will share with you, and the more effective your collaboration can become. The 1 on 1 meeting is the most mechanism to earn this trust.
- **Trust by default** - Trust is extremely hard to earn and very easy to lose. The best way to earn someone's trust is to give them a lot of your trust. This will trigger a response where they will strive to follow The Golden Rule, giving you more of their trust to make things balanced. For an example of trusting by default and earning trust lightning fast, check out [our deep dive into great mentorship here](https://link.jointaro.com/YdUM4JP89Sjh7ruv5).
- **Make small talk** - 2-5 minutes of small talk per 1 on 1 can go a long way. By talking about things outside of work, you are showing that you truly care about them as a person.
- **Be honest** - Tell it to people straight, and don't mince words. By showing that you're comfortable sharing what you're genuinely thinking, people will want to do the same. This is especially powerful when talking about problems.
- **Use humor and self-deprecation** - Everyone likes to laugh: It's a very human thing to do. Crack a joke here and there when you can. Self-deprecation is effective as it's safe (you are poking fun at yourself instead of someone else) and shows your humility.
- **Show thanks** - Don't take your colleagues doing great work for granted: Doing great work is always hard. There is really no such thing as giving too much thanks and making people feel too appreciated. *This is a severely under-utilized technique*. Giving heartfelt thanks is supremely powerful - You can turn someone's bad day into a good one.

A Powerful Tool For Software Engineer Productivity - Focus Blocks

So many junior software engineers don't manage their calendar well, and this especially hurts their ability to write code and finish tickets efficiently. Don't blindly go into every meeting, especially as a junior software engineer who is often not relevant to the meeting. Be deliberate with your calendar and establish focus blocks.

Here are the core points from the video:

- **So what is a focus block?** - It's a long, uninterrupted period of time for you to focus on a singular track of work. A true focus block should be 4+ hours, ideally an entire work day.
- **Why are focus blocks important for coding?** - Humans are naturally bad at context switching, so focus blocks are just important for productivity in general. Having a focus block allows you to enter a "flow state" where you rate of work ramps up over time and you get more and more into the groove. When it comes to coding in particular, the focus time is crucial as context switching with code is especially painful. It takes a while to deep back into a codebase when you return to a coding task, and there's also practical reasons like rebasing your local and setting up your build environment again.
- **How can I set up a focus block?** - The main "culprit" behind hurting your focus blocks is meetings. Be aggressive about shaving meetings off your calendar where you aren't a core player, especially if you're earlier-in-career. Group the remaining meetings you have onto certain days with the goal of freeing up 1-2 days entirely for coding. 1 on 1 meetings will be the easiest to move. For the meetings you do end up going to, [follow this advice to really participate and get maximum value out of them](https://www.jointaro.com/question/3E3SBCa59z5oDb7AEciw/i-struggle-to-come-up-with-things-that-add-value-to-a-meeting-what-do-i-say/).

Related resources:

- [\[Masterclass\] How To Manage Your Time Optimally In Tech And Achieve More Results](https://www.jointaro.com/lesson/rnX9EKpzc43TgGW9MozG/masterclass-how-to-manage-your-time-optimally-in-tech-and-achieve-more-results/)
- ["How do I optimize my sacred hour at work?"](https://www.jointaro.com/question/l8dzUVTu99CahofQsYAi/how-do-i-optimize-my-sacred-hour-at-work/)

DSA Crash Course [Part 22] - Linked List Intro Lecture

In this lecture, Alvin explains the basic structure of a singly-linked list.

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 3] - Defining The Requirements

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

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

- It's very important for engineers to clearly understand the requirements of the product as they need to build them.
  - A common failure mode is that the proposed requirements aren't technically feasible. It's important for engineers to call this out as early as possible, which is why it's a valuable exercise for them to really lay out in the requirements in their system design doc and overall process.
  - Very senior product managers may give broad strokes in terms of what the product should do. Another reason why this exercise helps engineers is that it's actually up to them to convert the high-level points from their PM into very concrete features and requirements.
- "Jobs to be done" is a mental framework championed by Kevin Systrom, the co-founder and initial CEO of Instagram. The idea is that every product is "employed" by users to do a certain "job" in their life. This is a very important thing to understand about a product and clarifying this serves as an intermediary step towards creating concrete requirements.
- Something that's missing from this document are designs - This is because Taro has no dedicated design support at this stage. At a more mature company (which you almost certainly work at as the viewer), you would have designs at this stage in the document (it can be its own section). For front-end products, you need to put pixels on screen at the end of the day, so it's crucial for engineers to have designs to really understand the requirements and provide concrete feedback.

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

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.