You may be gaining access to hidden gems, but you're definitely turning away proven and experienced developers from even entering your hiring funnel.
It all depends on what type of employee you're wanting to hire.
You may be gaining access to hidden gems, but you're definitely turning away proven and experienced developers from even entering your hiring funnel.
It all depends on what type of employee you're wanting to hire.
In this scenario, we are asking for similar amount of time, but with no travel, time that works for everyone and has low stress with an interesting task folks can review beforehand.
Besides, before even going through this challenge, any engineer can make up their own mind whether it's worth for them because we present compensation brackets upfront on the call.
No, they don't. Like most people that champion these types of nonsense "code challenge" interviews you present a false dichotomy of "you have to either torture someone in person for multiple days, or torture them with a bullshit made up test for hours!"
You can talk to them for a while over the phone (or video chat), split up over a few days, and get to know them just fine.
I think it's perfectly reasonable to hire people based on resume, references, and conversation. If they can't handle the job once hired then they should be let go.
I do not think that the idea that all candidates are complete idiots unless they can be "proven" to be good engineers (by faked tests that rarely cover the actual job requirements but do have a way of discriminating against those who don't enjoy brainteasers, didn't go to college, or are older) is good or healthy.
I have, however, on two occasions probably personally convinced someone they had dodged a bullet by passing on me when I bombed that sort of quizzy interview—they were, I am entirely confident given the job descriptions, my work history, and actual feedback I've received from managers and peers, quite wrong, but I bet they were very sure I was useless and nowhere near being fit for the job.
[EDIT] I guess I should add that I have a history of not realizing that something I'm good at is not actually easy or obvious to others, so possibly I'm just unusually awesome at assessing developer suitability through conversation—I really doubt it, but maybe that's what's going on. I've also not found a way to make this fit with any sort of "we ask everyone the same set of questions because we want spreadsheets at the end" process, as you've got to tailor the interview to both the position and to the candidate, as presented on their résumé and related material. So if you want spreadsheets and quantifiable-everything then I'm not sure how you match that up with my preferred style.
This does assume that the interviewer is an expert in the area and can take that friendly conversation to the necessary depths.
At least that what my experience when I was a job candidate.
But yeah...people in tech seem to believe all kinds of weird stuff about hiring...if you are asking someone to come in for 2 days for a non-executive position, you are lighting bags of cash on fire.
However, asking that candidates donate 1-2 days of their time (probably burning PTO at their current gig) just to have a chance at an offer? That's a very unbalanced risk/reward for the company vs the candidate.
Maybe you pay candidates for their 1-2 days of interview time + comp PTO for time spent if they get the gig?
You've effectively filtered for people who are malleable and desperate for jobs.
> You may be gaining access to hidden gems, but you're definitely turning away proven and experienced developers from even entering your hiring funnel.
You're describing hidden gems.
My point was that for someone who is internet famous, more people will be willing to jump through hiring hoops, whatever they may be, just as they are for FAANG, but that doesn't work for most hiring companies, because most companies are small and you've also never heard of them.
Also, no amount of "works for me" argues against your process turning qualified people away unless you have some out of band way of knowing that that isn't happening.