Ingénieur senior en recherche de travail. Comment j'ai vécu 15 entretiens techniques et ce que j'en pense

La suite de l'histoire de la façon dont j'ai été interviewé dans différentes entreprises pour différents postes. Cette fois, nous fermerons quelques questions et commentaires concernant la première partie et continuerons à parler des tâches de test et des entretiens techniques.

À ma grande surprise, l' article précédent sur les entretiens avec les recruteurs et les RH a suscité un intérêt inattendu: plus de 100 000 vues de toutes les sources. J'ai reçu beaucoup de commentaires positifs dans PM, ils m'ont écrit par d'anciens collègues que j'ai vus pour la dernière fois il y a environ 5 ans; héroïnes de certaines histoires; un type à qui j'ai vendu une unité centrale via OLX il y a quelques semaines (analogue de Slando, - environ par.) ; le batteur avec qui nous avons joué du métal dans le garage l'année dernière et, curieusement, pas mal de recruteurs qui m'ont demandé ce que je pensais de certains aspects des interviews et de l'embauche. 250 personnes pour une raison quelconque m'ont ajouté sur LinkedIn :).

Avant de passer aux choses sérieuses, je répondrai aux questions les plus populaires et aux messages et commentaires personnels.

Comment organiser un salaire pour un entretien

De nombreux commentaires ont trait à l'argent. Je n'ai délibérément pas prêté beaucoup d'attention à cela, car les enchères sont une question distincte, mais les commentateurs l'ont toujours abordée et souligné les lacunes de ma stratégie - par exemple, nommer immédiatement le prix. Voici deux bons articles qui abordent cette question de manière beaucoup plus détaillée et professionnelle:

• Comment discuter de l'argent lors de l'entretien: stratégie de négociation pour le candidat
  
• Négociation des salaires: gagnez plus d'argent, soyez plus valorisé

Je recommande la lecture avant de chercher du travail.

Quelques réflexions sur le recrutement

Je ne conseille en aucun cas les recruteurs sur la façon de faire leur travail. Je ne suis pas un recruteur professionnel et je ne sais pas comment fonctionne leur cuisine intérieure. Lorsque je devais chercher du personnel (non seulement mener des entretiens techniques, à savoir la recherche et l'embauche - un cycle complet), alors il s'agissait de postes juniors, respectivement, je n'ai eu aucune difficulté particulière.

Dans des messages privés, ils m'ont demandé comment faire le premier message sur l'offre de travail, afin qu'elle paraisse attractive et intéressée par le spécialiste, comment attirer l'attention sur moi?

Il me semble que, malheureusement, rien ne dépend du recruteur. Tout ce qu'un recruteur peut faire est de trouver autant de contacts de spécialistes du profil nécessaire que possible et de leur envoyer une offre à tous. Après cela, vous devez attendre et espérer que l'un d'entre eux hésite ou recherche activement un emploi. Autrement dit, il y a 20% du travail avec la base et 80% de chance. Le réseau a beaucoup de matériel sur la façon de créer correctement des postes vacants, etc., mais pour moi, le facteur clé est précisément la volonté du candidat de changer d’emploi.

Le recrutement est la vente d'un poste vacant à un candidat. Le plus tôt vous comprenez cela et commencez à pomper vos compétences de vendeur, mieux c'est. Oh, j'ai dit que je ne donnerais pas de conseils :)

Je suis également convaincu que lors de la recherche d'emploi, les candidats doivent accepter tous les postes vacants qui conviennent plus ou moins, car en fait, découvrir de quoi il s'agit n'est possible que lors d'une conversation avec des spécialistes techniques. Dans mes recherches, je n'ai pratiquement pas prêté attention à ce qui était écrit dans le poste vacant et j'ai découvert les détails nécessaires au stade d'un entretien technique. Je pense que cette méthode est la plus correcte, car les chances de trouver un projet sympa qui peut se cacher derrière une description grise standard sont considérablement augmentées. Mon expérience ne fait que confirmer sans ambiguïté cette thèse. Pas une seule fois dans la vacance n'a été écrit spécifiquement ce qui devrait être fait. Seules des expressions générales comme «coder le code, tester les tests, déployer le déploiement».

S'engager dans une entreprise ou un projet

Dans nos réalités - définitivement pour un projet.

Comment choisir un titre

Je me suis positionné en tant que candidat au niveau d'Ingénieur Logiciel Senior et supérieur - Team / Tech Lead, Ingénieur Principal, Architecte Logiciel, Chef de Projet, People / Group Manager et ainsi de suite. C'est ce que le «ci-dessus» signifiait par «+» dans «Senior +».

Il me semble que le titre ne veut rien dire. La seule chose importante est ce que vous ferez réellement, et cela ne peut être découvert que par la personne avec laquelle vous travaillerez.

Alors, mesdames et messieurs, passons aux entretiens techniques.

Deuxième étape. Entretiens techniques

Dans cette partie, il y aura plus de mon expérience subjective et de ma philosophie que des conseils. Il y a beaucoup d'informations sur ce qui est demandé lors des entretiens techniques et comment s'y préparer sur Internet.

Clause de non-responsabilité: l'auteur n'est pas un turbo-ingénieur-olympiade, donc certaines décisions ou commentaires peuvent provoquer un sourire, une blessure au cul, le désir de signaler à l'auteur ses erreurs ou ses faibles qualifications. Je suis heureux d'écouter la construction.

Au total, j'ai passé 15 entretiens techniques, ce qui n'est pas tant que moi. J'aurais pu vivre bien plus, mais en moyenne je m'attendais à une semaine entre le premier contact avec un recruteur et une conversation avec un spécialiste technique. Et ce malgré le fait que je n'avais pratiquement pas de limite de temps. Une seule fois, j'ai programmé une interview pour le temps pour lequel j'avais déjà programmé une autre interview. Je note également que toutes les entreprises ou recruteurs sont venus me voir eux-mêmes. Je n'ai pas envoyé de CV à une entreprise en premier. C'est à la question que ce n'est pas le seigneur qui cherche du travail, mais le travail - le seigneur.

Tâches de test

De nombreuses entreprises donnent des tests avant de passer à une conversation pour éliminer les candidats non pertinents. Malgré le fait que beaucoup n'aiment pas investir leur temps dans des tâches de test, surtout si elles sont assez volumineuses, je pense toujours que c'est une bonne pratique. Voyons quelles peuvent être les tâches de test.

«Créez un projet à partir de zéro (peut-être en utilisant une technologie spécifique) et postez-le sur GitHub» - comme pour moi, la pire option. Vous pouvez passer beaucoup de temps sur un passe-partout, sur l'infrastructure autour de la solution, et l'intervieweur, en règle générale, sera intéressé par quelques petits détails de mise en œuvre définis dans les conditions de la tâche. Eh bien, si vous avez sous la main, par exemple, des modèles de projet et que vous pouvez soulever le serveur en 5 minutes et télécharger rapidement ce dont vous avez besoin. Sinon, vous devez vous souvenir de tout et recommencer à zéro. Il est également mauvais si la tâche a une condition pour utiliser des dépendances externes, par exemple, une base de données non intégrée.

Position Ingénieur DevOps. Ils m'ont envoyé une tâche pour faire une configuration Vagrant de plusieurs machines virtuelles, parmi lesquelles il devrait y avoir des serveurs web avec des statiques, un équilibreur pour eux et Jenkins. Tout cela devait être installé et configuré à l'aide de Chef. Imaginez maintenant - je n'ai jamais utilisé Vagrant, Chef et je n'ai pas configuré les serveurs Web nécessaires à la tâche. Je comprends comment tout cela fonctionne, j'ai utilisé des outils similaires, mais je ne les ai jamais utilisés spécifiquement.

J'ai dû m'asseoir pendant la nuit, réparer tout cela, ramasser un tas de râteaux et finalement terminer la tâche. La principale difficulté était que j'avais un vieux MacBook Pro de la 15e année, qui n'avait physiquement pas le temps de redémarrer les conteneurs, et aussi que je n'avais pas d'expérience avec Vagrant.

L'essence de la tâche - trouver comment installer quoi - m'a probablement pris une demi-heure. Le reste du temps (7 avec une queue d'heures), j'ai passé à installer tous les outils, à redémarrer - redémarrer, à fouiller les configurations pour essayer de comprendre pourquoi cela ne fonctionne pas, etc.
Je ferais probablement la même tâche sur Docker Compose en une heure, peut-être même moins. Ne pourriez-vous pas limiter le candidat aux outils? Il me semble que c'est possible.

Cette quête m'a-t-elle aidé? Certainement oui! Maintenant, je sais que Vagrant et Chef doivent rester à l'écart :)

Temps passé - 8 heures .

Malheureusement, je n'ai plus d'histoires sur ce type de tâche, car il n'y avait pas tellement de tests en général :(

«Voici un lien vers le site avec les tests - passez-les en revue» est une option très intéressante. À quoi ça sert? Il existe des SaaS qui vous permettent de configurer un ensemble de questions pratiques et théoriques et pour la solution, ils fournissent REPL et un éditeur de code directement dans le navigateur, ainsi que la possibilité d'exécuter des tests de vérification. Ensuite, vous allez simplement sur les affectations, corrigez celui qui existe ou écrivez votre propre code, exécutez-le et voyez les résultats. Les tests eux-mêmes vous sont cachés, vous ne voyez que le résultat (réussi / échoué) et une brève description du test, qui peut en même temps être un indice. Pourquoi j'aime le plus cette option? Parce qu'il existe un critère sans équivoque pour la qualité de la mission, et le candidat sait exactement combien de points il a marqué, si ses décisions fonctionnent, etc. Personnellement, j'étais même intéressé par ces tâches. La seule chose que je ne vois pas l'intérêt de problèmes théoriques comme "ce qui se passera si ce code est exécuté" - ils sont facilement google.

Poste d'ingénieur logiciel Ruby. Ils m'envoient un lien vers le site Web TestDome , bien sûr, vers un test personnalisé. Je clique, entre dans les tests réels. Ils me donnent 2,5 heures pour terminer l'ensemble, 5-20 minutes pour chaque question. En fait, ça m'a beaucoup plu, je n'ai pas vécu de telles choses depuis longtemps. J'ai particulièrement aimé l'approche TDD: j'ai codé, lancé, regardé ce qui est tombé, vous codez plus loin. Passé avec grand plaisir.

Les tâches elles-mêmes étaient assez simples: corriger le code (Ruby / JS / CSS / HTML), écrire des valideurs (Ruby), implémenter des structures de données (Ruby), rien de spécial. Cependant, le fait que vous puissiez vérifier immédiatement si la solution fonctionne est très utile.

J'ai terminé la tâche pour 93/100 points en seulement une heure. Malheureusement, ce résultat ne m'a pas du tout aidé à l'avenir.

TDD aide à la décision, pas besoin de passer du temps à augmenter l'infrastructure, à rejouer directement dans le navigateur - bref, très cool. Pour cela, il a été possible d'attendre un mois - au final, j'ai obtenu ma portion de dopamine (j'ai fait un excellent travail) et d'adrénaline (le temps tourne, moins de temps!).

Temps passé - 1 heure.

De plus, le grand avantage de ce type de tâche est que sa vérification est automatisée. Nous savons tous comment les enquêteurs «aiment» vérifier les devoirs, et ici la machine fait tout pour eux - c'est très pratique, du moins vous n'avez pas besoin de télécharger le code et de le récupérer. Peut-être que j'utiliserai cette méthode lors de l'embauche à l'avenir.

"Voici le référentiel, il y a une tâche, envoyer une Pull Request avec une solution" - Je n'ai pas trouvé une telle option, mais mes collègues l'ont utilisée. Je ne l'aime pas vraiment, car vous pouvez voir comment les autres candidats ont effectué la tâche (s'ils l'étaient).

Les inconvénients de cette méthode sont évidents: le testeur doit télécharger le code, collecter, regarder ce qu'il y a, c'est long et ennuyeux. Bien sûr, vous pouvez superficiellement voir le code dans le navigateur, mais pourquoi alors avez-vous eu besoin d'une tâche? Écrivons alors sur le pseudo-code.

«Voici le référentiel, il y a le code, refactorisez-le autant que vous le pouvez» - une variante du précédent. C'est mieux, car ici, dès le début, un cadre est créé pour travailler. Les inconvénients sont les mêmes: on ne sait pas quand s'arrêter. Comme l'a dit Egor Bugaenko, tout programme contient un nombre infini d'erreurs, et elles peuvent également être corrigées indéfiniment.

Les auteurs de la mission avaient probablement quelque chose en tête lorsqu'ils l'ont créée, nous ne saurons probablement pas ce qui était le principal pour eux seuls. Si la tâche avait un critère clair, ce serait cool. Par exemple, "il y a un code, il produit un tel résultat sur la vitesse sur un tel matériel, refactorisez-le pour qu'il fonctionne deux fois plus vite." C'est difficile de travailler sans critère. Dans la vraie vie, dans le vrai travail, nous avons toujours un cadre et recherchons la solution optimale, guidée par ce cadre et le bon sens. Le travail principal du développeur est simplement de ressentir cet équilibre et de trouver la solution appropriée.

À mon grand regret, personne d'autre n'a donné de tâches de test, donc ma sélection est très petite. À moins que je ne me souvienne de ces tests que j'ai faits il y a de nombreuses années. Tous étaient du premier type - un projet devait être fait. Fait intéressant, je les ai exécutés à l'époque où GitHub n'était pas encore si populaire et il fallait envoyer la solution dans l'archive zip par mail :)

Mes recommandations pour les éléments de test?

1. Ne l'aime pas - ne l'aime pas. Si la tâche, par exemple, consiste à terminer l'ensemble du site ou à écrire une crud - eh bien, mettez-le dans les bains. Les devoirs doivent être courts et axés sur la création d'un contexte pour la discussion qui suit, et non pas seulement un test sur la façon dont vous pouvez faire des échafaudages.
2. Si la tâche est du premier type - ajoutez au référentiel du fichier Lisez-moi, où décrivez en détail les instructions de démarrage, une courte annotation expliquant pourquoi vous avez pris une telle décision, quelles sont ses lacunes, ce que vous avez aimé ou non, comment résoudriez-vous la tâche, si vous aviez plus de temps, etc. Je ne sais pas si cela aide vraiment, mais en tant qu’intervieweur, je mentionnerais certainement une telle documentation de la décision.
3. Écrivez normalement, mais vous ne devriez pas passer beaucoup de temps à lécher des pièces. Quant à moi, il suffit de simplement lister dans le fichier Lisez-moi tout ce que vous amélioreriez s'il s'agissait d'un code de bataille.
4. Assurez-vous de réfléchir aux questions que vous pourriez avoir sur la mise en œuvre et de lire la documentation supplémentaire sur l'API que vous avez utilisée. Supposons que je n'ai pas travaillé avec la concurrence depuis longtemps. Je n'ai pas pratiqué cela depuis longtemps, donc après la décision, je suis passé rapidement en revue tous les sujets connexes, je me suis souvenu de toutes les tâches typiques et j'étais prêt pour la conversation.

Eh bien, testez-en un, j'espère que vous l'avez réussi, transmis cette information au recruteur, et après un temps indéfini, vous serez invité à parler en personne.

Entretien technique. Intro

Pour commencer, ils sont désormais rarement invités au bureau pour des entretiens. Je n'ai été appelé au bureau que plusieurs fois - pour un entretien aux postes de Solution Architect, Tech Lead et une fois - pour un poste de direction. Toutes les autres interviews ont eu lieu via Skype, Zoom, Hangouts. Comme lors de l'entretien précédent avec le recruteur, les recommandations sont les mêmes: un bon appareil photo, un bon casque, un bon Internet. J'ajoute également à cela la condition de tâtonner l'écran. Par conséquent, assurez-vous que vous n'avez pas de projets de travail ouverts (si cela est important) et d'autres choses personnelles que vous n'avez pas besoin de montrer aux gens à cette fin. Gardez sous la main un navigateur propre sans onglets et REPL pour le codage au cas où (IDE ou repl.it ).

De toutes les méthodes de communication, j'aime surtout Zoom. En fait, il a été utilisé le plus souvent.

Un conseil important concernant la bonne communication dans les groupes de discussion: prenez l'habitude de ne pas parler ou de taper sur le clavier quand une autre personne parle et parle sur le casque, et non, par exemple, via un microphone externe pour ordinateur portable et des haut-parleurs externes.

Pourquoi est-ce important? Le plus souvent, deux personnes vous parleront respectivement, elles n'utiliseront pas le casque. Lorsque vous parlez, le logiciel inclut de son côté un coupe-bruit qui empêche l'apparition de l'effet de rétroaction (fond, sifflement, écho). Lorsque l'annuleur de bruit est activé, leur microphone n'attrapera pratiquement rien, vous n'entendrez donc pas ce qu'ils vous disent.

Lorsque vous tapez sur le clavier, cela crée du bruit qui est transmis de l'autre côté et inclut également la réduction du bruit. À la suite de cela, les phrases se rompent et l'impression d'une mauvaise connexion est créée. Par conséquent, vous devez toujours attendre que les gens terminent la conversation. Sinon, vous n'entendrez tout simplement pas ce qu'ils voulaient dire (sauf lorsque les interlocuteurs utilisent également le garntiru). Curieusement, beaucoup de gens ne connaissent pas ces mécanismes. Il est également utile de désactiver le microphone pendant que vous parlez afin qu'aucun son de votre pièce ne parvienne aux personnes. J'ai été élevé pendant des années dans une entreprise où tout le monde connaît ces règles, donc pour moi tout cela est évident, mais j'ai vu de nombreuses situations où les gens ne suivaient pas ces règles de base et péchaient sur un mauvais Internet.

Si tout va bien, les pings sont allés et retours, alors la conversation va commencer. Souvent, les enquêteurs proposent eux-mêmes un plan de conversation. Il arrive qu'ils n'aient pas de plan, mais au moins un sujet sera toujours pertinent: "Parlez-nous de vous et de votre expérience . "

Avant l'entretien, relisez le poste vacant, faites attention aux exigences qui s'appliquent au candidat et préparez un discours. J'ai passé des entretiens sur Tech Lead, DevOps / SRE, Ruby / Java Software Engineer et dans chaque cas, j'ai dit différentes choses qui, selon moi, seraient plus intéressantes pour l'intervieweur. Essayez de ne pas entrer dans les détails, mais fournissez les informations qui créeront un vecteur pour une discussion plus approfondie. Vous ne devriez pas parler en détail de ce que vous avez fait il y a 5 ans (à moins bien sûr que ce ne soit pas quelque chose d'extraordinaire).

J'ai dit, par exemple, ceci: «Pendant 8 ans, j'ai travaillé dans un bureau d'entreprise, principalement avec Java. Puis je suis allé dans une startup, là j'étais engagé dans les infrastructures. Ces deux dernières années, j'ai principalement écrit sur Rails. " Ça y est, les enquêteurs ont suffisamment d'informations, et ils dérouleront la conversation dans la veine qui les intéresse.

Et maintenant un fait inattendu.

Personne ne lit votre CV

Honnêtement, cela s'est avéré être une grande découverte pour moi. Eh bien, les recruteurs ne lisent pas le profil sur LinkedIn, car il peut ne pas être mis à jour, les RH ont la possibilité de visualiser les CV en diagonale et de mettre en évidence l'essentiel pour vous-même. Mais les gens qui mènent une entrevue technique ne liront certainement pas votre CV. Pas un, j'insiste, pas une seule fois je n'ai senti que les gens au moins d'un œil regardaient ce que j'écrivais là-bas. Je soupçonne qu'en règle générale, ils ont découvert qu'ils devaient mener un entretien technique un jour avant l'entretien et ont décidé de lire le CV 5 minutes avant l'appel, et il serait déjà là d'une manière ou d'une autre.

: « , ». , ( , ). , , .

, .

, , 10 . CV, , , .

CV , . , , .

Et je vais à nouveau exprimer mon mécontentement face à cette attitude. Moi et vous, si vous êtes déjà une tomate senior, nous sommes des spécialistes d'un niveau relativement sérieux dans mon domaine (je vous rappelle que j'ai cette calomnie et ces tas). Il n'y a pas beaucoup de gens comme nous sur le marché, alors faites preuve de respect et familiarisez-vous avec ce que j'ai fait. J'ai lu votre entreprise, votre projet, votre client. Je m'attends à être traité comme une personne. Pourquoi l'inverse se produit-il?

Personne n'a besoin de toi

Mais cela me dérange le plus. Dans 80% des cas, j'ai eu affaire à des introvertis en colère, somnolents et fatigués qui n'étaient manifestement pas intéressés à embaucher quelqu'un. C'étaient des gens techniquement instruits et de bons spécialistes, mais pour une raison quelconque, ils n'avaient pas envie d'embaucher un collègue, ils ne voulaient pas faire appel à un bon ingénieur pour les aider.

, , . , , , , -. , , , , , , ? : , , , . , « , ».

Je n'ai eu que quelques conversations avec les ingénieurs, ce qui a montré que oui, ils ont vraiment besoin de gens, ils veulent embaucher un bon spécialiste, ils ont un plan pour moi et ainsi de suite. Et nous passons donc au paragraphe suivant.

Vous ne parlerez pas avec votre futur patron ou chef d'équipe

Ceci est une conséquence de la précédente. Je suis profondément convaincu que vous devez parler à ceux à qui vous obéirez alors, officiellement ou officieusement. Toutes les organisations ont une sorte de hiérarchie, que ce soit une équipe Scrum ou une entreprise sanglante. Partout il y a une personne qui s'occupera de vous (au moins au début).

Malheureusement, vous ne pouvez rien y faire. Yegor Bugaenko dans son article «Pourquoi je ne parle pas aux recruteurs de Google» a très bien décrit cette situation. Si vous exigez une conversation avec votre futur patron, vous n'obtiendrez tout simplement aucun entretien.

Il me semble que maintenant c'est l'un des plus gros problèmes d'embauche avec nous. Peut-être que cela est dicté par les spécificités des projets - l'externalisation, où les gens font quelque chose sur le flux. Peut-être la culture de communication généralement pauvre et une mentalité misanthropique, je ne sais pas.
Les blogs de langue anglaise écrivent souvent que l'embauche est l'un des domaines clés vitaux pour bâtir une entreprise prospère. Je pense que nos entreprises auront besoin de beaucoup de temps pour arriver à cela et former la bonne culture. En attendant, les clients doivent l'externaliser.

. , CTO CEO. , . , , . , .
, , (, ).

, , , . , .