I'm not sure what the OP suggests is feasible in most situations. It's disruptive to the existing team and you have to have "throwaway" projects around for the person to do that won't cause problems if they're late or poorly implemented (and if that's the case, why do them?) Also, you're letting every guy who "interviews" learn about the internals of your systems, code base, security, etc to some degree, which is not something most companies want to do.<p>Interviewing is hard, but it's clearly not totally broken, given that some companies obviously do a far better job of it than others. Do we really believe that the big consulting companies or banks don't know how to filter for the better candidates given how much their business depends purely on having the smartest people? Are Apple, Amazon and Google really just more lucky at hiring?<p>One non-interview thing that I DO like to look at is publicly viewable work like open source contributions, blogging, social media activity, etc. If someone wants to work on web sites, and they're not doing anything web-related outside of their job, I have to wonder how passionate they really are about the domain.
Hiring is hard because understanding people is hard.<p>There's also the problem of selection bias. Your technical interviewers are going to look for people that resemble themselves. In a broad sense this is because they think they're smart and everyone else is dumb (and rightly so). The problem is that this strategy can be far too successful and you will invariably turn away a perfectly suitable selection of candidates along with the unsuitable ones. It's human nature and difficult to detect.<p>There is another form of selection bias in the interview process. You need to know that the candidate you're going to hire is going to be competent, assertive, and talented. However the exact match of skills, abilities, and personality traits that fulfill those broad categories are going to be based off of those skills, abilities, and traits you believe have helped you to be successful so far. When interviewing someone it is far too easy to check off the features a candidate is lacking and miss the ones they do have that you do not. A good hire, IMO, is someone who has some of the skills and abilities you already have and some you do not. Yet all too often, we look for people who have ALL of the skills we already have instead.<p>I think strategies such as the one in the article would at least by-pass many of the definicies noted above. However I think it might be impractical in some scenarios (ie: when the candidate is already in a position at another company, or when they have received attractive offers from other companies). It's a start though and I think alternative strategies should be considered more often.
> Sometimes, a talented person can't, for whatever reason, commit to a 3 week project.<p>I would think this applies to pretty much anyone who is in demand.<p>> Maybe he can take 3 days off his oyher job and work half a week and a weekend with us.<p>Can someone else explain, why i'd take time off of work to do this job interview? Why not take a day off and interview with Google/Apple/Microsoft instead?
Perhaps Jason's approach may come out of his intuition, I'd like to explain it from a more "academic" perspective. In economics, the labor market is often suffered from information asymmetries where the employer has little means to determine the productivity of prospective employees. Therefore, if the employer is willing to pay average wage, it will obtain below average workers, as workers who has higher than average productivities won't accept the offer. Such a phenomenon is also called "the Market of lemons" in the context of used car market.<p>The root cause of such a market failure is because workers' productivity is difficult to measure. A certain measure has to be introduced to indicate the worker productivity indirectly (often termed Signaling in economics). For decades HR/Recruiters have been addressing this problem by using different metrics as the signals/indicators. Popular signals include education (GPA, university prestige).<p>Programming may be a bit more challenging as multiple factors can affect programmers' productivity, e.g., intrinsic intelligence, problem solving skills, the speed of learning. Our hard-working recruiters/interviewers have introduced some new signals --- brain teasers, coding tests, etc.<p>What Jason proposed in this blog post is that we don't need all those signals, they are all inaccurate and can be fooled around by a well-prepared interviewee, why not directly measure their performance by working with them for a short period, say, three weeks.<p>That does sound like a good idea. IMHO, that's basically what internship does for students, but not sure if that will work for full-time employees, as it will incur extra opportunity cost for them.
I was once given thirty seconds to come up with synonyms for information, which I did. Then I was asked come up with antonyms for fast and furious starting with the letter p, I came up with pudgy and pleased. Then I was asked to tell my life story in twenty seconds. I refused. The interview ended.
I like the idea, but as a developer there is little chance I'll do contract work before getting a job when I'm looking for a "real" job. Right now, finding a job is easy enough that I don't think a lot of people will jump through a lot of hoops before getting the job.
I like this approach of really testing out the waters before committing.<p>I find there is also a divide between HR/recruiting and the lead developers. Once I had two interviews at a company. The first one from HR and a second one from the lead developers.<p>The attitude of the developers made me think they didn't have much say into the whole process. They did ask the best (read hardest) questions. This interview order seems fine, though questions like:<p>how many lines of codes did you write in language X?
If we ask you to build Y, could you, and how would you go about it?
If there is a problem in the weekend, and we call you, would you come over to fix it?<p>Could perfectly be asked in the first round of the interviews. And if you really want to be sure that a person will come to the office, if need be, then maybe plan the contract meeting at midnight on a saturday :)<p>One thing I noticed while last searching for jobs is the apparent inconsistencies in job listings.<p>Pre-requisites like: PHP and Ruby, Web standards and Flash, thorough understanding of javascript (jQuery plug-ins), Photoshop or Illustrator and version control, familiar with Linux and .net.<p>At first I ascribed these pre's to unskilled job listers, but maybe this is the start of the negotiation process?
- "I do know X, but have to work on Y"
- "That is fine, have you thought about salary yet?"<p>Is this really a thing in recruiting, or am I seeing things?
My experience has been the opposite. Best employees aren't desperate to work for you. They're gainfully employed, and you have to poach them. No one I know who is productive would give up this much time to something. Almost everyone I know who is unemployed and desperate would.<p>The key to finding good employees is to do what Google does. Find successful people. Don't have them come to you -- go to them. How do you do this? Talk to professors and see who top students are. Read publications and books in your field. Hire whoever wrote them. Find neat free software projects, and hire the authors. The list goes on. People like that generally won't want to work for you, and the trick is to recruit them somehow.
I'm sorry. If I was currently gainfully employed and looking for a job, I don't think I'd be on board with your system. I appreciate the idea of getting to know a company, but, I'd be applying for several companies every day. Even given the current interviewing speed (several hours), it'd eat up time.<p>Doing part-time contracting is just not going to cut it. I've done moonlighting before: no one was very happy with my work, including me. You can't hire me this way if I have a job already.<p>If I was unemployed and looking, I'd be more interested, but you would not get a cut-rate from me: you'd get a full consulting rate & contract.<p><i>In my opinion</i>, if you want the best engineers, you need to know them and offer massive bait. Because they aren't just going to jump for anybody or any old normal reason. You have to offer them what they want - and more than their current job does.
Finding great talent is hard but identifying talent is not difficult. Yet, finding and identifying talent is just half of the story. The other half is determining if the person can focus in what you need, be motivated, take the initiative, and deliver great work. That's the difficult part. More often than not, very talented individuals have a lot of stuff in their heads, such that mundane but essential work ranks low in their platonic priority list, and that affects their capacity to concentrate and deliver.
I really like the approach of "Contract-to-hire" developers but I've often found it to be difficult in markets where most good developers have multiple offers at any given time.<p>Also it's tough to do this when you're boot strapping and literally every pair of available hands can make or break your first big deal that helps keep the lights on.
Tl;dr try someone out part time before hiring them full time.<p>Ignoring the link bait title of the post, I think the OP's suggestion is good. However, it's usually not possible. People are working full time and don't have extra time to work on your side project.<p>Interviews should include the same activities the interviewee will be doing during their job. Programmers need to program. Designers need to design. Sales people need to sell. It's actually quite easy to do this effectively in an interview and plenty of companies do that quite well (i.e. They don't suck)
After interviewing for months I basically memorized the answers to the main kinds of technical questions. After I started to hear the same sorts of questions asked over and over, I knew the process was completely broken and I would never ask stupid technical riddle questions to gauge someone's competence on the job.<p>I think a brief conversation about software development and a longer conversation to determine how smart the guy is is what matters. Even someone who barely knows how to code can learn on the fly if he's smart/competent enough.
Work sample tests are the best predictor (p of 0.54) of success on the job. <a href="http://bobsutton.typepad.com/my_weblog/2009/10/selecting-talent-the-upshot-from-85-years-of-research.html" rel="nofollow">http://bobsutton.typepad.com/my_weblog/2009/10/selecting-tal...</a>
For anyone looking for a job immediately (as I am), I don't think s/he has time to do multiple 3-months projects. I do believe current interview process is broken, and interview results are not indicative of job performance. I think that's why referrals work the best. Also, although much shorter, weekend hackathons are good ways to gauge working chemistry.
One issue that has been ignored is that of security / confidentiality. What happens if the individual you are "courting" works for one of your competitors? Any project that he would work on for you would likely require access to sensitive, proprietary data. Sure, you could force him to sign an NDA, but that puts him in a strange situation post-project.<p>How do you balance giving the candidate access to your data such that he can work on a meaningful project (read: the results of which are actionable) vs. having him toil away with some dummy data just to see how he thinks?
I strongly agree that the try before you buy approach is incredibly important for determining difficult to predict cultural and team fit. That being said while it is essential for early-stage companies to get this right, as pointed out in the comments, it can be difficult to scale and can be inefficient to make-up projects for potential hires, give them access to code, etc.<p>Some companies have found ways to bake cultural fit into their standard application process to great success. Twilio for example asks all applicants, business or engineering, to build telephony apps using the Twilio API before applying. This self-selects for people who are more willing to do research, be creative, and in general improves the likelihood that they will get along well with the team.<p>I am a bit biased here, but another path I would definitely advocate for is using interns. This is similar to the contractor approach but with a number of benefits in terms of price, and the fact that a hiring decision is not implicit at the end of the term. We have seen many startups build a pipeline of early hires by taking on multiple interns and seeing who is the best fit over the course of a few months.
I don't understand contract to hire. I get it from the employer perspective, but why do employees agree to it?<p>If I was willing to work contracts (e.g. had a wife I could get health insurance and maybe some income-in-case-of-layoff security from), why wouldn't I just always only contract so that I could make more and get paid for my overtime?<p>If I wasn't willing to work contracts, wouldn't requiring me to contract up front take me out of the running?<p>Or does this whole thing assume people will just go without health care for a while? I could understand that if there weren't other choices, but given that other full time employment is readily available, who does this?
IMO, an interview is to working at a company what speed-dating is to a long-term relationship. The interview process may get some measurements about someone's technical fundamentals, but very little can be gleaned about rapport with employees and in general how well an individual will gel with a company's goals and other team members. The success of a team is not just about the competence of each individual but how well the individuals work together as a team, and individual competence is not totally correlated to working well with a given team.
It's not just a time issue for the interviewee; the interviewer then needs to spend extra time checking the quality of the work, requiring extra technical expertise.<p>Awesome idea; just not feasible in many situations.
I know someone who could plausibly answer that interview question. She has a degree in English literature, undergraduate and post-graduate degrees in law (U. Queensland and Oxford, respectively), plus taking classics on the side while learning Scots / Civil law at Edinburgh. She's scientifically literate and active in various skeptical societies. She wrote an award-winning novel and has another on the way about an alternate history Rome where Archimedes was captured and not killed by the Romans.<p>People like this are out there. Perhaps such "Hail Mary Non-Sequiturs" are actually worth including.
IMHO the title of the blog is incorrect. What he is saying is that he never hires anyone fulltime without at least working with the person on a project, and not that he doesn't interview.<p>Since, think about it, how did he find the person who will do the project in the first place, especially if there were multiple applicants.
Unless of course the blogger is also saying that he never posts a job and only works through reference, which defeats the entire argument anyway.
I don't suck at interviewing, people who interview are usually as clueless as interviewee, so you can abuse this game from your side as well. I completely agree that people you hire most of the time have very little with what you need and want and that process is broken.<p>Suggestion in this post is how I would go about it as well, give people 2 weeks to try it out and see if we work for them as well as they work for us.
Some interview questions I want to say 'do you realise how awkward that is to answer?' like asking people how their former colleagues would describe them, or what their weaknesses are. You couldn't do that in a normal conversation so I'm not sure it's a good idea in interviews. But who knows. Maybe it's effective or maybe it's simply the done thing.
Automattic followed this practice and I think it worked quite well. When I was there, the company grew fast, but at least it was growing with known goods. When I'm back with Raffi Inc one day, I expect that I'll follow this practice too.
I totally agree with this article. You can get much better information from actually working with people. You don't have to expose them to your system, you can create a small project for them that is related and tests their skills.
@JasonFreedman That's great if it works for you, but personally I feel that you're just putting all the risk with the employee, which is shitty.<p>If someone is out of a job, the last thing they want is a 3-week gig. Yeah, I get that "well if they're good, they'll probably be allowed to stay". I wouldn't even consider working for a contract-to-hire position with a "few weeks" of guaranteed work. As a business, the risk is on YOU to hire the right person. As an employee, you're offering me what, maybe a month of rent while preventing me from going on most other job interviews? That's not a risk I'm willing to take. I'd rather do 3 interviews every day and have 5 jobs to pick from at the end of a week.<p>Also, the projects...I'd guess that the projects you have people work on aren't very beneficial to your company, or are so focused that they might not take advantage of the talents of the employee.<p>On the flip side, I think working with someone is the best way to get to know how they are / can be as an employee, and sometimes I feel that otherwise good employees will stumble on inverviews, so giving them some time to really prove themselves can be a good option....but I think that by limiting yourself to people willing to risk a few weeks on a long interview are going to be the most desperate of the desperate.
| You should follow me on Twitter: @JasonFreedman.<p>I should? Really? Actually, i think i'm just fine without signing up to be spammed by you. Thanks for asking so politely, though!
I like the idea of a "mini-internship" instead of an interview...<p>An employer could take on a person for say 2 weeks non-paid and let that person prove themselves.