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

141–150 of 337 posts

Re: On Being a Principal Engineer

#141

Post by billti »

jameshart wrote: post #120
ryanong wrote: post #2

This rings true to my experience. I'm a Staff engineer and of my 40 hour week about 10-15 of those hours are interviews, meetings, and answering questions. Questions about technical feasibility, architectural discussions and planning, long term strategic planning, and lots of one offs from other developers. I enjoy the soft work I do, a lot of emotional labor for other developers, soft sells for tech/feature work aro…

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…

In a similar vein: As a principle engineering manager, I feel awkward doing my “what did you achieve” write-up come review time, as it feels like I’m taking too much credit for what my team did - even though probably the biggest part of my job is defining the work and making the team productive.

Re: On Being a Principal Engineer

#142

Post by jedberg »

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…

Are you sure he wasn’t making twice as much because he brought more value? There is no reason that your report shouldn’t make more than you. In fact I’d love to manage a team where everyone makes more than me. That would be amazing!

Re: On Being a Principal Engineer

#143

Post by enraged_camel »

johnwheeler wrote: post #138
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.

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 valuable to the company.

Re: On Being a Principal Engineer

#144

Post by 2muchcoffeeman »

jameshart wrote: post #120
ryanong wrote: post #2

This rings true to my experience. I'm a Staff engineer and of my 40 hour week about 10-15 of those hours are interviews, meetings, and answering questions. Questions about technical feasibility, architectural discussions and planning, long term strategic planning, and lots of one offs from other developers. I enjoy the soft work I do, a lot of emotional labor for other developers, soft sells for tech/feature work aro…

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 developers prop up the senior ones. So why would we talk as though our specific roles were ‘special’?

Re: On Being a Principal Engineer

#145

Post by scarface74 »

jameshart wrote: post #120
ryanong wrote: post #2

This rings true to my experience. I'm a Staff engineer and of my 40 hour week about 10-15 of those hours are interviews, meetings, and answering questions. Questions about technical feasibility, architectural discussions and planning, long term strategic planning, and lots of one offs from other developers. I enjoy the soft work I do, a lot of emotional labor for other developers, soft sells for tech/feature work aro…

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…

I was asked a few question when I interview for my job as a dev lead: The one I remembered most was after he told me the current sad state of the department he inherited (not the people, the process) he asked me what was my 90 day plan if so sdrs hired.

He also asked me about my thoughts on hiring, mentoring, and testing strategies.

Re: On Being a Principal Engineer

#146

Post by welly »

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?

Someone who leads, inspires, gets people working at their best.

Re: On Being a Principal Engineer

#147

Post by scarface74 »

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…

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 algorithm interview both paid slightly more and was a permanent position and the other was contract to perm.

It told me a lot about the maturity level of the company that they would ask a senior developer algorithm questions and not architectural questions.

I’ve had my share of pair programming interviews and online multiple choice assessments but I’m okay with those.

Re: On Being a Principal Engineer

#148

Post by scarface74 »

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…

Managerial principles also state that your value to a company is also partially based on the relationships and good will you’ve built that enable you to be more affective when you need something from another team or department and even the relationships you’ve built with vendors and customers.

Re: On Being a Principal Engineer

#149

Post by analog31 »

pm90 wrote: post #102
analog31 wrote: post #32

Earlier quoted context omitted.

I'm in exactly this situation, at Senior Staff level. It is quite possible that a person is actually getting paid enough to make it hard for them to leave, which seems strange because it's not not the norm. The company may want to keep them because of what they can do for that company, not because of their potential market value to another company. They may know things about you, that are hard for you to communicate…

> I've decided to adopt the attitude: Enjoy it while it lasts, but don't count on it lasting forever. Live a lifestyle consistent with your market value, and squirrel the rest away. I'm also conscious about keeping my tech skills up to date. Same here. Its kinda easy to be fooled into feeling complacent when you get compensated very well and are respected for what you do and have done so far. But it will never be eno…

Indeed, I'm quite happy at my job right now, but stuff happens, and companies large and small have evaporated overnight.

Re: On Being a Principal Engineer

#150

Post by Swizec »

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…

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

Post reply on HN