In the past, I've taken existing code that needed a good refactor, checked the unit tests gave a good working/not working signal (i.e., deterministic pass/fail)

In the past, I've taken existing code that needed a good refactor, checked the unit tests gave a good working/not working signal (i.e., deterministic pass/fail), set up the candidate's preferred IDE/editor, and asked them to refactor it to be better, according to their definition of better. Then we talked about the things they did and why that was better. Probably the best "coding exercise" I've ever done in terms of getting to understand how someone approaches a typical code base. But sometimes candidates were very unsure about how to approach it, they found it hard to proceed without knowing exactly what "better" was. I stopped using this, as I realised that my approach was unconsciously selecting for a certain type of person, one who resembled myself and it excluded people who could be amazing devs within clear parameters. TL;DR interviewing is hard to get right, this reading idea is a good one.