An overview on what to do when hiring engineers

1. Hiring a developer: step by step
debugging
lcerveau@nephorider.com

2. Foreword
• Some part of this talk are specific to the French
situation of mid-2014
• Having been on both sides, I am biased in all
cases
• No name will be quoted (companies,
recruiters…) but all data come from true
examples

3. In a world of technical demand…

4. Cold facts on the problem

5. Recruiting = match making
Need Person
Need Competences
Hiring Person Candidate

6. !
Start-up context
• Money issue can change from one day to
another: Ship a product or build a team? Short
term need versus long term people.
• All VCs say they look after the team. Fashion
sentence or reality ? When raising money they
may enforce some hiring “you get this amount
when you get a CTO”
• Timing can be difficult. A possible answer is “do
job interviews all the time”. One, it gives
practice, second it creates a network, third it
helps you keeping a view on your needs

7. Parameters for a search
• How to search : direct, word of mouth, recruiter,
interns and students?
• Type to search: Contractor or employee?
• Who to search: junior or senior?

8. How to?
• Words of mouth and “personal contact” is IMHO
the best. But be careful of “clans” and “biases”
• Using recruiters implies more cost, but with the
hope of less time
• The recruiter problem: how to reduce the signal
to noise ratio? Do not forget, they have people to
be hired. But if the SN ratio gets higher they may
become precious allies.

9. Students hiring
!
• Starts usually with internship. Requires a certain
level of dedication. Do not hold yourself!
• Doing it well may imply that so much confidence
is taken bt the intern/student that she/he leaves
for a better place. See it as a success, really it
is.
• Have no mercy if it does not work. This can be
tough but hiring is also about making decisions

10. The “plumber” effect
• Apply to plumbers, but also electricians,
software engineers, car dealers, lawyers…
• More dangerous for contractors than employees
• “All was badly done. I have to redo a good
chunk of it before I can do my job”
• Ask for “english spoken” precisions, and what
would be the next steps or do not hire

11. Contractor/Employee
• When hiring a contractor especially senior, be
clear on the expectation “I pay you not only to
do a task but possibly to lay down foundations”
• Confidentiality and discretion with employees is
required. Stay in your role, on both sides.
• Plan the conditions of contract ending from the
start
• Be prepared to end fast

12. !
Contractor/Employee
• Think about building a team. Refer to the
Dreyfus model of skill acquisition.
• Decide what should be your team level. Never
forget: simple arithmetic counts. The “level” of
your team may not be the “level” of the “best”
employee.
• Employees talk (wages, opinion on decisions):
be fair all the time and explain it

13. !
WYPIWYG
• What you pay is what you get
• We are supposed to have a lack of engineers.
Basic market law applies. Good ones are
expensive… and may not on the market
• Let’s switch to the side of the one to be hired

14. Contractor
Price
Pay for Insurance
Pay for standard engineers
Pay for code writers
Pay for arms
(Paris 2014)
1200 €/day
800 €/day
200 €/day
Pay for software product doers
450 €/day

15. Contractor
• It’s like buying a pair of shoes. Buying bad ones only
make you pay twice. Buying a trademark depends
on the current shoe-CEO (consulting companies)
• Exception exists but those are exceptions! If you find
a real good contractor for a cheap price, think he
knows it and does you a favor for reason X
• In the Bay area multiply by > 1.5 (in dollars)
• Mistakes happens, those are the rules of the market.
Try many.

16. Employee
• Example of a junior engineer
Junior startup Paris 38/45K€
Junior Consulting/Big Company
Paris or East Europe startup
(Germany, Switzerland neighbors)
42K€/50K€+ Bonus
Junior Well known Startup SFO 90k/100K+stock
Junior Gross Boite SFO 100K-115K+stock

17. Employee
• Good senior in Paris can easily be > 70K and
way higher.
• Replacing money with equity has to be thought
In my opinion, it is a source of problem
• A fair market is the one where what is found for
the value corresponds to what it means. But it is
easy to become unfair; did you say Bay Area
sometimes?
• People know they can move. Play the game of
“trial period” (especially in France). Price are
likely to rise again

18. The ultimate dev recruiting
guide : Smart & Get things done

19. Preamb
• I have no connection to the author, Mr Joel Spolsky
• I hope he does not sue me for quoting his book!
• This book is the only one that should be read before
hiring developers. All is here!
• It can be read in a couple of hours, so re-read it
regularly

20. The book

21. Without quoting all books
• Now I will quotes a few excerpts and discuss them
• This talk is already influenced by this book
• Book is more on long term employee hiring
• Really you should buy it (did I say it already :-))

22. Philosophy
• In principle, it’s simple. You’re looking for people
who are
1.Smart
2.Get things done
• The real goal for software companies should be
converting capitals into software that works
Best working conditions -> Best programmers ->
Best software -> Profit

23. What you pay ?
And in fact, the conventional wisdom in the world of
copycat business journalists and large companies
who relies on overpaid management consultants to
think for them, chew their food, etc., seems to be
that the most important thing is reducing the cost of
programmers
…..
Essentially design adds values faster than it add
cost.
Or roughly speaking, if you try to skimp on
programmers, you’ll make crappy software and you
won’t even save that much money

24. Measurement
…
There’s nothing to see here and that’s the point. The
quality of the work and the amount of time spent are
simply uncorrelated.

25. Interviewing
• I can also tell you from extensive experience that if
you spend less than one hour on an interview,
you’re not going able to make a decision
• The third and final part of the interview is to let the
candidate interview me.
• Even though only about one in three applicants who
make it to the in-person interview stage passes all
our interviews, it’s really important that the ones who
do pass have a positive experience.

26. Developers
• On thing programmers pay close attention to in the
day of interviewing is the people they meet. Are they
nice? More importantly: are they smart?
• (Programmers) don’t care about money actually,
unless you’re screwing up on the other things. If you
start to hear complaints about salaries where you
never heard them before, that’s usually a sign that
people aren’t really loving their job
…
That doesn’t mean you can underpay people,
because they do care about justice

27. Practical job interview

28. Create a fixed frame
• Have more than one person interview the
candidates.
• I prefer when the first is the team leader/manager.
(but some prefer differently).
• Avoid overlapping exercices. Prepare with your
team
• Do not wait to provide feedback, especially in case
of rejection. Be honest with the candidate

29. Resume screening
• Difficult to get an idea of what the person is able/
worth. Look instead for hints : number of years
versus number of known technologies, words used
to describe and experience…
• In case of doubt, keep or do phone interview.
Personally I often send a technical short
questionnaire (some disagree with this practice)
• Read a lot of them!

30. Resume samples

31. A scenario
• 10 minutes: introducing the company and myself.
Explaining the interview process and what is the
goal :”we will see if it can match”
• 10 minutes: let the candidate give “his vocal version
of his resume”. Could be also something like “tell
me about your last project”
• 30 minutes: exercices (2 to 3)
• 10 minutes : let the candidate ask yourself
questions. If she/he has none ask “what did you
think of this interview”
• 5 minutes: debrief. If this is “No hire”, say it now

32. Exercices
• 2 to 3 of them, each one has a goal. Explain to the
candidate what are those goals
• Simple computer exercice. See if it is done fast and
with all attention. If a simple exercice is getting into
a nightmare, this is the only case where I would say
“OK this will not work”
• Then more something “do you have a complete
view of how something works” that goes into “Can
we talk about a technical problem”
• Finally maybe one of those “logical/invent” stuff.
More also to see what discussion is possible

33. End of the interview
• Simple decision hire or not hire (We’ll see later in
case of real real real doubt). If simple doubt no hire.
• Some interviewers may have a veto right.
• Direct rejection must be explained directly. It is rude
to send someone home and then send one of those
impersonal rejection email
• If multiple interviewers, say “we’ll debrief and get
back to you ASAP” … and do it.

34. The real real real doubt
• Usually at the beginning of a startup. Not enough
people to interview the candidate and still some
uncertainty of what will be done
• This is not to “give a second chance” when
someone has failed. More about “I am not sure
about what role I need in priority”
• I usually ask them to do an exercice and write some
code. Personally I find this useful.
• Other may think differently and reject directly

35. Post hire check list
• Do 1-1 meetings (More US than European). This
avoids isolation
• If this is not working : fire is usually the only option.
All others are about loosing time.
• Never think a situation is eternal (trial period in
France). It can take a few months to really
understand someone, but make sure you do not let
a situation go bad because of refusal to deal with it.

36. Interview samples

37. Thank You!