Comment concevoir un système arbitraire dans une interview?
Une question courante dans Tech Interview est de concevoir un système particulier, généralement un produit existant de l'entreprise. Par exemple, "Concevoir Google Docs".
Quelle est la réponse attendue à une telle question? Je veux dire, ces systèmes ont sûrement une conception complexe qui dépasse la portée de toute interview. Qu'attendent les enquêteurs en si peu de temps?
Découvrez comment votre cerveau regarde ce problème. Voici quelques points de départ que j'ai pu voir pour voir comment on pourrait essayer d'avoir cette conversation:
De haut en bas - En regardant d'un niveau très élevé, élaborez un design et étoffez-le au fur et à mesure que divers composants sont réalisés et voici une poignée de composants que je pouvais voir ...
De bas en haut - En regardant de bas en haut, voici des éléments que l'on pourrait construire pour essayer de rassembler ....
Clarification des exigences - Poser des questions sur l'échelle, la taille, le budget et l'équipe projetés utilisés pour cette conception. Vous pouvez essayer de faire coder une personne par un traitement de texte très simplifié ou vous pouvez planifier de dépenser des centaines de millions de dollars pour créer le système de gestion de documents ultime qui, selon vous, est la façon dont votre document Google a poussé à l'extrême. Ici aussi, vous avez la possibilité de demander quelque chose comme: "Que voulez-vous dire par Google Doc? Combien de fonctionnalités voulez-vous dupliquer?" questions aussi.
La clé est de savoir dans quelle mesure pouvez-vous communiquer vos réflexions et votre approche sur la manière de résoudre ce type de problème, car vous pouvez vous faire approcher par un utilisateur et vous demander: "Psst, pourriez-vous faire quelque chose comme ça en 2 semaines? cela pourrait effectivement arriver. Ainsi, comment vous donnez la réponse est plus important que quelle est la réponse.
Mon opinion personnelle serait que les projets passés ne sont pas une bonne idée ici. Ce que l'on essaie de trouver, c'est quel type de créativité et de communication dans un nouvea domaine plutôt que de simplement rappeler comment quelque chose a été fait dans le passé. Il y a de fortes chances que même si quelque chose qui se passe dans la nouvelle position peut être similaire à quelque chose du passé, il peut y avoir juste assez de différences pour que l'ancienne solution ne soit pas réalisable. C'est pourquoi, alors que ce qui peut être construit est similaire à une application existante, il peut y avoir diverses personnalisations qui rendent la solution très différente de l'exemple initial.
Les entretiens sont une voie à double sens. Les gestionnaires et autres développeurs sont rarement maîtres des entretiens, donc je ne suis pas sûr de voir l'intérêt d'essayer de déclarer qu'ils devraient être des experts en la matière lors des entretiens d'embauche. Les recruteurs que je pouvais voir s'attendre à savoir comment faire une interview, mais il y a beaucoup de mauvais recruteurs qui pourraient être utilisés comme exemples de pourquoi ce n'est pas toujours une bonne idée.
Surtout pour les développeurs seniors, je pense que ces questions peuvent être très bonnes. Ils montrent qu'un développeur est capable de passer d'une description volumineuse et compliquée à une implémentation réaliste. Même avec un système totalement inconnu, vous devriez être en mesure de faire un certain nombre d'activités intéressantes pour l'intervieweur:
- Recueillir les exigences pour répondre à la question (par exemple, la portée)
- Décomposez le problème en morceaux plus faciles à gérer; identifier éventuellement les interfaces ou les objets qui pourraient être nécessaires, ou décomposer la logique en front-end, back-end, DB, etc.
- Démontrer une familiarité avec la structure et les concepts derrière ce type de système, par exemple, les applications Web dans le cas de Google Docs
- Montrez ce sur quoi vous avez tendance à vous concentrer lorsque vous rencontrez un problème de conception (conception d'objet? Tables SQL? Modèles de conception?)
- Montrez au patron un aperçu de ce que ce sera de développer un nouveau système avec vous, où le patron entre avec une spécification et dit: "Que faudrait-il pour construire cela?"
Cette question n'est qu'une version de niveau supérieur de "Décrivez la hiérarchie d'objets que vous utiliseriez pour cela ...". "Décrivez l'interface que vous concevriez pour cela ..." "Concevez un ensemble de tables de bases de données relationnelles pour ces données ...", etc. qui seraient données aux développeurs débutants ou intermédiaires. Dans les développeurs de niveau inférieur, l'intervieweur pourrait évaluer le potentiel de croissance à long terme de la personne dans l'entreprise, ou tout simplement voir ce qu'elle fait face à un problème important qui pourrait éventuellement être écrasant.
Il s'agit de voir vos processus de pensée en action; ils ne sont pas intéressés par une solution, mais comment vous aborderiez la résolution du problème, quelles questions vous poseriez, quels problèmes vous identifieriez, etc.
Compte tenu de l'exemple de Google Docs, les problèmes évidents qui viennent à l'esprit sont des choses comme le stockage, la sécurité, l'évolutivité, la disponibilité, la conception de l'interface client, la compatibilité du navigateur, etc. Comment diviseriez-vous la responsabilité entre le serveur et le client? Comment géreriez-vous les sauvegardes? Que se passe-t-il lorsqu'un serveur tombe en panne? Que feriez-vous avec des documents "abandonnés" (des choses qui n'ont pas été consultées ou modifiées depuis longtemps)?
Encore une fois, il ne s'agit pas de résoudre aucun de ces problèmes, mais d'identifier les, parler à travers eux, réfléchir un peu sur la façon de les aborder, etc.
Je fais partie de ces coupables qui posent fréquemment ce type de question lors des entretiens. (Pour mémoire, je pose également des questions similaires sur leur "projet préféré".) La raison pour laquelle je pose la question est que c'est quelque chose que nous faisons fréquemment ici. Nous obtenons des ingénieurs de conception de tous les côtés d'une interface, une personne de l'ingénierie des systèmes, une personne du test et une personne ayant une certaine connaissance des cas d'utilisation client pour la fonctionnalité. Nous nous tenons autour d'un tableau blanc et disons: "D'accord, comment allons-nous construire cette chose?" Souvent, vous en savez très peu sur la nouvelle fonctionnalité à ce stade et n'y êtes que grâce à votre expertise dans votre partie du système, mais vous êtes toujours censé contribuer de manière productive. Ce n'est pas seulement un exercice académique hypothétique.
En ce qui concerne le type de réponses que j'attends, prenez par exemple la conception d'un système pour télécharger un nouveau firmware à partir d'un serveur, via 20 linecards intégrés dans un bureau central pour mettre à niveau 5000 décodeurs sur le terrain à la fois. Supposons qu'il y ait très peu de capacité disponible sur la liaison entre le serveur et les linecards.
Mauvaise réponse:
Hum, j'utiliserais probablement Ethernet ou quelque chose comme ça.
Bonne réponse:
De quelle taille parle-t-on? [Environ 7 Mo.] Eh bien, vous voulez vous assurer que le service n'a pas été affecté pendant le téléchargement. Vous auriez besoin d'un flash supplémentaire ou RAM pour stocker deux images à la fois. Vous voudrez probablement mettre en cache l'image sur vos linecards afin d'éviter de télécharger la même image encore et encore depuis le étant embarqué, vos linecards ont probablement un processeur limité eux-mêmes, donc vous devrez peut-être sérialiser les téléchargements afin de laisser suffisamment de capacité pour le service. Vous voudriez un moyen de vérifier que l'image était bonne et de revenir à l'ancienne version si cela ne fonctionnait pas. Vous auriez besoin d'un moyen de réessayer plusieurs fois et de signaler les erreurs à un humain si la mise à niveau échoue. Si vous avez différentes marques de décodeurs, vous auriez besoin d'une sorte de moyen pour identifier lequel image dont vous avez besoin pour l'envoyer.
Ce sont presque des transcriptions Word pour Word de deux candidats différents. La plupart des candidats se situent quelque part entre les deux, mais arrivent généralement à la fin avec un peu d'incitation, ce qui est tout à fait correct. Nous ne cherchons pas le prochain Einstein ici, juste une indication que vous pouvez réellement raisonner intelligemment sur les types de problèmes sur lesquels nous travaillons quotidiennement.
Je pose également ce genre de question et je suis d'accord avec la plupart des autres réponses. Peut-être que cela aiderait les personnes interrogées à comprendre POURQUOI ce type de question est important? Supposons que nous ayons une décision commerciale importante à prendre, et pour ce faire, nous devons construire un nouveau système. Si quelqu'un se présente à vous et vous demande ce qu'il faudrait pour construire un système qui utilise X, pouvez-vous lui donner une réponse perspicace qui prédit les principaux défis et ressources nécessaires?
Un programmeur junior n'a aucune idée par où commencer. Ils ne sont pas prêts à commencer à parler sans spécifications détaillées. Un programmeur senior verra instantanément qu'il existe de nombreuses facettes à la question et tentera de relever un défi. Vous n'avez pas besoin de concevoir tous les aspects, identifiez simplement un défi architectural, puis déterminez comment y faire face.
Considérez le problème de Google Docs:
Une chose intéressante est l'échelle de cisaillement des demandes qui vont venir. Vous ne pouvez pas simplement obtenir un seul serveur et y déployer votre code - c'est une entreprise plus importante. Une personne interrogée qui réussit pourrait se concentrer sur cela et décrira les types de ressources qui seront nécessaires, et certains des défis techniques de la mise en œuvre à cette échelle, avec une application qui a non seulement un état, mais qui partage l'état entre plusieurs utilisateurs.
Une autre chose intéressante à propos de Google Docs est que plusieurs personnes peuvent modifier en même temps. Une personne interrogée réussie sera en mesure de discuter des mécanismes pour s'assurer que le document résultant n'est pas une ordure, et un très bon candidat se rendra compte que différentes méthodes de synchronisation ou de fusion des modifications auront un impact important sur les performances et l'expérience utilisateur. Peut-être même discuter de variantes: un éditeur de documents partagé pour écrire du code devrait probablement utiliser une méthode de résolution des conflits différente de celle de Google Doc, car les choses se produisent dans un ordre différent ou ont une structure légèrement différente.
Il n'y a pas de bonne façon de créer une application comme Google Docs, vous n'avez pas à identifier ce que vous feriez pour chaque compromis, mais c'est vraiment génial de trouver une zone qui a un problème intéressant et d'expliquer clairement ce que le commerce -Offs pourrait être.
-t.
Je soupçonne que les enquêteurs veulent entendre:
Google Doc est une interface Web pour un traitement de texte. Les documents utilisateur sont dactylographiés et stockés et peuvent être récupérés par l'utilisateur sur le même ordinateur ou sur un autre ordinateur.
De quoi aimeriez-vous discuter davantage?
Ensuite, la balle est dans le camp de l'intervieweur. Si elle veut plus de détails, elle peut demander. Ce que l'intervieweur recherche, c'est, pouvez-vous regarder un problème ou un produit, et extraire le design?
Pour moi, si la personne ne commence pas par identifier les cas d'utilisation/histoires clés, cela suffira pour savoir qu'elle n'est pas préparée pour un poste nécessitant cette compétence particulière.
Ensuite, ils devraient être capables de trouver une solution architecturale basée sur les cas d'utilisation/histoires clés. J'espère qu'ils ont utilisé un processus systématique pour identifier les modules autres que de les retirer de leur ... Je n'attendrais pas beaucoup plus d'une situation d'entrevue pour la solution.
Cependant, je pourrais choisir l'un des modules architecturaux et demander une conception plus détaillée, juste pour voir s'ils ont des compétences en conception. Il serait également agréable de voir qu'ils prennent en compte les cas d'échec/problèmes de performances. Mais je soupçonne qu'à ce stade, nous nous heurterions à un mur du temps. Ainsi, je ne pouvais vraiment pas les pénaliser pour ne pas avoir pris en compte ces questions car il n'y a que très peu de temps et je pense qu'il est raisonnable pour eux de supposer que l'examen de chaque scénario possible n'est pas attendu d'une situation d'entrevue limitée dans le temps.
J'ai eu une interview récemment où on m'a demandé de concevoir un système de contrôle d'ascenseur. Fondamentalement, ils veulent voir votre approche de la tâche. Si on vous pose cette question, ils ont probablement un travail de très haut niveau en tête pour vous. Félicitations.
L'essentiel est de savoir comment résoudre les problèmes par rapport aux mérites de la solution que vous proposez et si vous êtes capable de faire face à des problèmes à grande échelle.
Je pense qu'une chose importante à faire est de poser des questions sur les exigences. Ne vous contentez pas de faire des hypothèses qui permettront à votre solution pour animaux de compagnie de fonctionner. Par exemple, il se peut que vous connaissiez une méthode vraiment astucieuse pour imprimer des documents que vous pourriez être tenté de passer directement à la description. Mais Google Docs n'imprime pas directement; il produit un PDF que le client imprime ensuite. Donc, si vous commencez par cela, vous aurez passé la moitié de votre temps à résoudre un problème qui ne fait pas partie du problème, et vous avez démontré que vous êtes plus intéressé à utiliser votre technologie chaude qu'à résoudre le problème du client.
Afin de gérer ce type de questions d'entrevue, vous devrez avoir un intérêt général à comprendre "comment les choses fonctionnent", non seulement dans les projets qui vous intéressent, mais aussi dans les projets qui vous semblent trop éloignés de vos expériences.
Cela signifie lire des blogs, des articles, http://www.infoq.com , Hacker News, etc. Même les bluffs matériels de Coding Horror.
Malgré le fait que vous oublierez la plupart de ce que vous avez lu (parce que ces informations ne sont pas liées de toute façon à votre travail personnellement), il pourrait y avoir des morceaux qui sont les "graines de l'imagination", et une infime fraction de ces graines germera lorsque vous rencontrerez un problème similaire dans un avenir très lointain.
Ainsi, l'intervieweur s'intéresse peut-être à votre habitude de lire (dans le cadre de votre hobby) et voyez si vous avez l'habitude de collecter des graines d'idées à des endroits aléatoires.
Le point derrière la pose de ce genre de question est d'avoir un aperçu de votre esprit. Une question courante que j'utilise est de demander aux programmeurs de concevoir un système capable de simuler PacMan.
Et oui, je cherche d'abord des cas d'utilisation, cela me montre que la personne réfléchit. Ensuite, pour le multithreading, considérer d'abord les structures de données (celles qui pourraient être utilisées pour le problème, puis les plus appropriées ou spécifiques avec le pourquoi de la décision).
C'est un must pour les postes de développement supérieurs. Il est à la fois idiot et inutile pour les gens de s'asseoir et de répondre à des questions sur les implémentations de tri à ce niveau d'expérience de développeur. La conception du système est ce que j'attendrais à ce niveau.