[crazy5sheep]

That's exactly what I have been done for years.

I have create a git repo specified for the question, with some code working in way, but buggy, such as logical bugs or race conditions...etc. with a lot of not business relevant assumptions. I usually told the candidate what this code supposed to do, and ask him to review the code first, then tell me what was his impression on the code base, and what were the problems, and how he can fix it. By doing this, I can judge the candidate if they are good at general coding, debugging and and comfortable to work on projects which they are new to, as well as their mindset on writing maintainable software. A good candidate will not just fixing the obvious issue, but propose some architectural changes, then I will ask them what are the strategy to do so as the project has existing dependents, this can give me signal on how the candidate coordinate with other teams. Then I will ask him some more questions related new features, and scaling..etc. to measure his design, communication skills and more.

It never failed me for senior level positions hiring, that either the candidates were hired and proven to be a great match, or they got a better offer elsewhere.