5 things to consider when hiring a developer
The challenges of hiring developers and technical team members keep vexing more and more people. It’s a natural development as technology becomes an integral part of our lives and businesses are more dependent than ever on skilled technical staff. But if you’re not a programmer yourself, hiring one can be a daunting task, whether you’re looking for a technical co-founder or a new developer for your product team.
Many people who hire developers are worried that their difference in skills may be the biggest obstacle. And yes, it offers challenges in understanding the skill level of the person you are interviewing. But I’d like to argue that those skills aren’t necessarily what you should focus on the most.
Over the years I’ve made some fantastic and some not-so-great hires, a teaching experience. As a result, I’ve learned to look for five specific things. These are soft skills that are often overlooked by many recruiters, in favor of a glossy resume full of fancy technical jargon giving the impression of experience and skills.
Trust or no broken deadlines
Being able to trust someone to deliver on what’s been agreed and on time is fundamental. It’s at the core of working together and being able to delegate and depend on each other. A person’s failure to deliver on time, breaking trust and promises, doesn’t just erode the trust you’ve placed in someone, it can put you in an uncomfortable position having to cover for their inability to deliver as agreed.
You won’t have any problems finding an overconfident young coder who considers no problem too great and has a massively inflated view of their ability to solve any problem. Or re-solve problems there are already solutions to, since in the minds of young developers, every previous implementation can always be improved upon. But finding someone who will make realistic estimates and stick to the deadlines is harder.
My advice: Don’t give up looking for a developer you can trust and who understands the importance of keeping deadlines.
How to test for this:
- Ask questions like: “Tell me about a time when a project was running late”, “How do you know when you’ll not be able to meet a deadline?”, “Have you ever missed a deadline and if so, what were the reasons?” and “What do you think I value the most in someone in this position?”
- Give the person an assignment which has a simple and a complex solution. Ask the developer about when they can have it done. They’ll likely offer an over-optimistic answer if they’re inexperienced. Ask them to complete the assignment and discuss the outcome with them and focus on how they reason about their success or failure to meet the deadline and the reasons for the first estimate.
Time optimism or working nights because “it’s awesome”
Saying “yes” is a wonderful feeling. It lets you replace that uncertainty that is gnawing inside your customer with a positive confirmation by a professional such as yourself. It feels great, until you realize that you weren’t really sure about what exactly you said “yes” to back there.
Many inexperienced developers are very optimistic about time or the challenges or problems that need to be overcome. I believe this to be the result of a combination of meaning well, being ambitious and wanting to impress. Arrogance probably also plays a part in it.
This is so common that it’s become a rule of thumb among project managers to take whatever the programmer says and multiply with pi (3.14).
My advice: Try to avoid having to cover for poor estimates. Make sure you hire people who have a realistic sense of their own abilities and whom you won’t have to cover for. Equally important, grow a culture that encourages honesty over making things look good.
How to test for this:
- Ask questions similar to the ones for the previous one. Check for whether they have developed awareness of their own abilities to make accurate estimates and plan their own work.
- Try a similar exercise to the one above.
Communication skills or putting yourself in someone else’s shoes
Software development might be one of the trickiest things to plan for. Many brilliant thinkers and researchers have contributed to our understanding of how to plan and perform IT projects. As a result, we have some amazing tools at our disposal. I’d argue that the general level of understanding of project management is higher in IT than in most other fields. Still, up to 70% of IT projects fail, by one measure or another.
One often overlooked aspect of project management is communication.
When things don’t go according to plan, your best course of action is to be proactive, clear and solution-oriented. This means informing affected parties as early as possible, outlining the potential effects of the problem and assuming responsibility (if you’re to blame) and suggesting one or more courses of action.
This probably sounds obvious to you but a majority of developers consistently fail to do this. Instead, they either inform too late or try to cover it up. Discussing the reasons for that would take a blog post of its own. Suffice to say, I believe one common reason is that few developers get the opportunity to see how their work fits in with everyone else’s and the role it plays in the big picture. That makes it hard to understand how one delay can have a wider impact.
My advice: This is a critically important skill, one which I'd not compromise with. But it can also be learned and the result of a mutual trust, good teamwork and leadership.
How to test for this:
- This is an interpersonal skill so roleplaying can be an effective way to create a simulated situation in which this can be tested. You can roleplay a situation in a fictional project in which a crucial feature is running late. You taking the role of project manager and the candidate taking the role of developer.
- Ask questions like: “If you were managing a project, what would you expect and need from members on your team in order to able to do withyour job?”, “What do you think is most important when it comes to handling delays and unexpected issues in a project?” and “What are the consequences of delays in projects and how can those be prevented or managed?”
Quality or taking pride in one’s work and doing everything possible not to deliver defective code
As important as being done on time is doing what was intended and in the intended way. It’s about doing the right things right.
In my experience, it’s not rare to find developers who insist they understand what needs to be done and how it needs to be done but consistently deliver something else. Once they deliver, you immediately spot defects or problems even after just a cursory review and the work gets sent back. This results in broken deadlines and repeated runs of “check and fix”. This doesn’t just risk derailing your project, it could also undermine your customer relationship.
A great developer understands what needs to be done and will do all the necessary testing as well as plan for it, sticking to your agreed deadline. They understand what’s relevant to you, and the customer, and work proactively. They will likely know how to test things in a systematic fashion and do not consider test-driven development a waste of time.
My advice: A junior developer is more likely to not think ahead but it can be learnt. If the person you are considering performs well on the other five, then you may tolerate somewhat lower scores when it comes to quality, provided the person understands your concerns and seems like someone who wishes to learn and improve.
How to test for this:
- Ask them questions such as “How do you go about testing something before delivering in?”, “How do you make sure you and the project manager or your team member are in agreement on what needs to be done?” and “How should requirements be written and presented in order to prevent misunderstandings?”
- Give them an assignment with unclear requirements. See if the candidate raises the issue with the poor requirements and wants to make sure you’re in agreement on what needs to be done. Check the work they deliver for defects and discuss the ones you find.
Strategic thinking or being humble enough to admit there’s probably a better way
There are many paths to a goal. A wise person knows this and can navigate between all of them. They can consider the risks and advantages associated with each. This form of goal-oriented analysis, a form of strategic thinking, is a crucial skill for a developer to have.
When you set out to solve a problem, usually one solution will pop into your head. This is most often not the best solution, only a starting point. Great developers know the value of not running with it but instead try and come up with several alternative ways of achieving the same thing. When doing this, they focus on the desired outcome, not the function per se.
Once they’ve chosen one strategy or way of solving the problem they make sure they do not invest too much into it initially. Instead, they consistently evaluate the return on their investment in the chosen path and are ready to re-evaluate the choice of strategy.
Software development is exploratory and driven by learning. This means it cannot be fully planned. There are always unknown factors at play and these are discovered over time and learned in a project. You cannot know these in advance and there’s no point in trying to determine them all. Instead, they are uncovered as the project proceeds. This is why “agile” has become such a key concept in modern IT project management. Instead of sticking to a fixed plan, you work in an agile fashion which allows you to re-evaluate decisions iteratively and in an ongoing fashion in order to use the knowledge you’ve gained.
Junior developers tend to underestimate risk and overestimate advantage. They also tend to get tunnel vision, losing sight of the overall scope and goals and fail to realize when a chosen strategy is no longer working.
Developers capable of strategic thinking also tend to be better problem solvers and troubleshooters as they apply an analytical approach to the process and eliminate causes, a bit like Sherlock Holmes solves crimes.
My advice: This skill influences several of the other ones I mentioned earlier, such as meeting deadlines. Why I believe this to be too important to be relaxed about when hiring. Make sure the person you are considering is capable of taking a strategic approach to problem solving.
How to test for this:
- Ask questions like: “Think of a case in which there were several possible solutions, how did you decide which one to use?”, “Why do companies spend money on IT?”, “Describe a beautiful technical solution to me and explain why it’s better than other possible solutions” and “Describe to me how you think and reason when approaching a new programming problem”.
- Simulate an engineering challenge such as bridge building in the form of a game and assume there are three possible designs but they depend on conditions that take time to find out such as whether there’s bedrock close to ground or the conditions of the riverbed. The candidate has a set deadline and can only do a limited number of things. Ask them to think aloud as they solve the problem.
I hope consciously looking for these skills will be of great help when hiring your next technical team member. Good luck!
Photo by: https://stocksnap.io/photo/M8SYXA8H4H