What do you really test when you ask an engineer with a ton of experience to solve a classic Leetcode problem like implementing a trie-based search? The only thing I can think of is that you are confirming they made an effort to brush up their algorithm and data structure knowledge.
I can already see people bitching about your proposal:
- it's too long
- coding along with another engineer is unrealistic
- it's close to impossible to scale this out to a number of interviewers as there are no strict scoring guidelines
- it's too different from what other companies do
- it's trying to outsource some of the problems your company has
- it's too technology specific
- candidates who know the domain will have an advantage
- candidates who know your tools will have an advantage
I'm not saying these are sensible arguments, but you will hear them against all and any kind of interview you can come up with.
Seriously though, the performance of an interviewee in such conditions are mostly a function of how well the interviewer can "onboard" the interviewee within 4 hours, or how much the interviewer is willing to actively guide the interviewee to the solution (as opposed to letting them figure it out).
Even with a single interviewer this easily introduces bias. I've interviewed many many people over the years, and sometimes I wonder whether I'm giving slightly more hints or less hints based on how subjectively I "like" the candidate. I mean, I try hard to be fair, but I don't follow a strict script, and the variability occasionally makes me doubt myself.
For such open ended tasks as 4 hours of essentially pair programming, I don't know how any interviewer could be objective and fair. Especially presuming that you wouldn't be re-using the same task once it's actually been solved/fixed... (otherwise that's just another artificial problem)
Algorithmic interviews like that test your capacity for bullshit. They're like "I know I'm testing you on irrelevant bullshit, but I want to see you succumb to my unreasonable demands to have studied trie-based search, because that means you are more likely to swallow any other bullshit I'll throw at you on the job".
Create a job posting on linked in, then review thousands of those CV's, pick people and have a 4 hour interview with each (meaning repeating the same problem, you don't want to have a different 4 hour coding session with each individual).
Then calculate how much time you wasted on (a) outright scam (b) people lying about their experience (c) people nervous enough so they almost freeze (d) people not motivated as if you already owe them something.
Then, you need to realize that you probably need more than 1 engineer and you'd want to repeat the process.
Things like leetcode at least filter out people who can't code and people not motivated enough to solve a couple of challenges. Yes, this will not prevent scam. And then you can filter out scam on the follow-up call.
If you solve this problem of getting qualified engineers to the companies at market rates (not overcharging like some outstaffing firms), where companies and engineers have a pleasant experience, I guarantee you can scale it to a billion-dollar-sized business.
How about saying no?