Asking questions in an interview, no matter how clever or insightful they may be, has been and will forever be a crap shoot.
Sadly, many of the best engineers I've worked with do have families, are working, don't live in the same town, and would absolutely balk at the idea of taking a week away from all that to "try out" a new job.
Of course, there's a wide spectrum between "work together for a week" and "write some C++ on a whiteboard for 40 minutes" that gets dropped from most screening processes. That's the zone where I'm most interested in finding creative evaluation tools.
Provide the right work environment and perks, and people will "jump through hoops" if they think its worth it.
At the end of the day, what job/pay/perks do you want?
If jobs require you to jump through some hoops, then they will be jumped through - within reason.
I do sympathize with the big damage done by poor hires & problems getting rid of them - I have seen similar as well. However, a process like this will select against a lot of quality developers and not necessarily select for the ones you want to work with. It just selects for the developers that that company wants to work with who are willing to jump through such an extra set of hoops. It also tells me as a candidate that the people who are working there don't have the courage to speak out against such a process selecting against candidates not willing or able to go through the process or the leadership is too weak to figure out that this sets up a bias that isn't intended to be selected for, thus being a bad hiring mechanism.
A trial process like this would select against lots of quality developers, true, but that isn't the real question. Instead, I want to know whether the developers who wind up being hired represent a more talented subset. I can't prove that it would, but I feel that this system would be more accurate in letting the right people through.
All that said, I like some of the gray area solutions proposed in this HN thread, including after-hours or weekend remote work on a project already in production. Not a perfect solution, given the inability to evaluate things like culture fit, but it combines many upsides of the alternatives.
Is the knowledge of splines a major predictor of a graphics programmer's success? I don't understand why it appears to be a point of denigration here. The details of your story are foreign to me, of course, so maybe I'm missing context. But it's always helpful to remember that time is finite when compared to the seemingly infinite amount of things to learn. No one comes to work and says, "I want to suck today!"
And yet companies will still let good engineers walk out the door because a competitor is willing to pay them 20% more.
Everyone always talks about how "amazingly difficult" it is to get under-performing people to leave, but really, why is that so? I find that simply saying
"You know, we don't think this arrangement is working out for either of us. Can you please do us a huge favor, and resign? BTW if you agree, here's $X, a perfectly respectable severance package that acknowledges that you are human being, and that this was just as much our mistake as yours."
pretty much always works (provided the company is willing to swallow $X, which if they have any integrity they should have no problem doing). You don't have to say the "this was our mistake part" of course, but that's what the $X is for, because it says it implicitly (and in a more substantial way than mere words ever could).
Of course, there's also the task of getting other people to see that someone is under-performing, which can be quite difficult sometimes -- but that's a separate issue (and if it really is especially difficult to have these kinds of conversations with persons of authority in your group, then maybe you should be moving on, as well).
Since I'd wager that the vast majority of skilled engineers would reject that offer outright, you end up really shrinking your pool of talent.
Sure, it'd be nice if you could hire all your great employees this way, but forgetting for a moment whether it's fair, it's not realistic.
Asking tough questions in interview is not particularly bad because tough questions generally work welll. This strategy has worked well for Google, Microsoft, Apple and Amazon I dont see why it cant work for everyone else.
The downside to the methods Google etc use is they have a huge number of false negatives. They reject tons of great engineers. This works out well when you constantly have thousands of great engineers applying to work for your company.
It does not work well at all if you are a normal company.
When you're a household name and most engineers view your company as a top place to go and you're getting thousands of resumes a day, you have the ability to filter differently than most folks.
There is a difference between what I call 'clever' and 'smart'. There are plenty of people that are fast on their feet at thinking about algorithmic-y type things. That doesn't translate into an ability to think through engineering problems, drive a project forward, cut through red tape, motivate peers, mentor the less experienced, identify market opportunities, behave ethically, build great teams .. I can go on. There is so much to this job other than manipulating binary trees, and swiftness at doing that at a white board is not a particularly good indicator of being able to think hard about novel problems. My best math professor, ever, had to ask the class to do the arithmetic and often we'd have to correct his algebra steps. He was fantastic, he just wasn't great at doing that stuff on his feet in front in front of an audience.
And, of course, not many jobs require novel algorithms; most require all other stuff. I'd give my eye teeth for an engineer that can just plod through and keep a project on schedule and budget. Don't see how the 'tough questions' identify her.
This is too strong a statement. It's an imperfect heuristic, and it's painful for all involved (which makes negative reactions to it be over-represented in online discussions), but it's better than shuffling the deck of resumes and randomly choosing one. You ask candidates what they know about tech, and it quickly becomes obvious who's in the know and who's able to think outside the box, and who isn't. It's more of a crap shoot in terms of gauging work ethic and personality. Week-long trials are simply not feasible for most companies (or candidates, for that matter).
This is why hiring people who we professionally interact with (referrals) is so important. And it's a handicap for people with weak networks or internal-only jobs.
You should just be sure you need and want to hire someone before they show up for their first day.
fuckin' word format resume. That is no longer a thing.