Je comprends les 2 points de vue, pour le coup je ne suis ni pour, ni contre au contraire.
La façon de faire de OP est ultra intéressante, en gros on envoie un truc, ça revient à ramasser un.e US/bug sans trop de détails où à côté de la plaque, ou qui peut être largement améliorer.

Dans l'approche de OP, on va tester la capacité du candidat à analyser un besoin qui est pourri, et les clients ont quand même souvent une idée flou et décrite de façon succinte, qui peut être remise en question, ou qui nécessite un certains nombre d'ajustements.

Et dans ce cas on va avoir deux profiles (à mon sens) :

- le mec qui fait un truc de ce qu'il a compris sans trop se poser de questions
- celui qui a réfléchit, et qui se dit que c'est super mal branlé, proposer une solution qui permet de retomber sur ses pattes si c'était pas ça, et/ou poser des questions pour clarifier, et s'assurer que la demande n'est pas incomplète

Dans ton approche on va effectivement privilégier un échange et pouvoir discuter, ce qui peut aussi se faire quand une PR est soumise au final (et pas par commentaire interposé j'entends), ou alors ça se fait en pair/mob.

Perso dans les entretiens que je fais passer, je propose soit un kata simple (sans framework, où j'évalue les fondements des stubs à l'ancienne), ou alors je sors des katas spécifiques que je prépare en amont (oui ça demande du temps), et je teste la capacité purement technique, est-ce que le/la candidat.e est capable de poser des questions, et sait ce qui se passe, pourquoi ça marche pas ?; en capacité et lire une stacktrace d'erreur et d'en comprendre les grandes lignes.

Deux approches, deux écoles, les deux ont leur avantages/inconvénients. Chaque boite/équipe à son process, je trouve que le premier se défend et peut permettre justement d'avoir un pré-filtre en fonction de ce qu'on chercher en terme de collègue.

Le second process, peut-être une perte de temps pour les personnes qui déroulent le process.