Question:
Pourquoi les intervieweurs posent des questions d'algorithme même si le poste n'exige pas de telles connaissances?
user10125
2014-06-14 20:57:35 UTC
view on stackexchange narkive permalink

J'ai vu beaucoup d'intervieweurs poser des questions avancées sur l'algorithme et la structure des données alors que le travail n'exige aucune connaissance à leur sujet. C'est vrai souvent, alors pourquoi les intervieweurs posent de telles questions?

Quels types de travaux de programmation ne nécessitent pas de connaissance des algorithmes et des structures de données? Sans ces bases, tout ce que vous pouvez faire est de copier des données sans réfléchir. Vous ne pouvez même pas concevoir un bon modèle de données.
@kevincline la plupart des développements Web dans les boutiques de sites Web standard par exemple.
@BenjaminGruenbaum Quel travail de développement Web ne nécessite pas la connaissance des algorithmes et des structures de données? Ma femme gère un magasin de meubles en ligne, mais lorsqu'elle a voulu apporter les plus petites modifications aux modèles de modèles de magasin, elle a dû en apprendre davantage sur les tableaux associatifs. Heureusement, elle est assez intelligente et cela n'a pris que quelques minutes, mais elle devait quand même savoir ce qui se passait.
Les tableaux associatifs ne "connaissent pas les structures de données", votre femme n'a pas eu à réfléchir une minute à la table de hachage de support ou à l'arbre rouge et noir. C'est ça la beauté :)
Pour beaucoup, la réponse est simple: ils le font parce que Google le fait.
Je pleure pour l'industrie en ce moment.
@Benjamin: Il y a beaucoup de place pour une inefficacité flagrante dans le Javascript côté client. Je l'ai vu plusieurs fois. Si vous vouliez dire "écrire du HTML et du CSS", c'est du graphisme, pas de la programmation.
C'est un test de la façon dont vous étiez récemment un étudiant CS.
Parce que c'est nécessaire pour le travail.
@GlenPierce pas vraiment c'est plus parce que c'est tendance
@Neuromancer, Je suis d'accord, car c'est à la mode.L'année dernière encore, des entreprises de technologie m'ont fait développer de petites applications pour elles, maintenant elles me donnent toutes les algorithmes Codility et Hackerrank et m'envoient sur mon chemin et non elles ne me demandent pas d'expliquer mes solutions.Alors j'appelle des taureaux sur celui-là.Ils regardent juste pour voir si j'ai 100%, non?ok, au prochain type désolé avec un CV.
Un tout dernier point flagrant que nous semblons tous manquer.Dans toute autre industrie, si on vous demande de prouver que vous pouvez faire quelque chose, cela a déjà été décrit dans la description de poste (pour la plupart).Ainsi, chaque endroit ** doit connaître les algorithmes ** dans la description de poste OU ** doit avoir un diplôme CS **.Tester quelqu'un sur quelque chose que vous n'avez pas demandé dans une description de poste sonne faux lorsque vous laissez de côté l'élégante justification donnée par Kolossus.En termes simples, cela s'appelle être aveugle.
Cinq réponses:
#1
+30
kolossus
2014-06-14 21:24:03 UTC
view on stackexchange narkive permalink

Il s'agit principalement d'un test de votre compréhension des principes fondamentaux de l'informatique (ce qui devrait être un prérequis pour tout programmeur).

Le développement de logiciels a évolué au point où les principes fondamentaux de la création de bons produits ont été retirés du développeur moyen. Les langages "de haut niveau" ont engendré une nouvelle culture de programmeurs copier-coller qui ne savent pas pourquoi cela fonctionne, mais seulement que cela fonctionne. Bien que ce ne soit pas facile, presque tout le monde peut apprendre une API de nos jours.

Poser des questions sur les algorithmes, les structures de données et les modèles de conception aide de nombreuses entreprises à éliminer les programmeurs qui peuvent attaquer Stackoverflow pour obtenir de bonnes réponses, sans comprendre le fonctionnement principes derrière eux. Vous constaterez également que de nombreuses entreprises qui posent des questions sur ces fondamentaux utilisent une variété de plates-formes. Plutôt que de demander des choses propres à une langue / plateforme spécifique, ils ouvriront l'entretien avec des questions informatiques plus générales.

Connaître les principes fondamentaux de CS vous aide à prendre de meilleures décisions de niveau supérieur lors de la programmation. Si j'étais un employeur, je voudrais recruter un programmeur qui connaît la différence entre une pile et une file d'attente; un ArrayList d'un LinkedHashSet; Tri à bulles à partir du tri rapide; Ces décisions ont des implications sur les performances / la conception. Il est important de les comprendre, plutôt que de simplement déchirer quelque chose du net (par un auteur qui a peut-être pris la mauvaise décision à votre insu). Connaître la solution, ce n'est pas comprendre la solution

Pourquoi les OS, les compilateurs, ...? Pourquoi juste des algorithmes?
... mais pourquoi? Si vous n'avez absolument pas besoin de connaître les principes fondamentaux, pourquoi le demanderaient-ils? (Je ne dis pas que vous ne devriez pas, juste que vous n'avez pas vraiment donné de raison dans votre réponse.) Il y a aussi d'autres raisons pour lesquelles ils poseraient de telles questions.
@VarunAgw - Les OS et les compilateurs sont finalement construits sur quoi? Algorithmes. Structures de données. Logique. Fondamentaux. C'est à cela que revient la programmation. Plutôt que de partager les cheveux entre C # et Java, je préfère vous poser des questions basées sur quelque chose qu'ils ont tous les deux en commun
@Dukeling - Si j'étais un employeur, je voudrais recruter un programmeur qui connaît la différence entre une pile et une file d'attente; un ArrayList d'un LinkedHashSet; Tri à bulles à partir du tri rapide; Threads vs processus. Ces décisions ont des implications sur les performances / la conception. Mieux vaut comprendre que de simplement déchirer quelque chose du net qui a peut-être pris la mauvaise décision sans votre compréhension / connaissance. Connaître la solution, ce n'est pas comprendre la solution. Je ne dis pas que vous devez comprendre la solution 100% du temps, mais en tant qu'employeur, je serais plus heureux de débourser l'argent si vous le faisiez.
@kolossus Cela devrait probablement figurer dans votre réponse.
@Dukeling - Je suis tout à fait sûr d'avoir donné plusieurs raisons, telles que ".. évitez les programmeurs qui peuvent attaquer Stackoverflow pour obtenir de bonnes réponses, sans comprendre les principes de fonctionnement derrière eux", etc.
AilixxoabrCMT - compris
`aide de nombreuses entreprises à éliminer les programmeurs` Je pense néanmoins qu'il existe de meilleures façons. Ils peuvent demander à coder quelque chose directement lié au travail. Cela peut également aider à éliminer les programmeurs. De plus, une bonne connaissance des algorithmes ne signifie pas que vous ferez bien le travail, car vous ferez quelque chose de différent de l'écriture de bons algorithmes dans le travail.
@VarunAgw- clairement les algorithmes et les structures de données ne sont pas l'intégralité de l'interview. On vous posera une variété de questions; les employeurs qui les utilisent ne sont pas stupides vous savez.
@VarunAgw, lorsque vous êtes manager, vous pouvez poser toutes les questions que vous voulez essayer de déterminer qui est et n'est pas capable de faire le travail que vous avez. Les personnes que vous interviewez ont une raison de poser cette question et peu importe la raison en fin de compte, car vous devrez avoir une réponse acceptable pour avancer dans le processus. Mais comme ce sont des questions qui testent votre compréhension fondamentale de l'informatique, je ne les vois pas disparaître de si tôt. Peut-être qu'ils ont éliminé certaines personnes potentiellement bonnes, mais ils ont également éliminé la plupart des incompétents.
@kolossus: NSMutableArray fonctionne très bien comme pile et file d'attente.Vous ajoutez des éléments à la fin et la seule différence est de savoir si vous supprimez des éléments à la fin ou au début.La performance est la même.
@gnasher729 "stack" et "queue" sont des types de données * abstraits * (ADT).Votre exemple est un type concret qui peut être utilisé dans le cadre d'une pile ou d'une file d'attente.La considération de performance devient alors si vous avez besoin d'un comportement FIFO (une file d'attente) ou LIFO / FILO (une pile).
@kolossus, J'adore votre réponse pour sa logique et elle m'ouvre à accepter cette nouvelle façon d'interviewer, mais elle est imparfaite.Donc, connaître les algorithmes me permettra d'apprendre facilement et rapidement le développement d'API?qui est censé m'apprendre?Aucune entreprise de technologie aux États-Unis ne prendra la peine d'investir des ressources dans une telle entreprise, je suis censé le savoir, mais j'ai passé mon temps à apprendre des algorithmes, un problème différent à résoudre que le développement d'API.
@Daniel - heureux que vous ayez trouvé la réponse utile.Pour votre point, connaître * certains * algorithmes fera de vous un meilleur développeur * dans l'ensemble *;vous n'avez pas besoin de connaître tous les algorithmes du livre.Défaut ou pas, c'est juste la réalité du recrutement pour un magasin de logiciels décent.Ils s'attendent à ce que vous connaissiez les principes fondamentaux (pas même les trucs vraiment sophistiqués comme les arbres les plus ésotériques) * avant * de venir travailler pour eux.
@kolossus, mon instinct me dit qu'une fois que nous sommes assez nombreux à apprendre et à réussir ces tests d'algo, ils vont à nouveau faire évoluer le fromage vers une nouvelle tendance.Donc, je suppose que mon point de vue général est que si la plupart des magasins le faisaient pour la raison que vous donnez, ce serait acceptable pour moi, mais je conviens que la plupart des entreprises le font simplement parce que d'autres le font.L'indice est dans ces entreprises qui ne prennent jamais la peine de me demander pourquoi?J'ai choisi la réponse que j'ai faite, celles qui vous donnent un lien Codility / Hackerrank et vous envoient sur votre chemin.
#2
+17
Bernhard Barker
2014-06-15 05:02:57 UTC
view on stackexchange narkive permalink
  • Pouvez-vous écrire du code de travail?

    Ceci suppose bien sûr que l'on vous demande d'écrire du code réel dans l'interview (tableau blanc style).

    Il ne s'agit pas tant de ne pas avoir une seule faute de frappe dans votre code, mais plutôt de savoir à quoi ressemblent les constructions de base comme les boucles for, de savoir comment assembler les bits et prouvant que vous avez réellement écrit un peu de code dans une langue pour connaître la plupart des méthodes / classes les plus courantes (apparemment, les intervieweurs ont un peu de problème avec les candidats qui ne peuvent même pas passer le test de buzz fizz).

  • Pouvez-vous réfléchir à un problème?

    Cela ne s'applique certainement pas uniquement aux algorithmes.

    Vous devez être en mesure de comprendre le problème, d'analyser les exigences, de choisir les structures de données et les algorithmes appropriés, d'écrire le code / de parcourir l'approche et de l'analyser - cela est requis pour beaucoup / la plupart (sans bogue -fix) tâches de programmation.

  • Pouvez-vous bien comprendre (à propos de la programmation)?

    Comprenez-vous le problème tel que décrit?

    Demandez-vous des éclaircissements si nécessaire?

    Pouvez-vous expliquer l'approche de haut niveau avant de commencer à écrire le code?

    Êtes-vous capable d'expliquer votre code après coup?

    La capacité de bien communiquer est importante dans votre quotidien -journal en tant que programmeur.

    Votre patron ne devrait pas craindre que vous ne puissiez pas comprendre l'explication d'un problème, pas demander des éclaircissements lorsque les choses ne sont pas claires (et certaines hypothèses radicales), ne sont pas en mesure d'expliquer comment vous prévoyez de résoudre un problème donné et / ou ne sont pas en mesure d'expliquer le code que vous avez écrit à quelqu'un d'autre.

  • Avez-vous une bonne connaissance des structures de données et des algorithmes?

    Bien que l'on puisse vous poser des questions sur une structure de données avancée ou un algorithme que vous n'utiliserez jamais, la connaissance de cette structure de données peut être un indicateur assez précis que vous connaissez à peu près tous les éléments de base assez bien.

    Je suis également assez sûr que vous pouvez vous en tenir à des structures de données ou à des algorithmes simples (liste liée, tableau, arbre de recherche binaire, recherche binaire, etc.) dans de nombreux cas et toujours bien faire dans cet aspect spécifique - alors que des données avancées la structure ou l'algorithme peuvent être mieux adaptés pour résoudre le problème en question, vous pouvez souvent résoudre assez efficacement le problème avec une combinaison de problèmes de base - il y a toujours un choix entre eux en fonction de leur pertinence et en les combinant de manière appropriée. vous avez certainement besoin d'une bonne connaissance des structures de données et des algorithmes - vous ne pouvez pas être bon dans ce que vous faites si vous ne savez pas quand utiliser quels outils dans votre boîte à outils.

  • Pouvez-vous analyser la complexité du temps et de l'espace et comparer les choix les uns par rapport aux autres en gardant à l'esprit ces derniers, faire le choix le plus approprié pour la situation?

    Toute question de structure de données ou d'algorithme doit impliquer de la complexité, et elle sera très importante pour votre travail quotidien - personne ne veut de vous pour, par exemple, écrire du code qui effectue une recherche linéaire sans fin dans un grand tableau immuable parce que vous ne savez pas ce qui se passe au bas niveau.

#3
+7
Sascha
2018-01-14 23:19:20 UTC
view on stackexchange narkive permalink

Je fais des interviews techniques. Très souvent, je ne demande pas du tout aux gens ce qu'ils vont faire, mais plutôt des choses vaguement liées qu'ils ont faites. La raison derrière cela est simple:

  • Je peux voir à quel point la personne aime entrer dans les détails techniques.

  • Je peux comparer la personne à ses pairs

  • Je peux mieux tester sa force analytique sur quelque chose où il sait réellement quelque chose sur cette chose inconnue.

  • Je vois aussi les capacités d'auto-réflexion et d'équipe. Par exemple. lorsqu'une personne CS parle de sa thèse de master et déclare explicitement qu'elle a laissé une certaine partie à faire à un coéquipier - ou comment elle a pris possession de quelque chose

Tout cela ne peut fonctionner que si je leur présente quelque chose que je peux vraiment m'attendre à ce qu'ils sachent. S'ils sont bons dans ces domaines, ils le sont généralement aussi dans d'autres domaines.

vous êtes un intervieweur technique très sensible et très sage.Je ne rejette pas le kolossus car cela a également beaucoup de sens.Il y a un petit détail qui manque à Kolossus.L'écriture d'un algorithme résout un problème très spécifique, la fonctionnalité CRUD résout un problème très spécifique.Comment sont-ils connectés?En d'autres termes, si j'apprends le premier, est-ce que cela mènera à une compréhension intuitive du second?
#4
+6
James Adam
2014-06-14 21:01:15 UTC
view on stackexchange narkive permalink

Il y a probablement deux réponses principales:

Premièrement, parce que c'est l'occasion de voir comment un candidat aborde un problème. Même si vous ne connaissez pas immédiatement la solution spécifique au problème, la façon dont vous expliquez comment vous aborderiez le problème peut révéler votre capacité à penser clairement, à comprendre le problème et à démontrer d'autres qualités comme la patience.

La deuxième réponse est qu'ils le font simplement parce que c'est une façon de démontrer ce qu'un candidat sait, et qu'ils croient que d'autres entreprises font de même, et donc la question agit comme un obstacle assez arbitraire qu'ils veulent des candidats pour sauter.

Très souvent, c'est une façon de recruter des gens comme moi et aussi parfois une façon d'utiliser ses informations d'identification comme une forme de comportement de domination.
@James, les tests d'algorithme qu'une entreprise m'avait fait prendre jusqu'ici, c'était juste un ici aller faire ce test sur Codility et partir pour toujours.Personne ne m'a jamais recontacté pour me demander pourquoi j'avais écrit les algorithmes comme je l'ai fait.Ils ont juste vu que toutes mes solutions n'étaient pas correctes à 100%, alors ils ont dit, eh bien, nous voulons le gars qui obtient 100% et c'est tout.
@Daniel Je suis désolé que vous ayez vécu cette expérience.Il semble que vous feriez mieux de ne pas travailler pour cette entreprise, si c'est ainsi qu'ils traitent les gens!
@JamesAdam, pour être clair, ils ne m'ont pas dit cela.Le fait est que de nombreuses entreprises recherchent ce moyen simple de passer par 100 candidats.Ils ont donc découvert qu'ils saisiraient Codility ou Hackerrank et donneraient simplement à tout le monde des tests d'algorithme standard dont ils n'avaient aucune idée et chercheraient le candidat qui obtiendrait 100%.Mais je conviens que moi et d'autres sommes mieux de ne pas travailler pour une telle entreprise.
#5
-3
Vladimir Nabokov
2018-01-14 02:08:33 UTC
view on stackexchange narkive permalink

L'auteur a demandé: "pourquoi ils vérifient les algorithmes, même si le travail ne les nécessite pas"

Dans la plupart des cas, parce que:

1) c'est le moyen le plus simple pour un programmeur immature, fraîchement sorti d'une université ou tout simplement un bon "googleur", pour argumenter avec un candidat, qui en sait plus qu'un intervieweur.

2) en raison de l'inconscience de la complexité des langages modernes de haut niveau et Les API.

Lorsqu'ils demandent des algorithmes - ils pensent qu'ils "vérifient comment un candidat pense".

Après 20 ans de programmation, vous oubliez naturellement la plupart de ces algorithmes d'une université, car il est rarement utilisé de manière bas niveau.

(Exception: les programmeurs C / Assembly dans certaines couches, les programmeurs de base du langage, l'exploration de données)

Vous vous êtes plus fréquemment concentré sur les API et des structures de données de haut niveau. Les fonctionnalités du langage de concurrence, les modèles de conception, les coins sombres des styles orientés objet et fonctionnels sont bien plus importants dans 80% des emplois de programmeurs, vous les gardez donc naturellement en mémoire. 80% des programmeurs commencent leurs connaissances sur les algorithmes de rappel / rafraîchissement uniquement pour les entretiens. Telle est la réalité.

Donc, vous avez demandé "ce que votre enquêteur sait ou est capable de rechercher sur Google", et non pas "ce que le travail exige", l'exigence réelle du poste pourrait être un très sombre secret pour votre enquêteur! !!

Les API modernes, les problèmes de simultanéité et les structures de données de haut niveau sont dix / centaines de fois plus complexes que les algorithmes scolaires et l'exigence de savoir tout cela en permanence est insensée.

Donc, vous avez en fait demandé "la partie la plus sûre", les choses que votre intervieweur est capable de gratter des pages Web,

la partie non algorithmique peut être 1000 fois plus complexe, mais c'est pourquoi vous avez rarement demandé cette partie - l'intervieweur a peur - ici une expérience est requise, pas seulement "googler".

À mon avis, l'industrie est paralysée par ces intervieweurs, la plupart d'entre eux sont des chefs d'équipe qui sont entrés dans leur position après une carrière de programmeur trop courte.

Ces questions sont une marque d’ignorance et d’expérience insuffisante.

Au lieu de poser 10 questions dans chacun des 10 domaines de programmation que cette entreprise / position impliquait, par exemple, les modèles de conception, la concurrence, les protocoles, le Web, la concurrence, le client, le serveur, UML, les frameworks, etc. (100 questions est un minimum pour avoir une vue large) pour découvrir tous les côtés faibles et forts d'un candidat, ils commencent généralement leur entretien de cette façon:

"Je ne pose généralement que deux questions!". (Il est obligatoire suivi d'un regard très narcissique - notez que - comme ce type a découvert le secret d'une bonne interview et ne se dérange jamais avec beaucoup d'autres questions!) Une question sera un puzzle, deuxième - algorithme. C'est assez! C'est ce qui est vraiment important pour un travail - la fissuration d'énigmes et un souvenir de vos jours d'école !!!

Cela signifie simplement: "Je pense que je suis intelligent, parce que j'ai cherché sur Google il y a une semaine, lisez la solution et compris, c'est à votre tour maintenant, vous avez 10 minutes, mais pas de google ".

Vous pouvez dire" n'exagérez pas, les gens savent ce qu'ils demandent ". Vraiment? Vous pensez vraiment que si je demande un autre "puzzle", j'obtiendrai la réponse claire?

À mon avis, l'intervieweur doit faire un effort pour demander ce qu'il est capable de faire lui-même, pas moins, mais pas plus. Sinon - c'est un cirque, dont le seul but est de construire un autre ego sur le compte du candidat.

Cela conduit à une avancée d'un nouveau puzzle amoureux, mais dans la pratique faible mec, en face, le cheval de travail qui en sait 1000 fois plus, mais moins concentré sur un aspect déroutant échouera généralement - une bonne mémoire garde rarement l'impression indésirable, que vous pouvez google, une bonne mémoire "opérationnelle" garde au jour le jour (Sauf, comme je l'ai dit, certains domaines, où les algorithmes - SONT les affaires quotidiennes, pas à leur sujet la question posée ici!)

Je demanderais des algorithmes uniquement dans les domaines où ils sont obligatoires pour un travail, pas pour chaque travail de programmeur.

BTW, une telle base de "deux questions" est un Klondike pour les entreprises d'externalisation.

Ils envoient généralement un type "sonde" pour découvrir ces questions, puis un "vrai candidat", qui va enfin y répondre (après une bonne recherche sur Google).

Je sais que c'est sûr - de cette façon, ces questions amusantes se sont généralement fissurées et le travail réel est également bien fait. Dans 99% des cas, vous ne pouvez en avoir qu'un: bon "algorithmiste" OU bon "langueur", pas les deux.

C'est l'une des raisons pour lesquelles ces sociétés d'externalisation se développent et vivent exceptionnellement bien, même si elles donnent 0 valeur à la fois pour leurs employés et pour les entreprises pour lesquelles ils sont employés.

C'est une très bonne réponse.Personnellement, je n'ai pas le temps de m'asseoir tous les jours et de pratiquer des algorithmes que j'oublierai la semaine prochaine.J'apprends mieux les modèles, l'architecture, le DDD et d'autres choses que vous avez mentionnées.La grande chose que j'ai apprise en essayant de mémoriser des algorithmes était la complexité de calcul asymptotique.
Juste pour compléter.Comprendre les structures de données est également une bonne compétence à mon avis.Savoir lequel utiliser et etc.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...