Some thoughts on the recruitment of great software engineers, how refining your process can help, and what the fundamental problems and contradictions of IT recruitment seem to be. The importance of coding and screening tests is demonstrated, and there some tricks of the trade shared too.

1. Recruiting the right people quickly:
Attempting the impossible!
Ashley Frieze (ashley@incredible.org.uk)
November 2014

2. Recruitment is a contradiction
• We should hire fast
• Don’t let a project get delayed
• We want the best people
• Better not to hire the wrong person
• It can hurt more than waiting

3. Recruitment is a contradiction
Graph of perceived quality of candidate vs speed of recruitment
Great
Quality
Oh dear
Sluggish Impulsive
Speed of recruitment

4. Driven by our perception of the market
Great developers

5. Driven by our perception of the market
Great developers

6. Driven by our perception of the market
Not so great employed
developers
Great developers

7. Driven by our perception of the market
Not so great employed
developers
Great developers
Pas-sive
On the market
Some great candidates entering the market
Plenty of not great ones available to job seek

8. Driven by our perception of the market
Not so great employed
developers
Great developers
Great
Not so great
Great candidates get jobs quickly
Not so great ones stay in the market longer

9. Contradiction version 2
• Choose carefully
• Avoid the likelihood that your candidate is not so great
• Act quickly
• If you don’t take a great candidate, someone else will

10. How can we choose the right candidate?
• Pick one at random and hire them outright
• Guarantees you’ll only hire lucky people

11. How can we choose the right candidate?
• Go on recruitment agent’s recommendation
• Now THAT is ridiculous
• Keyword matching at best

12. How can we choose the right candidate?
• Use the CV
Save me from the long winded… I enjoy a nice skills matrix
Lorem ipsum dolor sit amet, consectetur
adipiscing elit. Curabitur elementum risus
quis sem lobortis HTML. Morbi volutpat
facilisis quam at tempus. Donec
scelerisque justo ut nunc maximus, eget
tincidunt JAVA accumsan. Vivamus nec
blandit ante. Nulla laoreet eros in nunc
sodales hendrerit. Morbi C++ diam in
nunc efficitur congue. Phasellus turpis
risus, maximus vitae mollis ut, molestie
eget urna. Fusce sit amet orci ac augue
condimentum auctor eget eget elit.
• HTML, CSS, Javascript (5 years)
• C++ (9 years)
• Java (5 years)
• TDD, BDD, CI, CD
• Design Patterns
• SQL (MySQL, Oracle, Toad)
• IDEs (Eclipse, IntelliJ, Netbeans,
Microsoft Visual Studio)
• Word for Windows 2.0
• Punched cards
• Binary
• PuTTY
• Yes, but can you write great software?

13. How can we choose the right candidate
• Test them out
• Without slowing the process down

14. The Eureka Moment
• Hiring is a process problem
• So use a value stream mapping analysis

15. Our old process
CV
Notice it (3 days)
Read CV and email decision (10 minutes)
Send them coding
test (1/2 day delay)
Coding test comes
back (3 days)
Review test (10 minutes)
Delay organising
phone interview (3 days)
Phone interview (30 minutes)
Organise face to face interview (6 days)
Interview (2 hours)
Duration – 16 days
Value adding time – 2hrs 50m
Efficiency – 3%

16. Process after modification
CV
HR read CV and also
send screening link
(10 minutes)
Send both to manager (5 minutes)
Wait for screening result (1 day)
Review screening test (5 minutes)
Delay organising
phone interview (2 days)
Phone interview (30 minutes)
Organise face to face interview (4 days)
Interview (3.5 hours)
Duration – 7.6 days
Value adding time – 4hrs 20m
Efficiency – 10%
Double the speed
Three times more “efficient”
Most of the delay is unavoidable

17. Full disclosure
• It’s better now
• It’s not perfect
• It’s not quite like this now, either
• Some corporate wrinkles have entered the process
• The approach of analysing and refining the
process really worked for us

18. What to test: Screening
• A screening test is better than a CV or
application form
• Make it a question of opinion
• No Googling
• Read between the lines
• Find people’s communication style
• Find passion/bug-bears/missions

19. What to test: Coding
• Need to know if they can really write code
• Coding test is a
massively good idea
http://www.joelonsoftware.com/articles/fog0000000043.html

20. What sort of coding test?
• Not a hard test
• A fail can be inconclusive (“well, it’s quite a hard test”)
• Check it’s easy to pass
• Road test it
• We had “Output all numbers 1 – 999,999 as words in
English”
• Some solutions took 20 hours!

21. What sort of coding test?
• Something easily done in half the time
• Don’t test oblique framework knowledge
• See if they see code your way
• Coding style
• Really challenge them with a code review
• Ability to see alternatives in discussion
• We do our coding test in 90 minutes at start
of the face to face interview
• Some people leave the building after 15 minutes’ code
review

22. What sort of coding test? – Even better
• Provide automated tests
• Provide ready-made skeleton project
• Checks the speed of getting into your codebase

23. Example coding challenges:
• Work out a few different statistics on an array
• Put some data into a collection and then retrieve
certain values
• Implement a design pattern
• Implement a simple string conversion algorithm

24. Good coding challenge: Fringe benefit
• “I really loved your test – it impressed me that
you cared enough about these things to give
me such a challenge”
• Appeals to the right sort of candidates
• Someone who has passed your test may be
more inclined to accept an offer
• Stockholm Syndrome?

25. Finally
• It’s not all about the tech
• Hire on skills, fire on behaviour
• Remember to ask some human questions

26. Summary
• Not cool
• Recruitment agents
• CVs
• Most candidates in the jobs market
• Delays that lose great people
• Cool
• Speed up your process
• Add enriching screening/testing to it
• Act quickly for the right people
• Not covered
• How do we find candidates at all?