Alex Collins is a enterprise Java developer and currently works in the UK. He has worked in the insurance, publishing, telecoms and supply chain. In his spare time he codes in Python, Clojure and Scala (but not at the same time) and enjoys a multitude of sports. His catchphrase is K.I.S.S! Alex has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

Finding the right developers

10.10.2010
| 4481 views |
  • submit to reddit

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.

Knowledge

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. 

Be vigilant

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?

 

Published at DZone with permission of its author, Alex Collins.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Arul Kumaran replied on Wed, 2010/10/13 - 1:37am

Good discussion. To some extent through word-by-mouth. You still have to interview and so on. A number of How would you go about .... type of questions.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.