Herding Cats: The tricks and tips for interviewing contractors

There are lots of reasons to hire a contractor. The two most common - in my opinion - are a lack of skills in an existing team that needs to be filled quickly (or temporarily) and a lack of hands needed to complete a task on time. Arguably, these two reasons are one and the same and have a lot of overlap. It doesn't really matter whether you're a massive company or an individual with a startup idea, the fundamental fact is the same: there is something you want to do that you cannot do without help.

Hiring software developers is hard. If you don't speak the lingo, then it's a very confusing world to try and extract the best talent from. I know from some of the weird and wild questions I've been asked whilst applying for contractors how hard it can be to write a job advert or indeed interview a potential candidate. I honestly don't think it's impossible - or even necessarily hard - but it does require a shift in thinking.

"Pretending to know what you want is not better than not knowing"

One of the earliest and most obvious signs that someone perhaps doesn't know what they're looking for is in the requirements of a job.

"We want to build a project, it should use PHP and Javascript for the back-end and Javascript for the front-end".

You don't typically blend backend code languages unless you need a specific architecture to achieve what you're doing on the backend. The reason a requirement like this has come to exist is usually as a result of earlier discussions or haphazard googling. Often clients know what they want to build, and to an extent what goes into building it, but going back to my original point; they rarely know how to do it otherwise they wouldn't be hiring a contractor. Pretending to know what you want is not better than not knowing though.

In circumstances like this, the requirement you should be putting on a job specification is an altogether different one. After explaining what my project involves (e.g. I am building an UberEats for dogs), here's what I'd write:

"We are looking for a developer who can explain how they would implement this project to me/us and the benefits and drawbacks of their approach. We've been previously advised that it should use PHP and Javascript for the back-end, and javascript for the front-end"

The emphasis of this criteria is not on technical ability, it's on communication. In truth, communication is a fundamentally undervalued skill in a developer. If they can't explain how they would do something, or how they've done something, then how will you do handover later? You might be thinking - "Oh that's fine, I'll just keep using them" - but, what if they move on, or they get a full-time job, or they leave the industry. Even if your relationship with your contractor remains amicable, you should look for someone who can explain the details in a clear, understandable way so that you're always able to find another developer.

"Can you show previous projects you've done similar to this one?"

Portfolio work is important. This is indisputable, actually having implemented something is different to knowing how to implement it. In almost every project there are minor deviations that make it different from previous projects; having previously implemented projects demonstrates an ability to overcome the difficulties those deviations present. I still think this question is pointless though.

Why ask it? This is fundamental for every job spec. Whether it's a question or a requirement, you need to figure out the purpose of having it. This question suffers from one major issue - define "similar". In web development, I would argue that 99.9999% of projects are a CMS back-end and front-end client application. In one way or another literally every project can be built like this. There are naturally deviations - as I previously mentioned - but the simple reality is that I can pretty much shoehorn every web application into this kind of model.

That's not necessarily a good thing, but it is true. I would therefore argue that all my work is similar, and that all future work is similar. What you should really be asking with this question is more specific and should address a concern you actually have:

• "Can you show previous projects where you've implemented a payment system?"
• "Can you show previous projects where you've implemented a user account system?"
• "Can you show previous projects where you've implemented a google maps view?"

Be warned though, that you should never go too specific. It's unrealistic (and also pointless) to ask for specific experience. Circling back to my previous example - UberEats for Dogs - the odds of finding someone who has "experience implemented a food delivery system for animals" is slim to none. Now I realise that my example is a bit eccentric, but even if you have a more run-of-the-mill idea, the odds of being able to be that specific and find someone are still quite low.

There's also a second risk with finding someone that does have very specific experience that meets your project. You risk them reusing code and designs that is the IP of someone else - or at the very least being accused of it. Generally, under intellectual property law, when an individual is commissioned to complete a project for someone (be that person an individual or a company) the intellectual property rights of that project and it's content transfer to commissioner upon completion and payment. Of course, good professional practice says that we shouldn't reuse large chunks of code for different projects (admittedly, all programmers reuse bits of code, because some stuff is just common practice).

Simply put, having someone with a fresh perspective, who isn't just going through the motions of completing your project may actually be a benefit, not a drawback.

"Please can you provide an exact quote and not an estimate?"

This is probably the most offensive line to read on a job specification, personally. I completely understand the desire to get an exact number as soon as possible, but, in my experience job specs that attach this kind of line, haven't provided sufficient detail of what the project actually involves. I always give a ballpark figure in an opening message. The reason is simple, based on what I've been told I can roughly guess the order of magnitude a project is going to be on. Is it a £100 - £500 project, a £1000 - £5000 project or a £10,000+ project is fairly easy to work out, even with the vaguest of details.

I give this rough number, because it's important clients have realistic expectations of how much a project is going to cost. In many cases, my price is already well over what they've advertised. The guidance algorithm on some freelancer sites is so inaccurate it's almost laughable. So I give a number that says "if this makes you scoff I'm probably not the right guy for you".

Getting that number precise though is much harder, many times I find that clients underprice for some things, and overprice for others. My best example is user accounts systems. Now these are typically underaccounted for because they're so prevalent. So many sites have user accounts and passwords, and password recovery etc. But, implementing them well is actually quite hard - and any additional complexity is even harder. In some cases, user accounts are the most expensive part of an otherwise cheap project. As a general rule of them, anything with sensitive data (such as usernames and passwords and email addresses) costs more.

It's for this reason I try to have a call with every client before making a final quote. It's for this reason I write up several pages of detailed description of the project to outline what we will and won't do and how much it'll cost. Giving an accurate quote off a one or two paragraph description just simply isn't possible - particularly for bigger projects. It's all the more important for the client for me to get it right, because ultimately if I quote based on something substantially different (and smaller) than what they're looking for, they could ultimately end up with a bigger bill at the end as the scope expands as the project develops.

Which brings me on to my final point

"Keep it simple, stupid"

I've actually discussed this one before. It's still a very cogent and important point though for any project. Think about modularly, as individual components that once complete can start to be used. Rather than create one £10k job, with all the bells and whistles, think of it as 2 or 3 or 4 smaller jobs. Even if you end up awarding it to the same contractor, this more decomposed approach will ensure you have a clear idea of exactly what your objectives are in each stage - what you're expecting of your contractor and ultimately, the requirements and detail you need to provide on the job description.