Sentiers paresseux
En demandant aux ingénieurs en logiciel de faire une tâche spécifique, comme l'écriture d'un algorithme de génération factorielle (très courant) ou le tri d'une liste simple ou doublement chaînée facile à retenir, vous n'aurez aucune idée des compétences du candidat, à part la capacité de bourrer. Vous pouvez également demander le code ASCII du caractère «A».
Des solutions détaillées à de nombreux problèmes sont faciles à trouver dans une variété de documents de référence, souvent dans des livres, qui décrivent des solutions algorithmiques et spécifiques à tous les problèmes courants dans une entrevue de programmation.
J'ai travaillé pour une entreprise et là j'ai discuté en détail avec un collègue de ce à quoi ressemblait l'entretien avec un grand hedge fund. Il a soigneusement mémorisé toutes les questions techniques du livre largement disponible de questions et réponses d'entrevue, que l'employé de l'époque a transmis comme source de toutes les questions d'entrevue.
Heureusement, mon collègue est un ingénieur expérimenté, mais il a accepté de passer par cet exercice manifestement monotone et banal pour conserver son emploi. Il n'avait pas à faire cela - l'entretien n'était pas seulement une perte de son temps précieux, il n'a rien fait pour que l'entreprise de location détermine sa capacité. Un collègue est parti au bout d'un an, fatigué du faible niveau technique en termes d'embauche et de gestion inefficace ...
Mémoire
Les mêmes arguments fonctionnent lorsque vous écrivez un algorithme dans une langue particulière. Sur un projet réel, aucun ingénieur logiciel n'écrirait une section de code sans une sorte d'outil de vérification de la syntaxe (par exemple, la complétion de code intégrée dans l'éditeur), sans référence à une sorte de documentation technique, ou simplement sans copier la solution finie, où est-elle peut-être. Il ne sert à rien de réinventer la roue.
Je parie que la plupart du code qui fonctionne sur les systèmes mondiaux aujourd'hui est né en réponse à Stack Overflow.
Pour toute sa praticité, travailler avec la syntaxe d'un langage de programmation spécifique commence par la familiarité et l'application. La personne qui vous interviewe peut penser que tester vos connaissances sur les nuances d'une langue particulière teste votre compréhension de la langue. Par exemple, je peux affirmer catégoriquement que même si j'écris en C depuis près de 30 ans, la syntaxe me manque constamment.
En fait, au fur et à mesure que ma carrière progressait et que je me familiarisais mieux avec les langages qui m'intéressaient, j'étais constamment confus au sujet des nuances de syntaxe, disons, C, C ++ et Objective-C. Non pas parce que je suis un mauvais ingénieur logiciel (bien que certains puissent ne pas être d'accord ...), mais parce que seules les connaissances que vous pouvez garder dans votre tête et rappeler à tout moment sont stockées dans votre mémoire.
Un bon ingénieur ne connaît souvent pas immédiatement la réponse à une question précise, mais il sait certainement où la chercher. Vous souhaitez peut-être demander quel est le meilleur endroit pour trouver des informations sur les questions d'entrevue?
Tâches communes
Quelque chose que j'ai déjà abordé: c'est une maxime - ne réinventez pas la roue. Par exemple, si vous travaillez en C et que vous avez besoin d'une routine de port série, ne l'écrivez pas à partir de zéro à moins que la situation ne l'exige. Peut-être avez-vous besoin d'un analyseur JSON, une exigence très courante - à moins que vous n'écriviez du code sur une carte embarquée avec une ressource limitée, pour un satellite en orbite géostationnaire ou à Malbolg ; alors peut-être devriez-vous simplement extraire ce que vous avez déjà écrit de la bibliothèque. Très probablement, le code est utilisé depuis longtemps, il est entièrement testé et possède une documentation détaillée (et correcte). C'est fiable.
Il est peu probable que dans l'ingénierie logicielle moderne, il y ait une tâche commune qui n'a pas encore été automatisée dans la bibliothèque, ou dont l'algorithme est difficile à trouver.
Si vous êtes comme moi, et surtout que vous travaillez par amour du sujet, alors vous chercherez activement des positions où vous mettrez en œuvre ce que vous avez déjà écrit: à la recherche de nouveaux mondes étranges, de nouvelles vies, de nouvelles civilisations ...
En fait, le concept d'ingénieurs en logiciel dans un futur lointain a plus d'une fois été comparé aux archéologues du code, où les ingénieurs réutilisent essentiellement le code existant et passent relativement peu de temps à développer et à programmer de nouveaux et de nouveaux algorithmes.
Discussion. Discussion. Discussion
Je suis d'accord pour savoir que la personne que vous embauchez connaît son entreprise. Mais les méthodes ci-dessus sont totalement inutiles à mon avis. Je ne veux offenser personne, je le dis tel quel.
Par exemple, parler simplement des paradigmes de programmation dans l'ingénierie logicielle moderne, si un langage serait un bon choix pour une implémentation spécifique, ou si une méthodologie d'ingénierie logicielle spécifique (Agile, je vous regarde) est un sujet de discussion beaucoup plus utile et pertinent.
Menez une discussion pour mettre en évidence les points communs, voir comment le candidat comprend les nouveaux problèmes et éventuellement de nouvelles façons de résoudre les anciens. Comment les candidats voient le développement des choses, comment ils commenceraient à résoudre quelque chose. Restez ouvert, éloignez-vous des détails et des trivialités.
La clé ici est la discussion. Je suis constamment étonné que beaucoup d'entreprises considérées comme «tournées vers l'avenir» et «leaders dans leur domaine» recourent encore à des méthodes d'embauche dépassées, monotones et totalement prévisibles, car elles n'apprécient guère la vraie veine technique.
On dit souvent qu'un demandeur d'emploi devrait interviewer une entreprise de la même manière qu'une entreprise l'interviewe. Je suis totalement d'accord.
Interviewer quelqu'un avec une liste de questions techniques précises est toujours un signal d'alarme, en particulier lorsque les gens ne veulent pas traîner une discussion sur un seul problème. Cela montre souvent que la personne interrogée peut ne pas comprendre pleinement ce qu'il demande, et toute réponse qui ne correspond pas exactement à ce qui est écrit dans le script sera considérée comme incorrecte.
Résumons
Certaines entreprises sont passées à de meilleures méthodes de recrutement, d'autres - eh bien, elles échouent. C'est là que je vous exhorte, chers programmeurs, à ne pas vous impliquer dans des entreprises qui embauchent à l'ancienne et insistent sur des tests et des exercices de codage. Surtout pour les longs!
J'ai entendu des histoires d'entreprises demandant que les projets soient terminés à la date limite d'un candidat, ce qui prend souvent des jours.
D'autres ont des "tests d'aptitude" génériques pour des langues spécifiques, des tests à choix multiples, où dans un temps limité, un soupçon de brouillard dans la tête signifie que vous avez échoué à l'entretien!
Si vous êtes débutant, vous ne serez peut-être pas en mesure de sauter une entrevue, et je vous comprends parfaitement, mais je la considère comme une expérience d'apprentissage. Allez-y, construisez de l'expérience, apprenez autant que possible, et si le travail vous déçoit, passez à autre chose. À l'avenir, vous gagnerez en confiance, en connaissances et en expérience. Après tout, l'entreprise profite de vous, vous devriez donc profiter également de l'entreprise.
Si, comme moi, vous êtes plus âgé et plus expérimenté, laissez simplement l'entreprise de location vous parler. Nous avons beaucoup d'expérience, nous avons vu et fait beaucoup, les qualifications sont clairement visibles dans le CV et le CV. Et je suis indigné que je sois guidé dans le pipeline de recrutement général et que mes capacités soient testées à plusieurs reprises.
Si vous pensez que vous êtes un employeur digne et que vous ne parvenez pas à comprendre pourquoi des candidats apparemment excellents partent et partent, regardez de près comment vous embauchez des gens.
<>
Autres professions et cours
</>