Ingénieur senior en recherche de travail. À propos des tâches lors des entretiens techniques et des questions théoriques

Nous continuons à parler des entretiens techniques (si vous n'avez pas lu, regardez les articles précédents de la série - sur les entretiens avec les RH et les techniciens ). Cette fois, il y aura une expérience plus subjective, un minimum de conseils, ainsi qu'un peu de tâches de test et de questions théoriques. Allons-y.

Avis de non-responsabilité: l'auteur n'est pas un développeur turbo, mais un macaque Web régulier sans aucune plainte. Par conséquent, les tâches et les solutions ci-dessus peuvent vous faire sourire, faire des fesses et désirer et vouloir indiquer à l'auteur son incompétence. J'ai hâte de vous voir dans les commentaires! :)

Discussion des éléments de test terminés

Dans la dernière partie, j'ai décrit comment j'ai effectué deux tâches de test: la première sur DevOps Engineer, la seconde sur Ruby Developer. Je vais vous dire ce qui s'est passé ensuite.

Entretien avec Ruby Developer - l'intervieweur n'a même pas regardé mon test, ne lui a pas posé de questions, n'a pas complimenté (j'ai terminé la tâche mieux que tous les candidats précédents, du moins le recruteur m'a flatté). Il semble qu'il ne savait même pas de lui. Cela m'a un peu bouleversé, car alors ils ont commencé à me demander la théorie, et, par conséquent, ils ont refusé par le biais de la théorie.

Interview sur DevOps Engineer - l'intervieweur a regardé la mission, a fait un compliment (a déclaré que je l'avais terminé qualitativement) et a posé quelques questions de contrôle sur la solution: pourquoi cette ligne est-elle ici? si vous remplacez la condition par celle-ci, dans quel fichier devrez-vous procéder? pourquoi cette approche est-elle utilisée ici? et ainsi de suite. Comme me l'a dit le recruteur, certains candidats n'ont pas effectué de tâches par eux-mêmes et n'ont pas pu répondre à ces questions. Par conséquent, ici, j'ai réussi sans problème.

Dans le premier cas, je n'ai pas demandé à la personne interrogée s'il avait regardé ma tâche de test et ce qu'il en pensait. Mais c'était nécessaire! Si vous avez une telle situation, assurez-vous d'en parler à vos interlocuteurs.

Tâches d'entrevue

Nous continuons le sujet des tâches de test de la partie précédente et considérons les tâches de codage lors des entretiens.

Il peut y avoir plusieurs types de tâches: implémenter un algorithme, écrire une solution en pseudo-code, refactoriser quelque chose, etc. Nos ingénieurs adorent les problèmes algorithmiques.

Beaucoup de gens, y compris moi-même, pensent que ces tâches ne montrent que la capacité du candidat à résoudre de tels problèmes, et ne montrent pas du tout comment il va faire face à des tâches de travail réelles, qui, en règle générale, sont de niveau supérieur. Pourquoi leur donnent-ils encore? Je pense que la raison est simple: les enquêteurs ne sont tout simplement pas en mesure de trouver quelque chose de mieux. Et comme nous ne pouvons rien trouver de mieux, prenons les bonnes inversions de la vieille ligne, le tri, l'équilibrage des arbres, etc.

En tant qu'outils utilisés pour la solution, l'éditeur de code + repl + la possibilité de collaboration est le mieux adapté. De toutes les options sur le marché, j'aime le plus CoderPad . Une salle est créée où vous et les enquêteurs vous connectez, vous pouvez éditer, exécuter du code ensemble et regarder les résultats de l'exécution. Très confortable. S'il n'y a pas d'argent pour un codepad, repl.it se lance dans la bataille et le partage d'écran est fondamentalement le même, mais sans possibilité de collaboration.

Mise à jour: pendant la traduction de l'article, repl.it a ajouté le mode multijoueur, qui permet à un nombre illimité de participants de travailler simultanément avec le code. Totalement gratuit! CoderPad n'est plus nécessaire, cheers!

J'ai eu un entretien avec l'entreprise pour le poste de développeur Java . L'entreprise fait quelque chose comme CRM et écrit un tas d'intégrations. J'ai contacté un spécialiste technique Zoom et il dit: "Commençons par le problème algorithmique." Je réponds: "D'accord, je vais faire la tâche, mais j'ai une question: avez-vous besoin de ces connaissances dans votre travail, avez-vous besoin de résoudre des choses similaires?" À quoi j'obtiens une réponse phénoménale: "Nous écrivons des points de terminaison de repos et conduisons json-chiki dans les deux sens, mais ce n'est pas intéressant d'en parler , alors résolvons le problème." C'est-à-dire que l'intervieweur lui-même a reconnu son incompétence. Je ne sais pas qui comment, mais à partir de ce moment, j'ai réalisé que je n'aurais rien à attraper là-bas. Cependant, par intérêt sportif, la conversation s'est poursuivie.

Nous avons ouvert le pavé de codage et procédé à la tâche, dont la condition m'a été exprimée oralement: "Trouver la plus longue séquence de caractères uniques dans une chaîne donnée." Après cela, l'intervieweur a déclaré que «l'on pourrait donner une tâche à la programmation dynamique , mais nous nous limiterons à une option plus simple». J'aimerais regarder sérieusement la personne qui se chargera de la programmation dynamique lors des entretiens.

J'ai répété les conditions de la tâche à l'enquêteur pour m'assurer de bien le comprendre, auquel j'ai reçu une réponse affirmative et commencé à travailler. Au bout de 5 minutes, il s'est avéré que je comprenais tout de même mal le problème, car il fallait trouver non pas une sous-chaîne, mais sa longueur (c'est plus facile). Cependant, j'ai répondu: "Eh bien, depuis qu'ils ont commencé, résolvons le problème avec un astérisque, et pas avec un simple." L'intervieweur était un peu confus, car il avait préparé les tests spécifiquement pour ses conditions, mais j'ai déjà décidé que je ne donnerais pas le dos et essayerais de le faire tel quel. J'ai demandé combien de temps j'avais (environ 40 minutes) et j'ai commencé à coder. Je note que, malgré le fait que je savais qu'ils allaient confier des missions, je ne me préparais pas spécialement.

J'ai donc immédiatement écrit des tests et commencé à chamaniser avec les indices i, j et k :) Boucles en boucles, etc. Au bout de 15-20 minutes, j'ai eu une solution à demi-travail, mais les cas limites que l'intervieweur a donnés n'ont pas été traités. Encore 20 minutes leur ont pris, à la fin, j'ai toujours correctement terminé la tâche. L'enquêteur semblait satisfait, puis a commencé à me poser des questions sur les structures de données. Il s'est avéré que pour résoudre le problème qu'il voulait donner au départ, il serait possible d'utiliser un hashset, ou quelque chose comme ça, et il s'attendait à une telle solution, mais j'ai tout cassé.

Ensuite, nous avons parlé un peu du projet (formes et piles). Et puis il dit: «Après cela, il y aura une interview sur la conception du système. En général, je ne vois aucune raison de le faire, car nous ne le faisons pas ici et nous n'avons pas besoin de telles connaissances, mais l'ordre est l'ordre, donc la prochaine étape est la suivante. Eh bien, vous comprenez - deux (!) Entrevues sont menées pour comprendre si le candidat peut faire des choses qui ne sont pas nécessaires dans le travail quotidien dans cette entreprise. Puis je me suis permis de parler un peu du vide de sens de ces entretiens. L'enquêteur était d'accord avec moi, mais a de nouveau inclus la délégation de responsabilité et a déclaré: "Je ne décide pas quel devrait être le processus, alors nous faisons ce que nous faisons." J'ajouterai que je suis passé par la deuxième interview (sur la conception du système) et qu'elle était aussi dénuée de sens que la première.

Quelle erreur l'intervieweur a commise - il n'a pas fixé les conditions de la tâche dans le texte. Lorsque j'ai mené de tels entretiens, j'ai simplement copié les conditions de la tâche dans l'éditeur de code pour que le candidat n'ait pas de questions.

Quelle erreur j'ai commise - je me suis immédiatement précipité pour écrire le code, sans préciser trois fois si j'avais bien compris la condition. Si vous êtes chargé de telles tâches lors des entretiens, déconnectez-vous immédiatement du chat et trouvez-vous une leçon plus intéressante; vérifiez plusieurs fois si vous avez bien compris la condition, écrivez un test dans l'éditeur et vous recevrez une confirmation de l'intervieweur que tout est correct.

J'ai également eu une interview pour le poste de développeur Ruby . Après avoir rencontré et posé des questions par défaut, on m'a confié la tâche d'écrire la méthode each_slice. Pour ceux qui ne le savent pas, c'est une telle chose qui frappe un tableau de sous-réseaux d'une taille donnée et exécute pour chacun d'eux un bloc que nous avons passé à la méthode, ou renvoie un itérateur sur ces sous-réseaux. Je me suis assis pour écrire, puis j'ai allumé le tuping. Le problème est que sur Ruby, pendant un certain temps, je n'ai été engagé avec succès que dans le web macing et, en tant que liste blanche de référence, je ne connaissais pas certaines des constructions de base du langage. À savoir - je ne savais pas que l'index de la boucle for est immuable (contrairement, par exemple, à Java).

J'ai écrit la méthode elle-même plus ou moins rapidement, mais cela n'a pas fonctionné et je ne comprenais pas pourquoi. J'ai commencé à paniquer un peu, j'ai tout supprimé et j'ai encore écrit, mais mon code n'a pas fonctionné comme il se doit.
"Ça n'a pas marché", ai-je pensé, et j'ai dit à mes interlocuteurs: "Les gars, vous savez, je suis bon en hébergement de sites Web et en projets, mais je ne réussis pas avec vos tâches stupides. Je comprends que c'est une tâche simple et qu'une personne avec 10 ans d'expérience est simplement obligée de le faire rapidement. Alors, ne me retardez plus et nous nous disperserons. » Les gars ont accepté et se sont séparés.

J'ai été sérieusement bombardée parce que je n'avais pas l'habitude de perdre si facilement. Afin d'entrer en quelque sorte dans un plus existentiel, j'ai écrit à un recruteur que j'avais décomposé sur une tâche qui n'était pas liée au vrai travail. Puis il s'est calmé, s'est assis, a rapidement testé le fonctionnement des index en cycles. J'ai réalisé que j'avais fait une erreur junior, refait l'index et obtenu une solution toute faite. En fait, l'erreur que j'ai eue était sur la même ligne. J'en ai parlé aux RH et lui ai suggéré de transmettre le lien vers la solution aux gars s'ils étaient intéressés, car j'ai toujours résolu le problème. Mais elle a répondu: "Vous n'êtes pas allé plus loin parce que vous n'avez pas résolu le problème, au revoir ." J'ai encore un peu compris les processus d'entrevue brisés afin de nous justifier en quelque sorte et nous nous sommes séparés.

Après cela, j'ai repensé mon attitude face à de telles tâches. Habituellement, cela n'a jamais été un problème pour moi de coder quelque chose sous supervision, mais plusieurs facteurs ont fonctionné ici: ma candidature à un poste sérieux, un manque de compréhension des constructions de base du langage (bien que je n'en ai jamais eu besoin, et si je l'étais, je pourrais google la solution en 5 secondes) et l'effet de l'observateur. Bien sûr, j'ai lu que beaucoup de gens ne peuvent pas résoudre les problèmes quand ils les regardent, mais il m'a toujours semblé que c'était une excuse pour ma propre insécurité et mon incompétence, jusqu'à ce que je tombe moi-même sur ces gars durs avec chaque tranche.

J'ai également eu une interview pour le poste de développeur Java. Cette fois, elle s'est déroulée dans un format légèrement différent. Nous avons contacté Zoom et l'intervieweur a déclaré: «Dites-moi votre e-mail, je vous enverrai une tâche, lisez-la, dites-moi si tout est clair. Vous aurez deux heures, je serai en sourdine et je ne regarderai pas ce que vous faites là-bas (nous ne jouons pas avec l'écran). Deux heures plus tard, nous entrons en contact, tâtonnons l'écran et voyons ce que vous y avez fait. Vous pouvez utiliser n'importe quoi. " J'ai lu les conditions de la tâche, en ai reparlé avec l'intervieweur, j'ai désactivé la vidéo (car le codage du flux mange le CPU) et je me suis trompé. Ouvert l'IDE et a commencé.

La tâche était liée aux E / S - il était nécessaire de créer une API pour écrire des données dans un fichier sur le disque, afin que tout soit sûr et rapide pour les threads, et également d'écrire des tests unitaires qui vérifieraient cela (y compris la sécurité des threads). Je n'ai pas travaillé avec la concurrence et les E / S depuis longtemps, j'ai donc dû rapidement passer en revue les quais et me souvenir de ce qui se passait. J'ai écrit une solution sur le front, vérifié qu'elle est thread-safe, etc. Tout sur tout m'a pris environ une heure et demie. J'ai cinglé mon intervieweur, j'ai dit que j'étais prêt, mais il n'y avait qu'une petite chose à polir, allons-nous chercher? À cela, il a répondu: "Asseyons-nous pendant encore une demi-heure et terminons tout ce que vous n'avez pas terminé." Ok, je me suis assis et j'ai pensé à toutes les petites choses et à la rugosité, j'ai fini le javadki, encore une fois j'ai lu tout ce que je pouvais sur les E / S et j'ai pensé quels pourraient être les inconvénients de ma solution.

Après une demi-heure, nous sommes entrés en contact, j'ai partagé l'écran, montré le code, exécuté les tests, etc. La demi-heure suivante, nous avons parlé strictement de la résolution du problème et des options possibles pour sa modification lors du changement de certaines conditions. Je veux attirer l'attention sur le fait que dans les entretiens précédents (et dans les suivants également), personne n'a préparé la base de la conversation par tâches, c'était toujours juste une sorte de morceau abstrait, qui donnait 0/1 à la sortie, et nous sommes passés à la question suivante. Et ici, la tâche était assez simple pour qu'elle puisse être effectuée en quelques heures, mais en même temps suffisamment approfondie pour ajouter des conditions et discuter avec le candidat de la manière dont il allait finaliser la décision.

J'ai vraiment aimé cette interview. J'ai pu montrer que non seulement le fizz buzz peut résoudre, mais aussi comprendre quelque chose dans les architectures. L'intervieweur était convaincu qu'il n'était pas assis en juin, mais un spécialiste qui tire quelque chose dans son travail. Ce fut la meilleure interview technique que j'aie jamais eue. Je pense que vous avez déjà deviné que l'intervieweur n'était pas l'un des nôtres :) J'ajouterai également que je l'ai réussi, puis deux autres étapes et finalement reçu une offre. Mais c'est une autre histoire.

Quelle était la qualité de cette tâche?

• La proximité du vrai travail, de ce qu'ils font dans cette entreprise.
• Limite de temps.
• Manque d'observation.
• La possibilité d'utiliser n'importe quoi et non une vérification de la mémoire.
• Créer une base pour une conversation ultérieure.
• Tester les compétences du candidat pour coder, utiliser l'IDE et réfléchir en général.

Malheureusement, parmi toutes les interviews, je n'avais que trois tâches de ce type, donc la sélection est petite. Il y a peut-être des tests / tâches plus difficiles, mais je ne les ai pas obtenus.

Lacunes typiques des tâches d'entrevue

1. La tâche n'a rien à voir avec un vrai travail. Cela m'énerve le plus. Les algorithmes sont autorisés à résoudre, bien qu'en réalité les piles soient rivetantes. Laissons la tâche pertinente, je vais vous faire un brut! Pourquoi avez-vous besoin d'une personne qui sait comment rechercher des sous-chaînes dans des chaînes?
2. Organisationnel - il n'y a souvent pas d'outil normal pour une solution. Une fois qu'ils m'ont montré le code dans google docs, une fois que j'ai fouillé l'écran dans repl.it, une fois était CoderPad.
3. La tâche ne crée pas de contexte pour une conversation ultérieure - c'est une conséquence du premier paragraphe. Pourquoi donner une tâche si nous n'en discutons pas plus tard?
4. Tout le monde ne peut pas faire face à la tâche sous surveillance. En conséquence, un bon candidat peut être éliminé à ce stade.

Questions théoriques

Ceci est ma partie préférée. Tout le monde aime demander de la théorie, revoyons cela un peu.

Pour une raison quelconque, il s'est avéré que la théorie m'était surtout demandée aux postes de l'ingénieur Ruby. Je la connaissais le pire de tous, alors je remplissais constamment les interviews et ressemblais à un juin jusqu'à ce que je réalise que ce n'était plus approprié de continuer comme ça. Je me suis assis et j'ai lu un manuel sur la langue, ce qui m'a permis de parler beaucoup mieux et sans pleurnicher «Les gars, pourquoi me demandez-vous cela? Je suis un bon développeur, quelle est la différence, quel est l'ordre de la méthode de recherche d'un objet? Qui a besoin de ça? "

La première interview à laquelle je suis allé en tant que développeur Ruby était exactement l'endroit où la tâche de test devait être effectuée, mais il s'est avéré que personne n'était intéressé. Timlid, qui était censé communiquer avec moi, n'est pas venu (il était coincé dans un embouteillage ou quelque chose), alors ils m'en ont donné un autre. Après la réunion, il dit: "J'ai une règle - je mène toutes les interviews en anglais, alors nous passons à l'anglais." Et puis mes oreilles sont tordues en un nanotube de graphène, car l'intervieweur a un accent très fort. Cela m'a quelque peu troublé (il m'est très difficile de communiquer avec mes compatriotes en anglais).

Viennent ensuite les questions: qu'est-ce qu'un module, qu'est-ce qu'un bloc, quel est le rendement, et j'ai commencé à déposer. Au lieu de définir "comme dans un manuel", j'ai commencé à babiller: "Eh bien, je ne connais pas la définition exacte, mais c'est probablement une chose pareille, je l'ai utilisé comme ça." L'enquêteur était mécontent, j'ai commencé à le ressentir et j'ai alors pensé que tout le monde était arrivé.

Ensuite, il y a eu des questions sur des méthodes spécifiques, à savoir: "Quel est le nom de la méthode qui filtre tout le zéro dans la collection?" Puis j'ai allumé le troll et j'ai répondu: "Si vous vérifiez ma mémoire pour connaître ces méthodes, je ne peux rien vous dire sur ce que je n'ai pas utilisé récemment. J'écris dans de nombreuses langues et plates-formes et je ne me souviens pas de toutes les méthodes du SDK. " Cela n'a pas satisfait l'intervieweur, et la question suivante était quelque chose comme: «Qu'est-ce qui est énumérable? Quelles sont les méthodes et qui vont les étendre. » "Mon oncle, n’avez-vous pas compris?", Me suis-je dit, mais j'ai dit à haute voix: "Je ne sais pas avec certitude, je pense qu’il existe des méthodes comme map / réduire / slice et ainsi de suite." Cela ne lui convenait pas non plus.

Puis il m'a posé une question standard sur l'endroit où mettre la logique dans MVC. J'ai répondu que dans le modèle, et si ça ne rentre pas dans le modèle, alors dans d'autres classes. Il s'est avéré que les soi-disant objets de service étaient la bonne réponse (ces déchets sont-ils arrivés ici aussi?). J'ai marmonné quelque chose en réponse, comme, eh bien, vous pouvez l'appeler comme ça, mais je n'aime pas ça.

Puis il a posé la question par défaut sur SQL, à laquelle j'étais déjà en mesure de répondre correctement, puis a posé une question sur RSpec, que je n'ai pas utilisé, c'est tout. Sur Rails (et ils avaient juste des rails), je n'ai reçu aucune question. De plus, je n'ai pas reçu une seule question sur mon expérience précédente.

Après cela, il m'a demandé ce que je pensais des stand-up quotidiens. Ensuite, j'ai décidé de ne pas donner les réponses socialement attendues (la grange a brûlé - brûle et hutte!), Et j'ai immédiatement dit que c'était une perte de temps et était pratiqué dans des équipes où le manager ne pouvait pas garantir la transparence et la facilité de rendre compte des progrès. Et il a ajouté que Scrum est une poubelle dans de l'huile végétale, et personne ne travaille normalement selon la mêlée, mais tout le monde fait semblant. Évidemment, j'ai quand même saisi le contre.

De plus, il a suggéré de lui poser des questions (apparemment par politesse), et moi, de ma propre tête, j'ai posé des questions sur le processus, l'architecture, etc. Ce que j'ai entendu, je n'ai pas aimé, car ils faisaient beaucoup de vélo pour des tâches typiques. Je voulais faire comprendre au gars que je n'étais pas seulement un développeur, mais je pouvais en faire un peu plus, mais tout était en vain, et bientôt il a dit qu'il devait aller au rallye et mettre les voiles.

Le lendemain, un recruteur m'a écrit et m'a informé du refus. "Et Dieu merci," pensai-je, mais toujours un peu brûlé. J'ai eu l'impression que l'intervieweur avait des préjugés depuis le tout début, je ne sais pas. À propos, c'était le même bureau qui avait traîné un mois entre le premier contact et une entrevue technique.

Alors, ils m'ont refusé parce que je ne connaissais pas les bases de la langue (Ruby). Ok, passons.

Une autre interview chez Ruby Debeloper , deux intervieweurs déjà. C'est bien qu'au moins un soit parlé en russe, le second - en ukrainien, donc je n'ai pas eu à me casser le cerveau. À ma grande surprise, la même histoire commence: quels sont les modules, quels sont les blocs. Je n'avais pas encore lu le manuel, j'ai donc nagé à nouveau dans les réponses. Plus questionné sur les types d'associations dans Rails. Enfin, au moins quelque chose, pensai-je, et j'ai nommé trois espèces de mémoire. ( ), , : « ». , — each_slice. , , . : « , - Rack middleware?». , . , , ( Java Servlets, middleware - Laravel/Express), . , .

, , . . , , rack middleware, , .

. — . , , , , …

Ruby Developer. , . , , . Proc, , :) : « , , , - ». 100% , - , . .

: « require». Rails Grape, , , . « , ». , . - -, « , ?». ActiveRecord — , .

concurrency ( ). , concurrency Ruby — . , , . , MRI — JVM , volatile synchronized , . , , ( !) concurrency . ? ?

, - SOLID. , « — », . , . , . - , . , « ». .

? . , , , . , ! ( ). , , Cracking Ruby Interview, . , - «» , , , :)

.

Fullstack Java Developer. — . , . , , Java.

, , , - . , , , , . , , .

. . , , , undefined null, var. JS WAT-. : «, WAT . , , , ». , -. «JavaScript: The Good Parts», .

, , . (?) , ( , ) , . . , :)

- , , . jQuery, . :)

DevOps Engineer , . : « ?». - :) , , — . , . , , , . . ( )?

( MVC). (-) 5-10 . ( GoF) . . Ruby-, , — , , ( MVC ActiveRecord ). Java- .

SOLID , , : Ruby-, — Java. DRY :)

?

1. , .
2. , .
3. , .
4. , .

, , :

• / . , . : « -AOP AspectJ Spring?» :) , , .
• LeetCode , .

, , . , , « » , .

( , ), , !