The Core Principles Behind Writing Great Performance Review Feedback

- Don't procrastinate writing performance review feedback, especially for your peers! It's such a intimate, powerful thing, and if you truly enjoy working with your peers, they deserve meaty, thoughtful feedback from you.
- Keep it organized
  - Have clear sections. If your company has performance review axes, these can usually be used as your sections.
  - Use bullet points. People hate reading essays and paragraphs.
- Be concise: Use your word count efficiently and avoid repeating yourself.
- A lot of resume feedback applies to performance review as well. Use strong verbs, show the impact, and "Show, don't tell".

The Key To Avoiding The Performance Improvement Plan (PIP)

Getting hit with a performance improvement plan (otherwise known as a "PIP") is one of the worst things that can happen to you as a software engineer. This makes avoiding a performance improvement plan one of the most important things for you to do, especially in the currently layoff-rich economy.

Here's the core points from the video.
- Your performance review rating should never be a surprise: Regularly check in with your manager to figure out how you're trending to avoid the dreaded PIP.
- On top of asking for constructive feedback regularly, you shouldn't be afraid to ask every 2-3 months if you're on track to get the rating you want once the formal performance review happens. The clearest way this manifests is a hypothetical rating: *"Would you give me at least a [Meets Expectations] for my performance so far?"* This is the most powerful way you can stay in sync with your manager.
- Make it clear with your manager that you'll take any hypothetical rating with a grain of salt, so they're more comfortable giving it to you. If you're brave enough, you can even ask them to err towards the lower-end so you don't overset expectations.
- Keep your eye on the ball: Keep referencing the expectations plan you made at the beginning of the cycle and evolving it as necessary.
- Turn it up at the later end of the cycle. Humans have bad memory: It's unfair, but recency bias is huge. Try to land your bigger wins just a few weeks or months before the formal performance review process starts.

Related resources:
- [[Masterclass] How To Navigate Your Performance Review In Tech](https://www.jointaro.com/lesson/b0B8uqIAUnBLE10jJHJG/masterclass-how-to-navigate-your-performance-review-in-tech/) - This is the full video the clip was taken from
- ["What's the difference between a low performer software engineer and a high performer?"](https://link.jointaro.com/QHkWNXoJV5Y9VYvH9)
- ["How do I help my manager (who is also my mentor) be a better manager and mentor?"](https://link.jointaro.com/eG5c6usaJNY9wopP8)

Make Sure To Set This Up With Your Manager To Ace Your Performance Review

- Work with your manager to figure out which peers you should request feedback from at the end of the cycle: They may already have a bunch of peers in mind!
- Once you figure out these key peers, talk with them upfront about your goals, especially if they're ambitious and you're gunning for promotion. Work with them early to build this relationship, especially if they're more senior.

CRUCIAL Ingredient For Senior Engineer Performance: Assembling A Feedback Team

You can find the [full video on navigating your performance review in tech here](https://link.jointaro.com/Tp93kAUNoPwmFcmc9).

- Be deliberate about who you request performance review feedback from: Don't just go through your half or year without a plan here and just request feedback from those you happened to work closely with at the end.
- Work backwards from how you want to be perceived at the end of the performance review cycle. Figure out the picture of your performance you want to paint and come up with the bench of peers who can paint that picture for you. From there, strive to build deep relationships with those peers (for advice on how to do that, here's [our course on Effective Communication](https://link.jointaro.com/VReQtMPn7rPa3gUB7)).
- Make sure that feedback isn't duplicated: You don't want to waste your peers' time by having them write effectively the same thing about you.

Understanding How To Empower Your Manager To Get The Rating You Want

- Come calibration time (i.e. when managers and very senior engineers come together to calculate your manager), your manager is going to have to defend you to get the rating they're proposing for you.
- This is another reason why it's so important to have a clear expectations plan. By setting the baseline, your manager has a concrete anchoring point to argue your case, in particular when you have gone above and beyond the baseline.

Avoid This Performance Review Death Trap - Creating An Expectations Plan

- Work with your manager at the beginning of your performance review cycle to create a plan. Do this no matter what: Even if your goal isn't too ambitious and you just want to get an average rating.
- The plan should outline expectations for you very clearly, ideally as a checklist:
  - What does it mean to hit your baseline expectation and not be in danger of a performance improvement plan (PIP)?
  - What does it mean to knock it out of the park?
- Things will change, especially in high-performance tech companies. This document will change over time, and you and your manager should be 100% aware of this and adapt.

360 Feedback: The BEST Performance Review System Top Companies Use

- The goal of 360 feedback is to generate as holistic and fair a picture of employee performance as possible.
- It does this by getting feedback from all directions:
  - Within (yourself)
  - Above (your manager)
  - Below (your reports if you are a manager)
  - Laterally (your teammates)
- This system prevents employee performance from reducing down to sucking up to the manager, which is the case in more traditional companies that aren't using this system.
- 360 feedback also makes the power dynamic between manager and report more equal. A manager will have a bad feedback packet if their reports all share bad feedback about them. This holds bad managers accountable.

The 3 Core Performance Review System Archetypes

- 3 archetypes:
  - Ad-hoc spaghetti (small companies): No ratings, no recurring timeline, no formal process to get feedback
  - Manager determines all (traditional companies): Manager determines 90%+ of your rating. Used by most companies.
  - **360 feedback** (modern, mature companies): Get feedback from all directions.
- 360 feedback is the best system, and it's used by pretty much all the top companies like Meta and Google.

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

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

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

The Breakdown Of A Good Technical Question

Asking effective technical questions: 
- **Intention**: What is your high level goal?
- **Expectation**: What do you expect to happen? 
- **Mismatch**: What is actually happening?
- **Investigation**: What have you tried?

If you're interested in learning Android, check out the tutorial Rahul references:  [Tip Calculator - Build Your First Android App](https://www.youtube.com/playlist?list=PL7NYbSE8uaBCMVBVg6cskGzdYguj3CUP-)

Performance Review Ratings Example: Meta & Google

- Meta:
  - Meets Some Expectations (MS)
  - Meets Most Expectations (MM)
  - Meets All Expectations (MA): Need this or above to be doing okay.
  - Exceeds Expectations (EE)
  - Greatly Exceeds Expectations (GE)
  - Redefines Expectations (RE)
- Google (these are the old PERF ratings):
  - Needs Improvement (NI)
  - Consistently Meets Expectations (CME): Need this or above to be doing okay.
  - Exceeds Expectations (EE)
  - Strongly Exceeds Expectations (SEE)
  - Superb
- Other companies will use a 1 to 5 system which roughly maps to the above, Google in particular

If you fall below MA at Meta or CME at Google, you will either immediately be put on a [performance improvement plan (PIP) or be at huge risk for one](https://www.jointaro.com/lesson/7SsdpweHE4sbyTtz2kxQ/the-key-to-avoiding-the-performance-improvement-plan-how-to-figure-out-where-youre-trending/). Learn how to [avoid or manage a PIP from our course](https://www.jointaro.com/course/the-ultimate-performance-improvement-plan-pip-guide/).

Related resources:

- [\[Masterclass\] How To Navigate Your Performance Review In Tech](https://www.jointaro.com/lesson/b0B8uqIAUnBLE10jJHJG/how-to-navigate-your-performance-review-in-tech-7232022/) - This is the full video this clip was taken from
- ["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 do I help my manager (who is also my mentor) be a better manager and mentor?"](https://www.jointaro.com/question/LbHgSEtXcb5QR5nVu8xt/how-do-i-help-my-manager-who-is-also-my-mentor-be-a-better-manager-and-mentor/)

This Is What Most Companies Get WRONG About Promotion

- 2 types of promotion:
  - **Strong companies:** Already functioning at the next level
  - **Weak companies:** Mastery of current level + long tenure
- In the best tech companies, each level is fundamentally different from the previous one. This is why promotion is lagging there: You need to be functioning at the next level consistently for 3-6 months before getting promotion.
- The goal is to avoid the Peter Principle: Getting promoted to higher and higher levels until you are completely incompetent. When levels are truly meaningful, it's really easy to be doing great at your current level and then be struggling to survive at the next one.

Understanding Performance Review Ratings

- The end goal of a performance review is to assign every employee a rating, which is like a grade in school.
- Know what ratings are good
  - What's average?
  - What puts you in the "danger zone" or on a formal performance improvement plan (PIP)?
  - Which rating is great?
- Understand which rating is necessary for promotion

Why Is Performance Review Important And How Does It Work?

- In the age of tech layoffs in particular, it is crucial to do well in performance review consistently. A lot of companies stack rank as well, where every performance review cycle, 5-15% of the lowest performing engineers are cut.
- 4 core steps of performance review:
  - Understand the yardstick (ratings)
  - Understand the process (how your rating is generated)
  - Prepare for success (come up with a plan)
  - Execute (go through the cycle and hit the calibration process at the end)

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

- [\[Masterclass\] What Software Engineers Should Look For In Their Engineering Manager](https://www.jointaro.com/lesson/oeY7ncZhzJ5NO6dij5e7/masterclass-what-software-engineers-should-look-for-in-their-engineering-manager/)
- [\[Masterclass\] How To Get Promoted Faster In Tech](https://www.jointaro.com/lesson/W730BOdrfAIXAEVd8HUf/masterclass-how-to-get-promoted-faster-in-tech/)
- [\[Masterclass\] How To Have Impactful 1:1 Meetings](https://www.jointaro.com/lesson/FEK6JZqW2Jg3rdN9yeGn/masterclass-how-to-have-impactful-1-on-1-meetings/)
- [Presentation Slides](https://docs.google.com/presentation/d/142PsWRJ-fmdP42CrFpR0VD64L1qFP-6nPTmjk5g1DKM/edit?usp=sharing)

[Part 8] Meta Intern Success Series - Rahul's Internship + Current Economy

I interned at Meta in the summer of 2013 (it was called Facebook in my day…). I barely got the return offer at the end of the summer. My reflections on what I could have done better: 
- Too much back and forth on my code review. I made the same types of mistakes in the code I wrote, and I occasionally tried to pushback if a reviewer requested changes. 
- Not communicating with enough with teammates. In addition to my intern manager, I should have had a regular 1:1 with the person who was primarily reviewing all my code. 

What I did well: 
- I was responsive. I replied to messages + comments quickly, and I tried to share my insights (from my project) where possible.. 
- I was a good culture fit: I built a substantial hackathon project which garnered some attention.

Advice for the current economic condition for software engineer interns: 
- Focus on cultivating relationships with people on your team, so they are able to refer you. 
- Leverage the work you did in Meta to more easily land interviews at competitive companies.

[Go back to part 1 of the Meta intern series](https://www.jointaro.com/lesson/DPcsvbf5IKk57xcqyiAC/part-1-meta-intern-success-series-internship-program-overview/)

[Case Study] Building A Meta Internal Tool To Empower An Entire Org: Staff Promotion Story

- Debugging was a huge pain point for the Facebook Portal org.
- To fix this, Rahul built a tool that made it far easier to debug tricky Android issues (Portal runs a fork of Android). It took all the crazy dump files from Android bugs and extracted the insights.
- Rahul started off the tool with an *extremely* simple interface: Upload the massive dump file and it would extract insights. He would improve it later by making it so the user only needed the bug ID.
- The tool started off with around 100 engineers using it and then grew to 250+! This massive scope was enough to get Rahul AE (additional equity) and a promotion to E6 (Staff at Meta).
- How you can incorporate these learnings into your work:
  - Look internally for opportunity. There are ways to have impact besides shipping flashy products, and in Big Tech in particular, improving engineering efficiency can be a *huge* win given how many engineers there are!
  - Understand the pain of your peers. Not only is this just a kind, empathetic thing to do that builds relationships, pain often comes with opportunity.
  - Think outside your stack. Instead of working forward from your stack of choice and what you can do with that, zoom out and holistically look at problems across your org in general. It's cheap to learn other stacks to build solutions - The main thing to do is identify problems.
- Here's [a link to the slides](https://docs.google.com/presentation/d/1Scxll_pApdPLXk42jSHcrZ4LaTE8_7BUjvB14z9-SgU/edit?usp=sharing).

Related resources:
- [[Case Study] Effective Communication: Leading A Multi-Org Re-architecture At Meta](https://www.jointaro.com/lesson/Rovw6IfITXGr55NdftFw/case-study-effective-communication-leading-a-multi-org-re-architecture-at-meta/)
- [What's the Difference Between A Senior And Staff Engineer?](https://www.jointaro.com/lesson/FzvHLUprcYonudsxnJc2/whats-the-difference-between-a-senior-and-staff-engineer/)
- ["I would like to get more clarity on what a Staff-level project and execution look like."](https://www.jointaro.com/question/RQa5tsnXnZr6Xg1ziv0X/i-would-like-to-get-more-clarity-on-what-a-staff-level-project-and-execution-look-like/)

[Part 7] Meta Intern Success Series - Succeeding As A Remote Intern

- Learning speed is severely nerfed by remote work, which is awful for you as an intern since this is when learning speed is the most important. It's important to keep this mind as you navigate your internship.
- Attend all team events, even the less formal ones (i.e. non-offsite) like team lunch. It's extremely important to build relationships and social capital in this environment where everyone is more isolated.
- Have 2 to 3 1:1s with your non-intern manager peers.
- Match the working hours of your team if you're in different time zones. It's absolutely vital that you always get blocked ASAP, and this is way harder when you're operating on a different time scale. This could be painful, but it will be worth it.
- Do virtual coworking whenever you can. The idea is that everyone joins a video call and just works, no meeting agenda or anything. The idea is to mimic an in-person working environment as much as possible. This creates peer pressure for you to be productive and makes it seamless for you to ask for help (just say something on the call!).

[Part 6] Meta Intern Success Series - How Most Interns Fail

Here are the common ways software engineer interns at Meta fail:
- **Misalignment of expectations**: Make sure that you're getting feedback regularly from your intern manager (IM) and ask every 2-3 weeks for a honest, real take on how you're trending. Don't wait until mid-cycle for real feedback!
- **Doesn't take feedback well**: Remember, feedback is a gift. Respond to it gracefully and quickly; treat every piece of feedback with urgency. As a software engineer intern, you barely know anything (which is expected): If you get constructive criticism, there is a 99% chance that it is correct.
- **Writes sloppy code**: Volume is straightforward and not that special - Most interns know how to write a lot of code from school. The point of your internship is mostly to teach you how to write good, clean, production-level code. Make sure your diffs are thoughtful, focused, and atomic with thorough context sections and test plans.
- **Sphere of influence is too small**: Don't only rely on your IM; you need to have 2-3 other peers to vouch for you in final calibrations. It can be comfortable asking your IM for help on everything, but you have to diversify: Make sure that you also ask other peers for help and to review your diffs. Consider having a recurring 1:1 (once every 3-4 weeks) with your non-IM peers.

[Part 5] Meta Intern Success Series - Writing The Code

- Keep your diffs focused and atomic. Aim for 25-250 lines of code per diff.
- Use stacked diffs: They are core to Meta's code culture. If you're unsure how to break up your work into a diff stack, work with your intern manager to come up with how things should be broken down.
- Make sure that all your diffs have a really good context section. You can have a "Context" section at the top explaining the overall goal of the diff stack (i.e. usually what your intern project is meant to do) and then a "In This Diff" section which explains the specific problem your diff tackles.
- Attach a test plan to show that your code works and to turn the diff review into a high-value artifact. Record a video of you stepping through the flow if possible (this should be easy as many interns work on internal tools) and make sure to cover those edge cases!
- Keep a very close eye on your Phabricator notifications. Your goal is to respond to code review comments quickly (within 30 minutes) and gracefully. **Code review feedback is the main way you grow as a software engineer intern** as the internship's goal is to develop your raw coding ability.
- Land diffs ASAP, so you don't need to deal with rebase hell.

Related resources:
- [One Diff, One Thesis - What Every Code Review Should Be Like](https://link.jointaro.com/Wnp45zAysqyaidSF7)
- [The Most Common Mistake Made When Authoring Code Reviews](https://link.jointaro.com/bCaB7gh2u5budm2V6)
- [What A Test Plan Is And Why Every Code Review Needs One](https://link.jointaro.com/62fq4369rxjXuDju5)
- [This Is What A Good Code Review Test Plan Looks Like](https://link.jointaro.com/ieDhChExstEpD8sw9)
- [Full In-Depth 1 Hour Masterclass On Effective Code Review](https://link.jointaro.com/Vn7YSzTL61i9shwM8)

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.