Senior != Senior
Let’s say you were laid off, like lots of tech workers this year. You are looking for a new gig as a Senior Software Engineer. But if you’d apply for all roles based on title and benefits alone, you might be surprised to find some bars be set extremely low and some very high.
Neither extreme makes for a lot of growth, assuming you get the job of course. But to figure out which job would suit you, you have to figure out what sets them apart first.
To give a quick sample of what I mean, I grabbed a few Senior Software Engineer postings on LinkedIn, for jobs located in Czechia. I’ll highlight some of the things expected in each of these roles.
The jobs
5 years exp
working with others
strong communication skills
leadership
facilitation
technical writing
working with others
mentor / teach
testing
5 years
team lead practically
working with others
“communicate at all levels” ~ navigate politics, manage stakeholders and clients
can explain technical topics
expert understanding of DDD
5 years with that framework
English
they list growth mindset twice
some OOP experience
English
working with others (pair programming, code reviews, communication skills) listed under nice to have
cloud, REST, CI/CD knowledge also optional
comprehensive knowledge
English
discuss topics even before they become tasks
5 years
working with others
mentor
RFCs (write and review)
communication skills
testing
What’s similar
can work independently
5 years experience usually
What’s different
automated testing
range of skills required
depth of knowledge required
management skills required
communication skills required
Sounds like a junior, doesn’t it?
Maybe to you it does. In two of these ads, Vista and Siemens set the bar quite low in comparison. They might be desperate, they might have the bandwidth to teach or the project simply might not require more.
Let’s go back to the key phrase: can work independently. (and productively is implied)
What that requires depends primarily on the size of the team working on the project and the way the company itself functions.
While in a team of 5 people working on a project, especially given some platform support, many engineers fresh out of university can meet the bar.
What do you consider a senior?
In a larger engineering team, the technical bar is usually set higher (to prevent breaking shit all the time), but more importantly, you need to collaborate to accomplish anything, assuming you don’t want to be chased with pitchforks by your colleagues.
Written and spoken communication skills become critical to get anything done! More code, more services, more features, more product terminology, more domains and soooooo many people.
Two big topics start to become requirements at some point
not delivering useless crap (agile, product management, UX design & research)
delivering fast in a large teams (microservices, CI/CD, DevOps, platform engineering…)
So what is your bar? Well, it’s likely set by the largest team you worked in. Note that it doesn’t really matter if there are 5000 engineers unless they work on the same product.
That’s what often makes agencies / consultancies / dev shops a bit odd to me. EPAM might have thousands of software engineers, but if you are pimped out to work on small projects, working with small engineering teams of the client, your growth will quickly plateau there.
While at Microsoft, there are projects with literally thousands of engineers working on a single product e.g. Windows.
That’s why collaboration skills are critical at Microsoft, while EPAM expects deeper technical knowledge and basically a command of English, no more no less.
How high does the bar go?
There are a few companies here that set the bar high in their own specific way.
Microsoft, due to the scale of the team, expects two things from seniors beyond technical aptitude:
good communication skills
eagerness to mentor / teach
In a large engineering organization, that hires lots of fresh graduates, this makes perfect sense.
McKinsey is going in a very different direction. They are a consulting company after all, so these things are more important:
lead team
deal with client
In client facing environments, self organized teams aren’t that popular, so here they are looking for a backend engineer who can handle the client and tell the team what to do. If this sounds a little “top-down” keep in mind that consultancies rely heavily on junior talent, so nothing to see here.
Now we’re getting to the fun stuff. Make and Pure Storage are product companies with already large engineering teams, but not the behemoths like Microsoft or Uber.
To be productive in their engineering team, they expect their Senior Engineers to:
write and review RFCs, do other technical writing
mentor
leadership and or facilitation skills
One of them expects a bit more mentoring, the other wants more leadership aptitude. Both go far beyond technical skills when searching for their senior talent.
That sounds hard!
If that’s your first thought, I’d really encourage you to give such opportunities more thought. Not that I blame you. I also find myself exhausted sometimes reading a pile of responsibilities I just don't feel like having. Anyway, I thinks there plenty of benefit to working in such teams once you gather the energy, namely:
good collaboration → more gets done → more fun
bigger teams → more impressive projects
bigger teams → higher / more complex skill requirements → smaller talent pool → much higher salaries!
bigger challenge, less shortcuts
more senior engineering roles available
If the first points leave you feeling “meh”, really think about that last one. I’ve written about career paths for engineers that minimize management recently. The problem is, most of those roles only exist in organizations with large enough teams and large enough projects.
TL:DR
Senior ≠ Senior. Pay close attention what you are applying for and whether it’s the right step for your growth.