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

281–290 of 337 posts

Re: On Being a Principal Engineer

#281

Post by mlthoughts2018 »

brlewis wrote: post #244
mlthoughts2018 wrote: post #33

This article, along with a boatload of companies, fundamentally misunderstands the way that senior / principal / staff engineers add value. The article mentions it briefly in the small part about “force multiplier” but then seemingly reverses course when talking about “soft” duties & especially emotional labor. The value of staff engineers is to give them autonomy in deciding how to be a force multiplier. If they rea…

> burdening them to “sell” their vision on some architecture, recruiting policy, whatever. Fair warning, if I ever interview you for a position of senior or higher, I will be evaluating your ability to sell your ideas to other engineers. 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.

In that case, I would politely thank you for the chance to interview and decline to speak further with you, because it would be clear I would not be empowered to get my job done in the face of all the time-waster politics to lobby for projects or quarterly goals, etc. I would feel, “why have they hired an expert like me if they don’t plan to trust my advice on what action to take?”

Re: On Being a Principal Engineer

#282

Post by scarface74 »

hvidgaard wrote: post #267
scarface74 wrote: post #147

Earlier quoted context omitted.

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

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. I tell them they have a website that implements FizzBuzz. How would they test it. I want to see answers like this:

https://twitter.com/sempf/status/514473420277694465

Re: On Being a Principal Engineer

#283

Post by abhishekjha »

Titles like these scare me.

I mean when would I know that I need a different title? I am a Software Engineer with around 2 years of experience who implements most of the already made design by my seniors.

When would I know that I need a better title or that I am doing something that needs a better title? Or should I just wait for the company to promote me with a proper title? It will still leave me baffled though that somebody else is able to measure my competence/worth much better than myself.

I am trying to learn designing software as much as I can which seems like a gradual next step though sometimes I do have difficulty inverting a binary tree in C++ which makes me rethink my worth.

Re: On Being a Principal Engineer

#284

Post by empath75 »

abhishekjha wrote: post #283

Titles like these scare me. I mean when would I know that I need a different title? I am a Software Engineer with around 2 years of experience who implements most of the already made design by my seniors. When would I know that I need a better title or that I am doing something that needs a better title? Or should I just wait for the company to promote me with a proper title? It will still leave me baffled though tha…

Keep your linked in updated and talk to recruiters every once in a while. When they start knocking down your door with job offers that are better than what your current job, it’s time to push for a raise and promotion.

But generally once you start implementing your own ideas and stuff goes into production, it’s time to ask for a senior role.

Re: On Being a Principal Engineer

#285

Post by matwood »

roel_v wrote: post #176
matwood wrote: post #118

Earlier quoted context omitted.

> 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.” This is important for any level job. Java to Go by itself is really only interesting for a low level position. 8MM revenue growth is a person that will almost always get another look. In general,…

How does anyone quantify the value from something as generic as switching programming languages/frameworks to a number as specific as '8mm'? It could just as well have grown by that much even if there had been no switch. When I see formulaic nonsense like that in a CV, it better be meticulously sourced and they better be prepared to defend such a number in a potential interview, because usually I'll bin them with the…

> How does anyone quantify the value from something as generic as switching programming languages/frameworks to a number as specific as '8mm'?

In addition to what pm90 already said, if you can't quantify the value to the business on some level, then why are you doing the work?

My comment also said to back up the numbers. If I said I wrote a little utility and it saved the company 8B/year I better be able to explain how.

Also, the numbers do not have to necessarily go directly to revenue. Less bugs, faster feature development, less server resources, lower costs, better estimates, etc... are all quantifiable on some level. Is this an exact science? No, but this is what any engineer above junior (even they should be asking why are they doing something), should be asking themselves about every single engineering task. Because something is new and shiny is generally not a good answer, yet these types of migrations still happen in companies and waste large amounts of money.

Re: On Being a Principal Engineer

#286

Post by hopler »

nevir wrote: post #31
xtreak29 wrote: post #7

Is there a path where one can get to work on code without getting to design and architectural space. Is this thought as career stagnation when someone doesn't wants to work more on higher level design and to remain close to implementation side of things?

At our company we've implicitly split the technical ladder at the principal level into "broad" principals (this article), and "deep" principal (expert at their field). We're struggling to formally define it, though. How much pure IC work do we expect of broad roles? How much coordination/communication do we expect of deep roles?

Amazon invented the SWE 4/5 roles late because they were losing people who were surpassing 3 as individual engineers but couldn't meet the people-leadership requirements of Principal.

Re: On Being a Principal Engineer

#287

Post by hvidgaard »

scarface74 wrote: post #282
hvidgaard wrote: post #267

Earlier quoted context omitted.

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

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 problem logically in code.

I purposely try to make it less dependent on environment and syntax because it's not important for the candidate to show that they can. I always interact with the candidate and try to get them to implement enhancements or edge case handling that's missing.

It's a minor part of the interview we get over with in the first round. But if they asked you that and nothing else I would've walked away too - no one with a clue have been involved in that process anyway.

Re: On Being a Principal Engineer

#288

Post by skj »

tayo42 wrote: post #236
thundergolfer wrote: post #131

Earlier quoted context omitted.

As an example, I recently got offered a Senior Software Engineer position with 6 months experience @ Zendesk.

my whole dept seems to be filled with seniors younger then me, except my manager thinks the title still means something at this point so i'm not being considered for senior for years. im asking to be senior because i just want the money fuck the titles...

It's about what you can do, not about how long you've been around.

Re: On Being a Principal Engineer

#289

Post by nf05papsjfVbc »

mlthoughts2018 wrote: post #281
brlewis wrote: post #244

Earlier quoted context omitted.

> burdening them to “sell” their vision on some architecture, recruiting policy, whatever. Fair warning, if I ever interview you for a position of senior or higher, I will be evaluating your ability to sell your ideas to other engineers. 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.

In that case, I would politely thank you for the chance to interview and decline to speak further with you, because it would be clear I would not be empowered to get my job done in the face of all the time-waster politics to lobby for projects or quarterly goals, etc. I would feel, “why have they hired an expert like me if they don’t plan to trust my advice on what action to take?”

Do you really think software engineers react well to being told what to do by someone who has not yet earned their respect?

Re: On Being a Principal Engineer

#290

Post by ryandrake »

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…

> Even your best developer is not going to do anything great if he’s fixing bugs.

Honestly, I wish this mentality would go away. Maybe software in general is so "barely shippable" shitty because 95% of everyone's engineering effort is spent on cranking out features rather than fixing bugs and improving stability/performance. Somehow, feature work is glamorous and gets you promoted and quality is seen as boring, dead-end work. This really needs to change.

Post reply on HN