Goroutines, channels et context.Context d'un côté, vie d'un service en production de l'autre : les questions d'entretien pour un développeur Go en microservices couvrent les deux. Le poste consiste à écrire des API gRPC décrites en Protobuf, à les instrumenter avec OpenTelemetry, à consommer des messages Kafka ou NATS JetStream et à livrer une image légère qui démarre et s'arrête proprement sous Kubernetes.
Go attire beaucoup de profils venus de Java, de Python ou de PHP. Ils écrivent du Go correct assez vite, mais laissent souvent fuir des goroutines, oublient l'annulation du contexte ou relancent un appel en échec sans limite, et une panne locale devient une panne de toute la chaîne. L'expérience se voit aux détails : une deadline propagée d'un service à l'autre, un profil pprof lu pendant un incident, un SIGTERM traité avant que Kubernetes ne coupe le pod.
Regardez aussi la version du langage. Go 1.25 a rendu GOMAXPROCS sensible à la limite CPU du conteneur, Go 1.26 active par défaut le ramasse-miettes Green Tea, et un développeur qui suit les versions sait ce que ces changements modifient dans ses réglages. Le PDF ajoute un cas de 20 minutes sur un service de réservation.
La pile technique d'un développeur Go microservices
Langage Go et bibliothèque standard
Un langage compilé et typé, avec ramasse-miettes, et une bibliothèque standard qui couvre HTTP, JSON, cryptographie et tests. Les interfaces implicites, les erreurs retournées comme des valeurs et les génériques structurent le code. Beaucoup d'équipes Go limitent les dépendances : demandez à la personne ce qu'elle prend dans la bibliothèque standard et ce qu'elle importe.
Goroutines, channels et context
Les goroutines sont des fils d'exécution légers, lancés par milliers, coordonnés par des channels, select et le package sync. context.Context transporte les délais et l'annulation d'un appel à l'autre. Une bonne partie des bugs Go en production vient de là : goroutines qui ne s'arrêtent jamais, accès concurrents non protégés, contexte ignoré.
gRPC et Protobuf
Le protocole d'appel entre services, sur HTTP/2, avec des contrats décrits en Protobuf et du code généré par protoc ou buf. Il gère deadlines, codes d'erreur, intercepteurs et streaming. Demandez comment la personne fait évoluer un fichier .proto sans casser les clients déjà déployés.
HTTP et API REST
net/http suffit pour beaucoup de services, d'autant que le routeur standard gère les méthodes et les paramètres de chemin depuis Go 1.22. D'autres équipes utilisent chi, Echo ou Gin. Le serveur et le client HTTP de Go n'ont aucun timeout par défaut, et un profil expérimenté les règle toujours.
OpenTelemetry, Prometheus et pprof
OpenTelemetry produit les traces distribuées et les métriques, avec une instrumentation prête pour gRPC et net/http. Prometheus et Grafana affichent les métriques. pprof, fourni avec le langage, profile le CPU, la mémoire et les goroutines d'un service en marche. Un candidat qui a vécu la production a déjà suivi une requête lente à travers plusieurs services.
Kafka et NATS
Les files de messages entre services. Kafka conserve les messages et permet de les relire, NATS est plus léger, et sa couche JetStream ajoute persistance et acquittements. Les clients Go courants sont franz-go, confluent-kafka-go et nats.go. Dans les deux cas, un message peut arriver plusieurs fois, et le service doit le supporter.
Conteneurs et Kubernetes
Compilé sans cgo, un binaire Go tient dans une image distroless ou scratch très légère. Sous Kubernetes, le service répond aux sondes de démarrage et de disponibilité, traite SIGTERM et respecte ses limites CPU et mémoire. Depuis Go 1.25, GOMAXPROCS suit la limite CPU du conteneur, et GOMEMLIMIT aide à rester sous la limite mémoire.
Accès aux données et tests
database/sql ou pgx pour PostgreSQL, sqlc pour générer du code typé à partir des requêtes, golang-migrate ou Atlas pour les migrations. Les tests s'écrivent avec le package testing, en tables de cas, avec le détecteur de concurrence (-race) et testcontainers-go pour les vraies bases. testing/synctest, stable depuis Go 1.25, teste le code concurrent sans attendre de vrais délais.
Le poste dépend de la maturité de la plateforme. Sur une plateforme en place, le développeur Go reprend des services existants, suit leurs métriques, corrige des fuites de goroutines ou de mémoire et ajoute des fonctionnalités sans casser les contrats Protobuf. Sur une plateforme qui se construit, il choisit les bibliothèques, le format des erreurs, la propagation des deadlines et le niveau d'instrumentation, et ces choix se retrouvent ensuite dans tous les services. Il n'administre pas Kubernetes, mais il doit savoir comment son service y vit : sondes, limites, arrêt, montée en charge. Les offres françaises associent souvent Go à React ou à Angular, donc précisez la part de back-end attendue.
Les compétences Go à contrôler en entretien
- Concurrence Go et context.Context
- Conception d'API gRPC et Protobuf
- Timeouts, retries et coupe-circuit
- Messagerie Kafka ou NATS
- Observabilité OpenTelemetry et pprof
- Conteneurs, Kubernetes et arrêt propre
Questions d'entretien pour un développeur Go cloud-native
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Votre service reçoit une requête gRPC avec une deadline de 300 ms et appelle deux autres services. Comment gérez-vous ce délai ?
Une bonne réponseLe ctx reçu est passé à chaque appel sortant, sans context.Background(), pour que la deadline se propage aux services appelés. Les deux appels partent en parallèle s'ils sont indépendants, avec errgroup.WithContext. Le code vérifie ctx.Err() avant un travail coûteux et renvoie DeadlineExceeded proprement. Un context.WithTimeout un peu plus court garde une marge pour répondre avant l'échéance.
Signal d'alerteUn nouveau contexte sans délai pour les appels sortants, ou un timeout fixe de cinq secondes partout.
Question 2 · confirmé
La mémoire d'un service Go monte lentement pendant plusieurs jours, puis le pod redémarre. Comment cherchez-vous ?
Une bonne réponsenet/http/pprof exposé sur un port interne, deux profils heap pris à quelques heures d'écart et comparés, et le nombre de goroutines suivi dans le temps. Les causes habituelles : goroutines bloquées sur un channel que personne ne lit, ticker jamais arrêté, corps de réponse HTTP jamais fermé, cache sans taille maximale. Un profil à jour sait que Go 1.26 propose en expérimental un profil des goroutines bloquées (goroutineleak).
Signal d'alerteAugmenter la limite mémoire du pod, ou appeler runtime.GC() à intervalle régulier.
Question 3 · senior
Un service appelé répond une fois sur deux en erreur. Comment vos appels sont-ils protégés ?
Une bonne réponseUn timeout par appel, des retries en nombre limité avec backoff exponentiel et jitter, seulement sur les erreurs transitoires (Unavailable, pas InvalidArgument) et seulement pour les opérations idempotentes. Au-delà, un coupe-circuit qui suspend les appels le temps que le service se rétablisse, et un repli si le métier l'accepte. La personne connaît la politique de retry configurable dans la service config de gRPC et sait que des retries à chaque couche multiplient la charge.
Signal d'alerte« On relance trois fois », sans délai, à chaque niveau de la chaîne, y compris pour un paiement.
Question 4 · confirmé
Vous devez renommer un champ et en supprimer un autre dans un message Protobuf utilisé par cinq services. Comment procédez-vous ?
Une bonne réponseSur le fil, Protobuf identifie un champ par son numéro. Renommer ne casse pas le format binaire, mais casse le JSON et le code généré des clients. Un champ supprimé voit son numéro et son nom passer en reserved pour ne jamais être réutilisés. La personne ajoute avant de retirer, déploie les serveurs puis les clients, et fait tourner buf breaking dans la CI.
Signal d'alerteRéutiliser le numéro du champ supprimé pour un nouveau champ, ou changer le type d'un champ existant.
Question 5 · junior à confirmé
Kubernetes envoie SIGTERM à votre pod pendant un déploiement. Que fait votre service ?
Une bonne réponseIl capte le signal avec signal.NotifyContext, fait échouer la sonde de disponibilité pour ne plus recevoir de trafic, termine les requêtes en cours avec http.Server.Shutdown ou GracefulStop côté gRPC dans un délai inférieur à terminationGracePeriodSeconds, arrête de consommer les messages après avoir validé ceux déjà traités, puis ferme les connexions à la base.
Signal d'alerteRien : le pod s'arrête et les requêtes en cours tombent en erreur. Ou un os.Exit dans le gestionnaire de signal.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Le recrutement d'un développeur Golang en pratique
Un développeur Java ou Python peut-il passer sur un poste Go ?
Oui, et c'est fréquent. La syntaxe s'apprend vite. Ce qui prend du temps, c'est la concurrence à la manière de Go, la gestion explicite des erreurs et l'habitude de peu de dépendances. Un développeur Java qui a déjà écrit des microservices en production connaît les retries, les timeouts et l'observabilité, et apprendra le reste. Vérifiez qu'il a écrit du Go sur un vrai projet, même personnel, et pas seulement suivi un tutoriel.
Faut-il exiger Kubernetes d'un développeur Go ?
Pas l'administration d'un cluster, qui relève de l'équipe plateforme ou SRE. Le développeur doit en revanche savoir écrire des sondes qui reflètent l'état réel du service, traiter SIGTERM, régler la mémoire et le CPU de Go par rapport aux limites du pod et lire les événements d'un déploiement raté. Un service qui perd des requêtes à chaque mise en production est un problème de code autant que d'infrastructure.
Quelle différence avec un développeur Go orienté Kubernetes ?
Le développeur Go microservices écrit des services métier : API gRPC ou HTTP, messages, base de données, résilience. Le développeur Go Kubernetes écrit des outils pour la plateforme elle-même : opérateurs, contrôleurs, CRD, souvent avec controller-runtime ou Kubebuilder. Les deux partagent le langage et la concurrence, mais l'entretien ne porte pas sur les mêmes sujets. Une offre qui mélange les deux attire des profils très différents.
Quel test technique pour un développeur Go ?
Un exercice d'une heure au plus, en direct ou en revue de code. Par exemple un pool de workers avec annulation par contexte et limite de parallélisme, ou un handler HTTP qui laisse fuir des goroutines et n'a aucun timeout, à corriger en expliquant. Demandez de lancer les tests avec -race. Un long projet à rendre en une semaine dit peu de choses sur les réflexes de production.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
