[rowborg]

For purposes of discussion, let's take it as a given that a work-hire tests are the best way to screen candidates.

The effort required to administer an on-site work-hire test is non-zero, therefore I cannot administer such a test to every applicant.

I therefore need a way to determine who to bring on-site, in order to administer such a test. I cannot phone screen every single applicant due to the cost involved.

That process could also be a work-hire test of some sort (e.g. a remote coding project), but regardless of what has been said on this thread, many good applicants will drop off at this step. I know this empirically, because I've experienced it, many, many times.

Additionally, the people who tend to drop off because of this extra effort tend to be senior applicants, who often have multiple offers from multiple companies due to the competiveness of the current hiring market. It also disproportionately drives away passive candidates, who are often the best candidates, because the best candidates are often not looking for work (since they are good, people who have worked with them previously want to work with them again, and they get poached).

So I need some method of sourcing and filtering candidates down that is non-intrusive to both our development team AND the applicant. This is the reality. This simply has to happen in a startup's hiring pipeline.

Currently, most companies do this by looking at resumes. That is obviously sub-optimal.

Any suggestions for alternatives?

EDIT: spelling.

[vellum]

http://www.stackoverflowcareers.com/blog/2014/05/20/getting-...

Try segmenting potential hires into different categories and using different strategies for each group. You should also clearly communicate the process, so they don't get the wrong idea.

>Additionally, the people who tend to drop off because of this extra effort tend to be senior applicants

Is this before or after the phone screen? If they think the work-hire test is going to be in addition to a phone screen and an on-site whiteboard session, they'll drop. If they're senior devs, you should be able to tell from their resumes. Do a phone screen, and if they pass, explain that they can either do a work-hire test or a whiteboarding session. Explain that the work-hire test should be doable in 4 hours, so they don't envision a week long project. Also explain that it's a substitute for the whiteboard portion of the on-site. People who tend to hate whiteboard coding will choose the work-hire test and vice versa.

If you're trying to find diamonds in the rough among junior talent, sending out a first-pass work-hire test might work. You'd still get better results if you explained that it was short and a substitute for the onsite whiteboard session.

[sillysaurus]

I do. I was going to bail from this thread, but it sounds like you see the great potential that this idea can have, if it can work. The truth is that it works. Okay then, one last try:

Set up a system that can spin up a droplet for a remote candidate. Any time a candidate expresses interest in your company, spin up an instance and email them a link to it.

What does the link do? That depends on your company. Are you making an iOS app? Then the link takes them to where they can download source code for a fake, hypothetical iOS app. It says "X, Y, and Z bugs exist. Find them and fix them. Then add a feature: here is a clear description of what to add."

When the candidate is done doing this, they zip up their code and send it back to you.

If it sounds way more effective to look at that than to look at resumes, it is. If it sounds like it will repel candidates, well... Two things. First, if you're chasing a specific developer, then that isn't really the normal hiring process. You want them already. This pipeline is for everyone else. It makes no sense to subject them to a work hire test when you're actively seeking them out.

Here's the other point. The type of candidates you will find with this method will shock you. They will be so skilled that it won't matter whether they're called a senior or fresh out of college. You'll know immediately that you want them.

Everything I've described up to this point is a remote process. There is no on-site work hire test. By the time they come on site, you're mainly checking they can show up, and telling them about your company. You're no longer trying to filter them based on ability; they already demonstrated it.

Let's say your company's website is the primary focus, not an iOS app. Ok. The link will take the candidate to a hypothetical, fake website built with a similar framework. Again, it will have multiple bugs and a missing feature. Tell them what the bugs are, and tell them what the feature needs to do. Then have them send you their code when they're done.

I feel like at this point no one will even try to do this. You can think of so many reasons not to try: it takes too much work, it will scare too many people off, it will... Etc.

These reasons turn out to be largely fake or mistaken. Try it. Invest the resources to build this pipeline, tell HN when it's ready, and you win.

If this sounds prohibitive or unlikely, remember how counter-intuitive the most effective techniques in life are. Penicillin was discovered by accident. It sounds pretty unlikely that it would work. Same deal here.

I've explained this as clearly as I can. It's up to everyone else to either try it or to watch others win after they try it. Because the filter I've explained is the only way to let talent find you.

The type of people you'll discover will range from passive people who found the process amusing, to well-off senior developers who are demonstrating why you should pay them X equity or Y salary, to high school dropouts who turn out to be one of the most valuable people that join your team.

I'm not even going to touch the topic of what tech companies currently do. It doesn't matter. I've described what works, and if whoever reads this suppresses their instincts and builds this, they will discover it's practically the key to winning.

[chevman]

I think what you're filtering for here is 'initiative'.

I don't hire programmers, but have been a hiring manager, running fairly technical business teams now for 10+ years, and have found that initiative is often the deciding factor in any given employee's success.

There are other ways to select for it, and clues you start to pick up on over the years, but once you've figured out how to gauge relative levels of initiative across different people, I've found it makes hiring/resourcing questions quite a bit easier.

[creamyhorror]

I really like what you've been advocating in this discussion.

We've evolved the same process in my own startup - in the last 2 months we've hired 5 remote programmers in Vietnam and India by giving them 2 rounds of remote work-sample tasks (a simple web app), then ending off with a text or voice interview. We ended up retaining 2 out of 5 of them (both Vietnamese, incidentally) who demonstrated a higher level of ability after they started.

The retention rate is low, so we've been tightening up the process. What we've found is that we probably needed to raise the bar a little by asking candidates to design and architect a feature (DB-backend-frontend) during the chat interview. That would have given us a better insight into their code structuring and teamwork/communication skills.

We've just brought on a 3rd hire (Vietnamese again) who passed our improved interview, and I have a good feeling that the process works very well to weed out candidates who don't have the needed level of ability and scrupulousness.

The best of our hires didn't attend college or have much relevant experience, but was clearly very capable and possessed great initiative. We're really glad to have managed to hire him. Another guy is finishing his 3rd year of college.

In summary, I think remote work-sample tests are fantastic, and I hope you're right that they're the key to winning :)