Comment concevoir un système arbitraire dans une interview? [fermé]

Une question courante dans Tech Interview consiste à concevoir un système particulier, généralement un produit existant de la société. Par exemple, "Créer des documents Google".

Quelle est la réponse attendue pour une telle question? Je veux dire, de tels systèmes ont sûrement une conception complexe qui dépasse le cadre de toute interview. Qu'attendent les intervieweurs dans un délai aussi court?

Découvrez comment votre cerveau examine ce problème. Voici quelques points de départ que j'ai pu voir pour savoir comment on pourrait essayer d'avoir cette conversation:

• De haut en bas - À partir d'un niveau très élevé, créez un dessin et étoffez celui-ci à mesure que divers composants sont réalisés. Voici une poignée de composants que je pourrais voir ....

• De bas en haut - Voici une liste de morceaux 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 pour cette conception. Vous pouvez essayer de faire en sorte qu'une personne code un traitement de texte très simplifié ou de dépenser des centaines de millions de dollars pour créer le système de gestion de documents ultime que vous considérez comme la façon dont Google Doc est utilisé à l'extrême. La possibilité de demander quelque chose comme: "Qu'entendez-vous par Google Doc? Combien de fonctionnalités souhaitez-vous dupliquer?" des questions aussi.

La clé est de savoir comment bien communiquer vos idées et votre approche sur la résolution de ce type de problème, car un utilisateur peut s’approcher de vous et demander: "Psst, pourriez-vous faire quelque chose comme ça dans 2 semaines?" cela pourrait effectivement arriver. Ainsi, la façon dont vous donnez la réponse est plus importante que ce qui 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 le type de créativité et d’aptitudes à la communication dans un nouveau domaine plutôt que de simplement rappeler comment quelque chose a été fait dans le passé. Il y a des chances que, même si quelque chose qui se produit dans le nouveau poste ressemble à 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, bien que ce qui peut être construit soit similaire à une application existante, diverses personnalisations peuvent rendre la solution très différente de l'exemple initial.

Les entretiens vont dans les deux sens. Les gestionnaires et les autres développeurs maîtrisent rarement les entretiens. Je ne suis donc pas sûr de comprendre l'intérêt d'essayer de dire qu'ils devraient être des experts en la matière lors des entretiens d'embauche. Les recruteurs que je voyais bien s’attendaient à savoir comment faire une entrevue, mais de nombreux recruteurs médiocres pourraient servir d’exemples pour expliquer pourquoi ce n’est pas toujours une bonne idée.

En particulier pour les développeurs expérimentés, je pense que ces questions peuvent être très bonnes. Ils montrent qu'un développeur est capable de passer d'une description longue et compliquée à une implémentation réaliste. Même avec un système totalement inconnu, vous devriez pouvoir 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 parties plus gérables; identifiez éventuellement les interfaces ou les objets qui pourraient être nécessaires, ou divisez la logique en interfaces frontales, principales, principales, bases de données, etc.
• Démontrer une connaissance de la structure et des concepts à la base de ce type de système, par exemple les applications Web dans le cas de Google Docs.
• Indiquez 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 intervient avec une spécification et dit: "Que faudrait-il pour construire cela?"

Cette question est simplement 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 ..." "Concevoir un ensemble de tables de base de données relationnelles pour ces données ...", etc., qui seraient donnés aux développeurs de niveau débutant à intermédiaire. Dans les développeurs de niveau inférieur, l'intervieweur peut évaluer le potentiel de croissance à long terme de la personne dans l'entreprise ou simplement voir ce qu'il fait lorsqu'il est confronté à 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 par la façon dont vous envisagez de résoudre le problème, quelles questions vous poseriez, quelles questions identifieriez-vous, etc.

Dans Google Docs, par exemple, les problèmes évidents sont le stockage, la sécurité, l’évolutivité, la disponibilité, la conception de l’interface client, la compatibilité du navigateur, etc. Comment répartiriez-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 les documents "abandonnés" (éléments qui n'ont pas été consultés ou modifiés depuis longtemps)?

Encore une fois, l’important n’est pas de résoudre ces problèmes, mais de les identifier , d’en parler, de réfléchir un peu sur la façon de les résoudre, etc.

Je suis l'une de ces personnes coupables qui posent souvent ce type de question en entrevue. (Pour mémoire, je pose également des questions similaires sur leur "projet favori".) La raison pour laquelle je pose cette question est que c'est quelque chose que nous faisons fréquemment ici. Nous avons des ingénieurs de conception de tous les côtés d'une interface, un ingénieur systèmes, un test et une personne connaissant les cas d'utilisation client pour cette fonctionnalité. Nous nous tenons autour d'un tableau blanc et disons: "D'accord, comment allons-nous construire cette chose?" Vous connaissez souvent très peu la nouvelle fonctionnalité à ce moment-là et vous y êtes uniquement en raison de votre expertise dans votre partie du système, mais vous devez toujours contribuer de manière productive. Ce n'est pas simplement un exercice théorique hypothétique.

En ce qui concerne le type de réponses que j'attends, prenons, par exemple, la conception d'un système permettant de télécharger un nouveau micrologiciel depuis un serveur, via 20 cartes de ligne intégrées dans un bureau central, afin de mettre à niveau 5 000 décodeurs sur le terrain. Supposons qu'il y ait très peu de capacité disponible sur la liaison entre le serveur et les linecards.

Mauvaise réponse:

Euh, j'utiliserais probablement Ethernet ou quelque chose comme ça.

Bonne réponse:

Quelle est la taille d'une image? [Environ 7 Mo.] Eh bien, vous voudriez vous assurer que le service n'a pas été affecté pendant le téléchargement. Vous aurez besoin de davantage de mémoire flash ou de RAM pour stocker deux images à la fois. Vous voudrez probablement mettre l’image en cache sur vos cartes de ligne afin d’éviter de télécharger sans cesse la même image à partir du serveur. Étant intégrées, vos cartes de ligne ont probablement elles-mêmes un nombre limité de processeurs. Par conséquent, vous devrez peut-être sérialiser les téléchargements afin de laisser une capacité suffisante 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 avez besoin d'un moyen d'identifier l'image à envoyer.

Ce sont des transcriptions presque mot pour mot de deux candidats différents. La plupart des candidats se situent quelque part entre les deux, mais finissent généralement par y arriver avec un peu d'inspiration, ce qui est parfaitement correct. Nous ne cherchons pas le prochain Einstein ici, mais simplement une indication que vous pouvez réellement raisonner intelligemment sur le type de problèmes sur lesquels nous travaillons tous les jours.

Je pose aussi ce genre de question et je suis d’accord avec la plupart des autres réponses. Cela aiderait peut-être les personnes interrogées à comprendre POURQUOI ce type de question est-il important? Supposons que nous ayons une décision commerciale importante à prendre et que, pour ce faire, nous devions créer un nouveau système. Si quelqu'un se précipite vers vous et vous demande ce qu'il faudrait pour construire un système prenant en charge X, pouvez-vous leur donner une réponse perspicace qui prédit les principaux défis et les ressources nécessaires?

Un programmeur junior n'a aucune idée par où commencer. Ils ne sont pas prêts à commencer à parler sans spécification détaillée. Un programmeur expérimenté constatera instantanément que le problème présente de nombreuses facettes et tentera de relever le défi. Il n'est pas nécessaire de concevoir chaque aspect, il suffit d'identifier un défi architectural et de déterminer ensuite comment le résoudre.

Considérez le problème de Google Docs:

Une chose intéressante est l’échelle de cisaillement des demandes à venir. Vous ne pouvez pas obtenir un seul serveur et y déployer votre code - il s'agit d'une entreprise plus vaste. Une personne interrogée qui réussit peut se concentrer sur ce problème et décrira les types de ressources qui seront nécessaires, ainsi que certains des problèmes techniques liés à la mise en œuvre à cette échelle, avec une application non seulement state, elle partage le même état entre plusieurs utilisateurs.

Une autre chose intéressante à propos de Google Documents est que plusieurs personnes peuvent modifier en même temps. Une personne interrogée ayant réussi pourra discuter des mécanismes permettant de s’assurer que le document obtenu n’est pas déréglée, et un candidat vraiment formidable 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 discutez-vous des variantes: un éditeur de document partagé pour l'écriture de code devrait probablement utiliser une méthode de résolution des conflits différente de celle de Google Doc classique, car les conséquences sont différentes pour des événements se déroulant dans un ordre différent ou ayant une structure légèrement différente.

Il n'y a pas de bonne façon de créer une application telle que Google Documents, vous n'avez pas à identifier ce que vous feriez pour chaque échange, mais il est vraiment génial de trouver un domaine présentant un problème intéressant et d'expliquer clairement le -offs pourrait être.

-t.

Je soupçonne que les intervieweurs veulent entendre:

Google Doc est une interface Web pour un traitement de texte. Les documents de l'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 ordinateur différent.

Que voudriez-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 recherche l’intervieweur, c’est: pouvez-vous examiner un problème ou un produit et en extraire le design?

Pour moi, si la personne ne commence pas par identifier les cas d'utilisation / histoires clés, cela serait suffisant pour savoir qu'elle n'est pas préparée pour un poste nécessitant cette compétence particulière.

Ensuite, ils devraient pouvoir proposer 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, autrement que pour les extraire de leur ... Je ne m'attendrais pas à beaucoup plus d'une situation d'entretien pour une solution.

Cependant, je pourrais choisir 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. Par conséquent, je ne pouvais vraiment pas les pénaliser pour ne pas avoir tenu compte de ces problèmes, car il ne leur restait plus beaucoup de temps et je pense qu'il est raisonnable pour eux de penser que, compte tenu de tous les scénarios possibles, une entrevue limitée dans le temps ne devrait pas être envisagée.

J'ai récemment eu une entrevue au cours de laquelle on m'a demandé de concevoir un système de commande d'ascenseur. En gros, 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 avantages de la solution que vous donnez, et si vous êtes capable de gérer des problèmes complexes.

Je pense qu’une chose importante à faire est de poser des questions sur les exigences. Ne faites pas que des hypothèses qui permettront à la solution de votre animal de compagnie de fonctionner. Par exemple, il se peut que vous connaissiez une méthode vraiment astucieuse pour l’impression de documents que vous pourriez être tenté de décrire directement. Mais Google Docs n'imprime pas directement. il produit un PDF que le client imprime ensuite. Donc, si vous commencez par cela, vous aurez perdu la moitié de votre temps à résoudre un problème qui ne fait pas partie du problème et à démontrer que vous êtes plus intéressé par l'utilisation de votre technologie de pointe que par la résolution du problème du client.

Afin de traiter ce type de questions d’entrevue, vous devez 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 que vous jugez 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 oubliez la plupart de ce que vous avez lu (car ces informations ne sont en aucun cas liées à votre travail), il se peut qu'il y ait des petites choses 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 passe-temps) et cherche à savoir si vous avez l'habitude de recueillir des graines d'idées à des endroits aléatoires.

Le but de poser ce genre de question est de mieux comprendre 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, prenez d’abord en considération les structures de données (celles qui pourraient être utilisées pour le problème, puis celles plus appropriées ou plus spécifiques avec le pourquoi de la décision).

Ceci est un must pour les postes de développement supérieurs. Il est à la fois ridicule et inutile 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 correspond à ce à quoi je m'attendrais à ce niveau.