I have generally avoided or balked at typical coding interview questions. They’re very seldom representative of real work, and have more value for helping big companies avoid lawsuits than helping anyone else evaluate candidates or prospective jobs.

That said… the article offers good advice for people going through the process. I’d add that it’s not much different from type- and test-driven development. Which, conceptually, might help readers who are reading this advice and feeling overwhelmed by the idea of trying to gather the information discussed while “buying time to think of a solution”.

Which is to say, if that feels like a lot of cognitive load on top of trying to navigate “soft skills” and/or other challenges in an interview, you may find it more grounding if you map the advice to ways you already work.

Another way to look at it that occurred to me: it doesn’t feel very different from a very short sprint (or new Kanban card or choose your working cycle abstraction).

1. Planning meeting to clarify user intent, acceptance criteria, whatever you need to get started.

2. Definition of smaller tasks and any feedback loop that might entail.

3. Implementation and its own feedback loop.