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

171–180 of 337 posts

Re: On Being a Principal Engineer

#171

Post by james_s_tayler »

hellisothers wrote: post #85
nickm12 wrote: post #47

Earlier quoted context omitted.

An exception to this is the "boomerang" engineer, who leaves the company as a senior software engineer and is hired back as a principal/staff engineer. At my company, there is a belief that it's easier to become a principal by leaving than by going through the rigorous promotion process.

I am also experiencing this and thus am starting to look elsewhere (and others at my co. feel the same), I imagine it’s an industry thing but have been trying to figure out what the root cause is.

Supply and demand?

When you are employed they demand you show up every day and you supply yourself. There isn't an expectation that you wont supply yourself. After you leave but before you are hired back then there is demand but no supply. Leverage I guess. Makes sense to me.

Re: On Being a Principal Engineer

#172

Post by james_s_tayler »

tetha wrote: post #114
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 mean I'd consider myself somewhat experienced with the tech I have. But practically speaking, if you have a company with a somewhat established technology stack - or 2 or 3, commonly called legacy of some degree. How would you have a thoroughly constructive opinion on moving the tech stack away from legacy and towards a more productive situation, without understanding the needs, situations and interactions of a com…

This. This really is the value add and it's unique to every company, so it just takes time to learn.

Re: On Being a Principal Engineer

#173

Post by nilkn »

md5person wrote: post #104

I appreciate the idealistic take on what a "principal" role should be like, but in all actuality, principal engineers are commonly the ones that simply stayed there long enough (ie. to survive multiple re-orgs), and played their politics cards wisely. They were playing the title game. Often, their work is invisible to most. They perpetuate tribal knowledge, and have trouble letting go of the past and accepting change…

This sounds like standard title inflation, and it's not restricted to just technical ladders. It's certainly a problem, but I don't think we should discount the idea of principal engineering roles just because job titles can be misused or abused.

The company I'm at has a single principal engineer. He was hired externally. Within a year of starting, he'd had a bigger impact across teams than the CTO in the same time period. He doesn't necessarily write tons of code, but he's also not sitting in an ivory tower telling other developers what to do. Rather, he very quickly got in tune with the sorts of technical problems being faced by basically every team and developer at the company and started introducing various techniques and technologies to resolve pain points around the organization. Before long, we were doing things that wouldn't have even been possible before.

Re: On Being a Principal Engineer

#174

Post by scarface74 »

throwaway98988 wrote: post #158
md5person wrote: post #104

I appreciate the idealistic take on what a "principal" role should be like, but in all actuality, principal engineers are commonly the ones that simply stayed there long enough (ie. to survive multiple re-orgs), and played their politics cards wisely. They were playing the title game. Often, their work is invisible to most. They perpetuate tribal knowledge, and have trouble letting go of the past and accepting change…

Unfortunately, I have to agree. I've been hired into an informal "staff/principal" role for my part of the organization and it's simply impossible to work. The other staff/principal engineers I see here are exactly how you describe. They are against anything that will make their roles as "the oracle" less important. Documentation is such a mess because of that and the onboarding process specifically says there are a…

I don’t get that but it does happen. I don’t want to be stuck working on the same project forever and the only ways I can avoid that is by documenting everything, using off the shelf widely used frameworks where documentation is available and cross training.

Re: On Being a Principal Engineer

#175

Post by zyncl19 »

jedberg wrote: post #129

Re: companies that claim to have a fully equivalent technical track: What I've found is that is mostly lip service. Yes, they publish salaries and requirements for the highest levels of engineering, and those salaries are equivalent to high levels of management as far as pay goes. But if you look a little deeper you see the problem. At Google and Amazon and Facebook, a Distinguished Engineer is equivalent to a Vice P…

I would argue that for a Distinguished Engineer to have as much impact as a run-of-the-mill VP, they have to be the best at the world at what they do.

Re: On Being a Principal Engineer

#176

Post by roel_v »

matwood wrote: post #118
tibbetts wrote: post #103

Earlier quoted context omitted.

Learn to talk about your accomplishments like an entrepreneur or executive would: impact with quantified customer and company value. Not “I switched our development from Java to Go” but “improved time to deliver new customer functionality from 8 weeks to 4 weeks through new platform choice. Improvements in agility yielded $8 million in revenue growth.” Another thing I don’t see enough in this thread is emphasizing so…

> Not “I switched our development from Java to Go” but “improved time to deliver new customer functionality from 8 weeks to 4 weeks through new platform choice. Improvements in agility yielded $8 million in revenue growth.” This is important for any level job. Java to Go by itself is really only interesting for a low level position. 8MM revenue growth is a person that will almost always get another look. In general,…

How does anyone quantify the value from something as generic as switching programming languages/frameworks to a number as specific as '8mm'? It could just as well have grown by that much even if there had been no switch. When I see formulaic nonsense like that in a CV, it better be meticulously sourced and they better be prepared to defend such a number in a potential interview, because usually I'll bin them with the other bullshit artists straight away.

Re: On Being a Principal Engineer

#177

Post by scarface74 »

xtreak29 wrote: 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?

How can you be a great cider without understanding architecture? Great coders are people who know how to bring business value.

That is unless you work for a company that is truly doing something unique or doing it at a unique scale.

Re: On Being a Principal Engineer

#178

Post by jedberg »

zyncl19 wrote: post #175
jedberg wrote: post #129

Re: companies that claim to have a fully equivalent technical track: What I've found is that is mostly lip service. Yes, they publish salaries and requirements for the highest levels of engineering, and those salaries are equivalent to high levels of management as far as pay goes. But if you look a little deeper you see the problem. At Google and Amazon and Facebook, a Distinguished Engineer is equivalent to a Vice P…

I would argue that for a Distinguished Engineer to have as much impact as a run-of-the-mill VP, they have to be the best at the world at what they do.

I agree, that's why it's lip service when they say that you can progress just as easily on the tech track because they "have the levels available".

Re: On Being a Principal Engineer

#179

Post by beaner »

2muchcoffeeman wrote: post #144
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…

> It’s something that comes hard to senior developers, because we’re all aware that every result is a team win. So when you’re asked about a project you worked on, you’ll tell the story all in first person plural: ‘we had to solve this problem, so we decided to use this approach’. As you said, good outcomes are team efforts. Even your best developer is not going to do anything great if he’s fixing bugs. Less senior d…

Why do you have that in quotes? They did not say senior roles are special.

They're just saying: acknowledge team wins, but you still did something individually, be able to explain what that thing was in detail.

Re: On Being a Principal Engineer

#180

Post by scarface74 »

solipsism wrote: post #108
lclarkmichalek wrote: post #26

Earlier quoted context omitted.

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

These companies usually expect advancement, and advancement requires participation-in/production-of higher and higher level design/architecture. You can hang around for a few years, but eventually people are going to ask why you're not progressing. Depending on the FAANG you'll either be stack-rank laid off, or put on a PIP and pushed to voluntarily leave. EDIT to add: On the contrary, non-FAANG is where you want to…

You can do that...work at a company and just make more money without learning anything new. But more than likely your job will end before you are ready and you will find it impossible to get another job. While I do think ageism is overblownef for experienced developers who have kept their skills current, it’s almost impossible for an older person who hasn’t kept their skills current to find work even as a junior developer.

Disclaimer: I’m in my mid 40s.

Post reply on HN