I wasn't suggesting you hire everyone who walks through the door, but I bet my hour-long test is within 80% as accurate as those crazy all-day stress tests, and

I wasn't suggesting you hire everyone who walks through the door, but I bet my hour-long test is within 80% as accurate as those crazy all-day stress tests, and much cheaper. Asking for code (even a few lines) in the application itself would further reduce the number of applicants. Your system/circumstances seem like they'd make trusting and benefiting from new hires quite a hassle. Ideally you'd have some public and open-source app to have new hires hack at, but there should be tests to be written, etc, which shouldn't leak trade secrets. (If you don't have docs for which files/components implement your trade secrets, and therefore which ones do not, I don't see how you have any hope of keeping anything straight.) If their early mistakes cause an outage I think it says more about your build processes than them. As for people not quitting for what's in essence an extended interview, that's what they are doing for you and others already. You fully intend to dump them if they don't prove to be good, but you don't have a quick process to determine this so you aren't as up-front about it. But yes, not every place has it as easy as Github, for instance. They have a ton of publicly available code an applicant could work on, and in doing so they'd show they could use the company's products and tools. I don't know, but would bet they have a comparatively easy interview process.