Warum sind SW-Engineering-Interviews unverhältnismäßig schwierig (im Vergleich zu Forschungsinterviews)? [geschlossen]

Zunächst einige Hintergrundinformationen zu mir. Ich habe einen Doktortitel in CS und war sowohl als Software-Ingenieur als auch als Forschungs- und Entwicklungswissenschaftler bei sehr großen Unternehmen tätig, die Sie sehr gut kennen. Ich habe kürzlich meinen Job gewechselt und für beide Arten von Positionen ein Vorstellungsgespräch geführt (wie ich es in der Vergangenheit getan habe).

Meine Beobachtung: Bewerbungsgespräche für SW-Ingenieure sind viel, viel schwieriger als Bewerbungsgespräche für CS-Forscher, aber der Beruf als Forscher ist höher bezahlbar, wettbewerbsfähiger, lohnender, interessanter und hat einen höheren Gewinn.

Hier ist eine typische Interviewschleife für Forscher:

• Telefoninterview, um zu sehen, ob meine Forschung mit der Forschung des Labors in Einklang steht
• Persönlich: Präsentieren Sie eine Stunde lang meine neuesten Forschungsergebnisse (was einem Arbeitsaufwand von 9 Monaten entspricht) und beantworten Sie Fragen des Publikums
• Persönliche Einzelinterviews mit ungefähr 5 Forschern, in denen sie mir sehr vernünftige Fragen zu meinen Arbeiten / Veröffentlichungen / Patenten stellen, darunter: technische Fragen, wo meine Arbeit zu verwandten Arbeiten passt und wie ich meine Arbeit erweitern kann neue Bereiche

Hier ist eine typische Interviewschleife für SW-Ingenieure:

• Telefoninterview, in dem ich Algorithmusfragen stelle und vielleicht etwas programmiere. Ziemlich normal.
• Persönliche Interviews am Whiteboard, in denen das F *** über esoterische C ++ - Minutien (z. B. wie ein polymorpher virtueller Funktionsaufruf funktioniert) und Algorithmen (damit der All-Pair-Shortest-Path-Algorithmus für 1B-Vertices funktioniert) durchgeführt werden , Systemdesign (Entwerfen eines Datenbanklastenausgleichs) usw. Dies dauert sechs oder sieben Interviews. Lächerlich.

Warum sollte sich jemand damit abfinden? Was bringt es, nach C ++ zu fragen oder Code zu schreiben, um sich zu beweisen? Warum sollte das SE-Interview nicht eher dem Forscher-Interview ähneln, in dem Sie einen Vortrag darüber halten, was Sie getan haben?

Wie sind technische Vorstellungsgespräche für andere Bereiche wie Physik, Chemie, Bauingenieurwesen, Maschinenbau?

Es ist relativ einfach festzustellen, ob Sie technisch kompetent genug sind, um die Recherchen durchzuführen - Sie haben Veröffentlichungen, die die Personalchefs lesen können, und diese Veröffentlichungen deuten wahrscheinlich auf andere Personen hin, mit denen sie sprechen können, um Sie zu überprüfen.

Andererseits ist Software-Engineering eine Disziplin, die mit inkompetenter Verschwendung von Speicherplatz gefüllt ist. Man muss viel Sorgfalt walten lassen, um sicherzustellen, dass der Mitarbeiter, den Sie einstellen, tatsächlich den Code schreiben kann, für den Sie ihn einstellen möchten.

Hier auf die Beine gehen.

Als promovierter Forscher haben Sie bereits mehreren anerkannten Organisationen Ihren Wert und Ihre Mindestqualitäten als Forscher unter Beweis gestellt. Sie haben eine Dissertation erfolgreich vor einem Gremium Ihrer Kollegen verteidigt und mindestens eine von Experten geprüfte Publikation davon überzeugt, Ihre Arbeit zu veröffentlichen.

Die Softwareentwicklung hingegen hat keine Qualifikationsstandards. Die Leute blähen routinemäßig ihre Wissensbasis auf. Infolgedessen müssen Softwareentwicklungsinterviews die gesamte Arbeit leisten, die die Verteidigung von Doktoranden und die Begutachtung durch Fachkollegen in der Wissenschaft leisten. Sie lassen Sie beweisen, dass Sie wirklich wissen, wovon Sie sprechen.

Betrachten Sie dies für einen Moment.

Wenn ich mich für diese Stelle als CS-Forscher bewerben wollte, würde ich meinen Lebenslauf nicht einsehen. Ich würde gar nicht erst zu einem Interview kommen. Ich erhielt einen standardisierten Brief mit der Aufschrift "kein Hochschulabschluss", in dem mir mitgeteilt wurde, dass ich nicht einmal für die Prüfung meines Lebenslaufs qualifiziert war.

Meine Fragen sind: "Warum ist es so schwer, einen Doktortitel zu bekommen?" Und "Warum brauche ich einen Doktortitel, um CS-Forscher zu werden?" "Warum so viele Hindernisse und Hürden?"

Warum sollte sich jemand damit abfinden?

Was bringt es, all diese Kursarbeiten zu erledigen und Forschungsergebnisse in Zeitschriften und Konferenzen zu drucken? Warum kann ich nicht einfach recherchieren und dafür mehr bezahlen als für das Engineering?

Warum sollten Sie sich auf Graduiertenschulen und Veröffentlichungen verlassen, um Zeugnisse zu erlangen? Machen Sie das Forschungsinterview doch eher zu einem SE-Interview, bei dem alles davon abhängt, woran Sie sich im Moment erinnern können.

Nun, ich habe eine Theorie. Forschung wird in der Regel durch Zuschüsse bezahlt, daher ist das Bargeldangebot hoch. Sie müssen einen Eimer Geld ausgeben, und sie müssen nur jemanden finden, für den sie es ausgeben können. Unabhängig davon, ob Sie in dieser Position tatsächlich etwas erreichen oder nicht, weist das Unternehmen / die Institution keinen Nettoverlust aus, da es sich ohnehin nur um eine abgerechnete Ausgabe handelte. Es besteht nur ein geringes Risiko, die falsche Person einzustellen. Das schlimmste Szenario ist, dass sie alles wegwerfen, was Sie getan haben.

Auf der anderen Seite liegt der Erfolg oder Misserfolg bestehender Produkte auf den Schultern alltäglicher Entwickler. Gerade wenn Sie in der Produktentwicklung tätig sind, sind Sie ein Profitcenter für das Unternehmen. Gute oder schlechte Entwickler haben einen enormen Einfluss, der weit über die Lohnkosten hinausgeht. Ein schlechter Entwickler verursacht tatsächlich Schaden. Sie können ein Team, eine Produkteinführung usw. zurückwerfen. Die Konsequenzen der Einstellung eines schlechten SW-Ingenieurs sind viel höher.

Unsere Firma "stellt auch viele schwierige Fragen" und ich werde erklären, warum. Es ist uns wichtig, ob Sie wirklich wissen, wie ein virtueller Funktionsaufruf ausgeführt wird, aber nicht, weil er für die Aufgabe, die Sie ausführen, so wichtig ist.

Stattdessen kümmern wir uns darum, weil wir wissen müssen, wie schnell Sie grundlegende Dinge lernen können. Sie beanspruchen X Jahre Erfahrung? Okay, wir werden schwierige Fragen stellen, um herauszufinden, ob Sie solide Kenntnisse haben.

Sie wissen nicht, wie ein virtueller Funktionsaufruf unter der Haube erfolgt, wissen aber alles über Profilerstellung und Optimierung? Sehr gut, wir stellen Sie wahrscheinlich ein - Sie haben solide Kenntnisse in einem Bereich erworben, und Sie werden sicher solide Kenntnisse in einem anderen Bereich erwerben.

Sie behaupten, Sie hätten X Jahre Erfahrung in der Entwicklung, dem Debuggen und dem Reparieren von C ++ - Code und können nicht in einfachen Worten erklären, wie ein Zeiger auf ein Objekt verweist? Entschuldigung, wir können Sie nicht einstellen. Wenn Sie dies nicht können, wie können Sie dann schwierigere Probleme erklären, wenn wir komplexe technische Entscheidungen treffen müssen?

Kurze Antwort: Es gibt viele Leute auf dem Markt, die behaupten, Programmieren zu können, aber nicht programmieren können.

Randbemerkung: Ich bin überrascht, dass niemand einen Link zum FizzBuzz-Aufsatz gepostet hat .

Ich gehe einen anderen Weg und sage, dass das Problem möglicherweise nicht so sehr darin besteht, dass die Software-Engineering-Interviews von Natur aus schwieriger sind, sondern dass verschiedene Branchen nach unterschiedlichen Dingen suchen, die sich in ihrem Interviewstil zeigen.

Ich habe in einer Vielzahl von Branchen Interviews geführt (z. B. Start-up-Unternehmen, kleine Unternehmen, große Unternehmen, interne IT-Abteilung, Software-Unternehmen, Forschungsorganisation), und alle haben eine andere Art der Befragung, die ich normalerweise gefunden habe folge dem folgenden Muster:

• Start-ups sind in der Regel mit dem Wissen , besorgt zu sein , dass Sie das Schreiben von Code beginnen jetzt und ein schnelles Umwelt umgehen können. Als solche neigen sie dazu, sich Gedanken darüber zu machen, wie viel Sie aus dem Kopf wissen, da sie anscheinend nicht wollen, dass Sie viel Zeit damit verbringen, nach dem zu suchen, was sie für "Kernwissen" halten. Zuzugeben, dass Sie etwas nicht wissen, ist in dieser Umgebung möglicherweise nicht so gut, wenn sie es von Ihnen erwarten.
• Kleine Unternehmen neigen dazu, in Bezug auf Ihr Wissen nach den gleichen Dingen wie Start-ups zu suchen, sind jedoch weniger daran interessiert, wie gut Sie mit schnelllebigen Umgebungen umgehen (abhängig vom Job) und mehr daran, welche Art von Soft Skills Sie einsetzen bringen und wie gut Sie in das Unternehmen passen.
• Große Unternehmen und interne IT-Abteilungen scheinen eher darauf bedacht zu sein, dass Sie über einen bestimmten Standard an technischem Wissen verfügen, sind jedoch weniger besorgt, wenn Sie nicht alles auf den Kopf stellen, da sie davon ausgehen, dass es welche geben wird Zeit, die erforderlich ist, um Sie über die Erwartungen des Unternehmens zu informieren. Daher ist dies ein Umfeld, in dem das Eingestehen, dass Sie nichts wissen, aber bereit sind zu lernen und zu studieren, als Vorteil angesehen werden kann.
• In der Forschungsumgebung (dh nach meiner Erfahrung bei der Softwareentwicklung für Wissenschaftler) geht es ihnen in der Regel darum, ob Sie Software schreiben können, vor allem aber, ob Sie bereit sind, die erforderlichen Maßnahmen zu ergreifen, um sicherzustellen, dass Sie lernen, was sie tun Sie müssen Ihre Hand nicht halten, während Sie versuchen, ein Problem zu lösen. Da es sich auch um eine Forschungsumgebung handelt, scheinen sie auch daran interessiert zu sein, wie interessiert Sie daran sind, neue Dinge zu lernen.

Nun habe ich es versäumt, Softwareunternehmen (z. B. Google, Microsoft) zu erwähnen, da diese dazu neigen, ihre eigenen Dinge zu tun. Je nachdem, wie ausgereift das Unternehmen ist und für welche Gruppe Sie Interviews führen, suchen sie nach unterschiedlichen Dingen.

Am Ende des Tages kommt es jedoch, wie bei den meisten Dingen im Leben, darauf an. Persönlich habe ich festgestellt, dass sich einige Unternehmen sehr stark auf das "Buchwissen" konzentrieren, das auf Kosten der tatsächlichen Lösung der übergeordneten Probleme gehen könnte, während andere Unternehmen sehr besorgt zu sein scheinen, wie gut Sie mit den übergeordneten Problemen umgehen (dh können Sie ein Schema für x entwerfen ) und unter der Annahme arbeiten, dass sie bereit sind, drei bis sechs Monate zu investieren, um Sie auf den neuesten Stand zu bringen, bevor Sie voll produktiv sind.

Auch hier sind technische Interviews willkürlich und launisch.

Es gibt einen großen Unterschied zwischen dem Grillen einer Person auf den Minutien und der Frage, ob sie ihre CS kennt. Wie ich oben sagte, habe ich über ein Jahrzehnt Erfahrung mit C ++, aber ich würde dazu neigen, die OOP / Inheritance-Fragen zu bombardieren. Warum? Da nach dem Hinzufügen der Vorlagenunterstützung C ++ fast ausschließlich für die generische Programmierung verwendet wurde .

Ich habe mit mehreren BigHouseHoldNameTech-Unternehmen in der Bay Area und in Seattle gesprochen, und eines der besten Interviews beinhaltete echte Fragen, mit denen sie sich im Job befassen mussten, einschließlich Datenstrukturen und Algorithmen [dh: Sie haben 300 Milliarden Datenpunkte bestehend aus XYZ. Wie speichern und suchen Sie effizient? ].

Auf diese Weise wissen Sie, wie ein Kandidat eingreifen und die tatsächlichen Probleme lösen kann, mit denen Sie konfrontiert sind. Das absolut Schlimmste war auch bei einem anderen BigHouseHoldNameTech-Unternehmen, aber es stellte stundenlang unglaublich arkane Fragen, die man wirklich nur in einem Handbuch nachschlagen sollte [ dh die Hauptunterschiede zwischen der Leiterplatte in Windows und Linux beschreiben - und das war nicht der Fall]. t für eine Kernel Level Position ]

Hedge-Fonds sind bizarr, wenn es um Folter geht. Erwarten Sie 8 Stunden, um Probleme mit dem Rucksack auf einem Whiteboard zu lösen .

Ich bin ein Softwareentwickler (c / c ++) mit über 20 Jahren Erfahrung auf diesem Gebiet. Die Art der Interviews, die wir heute routinemäßig sehen (die Brain Teaser, die Implementierung von Datenstrukturen, Suchalgorithmen usw. auf dem Whiteboard), kam bis auf Neueinsteiger nur selten vor. Wenn eine Person für einen angemessenen Zeitraum für ein seriöses Unternehmen arbeitete, galt dies als Beweis für die Fähigkeit, Code zu schreiben. Jetzt ist es sehr schulisch geworden und ich weiß nicht warum. Die typischen Dinge, die Sie zum Code auffordern, KÖNNEN auswendig gelernt werden. Wenn Sie sie also auf dem Whiteboard ausführen, beweist dies nichts. In einem Arbeitsprojekt würden Sie das Internet nutzen, um etwas zu recherchieren, und Sie würden keine Bäume oder verknüpften Listen von Grund auf neu schreiben.

Ich denke, es ist eine weitere Modeerscheinung des Managements - genau wie Scrum -, wobei diese wahrscheinlich von Google, Amazon und Microsoft gestartet wurde. Alle anderen haben genauso kopiert wie Jack Welchs Rang und Trottel ... erinnerst du dich an GE?

Wenn Sie ein Personalmanager sind, der meine Kommentare liest, sollten Sie die Kandidaten fragen, WIE sie bestimmte Probleme lösen würden. Anstatt sie zu bitten, eine Hash-Tabelle zu codieren, geben Sie ihnen ein Problem mit einer Hash-Tabelle und fragen Sie, wie sie es lösen würden.

Ich stimme auch dem Entwickler über diesem Beitrag zu, der sagte "Gib ihnen ein echtes Problem, das das Unternehmen lösen musste"!

"Aber ich neige dazu, die OOP / Inheritance-Fragen zu bombardieren. Warum? Weil ich C ++ fast ausschließlich für die generische Programmierung verwendet habe, nachdem die Unterstützung für Vorlagen hinzugefügt wurde."

Dem stimme ich auch zu. Wenn Sie für ein Unternehmen arbeiten, schreiben Sie Code auf Ihre Weise. Manchmal fällt es mir immer noch schwer, mich an die C ++ - Aufrufsyntax zu erinnern, weil der leitende Architekt der Firma, für die ich 15 Jahre gearbeitet habe, lieber Zeiger als Referenzen verwendete. Er war ein alter C-Programmierer, wie Sie sehen. Das haben wir also alle genutzt.