Erfahrungsbericht eines Entwicklers, der bei einem Take-Home-Interview für Kagi Search abgelehnt wurde
(bloggeroo.dev)- Ein Entwickler implementierte im Backend-Bewerbungsprozess von Kagi Search rund eine Woche lang in Vollzeit einen E-Mail-Client mit Terminal-Anmutung, wurde nach der Einreichung jedoch ohne Folgeinterview abgelehnt
- Die Aufgabe war offen formuliert: TUI oder Web-App, grundlegendes Lesen und Senden von E-Mails, Fake-Backend oder wahlweise IMAP/POP/JMAP. Umfang der Umsetzung und Bewertungskriterien musste der Bewerber selbst einschätzen
- Der Bewerber schickte vorab einen detaillierten Plan mit Go-Web-App, AWS ECS Fargate, SSL, Postmark, Login, Pulumi, Pocketbase, TEMPL und mehr, doch Kagi nannte keine konkreten Kriterien für ein Bestehen
- Auf die nach der Absage erbetene Rückmeldung kam nur die Antwort, es habe „einfachere und stärkere Einreichungen“ gegeben; in dieser Phase gebe man üblicherweise kein individuelles Feedback
- Die Erfahrung zeigt, dass unbezahlte Take-Home-Aufgaben und zeitbegrenzte Coding-Puzzles stärker die verfügbare Zeit und Lebensumstände von Bewerbern testen können als ihre tatsächlichen Engineering-Fähigkeiten
Bewerbung und Erhalt der Aufgabe
- Der Bewerber schickte seinen Lebenslauf für eine Backend-Rolle bei Kagi Search; die Rollenzusammenfassung enthielt unter anderem folgende Fähigkeiten
- Erfahrung im Aufbau von Backend-Systemen
- Kenntnisse in Go
- Verständnis für Skalierung und Wartung von Backend-Systemen
- Fähigkeit zur Zusammenarbeit mit SREs und Teammitgliedern
- Verständnis von Containerisierungstechnologien wie Docker
- Anschließend erhielt er von Kagi eine E-Mail mit der Bitte, als nächsten Schritt das Kagi Developer Assessment abzuschließen
- Die Aufgaben-URL wurde über HackMD übermittelt
- Darin stand, dass man die Lösung nach seiner Rückmeldung prüfen und bei Bestehen in einem Folgeinterview den Ansatz und die Lösung besprechen werde
Anforderungen der Aufgabe und offene Bewertungskriterien
- Ziel der Aufgabe war es, einen „minimalen E-Mail-Client mit Terminal-Anmutung“ zu bauen
- Die Umsetzungsbedingungen waren relativ weit gefasst
- Der E-Mail-Client konnte als Terminal-TUI oder als Web-App umgesetzt werden
- Grundfunktionen zum Lesen und Senden von E-Mails waren erforderlich
- Ein Fake-Backend (DB, In-Memory usw.) oder ein echtes IMAP/POP/JMAP-Backend war möglich
- Rich-Text-Nachrichten waren ausgeschlossen; es musste nur Klartext verarbeitet werden
- Es wurde erklärt, dass nicht nur Coding-Fähigkeiten bewertet würden, sondern auch die Fähigkeit, mit Mehrdeutigkeit und offenen Problemen umzugehen, wie sie für R&D-Projekte wie Kagi Labs nötig sei
- Für die Ergebnisse galten folgende Bedingungen
- Umsetzung auf eine Weise, die die Fähigkeiten als Entwickler zeigt
- Das fertige Projekt in ein GitHub-Repository hochladen und irgendwo deployen, damit es leicht getestet werden kann
- Ein README mit Einrichtungsschritten verfassen
Kommunikation mit dem Recruiting
- Der Bewerber hielt die Anforderungen für zu breit und schickte dem zuständigen Recruiter Fragen
- Dieser antwortete, es gebe viele Kandidaten; manche setzten nur die Basis um, andere lieferten zusätzliche Funktionen, hervorragende Dokumentation, Erläuterungen zu Entscheidungen, ein Demo-Deployment und zukünftige Pläne
- Auf die Frage, welche Zusatzfunktionen besonders positiv bewertet würden, antwortete der Recruiter, „das sei Teil der Bewertung“; man wolle sehen, welche Zusatzfunktionen den Kandidaten einfielen
- Der Bewerber entschied sich, vor dem eigentlichen Coding einen detaillierten Umsetzungsplan für das gesamte Ergebnis zu verfassen und zu schicken
- Er erwartete, dass ihn eine angenommene Idee einem Telefoninterview oder einem Jobangebot näherbringen könnte
- Rückblickend kam er zu dem Schluss, dass seine Bemühung, die Bedingungen vorab passend zu treffen, für den Recruiter keine große Bedeutung hatte
Vom Bewerber vorgeschlagene Umsetzung
- Im Zentrum des Vorschlags stand ein E-Mail-Client auf Basis einer Go-Web-App
- Deployment auf AWS
- Einsatz von ECS Fargate
- SSL/HTTPS
- Integration mit einem Anbieter für E-Mail-Versand
- Authentifizierung über einen Login-Screen
- Formularbasierter E-Mail-Versand
- Anzeige eingehender E-Mails in der UI
- Im Vorschlag war als Liefertermin Sonntag, der 30. März, EOD genannt; das sei zwei Werktage später als der Zeitpunkt zwei Wochen nach der ersten E-Mail
- Die technische Auswahl sah wie folgt aus
- Go-Backend: Nutzung von Pocketbase und TEMPL
- Infrastructure as Code: Nutzung von Pulumi, TypeScript SDK gewählt
- E-Mail-Service-Provider: Nutzung von Postmark
- UI: Paginierung für gesendete und empfangene E-Mails, Login-Screen, zwei Demo-Konten
- Die Begründung für diese Entscheidungen zielte eher darauf ab, Rolle und Bewertungsumfang breit zu demonstrieren
- Obwohl es eine Backend-Rolle war, könne ein zusätzliches Web-Frontend die Breite der Web-Technologien zeigen
- Eine Datenbank sei für eine Backend-Rolle relevant
- AWS und Deployment per Infrastructure as Code seien mit Diskussionen über IaC, Docker, Networking und Resilienz verbunden
- Ein E-Mail-Service wie Postmark reduziere die Komplexität einer IMAP/POP-Integration, während die Funktionalität erhalten bleibe
- Der Bewerber fragte, „welche Reaktion er von Kagi erwarten könne, wenn er das fertigstellt“, doch die Antwort blieb auf dem Niveau von „sehr interessant, wir freuen uns auf die Einreichung“
Einreichung und Absage
- Der Bewerber setzte alles Vorgeschlagene um und erklärte, die gesamte Arbeit habe eine Woche in Vollzeit gedauert
- Die Demo der Webanwendung lud er auf YouTube hoch, den Code veröffentlichte er samt Dokumentation auf GitHub
- Nachdem er eine automatische Absage erhalten hatte und um Feedback bat, antwortete Kagi wie folgt
- In dieser Phase gebe man normalerweise kein Feedback
- Es habe einfachere und stärkere Einreichungen gegeben, daher werde man mit diesen Kandidaten weitermachen
- Für jede Position gebe es viel Interesse und viele Bewerbungen, weshalb der Auswahlprozess sehr wettbewerbsintensiv sei
- Er solle künftige Positionen im Blick behalten und sich erneut bewerben
Offene Fragen nach der Absage
- Der Bewerber ist der Meinung, Kagi hätte es sagen können, wenn eine „einfachere Lösung“ gewünscht gewesen wäre, als er am 18. März den Vorschlag schickte
- Wenn die Lösung nicht zur Rolle gepasst hätte, hätte man das seiner Ansicht nach ebenfalls bereits in der Vorschlagsphase am 18. März beurteilen können
- Er schreibt, dass die Stellenanzeige zum 13. Mai, anderthalb Monate nach der Absage, weiterhin online war
- Er räumt ein, dass das Unternehmen mit derselben Anzeige mehrere Rollen besetzen könne
- Dennoch hält er es für schwer, dies als einen Wettbewerb zu betrachten, bei dem der „Siegerplatz bereits besetzt“ war
- In den ursprünglichen Aufgabenhinweisen sei ein Demo-Deployment wünschenswert, aber nicht zwingend gewesen; nach der Einreichung seien die Hinweise so geändert worden, dass das Deployment eine strikte Anforderung wurde
Vorschläge für ein besseres Auswahlverfahren
- Der Bewerber kritisiert, dass unbezahlte Aufgaben eine große Belastung für Jobsuchende darstellen, insbesondere für Menschen ohne Beschäftigung, deren Ersparnisse schrumpfen
- Auch LeetCode-artigen Interviews steht er negativ gegenüber
- Bei einer jüngsten Clojure-basierten Rolle habe er eine „coin change“-Aufgabe gelöst; innerhalb von 50 Minuten habe etwa die Hälfte der Tests bestanden, aber für die Implementierung des Backtracking-Teils habe die Zeit nicht gereicht
- Als Alternative schlägt er Live-Code-Reviews vor
- Diese könnten sowohl asynchron als auch synchron ablaufen
- Dabei ließen sich Probleme und Themen eines realen Softwareprojekts verbal durchgehen
- Das könne das Wissen erfahrener Software Engineers besser sichtbar machen
- Live-Coding an sich lehnt er nicht vollständig ab, ist aber der Ansicht, dass die Fähigkeit, in 50 Minuten knapsack zu lösen, wenig mit alltäglicher Engineering-Arbeit zu tun hat
- Er empfiehlt, Rollen abzulehnen, die unbezahlte Arbeit dieser Art verlangen, sofern man sich nicht in einer verzweifelten Lage befindet
1 Kommentare
Meinungen auf Hacker News
Aus Sicht eines Recruiters mag ich Take-Home-Aufgaben aus diesen Gründen nicht. Sie verschwenden die Zeit aller Beteiligten; als letzter Schritt unmittelbar vor der Einstellung sind sie in Ordnung, als Filter aber ungeeignet.
Trotzdem wirken Kompetenz und Ernsthaftigkeit klar erkennbar; ich spiele hier nur aus einer anderen Perspektive den Advocatus Diaboli.
„Baue einen terminalartigen E-Mail-Client, den wir mit ein paar Kunden als Alpha testen können“ ist eine vernünftige Bitte an einen Engineer in einem Early-Stage-Startup, und die Details müssen zwangsläufig dem Engineer überlassen werden.
Besonders die Frage „Ich möchte wissen, welche Reaktion ich von Kagi erwarten kann, wenn ich bis zur Fertigstellung weitermache“ war nicht gut. Wenn man Hunderte bis Tausende Einreichungen sichten muss, gibt es keine Möglichkeit, eine verbindliche Antwort zu geben.
Wenn der Versuch, Anforderungen zu klären, unerwünschtes Verhalten ist, ist das nicht viel anders, als Leute eine Zahl zwischen 1 und 10 wählen zu lassen und diejenigen auszusortieren, die falsch liegen.
Eine Take-Home-Aufgabe soll Fähigkeiten zeigen; wenn es keine konkrete Anleitung gibt, wie soll man dann erraten, wie viel man zeigen soll?
Feinschliff ist nur dann schlecht, wenn er die Auslieferung verhindert; jemanden abzulehnen, weil er „zu sehr poliert“ hat, fühlt sich an, als würde man ihn ablehnen, weil er seine Arbeit zu gut gemacht hat.
Solche vagen Tests wirken am Ende eher wie eine andere Methode, Menschen unter dem Vorwand mangelnder kultureller Passung auszusortieren.
Umgebungen nach dem Motto „erst bauen, später reviewen“ gehörten in meiner Laufbahn zu den toxischsten, und es ist das Schlimmste, wenn man Tage in ein Feature steckt und dann erfährt, dass es gar nicht gewünscht ist.
Deshalb ist es nahezu Branchenstandard bei Projekt-Launches, ein Feature schriftlich zu beschreiben und sich absegnen zu lassen; dieser Bewerber hat Software-Praktiken befolgt, denen gesunde Organisationen folgen.
So sehe ich das auch als Hiring Manager in einem Unternehmen mit mehr als 1.000 Engineers.
Natürlich sollte man sie nur Bewerbern geben, bei denen das Ergebnis einen Teil der Entscheidung über Zu- oder Absage ausmacht.
Bei meiner letzten Jobsuche bekam ich so eine breit angelegte Aufgabe, und obwohl ich für die Stelle überqualifiziert war, wurde ich abgelehnt, weil ich nicht erraten konnte, welche Teile bewertet würden.
Es sieht unwahrscheinlich aus, dass ich künftig ohne Empfehlung eine Stelle bekomme, aber seitdem habe ich große Vorbehalte, solche Aufgaben zu erhalten oder zu stellen.
Diese Aufgabe sollte testen, ob man ein paar Fragen stellt, Annahmen notiert und sich dann selbstbewusst in eine unklare Aufgabe stürzt und etwas baut.
Wahrscheinlich spielte der Code nach dieser E-Mail keine Rolle mehr; das Unternehmen hätte an diesem Punkt abbrechen sollen, damit der Bewerber keine Zeit mit der Implementierung der Aufgabe verschwendet.
Als ich den Code und das Demo-Video sah, war mein erster Gedanke: „Für eine zweiseitige Web-App hat er eine Woche gebraucht, und selbst grundlegendste E-Mail-Funktionen wie das Öffnen einer Nachricht fehlen.“
Den Anforderungen nach hatte sich diese Person als „Email Backend Engineer“ beworben, nutzte für das eigentliche E-Mail-Backend aber Drittanbieterprodukte wie Postmark und Turso.
Es fehlen grundlegende Elemente wie Plain-Text-E-Mail-Formatierung, Anzeige, Ordner sowie mindestens Posteingang und Gesendet; dafür sind optionale Funktionen wie Login-Screen, Admin-Seite und Backend-Framework enthalten.
In der Backend-Datenbank gibt es nicht einmal eine Map der E-Mail-Header.
Er mag ein ausgezeichneter Engineer sein, aber für diese konkrete Position wirkt er nicht passend, und ich hätte ebenfalls abgesagt.
In der ursprünglichen Ausschreibung stand als Titel „The project is to build a minimal, terminal-inspired email client“, und es war ausdrücklich erwähnt, dass man sich von bestehenden Terminal-E-Mail-Tools wie aerc, mutt und himalaya inspirieren lassen solle.
Das wirkt, als hätte er die Anforderungen schlicht nicht richtig gelesen, also nicht einstellbar.
Beides scheint ausreichend erfüllt zu sein.
Sich von bestehenden Tools inspirieren zu lassen ist subjektiv, und bei einer Aufgabe für eine Backend-Position hätte er wahrscheinlich nicht gedacht, dass es die beste Demonstration seiner Fähigkeiten ist, Zeit in die Benutzeroberfläche zu stecken.
Ich verstehe, dass das nicht immer realistisch ist, wenn Recruiter bei beliebten Positionen Hunderte Leute prüfen müssen, aber genau deshalb sind Take-Home-Aufgaben schlecht.
Bewerber können Stunden ihres Lebens verschwenden, ohne irgendetwas mitzunehmen; deshalb sollten beide Seiten die Zeit des jeweils anderen respektieren.
Ich verstehe, dass die Antwort sehr kurz und wenig hilfreich war, aber in den Anforderungen stand eindeutig, dass ein terminal-inspirierter E-Mail-Client gebaut werden sollte.
Wenn man sich das geteilte Video https://www.youtube.com/watch?v=yY1sVXMkP_o ansieht, wirkt es wie eine gewöhnliche E-Mail-Web-App ohne besonderen Terminal-Bezug.
Wenn entweder ein echtes TUI oder eine Web-App gewünscht war, hätte vermutlich auch die Web-App terminalartig sein sollen.
In den vollständigen Anforderungen steht unter „Inspiration“ ausdrücklich, man solle sich von bestehenden Terminal-E-Mail-Tools wie „aerc, mutt, himalaya“ inspirieren lassen.
Trotzdem nannte der Prompt ausdrücklich andere Terminal-Clients als Inspiration.
Außerdem verändert die Anforderung eines Terminal-Clients den Bewertungsgegenstand erheblich. E-Mail-Web-UIs sind seit Langem ein bekanntes Feld, aber die User Experience von Terminal-Clients ist noch kein vollständig „gelöstes“ Gebiet.
Wahrscheinlich hatte die Bewertungsmatrix einen großen Anteil an Designentscheidungen für Terminal-Clients, die die Einreichung des Bewerbers überhaupt nicht behandelte.
Aufgabenbasierte Bewertungen können im Interviewprozess wertvoll sein, brauchen aber unbedingt ein Zeitlimit. In 2 bis 3 Stunden erhält man genug Informationen; alles darüber hinaus filtert eher Berufseinsteiger ohne Angehörige, Hobbys oder Verpflichtungen heraus.
Hätte man auf 3 Stunden begrenzt, hätte der Bewerber im schlimmsten Fall nur 3 Stunden verloren; wahrscheinlicher ist, dass er einen ganz anderen Vorschlag oder eine andere Lösung passend zu dieser Zeit abgegeben hätte.
Bewerber sollten außerdem klären, ob „irgendeine Antwort“ oder eine gute Antwort erwartet wird.
Manche Aufgaben prüfen nur, ob ein Test-Bundle besteht, und die Vorgehensweise ist egal; andere bevorzugen besseren Code, auch wenn nur 80 % der Anforderungen erfüllt sind. Ich habe gesehen, wie Bewerber in beiden Fällen falsch lagen.
Solche Aufgaben filtern Menschen heraus, die viel Zeit in ein Projekt verschwenden können, und lassen gerade die Vielbeschäftigten außen vor — also die, die man vermutlich haben möchte.
Wenn ich Data-Engineering-Kompetenzen einstelle, gebe ich eine einfache ETL-Aufgabe: Daten aus einer ZIP-Datei extrahieren, transformieren und in irgendeine Datenbank laden.
Ich lasse Unklarheiten bestehen und baue versteckte Elemente in den Datensatz ein, etwa unerwartete Null-Werte oder falsch formatierte CSVs, um die Ausführungskompetenz zu sehen.
Ich setze ein Limit von 4 Stunden, gebe aber keine Hinweise dazu, was bei Zeitmangel zu tun ist; das ist ein guter Vorschlag.
In einem anschließenden Gespräch sehen wir uns den Code gemeinsam an und fragen nach Verbesserungen, etwa „Was, wenn der Datensatz nicht komplett in den Arbeitsspeicher passt?“, und genau dort findet die eigentliche technische Bewertung statt.
Da nicht garantiert ist, dass alle Bewerber dieselbe Zeit aufgewendet haben, wird es zu einem spieltheoretischen Problem, und Bewerber verlieren in der Regel auf die eine oder andere Weise.
In vielen Fällen ist die richtige Antwort, mehr Zeit zu investieren, eine sehr ausgefeilte, aber nicht zu ausgefeilte Lösung zu bauen und dann so zu tun, als habe man das Zeitlimit eingehalten.
Selbst 3 Stunden sind für einen Bewerber, der nicht weiß, ob er überhaupt mit der nächsten Person sprechen wird, eine sehr lange Zeit.
In einem einstündigen Interview kann man eine Programmieraufgabe durchführen und sicherstellen, dass der Bewerber keine zusätzliche Zeit verschwendet.
Wenn der Bewerber möchte, kann man ihn später eine verbesserte Antwort schicken lassen; normalerweise hat man seine Fähigkeiten zu diesem Zeitpunkt bereits positiv eingeschätzt und kann sagen: „Wenn Sie möchten, gern, aber Sie sind bereits weiter.“
Wenn man den Zeitaufwand von Bewerber und Interviewer gleich hält, respektiert man die Zeit des Bewerbers so, wie man die eigene respektiert.
Wenn ein Hiring Manager die Zeit von Bewerbern nicht respektiert, wirkt es auch unwahrscheinlich, dass er die Zeit von Mitarbeitern respektiert.
Ich hatte kürzlich mehrere Interviews, und sie ähnelten dieser Erfahrung sehr. Ich lieferte eine hervorragende Lösung für die Aufgabe ab, wurde aber ohne Diskussion des Ergebnisses abgelehnt.
Da ich als einstellende Person mehrfach Take-Home-Verfahren durchgeführt habe, bin ich überzeugt: Wenn man jemanden zu Hause eine Aufgabe machen lässt, muss man anschließend über den Code sprechen.
Wenn man eine Take-Home-Aufgabe erhält, sollte man unbedingt klären, ob es unabhängig vom Bewertungsergebnis ein Folgegespräch gibt; falls nicht, empfehle ich dringend, diese „Hausaufgabe“ nicht zu machen.
Ehrlich gesagt ist das Niveau vieler Hiring-Teams niedrig, sodass eine gute Lösung umzusetzen sogar ein Nachteil sein kann. Man kann aus dem frustrierenden Grund abgelehnt werden, dass das Hiring-Team diesem Niveau nicht gewachsen ist.
Ich war früher Nutzer von Kagi, erwäge aber wegen dieser Sache, mein Konto zu kündigen. Wenn man keine Zeit hat, mit einem Bewerber zu sprechen, sollte man ihm von vornherein keine Arbeit geben.
Eine Take-Home-Aufgabe erfordert nicht nur von Bewerbern, sondern auch von den Durchführenden und dem Hiring-Team erheblichen Aufwand; wenn ein Projekt geprüft wurde, ist es vernünftig, auf Anfrage Feedback oder eine Antwort zu erwarten.
Es gibt allerdings auch die Realität: Wenn es pro Stelle 20 hervorragende Kandidaten gibt, werden viele fähige Menschen abgelehnt. Das bedeutet nicht, dass sie unzureichend waren oder „gescheitert“ sind.
Wenn man rechtlich erklären muss, warum A eingestellt wurde und B nicht, ist es schwer zu sagen: „Beide waren hervorragend, aber wir haben einen ausgewählt“; am Ende sucht man leicht nach Mängeln, die gar nicht wirklich existieren.
In der US-Unternehmenskultur habe ich dieses Muster oft gesehen, und Kagi sitzt in Palo Alto.
Bei einer Aufgabe durchzufallen ist in Ordnung, aber die Zeit einer Person zu verschwenden, ohne irgendetwas zurückzugeben, ist schwer akzeptabel.
Viele Unternehmen, auch beliebte Startups, handhaben das gut.
Das Ergebnis ähnelte kaum einem „minimalen terminalartigen E-Mail-Client“ und scheint die als Inspiration genannten Tools vollständig ignoriert zu haben.
Wenn die Anforderungen so grundlegend missverstanden wurden, hätte auch ich keine Zeit in eine Diskussion investiert.
Das ist ein typischer Fall von versteckten Kontext falsch gelesen. Das Unternehmen wollte jemanden, der unabhängig seine eigene Arbeit und seine Ziele definieren kann.
Die Unschärfe der Aufgabe war nicht dafür gedacht, sie in mehreren E-Mails auszufragen, sondern war eine leere Leinwand, um zu zeigen, wie man eine ziemlich breit angelegte Aufgabe nimmt, den Problemraum selbst erkundet und ein Ergebnis liefert.
Wenn man an einer Universität arbeitet, erinnert das sehr an Studierende, die eine Aufgabe nicht verstehen, eine unerwartete Note bekommen und sich dann beschweren.
In einer Interviewsituation, in der man beeindrucken möchte, gibt es nicht viele, die es wagen, „faul“ zu sein.
Wenn ein Unternehmen auf schnelle Experimente, Releases und einen prototypenorientierten Ansatz setzt, passen manche Leute wirklich nicht dazu, und das ist für alle schlecht.
Vermutlich hätte ein anderer Bewerber zehn Minuten darüber nachgedacht, was sich in 60 Minuten machen lässt, HTTP-Auth und ein Formular genutzt, es mit einem kleinen Go-Backend zum Laufen gebracht und es mit einer kurzen E-Mail geschickt. So jemand hätte im Prozess wahrscheinlich deutlich besser ausgesehen.
Man weiß nicht, ob es ein Wegwerf-Prototyp ist, ob echte Nutzer es sehen werden, ob man für eine unfertige User Experience kritisiert wird oder ob sie einfach nur irgendetwas sehen wollen.
Am Ende wird daraus eine Übung darin, den Geschmack des Reviewers zu erraten.
Umgekehrt wird es auch Leute geben, die scheitern, weil sie Anforderungen nicht beharrlich weiter geklärt haben – dabei ist das eine wichtige Tugend für Engineers.
Das Leben ist nicht fair, aber von Hiring Managern erwartet man mehr, und deshalb wird man immer wieder enttäuscht.
Vielleicht hat der Student kein Gedankenlesen beherrscht und die Aufgabenstellung war schlecht geschrieben, weshalb er sie missverstanden hat.
Gute Lehrkräfte sorgen dafür, dass möglichst viele Studierende verstehen; schlechte tun das Gegenteil.
Bei den besten Lehrkräften musste man die Note nicht anzweifeln, weil die Bewertungskriterien von Anfang an transparent waren.
Wenn viele Studierende verwirrt sind, könnte der gemeinsame Nenner die Lehrkraft sein.
Nur weil buddhistische Mönche durch das Lösen rätselhafter Koans lernen, heißt das nicht, dass man dieselbe Methode auf Studierende anwenden sollte, die Studiengebühren zahlen.
Da es so aussieht, als hätte der Autor selbst gepostet, erkläre ich einmal den Kontext der Reaktionen, die er bekommen hat. Ich habe früher bei Kagi gearbeitet und einen ähnlichen Take-home-Test durchlaufen.
Damals war das Unternehmen sehr klein, Vlad prüfte Bewerber persönlich, und solche Aufgabenprojekte wurden eingesetzt. Heute ist das Unternehmen größer, sodass er es vielleicht nicht mehr selbst anschaut, aber der Kern scheint ähnlich zu sein.
Wenn man mit Vlad spricht, ist er fast der Archetyp eines Hacker-News-Kommentators, und das Interview ist eher ein Vibe-Check, ob man wie ein vernünftiger Mensch wirkt.
Ihm ein langes Designdokument zu schreiben, in dem steht, man werde „Galactor verwenden, es florp-ready machen und fleemen“, ist so ziemlich das Gegenteil von cool.
Wenn die Aufgabe ein „terminalartiger E-Mail-Client“ ist, wäre ein nahezu perfektes Projekt wohl etwas, bei dem jede Funktion Keyboard-Shortcuts hat und in einem Absatz erklärt wird, dass das Zeichnen eines Frames nie länger als 2 ms dauert.
Der Interviewer könnte den Eindruck gehabt haben, dass der Bewerber zu enterprise-mäßig denkt, um bei Kagi zu arbeiten.
Ob diese Auswahlmethode gut ist, ist natürlich eine andere Frage. Vlad will Leute, die wie er denken, und bei solchen Interviews gibt es viele lange diskutierte und erforschte Probleme.
Wenn man das aber versteht und die Kapazität hat, so einen Prozess mitzumachen, ergibt die Aufgabe tatsächlich Sinn. Kagi hätte diesen Punkt besser vermitteln können.
Schade, dass so viel Zeit verschwendet wurde; hoffentlich findet er einen Ort, der besser zu seiner Arbeitsweise passt.
Um neue Einsichten in ein Problem zu bringen, braucht es Vielfalt im Denken. Wenn alle gleich denken, besteht die Gefahr, dass alle feststecken, sobald eine Person feststeckt.
Das wirkt wie ein häufiges Problem bei Startups und könnte ein Hinweis darauf sein, warum 9 von 10 Startups scheitern.
Das ist etwas anderes, als Fähigkeiten zu testen. Hier muss man bei Metriken gut abschneiden, die einem nicht genannt wurden, um weiterzukommen.
Eine Aufgabe nach dem Motto „Codiere einfach irgendwas, du musst ja gut mit Unklarheit umgehen können“ zu stellen, ist kaum etwas anderes, als zu erwarten, dass man errät, was ich im Kopf habe.
Das ist eine sehr rücksichtslose Art, mit Menschen umzugehen, und es sendet auch kein gutes Signal über Vlad.
Soll ich dafür die Social-Media-Profile der Leute im Unternehmen durchforsten?
Wenn sie am Ende nur ihre Neugier befriedigt haben, indem sie mich „weitermachen“ ließen, obwohl ich schon ausreichend gezeigt hatte, dass ich nicht cool bin, dann hoffe ich, dass sie so behandelt werden, wie sie andere behandeln.
Danke für die Erklärung, keine bösen Gefühle. Ich wünschte nur, ich hätte so etwas früher gelesen.
Künftig sollte man Jobs mit „Take-home“ am besten als Jobs für die coolen Kids einordnen. Dann können langweilige, aber erfahrene Engineers Druck auf Unternehmen ausüben, ihre Methoden zu ändern, wenn sie unsere Arbeit tatsächlich wollen.
Wenn ein Unternehmen sie nicht ändert, kann man daraus ableiten, was für eine Art Unternehmen diese Rolle „anbietet“.
Ich habe mir den Code angesehen, um zu sehen, wie ich ihn als Reviewer bewerten würde.
Bei der ersten Datei, die ich geöffnet habe, wäre ich bis hier gekommen und hätte aufgehört: https://github.com/Sleepful/mymail/blob/main/app/router/page...
Der erste Kommentar ist sehr seltsam, weil er nichts mit der Aufgabe zu tun hat, und wirkt, als sei er aus einem Blogbeispiel kopiert. Dass er trotzdem stehen geblieben ist, zeigt jedenfalls mangelnde Sorgfalt.
Die Formulierung in der zweiten Zeile ist nicht konsistent mit der dritten Zeile.
An dieser Stelle hätte ich das Review beendet. Das ist mangelnde Liebe zum Detail und zeigt nicht die Fähigkeit, klar zu denken.
Zurück kam dann nur eine leere Absage-Mail.
In dieser Situation fällt es mir schwer zuzustimmen, dass ich mehr Zeit in Code-Kommentare hätte investieren sollen.
Ich möchte das aus Sicht eines Engineering-Interviewers sagen: Ich mag weder LeetCode noch Take-Home-Aufgaben. Beides kostet viel Zeit und liefert wenig Erkenntnis.
Trotzdem hätte ich die Person in diesem Fall vermutlich ebenfalls abgelehnt. Kagi Search ist ein Startup, und solche Unternehmen suchen meist nach pragmatischen Optimisten, die Tiefe und Breite ausbalancieren können.
Ich hatte früher einmal einen Kollegen, der Input gesammelt hat, sich dann tagelang eingeschlossen und mit einer Lösung wieder herauskam — nur waren die Anforderungen in der Zwischenzeit geändert worden. Für niemanden war das eine angenehme Erfahrung.
Ich hasse Take-Home-Verfahren wirklich.
Die Formulierung „Dieses Projekt testet nicht nur Coding, sondern auch die Fähigkeit, mit Mehrdeutigkeit und offenen Problemen umzugehen“ klingt in der Praxis wie: a) Die Aufgabe ist so schlecht entworfen, dass nicht einmal ein Bewertungsraster erstellt wurde, oder b) die Arbeitsumgebung ist so chaotisch, dass keinerlei Spezifikationen oder Anforderungen klar definiert werden.
Außerdem widersprechen sich die Anweisungen „zeige dein technisches Können“ und „liefere eine pragmatische, funktionierende Lösung“. Eine gute, einfache Lösung ist nicht spektakulär.
Dass jemand HTTP-Requests bauen und eine einfache CRUD-Bearbeitungsmaske erstellen kann, sagt fast nichts aus. Auch AI-Tools erzeugen so etwas schnell in ziemlich ordentlicher Qualität.
Was ich sehen möchte, ist, wie ein Engineer unbequeme Geschäftslogik implementiert.
Wird daraus eine Million verschachtelter
ifs und Kommentare à la „hier gibt es Drachen“, oder findet die Person passende Patterns und schreibt Code, den man lesen und nachvollziehen kann?Das ist in der realen Arbeit deutlich wertvoller, liefert im Interview ein stärkeres Signal, ist für AI schwerer korrekt zu treffen und kostet weniger Zeit.
Eine gute, einfache Lösung zu bauen, kann gerade die Art sein, Kompetenz zu zeigen.
Das sehe ich als einen großen Teil der Rolle eines Senior Software Engineers.
Dieses Format ist vielleicht nicht der beste Weg, das zu testen, aber „wir wollen sehen, ob du mit Mehrdeutigkeit umgehen kannst“ heißt nicht, dass alles mehrdeutig ist.
Es kann bedeuten, dass jede Aufgabe den Weg von „unklaren Anforderungen“ zu „klarer Spezifikation“ durchlaufen muss.