Coding Interviews are Broken

Hat mir zu denken gegeben. Ich mag Algorithmen und Datenstrukturen, aber wenn ich mal einen Job nicht bekomme, weil ich Prim mit Kruskal verwechsle, wäre das schon ziemlich doof. Und ich habe exzellente Kollegen, denen das nicht so ihr Ding ist, wie soll das für die laufen? Und es ist schon eine Idiotie, dass ein Krauterladen diesen Interview-Stil übernimmt, nur weil es die "Großen"auch so machen.

Hattet ihr schon solche Erfahrungen?

Sind echte Erfahrungen eine Voraussetzung für eine Antwort?

So ein spezifisches Video als Anlass zu nehmen, bestimmte Dinge kritisch zu sehen, finde ich etwas irritierend. Ich meine … *wild gestikulierend in allen Richtungen auf die Welt zeigt, in der man als Informatiker arbeitet* :confounded: … Was mich besonders irritiert (neben der Tatsache, dass da irgendein Junge was erzählt, der ungefähr halb so alt ist, wie ich, und so fest davon überzeugt ist, die Welt verstanden zu haben, dass er nicht nur irgendeinen Kommentar irgendwo ablässt, den niemand liest, sondern die extra Meile geht, und ein Video erstellt, um seine Erleuchtung mit der Welt zu teilen), ist der Fokus auf „Job Interviews“.

So gesehen ist das Video ist so gesehen ein bißchen, wie wenn man auf ein brennendes Haus zeigt, und sagt: „Es ist nicht gut, dass es in der Küche so warm ist“. Joa. In der Küche ist es warm, weil das fLIucking Haus eben brennt!

Ich sehe das Problem nicht darin, dass in Job Interviews Fragen gestellt werden, die sich auf das beziehen, was man an der Uni gelernt hat, und was nichts mit der tatsächlichen Arbeit zu tun hat, sondern … eben darin, dass das, was man an der Uni lernt, nichts mit der tatsächlichen Arbeit zu tun hat!

Man lernt Dinge über Algorithmen, Datenstrukturen, Komplexität, Algebra, Abstraktion (und das sind Dinge, mit denen ich mich auch „gerne“ beschäftigen würde), aber in der Realität braucht man nichts davon. In der Realität geht es nur noch darum, eine Webseite anzuzeigen. (Natürlich mit einer MongoDB im Hintergrund und Node Express und Angular, und alles in Docker-Containern, und dafür braucht man dann eben einen Full-Stack-Developer, aber das schweift jetzt etwas ab).

Eine explizite Trennung zwischen einem Studiengang „Real Computing Science“ und einem „Stuff That You Need To Get Some Computer Job“ (mit Vertiefungsoption „Googling Error Messages“) wäre nicht verkehrt. Oder anders gesagt: Wenn eine Firma seinen Vorschlag umsetzen würde, und mich bei einem Interview fragen würde: „Hey, hier ist der letzte React-Bug, mit dem wir zu tun hatten, wie würdest du den beheben?“, dann würde ich sie auslachen und kommentarlos den Raum verlassen.

Ich denke, dass es diese Art Interviews mehr in den USA gibt, habe das aber auch schon erlebt (länger her, für einen Job in der Schweiz). Und ich finde dieses Nachäffen von Google und Co ziemlich albern. Zu sehen, wie sich jemand fremden Code liest, fände ich schon interessant. Debuggen muss nicht sein, ich würde eher Code Review machen lassen.

Bezüglich der Ausbildung gebe ich dir teilweise recht. Ich finde es schon wichtig, dass man einen Algorithmus verstehen und implementieren kann, nur dass man sie unbedingt alle kennen muss, ist ziemlich überflüssig. Dass man die Uni mit einem Master verlassen kann, ohne auch nur ansatzweise programmieren zu können, ist ein Unding. Damit sind wir aber nicht allein, das ist selbst bei den ältesten Studiengängen so (z.B. ist Ziel des Jurastudiums offiziell immer noch die „Befähigung zum Richteramt“, wobei am Ende 98% aller Absolventen genau das nicht tun werden, und von denen lernt auch niemand, wie z.B. die Rechtsanwaltsgebührenordnung anuzuwenden ist).

Wenn man versucht, weitere „Schichten“ dieser Fragestellung runterzuschälen, liegt recht weit oben IMHO der Punkt, dass eben ~„alles irgendwie mit Computern zu tun hat“, und anscheinend gibt es die Ansicht, dass „wenn irgendwas mit einem Computer gemacht werden muss, dann muss man einen Informatiker da hin setzen“.

(Weitere Schichten sind, dass das einen falschen Bedarf suggeriert, und bewirkt, dass ~„Informatiker händeringend gesucht werden“, und die Unis und FHs ihre Kapazitäten erhöhen, um im großen Stil Leute, die vor 20 Jahren noch „Webdesigner“ genannt worden wären, mit einem „Bachelor of Science“-Zeugnis in die Welt entlassen, damit sie sich auf der Unmöglichkeit einen ROI für IT-Projekte zu definieren ausruhen und vielleicht nebenbei noch irgendwelche Trivialitäten als NPM-Pakete veröffentlichen, die ein wichtiger Stein im Kartenhaus der IT-Infrastruktren werden… oh jeh, so viel Verbitterung :frowning: )

Die Frage, wie man in einem Interview einen geeigneten Kandidaten findet, ist schwierig zu beantworten. (Was nicht zuletzt daran liegen könnte, dass Leute gar nicht genau definieren können, was jemand denn können muss - außer, dass er eben ~„machen soll, dass die Webseite so läuft, wie Kunden das wollen“). Vor einiger Zeit hatte ich mal den (zugegeben recht langen) Artikel The Guerrilla Guide to Interviewing (version 3.0) – Joel on Software gelesen, und da waren IIRC ein paar ganz gute Punkte drin)

Reine Spekulation: Es könnte sein, dass jemand, der ein Job-Interview gestalten muss, nicht so genau weiß, wie er da vorgehen sollte, und dann dazu neigt, etwas zu fragen, was er selbst weiß und/oder womit er im Studium viel Zeit verbracht hat.

(Zumindest beobachte ich - zugegeben, auch bei mir selbst - dieses Denkmuster: „Das sind doch Grundlagen, das muss jeder wissen“. Wenn du jemanden fragen würdest, ob er glaubt, den Dijkstra-Algorithmus nachimplementieren zu können, wenn er ihn als Pseudocode bekommt, und der würde fragen: „Den was-für-einen-Algorithmus? Nie gehört…“, dann würdest du ja sicher auch zumindest skeptisch eine Augenbraue hochziehen…)

Und „verstehen“ ist dabei ein Begriff, der sehr tief sein kann (genau wie „implementieren“ :smiley: ). Vielleicht steckt da im Kern das dahinter, was bei xkcd: Academia vs. Business mitschwingt. Es gibt nur wenige Jobs, in denen man ein Paper (d.h. eine wisschenschaftliche Veröffentlichung) lesen und das ganze in Code gießen muss. (Das Fass, was heute für ein Dreck an Papers in die Welt gepresst wird, mache ich jetzt mal nicht auf). Und die Spanne zwischen „Es compiliert (und läuft sogar!!11) - deployen wir’s“ und „Dieser Code ist ein wertvolles Asset für unsere Firma“ ist eben gigantisch…

Code-Reviews sind so eine Sache. Viele Fragen, die man für „wichtig“ hält, sind vielleicht gar nicht so wichtig, wie man selbst glaubt. Aus Neugier, auch wenn das abschweift, habe ich gerade mal „github java“ in Google eingetippt und mich mehr oder weniger zufällig zur ersten Klasse durchgeklickt, die da erschien. Ich habe keine Ahnung was das ist oder was das macht, aber ich bin bei quarkus/core/processor/src/main/java/io/quarkus/annotation/processor/ExtensionAnnotationProcessor.java at main · quarkusio/quarkus · GitHub gelandet.

  • Kein Copyright-Header
  • Die Klase ist zu groß
  • Kein JavaDoc
  • Die Klasse ist public - sollte sie nicht auch final sein?
  • Loake Variablen final zu machen ist an sich meistens überflüssig, aber kann gerechtfertigt sein
  • Ist processingEnv etwa eine protected-Variable? Neeeein!
  • doFinish ist zu lang
  •      try (...) {
             try (...) {
                 try (...) {
                     try (....) {
    
    at least you tried

und das ohne, das ganze in einer IDE aufzumachen und wirklich nachzuvollziehen (und trotzdem scheint das noch eine der „besseren“ Codebasen zu sein…).

Man könnte aber, das mag sein, erkennen, wie jemand bei einem (richtigen) Code-Review vorgeht, und versuchen, daraus Rückschlüsse zu ziehen…

Volle Überinstimmung beim Code-Review. Die try-Kaskade ist ja furchtbar, sagt ihm doch mal jemand, dass man die „Köpfe“ zusammenfassen kann…

Hm, ein langes Video, statt einfach nur Text (in einem Blog). Ich komme mit Videos, in denen jemand etwas (wichtiges) erzählt, nicht so gut zurecht… aber das nur nebenbei. Ich verliere dann schnell die Geduld und bin nicht so dizipliniert.
Also ja, ich finde Algorithmen für bestimmte Probleme zu kennen wichtig. Möglichst alle. In einem Interview wurde ich auch schon danach gefragt. Ich habe dann einen kurzen Abriss über die mir bekannten Algorithmentheorien gegeben.
Wenn man fies sein möchte, könnte man sagen, daran trennt sich die Spreu vom Weizen. Allerdings gilt immer auch bei Interviews, dass sie immer auch von der Tagesform abhängig sind. Zu dem, wie man sie stattdessen besser gestalten und das Setting verbessern könnte, habe ich mir noch keine Gedanken gemacht.

Ich habe persönlich nur wenige Bewerbungen hinter mir. Bin aber bei vielen als fachlicher Ansprechpartner dabei gewesen. Und ich denke, dass der Autor / / Streamer hier den Hauptpunkt nicht trifft.

Ich habe es so kennengelernt, dass HR einfach anders arbeitet als ein technisch versierter Nutzer. Diese überprüfen nicht, ob man tatsächlich ein binärbaum umdrehen kann, sondern wie man in der Lage ist mit Problemen überhaupt umzugehen.

Dabei stehen im Fokus Eigenschaften, wie strukturiertes Denken, Abstraktionsfähigkeit, Umgang mit Stress, Verhalten in unbekannter Situation. Und das in einem abgeschlossenen Problemraum, den man fachlich schnell begreift.

Den Vorschlag einfach mal 30 Minuten einen Gemeldeten Bug zu beheben ist einfach dumm. Denn dafür müsste man die fachlichkeit der Sw kennen, die Architektur und die Systemlandschaft.
Also ich kenne Produkte da würde man 30 Minuten damit verbringen ohne Hilfe die IDE zu starten und dann das Produkt.
Das macht überhaupt keinen Sinn.

Ich denke für Junior Entwickler, wie der Autor einer zu sein scheint, ist das umkehren eines Binärbaums gerade die richtige Frage.

Bei Architekten würde HR entsprechend anders vorgehen. Jemand der sich im HR bewirbt wird ja auch ein passendes Interview erhalten. Da fehlt dem Autor einfach die Erfahrung.

Das. Es ist das „Allgemeinwissen, dass doch jeder kennen muss“. Ich frage dann immer zynisch zurück ob die Person denn auch Themen kennt, die für mich persönlich jeder wissen müsste. Den Spiegel vorzuhalten funktioniert relativ häufig ziemlich gut, würde ich behaupten.

Ich sehe aber auch noch ein anderes Problem, und zwar das häufig Anforderungen gestellt werden, für die man höchstens ein paar Stunden, vielleicht ein paar Tage Einarbeitungszeit benötigen „würde“. Also wenn man kein Idiot ist - ‚lernfähig‘. Aber häufig scheitert es daran, dass ein Bewerber dann simple Fachkenntnisse nicht hat und man ihm nicht zutraut sich die Kenntnisse selbstständig in vertretbarer Zeit zu erarbeiten.

Perfektes Beispiel:

Es braucht eine Minute um dem Autor mündlich eine andere Möglichkeit mit zu teilen. Auch gutes Personal muss gepflegt werden.

Edit: Zu dem try..try...try gab es einige Antworten, das wird nun hier besprochen: Mehrere resources mit try-with-resources verwalten


Die Punkte mit dem „Allgemeinwissen“ und „Anforderungen mit geringer Einarbeitungszeit“ überschneiden sich. Das, was „Allgemeinwissen“ genannt wird, ist eben oft gerade das, was man nicht im working memory haben muss, sondern schnell auf Wikipedia, in der Doku, oder auf einer Q/A-Seite nachschauen kann. Und wenn es ein paar solcher Kleinigkeiten gibt, die man wissen muss, um die Aufgabe zu lösen, kann man sich da schnell einarbeiten, falls es eben nicht an anderern Dingen hapert.

In diesem Sinne ist es (wie ich an anderer Stelle schonmal erwähnt hatte) heute eben nicht mehr so, dass sich „Kompetenz“ darin äußert, dass man sich in dem Bereich, in dem man arbeitet, gut auskennt, sondern dass man sich in den speziellen Teilbereich, der gerade relevant ist, so schnell einarbeiten kann, dass man damit vernünftige Ergebnisse erzielen kann.

(An den relativen und subjektiven Begriffen („gut“, „schnell“, „vernünftig“…) erkennt man schon, dass man da sehr unterschiedliche Ansichten haben kann. Aber ob man die Details hier auswalzen muss, weiß ich nicht).

Ich denke ja, dass ein wichtiges Zeichen dafür, ob jemand seine Sache gut machen wird, nicht die Antworten sind, die jemand in einem Coding-Interview gibt, sondern vielmehr die Fragen, die er stellt. Aber das sehen andere sicher anders…

3 Beiträge wurden in ein existierendes Thema verschoben: Mehrere resources mit try-with-resources verwalten