Je suis un ingénieur travaillant pour Amazon qui est impliqué dans leur processus d'entretien, alors je vais rester anonyme, juste au cas où :). Je pense que ces considérations sont quelque chose que la plupart des entreprises technologiques de haut niveau utiliseront et pèseront dans leur processus, mais qui sait. Elles ne doivent pas être considérées comme des "secrets commerciaux". Je m'attends à ce que, si je lance ma propre entreprise un jour, j'emprunte probablement certains de ces concepts, car je les aime personnellement.
Je suppose que cette question est liée aux rôles de SDE ? Disclaimer : je dois noter que je ne peux pas représenter Amazon dans son ensemble ; il s'agit de mon opinion personnelle sur le processus.
Que recherche Amazon dans l'évaluation en ligne ?
Que vous ayez des compétences décentes en matière de résolution de problèmes et que vous puissiez coder suffisamment, dans une limite de temps. Que lorsque vous serez amené à passer un entretien, vous tiendrez le coup et saurez coder.
Il est ici avantageux de connaître un maximum de structures de données et d'algorithmes et de savoir les utiliser, dans au moins un langage populaire. Java ou C++ est probablement le plus idéal. Cela dépend du poste pour lequel vous passez l'entretien et de l'organisation d'Amazon, mais en général, vous êtes testé sur des structures de données que vous pouvez utiliser au quotidien, telles que les graphes, les arbres, les listes, les piles, les files d'attente, les ensembles et les cartes/dictionnaires. Les algorithmes sont généralement basés sur des cas d'utilisation, c'est-à-dire qu'on ne vous demande pas d'emblée d'écrire un algorithme de tri ou un algorithme de traversée d'arbre ou de graphe. En fonction des exigences, vous pouvez avoir besoin d'en utiliser un, et dans ce cas, vous êtes autorisé à utiliser des implémentations de bibliothèques de base.
Une bonne règle de base (qui s'applique également aux entretiens) est d'essayer de répondre au problème comme vous le feriez si vous étiez déjà embauché. Par exemple, réimplémenteriez-vous vraiment un mergesort ou un quicksort vs. utiliser une implémentation bien testée pour le tri qui existe déjà ? Gagnez du temps, ne le faites pas, à moins que l'on vous demande clairement et spécifiquement de le faire. Vous devez avoir une très bonne raison de réinventer une roue.
Que recherche Amazon lors de ses entretiens ?
Nous sommes intéressés par votre adéquation à la culture, vos compétences en matière de résolution de problèmes et si vous êtes un candidat " exceptionnel ". Si vous êtes embauché et que vous vous impliquez davantage dans l'entreprise, vous apprendrez la terminologie spécifique à ces concepts au sein d'Amazon ; je ne les utilise volontairement pas, car je pense que ces concepts ne sont pas uniques à Amazon, ils ont juste une " marque " spécifique.
Pour l'adéquation à la culture, il s'agit de montrer que vous êtes personnellement intéressé à améliorer les choses pour nos clients, et comment vous vous intégrerez à l'équipe. Pour cela, il s'agit de donner avec précision les points forts de votre expérience dans le secteur. Cela vaut la peine de passer en revue votre historique et de comprendre les cas où vous avez profité à votre équipe par votre prise de décision et votre communication, et/ou les cas où vous avez dû comprendre un problème difficile et les mesures que vous avez prises pour le résoudre. Il y a plusieurs facettes différentes ici, il est donc important de se préparer. Si vous n'avez pas suffisamment d'expérience dans l'industrie sur laquelle vous pouvez vous appuyer (bien que vous devriez également essayer de vous appuyer sur votre expérience à l'université/à l'école en premier lieu), vous devriez parler honnêtement et laisser l'interviewer déterminer comment procéder. Ne rien avoir ici ne vous fait pas échouer, cela signifie simplement que nous nous concentrerons davantage sur les autres choses que vous apportez.
Pour la résolution de problèmes, il s'agit de montrer que vous êtes capable de "faire le travail", et le codage peut ou non être impliqué (chaque créneau d'entretien est différent). C'est la plus complexe des trois facettes ; elle nécessite que l'interviewer vous transmette bien son problème, que vous le compreniez bien, et que vous soyez capable de lui transmettre bien votre réponse, soit en code et/ou en explication. Pour cela, je vous dirais d'essayer de faire comme si vous étiez déjà embauché : quelles questions pourriez-vous/devriez-vous leur poser pour mieux comprendre ce problème avant de vous lancer ? Qu'est-ce qui les intéresse vraiment ? Il est important d'essayer de voir d'où vient l'intervieweur et comment lui donner ce qu'il recherche ; chaque intervieweur (car nous sommes tous humains) est différent. Il est également important de savoir que certains intervieweurs insisteront pour obtenir un ensemble spécifique de détails que vous ne serez peut-être pas en mesure de leur fournir. Si vous pouvez reconnaître cela, il est important d'être honnête et de dire à l'interviewer que vous ne savez pas ou ne comprenez pas ce qu'il demande, et il modifiera idéalement le problème pour vous donner une meilleure occasion de le résoudre. Ces situations ne sont jamais idéales ; plus vous en savez sur les structures de données et les algorithmes et plus vous savez reconnaître quand un problème vous demande d'en utiliser un plutôt qu'un autre, moins souvent cela devrait se produire.
Pour être un candidat " exceptionnel ", il s'agit de montrer que pour le poste dans lequel vous êtes embauché, vous pouvez être meilleur que les pairs avec lesquels vous travaillerez, et que vous évoluerez et prendrez plus de responsabilités avec le temps. C'est là que la réussite de l'entretien peut être la plus volatile ; je ne pense pas qu'une entreprise, y compris Amazon, ait trouvé un moyen juste ou raisonnable d'évaluer cela de manière constante. Tout ce que je peux dire, c'est que la raison pour laquelle vous serez interviewé par plusieurs personnes est que nous pouvons essayer de nous faire une idée objective de la façon dont vous travaillerez chez Amazon. Il est important que vous soyez personnellement intéressé à aider nos clients, et il est important que vous soyez intéressé à devenir un meilleur programmeur/ingénieur/etc.
En conclusion, nous voulons spécifiquement vous embaucher si vous êtes personnellement intéressé et capable de servir nos clients, et cela se joue de plusieurs façons, couvertes ci-dessus. Si vous n'êtes pas intéressé à devenir un meilleur programmeur/ingénieur/etc, alors vous ne nous aiderez pas à servir nos clients. Le codage sur tableau blanc est probablement la partie la plus discutable de toute l'expérience, mais il est là pour vous aider à faire vos preuves. Vous n'avez qu'une heure pour impressionner la personne qui vous interroge ; comment allez-vous l'impressionner ? Dire que vous aimez les clients d'Amazon est une chose ("talking the talk"), mais montrer que vous examinez attentivement les problèmes d'Amazon, leurs exigences, et que vous êtes capable de travailler sur des solutions pour eux, cela aide à le confirmer ("walk the walk"). Si vous êtes capable de faire ces choses de manière cohérente, vous passerez un bon entretien.
Ne vous gênez pas pour demander des détails supplémentaires, si nécessaire.
Comment l'évaluation est-elle " notée " ? Est-ce que vous ne passez à autre chose que si vous réussissez les deux questions de manière optimale à chaque cas de test passé ? Le code/solution est-il examiné par un humain pour déterminer où se trouvait l'erreur ou les erreurs ?
Pour autant que je sache, l'évaluation en ligne peut différer entre les organisations chez Amazon en ce qui concerne la façon dont vous êtes noté. Parmi les organisations avec lesquelles je travaille, le code/solution est généralement examiné par des ingénieurs (humains 🙂 pour déterminer les erreurs et faire l'appel de jugement final pour l'accepter ou non. Il est, à ma connaissance, possible de passer avec une solution imparfaite, tant que l'approche globale semble être correcte et qu'elle répond à la plupart des cas limites. Il est bon d'être proactif en indiquant les compromis de votre approche et en effectuant des tests sur celle-ci. Il est également bon, comme indiqué précédemment, de ne pas suringénier la solution (par exemple, essayer de réimplémenter quicksort ne fonctionne presque jamais bien). Réussir tous les cas de test pour toutes les questions est définitivement préférable (cela rend beaucoup plus facile pour nous d'examiner et de noter la solution).
Nous essayons de faire des examens " humains " pour la sanité, car certaines solutions dans le passé ont réussi à exposer des bugs dans le correcteur d'évaluation et/ou des incohérences dans la présentation du problème. Nous avons fait ce que nous pouvions pour itérer et améliorer les problèmes d'évaluation, et cela inclut également l'échantillonnage contre les ingénieurs qui travaillent chez Amazon.
.