I suffered with this problem quite often with my previous job. There would be something vague assigned to me and I didn't quite get what to do but I also felt like if I asked questions, it'd give off a vibe like I didn't know what I was doing so I would just start programming and making a bunch of assumptions.
That wasted a lot of time which is a lesson to be learned from.
My superpower as a staff engineer was having zero shame in asking questions. Anything from "what does that abbreviation stand for?" through to "what will the traffic look like when we go live?" - mostly people are worried about looking ignorant, so weirdly this makes you look both knowledgeable and confident! I wish I'd known that when I was younger...
While I wouldn't say more people shouldn't do this more of the time, there is also a lot of social capital you have as a staff level person that makes it "easy" to do this. (and is part of why it's important to)
One of my favorite moves is to ask a question that I feel has an obvious answer and then say "what am I missing?" Sometimes I am right, other times I am missing something.
Either way I'm modelling:
- that it's okay to ask questions to which the answer seems obvious
usually what i did is to take an abstract spec, derive thick layers / modules to decompose the problem, and then look at the deadline to see what MVP i can draw in that space.
whenever that mvp is not what was expected, if i'm lucky enough, the decomposition allows for easy adjustements to match the need
Can someone who worked in multiple industries clarify: is it only software that has constant identity crisis with "what makes you X" and "what is expected of Y"?
The only thing that makes a senior are years of experience, that's all. You can be a shitty senior if you only do one thing for 10 years, but you're a senior nonetheless.
I was a teacher, and I didn't notice anything similar. It's just a job -- if you can do it, you can do it. You can be more experienced, you can be more comfortable with solving certain problems, you can do it better or worse, but there is not... this.
Some software developers seem to be in a lifelong dick-measuring contest. "You are not a true X unless you know this one important thing that I know." Okay dude, now do you expect Miss Teacher to come and praise you for how clever you are? You know some things that others don't, perhaps the others know some things that you don't, why is the former important for being a true X and the latter is not.
In software engineering, "senior" or not usually means you can be trusted to take on certain problems vs. others.
In US primary school (an industry I've never worked in), this might be close to something like teacher, curriculum planner, assistant principal, principal, district supervisor, etc.
As you progress further in your field and hone your skills and knowledge, the scope and impact of your responsibilities should grow.
If you have contacts on the seniors who have left, call them, ask them if they like the companies they are currently working for, and whether the companies are looking for new hires.
In the job interview, give them the list of responsibilities that you have now. Then ask for a higher salary than you have now.
Jump ship. You'll forever be bargaining for the pay rise and if you do get it and don't deliver for whatever reason you'll end up shooting yourself in the foot. As the recent justification was for more pay.
I like the post but I’d add senior is also the instinct to take risks. I was once at a client in NY with an ASP.NET code base that used the compile at runtime capability (like Java used to). The C# source was being pushed to the web server.
I ran a compile and the code was riddled with errors. So I went to the PM and explained the code needed to compile and I needed a day to clean it up.
I refactored the entire project to compile and deploy that way. After that the development went very fast.
The hilarious part was the three devs who’d gone on vacation came back and thought what I’d done was “wrong”.
But the client said we (consultants) had done in two weeks what they couldn’t do in six months.
That's an old ASP.NET Web Forms / ASPX thing that was IIS-based. IIS would just compile .cs files into a temporary folder when first running. So the first request takes like 5s or something.
It's not the new .NET Core AOT feature, GP was building the DLLs and packaging the website locally.
Not GP but funny enough I ran into a similar problem with a team that also didn't know compilation and was just copy/pasting into a server.
>> So the first request takes like 5s or something.
I haven't worked with IIS in more than five years, but couldn't you change some setting to infinity so the thread never sleeps... or something like that? I remember the "5 second" thing being a problem with commercial IIS apps we deployed, and that's always how we avoided it.
This shows very visibly in the devops/platform engineer/whatever-the-hell-we're calling-it-these-days world.
Often you will get a request, sometimes (or quite often) you have no idea what is driving it, like for example "reduce rate limiting for xyz service." Lots of ops guys will just blindly do this ticket shuffle, even very senior ones - maybe for their own sanity, maybe out of preservation - but the best ones I've ever worked with, will often question "Wait, why do you need that?" Then you find out there is some other really trivial solution to fix that underlying problem that doesn't involve as drastic of a change, or maybe even none at all. Especially if it doesn't involve code change on their side, you're not going to face much headwind in pushing back.
The reason this is important is that, no disrespect to developers, they often live in a world where they treat infrastructure as a blackbox (as I believe they should). The problem sometimes is they want to also control the behavior of that blackbox. So while the request may seem to solve the problem, often there is a much easier/simpler/safer/scalable way to fix whatever underlying problem got tossed over the fence to you.
The senior guys I've respected the most always will ask the "wait, why?"
I realized I was senior when jr. people would ask me things like "how do I make awk do this this?" and I responded with "what problem are you trying to solve?"
>> Often you will get a request, sometimes (or quite often) you have no idea what is driving it, like for example "reduce rate limiting for xyz service."
At my company, we do not allow tickets that prescribe a solution. A ticket can only describe a problem or a need. The engineer is then responsible for starting a conversation with the stakeholder(s) to discuss which solution might work better for them. They then implement that solution.
I know that larger companies have multiple teams that sometimes create tickets in each others' queues. I think this is a mistake. In multi-team environments, requests should go through some sort of custodian or gatekeeper who is responsible for making sure the problem or need are documented fully. This person can be a product manager or a scrum master. It should not be an engineer, though.
I've had good PMs answer most of this themselves. Only if there's a technical detail they don't know about do they then ask specifically.
OTOH other PMs throw vague jira-shit over the fence because they know how to take advantage of seniors who have been taught to reflexively work out the details even though it should be PM's job, just like this right here:
>So we end up with “senior” engineers who can reverse a binary tree on the whiteboard but freeze when the spec is half-baked.
The story here should be "the senior engineer is senior because they tell the person responsible for the specs to not half-bake their specs", not "senior engineer is senior because they fixed someone else's incompetence", but even then, there is likely a manager that should be demanding that before the senior does.
Some of you senior engineers are less senior than others, and what I've continually seen is early senior engineers covering for other people (like half-baked specs). Eventually they learn that maybe a PM/Design should put some effort into a spec and covering for them means more work without compensation, and they stop fixing the laziness.
If you have PMs answering the how of issues such as "we need to improve performance" or "we should probably think about scaling", then the senior engineer on the team is the PM, not you.
The list of example questions at the bottom is clearly not exhaustive.
Sure, those two specifically can be handed off because they involve basically no user journeys for the product and a PM can't reasonably be expected to know the technical details of performance or scaling. But any PM or engineer should be able to at least ask "is the performance bad everywhere, or only specific things"?
But a PM absolutely should be diving deeper to get more details on "users are complaining about the onboarding flow" and figuring out what should be fixed or what the ideal onboarding flow should be before involving an engineer. The exception of course is the onboarding flow has errors or is slow, which again the PM is not responsible for.
This is basically a full-time job for many senior engineers. It may as well be the job description. Thing is, most of these 'leaders' are not capable hiring competent engineers - as if they're capable of identifying competence. You do not want to end up at one of those organizations - but they are everywhere.
If juniors ignore guidance and advice, they stay in junior roles, handling simpler, less impactful tasks.
Everyone seeks career growth, but pushing for it too quickly often just leads to inflated titles without real substance.
It’s perfectly fine to remain a mid-level engineer for your entire career if it makes you happy; it’s solid, honest work that contributes meaningfully.
Plenty of people in their 60s have held the same job for decades, and that’s okay; it can be a path to genuine satisfaction.
Hinging senior evaluations on junior promotions directly fuels the title inflation I’m decrying. Desperate to show “impact through development,” seniors (or managers) push for premature title bumps; turning fresh juniors into “mids” or “seniors” without the skills to match, just to hit metrics.
This is rampant in tech, where inflated titles compensate for everything from low pay to talent wars, eroding expertise and making hiring a nightmare.
We end up with a system that prioritises optics over substance, where growth takes a backseat to checkbox promotions. It’s frustrating and counterproductive.
Mentorship should inspire organic development, not force-fed ladders that collapse under their own weight!
Instead, let’s measure seniors holistically, decoupling from junior title escalations to allow people to excel at their level indefinitely. Alternatives include:
* Technical Proficiency and Individual Contributions: Use code reviews, technical assessments, or metrics like deployment frequency and bug resolution rates to gauge a senior’s direct impact, without needing to “graduate” juniors.
This focuses on their own output and problem-solving prowess.
* Knowledge Sharing and Enablement: Track things like workshops led, documentation created, or peer feedback on guidance quality via 360 reviews—emphasising team uplift without mandatory promotions.
* Project Outcomes and Efficiency: Evaluate based on team velocity improvements, innovation (e.g., patents or architectural wins), or overall delivery success, rewarding systemic contributions over individual mentee milestones.
These methods honour diverse career paths, letting juniors stay put if it suits them while still valuing (and evaluating) senior leadership.
> Any mentor type figure is going to be at least partially evaluated by progress of the mentees against some benchmark.
Sounds like the same kind of mistake as evaluating teachers by the grades of their students. Soon people figure out the "one weird trick" how to get the highest score easily.
> Everyone seeks career growth, but pushing for it too quickly often just leads to inflated titles without real substance.
That's why I'm not a big fan of recommending people to often and quickly change jobs to increase titles and pay. Their skills don't level up the same way, and they end up with a title of senior/lead developer and can't actually build maintainable systems or solve problems that nobody tells them the solution to.
If one is unable to work alone but manages to join a new company with an inflated title, people will notice. They're gonna have to keep job-hopping until they find a place that doesn't notice the bad performance anymore.
This is demonstrable by the amount of CVs with "12 jobs in the last 6 years" in my reject pile.
Yes but there is also a temporal component as well. A Senior should be able to do all their tasks and whatever else comes their way without needing guidance. To be able to do that requires a certain level of time in position.
nah, the tasks evolve as you get older. having a senior do all their tasks and whatever else without guidance sounds like free work. even the old people in the old folk's home get an assistant to help them take their pills!
> The moment you hand them something fuzzy, though, like ...
> “we should probably think about scaling”,
> that’s when you see the difference.
Senior engineers should ask, "but do we need scaling? And if it does, how much needed now and future?"
But I've seen a lot of seniors who jumped to implementing an unnecessarily complicated solution without questions, because they don't think about it too much, want to have fun, or just don't have energy to argue (I'm guilty myself).
Isn't that just called "being put in charge"? The causality seems reversed to me here, as in, you're not senior because you're reducing ambiguity, but you've either explicitly been made senior or just have tenure and now others come to you with questions about what you think makes sense. Consequence rather than cause
Or maybe that's just in egalitarian companies, like in tech where I'd ask a second opinion or technical input of just about anyone, whereas in other lines of business it's different? I imagine a water treatment facility has a lot more niche constraints to work with than we do and so expertise goes much deeper and you're not immediately prompted for advice
When everyone in the room wants to go in a certain direction. And you tell the team "9/10 times i did it that way it blew up in my face.", and you don't fight them and let it play out as a lesson. And there is still a 10% chance it could work!
Who are the people in the room (including you) and what are they responsible and/or accountable for? There's a time and place to say "that's a bad idea", but typically it's 1:1 or very small groups not in a broad team setting. You also can't always be the naysayer, it is political capital based on a proven track record of saying what we should do instead—not necessarily in the same venue, but if you're just a perpetual pessimist it's of no more value than the irrational exuberance of the naive optimist.
This is not a positive behavior, also you should ask yourself why everyone wants to go against your position so often that you have a strategy like this in the first place.
Likely these are not “lose your army level” lessons. I’ve let idiots touch a hot pan if they’ve insisted to do it. I would not let someone pour gasoline on themselves and strike a match
Some people have to learn the hard way. I haven't personally encountered this in the professional world, but in my personal life there are several close family members who I've stopped giving cautionary instructions except in the most serious cases. No point in being Cassandra unless the Greeks really are invading.
Because it's not "your army" and there's no point in fighting meaningless wars. Just make a good effort to convey your point and if they still don't listen - let them learn their lesson.
It's subtle, but I think the use of "senior" rather than "Senior" in the article is an attempt to distinguish the concept of being a senior engineer from the title of Senior Engineer. The article is focused on actually being senior, not playing title games. I'd take it further and use the term "leader" instead of "senior engineer".
Leaders reduce ambiguity, so others can operate with more clarity. The ambiguity involved can be in many different domains. It can be focused on product and tech, as in the article. Another example is ambiguity around people and organizational structure, which is more common in management roles, where some in management are more effective leaders than others. It can be around finding ways for people to understand why they might want a product, which is more common in sales and marketing roles. And so on.
A very important skill for Senior engineers not mentioned in the article is an ability to take the initiative on something. For example, when a dev sees a bug in an area of code they aren't responsible for and thinks "I'll raise an issue for that and mention it to the product manager so we can get it fixed" instead of "Oh, a bug", then they're starting to show that senior mindset. It's a desire to make the whole of the software good rather than just the little bit they work on good.
beware, some cultures are territorial in nature and this kind of hard ownership will make people slap you if you ever try to improve things as they come.
i'm in the camp of improving things regularly without hesitation but again this can devolve. another way it can turn sour is when the team is made of people too different from each other. one improvement from someone pov is a waste or even a regression for others .. then it's a 'who decides here' conversation.
that said when you have a cohesive group all focusing on pushing in the same direction then it's bliss
I did this by constantly complaining about JavaScript and how TypeScript is so much better until some of my colleagues started writing new projects in TypeScript.
I have literally never seen or thought of this as “senior” thing. if anyone on the team regardless of their seniority does not operate this way they will see a quick exit to some other place
I like this. I more generally look for reduces chaos.
I’ve seen the pursuit of disambiguation employed to deadlock a project. Sometimes that’s the right thing to do—the project sponsor doesn’t know what they want. But many times the senior needs to document some assumptions and ship something rather than frustrating the calendars of 15 people trying to nail down some exact spec. Knowing whether to step on the brake or the gas for the benefit of the team and company is a key senior trait.
This is a yes, and to the article; building without understanding the problem usually will increase chaos—though sometimes the least effort way through it is to build a prototype, and a senior would know when to do that and how to scope it.
Eh. Whenever someone posts something like this, you get a bunch of folks, stating how they meet that description, etc. Sometimes, they do it humbly, sometimes, not.
In my case, I met that description on my first job, and I guarantee, I was not senior.
You see, my initial training was as an electronic technician (RF/microwave stuff).
That thought process described, was exactly what they trained us to do. Debugging a wonky RF board is about as ambiguous as you can get.
So maybe there's a different definition of "senior."
Great article. The key things often missing in meetings discussing a vague problem is do we really understand the problem and how do we make concrete progress. Its a hard skill and often just comes through experience - being able to put yourself in the user's shoes to understand their problem, and knowing based on past experience, how to execute. That is the value of seniority.
When did this "junior/senior" lingo get cool? I don't remember it being used when I was young. Maybe the leet code trend brought on a sort of gamification of the profession, with ranks etc..?
As a 51 year old, I hate when other old people think that “back in my day things were different”
> Evans has held his present position
with IBM since 1965. Previously, he
had been a vice president of the Fed-
eral Systems Division with the man-
agement responsibility for developing
large computing systems; the culmina-
tion of this work was the IBM/System
360. He joined IBM in 1951 as a
junior engineer and has held a variety
of engineering and management posi-
tions within the corporation
The title has always existed. I meant the obsession about being a "a junior" or "a senior", like gaining an achievement in a video game or something. I just thought every young person was a junior engineer and every old person was as senior engineer.
You don’t get to be a senior engineer just because of tenure. It’s not gaming the system to expect a level to be based on the amount of responsibility and not just from getting 1 year of experience 10x.
You want a promotion because you want more money. Even though I have found the difference to not be that great on the enterprise dev side. But in BigTech and adjacent, we are talking about multiple six figures differences as you move up.
I work in consulting and our bill rate is based on our title/level of responsibility. It kills me that some non customer facing consultants want to have a “career track” that doesn’t involve leading projects and strategy and want to stay completely “hands on”.
We can hire people cheaply from outside the country that can do that. There is an IC career track that is equal to a director (manager of managers). But you won’t get there hands on keyboard.
The bigger the company the less impressive "senior" is. There are probably three levels of staff above it and then distinguished super fellow territory.
A senior software engineer can easily make $300-400K+ at BigTech that’s “impressive” enough to me.
On the other hand, a “senior” working at a bank or other large non tech company will probably be making less than $175K if you aren’t working on the west coast.
When I talk to a senior: “hey we got this initiative, I know only little about it. Can you talk to $stake_holder figure out what they need and come back to me and let me know your design ideas, how long you think it will take, etc”.
I can do that with a few seniors and put Epics together and they can take ownership of it.
For a junior I have to do a lot more handholding and make sure the requirements are well spelled out
When I was a junior engineer, I did not need almost any hand-holding, and could take ill-defined initiatives, figure out the desired goals and outcomes, and ship them.
It's just that my code would be shit (hard to understand, hard to test...), but I learned quickly to improve that through code reviews (both getting them, but also doing them) and architecture discussions. I can't thank the team enough that put up with me in my first 6-12 months :)
When I find a junior engineer like that, I give them as little as I can, and remain available to pair, review or discuss when they get stuck. And they... fly... But I also try to develop these qualities in everyone, but it's sometimes really hard to get people to recognize what is really important to get over the finish line.
And I've seen plenty of "senior+" engineers who can't do it and go on to harp about a field in a data model here or a field in a data model there, adding weeks to shipping something. So really, it is only a paygrade.
Any of those "competency matrices" are really just a way to reject anyone from that promotion they are hoping for: it won't be a blocker if that someone has this innate ability to help the team get things done.
It’s way more than a “pay grade” for any company with real leveling guidelines.
This jibes with both my personal experience at BigTech, knowing the industry and various publicly available leveling guidelines. Sone are more granular
So are you really arguing that tech companies that pay top of the industry don’t require that you demonstrate that you can handle responsibility that requires you to be able to work at a larger scope, impact and dealing with ambiguity and go through a promotion process with a promo doc?
Are you saying that when you interview for one of those tech companies that they don’t level you according to your past experience?
Yes I know the answers to all of these questions from both personal experience of interviewing and hiring at one BigTech company and ignoring outreach from another’s hiring manager who I had worked with in the past.
(At 51, I would rather get a daily anal probe with a cactus than ever work at a large company again and I am damn sure not going back into an office)
You've put a lot of words in my mouth, and I don't know why.
What do I suggest? I suggest that big organizations have pockets of careful, competent folks. But in general a large company tends to be all fouled up. They do a lot of things pretty much randomly. Some stuff happens the way a new graduate has a right to expect, and the way many HN commenters insist it has to go.
But a lot of other shit just ... happens. People get promoted because they have another offer from another fouled-up company, or because the boss thinks they're awesome (but sometimes the boss is dumb), or because they talk the talk exceptionally well, or because they happen to get the attention of someone 2 or 3 levels up, or whatever.
Is any of that controversial? What am I missing here?
Do people not still read Catch-22? Or has it been proved wrong or something? Or take that mysterious cactus that you mentioned in connection with large companies. What's that about? Because the cactus sounds bad.
I have only worked for two large companies in my career - both Fortune 10 companies when I worked their - General Electric and Amazon.
At GE? Sure things are random. But it was also just another random enterprise company where it really didn’t make sense to work toward a promotion just to make $10-$20K more. You would be better off just getting another job (which I did after 2.5 years). There were no published leveling guidelines or procedures.
But I can guarantee you that a random mid level developer is not going to walk up to their manager with a competing offer and be handed a promotion at any of the large tech companies. The manager by themselves can’t determine a promotion. There are promo docs, committees, recommendation requirements. Etc
At 51, with just me and my wife, grown kids and already had the big house built in the burbs that sold for twice what we bought it for 8 years earlier and we downsized to a condo one third the size in state tax free Florida, the juice ain’t worth the squeeze.
But if I were 22 and had a choice between wallowing in enterprise dev making 90K doing CRUD apps or making $160K out of college and over $200K at 25, I would play the game with the best of them.
My own anecdote is that outside of BigTech now, I’m a staff consultant working at a 3rd party AWS consulting company making the same as a 25 year old SA that I mentored when they were an intern at AWS and the first year they came back
idk about titles, but my basic thought is that when you are less experienced, you're paid to do things, and when you are more experienced, you're paid to know things.
But it also depends on the organization. If your managers love to micro-manage, you will be paid to do things, because someone else believes they know better than you.
There is no denying practice is needed, but... I've been doing this (getting to reduce ambiguity and simplify complex problems) since before my first job in free software communities, yet really, I wasn't anywhere close to "senior" when I joined my first job at a demanding SW organization at 22 years old.
There was simply a lot I did not know, but I had the talent to do this part well (sure, one can argue that I had "practice" doing this with any problem since I was ~10 years old, but calling that "senior" would be... over the top: I think it rather qualifies as "talent").
It took me a couple of years of learning good software engineering from my wonderful and smart senior colleagues and through my own failures and successes for me to become a Tech Lead too.
Disagree, it's not _just_ practice. You can do something for 10,000 hours but never actively try to improve. Does that mean you're now more senior because you had more volume of practice?
e.g, let's say someone spends 10k hours doing just 'addition and subtraction' problems on 2 digit numbers. Are they now better at maths than someone who spent 0.1k hours but doing a variety of problems?
To grow as a software engineer, you need to have volume + have this be outside of your comfort zone + actively try to improve/challenge yourself.
Apart from this, I do agree it's not 'innate talent' that drives someone to become a senior engineer, and I think anyone with the right attitude / mindset can do so.
It is. You might pat yourself on a back that you're "not like them", and in fact might be better than them, but if they hold the same title and earn the same amount of money – they're senior just like you.
These are typical questions I ask when I’m interviewing a senior developer:
“Tell me about a project you’re most proud of?” Then I’m going to start asking questions about your decision making process, how you dealt with complexity and ambiguity, etc.
If all you did was pull well defined tickets off the Jira board, you’re not going to be able to answer that question well and you aren’t the type of person I’m going to delegate a very ambiguous assignment where you have to make good architectural and organizational decisions and have to deal with “the business” to disambiguate.
The next question would be “Looking at your resume, I see you have $x years of experience, if you could go back to one of your earlier projects, what choices would you have made differently knowing what you know now?”
If you haven’t led any major initiative, what are you going to say? “I would have pulled more tickets off the board?”
I interviewed someone from AWS at my last job, he thought he was a shoo in especially after he looked on LinkedIn and saw that I was from AWS. I guess he thought he was going to be reversing a binary tree.
No matter what I asked, he couldn’t describe anything he had done of note except be on a team who did stuff. I asked him had he led any features, presented any “six pagers” internally, blog posts on the AWS site, presentations - he had done nothing.
I passed over him for a guy at an unknown company who could talk about where he “took ownership”. That’s one of the Amazon BS Leadership Principals.
Hell I had a public footprint at AWS after only 3.5 years I had been there as a mid level L5 employee.
I do all my interviewing in a very similar way, but I don't use that to "level" an employee: I want most of the engineers in my team to have this mindset, and the only difference between seniority levels should be in the size/scope of the initiative they led and took ownership of, and obviously, the level of exposure to wrong things they had a chance to do and learn from. I will sometimes take someone where I believe they were not put in a position to do this, and who I believe I can support to develop this mindset.
I know I've done all of this since day 1 of my professional software engineer career (and well, before that too). I've also been "side-moted" to a Tech Lead after 2 years of starting my career in a strong tech company too.
One thing that I would like senior colleagues to avoid is the tendency to claim something can't be done or is impossible. Sometimes, a colleague would claim something can't be accomplished but when I do accomplish it, it can create tension and give the impression that I'm undermining them. I would prefer if senior leaders instead enumerate the reasons why it can't be done and avoid dealing with absolutes. Often, it requires research into unknowns that have real limitations such as costs or processing time. Thank you for considering it if this is useful to you.
I think a lot of people in the comments are getting hung up on titles and missing the real point of the post. The headline probably didn’t help with that.
The post actually does a great job of highlighting a genuinely valuable skill that the best engineers practice regardless of their title. In particular, “reducing ambiguity” is something I believe would be really beneficial for many early-career engineers to intentionally develop.
That wasted a lot of time which is a lesson to be learned from.
I also struggled with self management.
reply