Steve Levy is an engineer and recruiter with 26 years of experience recruiting in tech sectors. He is the founder and organizer of tech user groups and blogs about recruiting on his website. Some of his advice includes assessing candidates by having them work with broken or obfuscated code, asking about their experience with legacy code, and focusing on both technical and soft skills during the interview process. He emphasizes understanding candidates' interests and building relationships within the developer community.

1. Steve Levy

2.  Engineer who crossed over to the dark side
 26 years recruiting in tech sectors
 SME sourcing, engaging, recruiting, retaining
 Founder & Organizer of tech user groups
 IN: https://www.linkedin.com/in/stevenmlevy
 Twitter: @LevyRecruits
 Blog: http://www.recruitinginferno.com
 Google me: steve-levy recruiting

3.  Read this:
http://www.joelonsoftware.com/articles/Guer
rillaInterviewing3.html
 This too:
http://www.fastcolabs.com/3015662/want-to-
recruit-better-developers-give-them-broken-
code

5. “Not answering when I ask for more specifics
about the kind of work such as tech stack or
interesting classes of problems. I get this one a lot,
and my goal in asking for more details is to find out
if I or someone I know might be a good fit. If you
refuse to say anything more than ‘uses Python’,
I'm probably not going to respond back.”

6. “Asking me if I'm interested in a job using a
technology that appears NOWHERE on my
resume AT ALL and yet clearly requires significant
expertise in the technology”

7. it’s not that difficult to understand

8. “When debugging, novices insert corrective code;
experts remove defective code.”
[know it, use it]
[listen to how people describe their projects]

9. “Java is to JavaScript what Car is to Carpet.”
[know it, use it]
[please don’t fake what you know if you don’t know]

10. “It's hard enough to find an error in your code
when you're looking for it; it's even harder when
you've assumed your code is error-free.”
[know it, use it]
[when assessing, consider using broken or obfuscated code testing]

11. “If debugging is the process of removing software
bugs, then programming must be the process of
putting them in.”
~Edsger Dijkstra
[know it, use it]
[ask for a developer’s reaction to this during the interview]

12. “Always code as if the guy who ends up maintaining
your code will be a violent psychopath who knows
where you live.”
[know it, use it]
[ask how they work with psycho-code]

13. “There is not now, nor has there ever been, nor will
there ever be, any programming language in which
it is the least bit difficult to write bad code.”
~Flon's Law
[know it, use it]
[always ask opinions about alternatives to existing stack]

14. “Most software today is very much like an Egyptian
pyramid with millions of bricks piled on top of each
other, with no structural integrity, but just done by
brute force and thousands of slaves.”
[know it, use it]
[legacy code is a reality that both exists and must be planned for]

15. “Any code of your own that you haven't looked at for six
or more months might as well have been written by
someone else.”
~Eagleson's law
[know it, use it]
[be careful of making recruiting decisions based solely on code repositories ]

16. “Good code is its own best documentation.”
[know it, use it]
[assess code tests with and without documentation]

17. best ingredients + best recipe + best chef =

18.  The People are the ingredients
 You must know their Likes, Dislikes, Quirks,
Cultural Differences
 Look for tools other than the hammer – because
not everything is a nail
 You don’t want to lead the horse to water – you
want to make them thirsty
 Most of all, be knowledgeable & personal

19.  They want you to be honest; never fake it
 They want to know the real job not the tasks
 They want to know the entire stack
 They want to discuss your problems – not get
grilled about contrived CS 101 material
 They want a real mentor
 They want to be heard once on the job
 They want to have an impact – that’s mine

20.  The 7-10 years problem
 Trusting self-assessment as a Rockstar
 Not asking to write the “right” code
 “Hire but not for my team”
 Ignoring spelling errors
 Not focusing on technical and people skills
 Fear of hiring someone better

21.  A/B Testing Your Process. How do you know
that it works? Or are you simply cutting &
pasting from a previous job?
 How We Really Work. Scrum, Agile, Waterfall,
Paired, TDD, BDD, Design Patterns: Do you
assess they way you really work?
 How Our Best Developers Work. Is this built
into your assessment process?
 Community Matters. Do you really care that
many want to be part of something even larger
than the company?

22.  360 Relationships. Are you building all
relationships into your process?
 Great Code. How do you define and “score” great
code? “We’ll know it when we see it”?
 What They Really Want To Do. Do you care
about what excites them? How can your company
help them achieve this goal?
 Use Humor. “If you had just boarded a plane and
discovered that your team of programmers had
been responsible for the flight control software,
would immediately disembark?”

23. 3Sourcing
Aevy
Dice Openweb
Entelo
Gild
Talentbin

24.  It has to be real life to be “predictive”
 Hire for performance: Hire skill, not school
 Code Challenges differentiate good from great
developers
 Hackathons are the new career fairs
 Since great programmers live everywhere, you
need to engage them everywhere

25.  What would you like to improve?