Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Being a Principal Engineer

blog.dbsmasher.com

Post reply on HN
Print view View original

201–210 of 337 posts

Re: On Being a Principal Engineer

#201

Post by alexandercrohde »

deleted_account wrote: post #80
erikpukinskis wrote: post #71

Earlier quoted context omitted.

The two examples you gave, linting and tabs, aren’t architecture at all. They are toolchain. Architecture is questions like should this class of functionality be services or objects and why? Do these 3 functions belong in this class, or should they be a helper? Should this helper be copied between repos or be a separate module with a formal API? I agree with your point though that every engineer makes the decisions a…

These and the parent's examples are very team-centric. The heuristic I use when thinking about these engineering roles is, "Where is this person expected to be a leader?" The progression is usually: Team, Cross-team, Organization, Industry. Competent technical decisions are table stakes. The real differentiator is at what level can they effect change.

This is the very thing I'm criticizing.

"Leader" is one of the worst buzzword bingo terms in a company. It means nothing, it's just a convenient label to give people who you feel like promoting to maintain the 10:1 ratio.

You could argue Linus Torvald is an industry leader, or you could argue he doesn't show adequate leadership for cross-team.

Re: On Being a Principal Engineer

#202

Post by pvarangot »

mlthoughts2018 wrote: post #37
d4mi3n wrote: 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.

I was hired into a company as a staff engineer, and I probably won’t consider it again. The existing engineers resented me for it, though it was super clear that the product was suffering because the existing engineers had serious skill gaps in critical areas. Meanwhile, to other managers & directors, I was just some new engineer they didn’t know, a political unknown quantity. I hit the ground running and earned a lo…

I think a director should only kind of "put value" to tech debt, making the mid-term and long term choices and assessing the risks. How to do the actual tech debt emission and how to deal with it when it hurts is more of a staff engineer thing.

If you think that as a director you'll have "power" to make actual week to week or month to month architectural or technical decisions you are thinking more of micro-managed projects and not of serious mid-sized or bigger engineering organizations.

Re: On Being a Principal Engineer

#203

Post by pvarangot »

maxxxxx wrote: post #21
toomuchtodo wrote: post #10

Earlier quoted context omitted.

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.

This is not true in engineering contractors for aerospace in Europe or the USA, and it's also totally not true in the oil industry worldwide and in some of the big manufacturing firms. You can get double digit percent promotions by getting into roles that require a lot of travel, dealing with big outsourced contracts, have cross-country responsibilities, or other particular skills or layers of hardened skin that are hard to come by and at a premium.

Re: On Being a Principal Engineer

#204

Post by scarface74 »

discordance wrote: post #153
aqwsedopl wrote: post #117

Earlier quoted context omitted.

Promotions are just a form of vendor lock-in that (especially) small companies employ to keep people longer. I’ve seen barely two years out of college non cs majors promoted to senior engineer based on finishing some “large project” which anyone else in the engineering team could have done. The real sleezy thing is that by promoting someone to senior who isn’t nearly qualified at all, the company has now made it expo…

This applies at both small and large companies alike

I don’t care about titles at all. I care about three things when it comes to my job:

- Technology/Career enhancement - where will this job put me in three years if I want to find another job

- Environment - I’ve grown increasingly picky about my environment and work life balance.

- Money - at least pay me the local median wage for what I bring to the table. Don’t insult me. But beyond that, money is the least important criteria.

Re: On Being a Principal Engineer

#205

Post by mlthoughts2018 »

pvarangot wrote: post #202
mlthoughts2018 wrote: post #37

Earlier quoted context omitted.

I was hired into a company as a staff engineer, and I probably won’t consider it again. The existing engineers resented me for it, though it was super clear that the product was suffering because the existing engineers had serious skill gaps in critical areas. Meanwhile, to other managers & directors, I was just some new engineer they didn’t know, a political unknown quantity. I hit the ground running and earned a lo…

I think a director should only kind of "put value" to tech debt, making the mid-term and long term choices and assessing the risks. How to do the actual tech debt emission and how to deal with it when it hurts is more of a staff engineer thing. If you think that as a director you'll have "power" to make actual week to week or month to month architectural or technical decisions you are thinking more of micro-managed p…

I mean the general prioritization of tech debt as a continually worthwhile time investment / required basic hygienic activity necessary for product health.

As a staff engineer, I provided inarguable evidence that tech debt had been ignored to the point of extreme risk of product failure and revenue loss, along with well-scoped and iterative approaches to pay down the tech debt with ideas and creative effort from the existing tech leads and experienced engineers.

It was just squashed for political reasons. In this case, product management happens to be the part of the hierarchy with all of the “the buck stops here authority” and since tech debt did not contribute to visibly obvious progress on vanity features and cosmetic product changes (that had not been rigorously derived from product feedback, expertise or needs), then tech debt was disallowed from entering any quarterly goals, etc.

Director or certain “org wide” IC roles could plausibly have authority to stop that.

Sorry if I have the impression this was about micromanaging weekly tech debt stuff... definitely not.

Re: On Being a Principal Engineer

#206

Post by nichochar »

Principal engineer in that kind of company does not at all mean the same thing as principal engineer at google, amazon, facebook, twitter, pinterest, airbnb, etc.. (and even those aren't equal).

The article is still good, but confusing names is a big problem for us engineers. "Senior", "staff", "principal" mean nothing if they don't mean the same thing cross-company

Re: On Being a Principal Engineer

#208

Post by kentosi »

Sorry this is off topic, and I only found this out because I accidentally clicked on your alias rather than the topic.

You've made 4 other exact posts in the last 12 days: https://news.ycombinator.com/from?site=dbsmasher.com

Is it common HN practice to report the same thing until it finally gets attention?

Re: On Being a Principal Engineer

#209

Post by Klathmon »

phkahler wrote: post #199
jameshart wrote: post #120

Earlier quoted context omitted.

The challenge I have interviewing people for very senior engineering roles is how to tell the difference between somebody who was nearby when some interesting work got done, and somebody who made something interesting happen . What I’m looking for in a principal engineer is someone who turns good teams into great teams; who steers the organization away from disastrous mistakes; who enables the business to accomplish…

That's the challenge in all engineering interviews - determining weather they did anything useful or were just on the team. I've had to tell people to stop telling me about "we" and tell me what "you" did. Some people are so caught up in trying to be a team player that they hide their contributions. Others use it to hide their lack of contribution. It's not hard to separate these once you're aware of the issue and st…

I personally always talk about what "we" did because it helps me get out of my own way.

I worked at a company for like 6 years, and for almost 4 of them i was the sole engineer tasked with designing a database for the data, creating and deploying/maintaining an API server, and creating a handful of react frontend applications. The last 3 years we expanded into a "team" that I led and scaled it up from there.

I never talk about what "I" did because I'm always afraid it will come across as lying or exaggerating, and at the same time I know that I didn't do all that alone even if I was the sole contributor for the vast majority of it. I had managers that helped carve out time and lay out requirements, I had executives that were willing to let me make multiple mistakes as I found my footing, I had devs focused on other areas at the company that I could bounce ideas off of and learn new skills from. And to be honest there were some months that I was SO productive that I genuinely don't think I could ever do it again, and I don't know exactly why it happened.

I'm currently looking for a senior/lead job, and writing about what "I" did and what I feel i'm capable of is by far the hardest part of it. I feel like I flip flop between basically saying "I was part of a team that did awesome things" and "I did all this awesome shit all on my own", and in both cases it feels like i'm lying.

Once I'm talking to someone I feel i'm really good at talking through the choices and tradeoffs made, the mistakes I made, the parts of the job I'm good at and the parts I feel I'm not. But I can't seem to write that down well, and I think i'm throwing away chances because of it.

Re: On Being a Principal Engineer

#210

Post by bastawhiz »

nichochar wrote: post #206

Principal engineer in that kind of company does not at all mean the same thing as principal engineer at google, amazon, facebook, twitter, pinterest, airbnb, etc.. (and even those aren't equal). The article is still good, but confusing names is a big problem for us engineers. "Senior", "staff", "principal" mean nothing if they don't mean the same thing cross-company

> "Senior", "staff", "principal" mean nothing if they don't mean the same thing cross-company

Exactly this. At least three times, I've had EMs or recruiters approach me and ask about the titles at a previous company. "We've got a candidate that's coming in as a senior staff engineer, but they seem pretty junior." I've been around for hirings of "senior" engineers that come in at a junior engineering level (salary, I don't know).

A lot of companies hand out promotions like candy to keep people around. Companies that don't need to hand out promotions have titles that actually mean something. But the companies where title means nothing muddy the water so much that it's unlikely that title at a previous job actually means anything when changing companies.

Post reply on HN