Having worked many years as a software developer myself and having interviewed many other people for software developer positions, I often find that there’s a dearth of understanding outside of the field about what it is that a software developer really is.
Before you even start hiring, be sure you’re getting what you want. There are generally recognised differences (even if not formalised anywhere) between software developers, programmers, software engineers, and computer scientists. If you want one, but advertise for another, don’t be surprised when the majority of the candidates applying for the job don’t fit at all.
Programmers write code. They specialise in this. They’re very very good at it. But don’t ask for creativity. Don’t ask them to turn vague specs in to a working product. They will take a specification and give you exactly what that spec says. If the spec wasn’t right, you won’t get what you wanted. As a great man once joked: A programmer is a device for turning caffeine in to lines of code.
Computer Scientists are all about the algorithms. These are mathematic and logic experts that devise an algorithm for anything. Their code may often be slower than that of a programmer though, with user interfaces that are from some kind of 1980s console nightmare – they care about the beauty of the mathematics in the code and doing things that seem like magic to those that don’t understand it, not ‘unimportant’ (to them) things like user experience. It is said that computer science is as much about computers as astronomy is about telescopes.
Software Engineers are usually specialists in one or more particular fields. They will help you generate working code. Perhaps again not quite to the level of a programmer, and perhaps not with as much ‘depth and magic’ as a computer scientist, but with an overall well rounded level. The focus is on the big picture and the architecture of the system being created. Software engineers are engineers just like bridge-builders are. If you build a bridge wrong, it will collapse and software engineers view their code with the same level of concern. It’s all about the correctness of the implementation and making sure it’s robust and long lasting.
And lastly are the Software Developers. Software developers are the most generalist and have “a bit of everything” from the above. They may not be superstar programmers, so they’ll code a little slower. They may not be mathematical geniuses, so will struggle a little more than the computer scientists at complex algorithms. And they may not always be as thorough as the software engineers. But they will (or perhaps ‘should’) be able to do all of these things are more. Most experienced software developers also have significant skills in project management, specification translation, design principles, and more. If you have a mix of the above types, a senior software developer is absolutely the right person to lead and direct the team.
Once you’ve decided what kind of employee you want, and written the appropriate job advertisement, there are still further things to consider.
One of the biggest problems is that development itself is such a wide field. If you’re looking for someone to integrate a custom application’s data output in to your SAP system, someone that’s spent their career writing image processing algorithms isn’t going to help you much more than asking your cleaner to do it – and vice-versa.
There are of course cross-overs in skill-sets. A web developer who has focused her career on a mix of user interface and server/client connections can probably pick up mobile application development reasonably quickly, and someone who has been doing print drivers for a long time will transition quite easily to data format conversion work. But if you’re in charge of hiring a software developer and you’re not from the field yourself, how do you know what skills can transfer, what skills can’t, and even what it is that you really need?
The most important thing here is communication.
First and foremost internal communication, get your existing developers involved in the hiring process. Have them look over candidate CVs with you, get to know their own backgrounds and skills beyond the day to day work that they do, and then look for people similar to them. Ask them what skills and knowledge they use in their daily work – it may surprise you, as often it will be things that you never even asked for when you hired them to begin with.
But don’t forget communication with the candidate as well. In the interview, don’t focus as much on their background – they’ve told you that in the CV, which you’ve already read. Instead tell them what it is that you need them to do. Ask them if they think they can do it. If you’re in charge of hiring, you already know how to spot the difference between someone saying “yes” because they just really want the job vs someone saying “yes” because they really mean it. Focus on that. If they say they can do the job and you believe them, then they’re probably a good candidate.
Regardless of whether you’re getting a programmer, a computer scientist, a software engineer, or a software developer; you also need to be aware that – as with any employee – they are people, with a wide range of backgrounds, interests, and personal situations outside of work. Often, the mistake is made of thinking of them as all being “classic nerds”, and while there probably are quite a few more nerdy types in these fields than elsewhere, it’s dangerous and unhelpful to stereotype your employees in that way. Some people will work best huddled away in a small back-office kept away from human interaction, but others may be the talkative types that everyone chats to and laughs with around the coffee machine/water cooler. Some may like playing Dungeons & Dragons on the weekends, and others may go snowboarding (and some might do both). If you have false expectations in advance, you may find yourself losing some excellent talent by having a work environment that isn’t suitable for the person you’ve hired.
One thing you can be reasonably certain of is a level of creativity and free-thinking. Even programmers – who, as mentioned, focus mainly on implementing a specification as written – require creativity in translating specifications to code, and the other types even more so. Creativity is something that every good software creator will have as they can’t be effective in their job without it. Creativity generally goes hand-in-hand with free-thinking and as such, you should generally expect your software development team to be a little more chaotic and a little less cookie-cutter than some other teams in your organisation might be.
There’s a general view that software types don’t stay in one company for long. Looking at the statistics, this also usually looks to be true, with developers moving jobs every few years on average. It is my opinion however that this is not inherent in the mentality of developers, but rather that most employers don’t do enough to keep the talent that they’ve hired.
The biggest reasons that developers move on is waning interest. Creative people want new things to do, new tasks to occupy their minds. That’s not to say they want to be constantly bombarded with different kinds of work and having to learn a new skill every week – they’ll get burned out just as fast as any other employee thrown in to that impossible situation; but rather that they simply don’t want to be stuck doing the same kind of work day in and day out for years on end with no obvious reward or goal.
Giving developers the chance to be involved throughout the life of a product – even after development has finished – gives them the chance to feel more involved in the products they’ve created. Let them build a bond with their creation, and when your organisation is doing well because of it – whether it be that you’re selling a lot of the application they built, or the internal website has dramatically improved some processes – give praise (and bonuses if you can) to the developer or developers that worked on it. Show them that what they did has real value.
If you pay attention throughout the process of hiring, and during the working life and further personal development of the employee, you will not only hire the right people at the start, but be able to retain that talent for many many years beyond.
Thoughts on anything and everything 