Hiring a developer: step by step debugging

Preview:

DESCRIPTION

An overview on what to do when hiring engineers

Citation preview

Hiring a developer: step by step debugging

lcerveau@nephorider.com

• 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

Foreword

In a world of technical demand…

Cold facts on the problem

Recruiting = match making

Need Person

CompetencesNeed

CandidateHiring Person

!

• 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

Start-up context

• How to search : direct, word of mouth, recruiter, interns and students?

• Type to search: Contractor or employee?

• Who to search: junior or senior?

Parameters for a search

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.

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

• 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

The “plumber” effect

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

!

• 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

Contractor/Employee

!

• 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

WYPIWYG

Contractor

Price

Pay for arms

Pay for code writers

Pay for standard engineers

Pay for Insurance

(Paris 2014)

200 €/day

Pay for software product doers

450 €/day

800 €/day

1200 €/day

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.

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

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

The ultimate dev recruiting guide : Smart & Get things done

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

The book

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 :-))

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

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

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.

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.

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

Practical job interview

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

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!

Resume samples

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

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

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.

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

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.

Interview samples

Thank You!

Recommended