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

161–170 of 337 posts

Re: On Being a Principal Engineer

#161

Post by scarface74 »

ghevshoo wrote: post #156
dcosson wrote: post #137

Earlier quoted context omitted.

Just curious, in addition to looking for those things do you do all of the same types of technical interviews for a principal engineer as for other engineer roles? I would imagine a lot of principal candidates are older, maybe a little rustier at the rote algorithm type questions than a sharp new college grad. Do you expect a principal engineer to be along the lines of the best you've ever seen in every category, or…

Would love an answer to this question too. I effectively find myself in the role of a “principle engineer”. That’s exactly the reason why I was hired - with the expectations to be a “force multiplier” in the organization, which means I end up getting involved in many non-technical activities. My actual job title is just “software engineer”, but title’s don’t mean too much where I work (a mid-size bank in Europe). If…

It’s a continual dilemma for me in my career now as I hit the big four-oh this year, and trying to figure if there is some way to be just a regular “software engineer” without taking a big pay-cut.

Not that I’m looking to leave the company I’m working for now anytime soon, but I’m in my mid 40s and I think whenever I do leave, this may be my last full time software development job unless I find another small company I like as much.

My next job will either be an overpriced “digital transformation consultant”/“cloud consultant” or just a W2/1099 contractor where I come to work get paid and move on when the contract is over.

Luckily, I never have to worry about health care coverage again in 6 years since my wife will have guaranteed life long health insurance with her job after 10 years.

Re: On Being a Principal Engineer

#162

Post by tdumitrescu »

tibbetts wrote: post #103
maxxxxx wrote: post #81

Earlier quoted context omitted.

“Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills” Any ideas for doing this other having a lot of public visibility? I may have answered the question already but there may be other ways .

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…

Oh man, I see so many resumes littered with these kinds of statements. I totally gloss over them as they generally read like BS, and are formulaic enough that they just represent another "how to sell yourself" job-hunting checkbox point. Lots of devs would love to have some way to quantify our impact in monetary terms but the reality is that "process/tooling change X -> $Y ARR" is basically always hand-wavy made up math.

Re: On Being a Principal Engineer

#163

Post by barrkel »

OJFord wrote: post #116

In these org structures where Principal Engineer has significant say in technical decision making but no reports: a) are they (at least potentially) 'tech lead'; b) who is the manager of the rest of the engineers on the team? My only experience is with a full technical ladder being available, but the team technical leadership being the same as the team people management.

Orgs than blend people management with technical management seem suspect to me. You need to get elbow deep in problems to maintain the technical leadership and it doesn't happen often that you can do that if you're also in the middle of recruitment and communication and 1:1s and all the other machinery of management. Further, the authority of people management conflicts with technocratic leadership, which should be much more meritocratic.

People management requires a different set of skills to technical leadership. Looking to the same person to provide both is unlikely to be successful, IMO.

Re: On Being a Principal Engineer

#164

Post by fromMars »

javadocmd wrote: post #60
maxxxxx wrote: post #19

Earlier quoted context omitted.

"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…

I would argue that company-specific historical knowledge is not the value you (et al) are bringing. The value is the soft-skills of effective leadership that distinguish Principal from Senior (to use the article's parlance). Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills. And, of course, in finding a company and an interview panel that understands…

I am believer in promoting from within for the most part.

At the companies I have worked at, hiring people directly into principal roles hasn't worked well. Invariably, they struggle to fulfill that role because they don't have enough knowledge about the inner workings, code base, etc.

It usually takes them at least a year before they contribute at their level.

Re: On Being a Principal Engineer

#165

Post by bcherny »

enraged_camel wrote: post #143
johnwheeler wrote: post #138

Earlier quoted context omitted.

I would argue that a principal engineer who can’t function as an individual contributor is a less credible leader than one who could.

I didn't say they can't function as an individual contributor. I said they can't function efficiently as one. Meaning: the opportunity cost would be too high, since the alternative is that they help their more junior team members grow and also help the company make the right decisions when it comes to things like system architecture, tech stacks, features, etc. Those types of contributions can be several times more v…

Maybe what John is getting at is while a Principal can do that for a while, at some point their tech chops will get out of date and rusty, both in terms of industry knowledge and the company’s internal stack and best practices. At that point they may lose the respect of more junior engineers, which is a poor sign for company culture.

A senior IC that codes can stay relevant longer. The act of coding forces you to keep up.

Re: On Being a Principal Engineer

#166

Post by chii »

Swizec wrote: post #150
2muchcoffeeman wrote: post #144

Earlier quoted context omitted.

> 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…

> So why would we talk as though our specific roles were ‘special’? Because you’re selling yourself. Interviews are sales. You are the product. Not your team, not your boss, not your company. You.

Wouldn't that be just a round about way to lie about yourself?

Re: On Being a Principal Engineer

#167

Post by bcherny »

syndacks wrote: post #136
enraged_camel wrote: post #135

Earlier quoted context omitted.

>>I know a “principal engineer” who can talk the talk, write books and articles but can’t produce any software of real value, and I work with a guy that’s been working 1/8 as long as me and he’s ten times better. Perhaps you're measuring value too narrowly. A principal engineer can act as a force multiplier for the entire team, even if they themselves are no longer efficient individual contributors.

Can you elaborate a bit more on what you mean by "force multiplier" please?

Andy Grove talks about this in his excellent High Output Management, where he asks the question: how should knowledge managers (senior ICs) and people managers spend their time?

His answer is: on high leverage activities. Instead of fixing a small bug that affects a few customers, fix a big one that impacts revenue; train others to be better engineers, multiplying their future output; improve the process your team uses to build product. Essentially, look for activities that multiply output, rather than add to it.

Re: On Being a Principal Engineer

#168

Post by lucb1e »

johnwheeler wrote: post #133

Titles in software are so stupid. Where I work, everyone is “Software Engineer” whether they have 20 months of experience or 20 years. The respect and pay are commensurate with on-the-job performance and output. I know a “principal engineer” who can talk the talk, write books and articles but can’t produce any software of real value, and I work with a guy who’s been working 1/8 as long as me and he’s ten times better…

In my experience a 'principal' security consultant (I'm in infosec) is the same as the principal engineer you mention. They talk a lot but are so busy, they delegate everything and are very out of practice. If any actual work needs doing, they delegate not only because they don't have time but also because they would need to relearn and look up a lot of things. The junior and senior roles, however, are often pretty accurate descriptions, though the biggest difference is often in management skills and not in technical skills. Some juniors can't do anything and some are as good as some seniors will ever get, but in terms of talking to higher ups or negotiating between companies, there is usually a clear difference. And if a principal consultant still has technical skills, it's not noticeably better than a senior's.

Re: On Being a Principal Engineer

#169

Post by scarface74 »

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 know a (non tech) VP at a FAANG, his base salary is the same as mine and I am nowhere near SV/West Coast/NYC salary - he will get an extra $70K a year between stock and signing bonus. He asked me would I be interested, I told him that the pay difference wasn’t enough to make up for the cost of living difference. He then told me that most of the software developers make more than the non tech/business VPs.

Re: On Being a Principal Engineer

#170

Post by lucb1e »

erentz wrote: post #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 almos…

Additionally, it doesn't help that some customers of consultancies ask for senior consultants. Surely the consultancy firm wouldn't label some semi-juniors as senior just to be able to put them on more projects and/or sell them for more money?
Post reply on HN