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

151–160 of 337 posts

Re: On Being a Principal Engineer

#151

Post by scarface74 »

valleyjo wrote: post #90
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’ve seen this happen even within the same (large) company. Someone is a director level who has maybe 100 reports. The entire product gets cut. The IC’a find other jobs within the company. There are only so many Director level positions around and many of them are achieved organically. The ex-director then goes somewhere else as a regular engineering manager unlikely to ever have such a position again.

Three of my former managers “self demoted” to an IC because they didn’t really enjoy management. Including one of my former managers who is in his late 50s who self demoted after his kids graduated. Now he’s a full stack React/C#/Azure developer and said he threatened to quit his job when they tried to promote him.

Re: On Being a Principal Engineer

#152

Post by eeZah7Ux »

erikpukinskis wrote: post #71
alexandercrohde wrote: post #53

Meh, nonsense. Standard buzzword bingo. Every engineer I meet advocates for standards. Usually the more dogmatic ones are the worse ones. This doesn't make you a 10x force multiplier (telling people to lint makes them 2% more productive tops). Usually these "standards" people though have a negative effect because they get into a dick-contest over the most trivial details (e.g. tabs/spaces). Even if cross-team collabo…

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…

> Do these 3 functions belong in this class, or should they be a helper?

That's very basic design. System architecture goes up to: "how do we deploy 2 million hosts across 40 datacenters?"

Re: On Being a Principal Engineer

#153

Post by discordance »

aqwsedopl wrote: post #117
scarface74 wrote: post #111

Earlier quoted context omitted.

I absolutely hated my job as the dev lead for a medium size ($1 billion in revenue) non software company where we were a “cost center”. I liked helping smart developers who wanted to learn, I liked having a seat at the table to decide my own destiny and the level of autonomy to decide the “how”. I didn’t like the red tape, the political jockeying, meetings and more meetings etc. I wasn’t really learning anything that…

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

Re: On Being a Principal Engineer

#154

Post by scarface74 »

matwood wrote: post #123
bitL wrote: post #59

Earlier quoted context omitted.

I have seen how groups of people with dubious ethical standards played whole companies, pushing each other forward at the expense of more capable people, later taking their cronies with them to whatever company they landed, applying the same strategy. One of them made it to a director position at Google, largely propelled by "great networking". I can't with clear conscience support cronyism that deprives others of th…

> pushing each other forward at the expense of more capable people, later taking their cronies with them to whatever company they landed, applying the same strategy. So says you. This can also be thought of more charitably that someone hires people they know because there is much less risk. I've been working in software for ~20 years. I have a decent list of people who I would work with again, know what they bring to…

When I was a dev lead, you better believe I pulled in my former coworkers as well paid contractors because I trusted them. There was nothing underhanded about this. I let my manager and his manager know that they were friends and I had them go through extra interviews with my manager even though I usually had the final say about the contractors we brought in. I needed someone I could trust.

Re: On Being a Principal Engineer

#155

Post by fma »

teekert wrote: post #89
MisterOctober wrote: post #38

Earlier quoted context omitted.

I can really relate to this. I 'climbed the ladder' in company X and thereby acquired a lot of company-specific domain knowledge that didn't really have much value outside the company. I realized what kind of a fix I was in years ago and started to lay some groundwork for moving to another firm, but it took until this year to find a company that would place enough value on my [opaque] work at X to hire me at a salary…

Great tip, I feel more and more that my company has ancient tech that they still adhere to (basically as massive VM riddled with third party expensive proprietary software making it impossible to eat our own dog food even) and I now have three choices 1: Learn it and grow in this company but get stuck, 2: Force modern scaleable ways upon them (I've seen people try and fail but I hear more and more employees complain,…

I'm in the same boat. Funny how many people here are on the same boat. So many smart people but they feel like they can't prove themselves to land a job at another company. I feel that is one thing that stinks about our industry. I think option 1 and 2 are difficult..it takes a talented leader to pull off, but it may not be appreciated by people who haven't been there.

Meaning, it's easier to create a new project using x,y,z new tech. But to transform a company and bring business value from old tech, is more difficult.

Re: On Being a Principal Engineer

#156

Post by ghevshoo »

dcosson wrote: post #137
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…

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 I had my choice I would be spending 80% of my time writing and reviewing code, not just because I enjoy it but I feel like my coding skills are below what they should be and I want to spend more time improving them.

I struggle in programming tests. I find them pretty daunting. The value I can bring to a company is well known within the circle of people who have previously worked with me. From job to job, as long as I am touching that circle I can charge a premium. But the skills and experience I have are ones that rarely appear in a job description, and if they do they are usually under valued or the interviewers have no idea how to interview for such a position.

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.

Even though I still have plenty of interests and drive to learn, the normal situation 10 minutes into any discussion with a recruiter is “here is a technical/programming test...” at which point I get defensive and say “I’ll only do it if I think your test is interesting.” But I’m half covering up for my terrible ability for performing tests like what you see on hackerrank.

Re: On Being a Principal Engineer

#158

Post by throwaway98988 »

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 lot of "oral history" newcomers have to learn before doing anything meaningful.

Re: On Being a Principal Engineer

#159

Post by strken »

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 wasn't true for me in Australia. All my pay raises and promotions were double-digit percentages.

The bay area does have very big handcuffs, though.

Re: On Being a Principal Engineer

#160

Post by bsder »

teekert wrote: post #89
MisterOctober wrote: post #38

Earlier quoted context omitted.

I can really relate to this. I 'climbed the ladder' in company X and thereby acquired a lot of company-specific domain knowledge that didn't really have much value outside the company. I realized what kind of a fix I was in years ago and started to lay some groundwork for moving to another firm, but it took until this year to find a company that would place enough value on my [opaque] work at X to hire me at a salary…

Great tip, I feel more and more that my company has ancient tech that they still adhere to (basically as massive VM riddled with third party expensive proprietary software making it impossible to eat our own dog food even) and I now have three choices 1: Learn it and grow in this company but get stuck, 2: Force modern scaleable ways upon them (I've seen people try and fail but I hear more and more employees complain,…

I suspect you are probably at the "leave" stage.

Part of being at the principal/staff level is the ability to effect corporate change for the good of the business goals.

If that isn't happening, you need to ask some very hard questions as to why.

Post reply on HN