Pourquoi les structures de données sont-elles si importantes dans les entretiens?
Je dois avouer que je n'étais pas aussi solide dans les structures de données lorsque j'ai obtenu mon diplôme universitaire. Tout au long des stages sur le campus pendant mes études, j'ai vu que la plupart des grandes entreprises technologiques comme Amazon, Microsoft, etc. se concentraient principalement sur les structures de données. Il semble que les structures de données soient la seule chose qu'ils attendent d'un diplômé.
Pour être honnête, je me sentais mal à ce sujet. J'écris du bon code. Je suis des modèles de conception standard de codage, j'utilise des structures de données mais au niveau superficiel comme dans Java API exposées comme ArrayList, LinkedList etc. Mais les entreprises se sont généralement concentrées sur les aspects complexes des structures de données comme la manipulation de la mémoire basée sur un pointeur et la complexité du temps.
Probablement à cause de mon Java background, à l'époque, je ne comprenais l'efficacité du code et la logique que lorsqu'on parlait de programmation orientée objet comme des objets, des instances, etc. mais je n'ai jamais exploré le niveau de bits et octets. Je ne voulais pas que les gens me regardent de haut pour ce manque de connaissances dans les structures de données.
Alors pourquoi vraiment tout cet accent mis sur les structures de données?
la plupart des grandes entreprises technologiques comme Microsoft se concentrent principalement sur les structures de données. Il semble que les structures de données soient la seule chose qu'ils attendent d'un diplômé.
Non, il y a plus. Par exemple, nous nous attendons également que vous soyez un apprenant rapide qui peut apprendre de nouveaux cadres, API ou même des langages de programmation dans un court laps de temps. C'est une barre minimale. Quelqu'un qui met beaucoup de temps à apprendre un nouveau cadre, une nouvelle API ou un nouveau langage ne sera pas un développeur performant dans la plupart des équipes de Microsoft.
Et bien sûr, il y a beaucoup plus d'aspects sur lesquels nous nous concentrons dans les entretiens autres que la simple connaissance des structures de données. Capacité à gérer des spécifications ambiguës, par exemple, ou capacité à reconnaître des modèles de codage qui produisent du code non sécurisé, ou une douzaine d'autres choses. Mais la capacité de comprendre les structures de données est certainement très importante.
C'est particulièrement le cas où les entretiens sont biaisés pour tester la connaissance des structures de données pour les récents diplômés CS. Les diplômés récents, dont la plupart n'ont pas beaucoup d'expérience dans le monde réel, ne devraient pas être bons dans le même genre de choses que quelqu'un avec quinze ans d'expérience dans l'industrie serait bon.
Je dois avouer que je n'étais pas si fort dans les structures de données
C'est bien que vous le sachiez. Si vous ne pouvez pas ou ne voulez pas changer cela à votre sujet, ma recommandation est que vous ne postulez pas pour un emploi qui nécessite une installation avec des structures de données.
il y a cette perspective générale qu'un bon programmeur est nécessairement celui qui a une bonne connaissance des structures de données.
Il est tautologique qu'un bon programmeur soit un programmeur qui sait bien construire les types de programmes qui doivent être construits. De nombreux programmeurs travaillent sur des tâches qui ne nécessitent pas une connaissance approfondie des structures de données. Certains d'entre eux travaillent sur des tâches qui nécessitent une connaissance approfondie de la conception d'interfaces utilisateur, par exemple. Ou la normalisation de la base de données. Ou peu importe. Ces personnes peuvent toujours être de "bons programmeurs" dans leurs domaines.
pourquoi tout cet accent mis sur les structures de données?
Je pose des questions d'entrevue sur les structures de données parce que dans mon équipe, les développeurs conçoivent, implémentent et manipulent des structures de données complexes toute la journée. Hier, nous avons eu quatre heures de réunions au cours desquelles une demi-douzaine de développeurs ont fait valoir les avantages et les inconvénients de l'ajout d'un seul champ booléen à un nœud d'arbre particulier. Il n'y a probablement aucune compétence dans mon équipe plus importante que la capacité de comprendre les structures de données à un niveau profond. Il serait stupide de ne pas poser de questions d'entrevue à ce sujet, puisque c'est ce que nous faisons.
La connaissance des structures de données n'affecte-t-elle pas vraiment sa carrière en programmation?
Eh bien, cela vous empêchera certainement d'obtenir un emploi dans mon équipe. Mais comme je l'ai déjà dit, la programmation est un immense champ . Il existe de nombreux types de programmation informatique qui ne nécessitent pas de connaissances des structures de données.
les connaissances dans ce sujet sont-elles vraiment une base suffisante pour différencier un bon et un mauvais programmeur?
Non. Mais il suffit presque toujours de détecter les développeurs qui ont peu de chances de réussir chez Microsoft. Puisque c'est ce que je suis principalement intéressé à détecter, la connaissance des structures de données est l'un des facteurs que je teste lors des entretiens.
Un point important sur les structures de données est qu'elles sont universelles et intemporelles, au moins à des fins pratiques. Quiconque a été développeur au cours des 30 dernières années doit connaître les structures de données de base telles que les listes chaînées simples/doubles, les arbres binaires ou les graphiques. Si vous interrogez deux développeurs à leur sujet, vous pouvez comparer les connaissances des développeurs par leurs réponses. Cela peut difficilement être dit pour les frameworks ou même les langages: si vous interrogez deux développeurs sur Rails, et que l'un en sait beaucoup plus que l'autre, qu'est-ce que cela vous dit vraiment? Comme vous le dites dans la question, un développeur intelligent peut apprendre un nouveau framework assez rapidement, donc tester ses connaissances actuelles n'a pas beaucoup de sens.
Est-ce que, ne pas avoir de connaissances en structures de données affecte vraiment sa carrière en programmation?
Oui. Absolument. Sauf si vous voulez passer toute votre vie à écrire des applications CRUD.
Ou les connaissances dans ce sujet sont-elles vraiment une base suffisante pour différencier un bon et un mauvais programmeur?
Non, ce n'est pas suffisant. Mais il y a peu de choses que vous pouvez demander lors d'un entretien d'embauche qui sont suffisantes. Et je dirais que la connaissance des algorithmes est l'un des meilleurs indicateurs, au moins pour les personnes fraîchement sorties de l'école, où vous ne pouvez pas poser de questions sur les expériences de travail.
Je suis un apprenant rapide et je peux apprendre de nouveaux cadres, API ou même des langages de programmation en un temps considérablement court.
Pour ne pas paraître trop sévère, tout développeur à moitié décent sera en mesure de choisir un nouveau langage ou cadre dans un délai relativement court.
Les structures de données sont universelles, elles sont un élément fondamental de l'informatique - un arbre rouge-noir est fondamentalement le même, qu'il soit implémenté en Java, Python, PHP ou autre. Donc plutôt que en testant des langages spécifiques ou des cadres spécifiques, un employeur (au moins, un employeur à la recherche de développeurs hors pair) testera si vous connaissez les principes fondamentaux de l'informatique, plutôt que n'importe quelle saveur du -mois qu'ils utilisent actuellement.
(au moins, ils devraient tester les principes fondamentaux en plus de tout ce qu'ils utilisent actuellement ... inutile d'engager un assistant informatique s'il n'a jamais écrit une ligne de code dans sa vie)
Croyez-vous que F1 les coureurs juste conduisez les voitures rapides? Non, ils comprennent la voiture qu'ils conduisent et ils travaillent avec les mécaniciens/ingénieurs pour la régler. Bien sûr, un pilote normal ne fait que conduire.
Vous pouvez être un programmeur normal/moyen qui a juste écrit du code. Vous ne comprenez pas ce qui se cache. Vous faites avancer les choses. C'est tout, à demain.
Mais de nombreuses entreprises recherchent des développeurs F1. Les gens qui se développeront en sachant ce qui se cache derrière leur code. Des gens qui aideront également l'entreprise à construire quelque chose de mieux.
Il est assez bon de connaître les structures de données, non seulement parce que vous les utiliserez beaucoup sous une forme "précuite". C'est aussi bien parce que vous allez créer quelque chose qui dérive de leur idée.
Dans ma classe sur les structures de données, la toute première chose que le professeur a dit était: Cette classe il ne s'agit pas de pouvoir rechercher très rapidement. Nous avons ensuite passé six mois à trouver les meilleures structures de données et algorithmes possibles pour recherche vraiment rapide.
Pourtant, il est resté à droite. Être capable d'analyser des structures de données, d'appliquer la bonne structure de données à un problème donné ou même de proposer de nouvelles structures de données nécessite de nombreuses qualités d'ingénieur:
- Trouver des abstractions pour modéliser un problème concret
- Être capable de décomposer les problèmes
- Être capable de raisonner logiquement/formellement
- La créativité
- etc.
Quand Amazon et Microsoft embauchent des gens, ils ne le font pas poser des questions sur les structures de données parce qu'ils espérons inventer le prochain quicksort. Ils veulent s'assurer qu'ils embauchent quelqu'un avec les qualités susmentionnées.
Bien sûr, il est possible d'avoir un large éventail de ces qualités et de continuer à aspirer les structures de données. Mais alors, si c'est le cas, il ne vous faudra pas longtemps pour devenir un expert en structures de données.
Cela étant dit, il y a toujours le problème que ArrayList n'est tout simplement pas assez évolutif. Lorsque les systèmes sont volumineux, des solutions mieux adaptées sont nécessaires pour effectuer le travail. Et sans une bonne compréhension des structures de données, vous ne pourrez pas trouver et composer des structures et des algorithmes qui évoluent à grande échelle dans votre scénario concret.
En règle générale, les algorithmes et les structures de données sont considérés comme deux des sujets les plus "essentiels" de la programmation. En effet, il existe un énorme corpus de travaux et de recherches les concernant en informatique. Ils attirent également les programmeurs typiques du "lobe gauche" qui aiment des choses comme les mathématiques et les sciences (ce qui fait beaucoup de programmeurs)
Cela étant dit, leur connaissance peut affecter votre carrière en termes d'interview, surtout si vous interviewez dans des lieux de travail orientés ingénierie comme Google. Cependant, d'autres entreprises pourraient désormais se préoccuper de cet aspect.
D'après mon expérience, les demandes d'algorithme/de structure de données peuvent parfois apparaître comme un "élitisme programmeur" où les geeks alpha se précipitent pour montrer qui est le plus intelligent. Il est toujours bon de savoir ce qui existe, mais il existe de nombreux travaux de programmation différents où vous n'aurez jamais besoin de savoir comment utiliser un arbre rouge/noir ou coder une recherche boyer-moore.
Je recommanderais d'en savoir plus sur les sujets si vous les trouvez intéressants et avez un projet personnel où vous pouvez les bricoler, sinon vous pouvez probablement vous en passer pour l'instant
PS. La maîtrise de rudimentaires structures de données (listes chaînées, dictionnaires, tables de hachage, etc.) devrait être une connaissance obligatoire pour tout programmeur DS.
Alors pourquoi vraiment tout cet accent mis sur les structures de données?
Deux raisons.
D'une part, cela montre que vous pouvez penser au problème en termes abstraits plutôt qu'en termes d'un langage de programmation spécifique. Savez-vous pourquoi une table de hachage peut être un choix meilleur ou pire qu'un arbre rouge-noir dans une situation donnée, quelle que soit l'implémentation sous-jacente?
Pour un autre, il y a un nombre effrayant de personnes interviewées pour des emplois qui simplement mentent à propos de leur expérience et ont très peu le cas échéant, capacité de programmation; Les questions sur les structures de données sont un moyen rapide d'éliminer ces personnes.
Ils sont fondamentaux, mais aussi, sur quoi interrogeriez-vous les diplômés? Ils peuvent ou non avoir une expérience en dehors de leurs cours. Leur cours peut avoir couvert les technologies Microsoft plus que Java, ou vice versa. Les structures de données sont un terrain d'entente.
Souvent, le meilleur code évite de réinventer les structures de données de bas niveau. Cela est particulièrement vrai dans les langues de haut niveau. J'ai remarqué une tendance vers des questions de structure de données de bas niveau, même dans les emplois CRUD. YMMV, mais il semble que l'accent mis sur l'expertise des pirates informatiques ait éclipsé les autres compétences qui font un grand développeur:
- gestion de projet/temps: être en mesure de suivre le monde réel qui est dirigé par les entreprises, pas une nouvelle liste chaînée qui fonctionne 1% plus rapidement.
- un minimum de compétences sociales: un développeur arrogant et incapable de s'entendre n'est qu'une ancre.
- la capacité d'apprendre de nouvelles choses rapidement et en continu: les structures de données ne changent guère au fil des ans ... mais tout le reste change. Les structures de données sont d'excellents fondamentaux et chaque développeur devrait les connaître assez bien, mais un comptable ne se fait pas tester sur ses longues compétences en division lorsqu'il se présente pour un entretien. Les grands développeurs sont le type de personnes qui peuvent découvrir de nouvelles choses et l'aimer.
Les structures de données sont excellentes. Les structures de données sont importantes. Chaque programmeur doit les comprendre. Cependant, nous sommes devenus obsédés par le fait de pousser ces fondamentaux en dehors de leur place. Ce n'est pas TOUT sur les structures de données, et dans 99% des cas, il n'est pas nécessaire de poser des questions au-delà des bases des structures de données. Si vous interviewez un comptable, demandez-lui bien ce que 81 divisé par 9, mais si vous continuez à demander "Quelle est la racine cubique de 98425454242412 * 4512324? ... sans calculatrice!" alors vous effrayerez un bon pourcentage des personnes raisonnables, intelligentes, talentueuses et agréables que vous auriez pu avoir. Demandez-leur s'ils peuvent construire un modèle de données relationnelles de base, demandez-leur s'ils peuvent utiliser les structures de tableau améliorées fournies par le cadre pertinent, et demandez-leur s'ils peuvent expliquer quand une recherche binaire est plus rapide qu'une recherche plate, mais il n'y a pas grand chose à faire aussi bien au-delà. S'ils peuvent faire ces choses, alors commencez à chercher le plus beau, le plus professionnel et le plus créatif du groupe.
J'adore l'écriture de Joel, mais je pense que son truc "Java Schools" est complètement faux. Il y a beaucoup de choses qui peuvent prouver que quelqu'un est intelligent au-delà de la maîtrise du C++. Pensez-y, vous pouvez parler à quelqu'un pendant 10 minutes, sans lui poser de questions sur l'arithmatique des pointeurs, et avoir une assez bonne idée de savoir si c'est le type qui peut faire avancer les choses et comprendre des choses. Nous n'avons pas besoin d'être comme ça:
Intervieweur: "Parlez-moi de vos réalisations."
Coder: "Dans ma dernière position, j'étais le seul développeur d'un système personnalisé ERP pour une société financière d'un milliard de dollars. Nous avons livré des mois plus tôt que prévu, et le système est en production depuis le passé 3 années."
Intervieweur: "Permettez-moi de clarifier. Parlez-moi de vos programmation réalisations"
Codeur: "Umm ..."
Intervieweur: "Par exemple, avez-vous déjà créé votre propre liste de liens?"
Coder: "... [sortant]"
Être un bon programmeur, ce n'est pas être capable d'apprendre des langages et des frameworks. Il s'agit de pouvoir trouver des solutions à des problèmes complexes. Pour que ces solutions soient efficaces et fiables, elles reposeront presque toujours sur de bons algorithmes et une utilisation appropriée des structures de données. Connaître les structures de données existantes ne suffit pas. Vous devez comprendre que les structures de données seront suffisantes pour utiliser la bonne pour le problème. Les listes et les cartes offrent des fonctionnalités utiles, mais elles entraînent des coûts et l'utilisation de la mauvaise peut nuire considérablement aux performances de votre logiciel.
Un bon intervieweur le sait et essaie de déterminer si vous pouvez être utile à son équipe ou à son entreprise. La ou les langues que vous utiliserez dans 2 ans peuvent être très différentes, mais le besoin d'algorithmes efficaces et de structures de données ne changera pas.
Les structures de données, la complexité temporelle, la manipulation de la mémoire et les pointeurs sont tous des éléments fondamentaux que quiconque se faisant appeler informaticien devrait connaître de façon innée. N'importe quel code singe peut apprendre une langue et apprendre à l'utiliser, mais là où les professionnels et les étudiants CS doivent se démarquer, c'est de savoir non seulement comment utiliser une liste chaînée ou une carte de hachage, mais POURQUOI.
Le POURQUOI est ce qui nous distingue vraiment du kiddie de script de base, du singe de code et du grognement du monde informatique. POURQUOI utiliser une table de hachage au lieu d'une liste liée, POURQUOI ma table de hachage doit être à une densité de cluster d'environ 0,6 à 0,8, POURQUOI dois-je utiliser ici une liste liée circulaire au lieu d'une liste doublement liée. POURQUOI mon code devrait-il fonctionner à l'efficacité "x" dans le pire des cas et "y" dans le cas moyen.
Ces structures de données de base et la connaissance non seulement de la façon dont elles sont utilisées (le comment devrait être dans tous les programmeurs repritoire de toute façon), mais du langage agnostique POURQUOI elles sont utilisées, ce qui tend à être plus de ce qu'elles recherchent dans ces cas.
De nombreux endroits vous feront écrire le code dans un langage qui vous est familier, mais c'est plus une généralité, car C n'est vraiment plus la langue française du monde de la programmation, et le pseudo-code structurant peut être un méli-mélo et tout sur place et, dans la plupart des cas avec le pseudo-code/code p & p pas vraiment enseigné, en bas à droite impossible à traiter.
Les structures de données sont le fondement fondamental de tous les programmes. Vous n'avez pas nécessairement besoin de les comprendre en profondeur, mais vous devez absolument savoir comment ils fonctionnent.
Pourquoi? Parce que tout votre code interagit avec et manipule les données. Si l'ensemble de données ne peut pas être stocké dans une structure, il ne peut pas être utilisé. Les données sont comme les matériaux de construction d'une maison. Jusqu'à ce que vous le réunissiez dans une structure, vous n'avez qu'une pile inutile de planches.
Une fois que vous avez décidé comment penser et définir votre ensemble de données, alors vous pouvez commencer à l'utiliser pour faire des choses, la partie classique de l'algorithme du duo. Chaque programme que vous écrivez utilise une structure de données, bien que dans de nombreux cas cette structure soit si simpliste qu'elle n'existe presque pas. Quelques variables pour les données d'état et nous avons terminé!
Une fois que vous avez dépassé les programmes triviaux, presque tout nécessite une structure de données. Lequel préférez-vous, un architecte professionnel qui conçoit votre gratte-ciel avec les meilleures pratiques et les mathématiques, ou l'oncle Joe Bob qui commence immédiatement à construire?