Also, the best (albeit the most expensive) selection process is simply letting the new person to do the actual work for a few weeks.
Also, the best (albeit the most expensive) selection process is simply letting the new person to do the actual work for a few weeks.
What kind of desperate candidate would agree to that? Also, what do you expect to see from the person in a few weeks? Usual onboarding (company + project) will take like 2-3 months before a person is efficient.
You don't need him to become efficient. Also I don't think it is always necessary to have such long onboarding. I'll never understand why a new hire (at least in senior position) can't start contributing after a week.
Because you have zero context of what the org is working on.
Ok... take me through it. I apply to your company and after a short call you offer me to spend 4 weeks working at your place instead of an interview.
I go back to my employer, give them resignation letter, work the rest of my notice period (2 months - 3 months), working on all handovers, saying goodbyes.
Unless the idea is to compensate me for the risk (I guess at least 6 months salary, probably more), then I do not see how you'd get anyone who is just a poor candidate to sign up for this.
> You don't need him to become efficient
So what will you see? Efficiency, being independent and being a good team player are the main things that are difficult to test during a regular interview.
You can say that about all forms of hiring process. If you're unemployed, you obviously have more time: to spend more time on the take-home assignments (which I hate, see another thread [1]), to add more stuff to your GitHub profile, to go to more interviews, etc.
Yes, but there's a significant difference between spending a few hours on a take-home assignment and dropping your current employment to spend 4 weeks potentially in another city working full time.
Unless your role is trivial to replace with an LLM, you need to understand the business. Maybe not for really junior role, but everything above - you need to solve issues. Tech is just a tool.
Let's say you're hiring manager for a company that compares flight tickets, something similar to Google Flights or Skyscanner. You need three additional Rust engineers. You're located in Palermo, Italy.
How do you hire people that would not only know Rust, be willing to move to Palermo, or at least visit occasionally, but also know the airfare business?
Even if you're willing to have people remotely, in the same region, how many unemployed Rust developers that know that business are on the market? 0?
Ideally, yes. It's a common occurrence among large organisations. Google and Apple used to even have an anti-poaching agreement.
> How do you hire people that would not only know Rust, be willing to move to Palermo, or at least visit occasionally, but also know the airfare business?
Rust isn't Boring, which is why you don't do that and hire one of many Java developers and do Java, unless the tradeoff is really worth it.
For data size, if you're a medium-ish company, you may only hire a few engineers a year (1000 person company, 5% SWE staff, 20% turnover annually = 10 new engineers hired per year), so the numbers will be small and a correlation will be potentially weak/noisy.
For confounders, a bad manager or atypical context may cause a great engineer to 'perform' poorly and leave early. Human factors are big.
Sure, the confidence intervals will be wide, but it doesn't matter, even noisy data are better than no data.
Maybe some companies already do this, but I didn't see it (though my sample is small).