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

111–120 of 337 posts

Re: On Being a Principal Engineer

#111

Post by scarface74 »

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 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 could keep me competitive in the market.

I finished the green field project they hired me for initially, put it on my resume, quickly moved on to a small company and negotiated not to be made a dev lead and said I could help meet their objectives better by being a free agent and moving from team to team as needed and mentoring the younger leads.

I absolutely love my job. I have far more influence, autonomy, and a larger voice than I ever did at the larger company I left. I still mentor and advise, but I only have the responsibility as an individual contributor. I also get paid more because everyone including the CxO knows what I bring to the table.

I was in a similar position at the first place I worked for after the company I was at for 10 years. I was just a developer but I carried the weight of their biggest customer by myself as everyone else was trying to create the next project. I survived rounds of layoffs until the company folded.

Lesson I learned: I like small companies.

Re: On Being a Principal Engineer

#113

Post by mlthoughts2018 »

solipsism wrote: post #96
mlthoughts2018 wrote: post #37

Earlier quoted context omitted.

I was hired into a company as a staff engineer, and I probably won’t consider it again. The existing engineers resented me for it, though it was super clear that the product was suffering because the existing engineers had serious skill gaps in critical areas. Meanwhile, to other managers & directors, I was just some new engineer they didn’t know, a political unknown quantity. I hit the ground running and earned a lo…

I ... earned a lot of technical respect from my teammates, but nobody cares at all about my perspective on architecture, scoping, technology investment, tech debt, etc. How does that work? All the things you talk about are folded into my concept of "technical respect".

In fact they are not at all related. The engineers on my team bought into the ideas I was bringing as I rolled out implementations that proved the value.

Management however was less interested in increased value and more interested in entrenching their existing status and authority levels even if it meant torpedoing obvious and proved-out value-additive / cost effective engineering projects.

Re: On Being a Principal Engineer

#114

Post by tetha »

d4mi3n wrote: post #5
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…

In my experience it’s rare for orgs to hire for principal/staff/architect roles. What I’ve seen instead is people getting hired on as senior engineers and get promoted up from there after they’ve settled into the org.

I mean I'd consider myself somewhat experienced with the tech I have. But practically speaking, if you have a company with a somewhat established technology stack - or 2 or 3, commonly called legacy of some degree.

How would you have a thoroughly constructive opinion on moving the tech stack away from legacy and towards a more productive situation, without understanding the needs, situations and interactions of a company? And this takes time to learn.

In fact, even just learning the needs, goals, capabilities of different teams in an org just takes time to learn. Sometimes the path forward is to tell everyone to just do it. But no one talked with each other and thus, this never emerged.

Re: On Being a Principal Engineer

#115

Post by casper345 »

I am 23, just got my first real job and this has been on my mind as well. Although its early (I have been programming unprofessionally for 10 years),what track I want to go Senior or Principal based on the author's definition. Do I want to be the one who knows the tech stack from the back of my hand or managing people to move the overall goals of the company. Although the author says both roles involves people, at the end of the day the only way to become a better engineer is working on hard problems in the trenches. So the more you manage people the more you lose time "crafting" your skill. It's based on the individual pref, but right now I am at that crossroads.

Re: On Being a Principal Engineer

#116

Post by OJFord »

In these org structures where Principal Engineer has significant say in technical decision making but no reports: a) are they (at least potentially) 'tech lead'; b) who is the manager of the rest of the engineers on the team?

My only experience is with a full technical ladder being available, but the team technical leadership being the same as the team people management.

Re: On Being a Principal Engineer

#117

Post by aqwsedopl »

scarface74 wrote: post #111
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 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 exponentially more difficult for these engineers to switch companies. Esp funny is the promotion of unqualified individuals to “project lead”.

I’ve seen many of these individuals move to next companies and revert back to standard level software engineer.

It’s never about titles - you need to be aware that companies are using the titles against you rather than for you.

Also it pisses off the engineers in your organization who do deserve a raise to see unqualified promotions. Its a one way ticket for a small company to very quickly lose its true talent (80/20 rule) and talent follows talent. Once you get a few supporting cast leave, even the actually qualified senior engineers won’t want to stick around longer because they will feel intellectually isolated as well as feel like the engineering management are inept.

Re: On Being a Principal Engineer

#118

Post by matwood »

tibbetts wrote: post #103
maxxxxx wrote: post #81

Earlier quoted context omitted.

“Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills” Any ideas for doing this other having a lot of public visibility? I may have answered the question already but there may be other ways .

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…

> 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, using exact numbers that can be backed up is better because they tell the why.

Using the Java to Go example. Sure, the work was done but why was it a good idea? What did the company receive out of the change? How did the interviewee think about and mitigate the risks?

Re: On Being a Principal Engineer

#119

Post by matwood »

bitL wrote: post #42
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 don't think any leverage I have my with my current company will translate into finding jobs at other companies. You are right. Even if you are at FAANG, it doesn't really translate to a new environment, unless you are a direct pick by a CTO (you have to be famous in some way) or use your networking, which I consider unethical and don't do it.

> or use your networking, which I consider unethical and don't do it.

Have you worked with people who you would work with again and vice versa? Congratulations, you are using your networking.

Re: On Being a Principal Engineer

#120

Post by jameshart »

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 things that, without them, would not have been done.

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

When telling that story in an interview for a principal engineer role, make sure you clarify your role. What was expected of you, and how did you knock it out of the park? What parts of the problem did you have to take personal ownership of? Which decisions did you have to go to the mat for, and why were you right? Convince me you are a differentiating factor in successful projects and we’re going to be interested in hiring you.

As an interviewer I try to dig towards these things but it is hard and honestly I need some help from the candidate - and at this seniority level I don’t think that’s unreasonable (the candidate should know how interviews work because they’ll have been in the interview chair themselves, right?)

Post reply on HN