Hiring senior developers

Finding good developers is hard.

I don't know about the US, but there seems to be a genuine skills shortage in London. I have seen technical tests and interviewed literally hundreads of people over the last few years and only a handful were good enough for a job.

There were several people who passed the online technical test, but when faced with a technical phone interview, the large gaps in their knowledge quickly become apparent. Of the few that make it through to a face to face interview,  a lot seem to have, how shall I put it, poor communication skills. I'm not talking about the standard interview nerves everyone gets either. I am talking about a genuine inability to articulate them selves. If you can't speak technical to me, the chances of you explaining issues to a pm or client are minimal.

Harsh, but true.

Our dev team

The team on a project is generally made up of the following people.

Technical Director:

Responsible for overall technical output of Aqueduct

Lead Developer:

Responsible for and leads projects technically; they also mentor and lead other developers

Senior Developers:

Ensure projects are developed to the best technical standards

Senior Front End Developer:

The Front End Team is responsible for Aqueduct front end output quality and adherence to W3C  and government standards

Dedicated tester:

The tester is the lynchpin between the PM’s and the developers, the tester is responsible for the writing and execution of ad-hoc, automated and regression tests on projects to ensure the code is delivered with the best quality possible without jeopardizing existing code.

Methodology

The majority of our big projects follow the scrum methodology.  I won’t bore you with the details of scrum, as there are various good sources around the Internet.  I’ll just provide some of the more interesting things we have learnt from using it for a few years.

1) A one-week sprint is not long enough.

No matter how good your intentions, you never end up with anything finished in one week. The overhead just becomes too much.

2) Hold a pre-planning session.

On big projects, planning the stories for a two-week sprint can become a chore and people get bored very quickly. The lead developer on the project should sit down with the PM before the session and write the stories and the basis for the acceptance criteria.  Planning sessions will go much quicker after this.

3) A developer must commit to a story.

When pointing a story, the developer doing the work must commit to the work being done. The PM should have no influence on how long story X will take. // Need to explain why

4) Make your project manager / scrum master read the  Mythical Man Month .

Just because you add a developer to a team, does not mean you will finish it quicker.  We generally find that you shouldn’t have more than 3/4 dev’s in one team. It just becomes onerous after that.

           

5) Ensure the Lead Developer on the project has an understanding partner!

            Enough Said. (Sorry, Hazel made me write this.)