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

261–270 of 337 posts

Re: On Being a Principal Engineer

#261

Post by ww520 »

techslave wrote: post #101
ww520 wrote: post #78

Those stated in the blog are leadership stuff which team leads and senior engineers need to have. Principle engineers are simply people who can design and build a major product, a major project, or even a company's technology by themselves, alone if needed to.

no way! principal engineers are those who have the technical vision and understanding to build a product by themselves. And the people and leadership skills to lead a large multilevel team of engineers to actually do so. a project that could actually be built by a single person doesn’t have enough scope to warrant “principal”.

The sounds like a manager or a VP.

Re: On Being a Principal Engineer

#262

Post by firebones »

dehrmann wrote: post #73
twblalock wrote: post #35

Earlier quoted context omitted.

Tribal knowledge is good to have, and inevitable, but it is also a blinder that tends to limit people to a particular set of architectural assumptions, and this gets worse the older the company becomes. It’s also an obstacle to bringing in new people. Some people are able to join a company and expand/modernize/build on the tribal knowledge to make things better. It’s a rare gift but I’ve seen a few people do it. Peop…

I've seen engineering leaders at companies with lots of tribal knowledge who have been there so long and are so committed to and defensive of old decisions that they're net negatives to the company. They're like helicopter architects.

I've seen that too. And I've also seen some of the same people with very adaptable personalities who are continually learning and inquiring and who make working at such places tolerable.

Re: On Being a Principal Engineer

#263

Post by hk-mars »

mlthoughts2018 wrote: post #113
solipsism wrote: post #96

Earlier quoted context omitted.

I ... earned a lot of technical respect from my teammates, but nobody cares at all about my perspective on architecture, scoping, technology investment, tech debt, etc. How does that work? All the things you talk about are folded into my concept of "technical respect".

In fact they are not at all related. The engineers on my team bought into the ideas I was bringing as I rolled out implementations that proved the value. Management however was less interested in increased value and more interested in entrenching their existing status and authority levels even if it meant torpedoing obvious and proved-out value-additive / cost effective engineering projects.

so I think this kind of managers is the “shit” :)

Re: On Being a Principal Engineer

#264

Post by 2muchcoffeeman »

beaner wrote: post #179
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…

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.

The OP was frustrated about having to prompt interviewees to talk about their accomplishments and how they always talk in first person plural.

I am in support of this being the natural way of thinking. No one could do what they did without support.

I am also vaguely suggesting that maybe every company’s process of promoting, hiring or giving out bonuses is wrong.

Re: On Being a Principal Engineer

#265

Post by greg7gkb »

kentosi wrote: post #208

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?

I don't believe this claim is correct... all 5 submissions were made by different users.

Re: On Being a Principal Engineer

#266

Post by indogooner »

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

Yes I have seen Principal Engineers with 20 years of experience. And no it is not a coincidence. Those who stay put tend to get promoted earlier because of tribal knowledge they have. They may be lacking in core tech skills but they are still more valuable for management than people hired from outside due to their insider knowledge esp. if the work is not that technically challenging (crud apps/some business logic)

Re: On Being a Principal Engineer

#267

Post by hvidgaard »

scarface74 wrote: post #147
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…

I’ve been working 20+ years and have been on the job market 7 times and dozens of interviews. I’ve only been asked algorithm type questions twice. The first was back in 1999 at my second job where I would be doing a lot of complex cross platform C and the second in 2016 when I was asked to write a merge sort. I turned down the offer in 2016 to work as a dev lead at another company even though the company doing the al…

I'm on the fence about that. Interviewing a senior developer, my experience is that it's still necessary to gauge their ability to code. Some can barely do it, I kid you not!

An if you claim seniority, I expect you, if not to know merge sort, then to understand it quickly and make a simple implementation and assume boring stuff like the length of the array ect. It is not difficult. It would be a great example to demonstrate programming proficiency and if you didn't know merge sort, how you grasp new problems.

I would put more weight on architectural discussion though.

Re: On Being a Principal Engineer

#268

Post by closeparen »

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…

Unless all your company's projects are uniform, there's probably some informal ranking of who can be trusted with the biggest and gnarliest objectives. For us, the title Principal just formalizes your position at/near the top of that ranking for the entire engineering organization. For a division it may be Staff. For a line manager it's Senior.

Re: On Being a Principal Engineer

#269

Post by nickm12 »

gnulinux wrote: post #86

Should principal engineers necessarily be managers? My company has non-manager principals, manager seniors, manager principals etc... Manager is just an extra title added to someone to give them extra responsibilities, regardless of their engineering experience. Is my company different than "usual"? I don't know how they decide who is senior who is principal, but principal engineers are absolute rock stars. They know…

I think it is just the opposite. Principal engineers are PEs because they don't want to manage people but instead be responsible for technical systems. That said, I've seen PEs be managers of small teams (~4-5 engineers) for short stints when the org had a need and there wasn't anyone else to manage.

Re: On Being a Principal Engineer

#270

Post by nickm12 »

austincheney wrote: post #105

> It surprises me that many shops still claim to have a ‘flat org’ What is the rationale behind a flat organization?

The argument for "flat" is that management is waste and unnecessary process—you should just give smart people rein to attack your problems.

This notion is idealistic and appeals to people who have been burned by bureaucracies, but it denies the important functions that good management provides in setting priorities and coordinating work.

I once saw a case where a team switched managers and the team's output nearly doubled. Was the team suddenly better engineers? No. They were a fine team, but the manager worked to get everyone on the same page and ensure that their work was connected in a way that it had a multiplicative effect. Rather than everyone working on isolated projects, the projects leveraged each other to be much more valuable.

Post reply on HN