What makes a senior developer?

I guess that we as developers, we cannot complain about a shortage of job offers. There are a lot of opportunities in sites such as LinkedIn or StackOverflow Careers. But what happens most of the time is that a job offer will ask for someone considered a senior developer and who knows multiple technologies, platforms and so on.

Lately, I was faced with the task of interviewing someone for our team of developers. A task I did many times, but this time I got myself thinking how to measure the level of a developer, especially how to measure if someone is a senior developer and most important, how I'd like to be measured. Is it years working as a developer? Is it how many languages one is capable of working with? Is it how deep do one know a framework? Does the qualification junior, intermediate and senior really matters?

I'm not sure if I have all those answers. Let's take for instance the knowledge of a framework. Does it really matter how deep do you know a web framework like ASP.NET MVC if you're someone who knows a lot of Ruby on Rails. Isn't it more important that you really understand how the life cycle of a web MVC framework works? How does the pattern work? What the MVC really stands for? Can't you replicate these kinds of knowledge and experience to other frameworks?

Honestly, I think so, I think that, despite the differences between those two technologies, for instance, the experience with one can be replicated when using the other. But, (and this is an important but) I cannot argue with the fact that someone with experience in a given technology would be producing faster than someone without the same experience.

Some of those questions are not so easy to answer and for some companies, instant results are more important than waiting for someone to catch up with a technology in one or maybe two months and just then be fully productive.

So thinking about that, I decided to elaborate a few questions I'd like to ask a candidate. Some of those questions don't have a straight answer, rather, if those questions are interesting to you, you have to align the answers with what your team thinks is right.

What makes a good code?

What I want to know is, what the candidate thinks is a good code? Is it having separation of concerns? Is it having code generation? Is it having the simplest possible code? Is it having comments? Let the candidate speak freely, a more experienced developer will most certainly know what she thinks is a good code.

Given this code, what would you do to make it better?

Prepare a sample code that your team does not consider a good code and let the candidate point out what she would do differently to make the code better. That's always a good way to assess the experience of an interviewee, inexperienced developers tend to pinpoint the more simple and evident errors. If you're using an object-oriented language is also a good way to test the knowledge of good design patterns.

Can the candidate recognize code smells?

That's a consequence of the previews questions, does the candidate "smells" bad code? Like bad naming, code repetition, bad patterns, etc.

Can the candidate name things?

Naming classes, functions, methods, variables is a hard thing to do and is also one of the most important ones.

Does the candidate have experience with automated testing?

Testing is important, I don't care if you write them first or after. If you want to be a professional developer you have to write tests. That's another good moment to show some code and ask for feedback of the candidate. Show her some badly written tests, ask if the candidate can tell you why is it bad? Does she think it's bad? Tests should be considered as important as production code and bad tests are generally a consequence of bad production code.

What do you do to keep yourself up to date with new technologies?

Do you read? What do read? Do you listen to podcasts? Watch videos on youtube? Which channels? Some other site of on-line learning? Do you have a personal GitHub account? Do you write code at home? Really, I want to know that the professional I'm hiring is not only learning during the time she should be producing. It's OK to learn at work, it's not OK to ONLY learn at work.

Given the technologies x, y, z we use in our team, would that be something that interests the candidate?

This is for the case where the candidate does not have any experience with some important stack of technologies the team uses. This might not be a problem for your team, but is it something that interests the person being interviewed? I don't want someone complaining all the time because she has to write JavaScript code when all she wants to do is to write C#.

Can the candidate express herself?

Communication is key, be that in person or remotely, the candidate has to be able to express her ideas.

Conclusion

Well, this is by any means an extensive list, but I do think that this a great starting point for some conversation, and I'm sure that while asking these questions you will find out some other you'd like to ask.

With the answers of these questions, you and your team have to decide which answers were not satisfied, but you're willing to compromise? Or, are you willing to compromise to any of those?

I, I'm pretty sure that if I am satisfied with the answers for those questions, there's a great chance that this is someone I want to work with.

What about you? Do you have some questions you like to ask when interviewing? Maybe you'd like to share some of yours with me? ;)