I'm always happy to see efforts to improve the state of technical interviewing. IMO this style of interview works better for more senior engineers, where you w

I'm always happy to see efforts to improve the state of technical interviewing. IMO this style of interview works better for more senior engineers, where you want them to think about performance issues, pitfalls, API considerations, maintainability, etc. There's a separate but related workflow you could test which focuses on actually reading code to answer questions / debug issues. That's hinted at as one of the use cases in the FAQ ("roles like technical support or QA who may be tracing code, but not writing code"), but I think it's a sufficiently distinct workflow that it should be separated -- the difference here is reading a code sample, versus reading a pull request. I don't think either is a full replacement for coding exercises -- I for one can passably read code in many more languages (and even make some small edits) than I'd be comfortable writing in (mostly due to lower familiarity with standard libraries, but I can always consult an API reference if I'm not sure about some function or type).