Q&A highlight
Posted15 days ago
Key Takeaways
“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 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.
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
ps: even beyond work, that kind of knowledge is very important, culture is a form of abstract layer over a group, and it can make or break your future
> 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
Dated 1969
https://bitsavers.org/magazines/Computer_Design/Computer_Des...
Next meme that needs to die: “back in my day, developers did it for the love and not the money”
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.
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.
For instance Delta
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
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.
This jibes with both my personal experience at BigTech, knowing the industry and various publicly available leveling guidelines. Sone are more granular
https://www.levels.fyi/blog/swe-level-framework.html
https://dropbox.github.io/dbx-career-framework/
The company I work for now has similar leveling guidelines, it’s also more granular.
But levels are defined by scope, impact, and dealing with ambiguity
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)
Is that controversial?
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
I see a bit of contrast between your faith in these institutions (first three paragraphs) and your feelings about them (last paragraph). How can that be?
- Junior - someone who can work under guidance. - Regular - someone who can work alone. - Senior - someone who can guide others.
I understand that everyone wants career advancement, but all it ends up doing is inflating titles.
It’s totally fine to be a mid level engineer all your life if you’re happy. It’s honest work.
There are 60 year olds who have had the same job their whole lives. It’s ok.
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.
Any mentor type figure is going to be at least partially evaluated by progress of the mentees against some benchmark.
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.
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.
In either case it's an ambiguous problem that needs to be solved and just throwing your hands up and saying that you don't want to be evaluated for that is not going to help.
One dev I know was recently pip'd and asked me for advice. I asked him something his manager never could: "Do you really want to be here? Because fighting a pip is hard and you should make sure you really want what's at the other end."
If someone on my team wants to remain a junior dev for life, I'm going to tell them "here's how you can keep your job and make sure you always clock out at 5". There is absolutely a path for someone to aim to not have career growth and still produce the most value to the team given that decision.
It's perfectly fine remain "mid" (not junior IMHO) but is not ok to ignore guidance and advice from more experienced team members.
In the end, if a junior is repeatedly not responding to appropriate guidance or advice, then that junior should be gone from that position. Same for a senior who is repeatedly dispensing inappropriate guidance or advice.
But it requires careful analysis of the situation before such a drastic course of action: is there a communication problem, a training problem, a mistake in evaluating abilities?
A senior should be able to navigate cultural and technical differences competently. A junior should understand that that the ones with responsibility for a project also have the authority to make decisions about the project, which should be honored.
I have one junior at my company who is notorious for moving fast but wrecklessly, delivering results quickly that ultimately are so error prone they're not worth it. Anyone else at the company offers him suggestions, he balks at it. I just suggest there might be a problem? He's immediately all ears and eager to learn.
Whether they're motivated by ego or pure curiosity and love of the craft, juniors will seek the advice of a senior they see as representative of the dev they want to be.
Part of being a "senior" (in the meaningful sense) developer is setting and example of why you would even want to be a senior dev in the first place. It sounds insanely cheesy but people listen to the people they want to emulate.
This. Totally agree. Seniority level it’s based on the volume of practice someone has. Period.
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.
- Steven Covey
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.
That wasted a lot of time which is a lesson to be learned from.
I also struggled with self management.
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
- that it is totally fine not to know everything
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)
In an ideal world, juniors would all do this too, but I don’t blame them if they don’t. So it’s very important to do it if you have the social capital.
The details of how I ask it might change based on seniority, but that I ask it? No.
The idea of “disambiguation” is itself ambiguous. The way I recognize other people solving problems at a staff level is we are communicating in terms of properties, constraints and tradeoffs.
The first couple chapters of Roy Fielding’s dissertation goes through this. The first time I tried reading it, I did not have experience understanding that. The next time I tried reading it, it was helping me gel and articulate things I had started observing from experience. I recognized that I had previously been so focused on architectural elements and that the properties and constraints were far more important. It is this that determines what is being traded off, and antipatterns pop out. Knowing properties and constraints allows me to quickly identify problems, and start the process of disambiguation. Many of the other staff or principal engineers I have chatted with communicate along these lines.
Honestly, orgs that don't "get this" is why consultants exist.
Depending on who you are engaging with, a packet of Hobnobs (other socially acceptable bribes are available) might be needed or perhaps waiting until after lunch.
Now, your next mission is getting something done by making someone else think it was their idea in the first place. It might sound counter-intuitive: "How does that benefit me, they get the credit". Crack that conundrum and you will advance to the next level.
One issue I have quite often is I'll know I have a problem with understanding something and so I ask my team but then the response can be something like "you should know X" or "you should know this because of Y context" and it can be discouraging. I think a lot of the time I notice people conflate experience level with amount of context I have with something.
I'm still struggling with these kinds of challenges and I would readily admit it could be my own weakness but I also wonder if it's a team culture issue; but I've noticed this across my current org and my last one so maybe it's more of a me-problem.
This is definitely a cultural problem. You should get clear and non-judgmental answers to questions like these, because it should be regarded as absolutely normal that you can’t keep everything in your mind, or that you may have missed some context.
In a culturally healthy org, everybody supports each other.
whenever that mvp is not what was expected, if i'm lucky enough, the decomposition allows for easy adjustements to match the need
One approach to deal with ambiguity is to write a short design doc, which writes down what you are trying to do, and all of the assumptions that you are making. If you don't understand the domain, some of your assumptions will probably be wrong. The stakeholder should be able to see that and provide guidance.
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."
In my mind, a senior engineer knows what needs extra attention and where it’s ok to cut corners.
I think saying "no" is easier in a lot of business-related problems, and then when they're the manager, thy can decide. I also accept that as a manager, if I steer the ship incorrectly, I get to fall on that sword
It is true for me to say "9 times out of 10, when I delegated a utility script to an LLM, it did something stupid," but my GPT3-era experience may be less relevant in an Opus 4.5 world. What is relevant is being able to share how it went on to become a problem, and how we might avoid those things if we decide to try that route this time.
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.
In the job interview, give them the list of responsibilities that you have now. Then ask for a higher salary than you have now.
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 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.
It’s a typical pat on the back/confirmation bias article so whoever identifies with this specific opinion can feel good and close the tab with “yeah, I’m a real senior”.
Licensing never happened because its effect is to reduce the size of the labor pool and restrict what the labor pool can do as individuals. Barring the very recent abberation of the glut of new grads and not enough junior positions, even without licensing, there haven't been enough engineers to fill all the open senior-level positions. Licensure would make that problem worse.
A licensure board would also get embroiled in political disputes over what is genuinely ethical. Python is a performance nightmare, should engineers be permitted to pick a language with known poor performance characteristics? Electron is a RAM hog and battery-killer, is it an ethical choice? So how could any Python or Electron shop support licensure?
The only thing that makes you a senior in software is whatever titles the companies you've worked for happen to give out for various political or hiring reasons while you work there and there are basically completely arbitrary criteria from company to company.
In terms of official job titles, I was a "Senior Software Engineer" like 2-3 years after I started writing code professionally, and I mention this not to toot my own horn in any way but to point out how arbitrary titles can be (and we won't even get into the debate over the 'Engineer' bit).
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 what a senior engineer does.
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.
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.
The solution was just to compile the app before deploying, as grandparent did.
Even back then the general consensus was that "not compiling" was a bad idea.
Most serious developers skipped this goofiness and deployed compiled and tested builds.
You mentioned receiving approval after providing a persuasive justification - to me it implies that you were not in the position of making the decision, rather it was up to someone else and under their supervision?
Should Senior then more correlate to the value of curating ideas, mining for conflict, gathering consensus, and execution; while operating tactfully and methodically within certain bounds of composure/temperament?
The core trait of senior is, “gets shit done.”
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".
Some of you senior engineers are less senior than others, and what I've continually seen is this is early senior engineers covering for other people. Eventually they learn that maybe a PM/Design should put some effort into a spec and covering for them means more work without compensation.
The list of example questions at the bottom is clearly not exhaustive.
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.
Often you will get a request, sometimes (or quite often) you have no idea what is driving it, like "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?"
The reason this is important is that, no disrespect to developers, often live in a world where they treat infrastructure as a 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?"
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.
"No."
"But we need the capacity! The website suddenly slowed down!"
"Did the user count suddenly go up 10x?"
"... no."
"You need to fix your indexes/query/n+1 code."
-- this has happened so often to me over the last few years I need some cutesy version of it on a t-shirt or a mug.
Good to hear it
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
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.
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.
Senior deals with "what-if" statements.
<EoF>
> The moment you hand them something fuzzy, though, like ...
> “we should probably think about scaling”,
> that’s when you see the difference.
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.
13 more comments available on Hacker News
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.