Ceux qui me connaissent le savent déjà : Microsoft est la société que je souhaite de tout cœur intégré depuis déjà de nombreuses années. Récemment, j’ai eu la chance de pouvoir passer des entretiens, le 3 Décembre 2013, au QG de Microsoft à Redmond, près de Seattle aux Etats-Unis, afin de décrocher un stage d’été.

On m’a beaucoup demandé quelles questions on m’a posé là-bas, j’écris donc cet article pour vous le faire partager.

Je ne remercierais jamais assez les personnes qui m’ont soutenu et aidés à obtenir ces entretiens. Ils se reconnaîtront j’en suis sûr.
Voici ci-dessous comment s’est déroulé mon entretien pour un stage (c’est apparemment légèrement différent pour un job).

Arrivé au campus

J’étais attendu à 10h au bâtiment 111 du campus de Microsoft, un bâtiment de recrutement. J’y ai rencontré les autres étudiants qui venaient passer des entretiens. Nous étions une vingtaine. D’après ma recruteuse j’étais le seul Européen ce jour-là. Tous les autres étaient canadiens ou américains.

On a commencé par nous offrir un petit déjeuner, puis on nous a expliqué comment allait se dérouler la journée. J’ai ensuite été appelé par ma recruteuse pour passer un simple entretien purement Ressources Humaines : on m’a demandé de me présenter, quelle est mon école, en quel année je suis, quand se déroule mes stages habituellement et qu’est-ce que je fais en France en tant que Microsoft Student Partner et Ambassadeur Microsoft.

La recruteuse m’a ensuite présenté les différents entretiens que j’allais avoir et let’s go !

Premier entretien technique

Avant d’arriver aux Etats-Unis, j’ai dû expliquer par email quel domaine m’intéresse le plus, en l’occurrence, être SDE (Software Development Engineer Intern) et de préférence dans la division Visual Studio, qui demeure m’a plus grande source d’inspiration pour développer SoftwareZator.
Par conséquent, je me suis retrouvé à passer tous mes entretiens techniques dans la division Visual Studio, qui regroupe le logiciel Visual Studio, le .Net Framework, le site visualstudio.com et TFS (Team Foundation Service).

Ce premier entretien s’est déroulé dans le bâtiment 18, avec un développeur qui travaille sur Visual Studio. Après avoir fait connaissance (qu’est-ce que j’aime, quel est mon parcours rapidement, quels langages j’ai déjà manipulés…), il m’a demandé de réaliser un exercice sur tableau blanc : écrire un algorithme pour calculer une suite factorielle.

Ma première idée a été d’utiliser la récursivité. Mon algorithme était correct à mon premier avis.
Remarque du développeur : « Ok, ça fonctionne. Que se passe-t-il si j’utilise un énorme nombre? » – Ça a tout de suite fait tilt dans ma tête – « On aura un Stack Overflow. »

J’ai donc proposé une nouvelle solution : calculer la factorielle via une simple boucle For, en partant du factoriel, jusqu’à 0. C’était correct (et mieux du coup). Nouvelle question du développeur : « Que se passe-t-il si le factoriel voulu est négatif? » – Moment de réflexion car mon niveau en mathématiques est médiocre – « C’est impossible. Du coup on peut mettre une condition et lever une exception ». L’idée convenait.

Une heure s’était déjà écoulé durant ce premier entretien technique. Il était midi, on m’a accompagné jusqu’à l’entretien suivant.

Second entretien technique

Je me suis retrouvé avec développeur B.I, dans le même bâtiment. Je ne me sens pas très alaise en SQL, et il m’a expliqué que ça faisait longtemps qu’il n’avait pas codé autrement que dans un cade B.I. On était donc un peu à l’étroit, mais étant donné que ce qui les intéresse le plus est ma façon de penser et non le résultat au problème posé, ça n’a pas vraiment posé problème.

Au début, avant de passer un véritable entretien technique, nous nous sommes rendu au restaurant du campus le plus proche (je suppose, je n’ai pas vraiment eu la possibilité de visiter en détail). En attendant d’être servi, il m’a expliqué qu’il avait jeté un coup d’œil à mon site internet (via le CV que j’avais envoyé), qu’il le trouvait « awesome », et il m’a posé de nombreuses questions sur SoftwareZator, notamment comment j’ai eu cette idée de projet (histoire très simple et un peu fun que j’adore raconter). Il m’a également demandé pourquoi je souhaitais travailler chez Microsoft et, question qui m’a semblé étrange, pourquoi j’avais un Windows Phone.

Le restaurant étant bruyant et étant pressé par le temps (1h par entretien), nous avons mangé dans une petite salle de réunion, en même temps que je répondais à ses questions techniques. Autant le dire tout de suite : je n’avais pas vraiment mangé du coup.

Venons au problème technique posé : j’ai un tableau d’objets contenant des Class de différents types et j’aimerais stocker ces Class dans le Cloud. On a déjà le nom du fichier / le clée qui devra être enregistré dans le Cloud. Ecrire un algorithme / une méthode qui illustrerait ça.

J’ai mis à l’épreuve les quelques connaissances en Windows Azure que j’ai acquises durant mon dernier stage à DCube. J’ai donc tout de suite parlé d’un Blob Storage et d’une sérialisation binaire. « J’ai oublié de dire que j’aimerais que la donnée soit lisible sans avoir besoin de désérialiser ». J’ai donc finalement proposé une sérialisation XML.

L’algorithme était très simple, je devais seulement faire attention aux éventualités du type « si la connexion au Blob Storage se coupe » ou encore « si le fichier stocké existe déjà »…etc

Troisième entretien technique

Cette fois-ci, je me suis déplacé dans le bâtiment 25 du campus. Je me suis retrouvé cette fois-ci avec le Principal Development Lead .Net Framework. C’était un peu un honneur pour moi de rencontrer cette personne. Le .Net étant la technologie qui m’a donné envie de développer sous Windows.
Il m’a dans un premier temps demandé de raconter comment s’est passé mon dernier stage et qu’est-ce que j’y ai fait, à savoir : ASP.Net+MVC, Azure, Kinect, Parsing HTML.

Nous sommes très rapidement venu à un exercice technique : On a une table contenant un index associé à une URL du type « http://monsite.com/caejdb ». Exemple :

1 http://monsite.com/a
2 http://monsite.com/b
3 http://monsite.com/c
26 http://monsite.com/z
27 http://monsite.com/aa
28 http://monsite.com/ab

Le but était d’écrire un algorithme qui génère et ajouter la prochaine URL à la table.

Ma première idée a été vraiment moche : récupérer le dernier élément de la table, découper la chaîne de caractère, l’analyser et générer la nouvelle selon la précédente. Idée complexe et peu optimisée, les traitements sur chaînes de caractères étant longs. J’ai alors tenté de rectifier le tire (je n’avais pas commencé à écrire l’algorithme, juste présenter l’idée) en disant que l’on pouvait sûrement faire plus optimisé, mais tout de suite, je ne voyais pas comment.

La personne m’avait expliqué (à la fin de l’entretien) qu’il venait du Texas. Ça explique sûrement pourquoi j’ai eu beaucoup (mais VRAIMENT beaucoup) de mal à comprendre ce qu’il me disait, à cause de son accent.

Il voulait juste m’expliquer que l’on pouvait générer ce type d’URL de manière purement mathématique, via l’index dans la table. Je ne vous cacherais pas que j’ai passé peut-être 10 minutes à essayer de le comprendre, en lui faisant répéter de manière différentes 4 ou 5 fois, avec la peur au ventre de l’agacer.

Une fois compris (il était temps) ce qu’il voulait m’expliquer, ça m’a en effet semblé logique, et j’ai écrit un algorithme qui traduit le dernier index + 1 de la table en une chaîne de caractère en me basant sur une table ASCII fictive (ne la connaissant évidemment pas par cœur et lui non plus). Au final, ça se traduisait par une simple boucle While avec une division dedans. Facile !

Facile, mais tout de même un goût amer, dégoûté d’avoir mis autant de temps à comprendre et d’avoir proposé dans un premier temps une solution si longue et si coûteuse en CPU.

Mon dernier entretien de la journée approchait. J’ai eu le droit à une pause de 15 minutes environ, histoire de se reconcentrer. J’avoue qu’après 3 entretiens en Anglais (une première pour moi) et la dose de stress associé à ce dernier, j’étais un peu lessivé.

Quatrième entretien technique

Dans le même bâtiment, je me suis retrouvé avec un nouveau développeur (j’avoue ne pas avoir retenu sa fonction précise). Il m’a demandé si j’avais déjà fait un projet de fin d’année dans mon école. Il est très rapidement venu à me demander comment c’était passé le travail dans mon équipe, et comment je travaillais dans mon dernier stage. J’ai tout de suite compris que son but était de voir si je savais travailler en équipe. J’ai donc été honnête : la gestion du projet de fin d’année n’a pas été des plus vertes, on avait utilisé GitHub (c’était un très bon point pour un projet de première année), et en stage, au mieux j’ai travaillé à deux, avec TFS que je manipule depuis plus d’un an déjà. J’ai rajouté mes quelques connaissances avec Scrum que j’ai découvert en entreprise.

On est ensuite passé à l’exercice technique : dans Visual Studio, dans l’Explorateur de Serveur, j’ai un bouton « Actualiser », qui actualise le contenu d’une arborescence sans refermer tous les nœuds de celle-ci. Ecrire un algorithme qui réalise cette fonctionnalité.

J’ai dans un premier temps proposé de garder en mémoire les TreeNodes, de vider l’arborescence et de la recharger, puis d’étendre les nœuds qu’on avaient gardés en mémoire. Mais l’on m’a fait remarquer qu’il y a peu de points de comparaisons dans un TreeNodes pour être sûr d’assurer aucune confusion entre l’identité de deux nœuds.

Pour répondre au problème, j’ai proposé d’associer à chaque nœud un Id unique, par exemple « HostServeur_NomTable », selon le contenu du nœud et des nœuds parents. On garde en mémoire l’Id des nœuds qui sont ouverts. Une fois l’arborescence rechargée, on étend les nœuds dont l’Id a été conservé en mémoire.

Cette fois-ci, ça semblait correct aux yeux de mon examinateur. On a eu un peu d’avance sur le temps, j’en ai donc profité pour poser quelques questions sur le déroulement des stages à Microsoft, en particulier comment un stagiaire étranger peut vivre 3 mois le temps d’un stage. La réponse : je suis hébergé sur place dans des appartements réservés aux stagiaires.

Retour au bâtiment de recrutement

De retour au bâtiment 111, il étant environ 15h30-16h. J’ai revu ma recruteuse qui m’a indiqué en privé qu’elle avait eu de bons retours sur mon cas. C’était très gentil de sa part, quelque peu rassurant.

Le lendemain, retour à l’aéroport de Seattle, 10 minutes avant l’embarquement, j’ai reçu la réponse : je suis pris, de Juillet à fin Septembre 2014. 😀 😀 😀

Voilà, j’espère que cet article sera un peu utile aux prochains français qui iront passer un entretien de stage à Redmond.

Oh, sinon, Seattle-Bellevue-Redmond, c’est très jolie 🙂 J’irais jouer les touristes les week-ends cet été.