Principal Engineer Q&A and Videos

I have about 5 YOE and trying to grow from Senior -> Staff engineer but noticing that the path is taking longer than I'd hope.

This is the case whether I try to speak to other companies and ask about interviewing at that level or try to grow within my own company.

Within my own company: Requirements unclear, seems to be more time based (just keep on shipping). Since we're on the smaller side, we don't have a clearly defined structure like FAANG.

Externally: Due to the YOE, usually discussion of Staff isn't even an option even though I think I'm doing Staff level work. In fact, they usually decline the idea before even having a chance to explain what I'm working on.

The projects I'm working on span the entire org (startup), I have multiple mentees, and org-wide impact. I will be honest and say that I don't think the projects I work on are necessarily insanely technically complex (not going out to millions of users, dealing with hyper concurrency issues, or needing to deal with large scalability issues), but they do have a large amount of scope and senior+ level management required to run them.

I think from the project management perspective, I have things nailed down pretty well.

So I wonder if I'm either missing...

• YOE - Just some sort of arbitrary minimum that is being placed across the board for certain levels to be achieved
• Technical expertise - I definitely admit that I'm not necessarily INSANELY technical. For example, I can admit gaps like: I don't know how to design a concurrent document editing system like Google docs, or I wouldn't be able to write a live streaming service without reading up on the proper documentation and understanding better how those systems work. Are things like this a requirement to be a staff engineer? To just be more aware or know right away how various systems like this are designed, without needing to do research beforehand?

I'm essentially trying to understand what my gaps might be, and the technical aspect is one I'm unsure about how relevant it is.

Would appreciate any thoughts, especially from Staff+ engineers, maybe sharing what they feel makes them a Staff vs a Senior and how much technical skills play a role vs other elements.

I've been debating this though for a while. Is it worth it to go for a principal role (61 -> 62 -> 63 -> 64) or just go and build something your own

I am a seasoned Mobile engineer(Staff+) and have been looking for a new job since this January.

After failing at several job interviews with big tech companies like Meta, Square, Airbnb, Uber, etc I finally received offers from Okx, Doordash and Reddit.

To be honest, I feel like the biggest gap was DS&A. Over time, I improved a lot in this area and through the help of mentors and referrals, I was able to land the above offers. I'm very grateful for Taro (especially Rahul) for his constant words of encouragement and his guidance when I needed his help.

To everyone out there, I know the market may seem crazy but if you weather the storm, you will find success. If I can do it, you can too! Good luck!

I just joined Target at a Principal level. My manager is spread very thin and wants me to take initiatives and has told me to start networking heavily in the first few weeks. My plan is to create an Onboarding doc and share it with my manager. I'm going to use this doc to manage expectations and use it to review together 3 months down the line. How can I structure this doc? What pieces of information are more relevant/vital for such a doc. Any pointers?

How does it differ from an entry level engineer to the head of engineering level at each of the levels, given the scope grows as well at each level?

• Software Engineer
• Senior Software Engineer
• Tech Lead
• Staff Software Engineer
• Principal Engineer
• Head of Engineering
• Director of Engineering
• Vice President
• CTO

How do each of the levels ensure they are onboarded as quickly as possible to have maximum impact ?

A few months ago, I was bad at understanding the expectations for each level. Thanks a lot for the Taro courses and the community, you made a real impact on me. I now have a better understanding of L3, L4, L5, L6 levels.

I'm now curious about some things that L7 and L8s do. What do their projects look like? What's the size of the team/org that they have to manage?

Would be nice if you can provide some example projects to get a better idea.

I'm a Staff Engineer in the satellite telecommunications industry where I am responsible for the strategic success of the software products in my department. My organizational responsibilities and weekly calendar align almost perfectly with the . I'm sure that it will come as a surprise to no one that getting to this point in my career was an intense and conscientious journey. I am self-taught, I fell in love with programming as a child, and I have never attended a University. Things are not even close to perfect, but I am happy with my career so far.

My day-to-day work does not involve much programming, but I spend the vast majority of my time communicating with Tech Leads, Scrum Masters, PMs, TPMs, EMs, etc. to coordinate and accomplish different tasks. The rest of my time is split between communicating and aligning with high-level product stakeholders, such as my boss, and mentoring engineers. When I do code, it is because there is some experiment I want to run, i.e., I might create a prototype of a new product or feature that could massively impact a departmental OKR.

Outside of my day-to-day work, I dedicate as much time as I can to learning and practicing new technical (programming, cloud), professional (LinkedIn Learning), and domain-specific (satellites, AI) skills. I also consume a lot of content here on Taro and I often participate in company and community programs that I believe in (change maker programs, diversity and inclusion programs, etc. as a participant or as a coach).

I would love to have input on this aspect of my career as a Staff Engineer who would like to be a Fellow one day. As I make progress in my career, I find that (obviously) the expectations others have of me, in regard to being at the forefront of technology and really knowing what I am talking about in domain-specific (science-heavy, business-heavy) topics, have grown exponentially. I've already adapted my approach to developing domain-specific skills, for instance, instead of relying solely on MOOCs, I also now have regular sessions with domain experts (business folks with advanced industry-relevant university degrees), something my boss encourages and expects me to continue to do. I have now also considered the prospect of going to university myself, something my employer would sponsor.

So the question is, how can I best invest my personal development time so that as I progress in my career I can continue to meet, or even surpass, exponentially growing expectations?

I'm sure someone will have a great idea of how to approach this challenge. Also, there is a quote I appreciate from Alex Chiou that gives me hope that I can do it.

It wasn't due to natural talent or anything - I'm honestly not that smart.

1. How do pull requests and pull request comments look like with an increasing level of seniority?
2. Are pull requests for senior engineers not expected to have any comments for improvements? If yes, then what kind of comments should be there?
3. Also, have seen some principal engineers not sharing their pull requests as they are quite high in seniority and merging it directly. Do you recommend that? If not, who should review PRs for very senior engineers if the team does not have engineers at that level?

There's been a lot of talk in Taro posts recently about "being a strong engineer". Is there a single post or could we build one here where we outline all of the must haves of a strong engineer as to form a type of roadmap? I think imposter syndrome hits us all but I kind of want to be able to know am I fulfilling most of the right behaviors?

I would love to hear problem-solving stories from the Staff and Principal Engineers on here, that illustrate:

1. How you spotted a problem and went about assessing the impact of solving it
2. how you went about solving the problem, (optional: how you managed the execution)
3. how the buy-in happened

Answering this would help a lot of us staff and SWEs understand the scale and size of problem solving at this level. Not to mention inspire us to do similar things!