Archive for December, 2009

A Guide To Hiring Great Programmers

Monday, December 7th, 2009

There are a lot of programmers out there these days. Since the explosion of the PC and then later the Internet there has been more and more people learning to programme in a computer centric world. But how do you go about finding the best ones?

I have had to hire many programmers over the years and I tend to find that the really good ones have certain things in common. I have a three step process I go through now to find the best people with the best fit for the company.

  1. Finding great people and attracting interest in your position
  2. Working out if they are the right person for the role
  3. The interview

Step 1: Finding great people and attracting interest in your position

The key to attracting great people is having a great place to work – that means the company culture, offices, people and the work you produce. Companies like Google and Apple have no problem finding the best people as they are like a recruitment magnet, people fall over themselves to work there. Now your company may not have the same size and appeal but every company have a unique culture and soul. You need to make sure you sell the full package to a potential recruit more than just their job role. Most great programmers love to challenge themselves and solve the big problems, so you need to let them know what kind of projects they will be working on.

Try not to use an agency if you can help it; I have rarely had much joy with agencies, they are incentives to find candidates but not the best candidates. It is much better if you can find someone who has been recommended, someone who worked for you as an intern, perhaps someone you have come across on a forum or an open source project. There are always many routes to finding great people.

I read recently that the 37 Signals team and the Hash Rocket team pretty much only recruit people who they have worked with, so freelancers or contractors who have worked on joint projects with them.

Step 2: Working out who is the right person for the role

Now hopefully some CVs and emails enquires are coming in and you need some way to filter them. Of course the CVs you see are important but qualifications and work history do not give you the whole picture. Have a look at the person’s blog, portfolio site, twitter account etc. Google their name to see what comes up. It is interesting if they have been posting and promoting themselves within the web community.

When I am sifting through potential people I am trying to answer the following questions:

Can they get things done?

The most important thing for me is that they have the focus, resolve and energy to get projects done. That is not to say they have to do this all by themselves but most of the time they will be working alone. The way to see if people can get things done is to look at their personal projects, open source projects, github repo, anything that shows they can see a project through to the end and not give up.

Do they have a thirst to learn new skills and technologies and can they pick things up easily?

All good programmers can pick up programming languages with ease, much like linguists can learn new spoken languages. There are people in my team who just have spend a few days learning a new language before they are off and running; PHP, Python, Lisp, ActionScript skills can be acquired with what looks like seemly little effort.

Do they challenge themselves in the projects and job roles they have had? Age is not a factor here as I know some incredible programmers who are right out of school and some who are further down the line in their career.

Are they passionate about the web, do they share things that they have learnt with you, do they keep up with the latest trends and news, do they read RSS feeds and listen to podcasts?

Are they an artist looking for beauty?

Attention to detail and the personal drive to write elegant, beautiful code. We all know that we have to write hacky, quick fixes some times but that should be the exception not the norm. If someone in our programming team tries to write some hacky code, it is usually picked up by the other developers even before it reaches me.

Good coding is an art form, as you move from planning, to psudo code, to basic, and then elegant scripts, refactoring along the way. I have said it before but attention to detail is key.

Have a look at some of the person’s open source scripts or code examples on their blog. Are they a coding artist?

Now once you think you have found the right person you can move onto to the interview process.

Step 3: The interview

So once you have found some potentials stars you need to get them in to meet them in person.

Telephone chat

First of all I have a quick chat on the phone, no more than ten minutes just to get a feel for the kind of person they are. This is simply a getting to know you chat there are no interview questions, I am simply chatting to them as if I had been introduced to them at a dinner party.

Personal chat

If I think they are a good fit with the culture and think their personality would fit in with the company I invite them in for a chat in person.
This is a very informal event, I do not ask interview style questions or sit behind a big desk. This is one person talking to another person. I try to make them comfortable as you will never get to really see what they are like if there is tension in the air.

Are they a great communicator?

I don’t buy the stereotypical picture of a nerd programmer who is devoid of social skills. Programmers have to work as part of a team, they have to disseminate specs and write documentation, write comments, they also have to keep the project manager or tech lead informed of progress. There are often brainstorming and strategy meetings, code reviews. These all requires great communication both written and verbal. I do not mean they have to be an orator but they have to be able to clearly communicate their ideas and opinions.

Do they know their stuff?

You have already had a look at what they can do, but by talking to someone face to face you can see if they really know what they are talking about. Try to ask for specifics as that will show if they actually understand what they are talking about. The best people ask questions themselves relevant the the conversation and are keen to share opinions and throw ideas around.

Give them a real project to solve, not a pointless test

I have done some tests in corporate interviews in the past and they are pointless and not relevant and I think they should be scrapped! I like to get the person to do a small self contained project and then peer review their code. I never compile or test the code I only want to see the style and the methodology. This usually takes the form of a current project we have in the office. They can do it in their own time and take as long as they want this is not an exam. You do not code under time pressure in real life (well not often anyway!).

If they have got this far then they are probably a superstar, so hire them quickly before someone else does! It might seem like a lot of time and effort but creating the right team is the most important thing for your company and both you and your team deserve to have the best people.

One last sanity check is that we have a one month probation period (which we should really never have to use) just to make sure that we all work together like a well oiled machine.

I would love to hear what other people do as part of their hiring process. Especially how they attract and find the best people to start with. Any thoughts?

A Client Management Masterclass

Wednesday, December 2nd, 2009

Today I was given a master class in client management.

I went to meet a client of ours who was not happy with the final quality of the creative output of our work. They had called the meeting as they were thinking of ending the project and cutting their losses.

By the end of the meeting not only were they happy, they had renewed confidence in our abilities and were happy for project to continue. How did this happen? The reason it happened is that I had a secret weapon in the meeting. I was joined by one of my directors at Busara, Pier Bracher who is a master of client management.

I did not say that much in the meeting and watched as Piers led the client through a journey:

Work out if the relationship is still salvageable

If the client does not want to at least try to work things out then is it is a very short meeting, there is no point in talking and the meeting is over. It is then time to send the lawyers in. But on the other hand if they do want to work together that is the first step and this creates some common ground to work on.

Where was the breakdown in the project?

Next you need to find out what the root problem of the relationship breakdown was. This is done by asking lots of questions and really listening to what the client has to say. Try and read between the lines, we were lucky the client was very upfront about the issue; there had been a misunderstanding when it came to the brief and all the issues stemmed from there.

Do not assign blame or dwell on the problems

Now that you know what the issue is, do not assign blame, do not dwell on the problems. It is all about rebuilding trust and convincing the cleint that you can deliver. Trying to assign blame does not help anyone and will only hurt the relationship further. In most situations there is probably fault on both sides but that is not what you need to focus on.

Accept responsibility and create confidence that you can deliver

You need to accept responsibility for the problem and create confidence that you can deliver. Now you know what the problem is you need to work hard to convince the client that you can solve it and exceed their expectations.

Focus on the plan and what is going to happen next

Explain in detail the plan forward, really sell the new plan and give hard deadlines on when things will be done. It is important to fix thing quickly and get back on track. By explaining the plan you are showing evidence that you can deliver. Reiterate where there is agreement and summarise regularly.

Deliver on your promises and over service

The final thing is the most important, you now need to deliver on your promises and over service along the way. If you can do that you have a very good chance of turning a bad situation into a good one.

Quite honestly there were times in the meeting where I had to bite my tongue as the natural thing to do is fight your corner and play the blame game but that does not help anyone.

The key is for you to rebuild confidence in your ability and show conviction that you can deliver on the brief. If you can continue to work together and turn the situation around you can often increase your standing in the client’s mind.

Technology Should Be Invisible

Tuesday, December 1st, 2009

One of my philosophies is that technology should be invisible. What I mean by that is that you could have an amazing algorithm or incredible platform but your user interface should be simple, intuitive and elegant.

Some of the best technology out there like the Apple iPhone, Google’s search algorithm or Flickr’s image processing are hugely complicated with thousands of hours development but the user interface is elegant. The user does not care how amazing your technology all they care about is performing their task quickly and accurately.

I have been dealing with a lot of hardcore developers recently and I am finding that sometimes they can overcomplicate their applications to show off the complexity of underlying platform. You should always keep in mind your audience when developing an interface and make their choices simple and intuitive.