What is a "Senior Developer"?
When a company hires All Around the World to develop new systems or work on existing ones, they're sometimes surprised to find out that, with few exceptions, we only hire senior engineers. We're not a "body shop." We're the experts you hire when you need things to work and you've discovered that the $100 a day freelancer wasn't such a bargain after all (true story).
So when a self-described intermediate developer asked me what I meant by "Senior Developer", and does it just meant "time on duty", I realized that what we're looking for is different from what other companies look for. We have high standards and a difficult hiring process, but it's worth it.
What follows is my (edited) response to that developer.
"Senior" absolutely doesn't mean "time on duty." I've met quite a few devs who've been in the business for a long time but are no better than junior devs.
Different companies have different needs for senior devs and would thus define them differently. So take what I say with a grain of salt.
For me, a senior dev can look at a problem and come up with a solution that addresses three areas: business, human, and technical needs. All of these are worth examples to help explain what I mean.
I was with a company facing a legal deadline to come into compliance with new laws impacting our industry. There was some software we needed to purchase to help with that and almost every single developer voted for some fabulous software that did everything we would want and more. Management chose some software that no dev voted for. However, management was right because this software was the only software that would help us meet our legal compliance issue by a legally mandated deadline.
A senior developer can balance business and technical requirements.
My next criteria would be a developer who can understand human needs. There are many "superstar" developers who turn in fantastically complex code that does absolutely everything you could possibly want, but is very complex to understand and use. For one company, a sole developer worked for six months to produce an improved statistical model for financial projections. Calculations showed that it did indeed provide better projections. The project was abandoned because the company couldn't find a single developer who could understand the code aside from the one who developed it.
Or to oversimplify it: junior developers write simple code. Intermediate developers write complex code. Senior developers write simple code.
A senior developer remembers that other people have to maintain and use their code.
Understanding technical needs is the most obvious requirement, but still one that is sadly missing. I can't tell you how many times developers with years of experience still churn out spaghetti code which isn't fit for purpose. The code runs well with a few data entries, but fails to scale when presented with massive data. There is often little data validation and few (if any) tests. As is sometimes said "A good developer looks both ways before crossing a one-way street."
Or one story I sometimes tell: while interviewing a very experienced developer, I happened to mention that our application was fairly write-heavy at the database level. He immediately said we'd have to go NoSQL or shard our database. He had no idea what our application did or how our data was used, so his comment was enough to disqualify him because his skills were useless if he couldn't understand the importance of understanding a problem before offering a solution.
A senior developer can grasp a problem, understand the goals its trying to satisfy, and appropriately evaluate technical solutions to said problem.
You'll note that business, people, and technical requirements all have a lot of overlap. Different companies rank those requirements differently. Some companies find that prioritizing business requirements leads to great initial growth, but at the cost of maintainability. But building perfect software doesn't matter if you are always spending more than you're earning.
To me, a senior developer understands the relative importance of those three steps and how they fit the task at hand. It's not "do they know how to code a red-black tree from memory?" Nor is it "do they know this strange bit of trivia about their favorite programming language."
There's much, much more I could say, but I think the above covers the basics. I hope it helps!
Drop me a line at ovid at allaroundtheworld dot fr if you'd like to discuss how I can help you.