Pourquoi les entretiens d'ingénierie SW sont-ils disproportionnellement difficiles (vs les entretiens de recherche)?
Tout d'abord, quelques informations sur moi. J'ai un doctorat en CS et j'ai eu des emplois à la fois en tant qu'ingénieur logiciel et en tant que chercheur en recherche et développement, tous deux chez Very Large Corporations You Know Very Well. J'ai récemment changé d'emploi et interviewé pour les deux types de postes (comme je l'ai fait dans le passé).
Mon observation: les entretiens d'embauche d'ingénieur SW sont beaucoup, beaucoup plus difficiles que les entretiens d'embauche de chercheur CS, mais le poste de chercheur est mieux rémunéré, plus compétitif, plus gratifiant, plus intéressant et a un avantage plus élevé.
Voici une boucle d'interview typique pour un chercheur:
- Entrevue téléphonique pour voir si ma recherche est conforme à la recherche du laboratoire
- En personne: faites une présentation de mes recherches récentes pendant une heure (ce qui représente peut-être 9 mois de travail) et répondez aux questions du public
- Entretiens en personne avec environ 5 chercheurs, où ils me posent des questions très raisonnables sur mon travail/publications/brevets, y compris: des questions techniques, où mon travail s'inscrit dans un travail connexe et comment je peux étendre mon travail à nouveaux domaines
Voici une boucle d'interview typique pour un ingénieur SW:
- Entretien téléphonique où l'on me pose des questions d'algorithme et peut-être un peu de codage. Assez standard.
- Entrevues en personne sur le tableau blanc où ils vous forcent le F *** sur la minutie ésotérique C++ (par exemple, comment fonctionne un appel de fonction virtuelle polymorphe), des algorithmes (faire fonctionner l'algorithme du chemin le plus court pour toutes les paires pour les sommets 1B) , conception du système (conception d'un équilibreur de charge de base de données), etc. Cela se poursuit pendant six ou sept entretiens. Ridicule.
Pourquoi quelqu'un serait-il disposé à accepter cela? Quel est l'intérêt de poser des questions sur les anecdotes C++ ou d'écrire du code pour faire vos preuves? Pourquoi ne pas rendre l'entretien SE plus semblable à l'entretien avec un chercheur où vous discutez de ce que vous avez fait?
Comment sont les entretiens techniques pour d'autres domaines, comme la physique, la chimie, le génie civil, le génie mécanique?
Il est relativement facile d'établir si vous êtes suffisamment compétent techniquement pour faire la recherche - vous avez des publications que les responsables du recrutement peuvent lire et ces publications font probablement allusion à d'autres personnes avec lesquelles ils peuvent parler pour vous consulter.
Le génie logiciel, d'autre part, est une discipline tellement remplie de déchets d'espace incompétents qu'il faut faire beaucoup de diligence raisonnable pour s'assurer que le gars que vous embauchez peut en fait écrire le code que vous envisagez de l'embaucher pour écrire.
Sortir sur un membre ici.
En tant que chercheur titulaire d'un doctorat, vous avez déjà prouvé à plusieurs organisations reconnues votre valeur et vos qualités minimales en tant que chercheur. Vous avez défendu avec succès une thèse devant un jury de vos pairs et avez convaincu au moins une publication évaluée par des pairs pour publier votre travail.
Le développement logiciel, d'autre part, n'a pas de normes de qualification. Les gens gonflent régulièrement leur base de connaissances. En conséquence, les entretiens de développement de logiciels doivent faire tout le travail que la défense de doctorat et l'examen par les pairs font dans le milieu universitaire. Ils vous font prouver que vous savez vraiment de quoi vous parlez.
Réfléchis y un instant.
Si j'essayais de postuler pour ce poste de chercheur CS, je ne verrais pas mon CV/CV examiné. Je n'irais pas à une interview en premier lieu. J'obtiendrais une lettre standardisée "sans diplôme" me disant que je n'étais même pas qualifié pour faire examiner mon CV.
Mes questions sont les suivantes: "Pourquoi est-il si difficile d'obtenir un doctorat?" Et "Pourquoi ai-je besoin d'un doctorat pour être chercheur CS?" "Pourquoi tant de barrières et d'obstacles?"
Pourquoi quelqu'un serait-il disposé à accepter cela?
Quel est l'intérêt de faire tout ce travail de cours et d'imprimer la recherche dans des revues et des conférences? Pourquoi ne puis-je pas simplement faire la recherche et être payé plus que moi pour l'ingénierie?
Pourquoi se fier aux écoles supérieures et aux publications pour établir les titres de compétences? Pourquoi ne pas rendre l'entretien de recherche plus semblable aux entretiens SE où tout dépend de ce dont vous vous souvenez tout de suite pendant l'entretien?
Eh bien, j'ai une théorie. La recherche est généralement financée par des subventions, de sorte que l'offre de liquidités est élevée. Ils ont un seau d'argent à dépenser et ils ont juste besoin de trouver quelqu'un pour le dépenser. Que vous accomplissiez ou non quelque chose dans ce poste, l'entreprise/l'institution n'enregistre pas de perte nette, car il s'agissait de toute façon d'une dépense comptabilisée. Il y a peu de risques à embaucher la mauvaise personne. Le pire des cas est qu'ils jettent tout ce que vous avez fait.
D'un autre côté, le succès ou l'échec des produits existants repose sur les épaules des développeurs au quotidien. Surtout si vous êtes dans le développement de produits, vous êtes un centre de profit pour l'entreprise. Les bons ou les mauvais développeurs ont un impact énorme qui dépasse largement le coût de leur salaire. Un mauvais développeur cause des dommages. Ils peuvent faire reculer une équipe, lancer un produit, etc. Les conséquences de l'embauche d'un mauvais ingénieur SW sont beaucoup plus importantes.
Réponse courte: il y a beaucoup de gens sur le marché qui prétendent connaître la programmation mais ne peuvent pas programmer.
Remarque secondaire: je suis surpris que personne n'ait publié de lien vers essai FizzBuzz .
Notre entreprise "pose aussi beaucoup de questions difficiles" et je vais vous expliquer pourquoi. Nous nous soucions de savoir si vous savez vraiment comment un appel de fonction virtuel est effectué, mais pas parce qu'il est si critique pour le travail que vous allez faire.
Au lieu de cela, nous nous soucions parce que nous devons savoir à quelle vitesse vous pouvez apprendre des choses fondamentales. Vous revendiquez X ans d'expérience? D'accord, nous poserons des questions difficiles pour savoir si vous avez des connaissances solides.
Vous ne savez pas comment un appel de fonction virtuel est effectué sous le capot, mais vous savez tout sur le profilage et l'optimisation? Très bien, nous vous embauchons probablement - vous avez acquis de solides connaissances dans un domaine et vous gagnerez sûrement des connaissances solides dans un autre.
Vous revendiquez X ans d'expérience dans "le développement, le débogage et la correction de code C++" et vous ne pouvez pas expliquer en termes simples comment un pointeur pointe vers un objet? Désolé, nous ne pouvons pas vous embaucher - si vous ne pouvez pas le faire, comment expliquerez-vous les problèmes plus difficiles lorsque nous devons prendre des décisions techniques complexes?
Je suis développeur de logiciels (c/c ++) avec plus de 20 ans d'expérience dans le domaine. Le type d'entrevues que nous voyons régulièrement maintenant (les énigmes, la mise en œuvre de structures de données, les algorithmes de recherche, etc. sur le tableau blanc) ne se produisait pas beaucoup à l'exception des nouveaux étudiants. Si une personne travaillait pour une entreprise réputée pendant une durée raisonnable, cela était considéré comme une preuve de sa capacité à écrire du code. Maintenant, c'est devenu très scolaire et je ne sais pas pourquoi. Vraiment, les choses typiques qu'ils vous demandent de coder, PEUVENT être mémorisées, donc le faire sur le tableau blanc ne prouve vraiment rien. Sur un projet de travail, vous utiliseriez Internet pour rechercher quelque chose et vous n'écririez pas des btrees ou des listes liées à partir de zéro. Ce dont les entreprises ont vraiment besoin maintenant, ce sont des innovateurs et demander à quelqu'un de prouver qu'ils peuvent écrire à partir des structures de mémoire de l'université ne démontre pas l'innovation.
Je pense que c'est une autre manie de gestion - tout comme Scrum - avec celle-ci probablement lancée par Google, Amazon et Microsoft. Tout le monde a copié comme ils l'ont fait avec le rang et le coup sec de Jack Welch ... rappelez-vous GE?
Si vous êtes un responsable du recrutement lisant mes commentaires, ce que vous DEVRIEZ demander aux candidats, c'est COMMENT ils pourraient résoudre certains problèmes. Au lieu de leur demander de coder une table de hachage, donnez-leur un problème impliquant une table de hachage et demandez-leur comment ils pourraient le résoudre.
Je suis également d'accord avec le développeur au-dessus de ce post qui a dit "leur donner un vrai problème que la société a dû résoudre"!
"mais j'aurais tendance à bombarder les questions de POO/Héritage. Pourquoi? Parce qu'une fois la prise en charge des modèles ajoutée, j'ai utilisé C++ presque exclusivement pour la programmation générique."
Je suis également d'accord avec ce qui précède. Lorsque vous travaillez pour une entreprise, vous écrivez le code LEUR façon. J'ai parfois du mal à me souvenir de la syntaxe d'appel par référence C++ du haut de ma tête parce que l'architecte senior de l'entreprise pour laquelle j'ai travaillé 15 ans, a préféré utiliser des pointeurs, pas des références. C'était un vieux programmeur C, vous voyez. C'est donc ce que nous avons tous utilisé.
Je vais prendre un chemin différent et dire que le problème n'est peut-être pas tant que les entretiens en génie logiciel sont intrinsèquement plus difficiles, mais plutôt que différents secteurs recherchent des choses différentes, ce qui apparaît dans leur style d'interview.
J'ai interviewé dans un éventail assez large de secteurs (par exemple, start-up, petite entreprise, grande entreprise, service informatique interne, société de logiciels, organisme de recherche) et ils ont tous une manière différente d'interviewer que j'ai trouvé généralement tendance à suivez le modèle suivant:
- Les start-ups ont tendance à se soucier de savoir que vous pouvez commencer à écrire du code en ce moment et pouvez gérer un environnement au rythme rapide. En tant que tels, ils ont tendance à se préoccuper de tout ce que vous savez du haut de votre tête, car ils ne veulent apparemment pas que vous passiez beaucoup de temps à rechercher tout ce qu'ils considèrent comme des connaissances "essentielles". Admettre que vous ne savez pas quelque chose peut ne pas être une bonne chose dans cet environnement si c'est quelque chose qu'ils attendent de vous.
- Les petites entreprises ont tendance à rechercher les mêmes choses que les start-ups en ce qui concerne vos connaissances, mais ne sont pas aussi préoccupées par la façon dont vous gérez les environnements à rythme rapide (selon le travail) et plus par le type de compétences générales que vous apporter et à quel point vous vous adapterez à l'entreprise.
- Les grandes entreprises et les services informatiques internes semblent plus soucieux de s'assurer que vous avez un niveau donné de connaissances techniques, mais ne sont pas aussi inquiets si vous ne savez pas tout par le haut de votre tête, car ils anticipent qu'il y en aura temps consacré à vous former sur les attentes de l'entreprise. Ainsi, c'est un environnement où admettre que vous ne savez pas quelque chose mais que vous êtes prêt à apprendre et à étudier peut être considéré comme un avantage.
- Dans l'environnement de recherche (c'est-à-dire le soutien au développement de logiciels pour les scientifiques selon mon expérience), ils ont tendance à se demander si vous pouvez écrire des logiciels, mais plus encore si vous êtes prêt à faire ce qui est nécessaire pour vous assurer que vous pouvez apprendre ce qu'ils font. ils n'ont pas à vous tenir la main pendant que vous essayez de résoudre un problème. Puisqu'il s'agit également d'un environnement de recherche, ils semblent également intéressés par votre intérêt à apprendre de nouvelles choses.
Maintenant, j'ai négligé de mentionner les éditeurs de logiciels (c'est-à-dire Google, Microsoft) car ils ont tendance à faire leurs propres choses et selon la maturité de l'entreprise et le groupe pour lequel vous interrogez, ils recherchent des choses différentes.
À la fin de la journée, et comme pour la plupart des choses de la vie, tout dépend. Personnellement, j'ai constaté que certaines entreprises se concentrent beaucoup sur la "connaissance du livre", ce qui pourrait se faire au détriment de la capacité à résoudre les problèmes de niveau supérieur alors que d'autres entreprises semblent très préoccupées par la façon dont vous gérez les problèmes de niveau supérieur. (c.-à-d. pouvez-vous concevoir un schéma pour x) et opérer sous l'hypothèse qu'ils sont prêts à investir de trois à six mois pour vous mettre pleinement à jour avant d'être pleinement productif.
Encore une fois, les entrevues technologiques sont arbitraires et capricieuses.
Il y a une grande différence entre faire griller une personne sur les minuties et voir si elle connaît son CS. Comme je l'ai dit ci-dessus, j'ai plus d'une décennie d'expérience avec C++, mais j'aurais tendance à bombarder les questions OOP/Héritage. Pourquoi? Parce qu'une fois la prise en charge des modèles ajoutée, j'ai utilisé C++ presque exclusivement pour Generic Programmation.
J'ai interviewé plusieurs sociétés BigHouseHoldNameTech dans la région de la baie et à Seattle, et l'une des meilleures interviews impliquait de vraies questions auxquelles elles ont dû faire face sur le tas, impliquant des structures de données et des algorithmes [ie: Vous avez 300 milliards de points de données constitués de XYZ. Comment stocker et rechercher efficacement?].
Cela vous permet de savoir comment un candidat pourrait intervenir et aider à résoudre les vrais problèmes auxquels vous êtes confronté. Le pire était également avec une autre société BigHouseHoldNameTech, mais ils ont posé des heures de questions incroyablement obscures que vous devriez vraiment rechercher dans un manuel [ c'est-à-dire. décrire les principales différences entre le PCB dans Windows vs Linux - et ce n'était pas pour une position au niveau du noyau]
Les fonds spéculatifs sont bizarres avec leur intention de torturer ... attendez-vous à 8 heures de résolution sac à dos problèmes de type sur un tableau blanc.