What makes a developer “senior”?

In many industries, a senior level position is based mostly on the length of time that person has been working and maybe a standardized test or two. But what exactly defines a “senior developer?” This is something that I have been wrestling with for the last few weeks. The more I go through the hiring process (I am helping to hire people — I am not looking for a job), the more I have to ask myself this question. I know some of the general characteristics, but the details are driving me a bit nuts. And, it makes a difference because job title drives not just salary but also one’s future career opportunities. Someone may be doing “senior developer work,” but if they want to be a software architect, it may hurt them not to have the title. On the flip side, if I am told that we are looking for a “senior developer,” and the person who I think is right for the job is not one, I have not made the right decision.

Here are some of the basic qualifications that a “senior developer” should have: 10 years of experience in the programming field (although seven or eight may be enough depending on what they have been working on), a rock solid understanding of theory, and excellent debugging skills. They also should be able to: work closely with the software architect to suggest improvements within the overall vision for the project; ask questions at the architecture level and not at a low implementation level; and serve as a resource and mentor for less experienced developers. You should also be able to trust him or her to transform a set of class diagrams into quality code with little oversight. A “senior developer” should not require handholding.

But is it better to have, for example, a “senior developer” with four years of VB.Net-only experience and eight years of VB-only experience before that? I would imagine that 12 years of working with VB certainly has made that person a VB/VB.Net expert. On the other hand, someone who spent those same 12 years bouncing around Java, C++, Perl, VB.Net, and C# has had a much wider range of experiences to draw upon. Personally, I am attracted to the latter simply because it more closely resembles my own experience, but I think the former route holds many advantages as well.

Also, does someone who spent equal time on traditional client/server apps and Web-based apps have the same weight as someone who spent the same time working exclusively with Web-based apps? The client/server person has exposure to solutions to many of the problems that dog Web apps, but the Web-only person may have a unique insight into the bizarre oddities of Web development (the HTTP protocol, for starters). Again, there is a tradeoff between a specialist and a generalist, both with equal lengths of time in the industry.

I would love to be able to ignore the self taught vs. formally educated aspect, and I usually do. I have been able to simply verify that candidates have an appropriate amount of theory (I have found that this is the stuff that is easier to learn in school than on one’s own), which weeds out both the self-taught folks who learned too many bad habits and the people who slept through their degree.

The last major hurdle are people who have spent enough time in the work force to be considered senior but who have never worked on anything more complicated than a simple CRUD app. This is a tough call for me. For all I know, they have been so deep in that simple CRUD app that they know their stuff inside and out, even though their project does not really express it. On the other hand, there are people with experience that is indirectly related to programming and yet very helpful. For example, I have found that my time spent as a systems administrator and doing networking has been vital to debugging many applications, particularly on the deployment end of things. How does nondevelopment experience fit into the “senior developer” position?

Leaving all of these other considerations aside, there is the matter of personality. Am I willing to put up with someone who has less than an agreeable personality but has amazing tech skills? Or do the leadership responsibilities of a “senior developer” allow for someone who is a “good fit” as a person to offset a technical shortcoming?

I do have my own idea of what makes up a “senior developer.” For the sake of maintaining the integrity of the hiring process, I will not put it out in public at this time in case someone does a bit of homework and tries to game the system. But I would love to hear what your thoughts are about what makes a “senior developer.”

J.Ja

P.S.: I may not be able to reply as much as I usually do because I am currently on a high alert with the baby watch. I told her that she was in trouble — I know that if I was two or more days late on a nine-month project and did not tell the PM so they could update the Gantt charts, I would be in trouble! Just kidding, of course. But I will be looking forward to reading your feedback!