Taro Logo

What's the difference between a low performer software engineer and a high performer?

Profile picture
Forward Deployed Software Engineer at Palantir2 years ago

Some additional questions:

  1. Does it vary between big companies and small companies?
  2. Do you need to work a lot to be a high performer?


  • 120
    Profile picture
    Robinhood, Meta, Course Hero, PayPal
    2 years ago

    This is going to vary a lot across teams/orgs/companies, so I'm going to start with a couple commonalities I've noticed across low performers in general:

    • Didn't take feedback well - This led to them being unable to course correct, which was just asking for trouble.
    • Uncollaborative - I don't think I have ever seen an engineer who was very active socializing and working well with other members of the team (asking great questions, helping them out) also be a low performer. When I saw engineers get cut for performance, they were either toxic and actively didn't get along with teammates or were more lone wolves that stayed in their own corner and did their own thing.

    Both of the above failure modes are heavily tied to communication skill. For anybody worried about struggling with the above 2, I heavily recommend watching this: Alex's Guide To Effective Communication

    Big Companies vs. Small

    • When it comes to big companies, I've seen low performance from poor communication and code quality (on top of the above 2 things). Expanding on the poor code quality portion, they often had bad attention to detail in general.
    • In small companies, I feel like it's more about code velocity, since that's a much higher leverage thing to do there, especially in startups. However, smaller companies have a ton of variance, so this won't be true a lot of the time - I know small companies that actually do value code quality over speed.

    Do you need to work hard to be a high performer?

    • Generally yes, but it's not required. I am assuming the more "traditional" definition of working hard meaning a decent amount of hours.
    • Some companies equate many hours of work to quality of work, which is rough.
    • In the end, software skill is largely a matter of doing, which requires time. This means that it's inherently hard to become a good software engineer without spending a lot of time. I've rarely seen software engineers who just "got it" and were able to have tons of impact and growth while only working 2-4 hours per day or something.

    In terms of what makes a high-performer software engineer, there is simply too much to cover: There are so many creative, deep ways software engineers can add a ton of value to an organization. If I were to pick one resource in all of Taro that covers a good amount of these skills, it's my in-depth breakdown of my rapid Robinhood onboarding: [Case Study] Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta

    There's a ton of nuance in this topic, so I recommend going through the related resources below as well.

    Related resources:

  • 46
    Profile picture
    Staff Software Engineer @ DoorDash, ex-FB, ex-Klaviyo
    2 years ago

    This is a good question but also very generic. It really depends on the level, the context and the priorities of team. The expectations & areas of focus are very different for different levels.

    If I must generalize, a "high performer" are able to do two things compared to a "low performer"

    • be self sufficient and able to drive large changes on her/his own.
    • be able to share their learnings with others and increase the team efficiency as a whole.
  • 25
    Profile picture
    Comstock Software, Inc
    2 years ago

    In both cases, it comes down to business impact. Write and rank your list of priorities by business and economic impact. Identify the highest-ranked priorities. Talk about your assessment of business impact with your manager. Work on them all the time. Do not let the tyranny of the urgent keep you focused on low-value work.

  • 71
    Profile picture
    Ex-Microsoft, Ex-Meta, Ex-CEO of tech nonprofit
    a year ago

    To riff on Anna Karenina, great performers are all like; every poor performer is poor in their own way.

    Somewhat tongue-in-cheek, but these things are all true of high performers:

    • Higher impact than others of the same level. (Remember, all performance is relative. Any high performer would be a complete dog if you promoted them to the right level.)
    • Responsible / reliable. You don't doubt they'll get done what they say they will.
    • Great collaborator. Increasingly fewer companies continue to value high-impact jerks.
    • Great at self-improvement. Alex's comment about taking feedback is spot-on here. The best performers are self-aware, accept others' feedback, and implement feedback effectively.

    But poor performance comes in all sorts of shades:

    • Icarus. People who ask to be promoted too aggressively will likely land at a level they can barely compete in. Since all performance is relative, getting promoted too quickly is one of the fastest ways to become a poor performer.
    • Self-unaware. There's a t-shirt that says, "The only common thing in all your failed relationships is you." Setting the joke aside, there's some real wisdom in there. If you could instantly accept and implement any piece of feedback given to you, you'd be an amazing superstar. The fact is that people don't accept feedback half the times, and the other half, they struggle with implementing said feedback.
    • Motivationally challenged. "There are no boring things. Only boring people." Anybody who thinks it's their manager's job to make their job interesting is going to struggle long-term. Smart people are curious and they find the interest in nearly everything. You need to have your own goals and a strong drive to succeed.
    • Lackadaisical. If you're just as smart as everyone else, and you work just as hard as everyone else, you're average. By definition — not being cheeky. When I started at Microsoft, I had a sleeping bag in my office and worked ridiculous hours. While I now view that period of my life as foolish, you can bet I outperformed everyone else my level, and by a significant margin. Anyone telling you that you can Have It All™ — work only 40 hours a week, marry a supermodel husband/wife, have IPO after IPO fall on your head — is selling something. You will outperform others only through three means: 1. luck, 2. talent, and 3. hard work. You can't control 1 or 2.

    There are way too many other ways to be a poor performer to continue listing them. But I hope this is a helpful start.

  • 37
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    a year ago

    Taro has come a long way since I originally commented on this post, so I have a bunch of new thoughts. In particular, I didn't cover high-performers too much before, so I'll do it now.

    When it comes to high performers, there are 2 big core traits I have noticed:

    1. They are exceptional at learning from others from them, both directly and indirectly.
    2. They develop higher-level skills that are applicable everywhere across any team, any tech stack, and any given situation.

    Learning Through Osmosis

    By being able to quickly absorb good behaviors, expertise, and skills from their peers, this makes it so that once a high-performer finds a great team, they are going to grow like a rocket ship. Here are some excellent resources covering this:

    Developing Better Skills

    What would you rather have:

    • 1 skill that makes you tremendously useful in 1 type of situation?
    • 10 skills that make you at least moderately useful in 1,000+ different types of situations?

    The first is a common failure mode for struggling software engineers: They focus too much on the tech and only become good at 1 specific tech stack (i.e. the one used by their team). Sure, they're the most useful person in the world when there's a tricky task in Python 2.7 and they have written Python 2.7 for the past 10 years. However, this also means that when they're put in a non-coding situation or a different team, their usefulness plummets to near 0.

    The second is what rockstar high-performer engineers do. Of course, they'll develop the technical proficiency to accomplish the tactical parts of their job, but they're also getting good at skills like communication, building relationships, and time management. This means that no matter the situation, they have this solid bedrock of fundamentally useful skills to fall back on. This allows them to always add value, whether it's through effective project management or asking insightful questions.

    To learn what more about those fundamental skills, check out these awesome resources:

  • 28
    Profile picture
    Tech Lead/Manager at Meta, Pinterest, Kosei
    7 months ago

    I'll illustrate high performance with the story of my friend from college. We were taking the classic Stanford weeder class, CS107, systems programming in C. This class was extremely difficult since it was the first time we were exposed to:

    • Writing sophisticated C code
    • Managing our own memory, e.g. malloc() and free()
    • Using the command line and CLI-based text editors like vim/emacs
    • Figuring out how to compile and run programs with Makefiles

    The learning curve was steep. Most people, including me, would wait until the last few days before the deadline and then attempt to speedrun the assignment. But there were too many moving parts, too much to understand, for this to be feasible. I became overwhelmed.

    On the other hand, my friend made methodical progress every single day. He wouldn't try to get the whole thing done in one go, but he'd create mini-milestones: today he'd dive into Makefiles, tomorrow he'd understand valgrind, and the next day he'd achieve milestone 1 in the assignment. Needless to say, he not only aced every assignment, but he also had enough time to extend projects for extra learning (and extra credit).

    Two unique behaviors that led to his success:

    • Proper decomposition led to focus. At a certain complexity scale, you need to break problems down and tackle them one at a time. You need to not only figure out the decomposition, but also how the pieces fit together once you solve each piece.
      • Attempting everything results in achieving nothing. You can't learn AI, blockchain, and the newest JavaScript framework simultaneously.
    • Steady progress led to deeper understanding. One pernicious trait of weaker engineers is second-guessing themselves: they'll think component A is responsible for a bug, but then some other data leads them to another conclusion.
      • Same thing with building systems. You want to make methodical progress so that you emerge with a rock-solid understanding of the tool/system (can you teach others?)

    My friend is now a Senior Staff Engineer at a company in San Francisco valued at $9B, operating in one of the most senior roles. The path to high performance is simple but not easy: show up consistently and put in the effort over an extended period.

  • 2
    Profile picture
    SMTS at VMWare
    2 months ago

    This is just a personal answer which I have seen in many high performers:

    1. They try to be very much involved in meetings/discussions. They listen to what people are saying and do have some valuable questions and points to add up in the discussion.
    2. They are always well prepared in meetings. Easily able to answer questions/ doubts of participants.
    3. They invest their times reading the codebase and introduce improvements while working on the project.
    4. Will time they will keep trying to increase the complexity of the tasks in hand. Often times we stick with keeping up the same tasks at work. But these people will keep finding better work for themselves and add up their contribution.
Palantir Technologies is a public American software company that specializes in big data analytics. Headquartered in Denver, Colorado, it was founded by Peter Thiel, Nathan Gettings, Joe Lonsdale, Stephen Cohen, and Alex Karp in 2003.
Palantir3 questions