Hiring Software Developers (Part 1 of 2): What Makes a Developer "Senior"?

Hiring Software Developers (Part 1 of 2): What Makes a Developer "Senior"?

Following up on our post on how to successfully onboard a new developer, we're going to look at developing a strategy in building a software team, regardless of what the talent market's giving you.

In this first part we're going to define seniority in software development, and also how junior and mid-level developers compare.

In part two, we're going to discuss hiring holistically, and show how you can succeed by "taking what the house gives you", and structuring your team to adapt to the tightening market for senior talent.


What gives someone the right to call themselves a senior developer? What about a mid-level or junior developer? The criteria that should be met to move up the ranks is not just based on years of experience, and technical ability, but in a senior developer's demonstrated ability to shift their focus to a larger scope of the team's effort, and to lead and help others improve, which multiplies the effectiveness of the team.

Rank and File (Systems)

When I was in the Navy, rank structure was pretty straightforward. If you were a Chief Petty Officer or "Chief", everyone knew exactly what they could expect from you as far as leadership, level of knowledge, and performance. That's because in order to achieve that rank, those who have the authority to make you a Chief have strict guidelines to follow. Every Chief Petty Officer has to go through an initiation, and pass a string of interviews, as well as to demonstrate well-developed leadership abilities.

In software, it's very different. I left the Navy and started as a junior developer a decade ago. Even though I had a master's degree in Computer Science, and understood, very well, the fundamentals of Software Engineering, I didn't really know how to code at all, much less in an actual production environment. I'd taken software engineering classes, understood algorithms and data structures, but to be perfectly honest, not once in the five years that I had been in college had I heard the terms "refactor", "code smells", "technical debt", "maintainability", or "design patterns". These are terms, as a professional developer, I've heard almost daily.

Why is This Important?

In a professional sense, job titles are important, because they can help members of a team figure out where they rank amongst their peers, and help them gauge the person's potential contribution to the team. With these types of labels the team can make some assumptions about what a team member knows, as long as everyone can generally agree on the criteria. Practically, from a junior dev's standpoint, it becomes easier to know who to turn to if you need help.

This removes the need for everyone to staple their resume to their clothes, because the title is usually communicated, either during an introduction, or at some time after, and becomes well known once everyone starts working together. Though I have worked at companies where everyone held the title, "Member of Technical Staff", most software teams give you a title. When you are hired, they usually have an open job to fill that has a title and role already attached to it, which makes it easy to know what to call yourself. In other cases, like if a company is in "general hiring" mode, more or less, they will let you choose your own title. Titles are part of how the software community works, and for better or for worse, they are here to stay.

How Will I Know If Someone is Senior?

Let's start at the top, because senior developer is the title that is most often debated. The answer is that though it depends on the type of software you work on, it usually comes down to technical mastery of your stack, and what your focus, day-to-day becomes. As a developer starts to learn their craft, being able to share this knowledge with others needs to improve with it. That said, here are some criteria you can use to judge whether someone that's interviewing with you is really senior or not:

1. The Technology

The types of technology vary in the software business so the amount of work that goes into becoming a senior will vary as well. An embedded software engineer will focus on the lower-level languages like Assembler, and C as well as understand different hardware architectures, network protocols, and security mechanisms on a very low level. Mastery of more complex technologies may take longer than those for other types of development where the lower-level details are abstracted for you. For example, web developers may have mastered their technology in a few years while it may take much more time for a firmware or hardware protocol engineer.

2. Understanding Why it Works

One of the more important qualifications is knowing why the technologies you use work the way they do, and being able to explain it to others. I've heard many times that senior devs are paid for their opinions. This means knowing the right answer and being able to back it up. It also means recognizing tech debt, being able to refactor code, and knowing enough to justify choosing one design pattern, or even something as small as one line of code, over another.

This discernment comes from a deep understanding of how things work together, and being able to dive into the details, yet also maintaining the 10,000 foot view. Balancing all of this, with keeping a mind toward how the architecture should evolve with the businesses needs, is what makes a senior developer ready to lead on a technical level.

3. Being Able to Teach Complex Concepts to Other Developers

In the Nuclear Navy we had a saying that you didn't really know something until you could teach it to others. That's why I hesitate to call any developer senior unless they have had experience mentoring others on a team. When we learn, it's by nature a gradual process, so we will approximate a lot of our knowledge, initially, but as time goes on any gaps are filled in as we learn more. When we begin to verbalize a concept, and try to explain it to someone else, we can solidify our knowledge as we walk through an explanation. For more, here is a study that shows that teaching a concept to someone else is highly correlated with improved knowledge of the concept.

4. The Quality of Experience and Mentorship You Received

Who you interact with, professionally makes a big difference in your level of expertise. I would trust someone as a senior developer that has worked at AirBnB, or Facebook back in the day, for example, before I would trust someone that was mentored by the senior developers at a lesser known company with less critical, interesting challenges. The more interesting types of work being done will attract better talent, naturally, which means as long as knowledge transfer is happening, junior developers at those companies will be much better off than others.

5. Choosing the Right Tool for the Job

If you were building a high-end cabinet, would you want to use a jigsaw, circular saw, or chainsaw? Would you want to use one of each at different stages in a project? Similarly, when you're building software, the kind of database, language, or framework you would use to solve a particular problem requires knowledge a senior developer has picked up over their career. That means knowing the relative strengths and weaknesses of different technologies to make the best choice for the application. This can save a business a lot of money in development or operational costs, and can help determine whether a competitor gets their product to market before you.

6. Superior Interviewing Ability

This means not only understanding how to be an interviewee, but also knowing how to interview others. As an interviewer, you have to determine with very little time, whether someone standing before you is qualified or close enough to being qualified to work on your team. If they are close, someone with enough experience in hiring will know with a high degree of granularity, what areas need strengthening, and whether the team has the resources to help that person get there.

7. Saving the Day by Troubleshooting Production Systems

You must understand and be able to troubleshoot bugs that appear in a real-live production environment, whatever that means in your particular technology stack. So, if everyone else on your team is on vacation, you can jump in and save the business from collapse. This obviously can depend on the size of the business and the application, but it is more a mindset and accumulation of technical ability than anything else.

8. Software Testing Practices and Refactoring

I recognize that not all software disciplines use automated tests the same way a web or mobile developer do, for example systems, graphics, or embedded programmers. However, for technology stacks that have testing frameworks and for which there is a reasonable expectation to use them, a senior developer believes in tests, and knows how they can save your application from endless regressions, continual bug fixing, and the resulting low team morale. When a bug comes up, the senior dev knows the value of writing a test just for that bug, to make sure it doesn't come back again after the bug fix. Also, senior developers will know when not to test something, as in, they understand that achieving 100% test coverage can be a time-sink and can actually limit flexibility and velocity in turning out new features.

9. Clearly Developed Soft Skills

The ability to work well with others cannot be overstated because most people would reasonably view a senior developer as a technical leader on a team. The ability to speak candidly but respectfully, to mentor effectively, to train without belittling, and to demonstrate general communication ability, is what I expect from any professional I would want to work with, especially in software where work is constantly being reviewed by others. Having someone that can't demonstrate diplomacy or respect others' feelings really kills morale on a team, even faster than poor code quality and technical debt do. There are so many instances of when this communication is needed: discussing someone's code quality with them, collaborating with others to brainstorm an approach to solving a problem, participating in sprint/team retrospectives, discussing code debt, in an emergent situation, etc., that morale can really go south quickly if someone that knows a lot, can't play nice with others.

10. A Solid Understanding of Computer Science Fundamentals

First, this does not mean you need a CS degree. Some of the best software developers I've met have never stepped foot in a CS classroom. This means you will need to know things like algorithms, how to determine whether a particular piece of code is performant or not, and when to apply a different algorithmic solution if the one you're working with doesn't fix the problem. This will probably require some amount of understanding of mathematical concepts that drive the fundamentals of computer science, but this isn't anything you can't pick up with a desire to learn and an internet connection.

What About Everyone Else?

Now that we've talked about what a senior developer is, we can briefly touch on both Junior and Mid-level developers and when to know when you've clicked into the senior developer category. As mentioned before, the progression from one level to the other depends mostly on one's ability to shift focus from a narrower focus, to a widened scope of the larger effort. With that new focus, also comes a responsibility to help others out and share knowledge.

Junior/Entry-Level Developers

First, I see little difference between Entry-level and Junior developers. Entry-level is usually the first few months of a junior developer's employment at their first job, but once you get there, a junior developer can pretty much work on their own. This means working independently on less complex features like, in the case of a Web Developer, style a page to the standard of a design, create forms, and demonstrate some ability to write tests after they've been shown how by someone more senior.

Mid-level Developers

We've talked about what separates mid-level developers from senior developers, in the list above, but when can a junior developer drop the "junior" part of the title and just become a "developer"? It's when:

  1. You begin to consistently, effectively mentor other junior developers.
  2. You're probably working on your second or third professional application.
  3. You've learned lessons from those previous projects that you pass along to others, and use that knowledge to drive decisions in new code that you write.
  4. You start to at least participate in architectural discussions.
  5. You understand the performance implications of the code you write and can start to apply different design patterns.
  6. You can look at the code you've written and come up with ways to refactor it.
  7. You start to participate in code reviews of junior developers and lend helpful, constructive comments to improve other people's code.

Again, the scope of what a developer is responsible for no longer ends with what you're working on, individually, but  includes the work of others, too. This is similar to the spirit of the criteria that we use to judge senior developers because as you move up the ranks, you're not just accounting for the performance of your own code, but for the code of others on the team.

What About Years of Experience?

You may have a question after reading these lists which is, "why not base it on years of experience?" We are, sort of. Years of experience are important but the quality of those years is much more important. I could have worked at one company, worked on one codebase, with very little new feature development for a decade, and I would not be in the same league as a freelancer that's worked on thirty projects in that same time. Experience, as we talked about previously, also depends on who you work with, and how well they were able to transfer their knowledge to you. In nature, the "strongest" of almost anything imaginable depends on the conditions in which it was grown or raised. The software profession, much like an apprenticeship, is no different.

A Rising Tide Lifts all Ships

So what does all of this mean? It means that titles or levels in software development certainly are based on technical ability, and this can be learned over time with experience, but this technical ability isn't worth much if you haven't shown the ability to share it with others. If you take nothing else away from this post, please take this:

A developer is only as good as they are able to lift up other members of the team, showing ability to mentor and guide less-experienced developers.

Otherwise, you're dealing with a lone-wolf who may be great at working on their own and cranking out features, but trust me, that's not who you want to hire when you're trying to build a collaborative software team.

Thank you for reading! If you're interested in learning more about what we offer from a mentoring or software development standpoint, please don't hesitate to reach out and tell us about your needs. Click here to contact us!