In this post I’d like to reflect on our recruitment efforts for a new developer. We’ll have a look at how to go about matching people to roles in a team and how to actually find people.
Disclaimer: I should point out that this post was written in the Netherlands and focuses on how things are done in the Dutch culture. This may very well differ from your culture. I do not claim to be an expert either. Anything in this post is based on my experience so far.
Disclaimer: Although you can always feel free to send me your resume in order to apply for a job, I can not guarantee that we actually have an opening.
We need someone, but who?
Usually it’s obvious there is a need for someone extra on a team. Everyone is busy, yet the back log keeps growing. The problem is, getting the right person for the job is not as simple. There are all kinds of things to think about when hiring (or looking for a job, for that matter). Some of the questions that I think need answering:
- What is the level of experience and knowledge needed?
- How would I describe the role we’re trying to fill?
- What is the type of person we are looking for?
- What will the job look like in, lets say, three years?
These are obviously generic questions and there are also some more specific questions to be answered, but lets have a closer look at each of these questions.
What is the level of experience and knowledge needed?
This is obviously the single most basic question one can ask about a job. However the level of detail and the correctness of the answer is imperative for a successful cooperation between employer and employee. Obviously the employee needs to have the experience and knowledge needed to actually do his or her job. But the world doesn’t end there.
Hire someone who can barely do the job and you risk ending up with someone who’s frustrated, or spending loads of time and money to get the person in question to actually do their job.
Hire someone who over qualifies, though, and you risk boredom and a very short lived (and therefore expensive) cooperation.
So judging the level needed for a job is crucial.
How would I describe the role we’re trying to fill?
Having an accurate description of the role you’re trying to fill is again very important. Especially when hiring a developer this description goes a lot further then just saying: “we need a dev who can do tech A, B and C”. You should also know what you expect in terms of involvement in the team and the organization. Obviously this also depends on the kind of organization you’re in and on how the team is organized.
Getting this information across during an interview seems trivial, but without preparation it’s nearly impossible to do right. This becomes even more tricky when the demand for certain people goes up. At that point it becomes important to ‘sell’ the opening you have to candidates. Obviously you shouldn’t over do this. If it doesn’t fit, it doesn’t fit and you should not do business. It’s in the interest of both parties to determine if the candidate is suitable for the role. However, when doing an interview you should be prepared to move away from the ideal and look at options for making a role fit for a candidate.
Knowing what you’re looking for and knowing the options you have to adjust to a candidates needs is important, especially if you have a limited amount of candidates.
What is the kind of person we are looking for?
Off course things don’t end with can and will the candidate do what you need him or her to do. Making sure the candidate will feel at place in the organization and, more importantly, in the team is very important. An important point here, is to be aware of the culture, size and maturity of the organization and the team.
Look at what type of companies a candidate has been working and ask for an opinion on some of them. This should give you a picture as to what the candidate is looking for. It is also a good idea to describe the ‘soft’ part of the company to the candidate.
The point here is that having, for example, a very formal character in an informal organization is going to create friction and both parties will suffer.
What will the job look like in, let’s say, three years?
Let’s face it, you’re not going to hire someone to let them go again in a year. It would be costly to do so. So you should be thinking ahead. Where will this person go after a year, two years, or three years maybe?I picked three years, as this is, in my opinion, as long as you can somewhat realistically make any plans for, especially in IT.
It is important to have a plan as this will make a difference in who you hire. Also, a good candidate will ask about opportunities for him or her to grow. Make sure you have a story, but also be prepared to be creative with it. You might need to make adjustments based on the candidates possibilities and preferences.
Conclusion
Obviously there is a lot more to think about when hiring a new developer. The most important thing I think you should take away from all this, is that you should spend time planning and making sure you know what you’re looking for.
If you have any thoughts or questions on this, please leave a comment below. If you live in the Netherlands and are looking for a job, leave a comment with your email address (I won’t publish it), contact me at LinkedIn, or send me an email: jvandeveen at gmail dot com.
Posts
