There comes a point in every successful freelancer’s life when they consider switching from a one-person operation to a multinational conglomerate. That means employing people to do your job.
It’s certainly not for everyone. You’ll become ‘the boss’ and spend most of your days managing projects and sitting in meetings rather than writing cutting-edge code. But, get it right, and you could spend more days at the beach rather than sweating behind a screen like your employees.
Since you’re already a great developer, there’s one easy way to guarantee success. Hire programmers who are better than you. But how do you know?
Finding candidates in the current economic climate is easy. Unfortunately for you, good developers are rarely out of work and may be less inclined to take a gamble on your fledgling business.
Fortunately, the web makes it easy to contact potential employees via specialist job search sites and social networks such as LinkedIn and Twitter. However, be wary of recruitment agencies. There are some good ones but they’re astonishingly rare in IT. Most don’t have a clue; I’ve seen job adverts for client-side Oracle engineers and back-end HTML5 specialists. In my experience, agencies throw people at organizations until one sticks — then poach that person from you the instant they smell a larger commission elsewhere.
So you’ve created your shortlist of résumés. Each should have a range of sites and projects with associated URLs. Even those fresh out of school will have sample work.
Many companies now invite candidates for an interview. Don’t. I’m going to let you in on a secret: many people embellish the truth on their résumés. For every candidate who can do the job, there are many more who can’t. Worse are those who’ve convinced themselves they’re great developers. I once interviewed someone who claimed in-depth HTML knowledge because they worked in an office where others used it. Don’t waste your time and theirs.
The first step is a 15 minute telephone interview. Thank them for their application and ask why they’re interested in the role. More importantly — test their technical knowledge. A serious of basic questions will separate the can-dos from the can-nots, e.g.
- What development tools are you currently using?
- What HTML tag is used for the main title on a page?
- Name the CSS property which sets bold text.
- What is meant by a magic method in PHP?
- Explain what is meant by an abstract class?
- Name a couple of database engines used in MySQL.
- What SQL command could be used to remove all records in a database table?
The second step is essential: give your potential developer a development task. Ideally, it should be reasonably challenging, take no longer than a couple of hours and be completed using the language skills you need.
Some companies prefer to assess developers in-house to ensure they can’t cheat by Googling, seeking advice or taking too long. Is that an accurate reflection of coding in the real world? No — and it can lead to rejection of ideal candidates because they were nervous. Services such as Codility.com can help, but I wouldn’t worry about setting strict time limits or conditions. Good developers won’t take long and bad developers will give up before they start.
Finally, it’s time for one or two face-to-face interviews. Ask the candidates about their code, how they approached the problem and whether they would make any changes (good developers know improvements are always possible). Importantly: can you work with them? If they tick all the boxes, make the candidate an offer, put them on probation period then do your best to keep them.
I’m sure you have some great interview stories. What’s the most ridiculous claim you’ve heard from a potential candidate? Was your interviewer useless? Comments welcome…
Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.