Ask HN: What constitutes a "Senior Developer"?

11 points by mgkimsal ↗ HN
There's been a few threads on hiring recently, and I've been a little surprised as to what constitutes "senior developer" status in some peoples' minds.

Do you have any particular criteria you use when applying that label to someone (or yourself)? If someone refers to themselves as a "Senior Developer", what characteristics do you look for right off the bat, whether in a resume or face to face?

11 comments

[ 1.9 ms ] story [ 34.8 ms ] thread
It's a job title. It really doesn't mean anything other than that they are likely making a bit more money than mid-level.

I've worked with junior/mid-level devs that are amazing and senior developers that couldn't string three lines of code together.

When hiring a developer, we call them "Senior Developer" so they'll ask the next company to pay them more money. We'd rather keep the money and pay intangibles. Makes the shareholders happy and at the end of the day, that's all that matters.

Turns out the extra ink on business cards is free.

I am not sure whether I am impressed or appalled with this plan. I am impressed if it keeps your talent from being poached. I also might be appalled if everyone I met from your company was a senior developer and they didn't seem to know much.
To me there are only a couple of factors that create what I consider to be a senior:

First a large app under their belt, one in which they held an architecture type role and designed the system.

Second, full stack knowledge, if they are doing web, that means HTML, CSS, JavaScript, a REST API and back end language, and a database technology.

At this point I would consider them a Senior but specialized.

Once they know a few different options for each part of the stack I would consider them to be a senior. For example knowing Dojo and jQuery for the client, Node.js, ROR, and Java for the REST layer and back end, and several relational and or NoSQL datastores.

In addition to that, they should know how to administer the infrastructure that comes along with those stacks. Such as web servers, virtual etc.

Finally, they would have a SCM pattern down that works for them, they would have a issue tracking, source control and documentation pattern that they can adapt to projects.

To me those are the marks of a Senior Developer, but those are only the ingredients a senior has to be able to parlay that knowledge into leadership and creativity.

How long do you think it would take most people to reasonably achieve those milestones, and also retain competence in all of them? 2 years? 5 years? 10 years?

Personally, I'd done all those within 5 years (with one system I'd built and administered almost from scratch doing north of $500 million in revenue per year). But... I'm not sure I'd have called myself a senior developer at that time. I think others did for job/work purposes, but I didn't self-identify with that term.

I didn't feel comfortable calling myself a sr dev until I'd been able to repeat the earlier successes multiple times over a few more years.

But... maybe that's just me.

I think it is between the 5 to 10 mark. I think a lot of people realize that they have hit the mark long after their talents have put them on it. For some reason, people over assume competency in others in our industry. I think it has something to do with the fact that smart people generally rate themselves as less intelligent that they are perceived when self assessing. When I reflected on my career, I realized that I was a senior for about 3 years before I knew I was a senior. I don't know if that is standard but looking at the guys I have mentored who have come of age it seems to be.
I'm curious where classical computer science topics like algorithms and data structures fit into the equation. I ask because I've seen a heavy focus on "puzzle" interview questions that AFAICT end up self-selecting for people with solid algorithms and data structure experience, since more often than not, an elegant, fast solution requires a classic comp sci education.
If you look at my post history you will find that I am not a proponent of the puzzle to get a job practice. Development in the web space is a collision of right brain and left brain skill-sets, these puzzles favor the left brained model, because well most people are left brained and so they bias puzzles to left brained patterns. Further most of them are worthless at proving any competency at development.

Meanwhile right brained individuals posses a high creative capacity due to completely foreign ways of processing information (AKA thinking out side the box, I know I hate it to). Anyways, a lot of the big leaps is human knowledge have come from right brained individuals, specifically ones who have a particular bridge that spans both hemispheres.

By creating these puzzles you are guaranteeing that you will eliminate a good deal of creative candidates in favor of deeply technical candidates. Right brain dominated individuals will generally look to eliminate the problem along with the solution, people that can look beyond what is being asked and envision a different way of doing it all together. Think of puzzle solving as linear logic and cross it with creativity so they form an X, what you want to hire for (at least in web and mobile) is someone smack in the middle of the X. What code puzzles and trick questions do, is get you someone who sits on the top corner of the linear logic line in the X. All you get is someone with knowledge of how to solve puzzle games and trick questions.

On a personal note, I started researching this stuff because I am left handed and wanted to understand why I see things so differently from other people, and I started to draw the parallels in development. For example, when I see a puzzle, I don't try to attack the problem, I reflect on the nature of the puzzle, I try to understand why completing the puzzle is necessary, and the solutions to puzzles don't come to me through a liner process of working the problem, they come from reflection on the separate components of the problem. Many times, I will wake at night from an abstract dream that possess the solution. The way right brained people reason would be totally foreign to a left brain dominated individual. Also a big disclaimer, I am not involved in neurological sciences, what I understand of it, I gained from reading, I am in no way an expert in the subject matter, so please don't hold me out as one, there could be and most likely inaccuracy's and generalizations in my observations.

As for CS, I don't think it is that important in the web, I think creativity and experience trump it. For the sole reason that anyone can be taught it after the fact. Further having one guy on the team that has a deep understanding of CS problems, provides the coverage most web teams need. A good deal of senior level guys, know to go to the strongest algorithm guy when they need something to be efficient. Most of the time though in the web, we are gluing together prebuilt API's to create new business ideas. That is not meant to disparage web development, it takes a great deal of skill, it is rather meant to highlight that there is a huge gap between the skills people test for and the skills that are truly required. I always hold out Goggles hiring process as an example, I believe that their inability to innovate in the market is directly tied to their hiring practices, it is almost a case study in how to eliminate right brain dominated people from your organization.

Please not my observations only apply to web and mobile, I would not make the same recommendations for say, a medical device developer. It is a different field and has different needs.

It's all relative to your environment. A senior developer in one shop might be one of the more junior guys in the next shop. Salaries also vary depending on the market rates for the stack.

To me, deciding on whether someone's a Senior Developer depends on few things:

1) How much experience do they have in a stack similar to mine?

2) How much of their time would be spent learning versus doing?

3) How much of their time would be spent doing versus teaching?

Juniors learn a lot, Mid levels do a lot, Seniors teach a lot. Everyone's a doer, but the difference between a senior and a mid level is that the senior takes on the additional responsibility of teaching.

The next level is Lead, which is doing, teaching, and being held accountable for others' success.

I don't really see what teaching has to do with it. Not every developer's goal is to teach. The idea that he most capable developers should give up doing to pursue teaching is not very good economics. This assumes that the optimum balance is to have a well normalized force of average developers. In reality, you need extreme outlier doers. It's only because management is not optimizing for value creation that teaching is valued. They want a large growing number of average subordinates, not a fixed amount of commandos.
Well, in Greece a senior developer is a 28+-yo bald feller that f's his m0m and is also an ugly code/idea stealer/plagiarizer from Day 1.

I'm 35 and still not considered a senior developer (although I mentor two junior guys). This is due to the fact that I get things done, something very bad in the corrupt Greek state.

Cheers, http://www.nkavvadias.com/hercules/