Earlier quoted context omitted.
If your challenge is novel, as I said, then it should be difficult for them to cheat. All the same, people are welcome to cheat. It should become clear that they've done so when you're interviewing them if you ask the right questions when they're explaining what they did. And if they somehow make it through anyway, you should be evaluating the quality of their work until they get established in your company. If they'…
Any challenge that doesn't change across applicants at a company that has a large enough applicant pool, will eventually be solved and prepared for so well, that almost any question you can ask will be prepped for. 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…
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.