[hackingforfun]

For anyone who is a Principal Engineer at a FAANG, what do you do day to day?

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?

[topkai22]

Staff/principal level here. I accelerate my team. Sometimes that involves writing code, sometimes that involves teaching/mentoring others, sometimes it means improving our tools and processes, sometimes it involves hammer out our architecture and security approach, and sometimes it involves figuring out what baroque process I need to go through in order to get legal’s approval to launch our new product. I make sure almost all of what I do is well documented and communicated to the rest of my team.

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.

[jdc0589]

this is a great summary, and pretty much exactly reflects my role. My job is to help other engineers in our org be as productive as possible. That always means trying to include other people in what I'm doing from a mentor/career-development perspective, but otherwise follows your % splits pretty well.

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.

[hideo]

It depends.

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.

[Apofis]

I'm in love with #9. Looks like you have a good handle on the situation. The rest proves you're going places.

[hideo]

I admit #9 is fun but I try not to do too much #9, because there's a huge risk to doing too much of that: losing touch with what's important to the bottom line, and indirectly influencing all the other ICs that prototypes get you promoted. That's just not true in my company. My prototypes are usually for exploring something important to the company or validating a tech hypothesis of some sort. I try to spend more time writing production code where possible.

[Apofis]

I meant I love the way you phrased it.

A lot of programmers ignore the fact that they're serving a business function.

[hideo]

Thanks :)

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.

[Apofis]

Not everyone can do the same thing over and over again their whole life. Soon, I'm going to scream if I have to build another website or app... thankfully I'm making a massive career shift into Aerospace.

[decodebytes]

I am happy to be open here if it helps others. I am not with a FAANG, I am employed by Red Hat. My title is Senior Principal Software Engineer. At Red Hat it goes Software Engineer -> Senior Software Engineer -> Principal Software Engineer -> Senior Principal Software Engineer -> Distinguished Engineer.

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.

[nickm12]

I'm a staff/principal at a FAANG. My experience agrees with the other answers here that "it depends"—specifically, on what the larger org or team needs from me at the moment. There is a chunk of consistent work, though, which is somewhat of a mix between an engineering manager and an IC.

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).

[sciurus]

You might find https://staffeng.com/guides/what-do-staff-engineers-actually... interesting.