At Compose (YC, S11) we had a two part hiring method. The first was a blind work-sample. You had unlimited time to complete it. Identifying information was obfuscated and graders would yes/no objective criteria. The best samples proceeded to the "work day".

During the work day, you'd join is in Slack for 8 hours. You'd need to ask probing questions to mock-up our infrastructure and pitch a feature based on "how we work".

One could try to cheat on the first part, but there is no chance one could have bamboozled us during the work day.

For our technical writing positions we had some instances of outright plagiarism, but no instances of anyone trying to cheat the coding sample.

> During the work day, you'd join is in Slack for 8 hours.

That's amazing! For everybody else that shares my amazement, I found https://www.compose.com/articles/how-compose-uses-interviewe... that touches on said hiring practice, but I'd love to hear more.

Just out of curiosity, how many people applied vs. made it through the blind work-sample vs. the work day? I think this is a great system, but I'm not sure I could keep a team of engineers actively engaged in answering infrastructure questions while at the same time trying to get their own work done. Was that an issue?

Are you still working at Compose? I'm curious how the IBM mandate of all remote workers going back to an office every day has affected Compose.

How much did you pay people for the two days worth of work?

The trick is to then talk through the code with them in the next interview.

"Why did you do this part this way? Would you do it differently if requirement X were different?"

It's immediately obvious if they cheated. Better yet, that's a much better, more relevant discussion than most whiteboard problems.