I've said it before and I'll say it again here - the best job interview I ever had for a software engineering position was about 10 years ago. I was shown a piece of code (directly from their codebase) which was about 50 lines long and we had a free wheeling technical conversation around it in which the interviewer asked me the following questions:

- What does this code appear to do (both technically and in the context of the business domain of the company)

- Are there are any red flags, edge cases, etc. that this code might not cover?

- If I were to rewrite it in the using modern libraries/tooling/best practices, what might I have done differently? High-level - we're not looking for you to physically write syntactically correct code here.

This is the same interview process that I now use on prospective applicants. In a single 30-60 minute dialogue it helps me answer questions such as:

- Can they size up and summarize existing unfamiliar code bases? In enterprise the ability to deal with legacy code is often more common than writing new code.

- Can they re-interpret old code using a modern lens? For example if we're discussing JS/TS (requires vs imports, callback hell vs async await, XMLHttpRequest vs fetch). For python (nested lists vs dataframes, simple numpy regression vs pytorch, etc)

- Are they able to communicate and convey their thoughts in a coherent and logical manner?

This is brilliant. I'll be stealing this for my next interview.