Pourquoi les entretiens d'ingénierie SW sont-ils disproportionnellement difficiles (par rapport aux entretiens de recherche)? [fermé]

Tout d'abord, quelques informations sur moi. J'ai un doctorat en informatique et j'ai eu des emplois à la fois d'ingénieur en logiciel et de chercheur scientifique 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 par le passé).

Mon observation: les entretiens d'embauche d'ingénieurs SW sont beaucoup plus difficiles, de manière disproportionnée, que les entretiens d'embauche de chercheurs CS, mais leur emploi est plus rémunérateur, plus compétitif, plus gratifiant, plus intéressant et plus prometteur.

Voici une boucle d'entrevue typique pour le chercheur:

• Entretien téléphonique pour vérifier si mes recherches sont conformes à celles du laboratoire
• En personne: donnez une présentation d'une heure sur mes recherches récentes (ce qui représente environ 9 mois de travail) et répondez aux questions du public.
• Entretiens individuels sur place avec environ 5 chercheurs, où ils me posent des questions très raisonnables sur mes travaux / publications / brevets, y compris: des questions techniques, où mon travail s'inscrit dans un travail connexe et comment étendre mon travail à nouveaux domaines

Voici une boucle d'entrevue typique pour un ingénieur SW:

• Entretien téléphonique au cours duquel on me pose des questions sur l'algorithme et peut-être un peu de codage. Assez standard.
• Entretiens individuels sur le tableau blanc, où ils vous interrogent sur des minuties ésotériques C ++ (par exemple, comment fonctionne un appel de fonction virtuelle polymorphe), des algorithmes (utilisent l'algorithme toutes-paires-plus court chemin pour les sommets 1B) , conception du système (conception d’un équilibreur de charge de base de données), etc. Cela dure six ou sept entretiens. Ridicule.

Pourquoi est-ce que quelqu'un serait prêt à supporter cela? Quel est l'intérêt de poser des questions sur C ++ ou d'écrire du code pour prouver sa véracité? Pourquoi ne pas rendre l’interview SE plus semblable à l’interview du chercheur où vous donnez une présentation de ce que vous avez fait?

Comment se déroulent les entretiens techniques dans d’autres domaines, tels que la physique, la chimie, le génie civil, le génie mécanique?

Il est relativement facile de déterminer si vous êtes suffisamment compétent sur le plan technique pour effectuer la recherche - vous avez des publications que les responsables du recrutement peuvent lire et ces publications font probablement allusion à d'autres personnes avec lesquelles elles peuvent parler pour vous consulter.

L’ingénierie logicielle, quant à elle, est une discipline qui regorge de ressources incompétentes. Vous devez faire preuve d’une diligence raisonnable et vous assurer que le type que vous embauchez peut écrire le code que vous prévoyez de l’engager.

Sortir sur une branche ici.

En tant que chercheur titulaire d'un doctorat, vous avez déjà prouvé à de multiples organisations reconnues votre valeur et vos qualités minimales en tant que chercheur. Vous avez soutenu avec succès une thèse devant un conseil d'administration composé de vos pairs et avez convaincu au moins une publication évaluée par des pairs de publier votre travail.

Le développement logiciel, par contre, 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 logiciel doivent faire tout le travail que la soutenance de thèse et l'examen par les pairs font en 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 à ce poste de chercheur CS, je ne verrais pas mon CV / CV. Je ne voudrais pas obtenir une interview en premier lieu. Je recevrais une lettre standardisée "sans diplôme supérieur" 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 en CS?" "Pourquoi tant d'obstacles et d'obstacles?"

Pourquoi est-ce que quelqu'un serait prêt à supporter cela?

Quel est l'intérêt de faire tout ce travail de cours et d'obtenir des résultats de recherche imprimés dans des revues et des conférences? Pourquoi ne puis-je pas simplement faire de la recherche et être mieux payé que pour l'ingénierie?

Pourquoi se fier aux écoles supérieures et aux publications pour établir les diplômes? Pourquoi ne pas rendre l’entretien de recherche plus semblable aux entretiens SE, où tout dépend de ce que vous pouvez vous rappeler maintenant 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 d'argent est élevée. Ils ont beaucoup d'argent à dépenser et ils ont juste besoin de trouver quelqu'un pour le dépenser. Que vous accomplissiez quoi que ce soit dans cette situation ou non, la société / institution n’enregistre pas de perte nette car c’était de toute façon une dépense comptabilisée. Il y a peu de risque à engager la mauvaise personne. Le pire des scénarios est qu'ils jettent tout ce que vous avez fait.

D'autre part, le succès ou l'échec des produits existants repose sur les épaules des développeurs au quotidien. En particulier si vous êtes en développement de produit, 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 effectivement des dégâts. Ils peuvent retarder une équipe, lancer un produit, etc. Les conséquences de l'embauche d'un mauvais ingénieur SW sont bien plus lourdes.

Notre société "pose également 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 que cela est si essentiel pour le travail que vous ferez.

Au lieu de cela, nous nous en soucions, car nous avons besoin de savoir à quelle vitesse vous pouvez apprendre des choses fondamentales. Vous prétendez X ans d'expérience? D'accord, nous poserons des questions difficiles pour savoir si vous avez de bonnes connaissances.

Vous ne savez pas comment un appel de fonction virtuelle est fait sous le capot, mais vous savez tout sur le profilage et l'optimisation? Génial, nous vous embauchons probablement - vous avez acquis de solides connaissances dans un domaine et vous allez sûrement acquérir de solides connaissances dans un autre.

Vous prétendez avoir X années d'expérience en "développement, débogage et correction de code C ++" et vous ne pouvez pas expliquer en termes simples comment un pointeur pointe sur 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?

Réponse courte: il y a beaucoup de gens sur le marché qui prétendent connaître la programmation, mais ne le peuvent pas.

Remarque secondaire: je suis surpris que personne n'ait posté de lien vers l' essai de FizzBuzz .

Je vais emprunter une autre voie et dire que le problème ne réside peut-être pas tant dans le fait que les entretiens en génie logiciel sont plus difficiles, mais plutôt dans le fait que différents secteurs recherchent des éléments différents, ce qui se reflète dans leur style d’interview.

J'ai interviewé des secteurs très variés (par exemple, une jeune entreprise, une petite entreprise, une grande entreprise, un service informatique interne, une entreprise de logiciels, un organisme de recherche) et ils ont tous une manière différente d'interviewer, ce que j'ai généralement constaté. suivez le modèle suivant:

• Les start-ups ont tendance à savoir que vous pouvez commencer à écrire du code dès maintenant et que vous pouvez gérer un environnement au rythme rapide. En tant que tels, ils ont tendance à se préoccuper de votre connaissance du fait qu'ils ne veulent apparemment pas vous voir passer beaucoup de temps à chercher ce qu'ils considèrent être des connaissances "fondamentales". Admettre que vous ne savez pas quelque chose peut ne pas être une si bonne chose dans cet environnement si c'est quelque chose qu'ils s'attendent que vous sachiez.
• Les petites entreprises ont tendance à rechercher les mêmes choses que les nouvelles entreprises en ce qui concerne vos connaissances, mais ne sont pas aussi préoccupées par votre capacité à gérer des environnements à rythme rapide (dépend de l'emploi) et davantage par le type de compétences non techniques que vous avez. apporter et à quel point vous vous adapterez à la société.
• Les grandes entreprises et les services informatiques internes semblent plus soucieux de garantir que vous possédez un niveau de connaissance technique donné, mais ne le sont pas autant si vous ne savez pas tout par cœur, car ils prévoient qu'il y aura des le temps nécessaire pour vous former aux attentes de l’entreprise. Il s'agit donc d'un environnement dans lequel admettre que vous ne savez pas quelque chose mais que vous êtes disposé à apprendre et à étudier peut être perçu comme un avantage.
• D'après mon expérience, les scientifiques se préoccupent de l'environnement de recherche (par exemple, le soutien au développement de logiciels), mais plus encore si vous êtes prêt à faire le nécessaire pour que vous puissiez apprendre ce qu'ils font. ils ne doivent 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 pour l'apprentissage de nouvelles choses.

Maintenant, j'ai négligé de mentionner les éditeurs de logiciels (Google, Microsoft) car ils ont tendance à faire leurs propres choses et, en fonction de leur maturité et du groupe pour lequel vous interviewez, ils recherchent des produits différents.

À la fin de la journée, tout dépend de la situation. Personnellement, j’ai constaté que certaines entreprises se concentrent beaucoup sur la "connaissance du livre" qui pourrait leur permettre de 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érez-vous en supposant qu'ils soient disposés à investir de trois à six mois pour être parfaitement au courant avant de devenir pleinement productif?

Je suis un développeur de logiciels (c / c ++) avec plus de 20 ans dans le domaine. Le type d’entrevues que nous voyons couramment à l’heure actuelle (casse-tête, implémentation de structures de données, algorithmes de recherche, etc. sur le tableau blanc) n’était pas très courant, sauf pour les nouveaux diplômés. Si une personne travaillait pour une entreprise digne de confiance pendant un laps de temps raisonnable, cela constituait 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 de btrees ou de listes chaînées à partir de rien.

Je pense que c'est une autre manie de la gestion - tout comme Scrum - avec celle-ci probablement lancée par Google, Amazon et Microsoft. Tout le monde copié comme ils le faisaient avec le rang de Jack Welch et tirer… tu te souviens de GE?

Si vous êtes un responsable du recrutement en train de lire mes commentaires, vous DEVEZ demander aux candidats comment ils procéderaient pour 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 le résoudraient.

Je suis également d'accord avec le développeur au-dessus de ce post qui a déclaré "leur donner un problème du monde réel que l'entreprise devait résoudre"!

"Mais j'aurais tendance à bombarder les questions concernant la POO / l'héritage. Pourquoi? Parce qu'une fois la prise en charge des modèles ajoutée, j'ai utilisé le 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. Je n'arrive pas toujours à me souvenir de la syntaxe appel par référence C ++, car l'architecte principal de la société pour laquelle j'ai travaillé pendant 15 ans a préféré utiliser des pointeurs, et non des références. C'était un vieux programmeur C, voyez-vous. C'est donc ce que nous avons tous utilisé.

Encore une fois, l'entretien technique est arbitraire et capricieux.

Il y a une grande différence entre griller une personne dans les moindres détails et voir s'ils connaissent leur SC. Comme je l'ai dit plus haut, j'ai plus d'une décennie d'expérience avec C ++, mais j'aurais tendance à bombarder les questions de la POO / de l'héritage. Pourquoi? Une fois la prise en charge des modèles ajoutée, j'ai utilisé le C ++ presque exclusivement pour la programmation générique .

J'ai interviewé plusieurs sociétés BigHouseHoldNameTech dans la région de Bay et à Seattle, et l'une des meilleures entrevues comportait de vraies questions auxquelles elles devaient faire face sur le tas, impliquant des structures de données et des algorithmes [c'est-à-dire: vous avez 300 milliards de points de données composé de XYZ. Comment stockez-vous et recherchez-vous efficacement? ].

Cela vous permet de savoir comment un candidat peut intervenir et aider à résoudre les vrais problèmes auxquels vous êtes confrontés. Le pire était avec une autre société BigHouseHoldNameTech, mais ils ont posé des heures de questions incroyablement obscures que vous devriez vraiment consulter dans un manuel [ c.-à-d. Décrire les principales différences entre le PCB de Windows et celui de Linux - et ce n’était pas le cas ». t pour une position au niveau du noyau ]

Les fonds de couverture sont bizarres avec leur intention de torturer ... attendez 8 heures à résoudre des problèmes de type sac à dos sur un tableau blanc.