Cynically, big companies might be selecting for a modicum of technical expertise along with demonstrating capacity to put up with some amount of abusive processes.
They have no impetus to change and think they have found an approach that works reasonable well when given absurd amounts of candidates. The problem is the ridiculous false negative rate.
I struggle to think of a better system. Using experience is unfair and misleading (I worked on awesome stuff... that I can tell you nothing about, I was totally the lead on this software, etc...). Take home stuff is fine with me but a lot of people have problems with it. Come in for a week type things are incredibly applicant hostile.
Sit down with me and lets try and fix this bug seems like a more reasonable solution to me. Dev environment has the most popular ide with their devs, the source for whatever, internet access, and a bug report. Person is there to assist.
Talking about prior experience? Flawed for the reasons you mentioned.
Take home stuff? Flawed -- cheating and other issues (I discuss this in another comment).
Work with us for a week? Doesn't scale. Unfair to candidates. Lots of issues here.
Sit down and help me fix this bug? Flawed:
1. Huge bias based on whether they know this particular skill set -- the right tools, etc.
2. Pretty arbitrary as to whether they find that particular bug.
3. It can't be a real bug. It has to be a toy project in order to get a consistent evaluation.
You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details.
Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything.
Bug fixing is hard to prepare right. If you have a clear cut position, that would eliminate part of bullet one.
I'd argue that they should not be asked to find the bug. Only to fix it.
It does not have to be the same bug. I'd argue for a pool they can pick from.
You should be testing how they approach the problem and how they go about solving it. Heck you can debug and outline a fix for something you can't really code yourself, I know I did.
Pairing with someone from the team they'd work in could also provide some insight into the dynamic.
I agree there is no cookie cutter way for homework and bugs. That's why they need to be in a mix, well prepared and supervised.
That doesn't prove anything. They could've hired a senior developer to help them and explain the concepts in detail.
> Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything.
The more 'real-world' this is, the more it's going to be biased towards those that have experience in a particular stack or with a particular type of development. Which isn't necessarily bad (it could even be good!), but it may be if you want a more agnostic interviewing process.
I fail to see how that particular point can ever be a negative for the hiring company. If you need specific skills, you dictate the environment. If you want the candidate to bring his own skills, just tell him to pick his favourite tools.
There is a world of difference between "created something" and "can explain it in detail."