Level Up Your Code Quality As A Software Engineer [Part 11] - Case Study: Signup Form Edge Cases

So how exactly do you figure out the edge cases with a piece of software? Well, it's hard work, especially as the volume of edge cases scales up exponentially with the complexity of the underlying feature. This video will teach you:

- A process to think through edge cases step-by-step through the stack with an *incredibly* in-depth example covering one of the most classic features virtual every tech company ever has: The email and password signup flow
- Why Big Tech companies hire so many software engineers to build out seemingly basic CRUD applications (hint: They're not basic, not at all, and the signup form case study will prove that to you)

Level Up Your Code Quality As A Software Engineer [Part 7] - Code Quality Isn't Static

Things would be so easy if we could just copy-paste the tech stack of our favorite FAANG company and call it a day. The bad news is that this is a prime recipe for disaster. This lesson will teach you:

- Why there's no such thing as objectively "good" code and the primary vector stopping that (hint: It's the only resource that matters)
- The right mentality to have when improving your specific codebase in your specific situation
- How to think about your code architecture as it relates to scale

Level Up Your Code Quality As A Software Engineer [Part 6] - Embrace The Pain

A defining characteristic of mediocre software engineers is that they run away from problems in their code and avoid confronting hard problems in general. This lesson will teach you:

- Why (and how) you should embrace the pain if you truly want to write better code as a software engineer
- The process to follow to go from writing bad code to good code
- What it means to actually learn system design
- How to level up your technical understanding with an in-depth example from Alex's past about how he truly mastered a deep Android concept and applied that mastery to learn iOS development almost instantly

Level Up Your Code Quality As A Software Engineer [Part 5] - Fake "Clean Code" Shortcuts

A lot of software engineers want shortcuts: They want to find the optimal tech stack, programming language, and framework to slot into their code so it's automatically the best and they have conquered code quality. Unfortunately, that's just not how code quality works. This lesson will teach you:

- Why having truly good code quality is so, so hard and more about building up fundamental technical skills
- How to have a proper senior engineer mentality around "clean code" and how to extend a codebase
- Common fake "clean code" shortcuts that engineers desperately want to believe but ultimately aren't true (often stemming from obsession with FAANG and Big Tech)

Level Up Your Code Quality As A Software Engineer [Part 4] - What ACTUALLY Makes Code Good

Code quality is one of the most misunderstood topics in software engineering due to a combination of engineering laziness and misinformation. This video will teach you:

- What ACTUALLY makes code good and high-quality and why we're even software engineers to begin with
- How to have proper empathy for the end-user
- The common mistakes software engineers make when determining how good code is, including a very common misconception about how FAANG works
- The true value of clean code patterns and how they add value to the end-user instead of just being buzzwords (that can potentially make the code worse when used incorrectly)
- The #1 guiding principal when it comes to writing truly high-quality code

Level Up Your Code Quality As A Software Engineer [Part 2] - Code Quality = Engineer Quality

Want to make a ton of money as a software engineer? Get incredibly good at writing stellar, high-quality code. This lesson will teach you:

- Why software engineers who write the best code get paid more than everyone else, especially at Big Tech
- The most common trait of low-performing engineers and high-performing engineers (hint: It's about code quality)
- The incredible benefits of striving to write high-quality code and the toxic downsides of writing mediocre code

To dive deeper into the differences between high and low performing software engineers, check this out: ["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/)

Level Up Your Code Quality As A Software Engineer [Part 1] - How This Course Works

It is so easy to get completely overwhelmed as a software engineer with so many possible skills to learn. This video (and broader course) will solve that dilemma for you by explaining why *code quality* is the #1 skill for software engineers. Here are the core parts of the lesson:

- Code quality is the technical foundation that helps you learn every other necessary skill as a software engineer, both the technical and non-technical ones
- Your instructor [Alex Chiou](https://www.linkedin.com/in/alexander-chiou/) walks you through his extensive 10+ year Silicon Valley background across top companies like PayPal, Course Hero, Meta, and Robinhood, explaining how code quality was an integral part of his success (he was a Top 5% code committer + lander at Meta).
- We go through the objectives of the course. By the end of the course, you will:
  - **🔎** Understand what **good code looks like** (and *doesn’t look like*)
  - 🌱 Set up the right **growth mentality** around code quality
  - 💻 Learn how to submit a **quality pull request**
  - 🍝 Avoid common **messy code patterns** (and how to fix them)

If you want to learn how Alex built so many successful side projects with top reviews and 100,000+ users, check this out: [\[Case Study\] Building An App With 1,000,000+ Users To Get Into Facebook](https://www.jointaro.com/lesson/jly45Gx6qR1kqQwBmJEy/case-study-building-an-app-with-1000000-users-to-get-into-facebook/)

Level Up Your Code Quality As A Software Engineer [Part 12] - Break It Down

Software is scary, especially when you get big projects that require thousands of lines of code to implement. This lesson will teach you:

- The steps to turn any tough technical problem into something that's quite manageable (and even easy)
- Why decomposition is one of the important skills for a software engineer to have at all levels
- A framework to plan out your commits and create a crystal clear roadmap for your code
- How to decompose coding projects in a systematic way, demonstrated through an in-depth example covering a classic software flow: User login

Paper Reading - Attention is All You Need

Paper Discussion led by [Mandar Deshpande](https://www.linkedin.com/in/mandardeshpande1995/)

"Attention is All You Need" is a seminal research paper published by researchers at Google in 2017, introducing the Transformer model. The paper revolutionized natural language processing and machine translation by proposing a new architecture that relies solely on self-attention mechanisms, eliminating the need for recurrent or convolutional layers.

This paper and the Transformer model it introduced are crucial in the context of Large Language Models (LLMs) for several reasons:

- Parallelization
- Long-Range Dependencies
- Efficient Attention
- Mechanism Pre-training and Transfer Learning

We will be discussing the internals of the Transformer architecture which will help guide our journey into the LLM space.

Paper link - <https://arxiv.org/abs/1706.03762?ref=blog.oxen.ai>\
Event link - <https://www.jointaro.com/event/paper-reading-attention-is-all-you-need/>

Paper Reading - Gemini: A Family of Highly Capable Multimodal Models

Paper Discussion led by: [Akshika Wijesundara PhD](https://www.linkedin.com/in/akshika/)

Abstract: Google researchers recently unveiled Gemini, a ground breaking family of multimodal AI models capable of understanding and reasoning across images, audio, video, and text. The largest Gemini model, Ultra, achieved human-expert performance on several benchmarks and advanced the state of the art across a range of multimodal tasks.

In this paper reading, we will discuss key details from Google's paper introducing Gemini models. Topics will include:

- The Gemini model architectures and how they achieve cross-modal understanding
- Performance benchmarks and state-of-the-art results across text, image, audio, and video tasks
- Applications and use cases enabled by Gemini's multimodal reasoning
- Approaches to responsible deployment of large language models like Gemini

This paper provides a comprehensive overview of the exciting new capabilities of Google's Gemini project. Whether you're an AI researcher, engineer, or simply curious about the state of the art in multimodal AI, join us for an in-depth look at this new model family.\
\
Paper link: [**https://arxiv.org/abs/2312.11805**](https://arxiv.org/abs/2312.11805)\
Event link:  **[https://www.jointaro.com/event/paper-reading-gemini-a-family-of-highly-capable-multimodal-models/](https://www.jointaro.com/event/paper-reading-gemini-a-family-of-highly-capable-multimodal-models/)**

Behind the scenes of a $320K → $1.05M negotiation in Silicon Valley

[Yogi Sharma](https://www.linkedin.com/in/yogi1/), an early employee at Facebook, shares an epic story about negotiating a massive compensation increase from his offer at Uber while discovering his true worth in the process.

---

I am a mathematician and engineer at heart, and I hate negotiations. I want people to evaluate the value of my work and pay me accordingly.

That is the mindset I had before this negotiation with a big ride-sharing company that opened my mind to the possibilities of a different way of operating.

In this candid behind-the-scenes conversation, I will discuss the mindset, preparation, and tactics that went into a negotiation (for the role of a SWE) that started at $320k and ended at $1.05M.

Even harder than doing such negotiation was the decision to decline such a lucrative job offer. (Thanks to that decision, I ended up finding my current profession.) Towards the end, I will also share my rationale behind such a seemingly crazy decision.

If you feel you are doing the work needed for a promotion or raise, but don’t seem to get it, this talk is perfect for you. I used to be that person and struggled to get the rewards I thought I deserved. This negotiation changed me deeply, and I hope to share a few insights that would help you too.

Connect with Yogi Sharma: 

- LinkedIn: <https://www.linkedin.com/in/yogi1/> 
- Taro: <https://www.jointaro.com/p/yogi-sharma/>

Handling a PIP: The Ultimate Guide To Navigating A PIP

There are two options after a PIP: either the employee will remove all the doubts about the performance concern, or the employee will be terminated.

Your job as an employee is to judge your manager’s intentions. Your manager is the most important person in the PIP, and more generally, in your career. Many managers view the PIP as a formality before termination, and they’ve already given up on you. In that case, **you need to leave.** You don’t win any bonus points by "proving them wrong."

If the manager is responsive to your questions, provides constant feedback, and has a reasonable PIP plan, you may have a chance to succeed.

However, in the vast majority of cases, our recommendation is that you **must start looking for a** **new job.**

The biggest reason a PIP is not worth fighting is because **you want to work for people who believe in you**. This is critical for career success: you need someone who is unfailingly supportive of you, whether that's a friend, mentor, or manager. A PIP does not feel like support. In fact, it feels like the opposite. Your manager felt your performance was weak enough that they literally spent hours documenting how you fell behind, and then informed you in a legal manner.

The joke is that PIP should stand for “Paid Interview Period”, and that is honestly our recommendation for many tech workers who receive a PIP.

Here is the **PIP Evaluation Framework** in order to make the best decision once you’ve received the PIP. If 1+ of the following are true, you should **not** plan to have a long-term future at your current company.

- Your manager is uncommunicative or closed off
- The time horizon for the assigned work on the PIP is unrealistic (e.g. 1 week for a launch)
- The goalposts for the projects keep shifting
- The PIP work and your “normal duties” result in an unmanageable workload
- Your team is unsupportive

Conclusion: The Ultimate Guide To Navigating A PIP

Thanks for being part of this course! Here are the main takeaways:

- A PIP **does not** mean your career is over
- Make it easy to receive feedback
- You should (probably) start looking for a new job
- Don’t over-share information
- Discussions:
  - [I have been put in PIP. What should I do?](https://www.jointaro.com/question/i2RqeCiAQJ04eU1rp0eQ/i-have-been-put-in-pip-what-should-i-do/)

  - [Bouncing back after termination](https://www.jointaro.com/question/iDARmEmqYKlCIhzKIMNh/bouncing-back-after-termination-what-can-i-do-to-move-forward/)

  - [Advice on PIP with unsupportive team?](https://www.jointaro.com/question/93GBTJ73ayNLPY0sLuHz/advice-on-pip-with-unsupportive-team/)

PIPs and Interviews: The Ultimate Guide To Navigating A PIP

The PIP is as big a deal as you make it out to be. This is the key insight as you interview at other companies: **Don’t share information** **that hurts you.** 

In the same way that you wouldn’t share your previous salary or your compensation expeditions in the interview, you also shouldn’t share past performance struggles. You don’t get points for transparency. The thinking should be that you only share information if it helps you with the job interview. In particular, you should *never mention that you got PIP-ed*.

Instead, use neutral phrasing like “*I’m super excited about this company. I deeply resonate with the mission and people.*” Or *“The previous role wasn’t a good fit”*

Life After PIP: The Ultimate Guide To Navigating A PIP

One of the biggest concerns for anyone who has received a PIP is about how it may effect their future job prospects. The answer is, no, a **PIP does not need to follow you around**. You can (and will) find a fresh start and a thriving career if you want it. 

Remember, a PIP is about **both** employee and employer. When you change jobs, your employer is changing, so the situation leading to the PIP is very different.

As you reflect on your next role, it’s worthwhile to allocate some time to reflect: 

- Collect feedback from others: at the minimum, save a copy of your PIP and figure out what feedback there is transferable to another job.
- Collect feedback from yourself: Write down your reflections: what did you enjoy (or not) about your past work experience. What types of projects and people were fun for you?

Meta Manager Case Study: The Ultimate Guide To Navigating A PIP

This was an Engineering Manager at Meta who has put 20+ employees on PIPs throughout their career.

- PIPs come from a mismatch of a “square peg, round hole”

- PIPs should never be a surprise. PIPs get discussed with the skip manager and HR

- Designed to be achievable with effort

- Across 20+ PIPs, has never had anyone continue employment

- **Advice**: “Clarity is more important than agreement”

MongoDB Manager Case Study: The Ultimate Guide To Navigating A PIP

This was a manager at MongoDB who shared a specific story of putting one of their employees on a PIP.

- PIP delivered to people who needed a lot of handholding

  - “Problem presenters” instead of “problem solvers”

- PIPs are hard but not impossible. Goal is to help the employee overcome the situation and contribute to the health of the team.

- **Advice**: “Understand every single word in the PIP”

Meta Case Study: The Ultimate Guide To Navigating A PIP

This was a veteran engineer with more than 15 years of experience at other large tech companies before joining Meta.

- **Before**: Hired in as Staff Engineer \[**E6**\], brought in as a domain expert. Worked for almost 2 years before the PIP

- **During**: Not surprised based on rating trends. Main issue was code productivity, inability to use tooling such as version control

- **After**: Struggled with the PIP for a few months, then negotiated a severance package

Joining a company at too high a level is not good

If an employee's performance is subpar, it's better to act on that early, both for the employee and the team.

At a high level, your job is to lead the team and teach others. It’s ok if you don’t know the tooling, but you should not let that get in the way of landing code. Code output was poor.

Pinterest Case Study: The Ultimate Guide To Navigating A PIP

This was a non-engineer who had several years of experience before joining Pinterest.

- **Before**: 90 days after joining, was told they needed to improve

- **During**: “Completely blindsided” when placed on PIP at the 4 month mark. Goalposts kept shifting, didn’t receive feedback until 4 weeks later

- **After**: Took the termination after taking leave for interview prep

MassMutual Case Study: The Ultimate Guide To Navigating A PIP

This was a new grad engineer who joined MassMutual, a 100+ year insurance company in Massachusetts.

- **Before**: First job out of college, shared a project with another new grad engineer which lacked support

- **During**: Shocked to receive it (did not know what a PIP was). Told not to ask for help to test his velocity

- **After**: Chose to leave the company, since the manager lost faith

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.