The recent rash of interviews have made me think a little more about what makes a good developer and more importantly, which of these qualities can you try to spot during the interview process. After having a conflab with a couple of other devs and one of the few recruiters I know that isn’t a shark, I came up with this list. Of course this is going to be a personal list but some of the points seem to intersect with some other resources out there so I don’t think I’m too far out there:
- Polyglot in outlook
- Able to learn quickly, and happy to learn
- Open to new ideas but capable of defending their own
- Technically able
- An Influencer
- A Producer
- Not too proud to ask for help
- Knowledge across a broad spectrum of topics
Polyglot in outlook
One of the Java devs I work with recently coded up one of the most elegant solutions to a complex problems that I’ve ever seen. When asked how he came up with it, he mentioned that he based it around some of the structures that Make uses internally. Too many developers only live within the walls of their favourite language and never see what else is out there that they could take advantage of. As a Java house, currently I would have to say that anyone with Scala or Clojure on their CV will be seen far more favourably than someone with just Java and someone with half-a-dozen languages is almost always going to be going places. In fact during interviews I will deliberately ask questions on concepts in languages that aren’t on the candidate’s CV since I want them to at least be aware of these concepts even if they have never used them.
Able to learn quickly, and happy to learn
As a self-confessed knowledge junkie, I love learning. In fact I find it hard to comprehend what other developers do not. Given that we are in a knowledge industry, those that do not have a thirst to learn will find themselves going the way of the guys who thought that punchcards and ticker tape would last them a lifetime.
Open to new ideas but capable of defending their own ideas
What is the point of having great ideas if you don’t have the ability to defend them. Developers tend to have robust opinions about how things should be done so you have to be able to defend what you think is right. Otherwise you are condemning yourself to work on projects where you spend your time muttering to yourself “this could be done so much better”.
You have to bring skills to the table. You can be the greatest person in the world but unless you have the technical chops to be able to develop you will just be a drag on the rest of the team. Don’t be the Net Negative Producing Programmer
This is the pro-active side of being able to defend your own ideas. You need to be able to change or at least shape the ideas of others and have the communication skills to do so. Especially at the level of senior developer or above, you have to start spending time educating and influencing others. If you fail to do this, all you are doing is making your job harder. You have to be able to prevent small problems blowing up into big ones and if that means you need to sell your ideas, then that is what you do. If you are a Senior Developer and above, I expect you to influence your workplace. For example, if your current employer does not use a Continuous Integration Server like Hudson/Jenkins or Bamboo, you have failed in your responsibilities if you cannot convince them that they should.
Seeing someone’s work on something like Github gives me one of the best insights into what sort of programmer they are. Ultimately, it’s the Quarterback problem, it’s practically impossible to judge someone’s ability until you see them in action. The closest thing you can get to seeing them in action is to see the results of previous work and this is why we have a technical test as part of our interview process. And before you roll your eyes, we’ve made sure that the test is directly related to what we do and isn’t just some random logic puzzle. If you are already on a team, make sure that you take time to look at your work and check to see if there is anything your should be doing or anything you should not be doing that would improve your productivity. I knew of an Architect at a recent company who was obviously very bright but was unable to produce anything. He literally produced nothing but ghosted around on his domain knowledge and reputation when he actually contributed nothing to the teams in his area.
Not too proud to ask for help
If you get properly stuck on something, no one will think worse of you if you ask for help. You will drive your team mates mad if you disappear off and take days with a problem, especially if one of them immediately gives you the answer that would have saved days. Your colleagues will quickly realise that the people who have to cover for you getting stuck is them. The only time people will think less of you is when you get stuck and don’t even bother to try to figure it out yourself before you start asking for advice.
Knowledge across a broad spectrum of topics
Depth of knowledge demands breadth of knowledge. It is impossible to be an expert in one area without having a degree of expertise in others. The ability to link concepts is hugely important and if you already know something similar, even in an unrelated field, learning something else will be so much easier.
The tired old saw of ‘when the going gets tough, the tough get going’ aside, you have to have a certain cussedness to succeed in programming. Spending hours trying to pin down an elusive race condition or tracking an issue through layers of network infrastructure, web servers, caches, web services and database code means that you can’t be someone that throws in the towel early. Also, there are always going to be times when you are going to have to put in some extra work. Whether it is an approaching deadline or a sudden change in project priorities or roles, no one is going to thank you if you can’t manage your focus. If you are known to meet challenges head on, your team mates will always be there with you and will always have your back. If you have any tendency to slack off, you colleagues will leave you high and dry and I wouldn’t blame them at all.
I should also say that this also applies to situations where management are asking you to do ridiculous things. If the higher-ups have you on a Death March, I don’t want someone that meekly caves in an agrees to late nights and weekends in the office without seeing if it is the right thing to do. Determination is not the same as working insane hours and sometimes people need to remember that.
I was also going to put in something about leadership. This is a hugely important skill but you can be a very good developer without it so I felt I could leave it out without it being to big an issue.
Anyway, that’s my list. What do you think?