Not too long ago, the topic of “what makes a software engineer senior” came up during a 1-1 with my colleague.
His opinion was that it was years of experience.
I mentioned I saw it as more of when an engineer has reached a certain level of proficiency in a set of skills.
We were already finishing up the 1-1 then so I didn’t have much time to elaborate but after thinking about it a bit more, I realised I had some expectations over what a senior engineer could do for the team and I instinctively knew what I was looking for when interviewing people, but I’ve never really been clear in thought about what it was. I need to put it down in words to be.
So here goes.
What constitutes seniority and how to identify effective seniority is something I’ve always had at the back of my mind.
Initially this was because I wanted to level up myself as an engineer. Recently though, it’s because I’m going to have to hire a senior engineer soon to expand my team
So now seems like a good time to write, ponder, and gain clarity on the topic for myself as a nice side effect.
How a senior engineer contributes to the team
IMO the question here is why should an organisation pay 2-3x as much for a senior engineer as compared to a junior engineer?
You could get 3 junior engineers who are more hungry, could probably churn out more code, and can commit to longer working hours than a senior engineer with the budget for a senior engineer.
For context, I’m currently in a startup that’s pre-series-A (pretty close now!), I’ve been in seed product teams for most of my career and calling quits once the team has reached Day 2 operations. Your experience/your teams’ mileage may vary.
To me, having a senior engineer on my team means:
Someone who can be responsibly delegated objectives involving making decisions at the system architecture and organisational level
Someone with the ability to lead, influence, and convince fellow technical beings
Someone that can help everyone else on the team level up (including the lead if they’re not the lead!)
Someone who is still comfortable in the trenches making contributions to the codebase
For clarity, I see lead and senior as two different concepts.
A senior engineer can be a lead, but a lead doesn’t necessarily have to be a senior. To keep the scope simple and clear, I’ll be referring to senior engineers as engineers developing themselves in the “technical track” and the lead engineer as the engineers who chose the “management track”. They’re different roles with different responsibilities (although in reality the two often get conflated).
Also, if you’re applying for the upcoming open position on my team and happen to chance upon this, there you have it, above lies your criteria to pass I guess 🙈
What are the signs of a “good” senior engineer
This brings us to the next question of how to identify a good senior engineer over a not-so-good one.
I’m (only) a decade into my career as a craftsman of software so don’t take this as the bible or anything, but here’s what I’ve observed and what I believe to be true at this point of my growth.
Years of experience
At this point in time after having seen some people with many many years of experience fail miserably and get fired, I believe years of experience is only a number that indicates a person’s potential, not how good they will be on the job.
Many years in the industry means that person has probably “gone through a lot”. Unfortunately, “going through a lot” doesn’t necessarily mean the person has learnt or grown a lot. Cruisers will cruise.
I guess it’s in a similar line of logic as to how some people become wise with age and some are still held captive by their “glory days”. A candidate with more years of experience is not indicative of a better senior engineer.
But that being said, I believe there’s a minimum threshold.
And that magic minimum threshold seems to be ~7 years of being in the trenches based on people I’ve interviewed. Any less and they’d have to have a career trajectory involving gigs that operate 7 days a week across different timezones.
To some extent, you can’t have quality experiences without a certain level of quantity. 7 years seems to be about the time when people have generally seen and solved enough shit, and have had time to not just learn/grow but to apply those learnings and achieved success where they/their seniors failed before.
It could also be an age/maturity thing since 7 years on the job in software engineering generally means the person is at or nearing their thirties and has a better sense of how they operate and how they contribute in a team.
Of course, this isn’t a strict rule and other things matter like how long a person has stayed in each organisation, why they left, what they enjoyed/disliked about it, and whether they were in the role because they wanted to be there or the money was simply too good. None of them affect the outcome in a causal manner, but I’ve found results can vary based on these.
Organisational context
I believe that it’s more effective for organisations to promote from within. And this belief stems from an underlying belief that effective seniority requires organisational context.
Since seniors should be able to make architecture and organisational level decisions, it’s likely that they’ll need to work across squads/teams. Knowing who to talk to and how to talk to them reduces the friction most people experience when trying to influence/convince someone else to agree to do something of someone else’s conception.
An organisation that can afford to hire a senior engineer generally has some level of legacy code. To make decisions about what to migrate/upgrade, a senior engineer will need to have context of how the system has evolved before they joined. A mid-level engineer who has been around much longer than a new senior engineer will be much more effective (why not promote them to senior?).
That being said, sometimes it can be effective to hire externally. Someone unaware about the organisation’s shared self-limiting beliefs has the ability to come up with an Occam’s Razor-esque solution.
So what are the signs that a candidate can adapt to your organisation’s context?
In terms of hiring, I think business domain is a pretty good proxy for organisational context. Technology stacks in a fintech company generally grow the same way; same with E-commerce products; same with dating apps; and the list goes on.
In general, I’ve found that it’s up to me (or you, if you’re interviewing senior engineers) to be able to draw analogies from a candidate’s experiences and the hiring organisation’s context.
The work is not all on the candidate y’know.
Technical skillset
The next thing I believe to be significant is a match in technical skillset.
In a similar way to how more years of experience enables a person to go through more shit, how long/deeply a person has worked with a certain stack is indicative of how well they would be able to make decisions for a stack that resembles what they’re familiar with.
A part of being able to responsibly make high-level technical decisions is knowing all the ways a thing could fuck up and implementing guardrails to either avoid or mitigate the inevitable fuck-ups.
A part of being able to influence/convince other technical humans is knowing about both the pros and cons of what you’re trying to convince others about. Technical humans are generally cynical yet logical beings and if you can’t justify a concept you want to push for, the conversation was over before it began.
Unfortunately though in 2024, an exact tech stack match is a pipe dream.
Within frontend development, you already get Angular/React/Vue/Svelte.
Backends range from legacy RoR/Django stacks from the bootcamp-graduates-flooding-market days, to Node.js, to the microframeworks of PHP and Go, and even to enterprisey/proprietary/legacy stacks involving things like .Net, JSP, and CGI.
Even platform engineering (my professional domain!) is not spared with the range of cloud infrastructure providers, Infrasturcture-as-Code (IaC) tools, CI/CD pipeline technologies, and hypervisor platforms. Don’t forget we also need a basic understanding in all the frontend/backend runtimes to be able to orchestrate automations effectively.
If a tech stack match is difficult to find, how could we assess for it?
Here’s where it gets tricky. For the interviewer.
My opinion is that it’s your duty as the interviewer to know a little about A LOT of stacks.
It doesn’t have to be an in-depth understanding and you don’t need to know implementation details. But you do need to know unique key concepts of each technology and how different technologies work synergistically to bring value to the stack.
For example you don’t need to know how to implement a Kafka queue, but you should know that Kafka follows a publisher-subscriber model with topics and consumer groups unlike AWS SQS which without AWS SNS is more suited for a simple FIFO queue. You don’t need to know MongoDB, but you should know that it’s a document database and that the data is structured differently from a relational database like MySQL or a key-value store database like Redis. You should also know that a room booking system requires a RDBMS and not a document database for example.
You didn’t think you’d just sit there and ask questions did you?
Being a generalist here helps a lot because you can draw analogies from a candidate’s tech stack to how those skills might be applied in your organisation. For example, if they have had extensive experience in using MongoDB, it’d be a travesty to hire them if your organisation uses exclusively MySQL. However, if they’re skilled in Postgres, that’s not too different from MySQL and they’d likely be able to contribute effecitvely.
Non-technical skillset
Lastly, I believe a senior engineer cannot escape the “people skills” requirement.
Collaborating with different teams and helping teams to level up necessarily involves proficiency in communication.
So what’s the deal with senior engineers being on the technical track and lead engineers being on the management track?
IMO lead engineers are responsible for dealing with management, senior engineers are responsible for dealing with other technical humans. If you’re technical, you’ll understand, but if you’re not: these communication patterns are not the same.
Most technical people can be swayed by logic. The same can’t be said for management people, not because they’re not logical, but because they’re under pressure to deliver value. Feature delivery and value delivery are two different things.
While lead engineers should be able to convince management that a feature cannot be delivered in less than X days and propose alternatives to achieve the same value, senior engineers should be able to effectively sell something like PHP (a relatively ancient technology that’s looked down on by modern developers) to someone who only knows Node.js (modern developers) and get them to acknowledge that in some circumstances, PHP should be their tool of choice.
Assessing this is more useful when left as an exercise to the reader.
In general, I’ve found that a technical debate over a hypothetical business with hypothetical technical constraints works well to bring this out in candidates. In excellent candidates, I’ve noticed that a fiery passion emerges to solve the problem within the given constraints.
And that’s what I personally look out for for this criteria. It’s difficult to fake passion. It’s also difficult to hide passion.
Cheers
I noticed I started this blog in January because I wanted to practice writing more. And obviously I haven’t delivered 😅 I promise I have like tonnes of stuff in draft but the perfectionist in me won’t let me publish them. I’ll look into getting them onto the blog soon.
Lastly, I hope this was useful to someone, give me a shout if it was!