[ryanong]

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 around the company, process strategy and such. I never expected this to be such a large part of my job, and how much value comes from it.

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.

In the past year, I have seen less than 5 job posting for a staff engineer.

[jameshart]

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?)

[PopeDotNinja]

> 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

When I was a technical recruiter, I could probably have faked my way through some technical interviews without much understanding of how to code. Now as a senior level engineer, I could probably do a pretty good job of sounding like I was the one who did the work that I saw someone else do.

> When telling that story in an interview for a principal engineer role, make sure you clarify your role. > 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 haven't tried to hire a principal engineer, and I don't consider myself to be one, but if I had to guess how to interview one, I'd probably try something like this...

- prior to the interview, prepare specific reasons why we need a principal engineer in the first place, including answers to questions like "what do we expect from a principal engineer that we don't expect from a merely senior engineer?"

- I'd budget enough to time candidly talk with the principal engineer about what we're trying to accomplish, especially getting into details about what sucks & where we're lacking principal level help

- I'd ask the principal engineer for their thoughts on how they might be able to help, including how they'd go about establishing themselves as someone who could be successful in the role, asking them to go into as much detail as possible

- After that, I'd ask them whether they'd even enjoy doing that kind of work, to share some examples about having done similar work previously, and ask what they'd need to be set up for success

- I'd ask them to think about the position I'm in, and whether or not they'd recommend I hire them, and why they feel that way

Basically, I wouldn't try act like I know how to spot a good principal engineer. I'd do the work to communicate my needs for one, and let the principal engineer candidates help me understand what I'm looking for. If I didn't find a principal engineer amongst the people I'd interviewed, I'd have to trust that I'd have a way to feel that.

[hadsed]

I think this is a great comment. The most critical aspect is understanding the risks and mitigating them (which is your question about how to get set up for success).

[phkahler]

That's the challenge in all engineering interviews - determining weather they did anything useful or were just on the team. I've had to tell people to stop telling me about "we" and tell me what "you" did. Some people are so caught up in trying to be a team player that they hide their contributions. Others use it to hide their lack of contribution. It's not hard to separate these once you're aware of the issue and start asking the right question "what did you do?"

[Klathmon]

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 talk about what "I" did because I'm always afraid it will come across as lying or exaggerating, and at the same time I know that I didn't do all that alone even if I was the sole contributor for the vast majority of it. I had managers that helped carve out time and lay out requirements, I had executives that were willing to let me make multiple mistakes as I found my footing, I had devs focused on other areas at the company that I could bounce ideas off of and learn new skills from. And to be honest there were some months that I was SO productive that I genuinely don't think I could ever do it again, and I don't know exactly why it happened.

I'm currently looking for a senior/lead job, and writing about what "I" did and what I feel i'm capable of is by far the hardest part of it. I feel like I flip flop between basically saying "I was part of a team that did awesome things" and "I did all this awesome shit all on my own", and in both cases it feels like i'm lying.

Once I'm talking to someone I feel i'm really good at talking through the choices and tradeoffs made, the mistakes I made, the parts of the job I'm good at and the parts I feel I'm not. But I can't seem to write that down well, and I think i'm throwing away chances because of it.

[tfigment]

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 what they individually did as opposed to the team and a lot if I still don't get a good feel for it. I realize at large companies it can be hard since you might be the guy that maintains a small section of a website but I prefer upfront honesty to having to sort it out with more questions.

[Klathmon]

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.

[devonkim]

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.

[lugg]

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

Your problem, where you feel you have no feedback is a problem but it's most likely a problem with you.

You need to be asking for feedback if you're not getting it. Get blatant if you have to.

What do I need to show you to get an offer today? What are you looking for? Your job ad didn't clarify on this this and this, can you spell out exactly what you're looking for in me today?

You're not really responding to my answers, is there something I'm not explaining well enough? Feel free to interrupt and get me to clarify, this point is important to me because it illustrates this skill which I think is important as a developer, do you agree, disagree or don't believe me? Why? What facts do you need me to spell out?

If you think it's on them to figure out how to be good at interviewing, you're right, it is, but that doesn't help you get a job offer today.

[phkahler]

One of the other posters here responded to you with:

>> Frankly, what you just wrote is what I want to hear in an interview.

I completely agree. Look back at what you wrote here. The word "I" appears plenty of times in your post and is very appropriate. You're talking about your experience so it makes perfect sense to mention yourself in that. You also mentioned the team and "we" a bit. Good. There is a lot of space between talking about your experience and being an egotistical jerk. Talk about your experience just like your post here and you should be fine.

When I interview I'm primarily looking for 3 things on the technical side:

1) Can this person DO things?

2) Can they learn things?

3) Are the interested in doing and learning the kind things we need done?

In that short post you've demonstrated #1 and #2. You also covered some of the non-technical stuff. If you showed experience or interest in embedded C on micro controllers I'd be telling you to apply here (Detroit area).

[fatnoah]

>It's not hard to separate these once you're aware of the issue and start asking the right question "what did you do?"

Another useful technique I've developed for interviewing senior folks is to probe them for details about important technical or other decisions that were made related to the things they say they did. I'll then challenge those decisions and make them justify and explain.

[2muchcoffeeman]

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

[ryandrake]

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

[bluGill]

The best developers are the ones you can give the hardest bugs to and trust they get them done. The ones where the principal engineers see someone heading for your desk and jumps up to figure out why - stopping your interruptions is far more important than anything else! (You can't give these to the principal engineer because his job is to be interrupted)

[Swizec]

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

[chii]

Wouldn't that be just a round about way to lie about yourself?

[Swizec]

No, don’t lie. Highlight your accomplishments.

Yes they wouldn’t be possible without the inputs of others and yet you still did something. What was it?

If you can’t answer that question then this project shouldn’t be on your resume and you shouldn’t bring it up in interviews.

[beaner]

Why do you have that in quotes? They did not say senior roles are special.

They're just saying: acknowledge team wins, but you still did something individually, be able to explain what that thing was in detail.

[2muchcoffeeman]

The OP was frustrated about having to prompt interviewees to talk about their accomplishments and how they always talk in first person plural.

I am in support of this being the natural way of thinking. No one could do what they did without support.

I am also vaguely suggesting that maybe every company’s process of promoting, hiring or giving out bonuses is wrong.

[beaner]

I don't think many people are opposed to that way of thinking. But as a responsible team member you still have individual duties and you need to be able to explain them.

[kortilla]

Right, a staff level engineer would have been the one to organize the team so the junior developers are picking up the easier stuff and learning the system.

If you think team dynamics just magically emerge that way around a complex technical project, you weren’t as senior as you thought.

[prirun]

I sort of hate the idea that senior people design and write stuff, while junior people fix bugs. In my experience this leads to developing code where "someone else will fix it up if there are problems" and in the long-run, is not good for the senior people (they get sloppy) or the junior people (they're not happy fixing others' crappy code).

I think a lot better model is ownership of code. If you write something, it's yours. If it breaks, it's yours to fix. If someone wants to change the design of it, they go through you first. Maybe eventually someone changes it so much that they own it.

[Tcepsa]

What about the idea that senior people design stuff but then hand it off to junior people to write and then coach them through the bug fixing and refinement? (Honest question; doesn't seem like there's much of this where I work and I'm considering trying to introduce it because it seems to me like a good way to leverage the senior folks' skills while also transferring them to more junior folks, but I'm wondering whether there is some kind of taboo against it or something else that I'm missing)

[dcosson]

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 do they just need a passing score in the various technical sessions and the differentiating factor is more of these leadership type questions and convincing you about their past successes?

[ghevshoo]

Would love an answer to this question too. I effectively find myself in the role of a “principle engineer”. That’s exactly the reason why I was hired - with the expectations to be a “force multiplier” in the organization, which means I end up getting involved in many non-technical activities.

My actual job title is just “software engineer”, but title’s don’t mean too much where I work (a mid-size bank in Europe).

If I had my choice I would be spending 80% of my time writing and reviewing code, not just because I enjoy it but I feel like my coding skills are below what they should be and I want to spend more time improving them.

I struggle in programming tests. I find them pretty daunting. The value I can bring to a company is well known within the circle of people who have previously worked with me. From job to job, as long as I am touching that circle I can charge a premium. But the skills and experience I have are ones that rarely appear in a job description, and if they do they are usually under valued or the interviewers have no idea how to interview for such a position.

It’s a continual dilemma for me in my career now as I hit the big four-oh this year, and trying to figure if there is some way to be just a regular “software engineer” without taking a big pay-cut.

Even though I still have plenty of interests and drive to learn, the normal situation 10 minutes into any discussion with a recruiter is “here is a technical/programming test...” at which point I get defensive and say “I’ll only do it if I think your test is interesting.” But I’m half covering up for my terrible ability for performing tests like what you see on hackerrank.

[scarface74]

It’s a continual dilemma for me in my career now as I hit the big four-oh this year, and trying to figure if there is some way to be just a regular “software engineer” without taking a big pay-cut.

Not that I’m looking to leave the company I’m working for now anytime soon, but I’m in my mid 40s and I think whenever I do leave, this may be my last full time software development job unless I find another small company I like as much.

My next job will either be an overpriced “digital transformation consultant”/“cloud consultant” or just a W2/1099 contractor where I come to work get paid and move on when the contract is over.

Luckily, I never have to worry about health care coverage again in 6 years since my wife will have guaranteed life long health insurance with her job after 10 years.

[scarface74]

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.

[hvidgaard]

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 demonstrate programming proficiency and if you didn't know merge sort, how you grasp new problems.

I would put more weight on architectural discussion though.

[scarface74]

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

[hvidgaard]

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.

[billti]

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.

[scarface74]

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.

[scarface74]

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.

[aqwsedopl]

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.

[scarface74]

I wouldn’t even go that far. The dev lead over one of the teams is far more qualified to be the lead over that team because of his company knowledge - he’s been there for five years. He’s a smart guy but I don’t know how well he would fare outside of our company. This was his only job out of college.

I’m one of the three oldest developers - two of us are in our mid 40s and one in his mid 50s. The “architect” is well qualified but he has a lot on his plate. The other dev in his 50s also fought against being made a lead.

Edit:

I usually don’t comment on downvotes, but I’m really interested in knowing what could possibly be offensive or disagreeable about this post.

[bootsz]

Yup, that was my last company . Had a bunch of inexperienced devs getting promoted to "Senior" all the time. I think I counted once and figured out that we had more people working there with the title Senior Software Engineer than we did regular Software Engineer's.

After one year of moderate effort I too got the promotion, with almost no pay raise. The problem of giving everyone a certain title is you basically completely dilute any meaning or status it conveys.

I soon went on to FANG and am now a regular ol' Software Engineer again. But I'd much rather be bottom rung at a top company than a "Senior" whatever at a company where it means nothing.

[discordance]

This applies at both small and large companies alike

[scarface74]

I don’t care about titles at all. I care about three things when it comes to my job:

- Technology/Career enhancement - where will this job put me in three years if I want to find another job

- Environment - I’ve grown increasingly picky about my environment and work life balance.

- Money - at least pay me the local median wage for what I bring to the table. Don’t insult me. But beyond that, money is the least important criteria.

[Bekwnn]

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 larger might require too much bueracracy and smaller might lose out on QoL and scale of work that can be accomplished.

[scarface74]

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.

[nomel]

I’m might be in this boat, and it terrifies me.

What are some characteristics of a “expert beginner”? What did you realize you were lacking/weak points?

[scarface74]

https://daedtech.com/how-developers-stop-learning-rise-of-th...

Unfortunately, you may not know until you get around people who have been developing as long as you have on paper but have learned from other people.

But this is my go to list of books.

https://news.ycombinator.com/item?id=18794561

[maxxxxx]

"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 have a pretty good reputation due to experience but I am not famous in the industry so I don't think any leverage I have my with my current company will translate into finding jobs at other companies.

That's a pattern I actually see quite often. People go very high in one company, but when something happens and they leave that company due to layoffs or other reasons they often find jobs only several levels lower and have to work themselves up again.

[analog31]

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 in a job application situation, such as how you work with people.

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.

I'm reminded of an old saying among people in the entertainment business: Think about how you treat people on your way up, because you will meet them again on the way down.

[pm90]

> 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 enough to keep you around forever; there are so many failure modes that you have to think about the possibility of being on the job market again.

Which is another reason why (apart from plain old human decency) I do make it a point to reply to most of the recruiters that try to recruit me with a polite explanation that I'm happy where I am currently but please lets stay in touch so in the future if things change we can try again.

[analog31]

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

[swagonomixxx]

> Think about how you treat people on your way up, because you will meet them again on the way down.

That’s an incredible saying. It really encapsulates the “fall from grace” that a lot of celebrities experience. Never saw it put in a way that would relate it to my life. Thanks for sharing!

[MisterOctober]

I can really relate to this. I 'climbed the ladder' in company X and thereby acquired a lot of company-specific domain knowledge that didn't really have much value outside the company. I realized what kind of a fix I was in years ago and started to lay some groundwork for moving to another firm, but it took until this year to find a company that would place enough value on my [opaque] work at X to hire me at a salary that was comparable.

Lesson learned : make a conscious and focused effort to acquire + maintain general skills and keep a visible portfolio updated!

[teekert]

Great tip, I feel more and more that my company has ancient tech that they still adhere to (basically as massive VM riddled with third party expensive proprietary software making it impossible to eat our own dog food even) and I now have three choices 1: Learn it and grow in this company but get stuck, 2: Force modern scaleable ways upon them (I've seen people try and fail but I hear more and more employees complain, perhaps I can be the one to lead change) or 3: Leave. I think I'll make this decision within 1 or 2 years (still a lot to learn).

But I feel more and more that growing in this company may be a trap.

[fma]

I'm in the same boat. Funny how many people here are on the same boat. So many smart people but they feel like they can't prove themselves to land a job at another company. I feel that is one thing that stinks about our industry. I think option 1 and 2 are difficult..it takes a talented leader to pull off, but it may not be appreciated by people who haven't been there.

Meaning, it's easier to create a new project using x,y,z new tech. But to transform a company and bring business value from old tech, is more difficult.

[bsder]

I suspect you are probably at the "leave" stage.

Part of being at the principal/staff level is the ability to effect corporate change for the good of the business goals.

If that isn't happening, you need to ask some very hard questions as to why.

[javadocmd]

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

Anyone worth their salt should realize that the long-term value of technical leadership far eclipses the short-term value of knowing what happened that one time we tried switching from Technology A to Technology B. (And unless you've completely purged your engineering department, such institutional knowledge is there to be queried.)

[scarface74]

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.

[fromMars]

I am believer in promoting from within for the most part.

At the companies I have worked at, hiring people directly into principal roles hasn't worked well. Invariably, they struggle to fulfill that role because they don't have enough knowledge about the inner workings, code base, etc.

It usually takes them at least a year before they contribute at their level.

[maxxxxx]

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

[tibbetts]

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 software you managed to avoid writing. That’s the real secret of being a 10x engineer: telling your organization when building something expensive is not necessary, either because you don’t really need it, can use something simpler, or can adopt something that already exists.

[matwood]

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

[roel_v]

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 other bullshit artists straight away.

[tdumitrescu]

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

[tibbetts]

Sure, but most business decision making is based on hand wavy made up math. Like, how do you decide to build a feature or switch programming systems? Does it not relate to customers or revenue?

Also, yes, don’t have the numbers be BS or fail to include other useful narrative in your resume. But I so often see none of this, and leaving it all out is a sign someone hasn’t had to justify their decisions at that level.

[riku_iki]

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

[javadocmd]

In addition to tibbett's point (expressing technical accomplishments in terms of their value to the business), do some honest introspection on your value to your peers. I'm really just elaborating on Ms. Botros' article here, but for example you want to ask yourself these kinds of questions:

Do you improve the skills of the people around you? Do you identify and help resolve barriers faced by your peers? (This doesn't always mean fixing things yourself!) Do you improve the environment and culture where you work? Can you work collaboratively to establish a vision for change? How do you gain the buy-in of your peers when it comes time to implement change?

Internalizing these answers will prepare you to steer the conversation onto the skills that you know are important for the role.

[micksabox]

Building RefactorKit.com to help with this too:

> Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills.

[imetatroll]

I think you are wise to worry. Last year I was laid off from a company whose technology I helped build for years. I was promoted up to the position of "CTO"... with no team below me. It was a very small company working on email archiving and encryption that still runs today. As the system admin and solo developer I was spread thin, working on a system that now processes anywhere from 80 to 120 (150?) million emails a month. In the last several months I sent out my resume to at least 40 different companies, but the only offer I received was through someone my previous boss knows. It isn't a CTO level position.

To be clear I was let go because the company ended up having financial difficulties. It is a strange story to tell and sometimes I wonder if people think I am weaving it as I go. I'm not. It did leave me severely burnt out and I find the question "what was your biggest accomplishment?" to be a frustrating one during interviews because I did so much for that previous company that I almost don't remember any of the subtle details. I thought that the numbers would speak for themselves but nobody seems to care. I find it bizarre.

The other thing that might be fascinating is that the technical portion of interviews seem to be where things stall out for me. I would never claim to be an incredible programmer, but my previous companies system was not a trivial piece of software. I am probably going to give my one and only job offer a try and see how that goes. shrugs

Finally when I say build I mean to say that there was a PKI api + c library for interfacing that layer when I started. The website, the inbound/outbound email processing, the ES portion of the service etc were all built by me. So the parts that brought the actual customers were built by me.

[D-Coder]

"I find the question "what was your biggest accomplishment?" to be a frustrating one during interviews because I did so much for that previous company that I almost don't remember any of the subtle details."

I've kept a daily work log at my last few jobs -- just a line about each significant thing I made progress on, so usually one sentence a day (and often the same sentence for several days). This could be helpful.

[imetatroll]

Thanks for the suggestion I will keep it in mind once I find another job.

[james_s_tayler]

I've been doing this starting this year. It's magic.

[tracer4201]

Contributing a ton and then not being able to speak to it isn’t that abnormal. Well, at least I felt in the same boat.

I keep a daily log of outstanding and completed tasks. It includes everything from high level sprint stories or tasks to setup meeting with such and such for some project or write status report for z.

[maxxxxx]

“The other thing that might be fascinating is that the technical portion of interviews seem to be where things stall out for me. I would never claim to be an incredible programmer, ”

The interview process filters for coming up with solutions quickly. My strength has always been that I worked through a situation even after the initial or obvious approach(es) didn’t work. A lot of people give up quickly but I keep going and solve it. You sound similar.

Unfortunately the interview process doesn’t filter for that.

[imetatroll]

Yes we probably are. I don't usually walk away lightly from a problem that initially gives me difficulty, but the speed with which I can execute just doesn't seem to satisfy the hiring process. It is frustrating.

[alchemism]

Try interviewing for senior SRE positions, if you would like that quality to become an asset towards being hired.

[james_s_tayler]

This is one thing I consider as a criteria. Will it make a good story?

[imhoguy]

People who leave your company may poach you some day, so continue your quality work and keep in touch with them. That is called networking.

[TheGRS]

Market forces can be tough to predict. There was a dearth of software engineers in the last 8 or so years and many of us have reaped the rewards. The hacker news articles used to be about switching jobs every 1-3 years to advance your salary and career. I don't see so many of those these days, which makes me suspect that many have found themselves in senior-level or managerial roles that they find satisfying, and maybe some found themselves in architecture roles that are very difficult to advance from (but still pay well).

[ec109685]

I think it more likely companies adjusted their salary bands to be at least in the ballpark of each other, so you either need to move locations or take a “riskier” job if you want an automatic large bump in salary. There are clearly exceptions to this, but in general, companies have started to wise up.

[valleyjo]

I’ve seen this happen even within the same (large) company. Someone is a director level who has maybe 100 reports. The entire product gets cut. The IC’a find other jobs within the company. There are only so many Director level positions around and many of them are achieved organically. The ex-director then goes somewhere else as a regular engineering manager unlikely to ever have such a position again.

[scarface74]

Three of my former managers “self demoted” to an IC because they didn’t really enjoy management. Including one of my former managers who is in his late 50s who self demoted after his kids graduated. Now he’s a full stack React/C#/Azure developer and said he threatened to quit his job when they tried to promote him.

[erichurkman]

You need a path of self-demotion otherwise the only route to fixing a misplaced promotion is by firing or quitting.

[pm90]

Yeah this is pretty common in most large enterprises. If your company is not in a hyper-growth stage (i.e. its a cash cow) then upper management positions become a game of musical chairs and political infighting as some leaders try to promote "their" people to top positions to hold on to their power and status.

I guess there are certain folks who find this enjoyable. Personally I find it a massive waste of really good talent and perhaps the single biggest reason why I enjoy the dynamism of the SV startup ecosystem even if I don't directly participate in it.

[hk-mars]

Yes, this situation also make uncomfortable. My company needs me to create new features and design implement the framework, but those managers always get involved with me. I known I can create more technical new features as competitive-advantages for the company at this stage.

[TuringNYC]

That sounds like a liquidity problem (not enough positions opening up, and opening up infrequently) rather than a qualification problem (not qualified for director positions elsewhere.) Presumably, if the ex-director waits long enough they may find another director position (or not...)

[bitL]

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

[maxxxxx]

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

Please don't shoot yourself in the foot. There is nothing unethical about this.

[fouc]

I think you misunderstand networking.

Perhaps you think it's a way for people to create and then exploit their connections in order to get a job that they're clearly unqualified for. I will agree that's unethical.

But that's not typically what networking is about, almost no one wants to recommend someone for a job if that person turns out to be an unqualified idiot. Networking is more about finding people/companies you have something in common with and once they know about you it's a lot easier to get hired or referred.

It's not really about some form of nepotism or cronyism.

[foobarian]

It feels like the OP came from a corrupt or communist locale where cronyism and nepotism were rampant. I grew up in a communist country like this and always found networking distasteful for that reason. However on the spectrum of hiring signals available it just turns out to be one with a very good SNR due to the trust involved.

[viscanti]

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

I don't understand the sentiment. Interviews are a proxy for how good you are. The companies hiring are very limited by what kind of information they can turn up about a candidate just through that process and for higher leveled positions like staff+ that might rarely be enough. Your network can speak much better about who you are and what value you can bring to a company. I don't understand how giving a hiring company better signal about your value is unethical.

[bitL]

I have seen how groups of people with dubious ethical standards played whole companies, pushing each other forward at the expense of more capable people, later taking their cronies with them to whatever company they landed, applying the same strategy. One of them made it to a director position at Google, largely propelled by "great networking". I can't with clear conscience support cronyism that deprives others of their shot at greatness and don't do it myself (rejected a couple of CTO roles advised by a friend with contacts etc.). I decided that expert/meritocracy ideal is better than what I see throughout the industry and academia.

[matwood]

> pushing each other forward at the expense of more capable people, later taking their cronies with them to whatever company they landed, applying the same strategy.

So says you. This can also be thought of more charitably that someone hires people they know because there is much less risk. I've been working in software for ~20 years. I have a decent list of people who I would work with again, know what they bring to the table, and their strengths and weaknesses. If I had to build a new team tomorrow, you can bet I would be calling the people I know first.

[scarface74]

When I was a dev lead, you better believe I pulled in my former coworkers as well paid contractors because I trusted them. There was nothing underhanded about this. I let my manager and his manager know that they were friends and I had them go through extra interviews with my manager even though I usually had the final say about the contractors we brought in. I needed someone I could trust.

[fouc]

cronyism and networking are quite different things though

[bitL]

I agree that in theory they are different, but in practice they seem to blend quite significantly (viewed with my sample size of 1 of course).

[marssaxman]

Cronyism is what you call it from the outside; networking is what you call it from the inside.

[bcyn]

> networking, which I consider unethical and don't do it

Humans are a social species, you can't avoid this if you want to get far.

[matwood]

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

[dacox]

You consider networking to find a new job unethical?

[nickm12]

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.

[hinkley]

There’s a five level ranking at my company, and I applied for a level 4 position (I’ve been in level 5 equivalent positions before).

My boss somehow talked me into hiring in as a 3 for some reason that I no longer recall. I should have listened to the alarms in my brain. I started mid-year so around 18 months I had to wait for a promotion. My boss quits a couple months before that.

3 years and still a level 3. Gave my two weeks and people high in the pecking order are sad to see me go because I’m good at what I do. Well thanks for the complement, but how about a promotion instead of a heartfelt goodbye?

Sometimes it’s not the bureacracy, it’s a boss who either isn’t good at bucking for promotions or burns all their political capital on other things. Other groups get people promoted. Everybody but my boss thinks I’m a level 4 and has for years. That’s how you lose people and never get them back (I wouldn’t want to work for this manager again, not for reasons of aptitude, but simply because he doesn’t prioritize things that I care about).

[auiya]

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

[hellisothers]

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.

[Aeolun]

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

Sadly it’s often the opposite.

[james_s_tayler]

Supply and demand?

When you are employed they demand you show up every day and you supply yourself. There isn't an expectation that you wont supply yourself. After you leave but before you are hired back then there is demand but no supply. Leverage I guess. Makes sense to me.

[mancerayder]

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.

That happened to me, and in my opinion and experience:

. Now you're competing with other managers for managerial roles

. The way you sell yourself for a managerial role is different, and in some ways a lot harder, than an individual contributor

. You have the option of gunning for 'lead' roles that aren't necessarily managing staff. That's what I do.

. You also have the option of architect roles, which is also what I do.

You're a higher tier employee now, and you're now competing with others of that tier level. While for most of us it's actually harder, not easier, to find roles that match, the plus side is there's a reputation and comp upside.

The exception to the last paragraph are those that constantly broadcast on social media and make a name for themselves that way and doing presentations at conferences, etc. Not my cup of tea, personally.

[pm90]

> The exception to the last paragraph are those that constantly broadcast on social media and make a name for themselves that way and doing presentations at conferences, etc. Not my cup of tea, personally.

These are folks who get hired by BigCos as "Evangelists". They're not gunning for the same roles that you are.

Oh hey... the system just works! : )

[zuhayeer]

https://levels.fyi is a good resource to understand where you stand laterally across many companies. Title inflation definitely skews a lot of this. Leveling nomenclature like “principal” and “staff” don’t necessarily correlate across other companies (for example, a senior engineer at Google could come in as a staff engineer or even higher at LinkedIn).

But even outside of titles, it’s difficult to become a new player and start from scratch on learning the inner workings of a company. I think the first step is establishing the confidence to make that move if it is going to be better for your career overall.

[ajdlinux]

It's very confusing reading tech career advice when you come from a company where "staff engineer" is one level above incoming grads and "senior engineer" takes 10 years...

[8note]

that doesn't answer whether he'd be able to work the same role at a different company, regardless of name.

[d4mi3n]

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.

[mlthoughts2018]

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 lot of technical respect from my teammates, but nobody cares at all about my perspective on architecture, scoping, technology investment, tech debt, etc. They had decided merely by the manner in which I joined to give no credibility to my ideas.

The next time I will require the role to be some type of director or IC/distinguished engineer hybrid that is operating with an authority level above that.

[majormajor]

> The next time I will require the role to be some type of director or IC/distinguished engineer hybrid that is operating with an authority level above that.

I've seen this go roughly. A director who brings in a lot of new technical views, challenging the perspectives and opinions held by the team, might not have an easier time than a staff engineer. The director was largely right, but dealt not just with technical resistance but with more political fallout of having disgruntled employees reporting to them.

Forcing change isn't easy. It can pay well, when upper management knows someone needs to take on that role, and doesn't have anyone already doing it, but authority alone won't solve your problems. Especially if your management doesn't want to be seen as the bad guy themselves.

[maxxxxx]

Authority certainly helps. It's not everything but without authority you almost have no chance.

[benc666]

There's kinds of authority. "personal authority" can easily work better than "org chart" authority since it usually has respect and trust attached - which no mere org chart can grant.

Admittedly some org charts do grant "respect" - the same sort you give a rattlesnake.

[maxxxxx]

There is the saying “always speak softly but carry a big stick”. It’s good to build up personal author but in the end it’s good to have the final say. Hopefully with buyin from everybody else.

[mlthoughts2018]

The difference is usually in terms of negotiating details about the budget & resources you’ll have when you join, your own much larger severance package or equity package with acceleration provisions, etc.

Based on the degree of resources they put into you at a director level, the option is disallowed for other people to fail to work constructively to onboard your new ideas / approaches.

Definitely still may not work out, but it’s a different ballgame than a high level engineering hire, which (however foolish) many companies will still view like they are sweetening some pot just with the title and don’t have any plans to honor the agreed nature of the role.

[matwood]

If it is going roughly that's on the director. Soft skills come into play when trying to make changes. IMO, "forcing" change means there are already leadership skill gaps with the director.

[solipsism]

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

[mlthoughts2018]

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.

[solipsism]

Ah, so it wasn't that nobody cared about your perspective. It's that managers didn't care about your perspective.

A gem I've picked up from my experience in different kinds of tech companies: Never work anywhere where managers are the ultimate decision makers. At engineer-driven companies, managers are enablers.

[mlthoughts2018]

That really is a good heuristic. Managers at these companies should be asking, “what do we need to be doing?” and “what do you need to get it done?” If instead they are dictating what to do or only telling you what you can’t have, that is big trouble.

[hk-mars]

so I think this kind of managers is the “shit” :)

[dehrmann]

This probably had more to do with the org and the role than the title. Management probably recognized the gaps and shortcomings of the team, but never had buy-in from the team that these are problems and more senior people can help with them.

[pvarangot]

I think a director should only kind of "put value" to tech debt, making the mid-term and long term choices and assessing the risks. How to do the actual tech debt emission and how to deal with it when it hurts is more of a staff engineer thing.

If you think that as a director you'll have "power" to make actual week to week or month to month architectural or technical decisions you are thinking more of micro-managed projects and not of serious mid-sized or bigger engineering organizations.

[mlthoughts2018]

I mean the general prioritization of tech debt as a continually worthwhile time investment / required basic hygienic activity necessary for product health.

As a staff engineer, I provided inarguable evidence that tech debt had been ignored to the point of extreme risk of product failure and revenue loss, along with well-scoped and iterative approaches to pay down the tech debt with ideas and creative effort from the existing tech leads and experienced engineers.

It was just squashed for political reasons. In this case, product management happens to be the part of the hierarchy with all of the “the buck stops here authority” and since tech debt did not contribute to visibly obvious progress on vanity features and cosmetic product changes (that had not been rigorously derived from product feedback, expertise or needs), then tech debt was disallowed from entering any quarterly goals, etc.

Director or certain “org wide” IC roles could plausibly have authority to stop that.

Sorry if I have the impression this was about micromanaging weekly tech debt stuff... definitely not.

[maxxxxx]

I have been in a similar situation as contractor. I would only do it again if I was in a position where I could ultimately call the shots. Usually that means being some kind of manager.

[tetha]

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.

[james_s_tayler]

This. This really is the value add and it's unique to every company, so it just takes time to learn.

[sam0x17]

And at some places the "senior" engineer IS the principal/staff/architect.

[sb8244]

Company size seems to (rightly) play a role in how many levels there are in the career track. Part of the mentality that the business needs to take off before titles are concerned. However, this would most likely apply to <20 person engineering team. If the engineering team is bigger than that, I'd question why the org structure is flat.

[d4mi3n]

Flat orgs at their finest.

[mxstbr]

I think you are right that seniority at the specific company plays a large role.

Anecdotally, I was told that GitHub does not hire from the outside above the senior level. Going from senior to principal engineer is expected to happen inside the company.

[mooreds]

Which is interesting to me, because once you get to staff inside such a company, how would you move to a different company? Are you locked to the company because any other move would be a drastic reduction in comp (because it would be a drastic reduction in value)?

Or are there transferable skills that are valuable enough that a transfer could happen at roughly the same comp level?

I don't know but this is an interesting question in terms of human capital and labor mobility.

[majormajor]

Pay bands are usually wide. You might find a role that's a step down title-wise but a sideways step comp-wise, though of course that's less likely the more you have in current comp. The top companies like their golden handcuffs.

You have to think about what you want to be doing. I think a strategy that's (company) tribal-knowledge dependent is a risky one, since it's going to be very hard to transfer. Industry-level tribal knowledge can be much more valuable, since you could move to competitors. Technical domain-level knowledge can be even valuable still, but if you're doing more soft-skill architectural guidance and mentoring you might still run into a shortage of companies willing to pay the same premium you're currently getting for that. Some companies may not need it, others may need hands on speed more at the moment. But in that case, they probably do need soft skill technical expertise + management, which at a small, young company is going to be much different than big-co management anyway, so that's an option too.

[toomuchtodo]

Staff/principal SWE compensation is the premium an org pays for your tribal knowledge, and arguably non-transferable. “Golden handcuffs”.

[maxxxxx]

Outside the big companies in Silicon Valley there are no golden handcuffs for engineers. With each promotion you make just a few percent more.

[pvarangot]

This is not true in engineering contractors for aerospace in Europe or the USA, and it's also totally not true in the oil industry worldwide and in some of the big manufacturing firms. You can get double digit percent promotions by getting into roles that require a lot of travel, dealing with big outsourced contracts, have cross-country responsibilities, or other particular skills or layers of hardened skin that are hard to come by and at a premium.

[pault]

I'm not sure about that. I moved to Austin three years ago and I have doubled my salary twice since I got here.

[maxxxxx]

It depends probably where you are starting from.

[strken]

This wasn't true for me in Australia. All my pay raises and promotions were double-digit percentages.

The bay area does have very big handcuffs, though.

[TheGRS]

At that point you would probably move into consulting.

[nevir]

Senior levels often have pretty wide bands, partially due to this. If you're moving to an organization that hires as senior, you'll almost certainly be able to negotiate your comp pretty far up

[twblalock]

Tribal knowledge is good to have, and inevitable, but it is also a blinder that tends to limit people to a particular set of architectural assumptions, and this gets worse the older the company becomes. It’s also an obstacle to bringing in new people.

Some people are able to join a company and expand/modernize/build on the tribal knowledge to make things better. It’s a rare gift but I’ve seen a few people do it. People like that could be a principal engineer at almost any company.

[dehrmann]

I've seen engineering leaders at companies with lots of tribal knowledge who have been there so long and are so committed to and defensive of old decisions that they're net negatives to the company. They're like helicopter architects.

[firebones]

I've seen that too. And I've also seen some of the same people with very adaptable personalities who are continually learning and inquiring and who make working at such places tolerable.

[gedy]

Thank you for the simple description of this. I've struggled to describe what I enjoy (and like to believe I'm good at).

[m0zg]

>> I am not sure if the title of "staff/principle" can be transferred

It usually can, actually, assuming you're going to a company of roughly the same stature. I.e. if work at a small company, your title doesn't mean much when going to a large company unless you're otherwise known in your field. And if you're a Staff engineer working at e.g. FANG, you can demand the "God Emperor" type title at a small company and you'll probably get it if they feel they need you.

The only things that matter are really:

1. Whether you'd enjoy the work

2. How much you get paid

Titles are arbitrary and they don't mean anything outside a particular company. Even between otherwise comparable companies there are significant misalignments, see e.g. https://www.levels.fyi/SE/Google/Facebook/Microsoft

[matwood]

I worked with a guy early in my career whose title was "Keeper of the Magic".

[cthalupa]

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

Outside of the politics and trust portion, most of this should be well documented and not something that relies on a person being around. What's been tried, and why, should all have documentation around it - what worked, what didn't, how the decision was come to, what data points were considered, etc. All of that is valuable, and it should have all been documented along the way to help back up the decision making process to begin with.

When the time comes to make decisions in that same vein, people can review the previous process. Maybe they have new information to bring to the table. Maybe they didn't account for something that was considered last time. Maybe the "you" of whatever process is no longer with the company.

I'm in a similar position to you. I've made it a mission the past couple of years to try and eliminate myself as a single point of failure for this sort of information.

To the second point, just because the job posting isn't there doesn't mean the job doesn't exist. Companies might not be looking to necessarily hire a staff engineer specifically, but could see the value in one if the right candidate appears.

[dizzydee]

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)

[01100011]

> I am not sure if the title of "staff/principle" can be transferred

It depends on how you got to be a principal. If you fell into the role because of accumulated knowledge and promotions, probably not. If you are self-driven, work to achieve complete knowledge of your company's products and technologies, push for high standards, and can transfer knowledge well to others...yes.

[hk-mars]

agreed

[mac01021]

Tangentially: anyone know where this use of the word "staff" comes from?

[jboles]

In some defence forces there is an NCO rank above Sergeant named Staff Sergeant, is my guess.

[Cthulhu_]

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

I can confirm this; about three years ago, I was in a position that was similar to this post's description of a principal engineer - doing a lot of code reviews, meetings across teams, interviewing, etc. I haven't had a similar position since; it's a very er, opportunistic one? In that you need to be in an environment where there is a need for a role like that. It's a role one needs to grow into.

[vikas5678]

With every organization, once you are part of a product initiative for a few years, this question of "how transferable are my skills to a different domain or company?" is a valid one to ask oneself.

Also, it is easy to get so involved in the daily busyness, that your skills might not be transferable.

I think spending some time in being curious and learning/investing in transferable skills, and building a "brand" of helping others(either online or in person) helps significantly when it is indeed time to pursue that next opportunity.

[vostok]

> In the past year, I have seen less than 5 job posting for a staff engineer.

Isn't this "just" a matter of getting leveled at L6/65/etc as opposed to applying to an advertisement that's only looking for staff level engineers?

[all_usernames]

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