Bitte keine unrealistischen Coding-Challenges mehr
(blackentropy.bearblog.dev)- Unrealistische Coding-Aufgaben in manchen technischen Bewerbungsgesprächen erzeugen Drucksituationen, die wenig mit der realen Arbeit zu tun haben, und messen die praktische Kompetenz von Entwicklerinnen und Entwicklern nicht zuverlässig
- Einzelaufgaben unter hohem Druck bilden ein Arbeitsumfeld mit Zusammenarbeit und Unterstützung nicht ab und laufen leicht darauf hinaus, veraltete Codebasen ohne Dokumentation oder Hilfe aus dem Team zu debuggen
- Selbst wenn Unternehmen von einer „4-Stunden-Aufgabe“ sprechen, kann sich der Aufwand mit Unternehmensrecherche, Prüfung der Rollenanforderungen und Überarbeitung der Ergebnisse auf 8 bis 10 Stunden oder mehr ausdehnen
- Aufgaben in einem für die Rolle irrelevanten Tech-Stack werden zwar als Test der Anpassungsfähigkeit begründet, doch von einer Ruby-Entwicklerin oder einem Ruby-Entwickler PHP-Debugging zu verlangen, kann an der tatsächlichen Eignung vorbeigehen
- Recruiting sollte sich statt auf willkürliche Druckaufgaben auf relevante technische Fähigkeiten, Problemlösung, Zusammenarbeit und Entwicklungspotenzial konzentrieren; überzogene Aufgaben können gute Kandidatinnen und Kandidaten erschöpfen und abschrecken
Interview-Aufgaben, die nicht zur realen Arbeit passen
- In manchen technischen Bewerbungsgesprächen sollen Entwicklerinnen und Entwickler innerhalb weniger Stunden Aufgaben wie Legacy-PHP-Debugging oder das Erstellen einer Mini-App lösen
- Solche Einzelaufgaben unterscheiden sich von der tatsächlichen Arbeitsweise
- Im Arbeitsalltag arbeitet man in der Regel mit dem Team zusammen und kann Unterstützung bekommen
- Eine alte Codebasis ohne Dokumentation oder Hilfe aus dem Team allein und unter Zeitdruck zu debuggen, entspricht nicht der üblichen Entwicklungsumgebung
- Unternehmen sehen darin zwar oft einen Test der „Problemlösungsfähigkeit“, doch wenn die Aufgabe nicht mit den tatsächlichen Anforderungen der Rolle verknüpft ist, lässt sich die praktische Eignung der Kandidatinnen und Kandidaten nur schwer beurteilen
Versteckte Zeitkosten und Belastung für Bewerbende
- Die empfohlene Bearbeitungszeit von Coding-Aufgaben spiegelt oft nicht wider, wie viel Zeit Kandidatinnen und Kandidaten tatsächlich investieren
- Vor der Aufgabe müssen sie das Unternehmen recherchieren und die Anforderungen der Stelle prüfen
- Auch das Überarbeiten des Projekts, damit die Abgabe in einem guten Zustand ist, kostet Zeit
- Eine „4-Stunden-Aufgabe“ kann leicht auf 8, 10 oder noch mehr Stunden anwachsen
- Für Entwicklerinnen und Entwickler, die Beruf und Privatleben parallel bewältigen, kann sich das wie unbezahlte Arbeit für einen Job anfühlen, den sie noch gar nicht bekommen haben
Wo die Bewertung von Anpassungsfähigkeit vorbeigeht
- Aufgaben in einem nicht relevanten Tech-Stack werden manchmal als Test der „Anpassungsfähigkeit“ gerechtfertigt
- Von einer Ruby-Entwicklerin oder einem Ruby-Entwickler PHP-Debugging zu verlangen, kann unabhängig von der Bedeutung von Anpassungsfähigkeit ein ungeeigneter Maßstab für den Wert einer Kandidatin oder eines Kandidaten sein
- Die Fähigkeit, vage und irrelevante Aufgaben schnell abzuarbeiten, reicht nicht aus, um zu beurteilen, ob jemand zur tatsächlichen Rolle passt
- Manche Aufgaben können sich weniger wie eine Eignungsprüfung anfühlen als wie eine Demonstration des unternehmenseigenen „Elite“-Anspruchs
- Wenn jede Einstellung mit einer „Top-1-%“-Hürde versehen wird, können selbst erfahrene Kandidatinnen und Kandidaten abspringen, die die eigentliche Arbeit sehr gut machen würden, weil die Situation künstlich und übermäßig druckvoll ist
Was Recruiting-Aufgaben bewerten sollten
- Der Bewerbungsprozess sollte sich an den konkreten Fähigkeiten orientieren, die für die Rolle nötig sind
- Coding-Bootcamp-artige Aufgaben ohne Bezug zu den tatsächlichen Anforderungen der Arbeit sollten vermieden werden
- Im Fokus sollten Problemlösung, Zusammenarbeit und Entwicklungspotenzial im relevanten Bereich stehen
- Anpassungsfähigkeit sollte nicht daran gemessen werden, wie schnell jemand willkürliche Aufgaben erledigt, sondern an der Fähigkeit, langfristig zu lernen
1 Kommentare
Meinungen auf Hacker News
Wann habe ich zuletzt eine alte Codebase ohne Dokumentation und ohne Hilfe vom Team debuggt? Ständig. Es waren 300.000 bis 400.000 Zeilen C++, und Legacy bedeutete: keinerlei Tests, kaum Dokumentation, und als einziger Entwickler in einem kleinen Unternehmen musste ich Bugs beheben und Features hinzufügen, während der Dienst weiterhin Zehntausende Nutzer versorgte.
Ein aktuelles Beispiel: Es gab einen über ein Jahr alten Patch für ein Kernfeature, dessen ursprünglicher Autor nicht mehr da war; ich musste den Code entweder von Grund auf neu schreiben oder den Patch wiederbeleben und an
masteranpassen.Die Fähigkeit, in ein Projekt einzusteigen und Leute auf ein Ziel hinzuführen, ist für einen Senior Developer eindeutig eine notwendige Kompetenz, und ich stimme zu, dass Problemlösungsfähigkeit getestet werden sollte. Allerdings sollte sich der Inhalt eines technischen Interviews nach der Rolle richten: Einem Junior-Webentwickler muss man auf dem Whiteboard keine Graphalgorithmen abfragen, aber ein Senior Developer oder Architect für ein Social-Network-Produkt sollte sie gründlich verstehen.
Letzte Woche habe ich ähnlich alten Go-Code aus dem Jahr 2020 debuggt, ebenfalls ohne Kommentare oder Dokumentation; auch das war ein Kernteil des Systems und wirkte, als hätten ihn Verrückte geschrieben. Schmerzhaft.
Die Bereitschaft, nach unten vorzudringen, um ein Problem auf der richtigen Ebene zu lösen, ist meiner Ansicht nach eine der großen Soft Skills, die Senior Engineers auszeichnen. Statt Bugs oder fehlende Funktionen in tieferen Schichten durch nachträgliche Korrekturen im eigenen Code zu umgehen, macht eine Reparatur auf der richtigen Ebene das Gesamtsystem robuster gegenüber Änderungen ober- und unterhalb im Stack sowie gegenüber unerwarteten künftigen Anwendungsfällen.
Umgekehrt beginnt eine Codebase zu verrotten, wenn man diesen Ansatz nicht verfolgt, nachdem Senior Engineers gegangen oder durch Juniors ersetzt worden sind. Wenn man zum Beispiel für jeden Edge Case beim Parsen von Eingaben vor einen unheimlichen, undurchsichtigen Parser jeweils noch eine naive Validierungs-Regex setzt, statt die Grammatik des Parsers selbst zu korrigieren, entwickelt sich die Codebase gerade zu einem Schlammklumpen.
Natürlich führt eine Korrektur auf der richtigen Ebene oft dazu, dass das Unternehmen einen kleinen, nicht öffentlichen, langfristigen Hotfix-Branch einer Ökosystem-Software pflegen muss, die es im Stack verwendet. Upstream sieht das Problem normalerweise nicht als Problem und nimmt den Patch daher nicht an, also muss man ihn allein behalten.
Halb im Scherz gesagt: Wenn man per GitHub-Profil verifizieren und zählen könnte, wie oft jemand solche langfristigen privaten Hotfix-Branches erstellt oder gepflegt hat, ließe sich die Seniorität eines Engineers vielleicht viel einfacher messen als mit einem Coding-Test.
So zu tun, als sei das in der Realität nutzlos, hilft nicht. Die Realität ist unordentlich, Dokumentation fehlt oft oder ist unzuverlässig, und die Person oder das Team, die den ursprünglichen Code geschrieben haben, sind möglicherweise längst weg.
Eine kleine Anekdote: Der Ehepartner eines Freundes kündigte Anfang des Jahres und bereitete sich dann jeweils 4 bis 6 Wochen auf Interviews bei einzelnen Big-Tech-Unternehmen vor. Meta 4 bis 6 Wochen, Stripe 4 bis 6 Wochen und so weiter. Zwischendurch machte er auch wahllose Interviews, um Übung und Muskelgedächtnis aufzubauen, recherchierte, welche Aufgaben bei den jeweiligen Firmen wahrscheinlich vorkommen, und löste täglich mehrere Stunden LeetCode-Aufgaben.
Am Ende lief es gut, und er nahm ein L6/staff-Angebot bei MAANG an. Als ich diese Woche mit ihm sprach, sagte er allerdings, dass er die meisten Details, die er geübt hatte, schon wieder vergessen habe, obwohl er die neue Rolle noch gar nicht begonnen hat. Da er keine Erfahrung mit Systemdesign hatte, sei die Vorbereitung auf Systemdesign am schwierigsten gewesen, aber jetzt ist er Staff Eng bei MAANG. Aus der Realität eines kleinen gemeinsamen Projekts kenne ich ihn als guten, aber nicht außergewöhnlich herausragenden Engineer.
Das ist wirklich seltsam und scheint viel über die Boom-and-Bust-Zyklen im Recruiting zu erklären. Wenn man sich Vorbereitungsvideos für Systemdesign-Interviews ansieht, wirkt das fast wie ein Skript. Man geht ins Interview und muss nur dem Skript folgen; ob man tatsächlich ähnliche oder komplexere Systeme entworfen hat, scheint keine große Rolle zu spielen. Der Zweck eines Systemdesign-Interviews scheint letztlich zu sein: „Kennst du das Skript?“
Wenn man diese beiden Videos direkt hintereinander mit 2-facher Geschwindigkeit anschaut, ist erstaunlich, wie sehr sie wie eine einstudierte Aufführung wirken: https://www.youtube.com/watch?v=4_qu1F9BXow, https://www.youtube.com/watch?v=_K-eupuDVEc
Meine beiden Eltern waren in den 1980er- und 1990er-Jahren in der Tech-Branche von Santa Cruz, und damals war der Talentpool nicht groß; es war ein inklusives Werkzeug, um Menschen zu finden, die man zu Entwicklern ausbilden konnte. Die heutige Branche hat diese Praxis übernommen, sie aber ins genaue Gegenteil verkehrt und exklusiv gemacht.
Einer der Menschen, die ich eingestellt habe, war Physiker, kannte überhaupt keine Fachbegriffe und war beim ersten Anblick einer Whiteboard-Aufgabe verängstigt. Als ich ihn bis zu einem Punkt führte, an dem er sich wohlfühlte, begann er von Tools zu erzählen, die er gebaut hatte, um seine physikalische Arbeit zu unterstützen. Er war überrascht, als ich sagte, dass diese Tools, die er ohne Entwicklerwissen gebaut hatte, Software seien. Das war nicht nur echte Software, sondern auch sehr beeindruckend, und die Whiteboard-Aufgabe war ein Werkzeug, um Potenzial sichtbar zu machen.
Ich verstehe, dass große Unternehmen statt Menschen lieber sofort einsetzbare Widgets wollen, aber es ist schon komisch, dass sie etwas verwenden, das ursprünglich für den genau gegenteiligen Zweck geschaffen wurde. Manchmal denke ich sogar, es ist ein Glück, dass ich alt genug bin, um keine Hoffnung mehr zu haben, in so ein tolles Unternehmen mit solchen Coding Challenges zu kommen.
Die Logik lautet: Egal, welche Universität man besucht hat, welche Kurse man belegt hat oder welche Vor- und Nachteile man hatte — wenn man die für die Rolle nötigen Eigenschaften mitbringt, kann man den Stoff innerhalb weniger Monate lernen. Da die Technik stark standardisiert ist, wird auch der Prozess ziemlich objektiv unterscheidbar.
Es wird nicht erwartet, dass man genau diese speziellen Skills im tatsächlichen Job einsetzt. Stattdessen zeigt man, dass man diese Art von Skills lernen und in einer stressigen Interviewsituation auf hohem Niveau abrufen kann. Die Logik ist, dass das ein gutes Signal dafür ist, ob man die für das spätere Projekt nötigen Skills lernen und unter hohem Termindruck liefern kann.
Ich verteidige dieses System nicht, aber dahinter steht eine klare Logik.
Er sagt zwar, er habe es vergessen, aber wenn er die Stelle bekommen hat, konnte er wahrscheinlich LeetCode-Aufgaben mittlerer Schwierigkeit lösen. Schwer zu glauben, dass er alles vergessen hat; leichte Aufgaben, die die meisten Leute spontan nicht lösen können, kann er vermutlich immer noch lösen. Die Komplexität grundlegender Backend-Aufgaben wie Suchen, Sortieren, Arrays und Hash-Lookups sowie Traversieren von Bäumen und Graphen kennt er wahrscheinlich ebenfalls noch.
Und schauspielerisches Talent könnte in der Gesamtbevölkerung häufiger sein als Programmiertalent.
Ich habe vor Kurzem den Interviewprozess für eine eher seniorige Engineering-Rolle bei einem kleinen Startup durchgeführt. Ich glaube, dass je nach Person unterschiedliche Interviewformate besser passen, deshalb habe ich allen eine Auswahl gegeben.
Weil ich viel Ärger über Take-Home-Tests gesehen hatte, dachte ich, die drei Optionen würden sich recht gleichmäßig verteilen. Überraschenderweise entschieden sich aber etwa 90–95 % der Kandidaten für den Take-Home-Test. Das war für mich ein interessanter Datenpunkt, weil ich das als Bewerber ebenfalls bevorzugen würde, und es hat mich sehr überrascht, dass die meisten ihn bevorzugten.
Bei einem persönlichen Interview hat auch das Unternehmen erhebliche Kosten, daher ist die Wahrscheinlichkeit geringer, dass meine Zeit verschwendet wird. Die Asymmetrie im Bewerbungsprozess nimmt ohnehin schon zu, und Take-Home-Aufgaben beschleunigen diesen Trend noch.
Ein nichttechnischer Freund nimmt mir bis heute übel, dass ich eine Aufgabe früher einmal nicht fertiggestellt habe. Die Kernanforderungen waren offensichtlich trivial, aber die Anweisungen waren vage genug, dass man Stunden damit verbrennen konnte, einzuschätzen, ob die Abgabe gut genug wäre. Außerdem wurde ein enger Tech-Stack erwartet, der zwar nicht schwierig war, aber ich wollte ihn nicht erst lernen, nur für die vage Chance, einem Unternehmen zu helfen, das angeblich „keine Tech-Talente findet“.
Ich würde vermutlich 1 und 2 gegenüber 3 bevorzugen. Denn wenn der Interviewer das Problem versteht, das ich löse, kann er meinen Ansatz besser bewerten.
Wenn ich es zu Hause mache und später einreiche, kann der Interviewer meine Lösung mit seiner eigenen oder mit anderen Lösungen vergleichen und anhand derselben Aufgabe meinen Coding Style besser einschätzen.
Wenn wir im Pairing zusammenarbeiten, kann er meinen Denkprozess sehen, und ich kann besser erklären, warum ich bestimmte Idiome gewählt habe.
Alter Code hat kaum Kontext. Es ist einfach Code, der für ein anderes Projekt geschrieben wurde. In einer frühen Phase kann er nützlich sein, um zusammen mit dem Lebenslauf zu zeigen, dass man tatsächlich Code schreiben kann. In späteren Phasen ist er aber wohl nur dann beeindruckend, wenn es eine funktionierende App gibt und man durch den Code einer bestimmten Funktion führen kann. Aber wie viele Leute haben einfach so funktionierende Software herumliegen? Meistens hat man nur Code, der mit ein paar Tricks irgendwie läuft.
Ich bevorzuge 1 gegenüber 2. Die Wahrscheinlichkeit, Fehler zu machen, ist geringer. Statt vor Ort 2 Stunden lang unter Druck und mit Murphys Gesetz im Nacken zu riskieren, alles zu vermasseln, ist es natürlich besser, zu Hause 2 zusätzliche Stunden zu investieren und frei recherchieren zu können, was man nicht weiß.
Ich war auch schon auf der Seite, die Take-Home-Tests bewertet, und ich weiß, wie schwer es ist, damit jemanden wirklich zu beeindrucken.
Als ich zuletzt ein echtes Coding-Interview hatte, durfte ich eine beliebige Programmiersprache wählen und mir auch eine von drei Aufgaben aussuchen. Das gefiel mir ziemlich gut, und ich bekam auch ein Angebot. In einem Interview mit Zeitlimit Python statt C++ wählen zu können, fühlte sich fast wie Cheaten an.
Je mehr Beschwerden über Coding-Interviews ich online sehe, desto überzeugter bin ich, dass Coding-Interviews mit Abstand die beste Methode sind, um Kandidaten für Softwareentwicklungsstellen auszusieben. In der Branche gibt es viel zu viele Leute, die gut reden können, Hochstapler und Meeting-Organisierer, und zu wenige, die die Ärmel hochkrempeln, sich in den Code stürzen und die Arbeit tatsächlich erledigen.
Je höher das Level, desto schlimmer wird dieses Problem. Man kann sich nach Herzenslust beschweren, aber ein bequemer FAANG-Job für 500.000 Dollar im Jahr steht einem nicht automatisch zu. Wenn man nicht bereit ist, sich grundlegende Programmierung noch einmal anzusehen und ein paar for-Schleifen zu schreiben, wird das Unternehmen eben jemanden nehmen, der dazu bereit ist.
Wenn das Interview wirklich die Fähigkeit testen würde, die Ärmel hochzukrempeln und in Code einzutauchen, verstehe ich nicht, warum ich als Neueinsteiger so vielen Leuten, die schon lange dort sind, so viel über Software Engineering und Debugging-Praktiken erklären muss.
Wenn man tatsächlich in großen Unternehmen gearbeitet hat, weiß man, dass 90 % der echten Arbeit von höchstens 5 % der Leute erledigt werden. Wenn Interviews richtig funktionieren würden, müsste dieses Verhältnis viel besser sein.
Es gibt Cracking the Coding Interview, Elements of Programming Interviews in Java/Python/anderen Sprachen, LeetCode und kostenpflichtige Premium-Abo-Seiten bis hin zu Mock-Interview-Bootcamps. Heute geht es weniger um Kompetenz als darum, das System zu gamen.
Erstaunlich, dass es keinerlei kognitive Dissonanz zwischen der Prämisse gibt, dass Coding-Interviews die Standardmethode für Einstellungen sind, und der Realität, dass die Ergebnisse so schlecht sind.
Wenn die Aufgabe so etwas wie LLM-Tokenisierung ist, wie will man bei einer „ML-LeetCode“-Aufgabe die Nutzung von LLMs verbieten?
Wenn ein Kandidat ein Experte darin ist, mit Cursor und Claude zu coden, die Aufgabe mit 3 Prompts und 2 leicht gefundenen Bugfixes in 10 Minuten löst und dazu noch NeurIPS-würdige Papers und Open-Source-Code vorweisen kann: Habe ich dann einen falschen Betrüger herausgefiltert oder einen Top-Kandidaten?
Für jemanden, der an LLM-bezogenen Themen arbeitet, halte ich LeetCode-artige Aufgaben nicht für sinnvoll. Ob man es mag oder nicht: Ein immer größerer Teil der bequemen FAANG+-Jobs für 500.000 Dollar im Jahr wird künftig mit LLMs zu tun haben.
Einem Ruby-Entwickler als Flexibilitätstest PHP zum Debuggen zu geben, klingt nach einem vernünftigen Test. Ein guter, insbesondere ein Senior Developer, sollte so etwas können. Sich selbst ausschließlich als „Ruby-Entwickler“ einzuordnen, ist eine Karrierefalle.
Manchmal muss man eine alte, anbieterspezifische DSL debuggen oder Code, bei dem Frameworks und Standards so alt sind, dass es fast eine andere Sprache geworden ist.
Oder man muss Support für zurückportierte Features ergänzen oder Sicherheitslücken bei alten Clients und Legacy-Stacks patchen. In großen Unternehmen ist es uns auch schon passiert, dass wir für den Escrow-Code eines deutlich kleineren Partners verantwortlich wurden.
Die Umgebung so einzurichten, dass man überhaupt ordentlich debuggen kann, ist oft mehr Arbeit als der eigentliche Fix. Trotzdem ist es ein guter Test für Senior-Level und darüber.
Der Interviewer sagte: „Drehen Sie dieses Array um“, und ich antwortete: „In Python würde ich array.reverse() oder reversed(array) verwenden, und in JS wird es vermutlich eines davon geben, wahrscheinlich eine .reverse-Methode.“ Der Interviewer sagte: „Gut geraten.“
Es hat mir wirklich Spaß gemacht, ich ging mit dem Gefühl raus, ein paar Dinge gelernt zu haben, und die Gegenseite konnte sehen, wie ich über neue Probleme nachdenke.
Ich habe schon mehrfach alte Codebases ohne Dokumentation und ohne Hilfe vom Team debuggt. Systeme, bei denen niemand von den ursprünglichen Entwicklern mehr da ist und es keine oder keine auffindbare Dokumentation gibt, existieren tatsächlich. Daher ist dieses Beispiel nicht besonders gut. Die Fähigkeit, ein Programm zu debuggen, Request-Flows nachzuverfolgen und zu sehen, was passiert, ist eine gute Fähigkeit.
Der wirklich schlechte Punkt an diesem Beispiel ist allerdings, dass es Entwickler in bestimmte Technologien in Schubladen steckt. Wenn man eine Legacy-PHP-Anwendung hat, filtert man damit Java-, Python-, Ruby- oder Go-Entwickler heraus, die diese Debugging-Fähigkeit hätten, aber langsam wären, weil sie PHP nicht kennen. Obwohl sie nach ein paar Monaten praktischer PHP-Arbeit vielleicht sogar stärkere Entwickler wären.
Ich stimme zu, dass eine „4-Stunden-Aufgabe“ leicht auf 8, 10 oder mehr Stunden anwächst, wenn man ein gutes Ergebnis liefern will. Die angegebene Zeit lässt sich leicht ausnutzen, sodass jemand mit mehr verfügbarer Zeit wie der bessere Kandidat aussehen kann.
Wann ich zuletzt eine alte Codebase ohne Dokumentation und ohne Teamhilfe debuggt habe? Diese Woche jeden Tag.
Was die Dokumentation betrifft: Der Code wurde zuletzt im Juni aktualisiert, die Doku zuletzt im Januar 2022.
Was das Team betrifft: Von der Hälfte, die vor zwei Jahren nicht entlassen wurde, sind alle zu besseren Orten gegangen. Natürlich gibt es ein Team, dem dieses Projekt gehört, aber es besitzt außerdem drei andere Projekte, und im letzten Jahr hat es hier vielleicht ein gutes Dutzend Zeilen beigetragen, davon waren 11 Zeilen Dependency-Updates.
Aussagen wie „Das ist, als würde man einen Ruby-Entwickler PHP debuggen lassen“ oder „Wenn für die Stelle eine bestimmte Technologie nötig ist, testet diese Technologie“ klingen wie von jemandem, der bei einer Coding Challenge durchgefallen ist.
Im Ernst: Unternehmen führen Recruiting-Praktiken selten einfach nur zum Spaß ein. Meist sind sie das Beste, was die kollektive Intelligenz dieser Gruppe hervorgebracht hat. Zu fordern, sie abzuschaffen, ohne zu verstehen, welches Problem sie lösen wollen, und ohne Alternativen vorzuschlagen, ist nicht produktiv.
Ich glaube, in der Softwareentwicklung erfinden wir das Rad zu oft neu, statt Praktiken aus anderen Berufen zu übernehmen. Schauen wir uns an, welche Einstellungsverfahren Bauingenieure durchlaufen, um die Hälfte des Gehalts von Softwareentwicklern zu bekommen, und integrieren wir das in unsere Praktiken. Dann werden wir alle glückliche Soldaten sein.
Ich halte es für sehr unwahrscheinlich, dass reflektiert wurde, was man damit eigentlich erreichen will. Man macht es einfach nach, weil andere es auch tun, und glaubt, dass irgendjemand irgendwo diesen Prozess mit Absicht entworfen hat.
Tech-Recruiting hat sich so sehr verirrt, dass es sich bestenfalls so anfühlt, als sei man bei einem lokalen Maximum gelandet.
Ich hatte eine sehr schlechte Erfahrung in einem Unternehmen, das überhaupt keine Coding-Tests gemacht hat. Es gab nur zwei bis drei Interviews.
Das Problem zeigte sich, als ich im Data-Engineering-Team zu arbeiten begann. Der Großteil des Stacks basierte auf Hadoop, Kubernetes, Ruby, Python und mehreren anderen Technologien, und ein grundlegendes Verständnis von Cloud Computing war nötig.
Die Berufserfahrung und Hintergründe waren jedoch so unterschiedlich, dass ich oft andere ausgleichen musste, statt die Arbeit zu machen, für die ich eingestellt worden war. Einige Kollegen konnten grundlegende Aufgaben wie das Paketieren eines Python-CLI mit Docker oder das Überprüfen von Hadoop-Jobs nicht erledigen, also musste ich viel Klebearbeit leisten, um das aufzufangen.
Am Ende bin ich gegangen. Nicht, weil ich mich für etwas Besonderes hielt, sondern weil ich es leid war, 80 % meiner Zeit damit zu verbringen, Leute zu unterstützen, die auf demselben oder einem höheren Level eingestellt worden waren. Ich gebe zu, dass die Einstellungspraktiken dieses Unternehmens sehr schlecht waren, aber irgendeine Form grundlegender technischer Prüfung ist nötig.
Eine weitere wichtige Frage ist, ob man denselben Personen dieselben Dinge wiederholt erklären musste. Etwas nicht zu wissen ist akzeptabel, aber nicht lernen zu wollen ist schwer zu akzeptieren.
Das Interessante an Aufgaben-Tests ist, dass es einen moral hazard gibt: Selbst wenn gesagt wird „verbringen Sie nur X Stunden damit“, wird man dazu verleitet, mehr Zeit zu investieren. Wenn das Unternehmen nachfragt, entsteht außerdem ein Anreiz, über die tatsächlich aufgewendete Zeit zu lügen.
Ich habe mehrmals Aufgaben abgegeben, bei denen ich betont habe, mich an die empfohlene Zeit zu halten, und das Problem angemessen gelöst habe; im Folgeinterview wurde ich dann dafür kritisiert: „Warum haben Sie X nicht implementiert?“
In diesem Zusammenhang sind allzu offene Aufgaben-Tests schlechte Aufgaben. Denn sie begünstigen Menschen, die mehr Freizeit haben und dadurch gründlicher arbeiten können. Grüße an den Data-Science-Aufgaben-Test, der als Endergebnis eine PowerPoint-Präsentation verlangt.