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

311–320 of 337 posts

Re: On Being a Principal Engineer

#311

Post by mixmastamyk »

6ak74rfy wrote: post #306
nilkn wrote: post #173

Earlier quoted context omitted.

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

This sounds like a great guy. Can you give some concrete examples of various techniques and technologies that he brought to the table?

Few places are hitting 12 on the Joel Test twenty years on. That, unit/integration tests, and a "message bus" with metrics dashboards and you're above average.

Re: On Being a Principal Engineer

#312

Post by mixmastamyk »

hk-mars wrote: post #273
throwaway98988 wrote: post #158

Earlier quoted context omitted.

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…

So how to improve this situation? I think it’s human problem :)

If you can't convince them, you might try the boss.

Re: On Being a Principal Engineer

#313

Post by scarface74 »

hvidgaard wrote: post #287
scarface74 wrote: post #282

Earlier quoted context omitted.

Notice I said I have no problem with pair programming type interviews. When I interview developers, I have a simple skeletal class based on a real world problem we’ve had with failing unit tests. They have to make the unit tests pass. Then I give them another set of requirements and unit tests they need to make pass without breaking the first set. When I interview QA people, I give them a version of the FizzBuzz test…

That works too, but the means to the end is less important than the result. I'm sure I would get the same from your approach, as I would with a simple programming problem question - algorithmic or not. Most of all it's a litmus test to see that they in fact know how to think in code. I really don't care if it's in C#, Haskell, or pseudo code - that's their tool of choice as long as they show the ability to solve a pr…

I very much care that they know the tools and are not just a good developer. I need someone who can hit the ground running using our choice of language. Learning a language is easy. Learning to use the tooling efficiently and learning the ecosystem takes time. I'm not hiring developers to write algorithms. I'm hiring developers who know whatever language we are working in. I'm not going to hire a PHP developer no matter how good they are if I'm running a C# shop. Why would I? I can easily find C# developers.

If they struggle writing code and don't know the syntax when given an IDE, why would I hire them?

Re: On Being a Principal Engineer

#314

Post by auiya »

nickm12 wrote: post #47
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…

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.

> there is a belief that it's easier to become a principal by leaving than by going through the rigorous promotion process

That's because in most places it is. The whole construct of "work above your pay level for years on end, and MAYBE one day you will be paid accordingly" is fundamentally flawed and will always foster an environment of low morale. That's a sucker bet, and is why people job-hop for meaningful career advancement. Promotions are little more than popularity contests, not unlike a beauty pageant. And much like a beauty pageant, they don't reward those who answer the judge's questions the most elegantly, they reward the ones who attract the most attention. If you want to know what a company values, pay attention to what it rewards/incentivizes, then ask yourself if you share those same values. If not, bounce. You'll likely make more money doing so anyway.

Re: On Being a Principal Engineer

#315

Post by skj »

mlthoughts2018 wrote: post #307
skj wrote: post #295

Earlier quoted context omitted.

The statement > anyone who comes in as a Staff Engineer expecting to simply dictate their ideas to lower-ranked engineers without selling those ideas, is going to fail was almost certainly about the field in general, not this person's immediate org or even company. So it's more like, "why would we hire an expert like you if we won't actually get the value we're paying for?"

> “So it's more like, "why would we hire an expert like you if we won't actually get the value we're paying for?"” But hiring them into a position where they are automatically subject to pre-existing political barriers guarantees you won’t get value out of them. Giving them autonomy means you could possibly benefit from their value-add.

I don't think it's fair to use the label "pre-existing political barriers" when talking about being able to convince people that your ideas and vision are worth the cost it takes to implement.

Re: On Being a Principal Engineer

#316

Post by mlthoughts2018 »

skj wrote: post #315
mlthoughts2018 wrote: post #307

Earlier quoted context omitted.

> “So it's more like, "why would we hire an expert like you if we won't actually get the value we're paying for?"” But hiring them into a position where they are automatically subject to pre-existing political barriers guarantees you won’t get value out of them. Giving them autonomy means you could possibly benefit from their value-add.

I don't think it's fair to use the label "pre-existing political barriers" when talking about being able to convince people that your ideas and vision are worth the cost it takes to implement.

That makes no sense at all. Pre-existing political barriers are the primary obstacle to convincing people in most business settings.

The actual technical merit or cost effectiveness usually has utterly no correlation at all to how the business decision is made.

Re: On Being a Principal Engineer

#317

Post by leetrout »

ahupp wrote: post #304
kanox wrote: post #292

Earlier quoted context omitted.

> "but you are too emotional" to promote. Jesus fucking Christ how is that even remotely acceptable as management feedback?

That seems like fine feedback as long as it was coupled with further specific and actionable feedback. e.g, "You yelled at Alice and Bob in the discussion about project X, rather than helping build a consensus about the right solution." Senior engineers should be solving problems in the org, not causing them.

And unfortunately it was not. That was the feedback in its entirety. Not an example of how or when I was being emotional nor what they wanted corrected.

Re: On Being a Principal Engineer

#318

Post by all_usernames »

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…

"Staff engineer" is used differently at different companies. Some, I understand, use that as the external-facing title to mask specific job rules as obfuscation against cold-calling recruiters.

Re: On Being a Principal Engineer

#319

Post by tbomb »

lugg wrote: post #247
Klathmon wrote: post #225

Earlier quoted context omitted.

I feel I do great during the interview, it's just getting to that point is where I'm struggling. Writing that out seems to really bring out a part of my brain that makes it always feel braggy. (I really think it's the fact that during a conversation I have realtime feedback on what the interviewer wants and what parts I should focus on) I'm "full time" looking for a job at the moment, and it's rough with how much of…

> A lot of no responses, no way to gauge how i'm doing, and even when rejections come in there's no information along with them to help me understand why or how to improve If you don't come out of an interview and know you have an offer coming your way: assume you have no offer coming your way. It's usually very obvious and both parties are trying to say your hired without actually showing your cards. It's kind of a…

One of my go-to closing questions in interviews is to ask them if they have any concerns/doubts about hiring me for the role.

So far I've gotten pretty good and honest feedback from it. It also gives me an opportunity to explain myself and/or try to turn around any doubts.

Re: On Being a Principal Engineer

#320

Post by brlewis »

mlthoughts2018 wrote: post #316
skj wrote: post #315

Earlier quoted context omitted.

I don't think it's fair to use the label "pre-existing political barriers" when talking about being able to convince people that your ideas and vision are worth the cost it takes to implement.

That makes no sense at all. Pre-existing political barriers are the primary obstacle to convincing people in most business settings. The actual technical merit or cost effectiveness usually has utterly no correlation at all to how the business decision is made.

> convincing people

I thought you didn't want to be burdened with selling ideas, but just wanted authority to implement them without convincing people.

Post reply on HN