The strongest signal we get in an interview is not code. It is a handover.
We hand a candidate a small working service they have never seen, give them time to read it, then ask them to brief us as if they are off tomorrow and we are the ones covering.
What we listen for: what they name as fragile before we point at it, which failure paths they have already thought about (the payment call times out, the queue backs up, a token expires), and what they say plainly they do not know yet. The people who do this well ask us questions back. The ones who do not walk us through the happy path and stop.
We interview this way because handover is what clients are actually buying. Not one brilliant engineer, but a team where someone being out does not stall the work. That holds only if engineers can read each other's code and explain it out loud, and half an hour of handover shows it far more clearly than a tidy solution to a puzzle.
It is fairer to the candidate too, they see how we work before they commit.
If you hire engineers, you probably have one question that tells you more than all the others. We would like to hear it.