Although it seems easy and straight forward, hiring a developer has its own specific challenges. For most managers and executes, developers may seem from another planet while talking to them (you might need a tech dictionary). I’ve hired dozens of developers over the years from all parts of the world.
Let me drop a bomb first…
Hiring a developer has nothing to do with having a rockstar coder.
In this article (5 minute reading time), I’m going to help you hire a developer by explaining what a developer is actually all about, how to interview a developer and what to avoid.
And the best of this article…I’ve put in a freebee as a holiday present! I’ve put together some technical interview questions you can use as a non-technical person. Rewarding you for reading my articles isn’t the worst, right?
Cost of hiring the wrong developer
As I did in my ‘How to hire the right product manager‘, we first start with what you want to prevent.
- Pay peanuts, get monkeys. Good developers have a price tag. A lot of companies and startups tend to go for price instead of skills. If you do, expect the developer skills to be poor and will need a senior guidance with no guarantees for the long run. Most of the times, this doesn’t work.
- Wrong architecture and (coding) structure = impact on product quality. Making the wrong technical architecture decisions have a high-level long term effect. Making the wrong coding decisions have a more short-term impact and effect. Your product will suffer on both terms.
- Frustrated (senior) developers. If there is one thing developers really hate, it’s crappy code and technical quality. This will impact the overall workplace environment and company culture as people walk around feeling frustrated with low quality work.
- Acquisition devaluation. When you have an exit strategy as a tech company and an acquirer runs their due diligence, they’ll look for your so-called ‘dev headcount’. It basically means how much skilled tech people they get with the acquisition. Poor quality developers will be excluded from this and will devaluate the total acquisition value. No real skills, no real cash.
- Competitor(s) gets the advantage. Poor coding means poor product (speed, design, etc). You just gave away an opportunity to your competitor(s) to get a better lead position in the market by delivering a better product.
The skills pyramid of a developer
It’s important to understand the several layers of skills needed to qualify as a good developer. Visually it can be portrayed as a pyramid to represent the several layers and their importance level:
As I mentioned before, coding skills are the least important. If you can code, you know by fact that coding is a lot of repetition work and can be trained more easily compared to the other skills. It requires a detailed eye. I’m not saying it’s not important. But in the bigger picture of required skills coding is the most detailed level of all and therefor has its position.
Analytical thinking skills is focused on the ability to solve problems. Tech is all about solving problems. Coding is just executing the solution to a problem you’re solving. It has a lot to do with Computer Science where you mostly learn how to approach problems and ways to look at solving them.
Communication skills and being able to convey a core message properly. You can have the most briljant solution but it renders useless once nobody else understands what you actually mean. Solutions that are properly communicated get adopted faster. It’s not what you sell, it’s how you sell.
Social skills are important once a developer is ready for the next step: leading other developers in a team. You need to be able to convince people, accommodate circumstances and expose persistency (which is not the same as being stubborn) as well as consistency. You’ll only lead if you’re worthy of following.
Vision is the foundation to a developer’s view on his work and impact. All that work should lead to something. A developer should have a clear view where he’s going and how he adds value no matter which company he’s working for. Having an open view of how to address challenges and the ability to adapt (being language-agnostic helps). People with a clear sense of value and impact have a tendency to guard themselves from delivering poor quality. This is because they have a clear incentive and they know this will only hurt them.
How to interview a developer
There is no holy-grail for interviewing a developer candidate. This is how I approach the hiring process and some details that relate to the skills pyramid.
There are 2 rounds of interview. The both have a specific goal and setting.
Goal = figure out communication-social fit and analytical depth.
Setting = One developer, one non-technical team member (preferably woman).
You might have raised on eyebrow about the woman part. The reason I always choose a woman to be in the first round interviewing: women have more advanced social dynamics senses than men.
The developer is there to figure out if the candidate’s problem solving skills are up to a standard. The other person is there to test on social dynamics and the probability of team fit.
Round 2: the real tech stuff.
Goal = figure out technical depth and (product) vision.
Setting = One developer (not the same person as in Round 1), technical Product Manager.
This is more like a tech drilling session. You want to go deeper into technical knowledge and specific cases how he/she would approach them towards product delivery. It will expose more about how they work with others on a technical level. The developer can go as far as breaking point (= when the questions exceed the knowledge of the candidate).
The product manager is there to focus on the dynamics between the developers and see how that works out. You can ask about product vision, things he/she wants to improve, etc.
You should never forget this important part…
Once you’re done, ask if the candidate has any questions for you. This is extremely important. The questions will reveal if the candidate did their homework about aspects of the job, the company. It’s also important that he/she seeks alignment with own ambition or goals. You shouldn’t be there just for a salary.
If someone has no questions and doesn’t reveal any of these traits, it should be an alarm bell!
Winning the developer hiring game
So why are there only 2 rounds?
Short answer: competition. Nowadays technical talent is recruited, scouted and even hjiacked faster than the speed of light. Companies are more aware than ever that part of their market advantage comes from the talent they can attract. You need to have a balance between being thorough and fast to close the deal. If you don’t, your competitor with a keen eye on talent will.
Hiring the best developer talent is a game you want to win. Go win or go home.
Developer ‘skills’ to avoid
- Being a know-it-all. Software engineering is like science: you’re correct about half of the time or less. You need to learn and iterate fast. Being a know-it-all portrays have a lack of reflection and are not open to other views.
- Being language religious. Someone who does 1 programming language and thinks he/she can save the world with Ruby. Means you’re not that adaptable and probably not willing to challenge yourself with new learnings.
- Not listening. I’ve said this a few times in my other articles: developers can be stubborn f*cks. This is OK till some degree. Not listening and just exposing own views is a bridge too far.
- Being reactive. Only being reactive instead of pro-active. Being on top of your game means taking initiative. Your company won’t win any wars with people that only react to circumstances (like only doing hotfixes instead of planned refactoring to keep technical debt manageable).
Freebee helping you hiring developers
You now have a clear structure and overview how to hire a developer. The most difficult part for most companies (specifically when you’re small or a startup) is the detailed technical part.
In the spirit of the holidays, I’m giving away a freebee to help you hire developers with technical superpowers for developer interviews!
I’ve put together a developer interview help document including answer for non-technical people. Giving you all the power to ask technical questions without knowing anything technical.
Disclaimer: it’s a living document and will be updated along the way.