Taro Logo

How can I think like a staff engineer?

Profile picture
Anonymous User at Taro Community10 months ago

This occurred to me at work today

I was working on a task for which I completed coding and and testing. I showed the code to some of our Staff engineer after standup. The first thing he asked me is why is this fix working. I did try to understand how my fix is working. However after I discussed this with him it was clear that my understanding was superficial. Apart from that, the fix I made even though it works in the current version might break if the library version is upgraded coz I am depending on some internal behavior.

Considering that I have 10 years of experience it felt very disappointing that I could not think of this on my own.

Any advice?



  • 41
    Profile picture
    Ex-Microsoft, Ex-Meta, Ex-CEO of tech nonprofit
    10 months ago

    First, don't pivot on this too much if it's an infrequent situation. Everybody has times when they don't get something right, or miss something obvious.

    That said, if you find that this is a pattern, it's a positive sign that you noticed. This sort of self-awareness and reflection are a key to growth.

    A lot of becoming a more senior engineer is about getting closer and closer to first-principles thinking. Growth over time looks like this:

    1. Junior engineers should at least be good at answering How: as in "How should I implement this? How would this best be done?" Excellence at this level is about being very good at operationalizing features that have been decided.
    2. Intermediate engineers should be able to answer What: "What should we work on? What is most important?" Excellence here is around choosing features and architectures wisely.
    3. The highest impact engineers answer Why: "Why is our business strategy this way? Why should we do the work we're doing?" Excellence here comes in understanding and motivating purpose -- both in yourself and in the broader team.

    A lot of levels 2 & 3 fail when people don't try to recenter around first-principles thinking. Instead of thinking broadly about satisfying goals using a wide aperture of possible solutions, we often instead hone in on one or two "obvious" ways to do what we want. Failures at level 3 are most catastrophic: I've seen teams of more than a hundred engineers working on a product for several years before the entire premise of the product came into question; it turned out that the product should never have been built, that the market never needed it.

    BTW, have you potentially already posed this question to the staff engineer that you consulted? Getting his take on this (e.g. "What methods do you use to assess technical solutions such that you so easily saw what I missed?") might be a great concrete way to start.

  • 26
    Profile picture
    Mid-Level Software Engineer at LCvista
    10 months ago

    I’ve been reading the StaffEng stories. It’s very interesting and you can get a lot of insights around how they think and operate


  • 23
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    10 months ago

    I would treat this as a learning experience - As Philip mentioned, you're already off to a great start by having this self-awareness and retrospecting on + sharing this moment!

    It's easier said than done of course, but my general mindset is to embrace being the dumbest person in the room. Of course, you don't want to stay that way forever, but the idea is that it's good to be humbled here and there and be shown how much room there is for you to grow! It means that there's scope within your team to really improve yourself as an engineer.

    The next step here is to be weave in this behavior proactively into your future work:

    • Let's say you're working on a meaty project or bug fix.
    • Instead of waiting for your staff engineer to grill you after you have written the code and submitted it for review, do it before you do any execution.
    • Better yet, "role-play" as this staff engineer yourself and try to poke holes in your own understanding/technical design before asking for external feedback.
    • You now know what kind of questions this great engineer thinks about when they push technical depth to the limit - There's nothing stopping you from running those against yourself now.

    And of course, if you don't fully get their mindset yet, just ask! They're your teammate - It seems like they're open to helping. In general, whenever you get into an education moment like these, you should always push the boundary and ask follow-up questions to maximize your learning. We talk about in depth in our video here: How To Actually Learn Software Engineer Skills

    Here's some additional resources on how to ask a good question:

    Considering that I have 10 years of experience it felt very disappointing that I could not think of this on my own.

    No need to be disappointed! I know many engineers who have 10 YOE and aren't staff yet - In fact, I think most engineers take >10 years to get to staff. Careers are a marathon, not a race: There's nothing wrong with taking 15 or even 20 years to grow to staff or even never making it to this level at all! And of course, staff engineers also have mishaps like these all the time - They're only human, just like all of us. This event has 0 negative bearing on your quality as a software engineer.

    Lastly, here's some great resources breaking down staff engineer behavior + mentality: