On Being a Principal Engineer • Hacker News Board

Re: On Being a Principal Engineer

#221

Post by john_moscow » Mon, Feb 11, 2019, 1:17 AM UTC

leetrout wrote: post #216

jedberg wrote: post #129

Re: companies that claim to have a fully equivalent technical track: What I've found is that is mostly lip service. Yes, they publish salaries and requirements for the highest levels of engineering, and those salaries are equivalent to high levels of management as far as pay goes. But if you look a little deeper you see the problem. At Google and Amazon and Facebook, a Distinguished Engineer is equivalent to a Vice P…

I left my previous company before their ladder (~14+ months of work) was finally released so I'm not sure how it has worked out but one of the first drafts I saw had a rubric for gauging your growth / fit for the roles. One of the biggest things I took issue with was that you had to have some sort of "community involvement" but management had to approve your speaking engagements to some degree (be it time off, messag…

>I was told "your technical skills are senior level" "but you are too emotional" to promote.

Funny. I got a direct opposite experience. Being told that I got technical skills, but I focus too much on the technical side and don't consider other engineers' emotions. The team was pretty toxic though and I'm happy I left as soon as my lock-in expired.

Re: On Being a Principal Engineer

#222

Post by Aeolun » Mon, Feb 11, 2019, 1:20 AM UTC

hellisothers wrote: post #85

nickm12 wrote: post #47

Earlier quoted context omitted.

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.

I am also experiencing this and thus am starting to look elsewhere (and others at my co. feel the same), I imagine it’s an industry thing but have been trying to figure out what the root cause is.

Companies always seem to think that the talent is out there. They just don’t have it yet.

Sadly it’s often the opposite.

Re: On Being a Principal Engineer

#223

Post by roel_v » Mon, Feb 11, 2019, 1:31 AM UTC

solipsism wrote: post #192

roel_v wrote: post #186

Earlier quoted context omitted.

Some technical roles require deep understanding of an extremely niche thing. It just doesn't make sense to have such a person supervise 10 junior and senior people, they wouldn't be able to do any more work than the one guy. For example I've seen a GPU optimization expert who did his PhD on GPU chip design. What sort of 'guiding' others would he be able to do? He could spend 2, 3 years teaching a team of 10 everythin…

In this situation you're describing, a single person is responsible for, and the only person at the company capable of working on, the "core of [the] product"? Unless this is a company of 1, that's absolutely crazy! There are many reasons you'd want more people (I don't know why you're jumping to the large number of 10... why not 2?) on this "core of the product": * mitigating risk from the bus factor ( https://en.wi…

shrug I guess we'll just have to agree to disagree. Of course nobody wants to build the single most important part of a company around a single person. My point is that for some deep niches, building entire teams around it, and pulling away the people who know most about those things in order to have them 'mentor' a bunch of people who in no way will be able to reach the require depth for a long time just doesn't make sense. And from my understanding, it is this sort of situation the GP was referring to. I don't think, and from my experience which of course suffers from insufficiently large sample size, this situation is not all that uncommon.

(as an aside, I especially object to 'taking advantage of a diversity of perspectives/approaches' being a universal good/requirement. I have seen many cases where having one person just get on with it absolutely beat the design committee. But again this perspective is probably skewed by being involved mostly in deeply specialized numerical software, where exceptional value mostly comes from having both deep domain expertise in something unrelated to computing and deep technical/programming knowledge)

Re: On Being a Principal Engineer

#224

Post by dizzydee » Mon, Feb 11, 2019, 1:36 AM UTC

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…

I am a Principal Architect/Engineer at a mid-size company (~200-300 engineers, 1500 total headcount).

I would consider myself a Principal Architect, Senior Engineer, Senior Implementation Specialist, Mid-Level Product Owner/Manager and Junior Account Executive when it comes to actual job breakdown on a day-to-day basis.

I'm fielding important sales calls with the team, help troubleshoot important implementations with clients, and design systems and generally try to lead the Seniors/Leads across teams towards a common goal.

That said, if it really comes down to it, I can also roll up my sleeves and sling some code - usually as effectively as the Seniors/Leads.

I actually think the above skills are as transferable as the raw tech skills. At the end of the day, we all have to actually _sell_ software that is useable/valuable to our customers. If you're in the position to prove/demonstrate that it really doesn't matter the stack.

Plus, all the failures spanning the XXXXX teams you assist are sure to teach you _something_.

(FWIW, the actual teams I interact with are not the original team/product I started at with the company - we were a startup that was acquired)

Re: On Being a Principal Engineer

#225

Post by Klathmon » Mon, Feb 11, 2019, 1:37 AM UTC

tfigment wrote: post #219

Klathmon wrote: post #209

Earlier quoted context omitted.

I personally always talk about what "we" did because it helps me get out of my own way. I worked at a company for like 6 years, and for almost 4 of them i was the sole engineer tasked with designing a database for the data, creating and deploying/maintaining an API server, and creating a handful of react frontend applications. The last 3 years we expanded into a "team" that I led and scaled it up from there. I never…

Frankly, what you just wrote is what I want to hear in an interview. That you were first and the team grew around you and if mistakes were made how what would you do differently. To me, the company/team talk eats away at the limited time in the interview and doesn't generally matter since we are not hiring your company but how you helped is very relevant. I will slightly demerit people if I have to resort to asking w…

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 "nothing" you get back. 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.

I'm trying to learn to write about myself more and feel more confident in writing about what i've done and that I really feel I was an integral part of the success of the things i've been a part of, but without any kind of feedback I'm constantly second (and third!) guessing literally every word.

Re: On Being a Principal Engineer

#226

Post by devonkim » Mon, Feb 11, 2019, 1:51 AM UTC

Klathmon wrote: post #225

tfigment wrote: post #219

Earlier quoted context omitted.

Frankly, what you just wrote is what I want to hear in an interview. That you were first and the team grew around you and if mistakes were made how what would you do differently. To me, the company/team talk eats away at the limited time in the interview and doesn't generally matter since we are not hiring your company but how you helped is very relevant. I will slightly demerit people if I have to resort to asking w…

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 recruiter I respect said that the interview process is the most egotistical, selfish thing we do as professionals and it does the process a disservice if you do not follow it as such. Selling yourself to your peers and to those that want to hire you is important for the accuracy and precision of the hiring process if your contributions are not self-evident.

Getting good feedback is definitely one of the hardest parts though and thus makes getting better at interviews tough without good mentorship / network. Heard of a guy that was one of the top n TopCoder engineers and was having trouble landing a solid gig. Turns out he’d just zoom through the whiteboard problems, hardly talk, and interviewers were just weirded out. When he started slowing down and explaining his thoughts better to the panels he finally got the offers he deserved.

Re: On Being a Principal Engineer

#227

Post by deleted_account » Mon, Feb 11, 2019, 1:52 AM UTC

alexandercrohde wrote: post #201

deleted_account wrote: post #80

Earlier quoted context omitted.

These and the parent's examples are very team-centric. The heuristic I use when thinking about these engineering roles is, "Where is this person expected to be a leader?" The progression is usually: Team, Cross-team, Organization, Industry. Competent technical decisions are table stakes. The real differentiator is at what level can they effect change.

This is the very thing I'm criticizing. "Leader" is one of the worst buzzword bingo terms in a company. It means nothing, it's just a convenient label to give people who you feel like promoting to maintain the 10:1 ratio. You could argue Linus Torvald is an industry leader, or you could argue he doesn't show adequate leadership for cross-team.

I think you very much understand a leader can be something more than a buzzword: "If you’re a leader in an organization, you need to be aware of the stories that occupy the minds you oversee."

Or maybe more succinctly: "If a great manager screws up, he should lay awake at night until he fixes it, just as a great engineer would wake up to fix a production issue."

These traits combined with a scope of influence is what I was referencing.

Re: On Being a Principal Engineer

#228

Post by scarface74 » Mon, Feb 11, 2019, 1:58 AM UTC

Bekwnn wrote: post #218

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…

I'm super appreciative of my current role for this and other reasons. I'm the sole software developer on a team of 6 people in a mostly isolated corner of the code base. I'm getting a ton of experience making calls and collaborating with non-engineers, while still getting to be involved in some broader discussions. A company of 20-50 programmers seems ideal to me now, with an overall company size of <300. I feel larg…

I wouldn’t go that far. Being the sole developer you risk becoming an “expert beginner”. I know that held me back for over a decade, being the only developer for three years and working with two other developers who never worked at any other company for 9.

Re: On Being a Principal Engineer

#229

Post by wolco » Mon, Feb 11, 2019, 2:02 AM UTC

tanilama wrote: post #41

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?

> code without getting to design and architectural space Then your impact is limited. Truth is, you need to do high-level thing to influence more people because that is more efficient and valuable use of your time. Implementation is fun and useful and all, but it can't scale beyond certain scale.

I always felt the higher the level the less the impact but the bigger the credit one will take.

The CEO sets the goal of more mobile connectivity this year. The VPs come up with high level projects. The managers assign the work. The programming team does it. The higher up the lesa the real impact.

Re: On Being a Principal Engineer

#230

Post by riku_iki » Mon, Feb 11, 2019, 2:09 AM UTC

tdumitrescu wrote: post #162

tibbetts wrote: post #103

Earlier quoted context omitted.

Learn to talk about your accomplishments like an entrepreneur or executive would: impact with quantified customer and company value. 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.” Another thing I don’t see enough in this thread is emphasizing so…

Oh man, I see so many resumes littered with these kinds of statements. I totally gloss over them as they generally read like BS, and are formulaic enough that they just represent another "how to sell yourself" job-hunting checkbox point. Lots of devs would love to have some way to quantify our impact in monetary terms but the reality is that "process/tooling change X -> $Y ARR" is basically always hand-wavy made up m…

It is a good question for interview to discuss how those numbers have been derived.