Outsourcing software development work is becoming quite common these days, especially with remote work now being more normalised.
Finding developers from all over the world using online platforms is easier than ever, and the rates can often be too good to be true.
If you’re someone who doesn’t have software development knowledge, how do you know that the person you’re hiring that will deliver you with high-quality, stable and maintainable software?
We’ll give you a few questions you can ask plus some answers to watch for, which will help you evaluate the type of development you’re likely to receive.
While it won’t completely replace the opinion of a trusted professional, think of it like hiring someone to build a house. You might not be able to tell who’s the best builder out there, but you’d probably forgo the fella who tells you that a rock is their preferred tool for driving in nails.
Here’s a few questions you can ask before hiring a developer, to get a feel for how good of an end product they’ll deliver. While they might not always give an answer a layperson can understand, you should be able to use this guide to distinguish between a good answer, a guess, or an “I don’t know”.
What’s your favourite software design pattern?
A software design pattern is like a template for solving given problems in software development. Good developers are aware of them and their names, and recognise when they use them. Many developers will use patterns without even knowing the technical names, but other developers may be able to explain a solution using only its name; for example, “I improved the end-readability and usability of their software library by implementing the façade pattern.”
A good answer to this would be (strangely): “It depends”. Since different design patterns are for different types of problems, being able to pick just one as a favourite would be quite strange. They should be able to elaborate on a couple of times they’ve used particular patterns and why. (Keep in mind that you should ask this question before you explain the details or the project, in order to get a better response.)
An adequate answer would be to just name one or more of the patterns. This would at least indicate that they’ve heard of these design patterns, and hopefully that they use them.
And of course, an “I don’t know” is not something you want to hear.
What code formatting style do you use?
When writing code, usually it doesn’t matter how it’s formatted; in the end, it will still behave the same (although there are some languages where formatting is very important).
For example, these three if statements are functionally identical:
if (a == b) {
printf("A equals b.");
}
if (a == b)
{
printf("A equals b.");
}
if (a == b)
printf("A equals b.");Despite the different placement, or complete lack, of curly braces ({ and }), you’ll get the same output each time. If formatting doesn’t matter during execution, why choose one over the others?
The secret is, it doesn’t matter which formatting you pick, as long as it’s consistent throughout the project.
It’s like typesetting a book – do you use 12pt Times New Roman or 11pt Georgia? Provided you’re not constantly switching between them throughout the book it probably doesn’t matter too much. (Apologies to any font nerds out there.)
Many languages also have tools that will automatically format code for the programmer, meaning that they can write it however they choose (although any coder should try to do a pretty good job from the start) and then run the tool to automatically clean it up.
So, a good answer to this question would involve naming some of the formatting tools they’d use. Listen for terms like “linter”, “beautifier” and “minifier”, alongside other specifically-named tools or programs. (There are too many of these to name without writing a whole separate article.) Otherwise, listen out for the word “consistent”. A good developer will be consistent with the style they use throughout.
Once again, if someone says “I don’t know,” or tries to buy time and waffle around the question with a vague answer that they’re clearly coming up with on the spot, that’s not a good sign.
How do you lint your code?
As we saw with the previous question, there is some flexibility with the way code can be written. However, just because code executes doesn’t mean it’s good.
For example, someone might initialise a variable (store a value somewhere in a program) and then never access it. Generally this won’t cause problems with the program itself, but when another developer comes along they’re going to waste time wondering why that variable was declared, and if it can be safely be removed.
There are tools that exist to “lint” code; while they do play a role in cleaning up messy formatting, their real purpose is to perform analysis for problems similar to the previous example. They scan for issues like:
- Code that is never accessed
- Variables that aren't used
- Functions that are too many lines long
- Variable or function names that are too long
- Functions that accept too many arguments
- Methods that should be static
And many more, depending on the programming language.
A good developer will be able to name the tools they use to perform linting. A great developer might also be able to mention that linting sometimes gets in the way, and mention a couple of rules they disable due to them just being too hard to work with. For example, a lot of linters try to limit lines to a very short length, as a holdover from when we had much smaller screens. These line-length rules are often disabled without any drawbacks.
Good developers will also tell you that they lint their code before “checking in” their code to version control (the system for sharing code with other developers). That way, any linting problems will be fixed before anyone else has a chance to see them.
If a developer says they don’t lint their code, take this as a bad sign. There are exceptions to this rule; it’s possible that their IDE (code editor) automatically flags issues for them, or that their chosen language flat-out won’t compile if formatting isn’t 100% perfect. However, in such cases, you should expect any such programmer to volunteer those details themselves, when faced with such a question. If you’re deciding between two otherwise equal developers, and one knows about linting and the other doesn’t, go with the former.
Do you write unit tests?
This is the developer equivalent of “Do you floss every day?” Everyone knows the right answer to this question, and it’s easy to tell a little white lie.
In this case, a simple “Yes” might be as bad of an answer as “No”. Let me explain.
Modern software development isn’t monolithic. Any piece of code is built from multiple building blocks, and the eponymous “units” are defined as the smallest testable parts of any software. This means that they take in a few very simple inputs and generally return a single output. A good example would be a tiny little odds/evens function that takes in an array of numbers and spits out a list of which numbers are odd or even.
Unit tests are exactly what they sound like; they’re tests that check whether or not a unit, given certain inputs, will spit out the results you’re expecting them to… and that’s all they are. Unit tests aren’t silver bullets. They won’t tell you, for example, how well that piece of code works when 10,000 users are on your website at the same time.
Unit tests are only the first step in software testing, and a good developer will explain that. They’ll tell you something like: “Yes, I unit test, but it won’t tell you the whole story. We also need to consider A, B and C scenarios when testing the product.”
There are many possibilities for what good developers might pick for their A, B and C options. They might talk about manual user testing, load testing or interface tests with users. In general, a willingness to go into detail is a hallmark of an experienced developer.
A poor developer will say “No” or “Yes” without elaborating why.
What performance bottlenecks or compromises do you think there will be?
Almost any project will require some kind of compromise between development time, running costs and performance – unless you have endless time and an unlimited budget. (In which case – please call me!)
You might think that a good developer is someone who can tell you that there won’t be any performance issues and that things will run smoothly no matter what happens. This is, sadly, never the case. At some point, you’ll have to take computing costs into consideration.
A decent developer should be able to point out where you’re going to hit bottlenecks. For example, they might say that you’d usually expect to have to scale out the interpreted application code before the database. (This is just the nature of the beast.) Possibly they may suggest that a caching layer will be necessary at some point.
These are all good ideas, but a pro developer will go a little further. They should be able to tell you about all of the above, and also talk about the costs and benefits of these improvements. For example:
- I can get this up and running on one server, and when you hit 100 users that will cover the costs of upgrading.
- I can write this quickly without any caching, but in a way that's easy to add it later. When we have enough users that it starts causing a problem, it will cover the costs of adding that in.
- If I use Database A, we can be up and running a lot sooner. When you've validated that there's enough interest in the product, it's easy to migrate to Database B, which provides more performance but requires some setup work.
In essence, an expert should be aware of not only the path to take for more performance, but that they shouldn’t go overboard with this work until it’s necessary. They need to understand both your needs and budget, and accurately assess when it makes sense to start spending time and money on improving performance instead of growing your user base.
Do you have references?
While references are important, I’d advise leaving this to the end of the interview. The reason for this is that if you’re looking for references relating to a technical position, you need to carefully consider what perspectives those references hold. As a non-technical recruiter, keep in mind that different people will have different perspectives on a candidate’s abilities; a Chief Technical Officer who doesn’t have a programming background might only describe how easy the candidate was to work with, whereas a CTO who’s also a Project Leader could speak directly about their programming skills.
Of course, I’m not saying that you shouldn’t reference-check your candidates; both perspectives are invaluable, and finding out whether a developer is amicable and communicative can be as important of a consideration as whether they’re able to deliver products on time. But like a shack with a fresh coat of paint, the appearance of the end product might not indicate that it has great foundations. Take the time to find out whether the reference-giver can speak authoritatively as to a candidate’s technical skills.
Go forth and hire good developers
As a consultant developer, clients often bring me in to add new functionality to pre-existing software projects. Oftentimes, I’m presented with what amounts to a snarled tangle of code, riddled with so many inefficiencies, shortcuts and bugs that just figuring out the software is often a learning curve in itself. This usually results in a need to undertake lots of fixes before I can even begin to add new features to a program, a process that can add days or even weeks to a project.
Ultimately, rushing to get a project done quickly and cheaply in the short term adds additional costs of time and money in the long term. The lives of me and my customers would be a lot simpler if I could jump into a new project and begin enhancements right away. Follow this guide and ask the right questions, and you’ll cut down on the long-term maintenance costs of your projects.