Ich habe also beide Seiten dieser Frage gesehen und war eigentlich auch auf beiden Seiten. In der Programmierwelt scheint es einen schmalen Grat zu geben zwischen großartigen Vorstellungsgesprächen, um Kandidaten richtig auszusortieren, und dem, zu zeigen, wie viel die Entwickler auf der Einstellungsseite des Tisches wissen.
Zum Beispiel ist es sinnvoll, jemanden zu bitten, eine für den jeweiligen Job anwendbare Logik pseudo-zu codieren oder sogar legitim zu codieren , aber ich bezweifle den Nutzen des Interviewers, der eine theoretische Frage wie „Erkläre Kovarianz und Kontravarianz“ oder eine andere Frage stellt eine Sprache, mit der wahrscheinlich nur das Team, das das Produkt erstellt, gut vertraut ist (dh das .NET Framework-Team bei Microsoft).
Ich weiß, dass die erste Reaktion auf diese Frage lauten könnte: „Sicher, es zeigt, wie ein Kandidat eine schwierige Frage beantwortet, die er wahrscheinlich nicht kennen wird, yada, yada, yada“ oder „Wenn es zutreffend ist, dann ‚Ja‘ … ." Immer häufiger scheint es jedoch, dass es bei dieser Art von Fragen darum geht, dass das Interviewteam dem Kandidaten zeigt, wie viel es weiß. (Ich war auf dieser Seite des Tisches, als meine Kollegen dies getan haben, und mein erster Gedanke war, wie irrelevant die Frage war.)
Wie können diese Art von detaillierten technologischen Fragen in einer Interviewsituation nützlich sein?
Es geht nicht unbedingt um Ego.
Ich neige dazu, zu versuchen, etwas auszugraben und zu finden, was die andere Person nicht weiß, nur um zu sehen, ob sie versucht zu bluffen oder ob sie ehrlich gesagt einfach sagt: „Nein, das ist mir noch nie begegnet … was ist das? " (das letzte bisschen für Bonuspunkte). Ich gehe jedoch nicht zu hart vor und ich demütige niemals einen Kandidaten. Ich möchte nicht einmal, dass sie für den Rest des Interviews gedemütigt werden. Ich möchte nur wissen, wie sie auf etwas reagieren, das sie nicht kennen.
Ich habe jedoch ein paar Interviews mit Entwicklern gesehen, die eindeutig nur angeben wollten. Diese Fälle waren offensichtlich, weil sie Fragen von einer Liste stellten und dann die Antwort laut blökten, wenn der Kandidat sie falsch verstanden hatte.
Interessant: Beide waren keine besonders guten Entwickler. Ich frage mich, ob sie überkompensiert haben. Oder vielleicht die Trivia-Teile, in denen die Antworten direkt vor ihnen lagen, in die Länge zu ziehen, um nicht in flüssigere technische Gespräche verwickelt zu werden (wo ich gerne ein Interview führe).
Ich bin mir zwar sicher, dass es da draußen Entwickler gibt, die in einem Interview angeben wollen, aber in den allermeisten Fällen, in denen ich gesehen habe, dass Leute in einem Interview „unmögliche“ Fragen gestellt haben, war die Absicht nicht böswillig. Stattdessen besteht das Problem darin, dass Menschen im Allgemeinen und Entwickler im Besonderen sehr schlecht darin sind, im Voraus zu wissen, wie einfach eine Frage wahrscheinlich ist und wie wahrscheinlich ein kompetenter Entwickler in der Lage sein wird, eine glaubwürdige Antwort zu geben. Im Allgemeinen braucht es einige Kandidaten, die durch die Tür kommen, die kompetent erscheinen, aber von einer bestimmten Frage völlig ratlos sind, damit der Interviewer erkennt, dass das Problem die Frage ist, nicht die Kandidaten.
Wenn Entwickler ziemlich viel Zeit in einer ganz bestimmten Nische verbringen und mit anderen Leuten interagieren, die sich ebenfalls auf diese bestimmte Nische konzentrieren, wird es sehr leicht, die Art von Dingen zu vergessen, die man in diesen Gesprächen für selbstverständlich hält, die eine Herausforderung darstellen würden ein kompetenter Entwickler in einer anderen Nische. Als ich zum Beispiel mit einem Kommunikationsunternehmen ein Vorstellungsgespräch führte, hatte einer der Ingenieure eine ganze Reihe von Fragen zur Huffman-Codierung. Es gab ein Problem bei einer Aufgabe in einer Klasse in meiner Karriere als Student, bei der Huffman-Codierung zufällig auftauchte und ich keine Zeit damit verbracht hatte, über den Algorithmus nachzudenken oder warum er auf eine bestimmte Weise strukturiert war, also war ich weit außerhalb meiner Tiefe um diese Fragen zu beantworten. Dem Interviewer jedoch, der viel Zeit mit Komprimierungsalgorithmen im Allgemeinen verbrachte, schien die Huffman-Codierung eine so grundlegende Sache zu sein, dass jeder kompetente Student sie verinnerlicht haben sollte, um mit der Art von Problemen fertig zu werden, die er war umgehen mit. Ich bezweifle, dass er absichtlich versuchte, sich vor einem Haufen neuer Absolventen schlau zu machen, es kam ihm einfach nicht in den Sinn, dass Signalkomprimierungsalgorithmen ' Eine Nische, in der die meisten Entwickler viel Erfahrung haben, es sei denn, sie arbeiten zufällig für große Kommunikationsunternehmen. Ich würde wetten, dass er das Problem erkannte und seine Fragen korrigierte, nachdem ein paar Dutzend Leute seinen Teil des Interviews komplett bombardiert hatten, während er an anderer Stelle recht gut abschnitt.
jcmeloni