Live data from Hacker News

On Being a Principal Engineer

blog.dbsmasher.com

21–30 of 337 posts

Re: On Being a Principal Engineer

#21
post #6

Earlier quoted context omitted.

Which is interesting to me, because once you get to staff inside such a company, how would you move to a different company? Are you locked to the company because any other move would be a drastic reduction in comp (because it would be a drastic reduction in value)? Or are there transferable skills that are valuable enough that a transfer could happen at roughly the same comp level? I don't know but this is an interes…

Staff/principal SWE compensation is the premium an org pays for your tribal knowledge, and arguably non-transferable. “Golden handcuffs”.

Outside the big companies in Silicon Valley there are no golden handcuffs for engineers. With each promotion you make just a few percent more.

Re: On Being a Principal Engineer

#22
post #8
post #3

Interesting article. A lot of the qualities the author descrives as required trains of a principal are things I always say a senior engineer/tech team lead should have—e.g. ability to act as a force multiplier, leading by example, and being active in less technical activities like mentorship and recruiting. Am I off the mark? I suspect I may just not have been at enough orgs with a well developed career track, what t…

This depends on the culture & hiring philosophies of the company. I've seen many places that "only hire the best" or "only hire seniors" then end up with a bunch of engineers who dont mentor or force multiply but tend to just focus on what ever pice of a system they own. I've also seen senior used only to justify a pay bracket as well. Personally I agree that a senior or lead enginner needs to have these skills.

I’ve been at the kinds of places you describe as only hiring seniors. I’m personally not a fan of that kind of mentality for a few reasons:

1. (In San Francisco) This can lead to reqs being open for way too long. My company had several roles open for upwards of a year and wouldn’t back off until I convinced my manager that we could train/mentor a less experienced hire to fill those reqs faster than we could fill them directly.

2. I think teaching a skill is important to the development of a skill. It forces you to distill what you do know, and articulate it in a way others can understand. This process is a huge boon to a lot of other traching-related soft skills as well.

3. (Personal opinion) I think we a professional, perhaps ethical, responsibility to improve the quality of our craft. I don’t think most places know how to write and maintain software well as an organization. The state of software as a profession will not improve until we raise the lowest common denominator and do a better job disseminating hard-earned lessons and best practices.

Re: On Being a Principal Engineer

#23
Unfortunately the Principal title has been abused and cheapened by some orgs. In some ways necessarily, as comps in tech have grown it’s become necessary to hire people at a Principal level in order to get the necessary comp. In other orgs it’s been a way to lure people who are attracted to the title. Ideally Senior positions would be more respected and have a greater comp range. But now it feels like Senior is almost entry level for some companies.

Re: On Being a Principal Engineer

#24
Though I am a principal that tracks very closely to what this article describes, I think eng organizations need both "broad" and "deep" principal technical roles.

E.g. at that level, the road forks three ways: deep principal ("pure" IC, & an expert in an area), manager, and broad principal (the hybrid force multiplier role).

The tricky part is making sure that the deep role doesn't devolve into promoting people purely on technical merits, and being blind to their cultural impact. Everyone at that level is a role model, for better or worse.

Re: On Being a Principal Engineer

#25
post #6
post #4

Earlier quoted context omitted.

I think you are right that seniority at the specific company plays a large role. Anecdotally, I was told that GitHub does not hire from the outside above the senior level. Going from senior to principal engineer is expected to happen inside the company.

Which is interesting to me, because once you get to staff inside such a company, how would you move to a different company? Are you locked to the company because any other move would be a drastic reduction in comp (because it would be a drastic reduction in value)? Or are there transferable skills that are valuable enough that a transfer could happen at roughly the same comp level? I don't know but this is an interes…

Senior levels often have pretty wide bands, partially due to this. If you're moving to an organization that hires as senior, you'll almost certainly be able to negotiate your comp pretty far up

Re: On Being a Principal Engineer

#26
post #7

Is there a path where one can get to work on code without getting to design and architectural space. Is this thought as career stagnation when someone doesn't wants to work more on higher level design and to remain close to implementation side of things?

You can totally do that in a FAANG. It's hard, but it's a recognized archetype.

Re: On Being a Principal Engineer

#27
post #13
post #5

Earlier quoted context omitted.

In my experience it’s rare for orgs to hire for principal/staff/architect roles. What I’ve seen instead is people getting hired on as senior engineers and get promoted up from there after they’ve settled into the org.

And at some places the "senior" engineer IS the principal/staff/architect.

[deleted]

Re: On Being a Principal Engineer

#28
post #13
post #5

Earlier quoted context omitted.

In my experience it’s rare for orgs to hire for principal/staff/architect roles. What I’ve seen instead is people getting hired on as senior engineers and get promoted up from there after they’ve settled into the org.

And at some places the "senior" engineer IS the principal/staff/architect.

Company size seems to (rightly) play a role in how many levels there are in the career track. Part of the mentality that the business needs to take off before titles are concerned. However, this would most likely apply to <20 person engineering team. If the engineering team is bigger than that, I'd question why the org structure is flat.

Re: On Being a Principal Engineer

#30
post #19
post #2

This rings true to my experience. I'm a Staff engineer and of my 40 hour week about 10-15 of those hours are interviews, meetings, and answering questions. Questions about technical feasibility, architectural discussions and planning, long term strategic planning, and lots of one offs from other developers. I enjoy the soft work I do, a lot of emotional labor for other developers, soft sells for tech/feature work aro…

"But I am also at this weird point where I am not sure if the title of "staff/principle" can be transferred to another company. A lot of the value that I add now is because of the historical knowledge I have. What we have tried as a company, what we haven't, why we built some things the way we did, how things work currently, how the politics works and the trust I have built. " This worries me too. Within my company I…

Market forces can be tough to predict. There was a dearth of software engineers in the last 8 or so years and many of us have reaped the rewards. The hacker news articles used to be about switching jobs every 1-3 years to advance your salary and career. I don't see so many of those these days, which makes me suspect that many have found themselves in senior-level or managerial roles that they find satisfying, and maybe some found themselves in architecture roles that are very difficult to advance from (but still pay well).
Post reply on HN