Everyone sucks at interviewing. Everyone.

So...

 

Just.  Don't.  Interview.

 

 

 

Interviewing is broken.  Has been for years. This rigid commitment everyone seems to have to the standard resume/cover letter/interview system of hiring is just plain insane.

I've been fascinated by hiring processes for years.  Hiring great talent is such a massively tough challenge, and I see so few companies that do it well.  Even the best companies hide a deep dark secret: their hiring processes don't predict success accurately.  It's long been whispered that Google's sophisticated HR scoring system has little correlation with an employee's success at the company.  One management consultant for a top firm told me recently that, despite incredible efforts to improve hiring analytics, the best predictor of success for junior employees was still just their SAT scores.

Paul English, one of the absolute best said this about his style of hiring at Kayak:

 

"At times, I've fired maybe one out of every three people I've hired. That might make people think I'm bad at hiring, but I think I'm quite good at hiring."


So, Paul English, one of the most respected out there, gets 1 out of 3 wrong?  Shit.  This stuff is hard.  But Kayak is at a stage of development where the organization can sustain the disruption of people leaving.  Most startups I know have such difficulty firing because everything is already so unstable.  Can't fire during a product launch. Can't fire during a funding round.  Let's give him 3 more months and see if things improve...

 

I don't claim to be good at hiring, but I do have a particular style that I learned from some advisors.

I never actually interview people.  Ever.

I think of hiring as mutual courting. The only way to court in a work setting is to spend time working together.  Whenever I'm thinking of hiring someone, whether entry-level or senior, we do a project together.  I pay them a reasonable contractor fee for the work, and I make sure it's the type of work that's easily definable, has clear deliverables, and lasts a few weeks.

Sometimes we do this process and the project goes outstandingly well, and we make a full-time offer.  Our ability at this point to define a job description and compensation package is remarkably easy.  We know what we're getting.  The employee is also motivated at this point because we've all proven ourselves to each other. He's learned the real strengths and weaknesses of the business and of working with the team.  A decision to accept a full-time offer at this point is a well-informed one.

Sometimes, the project turns out only so-so, at which point we wish the very best to the applicant and do whatever we can to help him find a role that is perfectly suited for him.  There's no termination paperwork, no 6 months of trying to make it work, no awkward conversations about his progress behind closed doors.

Sometimes, a talented person can't, for whatever reason, commit to a 3 week project.  But maybe there's a smaller project he can do over nights and weekends.  Maybe there's an open source project of mutual interest.  Maybe he can take 3 days off his oyher job and work half a week and a weekend with us.  If it's a student, maybe he can join us for part of spring break.  And if none of that works, then well, we can't hire him.  And we wish him well and do our best to refer him to a company that will work.

But what we don't ever do is engage in some interview/code puzzle/awkward question process that has nothing to do with what it's really like to work with us.

 

Courting great people, working together temporarily as contractors, and then only engaging in full employment when everything proves out as hoped--that's the way to go. This method is spreading throughout the startup world, and I think it's good for everyone involved.  Most of the BigCo business world doesn't work this way.  Most larger companies have HR departments that hire through a more formal process.  I would guess that BigCo Inc. could actually be far more flexible than it currently is, but that's out of my scope of expertise.  I know for certain that startups can be more creative (and less insane) in their hiring practices...and they should.

 

 

Find discussion of this post on Hacker News 

******************
I'm Jason Freedman.  I co-founded FlightCaster.  
You should follow me on Twitter: @JasonFreedman.
You can send me a Linkedin request or become my bff on Facebook
44 responses
Can't agree more, and as someone who has been through this kind of processes from the other side, I think this is a best practice for *both* parties. In the same way that we may stretch the truth when being interviewed, managers and owners stretch the truth about company culture, personal opportunities, and designated responsibilities. What seems like a fantastic opportunity may turn out to be less than idea once you get into the details.
This is nice! i hope everyone follows this method instead of confusing/confounding potential candidates with puzzles/scenarios. The (only) problem i see with this approach is scale.
Great insights and I believe this actually points to a bigger issue. The nature of the employee/employer relationship, employee responsibilities, notion of a "career", etc. have changed dramatically yet the process for instigating that relationship hasn't changed. Finding a way to address the fact that it's okay to fail when hiring would be great for employers and employees. The short term project/contract is a step in the right direction, but the whole process needs to evolve.
Great post. I've been thinking for a long time that HR hiring processes are broken. How best you can perform in an interview may have very little to do with how well you can perform on the job. Totally different skill sets, depending on the job.

Need to "lean" hire. Much better success rate.

Couple of thoughts: Good question about scale, and how do you decide who to contract?

It becomes much lower risk, but still, there's some.

I imagine a lot more hiring would happen if the process looked more like this.

I loose two weekends making CV for two distinct functions that I didn't get response, doing interview is one way to known the people that you wanna hire. But it's too tedious, because the people are perfect on the resume and on their death.
I think your method is a great idea given that you can get someone to agree. But all the really top candidates aren't going to want to go through your 3 weeks of contracting. They'll be able to get offers from comparable places directly. Have you thought about the potential cost to your method in terms of people not wanting to go through it?
If a ton of businesses started doing this, it could be an easy way to make money on the side.

Step 1: Just get to the point of the project, put in some bare minimum effort and collect a pay check in a few weeks for the time spent working on this project.
Step 2: Just repeat with different companies.
Step 3: Profit.

You've just invented "contract to hire".

The big problem with this approach is that it doesn't scale at all well - both for the hirer and the candidate. It's hard (and possibly a contractual problem) for a candidate to keep down a full time job and moonlight on the side. The candidate will probably be unable to "apply" for multiple positions using this approach. If it doesn't work out the candidate has wasted his/her time on a short time contract that doesn't go anywhere.

As for the employer - how many candidates can you manage at once? It may be great for a couple of folks at a time but if you really need to ramp up recruitment then this approach can't scale at all well. You'd be spending all your time managing (probably remote) candidates.

I think it is a good idea but only if you have only one appliant. If you have many, are you going to offer them all a contract job? Otherwise you still will have to somehow screen them
Not entirely sure that I agree with stopping the interview process completely, but I definitely see the advantages to the way your hiring process works. There have been plenty of times I felt a job was a perfect fit for me, only to never be given a chance. I would gladly take part in a process similar to yours as I feel it benefits both the employer as well as the employee.
Great post Jason. I think one importance aspect of this process worth highlighting is that the mere existence of a trial period prevents poor candidates, who don't want to "show their cards", from even applying. Therefore, you will get a higher hit rate with a trial project.

Also, for more of Paul English's unconventional hiring tactics, check this out:
http://www.boston.com/business/technology/articles/2011/04/10/at_kayak_the_go...

This practice has been common in pretty much 100% of Dutch companies for at least the last 20 years. You hire a consultant and try things out, if both are happy, you sign a contract.
+1
To those who say "It doesn't scale" I say - hiring bad people is an even worse way to scale, and can be fatal for small organizations.

As a development team, and development managers, hiring is the #1 priority. Hiring the best people is the only way (that I know) to ensure that awesome, smart, successful developers come to work with you.

And, if someone can't commit to that, then no big deal. It's just too risky.
Better to have a false negative and pass over a good person than to have a false positive and hire the wrong one.

You do realize that you have consistently used the male pronoun throughout to describe any candidate you would even consider? I think that tells me plenty about what's broken with the hiring process.
So, while this works in theory, I think it runs into issues in practice:

- Good luck trying to get the best people to join your startup who are fully and happily employed. They wouldn't have the inclination or time to spend a few weeks or months at your company.
- Your organization will be littered with remnants of failed candidates. If we're talking software engineers, this is a codebase touched by hundreds, where most of the quality will be poor. Beyond that, there's obviously huge IT and HR overhead to revolving more people in and out the door.
- Morale is going to be an issue in the long run. Interviews are designed to be sectioned off, so when things don't work out there wasn't that many points of contact beyond the interviewers themselves. Seeing people come and go all the time creates an unstable environment.
- And of course, if you're doing anything that requires company secrecy, you're putting yourself at much more risk having more candidates look intimately at the contents of your company.

Instead, I'd suggest doing interviews where you can distill something you do on an everyday basis, and go through it w/ the candidate. This way, nobody spends more than a day, candidates are still sectioned off, and you still get good working data even though it's for a very short burst. In programming, this may be a bunch of pair programming sessions, but you get the general idea.

While I do agree that the interview process is as broken as the wretched batteries of exams we also see thrown at candidates ...

... the consultant to perm route is equally broken by companies abusing the process, as well as recruiting agencies turned body shops.

Anyone who takes this approach is taking a risk. It might not work out. Telling a candidate it's not going to work out after seeing them everyday for a week is emotionally hard. It's going to cost something to pay these people for a couple days work.

The point is that it is *always* worth taking the risk to make the best hiring decision. Nothing affects the success of a business more than the people involved. There are so many to choose from, how do you know you've found the right person? Or even a good one?

The truth is no test (that's not doing the job) can determine how effective someone will be doing the job.
Nothing measurable can determine if someone will be a good employee. Every person is different, and every group of people is unique.

@allenmhc makes some good points, but is approaching hiring from a different perspective than most startups would. He is concerned with maintaining the success of an existing business. Not bothering his employees, not poaching, not giving out secrets. A common approach from established business a few years after being considered a success, many years after taking VC money. The primary focus is to scale the business and grow lead on competitors. The best aren't required - they've already been found - the exec team. Loyal good-enoughs are the goal.
Jason (the author) is trying to build the most effective team he can. He knows that the team is the core and that quick and sharp execution is reason the business will succeed. He knows that he can't afford to make everyone happy, and that doing anything well will leave a few (unintentional) dead bodies in the water. For Jason, the risk of drama is outweighed by the benefit by finding the right core employees.
Culture-wise, these are fundamentally different types of companies. Different approaches will work in different situations.

At the recent "Hiring and Tech" forum, Saad Khan from CMEA venture capital, said one of the biggest challenges that remains unsolved by employers and HR staff is making the right choices on cultural fit.

I think this is the heart of the issue you are describing. Determining if someone has strong skills and the right experience for a particular position, is a matter of developing a good review process and adequately checking up on references. But understanding if they will be motivated by your team, culture, product and management style can only be determined by working side by side.

I agree that contractors are a powerful way to "try before you buy." If you're interested in younger hires, internships are an extremely effective tool for hiring as well.

Also worth noting, at internmatch we launched a kill the cover letter campaign as an experiment to generate apps that would express cultural fit. It was geared towards startups (500interns.com) and the percentage of applicants hired shot up as students self selected as those who get social media and tech. I think there are a lot of interesting ways to bake cultural fit into the now stale application process to supplement the work together for a month solution. In fact, Twilio asks applicants to make telephony apps as they apply.

I noticed you always use the pronoun "he". Why's that?

This is just contract to hire, nothing new. You still have to find and filter the contractor candidates somehow - and I'm guessing you pick those candidates the tried and try way, though referrals. From guys just like you. And you end up hiring guys just like you.

I think it is also important to take a step back and look at the rest of your team. How would you like to work at a company where folks kept getting pulled in and out while running projects. One week John is contacting you trying to get something done and next week Mary is the new person on the project. Constantly introducing folks into this type of system is not only risky to the folks looking for work but extremely risky to your company's culture as well as relationship building and trust. That being said this may work for specific positions but these positions should be selected carefully and a plan be put in place to communicate to the 'contractor' and the team/individuals they will be working with that this may be a rotating position until 'we' find the right candidate.
Good read. We take a similar approach, but there's a challenge in finding the right people to trial! You also risk losing staff who are fantastic and confident in their abilities as they can feel undervalued. We like to say; "hire slowly and fire quickly".
I'm having a several hour conversation and "project" with candidates about some code I wrote. Do they understand the code, what would they change, where to grow, are there bugs? I get a feeling if they are a cultural fit, they see our setup and working conditions and it's not manhole questions.

I'd like to try your approach, I'm not sure how you handle 5-10 candidates per week, how does your screening process work? Or do you invite all of them?

@Adamtait: "Loyal good-enoughs are the goal." No way. Good enoughs will get promoted and then hire below their level and your company goes down the drain.

As a development manager, I totally agree with your comments, but at least in the market I am in, it is really rare that I could actually do this. The only cases where it works (that I know of) are where the person is fresh out of school is already a consultant, or is unemployed. But the people I want are good and have jobs, so there's no way they are going to quit for a 2-3 week contract gig or they are going to consume all their vacation for such. I wish it were so simple, but, unfortunately, it's not. I also think that you failed to mention at least two significant risks: 1) the intellectual property that walks out the door if you don't hire them and 2) the cost of training and coaching the person if it doesn't work out.
As a recent graduate who has been through both processes, I can say that the contract for hire is by far the best. I went through a month long interview process at a local (but huge) web agency in the Twin Cities back in January and didn't get hired even tho I was the #2 candidate (so I heard from colleagues working there).

The startup I am working with currently, got in touch with me at the end of March to meet up for lunch with a few of the developers. We mostly just talked about the cool projects we've all worked on, what the company is about, and if I'd be interested in working for them. The next day I got a call to come on as a 60 day contract-for-hire.

Overall, I'm much happier with this style compared to what I went through a few months back. I feel that it works out better for the company and the individual in various ways. Great post, Jason!

Sounds like you would be a joy to work with. I have often felt raped by employers who absolutely refused to acknowledge the success of an individual. Instead the employer gets you to train others what they should already know, and then promotes that person.
So, I'm going to take a cynical view of your process.

Basically, you are looking to take advantage, most of the time, of people who are in a vulnerable position and looking for work. Most of the time a project will go over budget, over time, and be an reasonably happy compromise between client and project leader. Thus nobody having been satisfied suitably, the "newbie" carries the can, and doesn't get the job (if there ever WAS one).
You employ them on a consultant basis thus avoiding all the usual employer liabilities and the crappy contract you have them sign has little surprises like; it doesn't include expenses.
Occasionally you come across a jewel, and offer them a contract, but BEFORE the project is finished so they can't use your project as a springboard to something else, or to a position at a competing firm.

Not interviewing a prospective employee is a cop-out for your company's laziness and lack of professionalism in hiring the right person. Doing it that way is giving something for nothing, right? If you can't create an atmosphere of goodwill and co-operation in an interview you are certainly not going to be able to do it the first week people work with you. What's stopping you asking the relevant questions pertaining to a job in the interview? Nothing. What's stopping you testing a potential employee on core skills during an interview day? Nothing. It doesn't have to be the shitty process you're claiming it to be. The unfortunate truth is often that it's below-par middle mgmt hiring people who won't endanger THEIR positions, and are essentially a new addition to the company softball team.

People might think you're all that and you've found the golden formula, but not me my friend. You've found what you deem to be an acceptable process that works for you and has an acceptable success rate. There is nothing to say that this can be used in other business sectors.

In general, medium to large size companies SCREW their employees badly, and I will never work for one again. Start-ups are also a massive risk, so anyone who goes for that option better have money to lose, because let's face it, how many actually succeed?

Nice try, but no cigar from me.

I love the concept! However, don't you have to interview some candidates to decide who you want to join you in doing the "project"?
Great post! The ability to predict future job performance is a real riddle that if solved, businesses of all sizes could use to immediately affect their success.

A good friend is the head of scouting for a major league baseball team, so I've always been fascinated with his ability to analyze players i.e. the way a pitcher releases the ball and how that indicates their propensity for longevity or for injury (therefore a riskier hire). My friend also got me into "Moneyball" and statistically-driven performance metrics.

In this current age of knowledge workers, we need to measure not the physical attributes, but a worker's inherent behavioral attributes. This is where we've found psychometrics (statistics) to be incredibly useful and accurate at helping to predict future job performance.

Through analyzing the behavioral attributes of top performers in a particular job, one is then able to seek those attributes in future hires and become 5x more successful at predicting future job performance. We have all the metrics and research on this ... it's really an issue of making the technology more accessible to those who need it (growing businesses).

Interesting approach, but not the way it works in Silicon Valley. Out here, it's all about who you know. If you can't network out here, you are toast. I have been through an entire interview process and only produced a resume for HR records at that end. Why? Because I got an excellent referral from a trusted friend of the CEO.

I also can't see how this would possibly work in a hot market or during the hyper-growth phase of a start-up. The funny thing is you are trying to avoid hiring mediocre employees who interview well and yet you might just be hiring mediocre employees who can produce short-term quality work.

Out here the interview process already has evolved.

Jimbo

I never had an interview for my first job...instead the company gave me a week's wages and I simply came in and worked on a little piece of a project they were doing at the time......they got to know me, I got to know them......worked pretty well I think.
You are going to ask someone to leave a job to come and tryout for a 3 week contract (star candidates are employed when you recruit them, that's one of the ways that you know they are stars)? There needs to be some symmetry in the risk each side is taking. To me, it would signal that your a cheapskate (i.e. can't afford to take a risk) and that you are gaming the process squarely to your advantage. What power will I have to negotiate in 3 weeks now that I've left my job for you? If you use this approach you will be picking from the bottom of the barrel. That being said, interviews are far from perfect... Aggressive reference checking with people other than references submitted by the candidate is a good place to start. Social media makes it easy to locate a candidates colleagues past and present... Also, weight soft skills higher (51%) than technical skills (49%) when you evaluate a candidate. You don't want to work with someone you can't stand, even if they are a genius in their field.
From another humbled MBA, former entrep trying to find employer, I wish more companies considered the "working interview". I have a portfolio but taleo doesn't like jpgs or urls. Can't seem to get to a warm body these days. Any suggestions?
In the UK we do this anyway. It's usual to have a 3 month probation period where either party can quit at 1 week's notice.

Yes, I have fired people on their last day of probation.

Yes, I have had people quit on the last day of probation.

We interview to make sure we're not wasting all our time having a probation period at all. And yes, this includes a code test for two reasons:

1) it weeds out the liars/deluded immediately, not in a few days with your method

2) it frequently becomes a discussion about coding technique, past problems overcome, and geeky stuff in general. I've given the job to candidates who failed every part of the code test but showed me they could do the job.

So- I don't really approve of the Homer Simpson "nobody is good at interviewing so give up" approach.

Neil.

Are you paying these candidates an appropriate contracting rate for their work - roughly 2x what their salary would be? Because if you are not, then they are disproportionately baring the majority of the risk and would only be a good deal for freelancers that probably wouldn't want to work at your place full-time anyway.
I've been hired (and had many more offers) based on interviews, contract-to-hire, and pair programming. These were all programming jobs.

Absolutely the best recruiting experience I (and my would-be employer) had was a 3-hour pair programming session.

There is very little new information you get out of a contract-to-hire commitment over what you obtain from a pair-programming session. You have to realize that contract-to-hire is a very big commitment from both parties. At this stage in my career, I would not even consider a contract-to-hire position.

Another negative about contract-to-hire is that it is biased toward "closers." There's a lot of brilliant programmers who can contribute as part of a team, but don't necessarily have the discipline/interest in wrapping up and checking off on a project by themselves.

OTOH that may be exactly what you are looking for. In that case, why not just drop the "to-hire" part and go with contractors?

But I agree 100% that interviews and puzzles are as useful as flipping coins or drawing straws when it comes to hiring programmers. I've written about this and pair programming before: http://carcaddar.blogspot.com/2009/11/recruiting-puzzles.html

Totally agree with you! We are currently hiring interns for 3 months with a review for a full time employment. The positions seem to attract some great talent, the applicats also seem to feel more confident that there will be a payback after working hard.
Wow, this is a great technique! Even though it is an old discussion, many commenters above raised the question "don't you have to interview some candidates to decide who you want to join you in doing the "project"?" (That is a great question!)

My approach is to let the candidates self-select themselves out. *BEFORE* they even send in a resume*, I have a short, real-worldish problem they can download from our client's website. All they have to do is read it, code it and send it in. It would take a reasonably-competent person a couple-three hours to do the whole thing. In this way, 95% of the people who would normally clog up the pipe with their dead trees don't even bother. (And who would want someone would can't motivate to do some work? Is that who my clients would want to hire?)

Step 2 - phone interview, where we discuss the person's code. This is to weed out the people who cheated or who cut-n-pasted their solution without really knowing what they did. We just ask them to explain bits of their code.

Step 3 - the 1 or 2 people (and it will be that few!) who didn't BS their way through the exercise are the ones you bring in for the 3 week exercise.

* DId you catch it? I don't ever ask for the person's resume, because it is useless! Some work someone did for someone else at some other company in some other industry HAS NO BEARING on whether that person will be able to do the work in my industry at my company! None at all! Look, I don't care if you were the golden child at your last 4 companies. If you can't (or won't) do my work, then there is no point in going through the hiring process.

Repeat after me: past performance is no guarantee of future returns.

5 visitors upvoted this post.