By Craig Buckler

How to Assess Potential Programmers for Your Business

By Craig Buckler

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.
  • Have you encountered the terms truthy and falsy in JavaScript?
  • 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…

  • crisita

    This a great way to judge how one’s programming skills are coming along and whether you are ready to apply for that job.

  • Peter

    I couldn’t disagree more with the point about setting a development task – a good developer will have plenty of code samples.

    • Absolutely. But how do you know they solved the objective or project requirements?

  • I learnt a few years ago to never give a CV to a recruitment agent as an editable file. My interview was going fine with me explaining my work along with my 100% truthful and well polished work history until I badly contradicted my CV. It turned out the recruitment agent had changed one of my job titles from ‘front end developer’ to ‘web designer’. I was really embarrassed at that point and felt like I must have come across as a liar. I can only presume that the agent must have thought that I would look better if that particular job was as a designer as it was in the same niche as the job I had applied for but didn’t realise that I emphasise the fact that that job allowed me to really focus on developing good coding standards.

    As for the questions above, make sure that you create your own rather than copying from an online test such as from the W3C, the candidate may just have brushed up on their knowledge the night before by using the same test and try not to ask questions that would be seen as patronising by your ideal candidate.

  • Xolani

    “…to ensure they can’t cheat by Googling,” I disagree. A good programmer will use Google and other internet resources to help them code well. Looking at on-line manuals is what programmers do to prevent re-inventing the wheel.

    • Exactly. It’s not cheating – as the article points out. Taking away Google is like taking away their editor, compiler and reference materials. It’s becomes a futile exercise in memory recall.

  • Tero

    I’ve had good experience with development tasks but when candidate is doing face to face I’m asking them to do minor modifications to their code. I’ve seen people submit brilliant response to the test and then completely failing to modify anything of it. They don’t get a job…

    • It’s possible for people to find a complete solution or get a more able friend to do it. Ultimately, they’re wasting their time — it’ll be obvious as soon as you start discussing their code.

  • Nice article Craig.

    I like your approach of not preventing the prospect from using the internet for assisting in their work. I work with a truly fantastic developer who amongst other things, keeps me on my toes. One day he solved a particularly difficult task in record time and when I asked him how he managed to do it so quickly he said:
    a) I’m really good at searching for code related issues
    b) I got lucky

    He’s been a pro developer for 10+ years and along with Netbeans & Visual Studio he considers Google just another tool.


    • Absolutely. A good developer uses all the tools at their disposal. Restricting access to the web or setting exam-like time limits are not realistic. Some people will fare well, but better candidates may fare worse.

      I’ve rejected people who didn’t use the web. I sent a brief questionnaire to a ‘database expert’ who couldn’t answer basic questions even though copying them into Google got the right answer straight away!

  • I could answer all of those questions, and although I’ve written hundreds of lines of JS this year, I’ve only encountered the “truthy” and “falsy” terms when reading the new Sesame Street Book of JS by Elmo. Seriously?

    • Yes, seriously. I’m amazed you’ve never encountered them, especially when they can lead to fundamental JavaScript bugs. The terms are in regular usage. I’m not sure if he devised them, but Douglas Crockford certainly features truthy and falsy in his books and videos.


Get the latest in Entrepreneur, once a week, for free.