Entretien de live coding : résoudre un exercice en expliquant son raisonnement

Vous fusionnez des créneaux, puis un test montre que votre résultat a perdu une partie du premier intervalle. Vous devez alors nommer l’hypothèse contredite, conserver la bonne frontière et vérifier la correction. Un entretien de live coding permet de rendre ces décisions visibles au fil du code.

Pour vous entraîner, choisissez un exercice assez petit pour calculer une réponse à la main. Ce guide propose un laboratoire téléchargeable, une trace d’exécution et un dialogue fictif autour de créneaux demi-ouverts. Vous pourrez reprendre la méthode sur les questions Software Engineer de PracHub, en reliant vos explications au cas que vous venez de calculer.

Faits officiels : les sources citées décrivent des mécanismes d’outil ou de langage. Récits de candidats : les questions PracHub sont des supports de pratique, pas une annonce de votre entretien. Proposition pédagogique : le cas, les répliques et les tests suivants sont les nôtres. Aucun entretien réel n’a été enregistré ou évalué ; aucune durée ni grille de recrutement universelle n’est déduite de cet exercice.

Préparez les gestes utiles dans l’environnement annoncé

Officiel : le guide candidat de CoderPad Interview décrit un environnement dans le navigateur où l’on écrit, exécute et consulte le résultat du code. Il propose un environnement de préparation. Cela documente CoderPad, pas le déroulement de tous les entretiens en direct.

Lisez votre invitation pour connaître l’outil, le langage et les ressources autorisées. Pendant une préparation permise, vérifiez où apparaît une erreur et comment lancer un exemple. Notre laboratoire utilise Python localement : il ne valide pas votre accès à un pad, votre connexion vidéo ou une configuration d’entreprise.

Dans cet entraînement, vous conduisez la résolution et l’interlocuteur pose des questions. Il ne s’agit pas d’organiser des rôles driver et navigator ni de programmer simultanément à deux. Vous cherchez surtout à montrer un contrat, un invariant et l’effet d’un test, avec des phrases suffisamment courtes pour laisser une place aux questions.

Clarifiez une ambiguïté qui change le résultat

Notre fonction reçoit une liste non triée de paires d’entiers (début, fin). Un créneau représente [début, fin) : le début est inclus, la fin exclue. Les unités sont abstraites ; nous ne traitons ni dates, ni fuseaux horaires, ni changements d’heure.

Le contrat initial demande de fusionner les créneaux qui se chevauchent et de garder séparés ceux qui se touchent seulement. Un intervalle vide [a, a) est ignoré. Une paire inversée est rejetée. La sortie est triée et l’entrée reste inchangée. Ces choix appartiennent à l’exercice ; confirmez ceux de votre énoncé plutôt que de les considérer comme obligatoires.

Les créneaux [1, 3) et [3, 5) ne se chevauchent pas : trois appartient au second, pas au premier. Ils peuvent pourtant être représentés ensemble par [1, 5) sans changer les points couverts. Demander si le contact doit être fusionné précise donc la représentation souhaitée, au-delà de la seule couverture.

Dialogue fictif, point A — avant le code :

Candidat : « Pour deux créneaux dont la fin et le début valent trois, gardons-nous deux paires ? Je vais aussi ignorer les créneaux vides et préserver la liste d’entrée. »

Interlocuteur : « Oui pour cette première version. Nous pourrons changer la règle du contact ensuite. »

Cette question évite de débattre d’une condition > ou >= sans savoir quelle sortie est demandée. Une fois la réponse obtenue, inscrivez un petit exemple attendu. Il devient un test du contrat, pas une préférence de style.

Reliez le tri à un invariant précis

Pour l’entrée [(5, 8), (1, 3), (2, 4), (4, 5), (10, 10)], le créneau vide disparaît. Après tri, vous traitez (1, 3), (2, 4), (4, 5) et (5, 8). La sortie initiale doit être [(1, 4), (4, 5), (5, 8)], puisque les contacts restent séparés.

Officiel : Python distingue sorted(), qui construit une liste triée, et list.sort(), qui modifie la liste. Ici, produire une liste triée séparée permet de conserver l’ordre original chez l’appelant. Le choix doit apparaître dans votre explication si la préservation des données fait partie du contrat.

L’invariant est le suivant : après chaque créneau traité, la sortie représente exactement leur couverture selon la règle choisie, et la borne droite du dernier groupe est la plus grande fin de ce groupe. Le tri garantit qu’un créneau futur ne commencera pas avant celui que vous regardez actuellement.

Dialogue fictif, point B — avant la boucle :

Candidat : « Je trie par début. Si le prochain créneau commence avant la fin du groupe courant, je conserve la plus grande fin. Sinon, j’ouvre un nouveau groupe. »

Interlocuteur : « Que devient cette fin quand le prochain créneau est entièrement inclus ? »

Cette intervention cible une propriété du programme. Vous pouvez répondre en suivant un cas, sans commenter chaque affectation. Une pause pour calculer les bornes apporte ici plus d’information qu’une répétition du nom « fusion d’intervalles ».

Faites apparaître l’erreur d’un créneau imbriqué

Considérez [1, 8), [2, 3) puis [7, 9). Après le premier, la borne droite vaut huit. Le deuxième est inclus dans le groupe courant ; il ne doit pas réduire cette borne à trois. Le troisième chevauche encore le premier et la sortie correcte est [1, 9).

Une version volontairement défectueuse remplace la fin courante par la fin du créneau rencontré. Elle produit finalement [1, 3) et [7, 9). Elle a perdu les points entre trois et sept qui étaient couverts par le premier intervalle. Ce défaut se voit sur un petit cas ; il ne nécessite pas une entrée volumineuse.

Dialogue fictif, point C — après le contre-exemple :

Candidat : « Mon affectation a réduit une frontière déjà établie. Je remplace cette fin par le maximum des deux fins, puis je relance ce cas et le cas de contact séparé. »

Interlocuteur : « Quel état doit rester vrai après la correction ? »

Candidat : « La fin mémorisée reste la plus grande de tout le groupe, même après un créneau inclus. »

Vous reliez ainsi l’échec, la modification et le test de régression. Présenter la correction comme un simple changement de ligne masquerait la raison pour laquelle cette ligne devait changer. Conservez le cas imbriqué dans vos notes pour vérifier une future réécriture.

Écrivez le cœur du code puis vérifiez ses limites

Voici le cœur de la solution pour des paires d’entiers déjà valides. Le programme complet du ZIP ajoute le rejet des paires inversées et des bornes non entières.

def merge_slots(intervals, merge_touching=False):
    result = []
    for start, end in sorted(intervals):
        if start == end:
            continue
        separate = not result or (
            start > result[-1][1] if merge_touching
            else start >= result[-1][1]
        )
        if separate:
            result.append((start, end))
        else:
            result[-1] = (result[-1][0], max(result[-1][1], end))
    return result

La branche initiale protège l’accès à result[-1] lorsque la sortie est vide. La condition de séparation matérialise ensuite la règle de contact. Pour un chevauchement, le maximum préserve la frontière du groupe. Les doublons fusionnent sans créer de couverture supplémentaire.

Officiel : la documentation des listes Python décrit notamment l’ajout d’un élément avec append. Ici, l’ordre des groupes suit celui des créneaux triés. Ne choisissez pas une structure plus complexe sans expliquer quelle opération supplémentaire elle rend nécessaire.

Le tri donne un coût O(n log n) ; la passe de fusion est O(n). La copie triée et la sortie peuvent occuper O(n) mémoire. Dire seulement « un parcours donc O(n) » oublierait le travail préalable. Si l’entrée était déjà triée avec cette garantie, le coût pourrait être réexaminé ; ce n’est pas notre hypothèse initiale.

Acceptez un changement de règle sans perdre les tests

L’interlocuteur demande maintenant de fusionner aussi les contacts. Notre entrée travaillée doit alors produire [(1, 8)]. Les points couverts restent identiques ; les trois groupes adjacents sont simplement représentés par une seule paire.

Dialogue fictif, point D — nouvelle exigence :

Interlocuteur : « Fusionnez aussi les créneaux qui se touchent. »

Candidat : « Je change la condition de séparation : une égalité rejoint désormais le groupe. Je garde le test imbriqué, puis je vérifie que [1,3) et [3,5) deviennent [1,5). »

Le paramètre merge_touching rend les deux contrats explicites dans le laboratoire. Une réponse d’entretien pourrait n’implémenter que la politique demandée. Le paramètre est ici un moyen de comparer les comportements, pas une obligation d’architecture pour chaque exercice.

L’intérêt du deuxième cas est de montrer ce qui ne doit pas changer. Un nouveau contrat de contact ne remet pas en cause le maximum de la borne droite. Relancer un test de l’ancienne erreur évite de réparer une frontière tout en abîmant une autre propriété.

Gardez une trace de ce qui a été exécuté

Le fichier trace.csv indique, pour chaque politique, le créneau trié, le groupe précédent, l’action et la sortie accumulée. Avec la règle initiale, (2,4) étend le premier groupe ; (4,5) en commence un autre. Avec le contact fusionné, ces mêmes bornes restent dans le premier groupe. Cette trace permet de vérifier si la phrase annoncée correspond à la branche réellement exécutée, notamment lorsque deux bornes sont égales.

Le reçu results.json conserve 16 vérifications exécutées avec CPython 3.12.14 : exemples, contact, inclusion, doublons, bornes négatives, entrée préservée et rejets de données hors contrat. L’une conserve le résultat erroné de la version volontairement défectueuse afin de documenter l’échec, sans le confondre avec une validation de cette version.

Un oracle indépendant construit un graphe de créneaux reliés, puis calcule ses composantes connexes. Il n’utilise pas le parcours glouton trié. Sur 3 616 listes de longueur zéro à trois, avec des bornes entières entre moins un et trois, les deux politiques ont donné 7 232 comparaisons concordantes avec cet oracle.

Cette vérification reste limitée à des bornes entières et à notre définition du contact. Elle ne valide pas un calendrier de production, une base de données, un benchmark ou votre capacité à résoudre un autre exercice en direct. Pour reproduire la pratique, décompressez le ZIP et exécutez python3 interval_lab.py depuis sa propre arborescence.

Entraînez l’explication avec des points de contrôle

Rejouez les points A à D en changeant une entrée, plutôt qu’en apprenant les répliques. Avant le code, annoncez le contrat. Avant la boucle, formulez l’invariant. Après un échec, nommez le cas qui le contredit. Après le changement de règle, dites quel test change et lequel reste valable.

Pendant un mock seul, vous pouvez enregistrer votre propre explication pour repérer les phrases qui ne renseignent aucune décision. Remplacez « je fais une boucle » par ce que cette boucle conserve. Si vous recevez un indice, notez son effet précis sur votre raisonnement. Cette note sert à votre progression ; elle ne calcule pas une note de recrutement.

Officiel : le guide CoderPad indique que l’usage d’une assistance IA disponible doit être discuté avec l’interlocuteur. Confirmez les ressources permises dans votre propre session. Les dialogues de cet article sont une préparation ; ils ne constituent pas une assistance à utiliser en secret pendant une évaluation.

Changez de problème en conservant la méthode

Récits de candidats dans PracHub : les cinq questions suivantes permettent de travailler une propriété différente. Les titres complets sont conservés et ne prédisent ni un employeur, ni une plateforme d’entretien.

Prenez une nouvelle question dans les exercices Software Engineer. Conservez le contrat reformulé, le contre-exemple et la sortie de votre dernière version. Ces preuves donnent une matière concrète à votre explication, même lorsque le problème ou une exigence change.

Sources and Further Reading

• CoderPad Interview : guide de préparation pour les candidats
• Python : les techniques de tri
• Python : structures de données et listes