Un débutant a écrit un bot Go pour les entretiens : voix, 860 questions et 25–35 Mo de mémoire

Situation connue : vous avez lu une dizaine d'articles sur le runtime de Go, votre tête est un joyeux mélange de slices, de scheduler GMP et d'escape analysis, et en entretien la langue s'emmêle. L'auteur de ce projet travaille la journée dans un garage automobile et apprend le backend la nuit. Il a résolu le problème par le code : il a écrit un bot Telegram qui pose des questions techniques, écoute les réponses vocales et les évalue sans aucune indulgence.

Pourquoi la voix et pourquoi pas Whisper

L'idée du projet : en entretien, personne ne demande de dissertation, il faut parler. C'est pourquoi le bot accepte précisément les messages vocaux. La première tentative avec Whisper en local a échoué : sur un VPS bon marché sans carte graphique, chaque message audio faisait grimper le processeur à 100 %.

L'auteur est passé à Deepgram dans le cloud avec le modèle Nova-2. Un message vocal Telegram au format OGG/Opus est traité en moins d'une seconde. Le jargon informatique russe comme « goroutines », « mutex » ou « generics » ne tourne pas à la bouillie, ce qui est crucial pour un tel bot. La conclusion pratique est simple : si vous n'avez pas de GPU et que le projet est modeste, auto-héberger la reconnaissance vocale coûte souvent plus cher qu'une API toute prête, si l'on compte le temps et les nerfs.

Comment empêcher le modèle d'acquiescer

Le grand défaut des évaluateurs LLM, c'est la flatterie. Demandez « que penses-tu de ma réponse ? » et vous obtiendrez presque à coup sûr « bravo, excellent ! », même si la réponse était faible. L'auteur a constitué une base de 860 questions réparties en 85 sujets et a ajouté à chacune des critères de référence, les key_points. Le prompt oblige DeepSeek (qui fonctionne via l'API Groq Cloud) à parcourir la liste : vérifier chaque critère, attribuer une note de 1 à 10, énumérer ce qui a été omis et donner une courte analyse sévère, sans compliments.

Exemple tiré du projet. Le candidat dit : « le slice double de taille en cas de dépassement ». Mais il n'a pas mentionné le seuil de 256 éléments ni la nouvelle formule de Go 1.18+. Sans checklist, le modèle aurait facilement validé cette réponse. Avec la checklist, il indique précisément ce qui manquait.

L'astuce est universelle. Ne demandez pas au modèle d'« évaluer », donnez-lui une grille avec des points obligatoires. Cela fonctionne aussi pour la vérification automatique de code review, de réponses du support ou d'exercices techniques.

Répétition, entretien simulé et pièges

Bachoter les questions à la suite est inutile, c'est pourquoi l'auteur a ajouté la répétition espacée. Pour chaque utilisateur, Redis constitue une file d'attente pour la session. Une réponse notée de 8 à 10 envoie la question en fin de file. Si la note est inférieure à 6, la question revient au bout de quelques étapes seulement. Toutes les tentatives sont enregistrées dans PostgreSQL, et les statistiques en sont tirées. Il existe aussi un mode de simulation d'entretien : on choisit un niveau, de stagiaire à senior, on reçoit 10 questions avec des précisions en cours de route et un verdict final Hire ou No Hire avec analyse des erreurs.

Les pièges se sont révélés typiques de tout bot Telegram :

• Balisage HTML. Si le modèle renvoie du code sans backticks ou perd une balise fermante, Telegram rejette le message. L'auteur a écrit un sanitiseur : il repère le code Go grâce à des mots-clés (package, func, :=) et l'encapsule lui-même dans pre/code avec échappement.
• Doubles clics. Un appui rapide sur un bouton inline génère deux callbacks d'affilée, et dans Redis apparaissait une condition de concurrence avec deux sessions parallèles. La parade : désactiver les boutons via EditReplyMarkup avant même les requêtes lourdes vers la base.
• Sécurité du déploiement. Les conteneurs ne sont pas lancés en root mais sous un utilisateur dédié, appuser. Dans docker-compose.prod.yml, read_only: true et cap_drop: ALL sont activés, et les dossiers système sont déplacés dans tmpfs.

Ce qu'il faut retenir

La stack : Go 1.23, telebot.v3, PostgreSQL 16 via pgx/v5, Redis 7, Docker Compose, architecture Clean Architecture. Selon l'auteur, en production le bot consomme 25–35 Mo de mémoire, démarre en une fraction de seconde et tourne sur un serveur à 200 roubles par mois. Pour un service léger qui appelle surtout des API externes, c'est un bon argument en faveur de Go.

Il y a aussi des limites. C'est un projet personnel de débutant, et l'auteur lui-même demande à des développeurs expérimentés d'examiner le code et l'architecture. On ne sait pas dans quelle mesure les notes du modèle coïncident avec celles d'un recruteur humain. Aucune métrique de qualité de la reconnaissance et de l'analyse n'est fournie non plus, donc la « sévérité » ne peut être jugée que d'après la description du prompt.

Mais comme ensemble de solutions prêtes à l'emploi, le texte est utile. Pour la voix, prenez la reconnaissance cloud si vous n'avez pas de GPU. Pour une évaluation honnête par un LLM, donnez-lui une checklist au lieu de lui demander son avis. Pour un bot Telegram, protégez-vous d'avance contre les doubles clics et le balisage HTML cassé. Les sources sont ouvertes : github.com/powood/Tg_GO_Mentor, et le bot est disponible sous le nom @go_SikkiMentor_bot.