Coding Interviews are Broken

Sonstiges Spielwiese
4

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…