„Senior-Entwickler“ im Interview mit Junior-Fragen, oder: wo ist der Beef? [geschlossen]

Senior Developer ist nur ein paar Wörter, sie können alles bedeuten, abhängig davon, was das Unternehmen damit sagen möchte. Ignorieren Sie sie außer als allgemeine Richtlinie und konzentrieren Sie sich auf das, was bezahlt wird. Das ist der wahre Test dessen, wonach sie suchen.

Ich habe für ein Unternehmen gearbeitet, in dem außer den Putzfrauen und den Fahrern jeder ein leitender Entwickler oder leitender Ingenieur zu sein schien.

Zwei Dinge hier.

1. Sie wären überrascht, wie viele "ältere" Entwickler nicht einmal die Grundlagen beherrschen. Bei meiner letzten großen Rekrutierungsrunde für Entwickler scheiterten vielleicht 75 % des Pools beim ersten richtigen Vorstellungsgespräch, und wir fingen an, Fizz Buzz zu machen, nicht weil es ein großartiger positiver Indikator war, sondern weil es viele erwischte, die nicht einmal das konnten. Viele erfahrene Entwickler erreichen diesen Weg, indem sie einige Jahre dort sind, aber in ihren Fähigkeiten keine Fortschritte gemacht haben, daher sind diese Fragen notwendig.
2. Abgesehen davon, was ist überhaupt ein "Senior"? Ich würde nicht automatisch sagen, dass technische Fähigkeiten der Unterschied zu einer Junior-Rolle sind, aber was ich erwarten würde, sind die mehr Soft Skills: in der Lage zu sein, ihre (und vielleicht die eines Juniors) Zeit zu verwalten; in der Lage sein, eine Aufgabe/Geschichte mit dem Unternehmen von Anfang bis Ende zu durchschauen und Probleme entsprechend zu behandeln (oder zu eskalieren); und in der Lage zu sein, einen Junior in den oben genannten Bereichen zu betreuen.

Was ich auch erwarten würde, ist eine andere Diskussionsebene zu den von Ihnen erwähnten Fragen, vielleicht einige weitere Meinungen darüber, warum sie gut / schlecht / hässlich sind und zu Kriegsgeschichten führen, die mir eher Vertrauen in ihre Fähigkeiten geben als eine Lehrbuchantwort.

Das sind nicht wirklich "Java-Fragen", das sind "OOP-Fragen" und "Fragen zu Programmiersprachen". Wenn Sie also meinen, dass Sie die Antworten auf diese Fragen aus der Arbeit mit einer anderen OOP-Sprache kennen, dann ist das gut für Sie.

Ich denke, dass Fragen wie diese eher ein gutes Zeichen sind als Fragen zu Details der Java-Syntax oder API. Es deutet an, dass das Unternehmen erkennt, dass das Kennzeichen eines guten Softwareentwicklers darin besteht, dass er Konzepte versteht, die über bestimmte Sprachen hinausgehen. Ich wäre besorgt, wenn mir ein Unternehmen Fragen stellen würde wie: "Was ist der dritte Parameter der foo-Funktion in der bar-Klasse". Wenn ich mich nicht erinnere, kann ich es in ein oder zwei Minuten nachschlagen. Aber wenn ich nicht weiß, was Garbage Collection ist, ist das eine lange Geschichte.

Geben Sie dem Interviewer etwas Spielraum. Sich Fragen für Vorstellungsgespräche auszudenken, ist eine knifflige Angelegenheit. Ist Ihr Problem, dass die Fragen zu einfach sind? Wenn ja, gut für Sie. Diese Fragen würden einen guten Prozentsatz der Entwickler, denen ich begegnet bin, verblüffen. Wenn Sie sie alle richtig beantworten können, gehören Sie wahrscheinlich mindestens zu den oberen 50 %, vielleicht besser. Sie möchten Fragen, die schwierig genug sind, dass Sie die Kandidaten unterscheiden können, aber wenn Sie ihnen keinen 20-seitigen Test geben, möchten Sie keinen Kandidaten ausschließen, weil er die Antwort auf eine schwierige Frage nicht kannte. Wenn du zehn weitere gefragt hättest, hätte er vielleicht alle bekommen. Sie können viel nicht nur an der Antwort erkennen, sondern daran, wie der Kandidat antwortet. Offensichtlich, wenn er keine Ahnung hat, ist das ein Minus. Aber wenn er eine Lehrbuchdefinition herunterrattert, das kann darauf hindeuten, dass er die Schlagworte kennt, aber nicht wirklich weiß, wie das alles funktioniert. (Ich war einmal verbrannt, als ich einen Typen eingestellt habe, der im Vorstellungsgespräch alle möglichen Fachbegriffe und Definitionen aufsagen konnte, aber sich herausstellte, dass er nicht in der Lage war, die einfachsten Aufgaben zu erledigen. Ja, er konnte alle Rahmenwerke benennen und Sprachen und Produkte, aber als wir ihn baten, einen Bildschirm mit zwei Eingabefeldern zu schreiben und ihn in einer Datenbank zu speichern, hatte er keine Ahnung.) Ich bin beeindruckt, wenn jemand ein Konzept klar und sicher erklären kann.

Oh, und nach obskuren Fakten zu fragen erscheint mir ziemlich sinnlos. Vor Jahren fragte mich ein Interviewer, welche Daten in einem Unix-Inode seien. Ich wusste es zufällig – tatsächlich wusste ich es besser als er, er dachte, der Dateiname sei in einem Inode – aber wenn ich es nicht gewusst hätte, na und? Ich wusste es nur, weil ich eines Tages zufällig darüber gelesen hatte. Ich glaube nicht, dass ich dieses Wissen jemals beim Schreiben eines Programms genutzt habe.