Mon expérience d’entretien Amazon SDE – mai 2024

En mai 2024, j'ai eu l'opportunité de passer un entretien pour un poste d'ingénieur en développement logiciel (SDE) chez Amazon. Tout a commencé lorsqu'un recruteur m'a contacté via LinkedIn. J’ai été agréablement surpris, car c’est toujours passionnant.

Comment tout a commencé

Le recruteur a été professionnel et clair, me donnant tous les détails nécessaires sur le processus et le rôle. Après avoir échangé quelques messages, j'ai reçu un lien de test pour le premier tour de l'entretien, qui était une évaluation de codage. L'évaluation était hébergée sur HackerRank et comprenait deux questions de codage.

Premier tour - Le test de codage

Les questions étaient simples mais légèrement longues. Voici une répartition :

1. Première question : génération de codes-barres
La tâche consistait à générer un code-barres basé sur certains paramètres prédéfinis. Même si la question n'était pas complexe en soi, elle nécessitait une attention particulière aux détails pour garantir que toutes les conditions étaient remplies. J'ai abordé ce problème de manière méthodique, en le décomposant en parties plus petites et en implémentant une solution en JavaScript. L'accent a été mis sur l'efficacité et la clarté, en garantissant que le code-barres généré répondait au format et aux contraintes attendus.

2. Deuxième question : traitement du tableau avec état de déploiement

Il s'agissait davantage d'une tâche de manipulation de données. L'entrée était composée d'objets, chacun avec un ID de déploiement et un statut de déploiement. Mon objectif était de renvoyer un tableau basé sur ces entrées. Même si le problème semblait simple, il comportait son lot de cas extrêmes. Par exemple, il manquait des clés à certains objets, ce qui n’était pas visible au premier coup d’œil. Cependant, après avoir soumis ma solution initiale, j'ai réalisé que de tels cas extrêmes devaient être pris en compte. J'ai rapidement révisé mon code pour gérer ces scénarios, en m'assurant que les clés manquantes n'entraîneraient pas d'erreurs ou de résultats incomplets.

J'ai résolu les deux questions en utilisant JavaScript et j'étais convaincu que mes solutions avaient réussi tous les cas de test, y compris les cas cachés.

Amazon a tendance à faire avancer les candidats dans le processus s'ils résolvent toutes les questions de codage et que tous les cas de test réussissent.

Après cela, j'ai reçu un appel du recruteur disant qu'il allait de l'avant avec le processus d'entretien et qu'il s'agirait d'un entretien sur place. J'ai eu 5 jours pour me préparer.

Je travaille à distance depuis 3 ans et je ne suis jamais allé au bureau, donc j'avais plus peur à cause du bureau que des séries d'entretiens ??

Autres séries d'entretiens

Je suis allé au bureau d'Amazon, peu de candidats étaient déjà là. Nous sommes tous allés à des entretiens. J'ai eu 3 séries d'entretiens techniques ce jour-là.

1. Cycle de dépannage

Le premier tour était un entretien axé sur le dépannage. Dès que je suis entré dans la pièce, j’ai été accueilli par un intervieweur qui m’a apporté un soutien incroyable. Il a gardé le sourire tout au long de la séance, ce qui a contribué à apaiser ma nervosité.

Il m'a remis une feuille de papier et a posé plusieurs questions liées aux pannes du système, aux réseaux et aux couches réseau. L'approche qu'il a utilisée était particulièrement intéressante. Il m'a demandé de réfléchir d'abord aux solutions de base, m'encourageant essentiellement à résoudre le problème à partir de la base. Une fois que j'ai fourni une réponse, il a légèrement modifié le scénario, ajoutant plus de complexité à chaque étape.

Par exemple, après avoir discuté d'une panne de réseau, il a déplacé la conversation vers des couches plus profondes du réseau et m'a demandé ce que je ferais si les solutions standard ne fonctionnaient pas. Cela m'a poussé à penser de manière créative et à considérer différents points de défaillance d'un système, des problèmes les plus courants aux problèmes les plus complexes.

L'entretien m'a demandé d'attendre dehors, après quoi un recruteur est venu et m'a dit que je participerais au deuxième tour.

2. Cycle DSA

Le cycle suivant a consisté en une plongée approfondie dans les structures de données et les algorithmes (DSA). Cette fois, mon intervieweur était un SDE senior chez Amazon. Elle m'a accueilli avec une feuille de papier et m'a posé une question assez vaste et complexe. En le lisant, je me suis vite rendu compte que l’objectif principal était de trouver le chemin le plus court dans un graphique. Ce type de problème est courant lors des entretiens, mais peut devenir délicat lorsque des cas extrêmes sont impliqués, qu'elle était sûre d'inclure.

J'ai posé quelques questions de clarification pour bien comprendre le problème et ses différents scénarios. Une fois que je me suis senti en confiance, j'ai commencé à travailler sur une solution : écrire du pseudocode directement sur le papier. Au fur et à mesure que j'expliquais mon approche et ma logique, elle approfondissait continuellement ses recherches, me demandant pourquoi j'avais pris certaines décisions et comment je gérais différentes parties du graphique. Je l'ai accompagnée dans mon processus de réflexion, en discutant des compromis et des optimisations. Heureusement, j'ai pu résoudre la question complètement et correctement.

Une fois satisfaite de ma solution graphique, elle m'a interrogé sur la complexité temporelle et spatiale, que j'ai analysée et expliquée. Ressentant un sentiment d'accomplissement, je pensais que le tour se déroulait bien.

Cependant, elle est rapidement passée à une autre question plus difficile, impliquant cette fois la programmation dynamique (DP). Le problème impliquait une matrice dans laquelle différentes cultures devaient être plantées d'une manière qui suivait certaines règles. C’était une question plus complexe et j’ai pris mon temps pour bien la comprendre. J'ai posé plusieurs questions pour m'assurer de couvrir toutes les contraintes et tous les cas extrêmes.

J'ai écrit une solution de pseudocode, mais elle n'était pas entièrement optimisée. Elle m'a donné quelques cas de test, et même si mon code s'est exécuté avec succès sur environ 80 % d'entre eux, il y avait encore des cas extrêmes qui échouaient. Je devenais nerveux à ce stade et elle l'a remarqué. Heureusement, elle m'a offert un indice utile et j'ai essayé d'optimiser davantage ma solution. Malgré tous mes efforts, je n'ai pas réussi à trouver complètement la solution, probablement à cause de mes nerfs qui prenaient le dessus.

J'ai encore attendu dehors, je n'étais pas très content et confiant de ce tour, mais le recruteur est de nouveau venu et m'a dit que mon prochain tour était la conception du système. J'étais tellement heureux !

3. Cycle de conception du système

Le dernier tour de la journée était l'entretien de conception de système, et ce fut de loin la session la plus intense et la plus épuisante. L’intervieweur faisait partie de l’équipe d’architecture d’Amazon et, dès le début, j’ai pu dire que ce tour serait un défi. Nous avons commencé par une discussion sur mon CV, en nous concentrant sur mes projets passés et les décisions de conception que j'avais prises lors de travaux antérieurs. Il a posé plusieurs questions sur l'architecture des systèmes sur lesquels j'avais travaillé, approfondissant les détails de mes choix de conception et les compromis que j'ai faits.

Après cette première discussion, il m'a demandé de concevoir un système pour une plateforme de technologie éducative, avec un accent spécifique sur la fonctionnalité de streaming vidéo. L'objectif était de concevoir un système permettant aux enseignants de diffuser des sessions vidéo en direct et aux étudiants d'assister à ces sessions en ligne.

Nous avons commencé par l'architecture de haut niveau, en discutant des principaux composants tels que les serveurs vidéo, les bases de données et les API. J'ai expliqué mon approche pour gérer un grand nombre d'utilisateurs et garantir une expérience de streaming vidéo fluide. Il a continuellement posé des questions sur les problèmes d'évolutivité, de fiabilité et de latence, qui sont cruciaux pour une plate-forme de vidéo en direct.

Une fois que nous avons abordé la conception de haut niveau, il a déplacé la conversation vers les détails de bas niveau. C'est là que la discussion est devenue plus technique. Nous avons exploré diverses approches pour optimiser le système, gérer les cas extrêmes et garantir une expérience transparente aux utilisateurs, même dans les pires scénarios. J'ai dû réfléchir rapidement, proposer des solutions et des alternatives à différents problèmes, notamment gérer les pics de trafic d'utilisateurs et garantir un temps d'arrêt minimal.

L'intervieweur a continué à présenter différents scénarios : que se passe-t-il si un serveur vidéo tombe en panne ? Comment géreriez-vous la congestion du réseau ? Comment garantir une faible latence aux étudiants de différentes régions géographiques ? Chaque scénario nécessitait une réponse détaillée et je me suis retrouvé complètement plongé dans la discussion des possibilités et des modèles de conception.

L'entretien complet a duré environ une heure et demie et à la fin, j'étais épuisé. C’était mentalement épuisant, mais aussi l’un des entretiens les plus perspicaces que j’ai jamais eu. Nous avons exploré divers défis architecturaux, et cela ressemblait plus à une séance de résolution collaborative de problèmes qu'à un entretien traditionnel.

Je suis donc allé au bureau d'Amazon à 9 heures du matin et je suis ressorti à 17 heures du soir, J'ai terminé toutes mes tournées et le recruteur a dit qu'il avançait dans la tournée managériale, qui n'est pas encore programmé.

Quoi qu'il en soit, j'ai oublié de vous dire une chose. Veuillez comprendre tous les principes d'Amazon avant de vous rendre à l'entretien, ils poseront au moins 2 questions à ce sujet à chaque tour. Alors s'il vous plaît, préparez-le aussi