Beyond that, if you do use a single question, you're now playing a game of whack-a-mole: I used to ask this question about the challenge, now I can't because it is leaked and people prepped for it. How do you scale that across an engineering organization? Do you have weekly meeting with every interviewer informing them of the questions about the challenge that are now blacklisted? It's going to be infeasible for any reasonable sized organization.
The challenge with this idea as well is that the risk of false positives is much higher than the whiteboard interview. The current interview process is designed around minimizing false negatives.
False positives are really costly to an engineering organization. It's not good for morale when engineers are being hired and fired in the same month on a regular basis. It's takes time to onboard, and slows the team down. It's also not good for the company reputation - would you apply to a company who had a reputation of firing a good chunk of its new software engineers within the first month?
A big part of the interview problem is that everyone wants to think that they are solving really important problems and are changing the world, etc.
Companies need to be honest about what they are doing and who they need to do it. Sometimes you have a hard problem and need a specialist or a brilliant problem solver to conquer it. Most companies need middle-of-the-road people who are reliable and consistent but not necessarily geniuses to maintain the things that have already been built. The idea that everyone needs to be a rockstar or a 10x-er needs to die. This overly inflated notion of what even some of the top tech companies are doing is the reason for all of this craziness.
Extremely few genuinely hard problems are solved by profitable companies. Some exceptions happen. But they happen(ed) in the R&D sections of those companies. Bell Labs, Google, Apple, Intel, Facebook-ish. But those are not the money-making day-to-day jobs that power the profit engines of those companies.
Those think tanks do excellent work, but they are not significantly different from research PhD programs. They just pay better. It's always been the .0001% of top people who solve problems theoretically, and then lesser people find ways to implement those solutions.
For any genuinely novel or hard problem there are ways to suss out how much a person has been coached, and how well the problem is truly understood. You don't have to change from week to week. It's not that hard.
In my own field, I can give a take-home challenge: here's a relational dataset. I want to work with this as a data warehouse. Give a rough outline of what changes need to take place, and how you would design the warehouse. Ask questions as needed as you go through the exercise, and be prepared to defend your design choices at the tech interview.
In less architecty roles, perhaps I'll ask a person to do some pretty basic data transformation as a kind of a fizzbuzz. But the tech interview is just to ask a series of questions that are pretty open-ended but have a list of points I think are relevant and assign points based on how many checkboxes they hit. And yes, that list can and will be leaked at a sufficiently large and desirable company, but it doesn't matter. Because the checkboxes are there to remind you from interview to interview what you were looking for. They are not a replacement for your assessment of the person. And you, personally, can change your mind as you go.
The point of an interview shouldn't be to find out if a candidate knows exactly what you know. If that's the design of your process and the only thing you care about, then you are going to have problems. The point of an interview is to let the candidate tell you what they know and for you to have some baseline for comparing that to what they need to know for the role.
In some cases, all the candidate needs is basic programming skills and the ability to memorize stuff. And in that case, you don't need to worry about if the candidate cheated, you need to worry about how honest your team is about what it's doing and what you need as a manager or coworker.
It's like security through obscurity. It never works. You need a better process.