How not to hire a Software Developer

I, like many other software developers, have gone through the process of looking for a job. After shining your CV, fielding many calls from recruiters and ultimately going to multiple interviews with potential employers, there are a few lessons learnt and many frustrations encountered.

Let's meet Bob. Bob is a 24 year old software developer. He loves what he does, is in a committed long term relationship, has no kids, likes the good things in life and values a good working environment - after all, Bob understands that when you spend anything from 8 to 12 hours of your day, every day, at a single place, that it ought to be a good environment.

Bob had a really smooth transition out of university. He got a job extremely easily with his scarce skills but didn't understand much about what the industry entailed. After working at his job for 2 years, he realised that he didn't enjoy where he worked. In those 2 years, he was able to figure out what made him happy in his workplace and what adversely affected his happiness at work.

So, Bob set out to find a new job - something that he enjoyed. This is what makes Bob happy:

• Doing work he loves. Bob spent a long time learning how to do what he does so he has a good idea of what he enjoys doing. Bob enjoys working on cloud based applications with appropriate technologies like PHP, Python, Mysql, Linux, 3rd party API integration etc... He knew a long time ago that he didn't enjoy frontend work - HTML, CSS, UX, UI etc...
• Working with chilled people. Bob understands the requirements of corporate but also knows that people can be a bit uptight in a corporate environment.
• Working for a good boss. For each of the top reasons that employees leave a job, they can all be attributed to their relationship with their boss. For example, an HCareers article I found suggests that the number 1 reason employees leave is because employees feel under appreciated. The root cause of this is obviously a lack of acknowledgement, communication and general understanding of the structure of the business from their line manager.
• Working in a flexible environment. Bob doesn't like the sound of the general unhappy worker rhetoric "working nine to five". So, Bob wants a job that doesn't care when he walks in as long as he works his required capacity.
• Personal Challenges. Bob has ambitions and wants to be better than he is. Bob wants to work in an environment that really challenges his skillset and improves it.

Notice that Bob doesn't place remuneration high on his list of requirements. Nor does he place a smoothie bar, a gym subscription or free lunch on that list. Bob thinks that a smoothie bar isn't going to help him feel happier when his non-technical manager is a d*&k.

So, Bob has been contacted by recruiters and has been offered a job. Let's call the company TI. TI said "We absolutely love your CV, our head developer loves you. We'd be delighted to offer you a job. However, your asking salary is a bit high but we can see you're worth it. So, we'll give you a reduced salary during your probation period and increase it to your asking price if it works out. Also, we totally understand your requirements and we just want to reassure you that you'll only be doing backend work". TI's CEO even went so far as to fly to Bob's city to have a meeting with him reassuring him of all of his requirements. This was an excellent gesture and Bob felt comfortable that this was a good fit.

A lot happened between this stage and when Bob decided to quit - only 3 months after having started working at TI! Bob was so unhappy that he resigned from TI before having a job offer from another company. What happened and what can employers learn from Bob's experience?

1. Don't lie about your Company - qualitatively, society has a few different definitions of the word 'lie'. However, if you've misrepresented something about your company, at the very least, you've been negligent. Saying "we have a flexible working environment" and then insisting that your employees tell you when they go to and come back from lunch is not flexible. Someone reading this might think that it's acceptable because it's non invasive and simply aims to keep track of the employees that don't have the same work ethic as Bob. We look at this in point 3 and 4 below. Also, don't forget that there are going to be days that Bob also wants to take a 2 hour lunch. We'll look more at that in further points.
2. Take the time to understand Terminology - if you're an owner or a manager of a company it's quite possible that you're not going to be a subject matter expert on every role in your business. That is okay. However, if you don't understand something, it's your responsibility as a leader to find out what Bob is talking about. So if you suspect that you're not on the same page, ask Bob to reduce the word "frontend" to individual roles and tasks. This puts you both on the same page regarding what is expected of them.
3. Have a good recruitment process - how a company recruits employees varies greatly across different industries and certainly across different companies within the same industry. However, what recruitment process you choose must be one that fulfils your requirements as a company and also treats potential candidates with respect and dignity. Nothing is worse than going for interviews and not being contacted back by a potential employer.
4. Trust your own recruitment process - this means trusting completely that your recruitment process has placed the correct candidate in your company. You should have so much trust in your recruitment process that you never doubt the employee's ability or cultural fit. That may sound difficult, but companies have been making use of excellent placement software like Shadowmatch that looks at the habits of candidates and compares them to a general curve of existing employees' habits. This helps hiring executives decide whether or not an employee is a good fit in terms of their current team.
5. Trust your team mate - you'll notice we've moved into the "team mate" phase. This is an important change. When someone joins your team, it's important that they have a say in how things are executed. Personally, I've never believed in a hierarchal structure. Flat structures have always yielded the best results in terms of happiness and productivity because they involve implicitly including someone in decision making. That being said, regardless of structure, it's important that your team mate enjoy autonomy in their role.
6. Let your Software Developer embody the role of Subject Matter Expert. There is nothing worse for a software developer than to be told how to do their job. Bob has been developing for 6 years, went to varsity and has experience working in business and in teams. What makes you think he hasn't figured out what's best for his workflow? In my experience, employers try to impose for one of two reasons - they don't trust their developer or they have shocking business processes in place that add no value to the workflow but require the developer to adhere to weird rules that ultimately hinder their work ethic and, by extension, their happiness.
7. Don't make decisions for your team. This is going to rub control freaks up the wrong way but the truth is that, every decision regarding the direction of the product, the way your team works together and what technologies should be used should ultimately be made by a democracy containing the people working with the product - your developers. As a manager none of that concerns you. That's not to say you can't offer guidance and facilitate discussions and play a pretty active role. However, to veto a decision made my developers is the quickest way to an unhappy team. Imagine the discussions - Employee A: "Aaarg, why do we do it this way?". Employee B: "Because that's what we decided as a team". There is no way Employee A will complain. Just no way. However, if that changes to "Well, the boss said so, I don't ask questions" - well then, that's not exactly buy-in is it?

I wanted to say something about point number 4 - Trust your own recruitment process. Why should companies do this? Why not just rely on legislation permitted probation periods and call it a day? It boils down to two aspects: how much money you want to waste recruiting people and having a high attrition rate, and how successful you want your company to be.

Let's face it, a software development company's success is not contingent on how good their project managers are (although that is important for other reasons). Take away all other roles if you so wish but you simply cannot run a company without software developers.

So that's the extreme - having no software developers. However, what about a more realistic medium - unhappy developers? There are a lot of developers in the world - surely this is okay?

Firstly, there are many developers and far fewer great developers. You'll be kicking yourself when you lose a great developer for a good one. Not to mention that the recruitment process isn't free. There are real costs associated to the time and effort it takes to recruit someone.

Secondly, software development has no clean formula. We've done a lot to build methodologies around workflow (like Agile etc...) but even so, software code is its own beast. Something will always go wrong and you're going to look to your developers to plug the holes you didn't think of  and these tasks will almost always fall outside the ambit of what is reasonably expected of them - how keen do you think they'll be to do that if they're unhappy with you or with their work environment?

In conclusion, Bob has been exposed to many situations that have made him a better asset in the job market - not just a better software developer. In the same way, one hopes that employers will learn that software developers are slightly diva-esque. However, for every ounce of diva inside them, software developers have triple that intensity of passion for their industry and as such can be fiercely loyal to you and the company they work for. Having that kind of resource doesn't come with a price tag. It's invaluable.