Récemment, j'ai pris des entrevues et constaté que beaucoup de questions étaient liées aux algorithmes et aux problèmes de mathématiques.
Je pense qu'il y a beaucoup de choses qui sont importantes autres que les algorithmes, telles que l'expérience, la connaissance spécifique à un domaine, la connaissance de base du système d'exploitation / compilateur, etc.
Pourquoi posent-ils tant de problèmes algorithmiques?
Fondamentalement, les algorithmes sont au cœur de la programmation. À peu près tout ce que vous écrivez suit une sorte d'algorithme, que vous le réalisiez ou non.
Et les problèmes de math montrent à quel point vous êtes capable de résoudre des problèmes logiques (un peu comme ceux que vous rencontrez en codant).
L'un des plus mal compris des éléments de l'interview est pourquoi certaines questions sont posées. La raison les gens ne comprennent pas, c'est que la plupart des gens ne réalisent pas que de vous poser une question, vous savez la réponse est que la moitié de l'interview. J'ai besoin de vous poser des questions que vous ne savez pas la réponse. Pourquoi? Parce que j'ai besoin de voir un couple de choses:
En tant que développeurs, nous seront constamment faire face à des défis que nous ne savons pas la réponse. En tant que gestionnaire d'embauche, j'ai besoin pour évaluer la capacité d'un prospect. Donc, je vous poser une question j'espère que vous ne connaissez pas et de regarder ce que vous faites. Quand je vois que vous ne connaissez pas, je vous demander, "qu'en pensez-vous?" pour voir si vous l'expliquer. Si vous pouvez expliquer vos idées de manière claire et concise et de gérer la pression d'être dans une situation difficile, qui me dira beaucoup sur la façon dont vous travaillez dans un environnement de stress élevé.
La dernière, et peut-être le plus important, la raison est la BS question. De nombreuses fois (notamment les consultants) sera posé des questions dans un forum où l'on doit donner une sorte de réponse. Lors d'une réunion avec un client par exemple. J'ai besoin de comprendre votre propension à BS. Rien ne peut mettre un projet en difficulté plus vite que quelqu'un qui va BS plutôt que de simplement dire "je ne sais pas, je peux vous revenir avec une réponse à cette question après je parle à certains experts à mon entreprise?"
Aussi, franchement, les algorithmes sont des questions faciles à poser pour l'interviewer. L'interview est extrêmement pénible. Vous demandez la même chose encore et encore et encore. Ça devient lassant et rote. Parfois, je pose des questions, je n'ai aucune idée de ce que la réponse est juste pour briser la monotonie!
Les questions relatives aux algorithmes ne tiennent pas compte de l'environnement et semblent pouvoir permettre de tester l'intelligence d'une personne. Il est beaucoup plus difficile de simuler une compréhension d'algorithmes que de connaître un ensemble de faits sur certaines technologies.
OMI, cela vaut la peine de poser au moins des questions simples sur les algorithmes, car elles révèlent si une personne peut réellement s'asseoir et réfléchir pendant un moment, et pas seulement google et copier-coller.
Il y a déjà quelques de bonnes réponses, mais j'espère que je peux ajouter quelque chose. Dans mon esprit, vous avez à regarder cette question dans le contexte plus large de
"Ce qui constitue une entrevue efficace?'
ou même plus simplement
"Comment savez-vous que la personne que vous interviewez sera travail?"
En tant que responsable du développement, j'ai très peu d'options. Dans un monde idéal, et compte tenu de l'infini du temps et des ressources, vous permettrait d'apporter un potentiel de chaque nouvelle location, demandez-lui de travailler pour un mois ou deux, et de faire une évaluation à la fin de cette période, s'il était utile de garder. Ce n'est pas faisable, cependant, pour un certain nombre de raisons:
Un peu plus pratique que la version de cette opération est d'offrir des stages à des étudiants ou récemment diplômés. De cette façon, vous pouvez voir comment la personne travaille, à fabriquer un reslationship, et si il est vraiment exceptionnel d'étendre une offre.
Dans la plupart des cas, cependant, il est impossible de simplement apporter une personne. De la sorte, alors vous êtes de retour à un certain type d'entrevue. Les questions que l'on peut poser à l'intérieur d'une certaine période de temps sont nécessairement circonscrit, et un peu artificiel. Il est difficile d'obtenir une sensation pour les capacités de quelqu'un dans un très court laps de fenêtre, de sorte que vous devez décider de la manière proche, vous pouvez venir à ce que vous pourriez obtenir à partir de l'exercice de répétition décrit ci-dessus tout en limitant la quantité de temps et de ressources que vous investissez dans le futur employé.
Dans mon expérience, le meilleur test qu'il vienne avec un simple exercice de programmation (quelque chose que la plupart des gens devraient être en mesure de résoudre complètement dans les 2-3 heures), donner au candidat un ordinateur portable, l'accès à son IDE de choix, de Google, et de toutes autres ressources, il aurait quand en train de faire son travail. C'est le plus proche, vous serez en mesure de venir à l'évaluation de lui en vertu de "monde réel" des conditions. Bien sûr, l'exercice sera toujours un peu artificiel (mais si possible, il doit être le reflet d'un travail similaire à ce qu'il va vraiment le faire). Lui donner des informations incomplètes, peut-être un peu misqueues. Mettez-le dans une pièce, donnez-lui votre numéro de téléphone, et dites-lui qu'il peut vous appeler à tout moment, et vous aurez à répondre à toute question qu'il a fait.
À la fin, il peut ou peut ne pas avoir répondu à la question complètement. Mais regardez ce qu'il a fait. C'est le travail sur le plan conceptuel solide? Son code paraître raisonnable? Faisait-il de poser des questions intelligentes? Avait-il l'avis des pièges que vous définissez pour lui et de lui demander des éclaircissements?
Généralement, c'est la dernière étape dans le processus d'entrevue. Retour à la question initiale, je tiens à obtenir un plus en face-à-face se sentir pour les candidats à la résolution de problèmes de compétences et de connaissances.
Comme d'autres l'ont mentionné, 8 personnes sur 10 qui de soumettre un curriculum vitae ne peut même pas résoudre le plus simple des questions dans la langue de leur choix. Je ne cesse d'être surpris par cela. Je ne peux même pas compter le nombre de gens que j'ai interrogés qui avaient reprend inscription '8 années de Java EE' expérience et pourtant pouvais à peine le programme "Hello World" en Java. Comme un résultat, j'ai appris à ignorer en grande partie reprend. Coversely, certaines personnes qui ont vraiment merdique reprend, ne phénoménale dans une interview. À moins que le résumé est juste atroce, presque chaque futur candidat obtient un écran de téléphone. Au lieu de quelque chose de mieux, je vais demander un peu de structure de base de données et algorithmique des questions.
Encore une fois, comme d'autres personnes l'ont mentionné, une question sur un algorithme ne devrait pas être posée comme un test pour voir si la personne peut mémoriser les choses. Je n'avais jamais demander de me parler de l'algorithme QuickSort?' alors si la personne ne s'en souvenait pas, le disqualifier. Non, ces questions sont posées de voir une personne du processus de pensée, un sentiment qu'ils comprennent les principes de base de l'informatique (par exemple, si une personne ne peut pas me donner les notions de base de ces listes, les tableaux et les tables de hachage, il va vraiment avoir une rude bataille). La chose est aussi artificiel que de telles questions sont, ils sont la meilleure chose que nous avons. Si j'ignore reprend, j'ai besoin d'une certaine manière à choisir la vraiment atroce et je ne perdez pas de 3-4 heures sur un parking. Et lorsqu'un candidat se rend sur place, j'ai besoin d'un moyen pour choisir les personnes qui ne devraient pas avoir passé l'écran. C'est une escalade de l'échelle. Encore une fois, comme artificiel, comme la plupart des questions sont des questions que devlve dans les fondamentaux de l'informatique, ceux que l'illustration d'une personne compétences de résolution de problèmes, et que de me montrer la personne peut penser sont le meilleur outil que j'ai après avoir vu comment la personne effectue dans le monde réel.
La pire des questions d'entrevue pour moi, ce sont ceux tha besoin rote récital de faits. J'ai toujours eu une rude bataille avec les départements de ressources humaines et de mes patrons, arguant que je n'ai pas de soins si une personne sait mettre en veille prolongée ou de Printemps ou ce que les technologies nous arrive d'utiliser. - Je me soucier de quelqu'un qui peut penser de façon critique, a une solide maîtrise des notions de base (y compris l'efficacité des compromis à des algorithmes & structures de données) et qui semble avoir un geniuine intérêt dans l'apprentissage de nouvelles choses.
Qui l'emporte sur le savoir à l'avance à chaque fois.
Je pourrais bien être un de ces enquêteurs, comme j'ai tendance à poser quelques questions autour de la mise en œuvre d'un couple de très simple des structures de données lors d'entretiens en face à face. J'ai également été appelé à poser des questions mathématiques dans le passé, mais étant donné que ces rôles ne nécessite de comprendre au moins de niveau secondaire en mathématiques, c'était juste un jeu.
Ma principale raison de poser ces questions est double:
Algorithmes et structures de données sont des concepts abstraits. En demandant à un candidat à les décrire et à mettre en œuvre dans un langage de programmation, vous pouvez avoir une idée de leur capacité à réfléchir aux problèmes puis les traduire et de les appliquer à un problème à la main. C'est l'une des compétences les plus importantes pour un développeur parce que vous êtes constamment la traduction entre le domaine du problème et la mise en œuvre de domaine. Un développeur qui a de la difficulté à faire cela pourrait encore être OK à manivelle code, mais nécessitera souvent de quelqu'un d'autre pour fournir la traduction, ou de créer une solution sous-optimale. En fonction de la taille et de la structure de l'équipe, cela peut être énorme fardeau sur le reste de l'équipe.
Algorithmes et structures de données sont des blocs de construction fondamentaux de notre métier. Les langues et les technologies changent au fil du temps, mais ces principes de base ne le sont pas. Un bon développeur expérimenté devrait être capable de trouver son ou ses pieds dans un langage de programmation assez rapidement et ont à plusieurs reprises au cours de leur carrière. Cependant, ce qui reste la même, les concepts (quicksort ne pas changer si vous modifiez les langues) de sorte que même si vous ne pourriez pas être un expert dans la langue X, vous serez toujours en mesure de créer une solution pour un problème donné, si vous pouvez appliquer des algorithmes existants. Le dernier changement beaucoup moins souvent l'ancien.
Quant à votre question concernant l'expérience - comment mesurez-vous et de test pour l'expérience? Il y a beaucoup de candidats n'dont "huit ans d'expérience de" traduire en "huit répétitions d'une expérience de l'année". Une façon de le savoir au sujet de ces candidats (parce que le recruteur ou d'un agent qui les a envoyés à vous souvent ne peut pas ou ne veut pas) est de poser les questions qui nécessitent une plus profonde, plus abstrait compréhension de certains problèmes et de solutions. Ce qui nous ramène à la ci-dessus...
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
