All IT companies at some point are faced with the problem of hiring staff – in particular, developers, who in most cases are the core of the business, as they create the product(s) the company builds upon. This is no easy task (if you think it is, go and outsource all of your development to India and fingers crossed you might be lucky to get something back); as such, a lot of companies get it wrong. I’m not claiming to be the expert on this, but having been on both sides of the hiring process I figured out there’s a few “NOT to do” things that I’ve learned — hence this post.
One of the most crucial aspects for the hiring process is the size of your team/company. Don’t expect a corporate-trained developer to be able to join a small team where eveyone does 200+ jobs and be effective: the reality is if the developer comes from a corporate background all they are used to do is coding — quite likely someone “at the top” makes the architectural decisions, including the manner the product will run, scripts, databases and so on. Take a small team in contrast and eveyone is responsible for chipping in with their architectural suggestions, do a bit of bash scripting, some dba work, sysadmin and a lot of other little tasks required to get the product off the ground and running in a production environment. As such your developer quite likely will struggle and will feel frustrated as they’re not being used at their full capacity and for their set of skills. You on the other hand, the employer, will also most likely become more and more frustrated with the fact that your new hire looks good on paper but the reality is far from that. Should you have mentioned in the interview the current setup in your team, your candidate might have declined the position upfront – or might have asked certain questions which could have made it clear from the start he or she is not a good fit for your team.
On the other hand, if you’re in a corporate environment, think twice before hiring someone who’s been used to smaller teams and startups — they will expect in most cases to be involved in all areas of development and have some input in all of them. Working on a product that spans over a few departments means your developer won’t have visibility of how modules inter-operate and as such they will feel frustrated and believe they are not utilised at their full capacity or come up with wrong ideas about improving the product – which will be rejected thus leading once more to frustration.
Second thing to take into account (though it is coupled quiet tightly with the first) is the manner you carry out the work in. In a small company you will find yourself quite often sacrificing standards to timescales and the odd hack is the norm. Unit tests are good — time permitting — but they don’t produce money so given a time constraint they will be skipped. More importantly, and that quite often is a crucial factor, small companies don’t employ an 9-to-6 policy in terms of working hours (if you are a small company and you do, trust me you’re fucked: you’re on the way to sinking the company – or at least prevent it from growing). If you’re small you have some crucial advantages: you’re versatile and you’re mobile, you can produce a quicker turnaround than a corporate — but this comes in 99% of the cases at the expense of sacrificing personal time. (Unless you’re an absolute idiot you know this means you have to repay your team for this — be in in hard cash, holidays, or other niceties paid entirely by the company-i’ll get back to this point in a second.) For someone coming from a small company that shouldn’t be a problem — and as long as you agree with them on rewards etc working longer hours is not a problem. Take a corporate guy and place him in this environment, fast forward to the first small crisis when you need all hands on deck and guaranteed when you ask them to stay late their jaw will drop, and they’ll look absolutely stunned: “you’re joking!“. From there on you know even if they stay late they are unhappy and frustrated — and quite likely brushing up their CV. So you end up wasting time (yours and theirs ), money, nerves to no avail. Even more, someone leaving a team (especially in smaller teams) destabilises the team for a bit — so now you have to work on keeping the morale up AND recruiting a replacement. (And if you still haven’t finished the work which required them to stay late you’re fucked!)
One other thing to consider is the budget: you have so many people to fit into so many pounds — hiring “the best” is not necessarily your best option if you’re small. While a corporate like Google can actively seek some of the best (technically) developers, they have the means and time to figure out how to use their skills at their best — and as such use a database design and speed improvement analyst for just that, and leave the tasks of backup and recovery planning to others specialised in that area for instance — in other words ensuring that each individual only does what he or she us good at. In contrast, a small company as I said thrives on versatility — so hiring “the best” won’t help you in any way — you should look out for those who have a good mix of development, sysadmin, dba, project management and people skills, because you will need a bit of each one of those from them. If they are also “the best” of each of those that’s an added bonus but shouldn’t constitute your main recruitment criteria, because if your new hire can code brilliantly but can’t mix in some sysadmin and dba they will have to wait for someone else to deploy their work — and if they got no people skills and can’t communicate this to others in your team effectively, their work might be done but only see your production environment 2 weeks later which is a huge delay for a small company. Whereas someone not that good technically might start off with a wrong approach and design and overlook some aspects of what might be happening once your project goes into production — however if their communication and people skills are decent, they will be able to find out about those through self-initiated discussions with team members; and as such be able to re-adress the design and code or work out a way with sysadmins of how to adjust some of the system setup so the system can still be run. On the other hand, your Google guy would probably write some brilliant tech specs that explain in every detail the insides of the system — whereas in a huge company eveyone would love that and take time to read and understand, in a small company no one will probably have the time to go through 100 pages worth of spec and much rather prefer the verbal 5-minutes-long brief. None of the 2 approaches are wrong however none of them is right in the wrong context!
I’ve mentioned earlier a reward system and promised i’ll get back to that: your average SME has some basic rewards system typically consisting of a mixture of private health care, pension, gym membership, bonus based on individual and/or team performance, extra holidays and so on. In comparison, if you’re small, you won’t be able to provide most of these (try to negotiate some private pensions when you only have 15 employees and you’ll get some shitty rates!) and as such you need to find other ways to entice your employees to come and join you and most importantly stay. (Paying just the standard rates means you will probably get your mediocre people in — who would choose to lose the other benefits unless they are struggling to find a job?) So when dealing with your new hires in a small setup you need to figure out very early in the process whether they’ll be likely to accept the package you have to offer and further more whether they will be pleased with or look upon this role as just a stepping stone and be out of there in a year? Your corporate employee might accept your offer then 6 months into it expect a bonus or some extra holiday which you cannot afford — so then you just lose him! Vice versa someone coming from a small company will not care maybe about the gym membership but prefer instead a significant salary raise / bonus every year, where your company policy is only to pay a standard 2-3% — so he will be out soon. The thing is in early stages of looking for jobs most candidates will say “yes” to virtually any package that has their basic salary covered just so they can secure some interviews for worst case scenarios and also to help them get an understanding of the state of the market and what’s out there on offer. You need to figure out whether they are likely to stay on the package you’re offering or likely to move soon. Do NOT simply assume that just because they said yes to the initial offer they are happy with it — maybe its the best they got but doesn’t mean its the offer they expected!
I talked earlier about hiring “the best” and I realised I’ve missed an important aspect: training! In a bigger company you can afford to hire potential: someone who has the right attitude, the basics covered and can through training develop the skills you need. It happens a lot in the IT world that new products, platforms and so on appear over night — no one would know upfront how to use them! If you need to use one of them you send your staff to training and allow for time for the technology to be assimilated. This is the standard scenario for a bigger company — when it comes to smaller company the idea is the same (your developers need to learn this technology) but the way you go about doing it is much different! First of all unlikely you will have the budget for training — you might (well, you should, really!) have the budget for books, CD’s and other such materials but you will be relying exclusively on your developers teaching themselves so to speak — in other words you would be relying on your team’s initiative, self motivation and drive. Furthermore, you might not have the time to properly test such technologies which means in a lot of cases you will be relying on your team’s experience and gut instinct to make a call regarding the usage of this technology. I’m not saying that someone who worked in a big company is not that motivated and experienced to do all these — I’m saying that they will find it difficult: when you work in an environment where a lot of these aspects are looked after for you by someone else and you’ve been there for a while it’s hard to adapt to a different culture where you have to cover these details.
I guess last but definitely not least it’s worth stressing that you shouldn’t hide the reality of your team from candidates — we all hope that one day things will get better and we’ll do more coding and less “other stuff” but that might happen a couple of years down the line — and meanwhile you would have probably frustrated each of your hires. Simplying hiding that away means you’re deceiving your potential employee and you might get them to sign the contract and join you — but their first feelings would be that they have been cheated since you have hidden these aspects from them; this in turns triggers in their mind the question of what else has been hidden from them? Are there any other “niceties” coming their way later on? And if it is the case that relatively soon some other irregularity comes up you can probably say goodbye to your hire soon after!
I’m sure there’s a lot more to be said around the subject (in fact don’t be surprised if I’ll come back later on with some more on the same issue!) — and I’ll be glad to actually hear some thoughts from my readers (yes, they do exist! :D) on the matter. For now though, to sum it up, in development we all know we need to use the right tools for the right job — and the same goes when choosing your developer: choose the right developer for the right job!
