Archive for the ‘Hiring’ Category
I’ve been in India for around 4 months and in that time I think I’ve probably interviewed more people than I have in the last 4 years.
Over this time I’ve come to realise that the two main things I’m looking for in candidates are passion and ability to communicate effectively.
It’s relatively easy to pick up on whether someone is passionate about what they do in a conversation or while pairing with them but I find the communication aspect a bit more tricky.
I’m typically trying to see whether the candidate can explain things at various levels of abstraction, moving up and down the levels as appropriate to get their point across.
With some people it’s really easy for me because they’re able to do this flawlessly without much feedback from me about whether I understand what they’re talking about and if they need to reframe.
However, in the majority of interviews I end up in the situation where the candidate perhaps isn’t explaining something in a way that I can understand.
Either they’re giving way too much irrelevant technical detail or end up beating around the bush at a high level and not really answering the question.
If this situation happened on a team I was working on then I would certainly consider it my job to try and guide the conversation so that we could both get what we want out of it.
After all communication is very much a two way thing.
In the interview context I do the same thing but I would expect the candidate to pick up the hints that I’m not understanding them easily and adjust the way that they reply to future questions to take that into account.
If they don’t seem to take that feedback on board then it’s quite likely that I’ll make the judgement that they’re not able to communicate very clearly and we won’t proceed with the candidate.
I’d be intrigued to hear the approaches others take because it does feel a little bit like I’m doing it wrong in this respect.
I recently came across this post which speaks about the desire of recruiters to put candidates into technology specific boxes when it comes to describing their experience.
I guess this desire is backed by humans’ need to see the patterns and similarities in data and having someone who doesn’t quite fit into a generalised box makes it more difficult.
I have worked on projects in Java, C# and a bit of Ruby so I do agree with most of the points with regards to language specialisation and as Jay Fields points out it is actually beneficial to diversify your experience to improve yourself. I have certainly come across some interesting ways of doing things from my so far limited experience with Ruby.
The one part of the post I disagree with is the following:
Never mind that years of experience will never really make you a better developer. Either you can code or you can’t. If you’re a good developer, you’ll be just as good with one month of Java experience as with 1 year.
While I still have a long way to go on my software development journey, looking at what I can do now compared with what I could do two years ago is not even a contest. It also doesn’t do justice to colleagues of mine who are orders of magnitude better than me, having constantly found ways to improve themselves over time.
I think perhaps the author was thinking more along the lines of ’1 years experience repeated 9 times does not equal 10 years experience’. I think it’s fair to say that some of the best people I have had the chance to work with have not repeated this pattern.
If we are constantly looking for ways to close the gaps in our knowledge and looking for better ways to do things then we are certainly going to get better. On the other hand doing the same thing over and over again for several years probably won’t lead to a significant improvement.
Using different languages is certainly one way to improve but I don’t think we necessarily need to change the main language that we work with in order to gain all the benefits of doing so.
I have used both Ruby and Erlang, albeit briefly, and there were certainly lessons learned from my experiences that I can apply to my work in Java and C#. For example, using Ruby has shown me the value of convention over configuration and keeping code simple where possible, while my experienced with Erlang have shown me the benefit of having no state and have led me trying to keep my objects as immutable as possible.
As long as we reflect on our experiences and improve the way we work from as a result, having experience in several different languages is certainly beneficial.
There are some other ways that we can improve as well.
Gaining experience with projects at different stages is another way to sharpen the tools in our software development toolkit.
I have worked on projects which have been going for a couple of years, rewrites of existing systems and projects which are just starting out. The skills are similar but not exactly the same.
Early on we have the opportunity to shape the system and indeed the code and a lot of the work revolves around getting environments set up, configuring 3rd party APIs to work with our system, setting up the build etc.
Later on in projects the skills are around working out how to add new code without breaking existing functionality. This may involve working out how to test around legacy code, which is a skill unto itself.
Gaining experience in different roles within a team is another way to improve ourselves.
While I am not sure that this extends to everyone on a team trying out each of the other roles, I have certainly heard developers speaking of the benefit of working in a QA role for some period of time and personally I have spent time working primarily on build and deployment and seeing the world from that angle.
A colleague of mine on an earlier project always advocated the benefits of developers having to work in production support so that they could appreciate the value of putting useful logging into the code. I believe that this is something that is done at Amazon – you are expected to support your application in production, it doesn’t just get thrown over to production support.
I’m sure there are other types of experiences that we can gain, but the best people I’ve worked with have demonstrated a superior ability to solve problems, integrate systems, explain ideas to others, write code and so on.
It’s not the number of years, it’s what you do with them that makes the difference.
It seems programmers are taking a bit of a hammering this week!
Kris Kemper talks about the Net Negative Producing Programmer referring to a paper linked to by Jay Fields, concluding that the code submission is very important in helping to distinguish between good and bad candidates.
Now I probably haven’t done as many interviews at ThoughtWorks as Kris has but from what I’ve seen of the recruitment process it seems to be more focused on ensuring that potential hires culturally fit into the organisation rather than that they write the best code that anyone has ever seen. Clearly a level of ability in coding is important for a Developer but I believe that the ability to communicate and collaborate with your colleagues is even more important. It’s quite a rare situation in software development where you have to develop something completely on your own, and even if it were to happen you would still need to communicate with your customer even if the development effort was solo.
Bruce Eckel has an interesting post about hiring technical talent where he lists several criteria for hiring people, ending on the note that organisations should not hire people he terms as ‘toxic’. A toxic person according to his description is someone who has some kind of quirk that causes destructive behaviour. In other words someone who is likely to destroy the morale of any team they are placed in by their actions.
I think ThoughtWorks are getting the balance right in hiring very talented people who are able to collaborate with each other to solve problems. One client even said to me that they did not understand how every single ThoughtWorks person they met was so nice. I think that is a glowing recommendation for looking at the overall personality of candidates and not just raw coding ability.