What does a Principal Software Engineer do?
blog.devgenius.io
blog.devgenius.io
When I see titles, it just makes unhelpful thoughts enter my head, like: are all these people “at my level” really contributing as much as me? Sometimes I even thought the reverse, like: how can this seemingly-junior person still be stuck at that level, when he is clearly doing all this great stuff we depend on every day? Of course the especially soul-crushing case is when you encounter people that clearly suck at what they do, and they’re 1-2 levels above you; and worse, I have occasionally seen those people promoted further!
It is also hard not to look at titles on places like LinkedIn. I know I shouldn’t care, since titles mean different things at every company, and some especially-impressive-sounding titles can range from “meh” to “god-level” depending on where it is. And yet, it gets in my head sometimes, making me wonder every few years if I am at the level I should be.
When the title “matters” at a company, it also makes me consider it a factor in annual reviews. If I get a raise, bonus, etc. but see my damned title stagnate year over year, suddenly I care about this and take it as a complete lack of recognition by the company (that literally would not happen if they simply did not tell me what my title is!).
Ended up doing something similar in my original tech job as well. I'm not sure I've ever really used my official HR title and would probably have to look it up to be sure I'm remembering it correctly.
Also, lots of folk deliberately opt out of level visibility, too.
It's really dehumanizing. I think I'd rather not know people's titles, just what team they're on, and their role.
Not 100% always, mind you, but way more often than not.
The fact that someone else is doing more or less with a higher title shouldn't influence your life at all. Jealousy shouldn't tell you when you should look for a job. If you are unhappy leave if you are happy stay. If your happiness is determined by what a random person is paid you will never be happy.
I think this is a logical contradiction. If there exists people that you are in a position to judge their competence you deserve to be in their position or higher, therefore it cannot be that they are 1-2 levels higher than you.
Logic is a great tool by the way, but unless you are applying it formally you might be better off not trying to invoke it casually.
> and seeing your influence grow as you are trusted with more things.
That's the ideal scenario, that you earn the esteem and trust of your peers because the work you do speaks for itself.
The flipside with this is, this process takes time. It really takes years. Sometimes there will not be that time. You are a new hire brought in to do a high-impact thing; or a high-impact project crosses across the entire organization where suddenly all participants are relative stranger; or the team you worked in was of very low external visibility but a mentor recognized your potential and pulled you out to help recalibrate a different but malfunctioning team, etc...
Then titles are important. It is very unfortunate that we are very cynical of titles, because, in well-run organizations, they are meaningful, and in fact, should be meaningful. Imagine in the military if every officer had to prove themselves over and over again. It's unworkable.
At some point, larger organizations will need to grant leverage to a technical individual. A title helps with providing that.
I've also seen the opposite, perfectly fine engineers get worse after a promotion due to the weight of the title, without any other change to their work / schedule.
I've been very disappointed by comparing people's titles with their actual technical ability -- somehow it never seems to be the case that the ability outstrips the title.
Really? You've never worked with a junior who's punching far above their weight? I've had several on my team and work as hard as I can to get them promoted asap.
That said, it definitely gets rarer the higher up you go.
People get promoted until they reach their level of incompetence :-)
TIL: This is a really interesting perspective; Thank You for this! I will use it from now to calm myself down. I, always either got mortified by the extreme skill of my juniors or by the incompetence of seniors — not sure if it’s the case with me or is it a general feeling.
The Kendo way at-least makes me ignore the titles :)
Beating that higher ranked player promotes you to their rank (and demoted them). It's like a mini boss that the game doesn't tell you about.
That's one benefit but I think that the main benefit is that when you've a high level, you'll know that this guy in front of you is a beginner and you'll go soft on him, which is quite important: if he doesn't know how to fall properly the beginner could be injured if the "high level" guy doesn't notice in time..
Does having limited ambition make you a bad dev/engineer, if you keep learning new things and contributing quality code at your current level of responsibility?
Sure, you might have some specialized knowledge or understand system X better than anybody else, but there's diminishing returns on that, hence why you won't get big raises forever.
As you move up the chain, it eventually stops being about your direct technical contributions and about your ability to multiply the value of everybody under you in your org.
I thought that was the whole point of the IC track: putting a technical person into a role where they can be a multiplier without burdening them with management responsibilities.
Every staff/principle/architect IC I've ever worked with has had that kind of positive effect on the teams around them. Their schedules were indistinguishable from most managers, except they met mostly one on one and they could get a senior engineer's worth of work (impact wise) done in between the meetings instead of paying the management overhead.
I don't disagree that principle engineers can and should have a big multiplying effect, but I also wouldn't consider them strictly IC's either, even if they don't have people managing duties.
Pretty much that, except that I wouldn't use the word "stagnate". What I said was "lag behind the cost of living", which might not have been the most concise way of putting it, but I hoped it would get my point across.
Essentially, the conundrum I've faced too often is that if you're not climbing the ladder, the purchasing power of your salary will start falling, even if your salary rises, because the raises you get reflect the lack of regard the company has for people who aren't climbing the ladder.
Stagnation, for me, would be to stay at the more-or-less same purchasing power. And I would be fine with that.
This will forever strike me as a post hoc rationalization for justifying salary increases when the truth is that the salary increase is just a natural outcome of being granted institutional authority. This is the most visible with the CEOs that fail being given absurd bonuses and then justifying that as necessary to attract top talent. The people that are value divisors are still given huge remunerations precisely because of the position, not because of their impact.
To the exclusionary aspect of the idea, unless your employees are being micromanaged then a large part of their work is discretionary. If they are not being kept in the dark and are not working alone then a large part of their work is also collaborative. Putting these things together, your good employees will field requests from other teams, prioritize them on an ad hoc basis, connect dots and report opportunities amongst themselves: solving problems that influence many more customers than the direct ones they work with. Promoting them will move them out of the circle where they learn about these situations on the ground. Instead of multiplying your capabilities, you may end up dividing your people by removing a key communicator from the employee social network when you promote them. Potentially, everyone recognizes there is a problem, but the problem solver role is a vacuum. Worse if nobody is able to recognize there is a problem now that the person who was able to recognize it is faced with different challenges.
Institutional authority is not isomorphic to collaborative potential (or any general notion of work multiplication). Personal authority, respect, cooperation, skill, insight, all kinds of things can make a person's individual contributions many times greater. All these things are independent of institutional authority and the actual use of institutional authority will almost always come off as a cheap form of insecurity: "Do it because I'm the boss."
The truth is that it is easy to create a hierarchy and challenging to measure impact.
If you're happy with where you are, and happy with your salary and status, then it's fine to stay there! Certainly, as you say, continue to learn new things, make quality contributions, and get your work done.
Many companies will have what they call "terminal levels" for individual contributors (most probably don't really advertise this unless you specifically talk about it with your manager). The idea is that you can work at a level where you can get your day-to-day work done with minimal guidance, even if you need guidance on the bigger picture stuff (like what you should be working on, and why). You should certainly talk to your manager about this, if you feel comfortable. And if you don't, and/or they keep pushing you to climb the ladder further, then yeah, you should probably find a new gig.
One caveat: ageism is still an unfortunate thing in our industry, and as you get into your 40s and beyond, if you're still "only" a "senior software engineer", you may have trouble getting new jobs.
Companies don't want to get stuck with people who are perpetually "junior" and need a lot of hand-holding to get their jobs done. That's of course ok for a while someone is learning and growing, but if they aren't growing out of that, they're a liability and time sink. But once you're past that point, you should be ok. The only problem is if you end up at a weird place where no one wants to progress up through staff/principal/architect/fellow, in which case I wouldn't be surprised if everyone starts getting pressured to up their ambition. But that sort of scenario seems somewhat unlikely?
[0] Well, unless they are in your immediate family and your lack of ambition is putting their livelihood at risk in ways they can't mitigate. But I'm assuming that's not the case here ;)
There might be some honesty / truth behind what is described but in my 2 decades of IT work, mostly ass kissers have taken home the big bucks .
Source: have been that person.
We have other titles above principal, which I wont name here because you could figure out where I work, but suffice, those titles are gated and only promotable by multiple director consensus. It keeps their numbers very, very low. My department wont mint a new one, but only hire outsiders already at the title.
Yikes, that sucks.
On the hiring side, everyone knows that titles only indicate relative seniority within a company. Interviewers must actually interview candidates to determine what their role was, how experienced they are, and other factors.
It can be a warning flag, however, if a company is giving titles like “Principal Staff Software Architect” to someone who is clearly junior enough that they would require a lot of mentoring and guidance if they were hired. It’s common that candidates are resistant to downleveling their titles when changing jobs, so handing out enormously inflated titles is one way companies try to trap junior employees in their companies. At least until they realize that nobody cares about their inflated titles and they still have to pass the same tech interviews as everyone else.
I was a manager-of-managers, but officially I was a “senior software engineer”. Burned me badly on a couple reference checks, until I specifically started explaining the situation during interviews.
I almost did it at my last startup, to signal the egalitarian, cooperative engineering culture that I intended. One of the concerns was that it could hurt people's career mobility out (and willingness to join, since the startup was unlikely to be the engineer's home for the next few decades until retirement).
I think it works easily when your organization is known as one of the places to go, everyone knows that they do titles that way, and that anyone there is worth considering as a hire. (But not when recruiters filter their resume keyword searches for senior, staff, or principal.)
I don't know why Google didn't do it, way back when, since they did a few other culture things. I suppose that might've set a different tone for our industry today. (Though what seemed at the time to be low-loyalty culture coming out of California was already in force when Google started, most conspicuously in what I called "IPO-hopping", and maybe Google just had to work within that, at the time.)
Legal at a bank only a vice president or higher can make some loan decisions. Thus if you go to a large chain bank to get a mortgage you will talk to a vice president. Their title must be vice president, but they doesn't make a lot of money, and don't have much power other than the ability to give you a mortgage.
Last time I posted the above someone chimed in "yeah, even though all I do is write code all day I'm a vice president because what my code does can only be done by a vice president"
You also see a lot of salesmen who are vice presidents - again they don't have a lot of power in the company, but the places they sell to want to talk to a vice president so sales hands out those titles.
Some companies believe this, but I don't think it's true. Handing out titles like candy can kill morale.
2 years ago I was hired as Staff with pretty high bar to clear.
This year I know a team where all the seniors complain they’re not Staff, and now half the team are Staff engs.
It’s hard to imagine a team where everyone is “leading”. Some people have to be doing.
TBH I doubt the actual work people are doing has changed. It’s more about status and salary.
* Engineer First Class
* Special Engineer
* First Engineer
* Staff Engineer
* Staff Engineer First Class
* Principal Engineer
* Staff Engineer Major
* Principal Engineer First Class
* Staff Engineer of the Office
etc. Need matching insignia on the collar, of course.
Then other people of the same rank become vice presidents.
At one bank anyone at director level (manager of managers) was a VP, for example.
Right? Because if not, I need to have a discussion about titles!
Managers deal with unrealistic salary bands via title inflation when they can, but sometimes their hands are tied. I joined a team that did have the freedom to use title inflation and ended up with a principal title in a team with more principal engineers than non-principal engineers.
The key element is that you are half technical and other half people. You could say the other half is political, but that's just what happens when you get a bunch of people together. The key is that larger companies are hard to steer. You can't have N engineers in N directions, and you need to point them in direction.
The way I look at it from a technical perspective is ensuring that the game being played is winnable. Is the project going to work? Or, is this a death march waiting to happen? Do people know what they need to do? Do they have the tools and knowledge? Are stake-holders bought into the picture? Is funding going to endure the march?
The title is entirely useless if you are not in a large organization. Turning the ship even 1 degree is a lot of talking and organizing... Meh...
I like to build, but I'm happy to never build a pyramid again.
And in most cases, that's in addition to writing code. One of my last job descriptions as a Staff Engineer had me writing code about 10% of the time :-(
Does this meaning providing tactical insight for the project? yes.
Does this mean questioning priorities and aligning priorities? yes.
Does this mean that making sure the department is sustainable on hiring objectives? yes.
You could say that the role is being a smart technical person that is responsible at the level of "almost stake holder". A key thing here is that a principal engineer should also have significant stock. At a big company, this should be in the seven figures.
Not intended to quibble, but to me that smacks of the dreaded "mid-level management" tier.
As a lead or principle, I describe what I do as being a "fire-and-forget resource". I build everything myself and don't require supervision. I will deliver regardless and am also able to justify my decisions. People seem to be happy so far.
That process is almost completely independent from meat-space concerns, aside from the requisite UX design.
Terminology is subjective of course, but:
I would also expect the above from a "senior" developer.
I would expect a "lead" developer to additionally be involved in leading a team and coordinating work within that team. (either from a project, people or tech perspective, or all/both).
I would expect a "principle" developer to be working at a higher level coordinating work between multiple teams and making architectural decisions that cut across the whole org or a large subsection of it at a larger company.
Some career ladders allow for this, others are more rigid about the size of team you need to be directly leading .
That's generally more than you'd expect from a typical Senior Engineer.
Reminds me of the classic: https://www.ribbonfarm.com/the-gervais-principle/
A colleague of mine at previous company once described all this in two words "managing expectations" :)
The problems we’re solving at these jobs (I reserve work for its meaning in physical systems, jobs/career for you know), are ostensibly people problems. So the decisions I make are optimized for that. I don’t call it politically optimal, but optimal, because that’s it; that’s THE game of life.
It’s subtle language emphasis maybe, but I used to visualize my thoughts as a text stream and “rewrite” constructs I did not appreciate in the moment. Redefining ideas like “optimal” to be human first behavior. Ideas like “optimal technical solution” are boxed away for when I’m working.
It helped me understand managements drive, to have folks doing useful things, but also made me question how useful much of this is except as busy work.
I think there's a continuum of political savvy, though, where most developers have some level of it. For example, if one of your developers creates a new service using a technology that is new to the codebase, and half of the senior developers say, "Ugh! I'm not touching that. It's just <developer's name> showing off his big brain. I'm not wasting my time figuring out that unnecessary academic crap," you can understand how that was a failure even if a purely technical evaluation concluded that the learning curve was reasonable and the benefits outweighed the effort required. Before committing to the technology, it was necessary to introduce the idea in a way that got the senior devs to buy in, and if you can't accomplish that, you can't use the technology at all, because it's going to create morale and social problems as well a creating an isolated service that few people will work on.
That's a basic level of political savvy I think most people can relate to, so, if you can understand that much, you have a base to build on.
At the big tech company I work at, we're often told that even even senior is primarily a non-technical designation. Technical expertise and independence is expected of the level below senior, and in order to make the jump to senior you need to demonstrate leadership and other for skills - influencing others, project management, coordinating between teams, etc. Principal is a level above that that is kind of the same but more.
All this to say: every company is different.
I'm a Principal Engineer, not at a FAANG, and that mostly means i'm an expert at what I do and know the product inside and out, and I spend a good amount of time coding. I do also help others, answer questions, and deal with complex problems. I'd say I do 80% coding and 20% meetings / other things.
I interviewed somewhere else and they wanted me to do 50% coding and 50% meetings / other things. Was a bit surprised, since i'd personally rather code and keep my skills up.
My take is companies should have their top engineers spending a sigificant amount of time coding, or at least architecting, but I could imagine, and have read, that at FAANG sized companies it becomes more political? Also with so many employees I guess in theory the idea is to have Principals spend more time leveling up the rest of their workforce? In practice does that happen?
On the whole my responsibilities are a mix of things:
1. Technical strategy - primarily writing strategy docs and discussing with other tech PEs. Usually precursor to architecture.
2. Business Strategy - reviews with non tech staff and leadership (across the org) about what the business needs are, where we see the future going. Often takes the form of reviewing other peoples documents or contributing sections to those
3. Product design reviews - reviewing CX/UX documentation
4. Architecture - Creating architecture documents - lots of text and boxes and lines. Several rounds of reviews. Usually precursor to coding or reading other people's code.
5. Coding - takes the form of staring at various IDEs and scratching my head.
6. Reading other people's code - same as above. Also include code reviews.
7. Operations - On call stuff. Usually where all the architecture stuff falls apart :-)
8. Mentorship - structured 1:1s, feedback, etc
9. Prototyping and demos
I spend probably 90% of my time doing the items above. The mix among these items varies but I consider all of it my work. For the rest I sometimes get pulled into the items below that are not officially my responsibilities
- Conferences and public speaking - I could, but choose not to
- Project tracking and reporting
- Managing people's careers directly
- Funding decisions
My work is rarely political depending on how you define politics. To me politics is about "who gets the cool stuff" so mostly funding decisions. I do get pulled in occasionally to sort out "who should build this" discussions but they are usually good faith discussions trying to align expertise and charters before funding decisions are made. Biz and tech strategy does involve consensus building but I suspect the Real Politics™ happen behind the scenes at higher levels.
A lot of programmers ignore the fact that they're serving a business function.
It does feel like some folks ignore the business side of things but I think I enjoy being a part of the larger picture. It's definitely not for everyone. I know several people who are personally happy and have had WILDLY successful careers being hands-on tech specialists and ignoring the business side. It's great that it works for them.
The three rough metrics I’ve heard for how staff/principals are evaluated are “creating clarity”, “impact”, and “leadership.” Those metrics are all very difficult to perform on if I were focused on my code related output as an individual, although there are people who make and achieve within that level in my company who do more straight up coding then I do. The important thing is good judgement on where to spend your time to have the most impact.
If you wanted me to put numbers on it, I’d say my time is probably 25% coding, 20% meetings, 20% working on infrastructure and tools, 20% documenting/communicating, and 15% mentoring/recruiting.
The bits that people don't talk about frequently are things like "what do you actually do in the 20% of the time you are coding?" It's usually things like performance analyses and optimizations, solving misc tech debt that I have the flexibility to work on since my time isn't allocated to project teams/squads, architecture and PoC work for new capabilities we think we will need, and honestly sometimes its just picking up a couple super low level tasks anyone could do because keeping team members focused on other things is what's most important.
At least in my org the common theme is almost always "there's a hard problem over there, go help them fix it'.
Source: principal engineer for a couple years, senior for 6 or 7 years before that. Not at a FAANG, but in a ~350 person technology org at a company with nationwide offices and consumer product presence in the USA.
My main duties are that I lead a team of 7 engineers and we all work on open source security projects.
My day is a mix of half coding / half meetings. I am UK based, so my mornings are nice and free (while the US sleeps) and then around 2pm I have a large chunk of meetings. The meetings are mostly with my team, senior management, and open source community meetings.
For me being a Principal is a much more than just coding prowess. You also need good 'soft skills'. You need to mentor engineers and think about their growth. Make sure they are challenged enough to grow, but not so much that they end up stressed and out of kilt. You need to be able to communicate with not just other software engineers, but also product managers, directly with customers and many other verticals within a business.
Like engineering managers, I am responsible for planning out a team's long term goals and reporting on them to senior management. Also like engineering managers I'm responsible for hiring and evaluating technical talent, particularly the senior software engineers in our org plus people who are under consideration for promotion or hiring into my level.
Unlike engineering managers, it's important that I do "hands on" work. This includes my own tech designs and coding, but much more reviewing the designs and code of others. I see my job as delivering technical artifacts through others. What's different between the principal/staff role and the senior eng/tech lead role is the levels of indirection. For a senior eng, you are generally owning the output of a team of people (roughly 3-7 people, though it varies).
At the staff/principal level you work at the level of a team of teams, so your job is really to develop and mentor the tech leads of those teams. Occasionally you might be called in as a tie-breaker or to assist on some cross-team issue, but ideally that doesn't happen too often because the tech leads know their stuff (and they'd better because there is no way you can know the details of multiple team's worth of systems).
My relationship with my manager was much more of a peer partnership than manager/IC. I let my manager know what I was up to, progress on things, and any challenges that needed help. The latter bucket was usually empty, but occasionally some cross-org priorities need to be clarified and sorted out.
As others have noted, it really varies between companies, but the main difference between Senior/Staff and Principal is that the latter can be a much more "people" oriented role. You still own and carry the technical vision, but you increasingly interact with non-technical people to enable it and to make it happen.
To all the managers out there please make note of the above. Do yourself a favour and please give senior engineers enough autonomy and freedom.
At my previous place I managed a senior engineer and made it amply clear to him that we are peers. Between us my job was to handle all the bureaucracy (including scheduling meetings, finding meeting rooms etc.,) and his was to be the team's tech lead.
Principal Software Engineers are essentially the Engineer Owner of a solution or closely related set of solutions.
They're expected to know the ins and outs of the solution both at a business level ('Hey, Principal, how much would it cost and how long would it take to do 'x'?' -- Some Sales Person), and have responsibility for the solution's engineering ('Two months? Great! See you at the February demo for the users group!' -- Some Sales Person), and be able to solve the more difficult engineering issues that crop up ('The app you promised to integrate with by February only uses SOAP and consists of around 14,000 on-prem installs...I graduated after the year 2000 so I'm not sure how SOAP works, can you walk me through this 'wizdal' thing?' -- Some Senior Engineer that you asked to look into the new project).
The definition bullets will probably be highly dependent on the company and while companies will likely copy those, they are likely not even transferable within a company, let alone across different companies.
For example, within company A, Mike is a manager that is a perfectionist leading a Java EE mid-sized application. Mike is hard on himself and is hard on his people. His people are probably underpaid, and that's how he likes it. Getting to a senior level is difficult. Getting above is political.
Within company A, Janet is a manager leading a relatively recent PaaS offering. She likes nimble, agile teams. She rewards quick thinking, wants her team to be satisfied, and gives her team yearly stock options because she doesn't want anyone to leave. Getting to a senior level is fairly manage-able after 1 to 2 years, provided one is viewed as a senior. Getting above is doable, provided one has peer support.
Now, company B is a consulting company that wants to offer "senior" engineers for $1000+/hour. They never hire anyone with the title "junior" (not even fresh grads) and promote practically everyone after 8-16 months to a senior title. Principal level is then another 6-8 months away, but they have very few of those due to insane attrition rates by that point.
I really started to see the value once I moved from Principal to Manager. All of a sudden I was busy with boring manager stuff and needed an IC who could get deep into the details of our initiatives and make sure everyone's efforts were lining up. You don't need the title of Principal to do this role, of course, but ICs who see the big picture and understand what's important for the business are invaluable.
The other points in the article are on the money as well, especially around modeling and amplifying a good dev culture for the organization.
That $800k number is more accurate for staff/senior staff.
All the principal engineers I have worked with have been humble and ego-less engineers. There’s this notion that they just write docs but they’re invaluable code/spec/design reviewers, they have taken on major refactors to tackle tech debt that just lingered for years, and have generally unblocked me on so many occasions. The strongest principal engineers have never taken credit for massive projects they have orchestrated but “everyone knows” they’re valuable.
It takes a lot of skill, and I’ve found they switch between the “archetypes” effortlessly. Beyond that, they’ve helped me grow in my career and find impactful projects that look good on perf reviews. In my mind, the good ones are definitely worth their cost.
Senior and principal prefixes are there to provide respect in orgs that rely on titles for respect (possibly a sign of toxicity), or a way to explain to HR why someone's salary is higher.
This is exactly how my company motivated it when I asked for a higher salary.
Whoa, that is a cynical take and smells a little of sour grapes.
I 100% agree that the PE title is abused both out of nepotism, and out of site-wide populism, but the intent is relatively pure, at least at large companies where the title actually matters:
There are some engineers that are so good at solving problems that they can be dropped into any crisis situation and help fix it, like a special forces soldier. After 30+ years in engineering I've seen them in action, and most of the time they deserve the title. They are just that good. Those are your PEs.
However, you need a large enough sample population to produce PEs because it is based on relative performance. It is harder to identify one in a group of 10, but in a division of 1000 it becomes abundantly clear.
Typically how you become a PE is by waiting in line and keeping at what you do, because usually there are only so many PE's promoted per year to help mitigate abuse of the system (there will be some in bigger organizations). This idea of being selective is ... misguided. You don't really have a choice.
Now combine those last two paragraphs and I can see how it appears there is room for gaming the system by only picking cherry products. However, it is unlikely you would be able to say to a VP or GM, "Hey, I want to work on THAT project, not this crap one you stuck me on, because I want more visibility for promotion!" Maybe that'll work, but good luck?
I think this is very dependent on the incentives that are set up for the GM. If they're being judged on how they're developing their org, and number of promotions is looked at, now they may agree with you that the non-crap thing is the best thing to work on.
There's also the more implicit side of it, where if you're just generally good at what you do (or more cynically, if you're on the manager's good side for whatever reason), they'll be more inclined to let you work on what you want regardless of the motivations.
I agree that "the solver" is one flavor of the role, but I think there are a few other valid ones too. Many of the staff+ engineers I've interacted with fall in the "tech lead" or "architect" category.
Me? I just want to write, improve or even remove code to make software better.
tldr; it varies from company to company.
In my experience the more senior you get the more like an organizational therapist you are expected to become. Instead of writing code you're helping engineering teams and executives communicate, fixing communication silos, writing specifications and requirements, reviewing progress on large multi-team features, and generally trying to move the ball on big-picture projects that span multiple feature teams/code-bases/etc.
This kind of work needs high-functioning social skills, excellent written communication skills, an ability to understand a large problem domain and all of the organizational levers you need to move to get it done. You'll also need to be able to tolerate long feedback cycles as the projects you take on will probably take months to see the light of day and you won't be writing the software yourself most of the time. At most I've seen engineers at this level write prototypes or reference implementations. Some enjoy it while others quickly learn that staying at a senior level was probably better for them.
The interview itself is here: https://softwareengineeringdaily.com/2020/10/29/staff-engine...
I like this type of work, gives good exposure to new tech and the ability to choose what tech is being used. For my next job I want something more focused on actual programming though.
Microsoft's Principal Engineer is much more junior than at these companies. It's more like Senior/Staff Engineer. Amazon (headquartered in Seattle like Microsoft), also has a Principal Staff Engineer role which is less senior than Principal at Google and most other Bay Area companies, roughly equivalent to Senior Staff at those companies.
Many of them can not really code anymore, just like those system architects.
I do respect those who can both talk and walk: design the system, write key sample code for major components, and let the team to enrich and expand.
If they only know how to write design documents(talk the talk), I can hardly trust them that much.
Look at https://www.levels.fyi to compare companies, but yes overall 800k to over 1 million is quite common for a Principal and typically it requires about 10-15 years of experience.
Even if you're confident they do have immunity, and that there's no way to pierce through their immunity, there's still opportunities to have a positive impact. A great place to start is with junior employees: every time there's an incident, reach out to them and let them know that this behaviour isn't normal or acceptable. Junior employees are in the worst position: they don't know what is normal and what is not. As a senior employee, you can say with confidence whether behaviour is normal or not, and so just saying "this is not normal" can make the world of difference to someone junior. Also, depending on the organization, reporting incidents can be useful even if it feels like you're just shouting into the void: you never know when these reports will come in useful.
Junior software engineer: arrogant, self-entitled child who thinks they know everything but doesn't even know what they don't know but insists that their ideas are better, creating a people-hostile minefield across the org.
I have met some amazing people that were tech leads during my career. Some of them titled as principal software engineers.
Sometimes it can be hard to find friendly and kind teams. But they do exist. I promise.