How does the community at large view the distinction between seniority for software developers, especially in java and .net technologies?
I posit that seniority is not a function of time. When it comes to working with or interviewing someone who is an outlier
on the curve, its quite simple to draw a conclusion, but how about for the rest?
What are some of the effective qualifiers and quantifiers used to make this distinction?
Answers (2)
Seniority is something that I personally think is viewed as a function of time by most people involved in the hiring process however from a personal perspective I see it as a diversity issue. I think we all could agree that we see people who have 10-20-30 years exp who are still doing the same job they were when they started. For a truly senior, esp with one of the newer languages it requires not only a level of experience of hammering out code for a particular platform but rather it requires many levels of involvement with different platforms and even going outside of ones own box for some time and working in other aspects that are affected by the code that we write - for instance, a dev is much more valuable to a team who is deploying an email software package if that person has worked on the network administration side of email before in order to understand the users perspective and the admin perspective before they can truly understand the business principles and requirements of the software. For most things I don't think that this warrants discriminating .net and java technologies but a good old fashioned Renaissance person is a good attribute for anyone senior doing anything. Quantification/Qualification is pretty much impossible to do a litmus test for but to get the ball rolling on this I would say: Involvement in more than one aspect of IT than simply being a dev; Some level of management experience, preferrably in dev; If a person has less than 5 years of experience or so then they should probably have at least a BS.
Chuck K.
Co-Founder and Software Architect at Milyli
Best Answers in: Software Development (4), Web Development (3), Computers and Software (2), Planning (1), Enterprise Software (1), Information Security (1)
Domain experience is important. Depending on the job though, the domain may never get very old before changing. This lessens the affects of time based seniority. If you are not up on the company's latest processes, years of experience doesn't necessarily translate to seniority.
Seniority on most teams I have worked on was comprised of several factors: domain knowledge, technical knowledge, organization abilities, communication abilities, reliability, accountability and raw talent to name a few. Your senior level people will tend to be individuals that have a good level of all of these characteristics.
I guess you could say that I tend to have worked in meritocratic environments. Those best suited to lead were recognized by the other developers and rose to the top. Most developers seem to figure out where they and others fall pretty fast.
If your asking how to judge people based on an interview and what to make their official title. That's a harder question. We got it wrong as often as right and you just need to be prepared to document performance against the roles and responsibilities of your team/company and adjust official titles and pay accordingly. Sometimes it may even be necessary to cut your losses (and an employee) and rehire.
