Hiring well

How you do hire the best people, in the most efficient way?

This question was the essence of a great conversation I had this evening with a young Agile Manager from a fast growing, Polish start-up. We're both in Bucharest for the grass roots Agile Lean Europe 2013 conference, so this will no doubt be one of many great conversations.

We compared notes and shared ideas. The take away was:

1. Attract the best talent. Through community involvement over a number of years, his company is way ahead in this area (thankfully they're in Poland, so not direct competition :). Joking apart, this reinforced the importance of developing and promoting your R&D Team as a brand - it pays off in the search for new talent.
2. Always phone screen first. If using agencies, have them do a pre-call, and get them to collect information to dig into on your own phone screen. Give the agencies a mix of open-ended and specific questions, e.g. "how to you learn?", "what have you learnt most recently?". Design these to give an early indication of height and cultural fit.
3. Show-me-your-code. If the candidate passes the phone screen, send them a coding exercise to complete. Their solution will give lots of insights, at very low cost.
4. Always meet face-to-face. If the candidate passes the coding exercise, then either do a Skype call (if remote working will be a significant part of the role) or skip straight to a face-to-face. The goal of the face-to-face is mostly to determine cultural fit. My friend put it this way: "only hire people you'd want to go for a beer with, so go for a beer with them". Our approach in more reserved England is a four-part face-to-face involving a code review and kata with an Engineer, a technical discussion with an Architect/Engineer and Engineering Manager, followed by a "cultural" discussion with a couple more Managers. The CTO often gets involved at this point too. A tour of Engineering is also done.
5. Use a tool that makes it easier to scale this process out to lots of people (in terms of both candidates and those doing the hiring). What was hilarious was that we both use Trello for this, and both have recently set up Zapier to allow candidates to be added by email (this was ahead of Trello's recent addition of their email-to-card feature).

Are you smart and can you get things done?

If you answer yes to both the above, and you've been writing fantastic web applications in Java or C# for the last 3 years, then please get in touch. I'm looking for exceptionally talented software developers (and testers) to join my agile team (in Basingstoke, UK).

Julian Treasure: 5 ways to listen better | Video on TED.com

Julian Treasure: 5 ways to listen better | Video on TED.com

Just watched this great video on listening. Julian provides five steps, of which I found the following useful:

1. Practice 3 minutes a day of silence.

2. Listen in a noisy environment - how many different channels of sound can you hear?

5. RASA - receive, appreciate, summarise, ask.

I'm a DHTC programmer

Interesting programmer personality test. My programming personality breakdown is below. Do you agree with this? What kind of a programmer are you?

DHTC

You're a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.

You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.

You work best in a Team.
A good group is better than the sum of it's parts. The only thing better than a genius programmer is a cohesive group of genius programmers.

You are a Conservative programmer.
The less code you write, the less chance there is of it containing a bug. You write short and to the point code that gets the job done efficiently.

Software development is like ... telling a story

Went North last weekend for a fantastic baptism in Glossop. Whilst waiting to join the M6 from the M6 Toll road, had an interesting conversation with my sons (aged seven and nine). They had been listening in on some work calls regarding some NAnt scripts that were playing up, and that combined with Vista's $10 billion development cost, led them to ask (for the nth time) what, exactly, I did at work.

Whilst trying to provide an understandable explanation, it struck me that the answer given can help measure the depth of someone's development background and experience.

The answer I gave (and sub-sequent cross-examination I endured) proceeded something like this:

• Child: So why did Vista cost so much to make?
• Developer: Because its a very complex system, that requires lots of (expensive) people to create.
• Child: Why is it so complex?
• Developer: <Sigh - here we go> Well let's imagine a story. A person (called a customer), tells you a story about what they want the software to do.
• Child: Uh-huh
• Developer: Software developers take that story and re-write it in a language that a computer understands.
• Child: What if the story is in French?
  
• Developer: That doesn't matter - developers use a "software language", like Ruby, which the computer understands and is written in English.
  
• Child: So what is a software language?
• Developer: Its like a normal language, with two differences: firstly, the language has a very limited vocabulary; secondly, it must be used exactly - no spelling, punctuation or grammar mistakes allowed.
• Child: So what happens if you make a mistake?
• Developer: The computer won't understand what you've told it.
• Child: Wow! Does that mean you have to get the story exactly correct, before the computer can read it?
• Developer: Weeeeell.... kinda.... Its more like the computer will do something different from what we asked it.
• Child: So why did Vista cost so much to make?
• Developer: <Sigh - lets try a different tack> You remember the story that the developer is translating?
• Child: Uh-huh
• Developer: Well, although the story is simple to the customer; to the computer, its hideously complex. So complex that no single person can understand it all. Therefore the story is divided amongst lots of people, who each attempt to understand bits of it. Its about managing complexity.
• Child: Uh-huh. Are we nearly there yet ...