Finding the right developers
Finding the right developers
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
If you happen to sit as a senior developer you may be asked to help find new talent for your team; here are some thoughts on how to best approach this empowering challenge.
The most common scenario where you're brought in to join an interview is when a large project is on its way and your team needs to expand to cover the everyday and the new development. Consider this as your chance to make a visible change on your team from a non-programming perspective.
One place to start - as with many things - is a plan. Look at what you need to fulfil the requirements of the future project. Given the technologies you need, it's a good idea to - if you have it - note down what aspects of the technologies you feel are important to your team. Let's take Spring as an example;
Breaking down the necessary components of your desired framework:
- IoC - basic aspect of Spring
- MVC - Model View Controller framework for simplifying web development and ensuring consistency and reusability
- Security - a role based framework ensuring reliable and safe implementation of sensitive and critical aspects of a system
Knowing what technological experience you need and what aspects of the framework you require, you now have a start in what you can look for. Once we have this we now need to know how to identify the good knowledge from the rehearsed.
For each of the technologies or skills you need from your developer, break it down and have an idea ofwhat you need from each.
What not to do
It is common when interviewing to look for similar habits of your own in your interviewee. It may seem to make sense to hire someone that holds the same skills and habbits that you do, as that is what works for you. This is a poor thing to do; a good strong team has a diverse and differening set of members each with their own strengths and weaknesses that compliment each other to ensure as many perspectives are covered. Having a team full of highly analytical developers would mean you'd have a very low yield; you need 'doers' that write code well and quickly, but don't necessarily spend as much time analysing - a delicate balance however. Similarly if you had a team full of code monkeys you'd have little analysis and design going on which would result in poorly maintained and inflexible code.During the interview
The most important thing to do when interviewing a fellow developer is to get them to not only talk about how they write but to get them coding in front of you. The aim is to see how they structure classes, witness their efficiency in their chosen IDE and their general saviness. Observe them making their decisions with interfaces or classes and question the decisions they make as they make them: force the developer to justify their choices. This allows you to get into the inner workings of your prospective colleague and to understand - at least to some extent - their thought processes.
You shouldn't stop at understanding their creativity however. Problem solving is a critical aspect of programming and so it's paramount that you propose a scenario and get the developer to articulate how they would investigate the issue. Try and get them to go through the process step-by-step and see how they solve your conundrum - make sure they include the steps you'd take for granted.
Some candidates you come across will hold a text book CV. All the right technologies, plenty of years on the clock, lots of varying challenges for a number of different clients. All is not what it may seem however, as plenty of the aforementioned desirables could be easily explained. All the right technologies? Anyone can read a book and memorise the fundamentals and then recite them on command. Lots of varying challenges for a number of different clients? They could just have had short contracts - 3 to 6 months - in which they performed mundane tasks and their clients let them go due to poor performance. Point being, the aim of your discussions with the candiate should be to glean opinions from their experience, not the text book answers.
Have you had any experience with interviewing? How have you gone about it? How does your organisation find new talent?
Opinions expressed by DZone contributors are their own.