Les questions ne sont pas le garçon, mais le juin. 22 questions à l'employeur lors d'un entretien pour le poste de "Middle Python-developer"

image

Présentation


Pendant 2 ans, j'ai eu la chance d'assister à plus de quarante entretiens en tant que candidat au poste de "Middle Python-developer". Au cours des quinze derniers entretiens, j'ai réalisé la nécessité de poser des questions à l'employeur afin de ne pas rencontrer de surprises professionnelles à l'avenir. En plus des questions de base que les candidats posent habituellement à l'employeur, j'ai décidé de formuler mes questions. Lorsque j'ai posé ces questions lors des entretiens, j'ai reçu diverses réactions des personnes interrogées. Quelqu'un a dit que j'étais méticuleux, quelqu'un a considéré ces questions comme trop banales, et quelqu'un a même commencé à devenir nerveux (rougir) et à interrompre immédiatement l'entretien avec une excuse absurde qu'il avait eu une réunion. Dans cet article, je voudrais parler des idées générales de la participation à de tels événements et apporter mes 22 questions que je pose lors de l'entretien à l'employeur.


Idées générales


Une interview avec un développeur intermédiaire ressemble souvent à une interview avec un junior.

Ça l'est vraiment. Cela est dû au fait que de nombreux chefs d'équipe / directeurs techniques ne savent pas exactement ce qu'ils veulent voir chez le développeur intermédiaire. Par conséquent, lors de ces entretiens, on leur demande généralement «d'écrire un décorateur» ou «d'écrire une sorte de bulle dans n'importe quelle langue» .
De plus, peu de gens comprennent en quoi un développeur junior diffère d'un développeur intermédiaire. Quelqu'un dit que middle est un développeur avec une expérience d'un an et demi et quelqu'un de trois ans. À ma connaissance, le développeur intermédiaire est ce développeur qui peut donner en toute sécurité un petit projet ou une partie d'un grand projet, et qu'il en était responsable. Un autre critère important pour un développeur intermédiaire est la capacité d'être le mentor de quelqu'un ou simplement la capacité d'aider un nouvel employé à s'infiltrer dans un projet.

Un entretien n'est pas un examen, mais une opportunité d'identifier comment l'entreprise et le candidat s'associent.

Cette règle importante n'est souvent pas comprise par les employeurs eux-mêmes. Une fois, j'étais à un entretien où j'ai été forcé de retirer un ticket et de répondre à l'interviewé sur un morceau de papier. De plus, tout au long de cette interview, nous avons parlé pendant dix minutes. Le même comportement est souvent tracé par le candidat. Souvent, le candidat veut répondre à tout et se comporte comme un excellent élève dès le premier bureau. Mais ici, il est également important de comprendre que l'employeur ne s'intéresse pas particulièrement à la façon dont vous connaissez la «différence entre Python2 et Python3» . Il est beaucoup plus important pour l'employeur de comprendre en général comment vous vous en tenez à un entretien, comment vous raisonnez, comment vous réagissez aux échecs, etc.

Le développeur intermédiaire ne peut pas être sans expérience.

Bien sûr, c'est possible, mais après un certain temps, cela entraînera d'énormes problèmes à la fois pour le chef de ce développeur et pour le projet. Pour les candidats surdoués et sans expérience, les spécialistes RH ont leur propre terme - «développeur junior fort». Très probablement, ces développeurs se verront offrir une bonne compensation monétaire, mais ils auront des responsabilités en tant que développeurs juniors. Revenant aux développeurs intermédiaires, je voudrais noter que le milieu est celui qui a travaillé dans le développement pendant un certain temps et qui comprend de quels processus il s'agit. Middle sait également travailler avec divers outils (surveillance, déploiement, profilage, test) qu'une personne sans expérience est peu susceptible de rencontrer à des fins de formation.

Les compétences générales deviennent un facteur important dans la position de développeur intermédiaire.

Plus la position est élevée, plus les gens doivent interagir. Par conséquent, très souvent lors de l'embauche d'un poste de développeur intermédiaire, des entretiens supplémentaires sont créés avec un spécialiste des RH pour dresser un portrait psychologique d'un futur employé. Cet entretien doit être pris aussi au sérieux que l'entretien technique. Vous devez comprendre que vous continuez à travailler avec ces personnes. Et si vous estimez que vos futurs collègues ne vous conviennent pas, il vaut mieux refuser immédiatement toute coopération ultérieure.

Les emplois de test sont moins susceptibles d'être attribués au poste de développeur intermédiaire.

Cette déclaration est assez subjective. Personnellement, je suis vraiment tombé sur un tel fait. Je relie cela au fait que l'employeur est plus intéressé par votre CV. Si le CV n'est pas bien compilé, alors vous devriez très probablement attendre la tâche de test.

Des questions


Dans cette section, la liste principale des questions que je pose à l'employeur lors de l'entretien sera présentée. Peut-être qu'après un certain temps, cette liste s'élargira ou se rétrécira. Il convient de noter que ces questions doivent être posées précisément lors des entretiens techniques et il est conseillé de savoir précisément avec qui vous interagirez plus tard.

1. Comment ça se passe avec les tests? Quels tests écrivez-vous? Quelles bibliothèques utilisez-vous pour les tests? ( usines , moki , etc.)

Les tests sont une partie très importante de tout développement. À ma connaissance, tous les développeurs devraient écrire des tests, au moins sous une certaine forme. Les seules qui peuvent pardonner le manque de tests sont les startups. Dans les startups, le cours du mouvement change souvent en raison du fait que les anciens projets ne sont généralement pas nécessaires à personne. Assurer la qualité de ces projets a donc été une perte de temps. Pour toutes les autres sociétés, il ne devrait y avoir aucune pitié à ce sujet. Vous devez comprendre que l'introduction d'un nouvel employé dans le projet entraînera d'abord diverses erreurs dans le code. Et les tests dans ce cas sont sa réassurance personnelle et la réassurance de celui qui va mettre ses décisions en production.

Lorsque l'employeur répond à la deuxième partie de la question, vous serez en mesure de comprendre dans quelle mesure l'équipe assure la qualité de son produit ainsi que les éventuelles responsabilités du développeur qui n'ont pas été discutées dans l'offre.

Il convient de noter que sur cette question, les experts techniques commencent souvent à se perdre. Quelqu'un dit parfois que l'équipe vient de commencer à écrire des tests et n'est pas encore familière avec toutes les subtilités de ce métier. Mais parfois, j'entendais cette réponse: "Les testeurs doivent être impliqués dans les tests, et le développeur doit créer." C'est absolument faux.

Le développeur doit écrire le minimum de tests requis, car c'est lui qui sait comment devrait fonctionner la fonctionnalité qu'il a créée. Personne ne parle de l'inutilité des testeurs. Mais il est important de comprendre que les développeurs doivent également être responsables de la qualité de leur code.

2. Que fait le développeur du code avant de l'envoyer au référentiel?

Cette question fait référence à la vérification locale de votre code par rapport à divers paramètres. Voici une courte liste des codes qui sont généralement vérifiés avant d'être envoyés au référentiel:

  • Flake8 - analyse de code pour la conformité avec PEP8 ,
  • Pylint - analyse de code statique,
  • Couverture - analyse de code pour la couverture des tests,
  • Tox - vérification de la compatibilité du code avec différentes versions de packages individuels et avec différentes versions de Python.

L'absence de ce cas dans le développement n'est pas critique. De plus, dans de nombreuses entreprises, ce cas est utilisé directement dans CI et le développeur ne lance rien localement. Même si cela n'est pas utilisé dans le développement, ce serait bien si les personnes qui vous interviewaient avaient une compréhension de base de ces outils.

3. Y a-t-il des projets CI / CD? Y a-t-il un ingénieur DevOps ?

Cette question n'a pas d'embûches et je lui demande de mieux comprendre le dispositif de l'entreprise. S'il n'y a pas de CI / CD dans les projets et que l'ingénieur DevOps est également absent, il est probable que vous le ferez. Par conséquent, ce point est également préférable de discuter lors d'une entrevue.

4. Existe-t-il une révision du code? Comment ça se passe?

La première partie de la question peut être laissée sans commentaires, car tout le monde comprend l'importance de cet événement. Mais il convient de noter que je me suis personnellement intéressé à savoir exactement comment cela se passe. Il arrive souvent que chaque équipe révise le développeur qui a fait la demande de fusion. Mais parfois, il arrive qu'il y ait un mentor / mentor sur n'importe quel développeur, et c'est lui qui examine le développeur. Je considère que la première approche est plus correcte, car plus les gens révisent le code, mieux c'est pour le projet et pour l'équipe. Ici, des aspects tels que le travail d'équipe, la responsabilité collective et l'augmentation du facteur bus sont immédiatement affectés.

5. Quel système de contrôle de version utilisez-vous?

À l'heure actuelle, en Russie, de nombreuses entreprises utilisent encore le hg , le svn et d'autres systèmes de contrôle de versions anciennes. Cela est particulièrement vrai pour les entreprises qui sont sur le marché depuis plus de 10 ans. Cette question teste plus l'âge de l'entreprise est sensible aux nouvelles technologies. Il est également intéressant de noter que j'ai participé au développement à l'aide de hg pendant une courte période et cela ne m'a pas apporté beaucoup de plaisir.

6. Utilisez-vous git / hg-flow ou une méthodologie spécifique lorsque vous travaillez avec git / hg?

Cette question découle de la question précédente sur les systèmes de contrôle de version. Par conséquent, si l'équipe n'utilise pas git / hg , il est inutile de le demander. Si l'entreprise utilise git / hg , cette question vous montrera à quel point le processus de développement est débogué.

7. Utilisez-vous une méthodologie de développement (scrum, kanban, etc.)?

En développement, il est important d'adhérer à une approche spécifique (méthodologie). L'approche de développement la plus populaire est itérative. Cette approche vous permet de déterminer votre contribution au projet. À ma connaissance, si une équipe utilise une sorte de méthodologie, c'est certainement bon. Cela vous permet de déterminer votre efficacité. Il vous aide également à comprendre les délais alloués aux tâches. C’est la même chose que les écoliers ont 4 trimestres par an, où ils reçoivent des notes pour déterminer la note finale de l’année.

8. Des systèmes de surveillance sont-ils utilisés dans les projets (Sentry, NewRelic, etc.)?

La présence de systèmes de surveillance dans un projet est aussi importante que la présence de tests. Ce sont des systèmes de surveillance qui vous permettent d'évaluer objectivement le travail de l'ensemble du système en fonction des actions que l'utilisateur final effectue. S'il n'y a pas de systèmes de surveillance, alors vous devriez penser à la qualité du produit fabriqué. C'est comme un cuisinier qui cuisine des aliments, mais qui ne demande jamais à personne s'ils sont savoureux.

9. Le projet utilise-t-il un système pour stocker les journaux et travailler avec eux (technologie ELK, etc.)?

Pour moi, c'est aussi un indicateur important. S'il n'y a pas d'ELK, il est très difficile de déterminer la cause d'une erreur complexe dans le système. Cette question n'est pas aussi importante que la question n ° 8, mais il vaut également la peine de demander à comprendre à quel point l'expérience de l'équipe dans le profilage des erreurs complexes est riche.

10. Quelles bases de données sont utilisées dans le projet? Pourquoi exactement ça?

Cette question vise à évaluer la compétence de la personne interrogée. Très souvent, lorsque j'utilise d'anciennes bases de données, j'entends quelque chose comme «cela s'est produit historiquement». Je considère cette réponse inappropriée. Le technicien doit comprendre les inconvénients / avantages de la base de données qu'il utilise. Cette question ne devrait être posée que si vous êtes vous-même familiarisé avec les différentes bases de données et leurs différences.

11. Quelle version de Python est utilisée dans les projets? Si la version de Python2.x est utilisée, existe-t-il un plan pour migrer vers Python3.x? Et comment allez-vous migrer d'une version à une autre?

Cette question, comme la précédente, vise à évaluer la compétence de la personne interrogée, ainsi qu'à apprécier son raisonnement. Il faut comprendre que les employeurs sont très analphabètes et de tels problèmes peuvent déjà être identifiés au stade de l'entretien. Avant de poser ce genre de questions, je vous recommande fortement de les approfondir vous-même.

12. L'entreprise recherche-t-elle un développeur fullstack ou un développeur backend?

Je ne pose cette question que si l'entreprise elle-même ne l'a pas précisé avant l'entretien. Les emplois de développeur fullstack sur le marché du travail peuvent être trouvés assez souvent. De nombreuses entreprises trouvent cela avantageux pour elles-mêmes. Mon expérience personnelle me dit qu'il n'y a pas de développeurs fullstack, car le frontend et le backend sont devenus des directions trop différentes depuis la création du Web. En d'autres termes, "Vous ne pouvez pas vous asseoir sur deux chaises."

Dans la plupart des cas, l'entreprise est convaincue que vous ne connaissez pas l'interface et s'attend à ce que vous l'apprendiez directement au combat. Je tiens à préciser que le poste vacant de développeur fullstack est inacceptable pour moi personnellement. Beaucoup de gens trouvent que c'est une excellente occasion de plonger dans le monde riche du frontend, et sans payer un seul rouble.

13. La technologie de conteneurisation est-elle utilisée dans les projets?

Cette question est un complément à la question n ° 3.

14. Demandez à l'enquêteur un peu ce qu'il faisait avant ce projet et depuis combien de temps il était dans le projet.

Cette question est très importante. Plus l'expérience de votre interlocuteur sera riche, plus cela affectera vos compétences au fil du temps. Il est particulièrement bon de poser une telle question dans une petite entreprise où le roulement du personnel est lent.

15. L'entreprise a-t-elle une évaluation annuelle / trimestrielle des employés et comment cela se passe-t-il?

Il est utile pour tout employé de recevoir des commentaires de ses collègues. Si l'entreprise organise des événements spéciaux pour cela, alors c'est merveilleux. Sinon, il n'y a rien à craindre. Dans tous les cas, personne n'interdit de demander des commentaires à des collègues sous une forme gratuite.

16. L'entreprise a-t-elle un traitement? Si oui, sont-ils compensés et à quelle fréquence se produisent-ils?

Peu de gens aiment recycler, surtout si vous êtes étudiant ou père infirmier. Il existe un grand nombre d'entreprises qui mettent le recyclage au premier plan. Pour comprendre que l'entreprise ne dispose pas de raffineries ou est rare, il faut poser des questions de ce type. Si l'entreprise arrive à l'occasion de raffinage, il n'y a rien de critique. Si le raffinage est plus fréquent, il vaut la peine d'envisager la possibilité de rester dans l'entreprise.

17. Quelle est la force de la bureaucratie dans l'entreprise? (Tarif de 1 à 10)
De nombreux développeurs ne sont même pas conscients de la présence de bureaucratie dans la sphère informatique, mais malheureusement, elle existe. Cela s'applique particulièrement aux grandes entreprises anciennes ou aux entreprises qui travaillent avec l'État. commandes. Le degré de bureaucratie dans une entreprise ne dépend que de l'imagination de la direction. En règle générale, la bureaucratie se compose de diverses applications formelles, vues, accès, conflits d'intérêts entre plusieurs services de l'entreprise et rédaction d'une documentation brute ennuyeuse dans Word. Le principal problème d'une telle bureaucratie est la très forte inhibition du processus de développement. Ce qui se fait dans une entreprise normale en un jour ouvrable, cela prendra des semaines. Autrement dit, plus la bureaucratie est forte dans l'entreprise, plus le développement du produit et votre développement en tant que spécialiste sont lents.

18. Quelle est la situation du dépouillement des ressources?

Les ressources sont comprises comme de nouveaux ordinateurs pour les employés, les serveurs, les domaines, les licences, etc. Ce problème peut également être attribué au précédent problème de bureaucratie.

19. Comment l'intervieweur est-il lié aux nouvelles implémentations du projet?

Cette question nous permet d'évaluer la démocratie au sein de l'équipe. Et aussi cette question permettra de comprendre combien la voix d'un développeur ordinaire a du poids pour une équipe et un mentor.

20. L'entreprise participe-t-elle à des conférences informatiques et l'entreprise a-t-elle des publications sur des sujets informatiques?

La conférence est une excellente occasion pour le développeur et pour l'entreprise de se déclarer et de leurs réalisations. Si l'entreprise est publiée et participe à des conférences, vous pouvez également, à un moment donné, saisir cette opportunité. Si ce n'est pas intéressant pour vous, alors poser des questions n'a aucun sens.

21. Y a-t-il des mitaps au sein de l'entreprise?

Nous parlerons ici des mitaps pour développeurs au sein d'une équipe ou entre équipes. Les mitapas sont très importants. Ils vous permettent de savoir qui et quoi fait exactement à un moment donné. Si vous avez des problèmes de prise de parole en public, cela contribuera également au développement de vos compétences générales .

22. L'entreprise a-t-elle des stagiaires et un système de mentorat?

Les stagiaires sont un avenir potentiel pour l'entreprise. Si l'entreprise a des stagiaires, vous pouvez peut-être être un mentor pour eux et partager votre expérience personnelle. Le mentorat est également l'un des domaines où vous pouvez vous développer.

Conclusion


Tout ce qui précède est ma pensée basée sur l'expérience personnelle et n'est pas une information 100% vraie. La principale morale de l'article est qu'il est nécessaire de vérifier non seulement le candidat, mais aussi l'employeur. Aussi, ne soyez pas nerveux avant les interviews ou lors des interviews. Vous devez comprendre que les enquêteurs sont les mêmes personnes que vous, qui se trompent également ou ne savent pas ou ne comprennent pas quelque chose.

Source: https://habr.com/ru/post/fr428283/


All Articles