Meine Erfahrung, nach einem aufgabenbasierten Bewerbungsgespräch bei Kagi Search abgelehnt worden zu sein

 (bloggeroo.dev)
4 Punkte von GN⁺ 2025-05-16 | 1 Kommentare | Auf WhatsApp teilen
  • Betont werden die Ineffizienz von Take-home Assignments in Vorstellungsgesprächen für Softwareentwickler und das Problem der Zeitverschwendung auf Bewerberseite
  • Im Bewerbungsprozess bei Kagi Search wurden übermäßig weit gefasste und vage Aufgabenanforderungen erlebt
  • Zu einem vorgeschlagenen konkreten Umsetzungsplan wurde das Fehlen von klarem Feedback durch den Manager sowie eine ineffiziente Kommunikation erlebt
  • Nach der Einreichung eines mit großem Aufwand entwickelten Projekts wurde die Absage ohne klare Begründung und mit veränderten Maßstäben als unangemessen empfunden
  • Es werden Alternativen für bessere Einstellungsprozesse geteilt (z. B. Live-Code-Reviews) sowie das Problem überzogener Anforderungen bei aufgabenbasierten Bewerbungsgesprächen aufgezeigt

Vorwort

  • Ein Take-home Assignment ist ein Bewertungsverfahren in Vorstellungsgesprächen für Softwareentwickler, bei dem Bewerber eine Aufgabe erhalten und diese als Code implementieren und einreichen müssen
  • Dieser Beitrag möchte anhand der tatsächlich erhaltenen Aufgabe und der dabei gemachten Erfahrung bei einer Bewerbung bei Kagi Search, das ich für ein Unternehmen mit gutem Ruf hielt, auf die Unvernünftigkeit dieses Verfahrens und das Problem der Zeitverschwendung für Bewerber hinweisen

Bewerbung bei Kagi Search

  • Es wurde ein Lebenslauf für eine Backend-Entwickler-Position bei Kagi Search eingereicht
  • Die Anforderungen für diese Rolle waren wie folgt
    • Erfahrung beim Aufbau von Backend-Systemen
    • Fähigkeit, mit Go zu arbeiten
    • Erfahrung mit der Skalierung und Wartung großer Backend-Systeme
    • Fähigkeit zur Zusammenarbeit mit Teammitgliedern wie SREs
    • Verständnis von Container-Technologien wie Docker

Einführung in die Interview-Aufgabe und Anforderungen

  • Nach dem Bestehen der Unterlagenrunde wurde eine E-Mail mit Informationen zum Take-home Assignment erhalten
  • Thema der Aufgabe: „Implementierung eines minimalen, vom Terminal inspirierten E-Mail-Clients“
    • Wahlweise als Terminal-Anwendung oder Web-App
    • Grundlegende Funktionen zum Anzeigen und Senden von E-Mails
    • Freie Wahl eines gefälschten oder echten E-Mail-Backends (IMAP/POP usw.)
    • Nur die Verarbeitung von Plaintext-Nachrichten ist verpflichtend, Rich Text ist nicht erforderlich
    • Projekteinreichung: GitHub-Repository, bereitgestellte Deployment-Version, inklusive Installationsanleitung
  • Es fehlte an klaren Leitlinien, und der Umfang des Projekts war erheblich
  • Aufgrund des guten Rufs wurde dennoch entschieden, die Aufgabe zu bearbeiten

Kommunikation mit dem Manager

  • Bei Nachfragen zum klaren Umfang der Aufgabe und zu zusätzlichen Funktionen kam nur die vage Antwort, dass „es dem Bewerber freisteht, was zusätzlich eingebaut wird“
  • Bevor Zeit und Aufwand in die Aufgabe investiert wurden, wurde ein konkreter Umsetzungsplan (Proposal) geteilt und um eine Rückmeldung dazu gebeten, doch es erfolgte kein besonderes Feedback

Vorschlag und Plan für die Aufgabe

  • Umsetzungsplan:
    • Web-App auf Basis von Go
    • Deployment über AWS ECS Fargate mit SSL
    • Integration des E-Mail-Senderdienstes Postmark
    • Hinzufügen von Login- und Authentifizierungsfunktionen
    • Senden und Empfangen von E-Mails sowie Anzeige in der UI
  • Begründung für die Technikauswahl:
    • Einsatz verschiedener Technologien mit Bezug zur Backend-Rolle
    • Praktischer Systemaufbau durch den Einsatz von Infrastructure-as-Code-Tools
    • Umsetzung von Funktionen, die eher einem echten Dienst ähneln, statt nur einer simplen API-Integration
  • Wichtige Implementierungselemente:
    • Pocketbase (Backend/DB), TEMPL (Templates), Pulumi (IaC), Postmark (E-Mail-Dienst)
    • Implementierung von Paging, Login usw.
    • Stretch Goal: Stabilität durch Datensicherung und Wiederherstellung
  • Fazit: Es wurden vorab ausreichend Erklärungen und Begründungen geliefert, und es wurde eine klare Prüfung und Rückmeldung dazu erwartet

Antwort des Managers und Kommunikationsprobleme

  • Ohne konkrete Prüfung kam nur eine kurze Antwort wie „interessanter Vorschlag“
  • Es gab keinerlei Feedback zur Eignung des Vorschlags oder zu notwendiger Verbesserung
  • Aus Sicht des Bewerbers wirkte das wie ein Mangel an Respekt gegenüber der investierten Zeit und Mühe

Durchführung des Projektauftrags

  • Sowohl die vorgegebenen Anforderungen als auch die vorgeschlagenen Punkte wurden vollständig umgesetzt, und dafür wurde eine Woche in Vollzeit investiert
  • Es wurden sogar ein Demo-Video des Projekts, ein GitHub-Repository und ausführliche Dokumentation eingereicht

Absage und das dazu erhaltene Feedback

  • Nach Erhalt einer automatisierten Absage-E-Mail kam auf die Bitte um Feedback folgende Antwort:
    • „Es gab stärkere Einreichungen anderer Bewerber“, „der Wettbewerb bei der Einstellung ist intensiv“
  • Problematische Punkte
    1. Wenn einfache Lösungen bevorzugt wurden, hätte das von Anfang an kommuniziert werden können
    2. Wenn der Vorschlag unzureichend war, hätte an diesem Punkt Feedback gegeben werden können
    3. Auch nach der Absage war die Stellenausschreibung weiterhin online, weshalb es nicht als bloßer Wettbewerb, sondern als überzogene Anforderung unnötigen Zeitaufwands beurteilt wurde
    4. Nach Einreichung des Projekts wurden die Anforderungen noch weiter verschärft, sodass die eingereichte Lösung die Messlatte faktisch angehoben hat

Fazit und Problembewusstsein

  • Diese Vorgehensweise ist für viele Jobsuchende unangemessen und kann sogar reale Bedrohungen für den Lebensunterhalt mit sich bringen
  • Es wird betont, dass es notwendig ist, überzogene unbezahlte Aufgabenanforderungen abzulehnen oder offen zu kritisieren
  • Es sind bessere Einstellungsprozesse möglich, etwa Live-Code-Reviews als Ersatz für projektartige Aufgaben
    • Die Fähigkeit, reale Entwicklungsprobleme zu lösen, lässt sich durch asynchrone/synchrone Code-Reviews betrachten
    • Es wird auf die Kluft zwischen Leetcode-artigen Aufgaben und den Anforderungen der realen Arbeit hingewiesen
  • Es wird dazu aufgerufen, die Kultur von Erschöpfung auf Bewerberseite und unfairer Bewertung zu verbessern

Vorschläge für ein besseres Einstellungsverfahren

  • Es werden Alternativen wie Live-Code-Reviews vorgeschlagen, die die Fähigkeiten von Entwicklern sinnvoller bewerten
  • Statt timerbasierter Algorithmus-Rätsel sollte stärker auf tatsächliche Fähigkeiten und Problemlösungskompetenz fokussiert werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-16
Hacker-News-Kommentare
  • Ich hinterlasse ehrlich gesagt einen Kommentar aus der Sicht eines Einstellenden. Persönlich mag ich Take-Home-Aufgaben nicht. Solche Aufgaben verschwenden die Zeit aller Beteiligten. Wenn es die letzte Phase im Hiring-Prozess ist, kann ich es verstehen, aber sie zum Aussieben von Bewerbern zu verwenden, ist ineffizient.
    1. Es kamen viel zu viele Fragen. Ein Teil der Aufgabe besteht darin, in Unklarheit Urteilsvermögen einzusetzen und das Problem zu lösen. Nach den gegebenen Bedingungen hätte es gereicht, ein oder zwei Tage zu investieren und etwas auf dem Niveau eines einfachen lokalen Projekts zu bauen.
    2. Das Schreiben und Teilen des Vorschlags war viel zu überzogen. Der Bewerber wollte vermutlich Gründlichkeit zeigen, aber aus Sicht des Unternehmens kann das tatsächlich als ineffizient und als Zeitverschwendung wahrgenommen werden.
    3. Das fertige Ergebnis war zwar funktional, aber es wurde zu viel Aufwand in Infrastruktur und Feinschliff gesteckt. Bei einer Absage war das am Ende nur verschwendete Zeit.
    4. Es scheint eine Anforderung in Richtung eines von Terminals inspirierten E-Mail-Clients gegeben zu haben, aber ich konnte diese Ausrichtung im Ergebnis nicht erkennen.
      Ich erkenne die Fähigkeiten des Bewerbers und seine Leidenschaft für die Arbeit an. Ich wollte nur eine etwas andere Perspektive geben.
    • Ich finde die Haltung des Blogautors etwas irritierend. Schon aus dem Text wirkt es, als sei es schwer, mit ihm zusammenzuarbeiten, als könne er nicht gut eigenständig Entscheidungen treffen und brauche klare Richtlinien. Das passt zu Großunternehmen, aber nicht zu Startups.
      „Einen von Terminals inspirierten E-Mail-Client entwickeln und mit Kunden alpha-testen“ ist für einen Engineer in einem frühen Startup eine legitime Anforderung. Selbst wenn es mehr Spezifikationen gibt, hängt vieles vom Urteil des Engineers ab. Der Bewerber scheint zu viel Sicherheit zu wollen.
      Dass er vorab wissen wollte, welches Feedback Kagi nach Abschluss der Aufgabe geben würde, ist kein gutes Signal. In so einer Situation kann man keine verbindliche Antwort geben. Vermutlich bewerten sie Hunderte oder Tausende Bewerbungen.
    • Der Autor hat gute Arbeit geleistet, ist aber implizit an der Bedingung „streng dich nicht zu sehr an“ gescheitert.
      Wenn keine Klärung der Anforderungen nötig war, dann könnte man auch einfach „Errate eine Zahl zwischen 1 und 10“ geben und Leute aussortieren, die die falsche Wahl treffen.
      Ich kann nicht zustimmen, dass jemand aussortiert wird, weil er sich Mühe gibt und etwas gut abschließt.
      Solche vagen Aufgaben sind in Wahrheit nur eine weitere Methode, auf „Culture Fit“ zu filtern.
    • Meiner Meinung nach ähnelt der Ansatz des Bewerbers, seine Ideen zu validieren, moderner Engineering-Praxis. Ein gesundes Team erklärt ein Feature-Design-Dokument auf Englisch, holt sich Zustimmung und arbeitet dann weiter.
      Eine Kultur von „erst Code, Feedback später“ war die schädlichste Erfahrung meiner Laufbahn. Dieser Bewerber hat moderne Software-Praktiken befolgt. (Ich bin Hiring Manager in einem Unternehmen mit über 1000 Engineers.)
    • Eine Take-Home-Aufgabe, die ich als Einstellender mag, ist in 30 Minuten fertig, hat klare Bewertungskriterien und erlaubt verschiedene Ansätze sowie Überlegungen zu Trade-offs.
      Ich selbst bin bei meiner letzten Jobsuche auch an einer umfangreichen Take-Home-Aufgabe gescheitert, weil ich nicht wusste, welcher Teil eigentlich bewertet wurde. Seit dieser Erfahrung habe ich eine starke Abneigung gegen solche Aufgaben.
    • Ich denke, der Grund für die Absage war, dass der Vorschlag viel zu groß geworden ist. In den Anweisungen wurde kein Vorschlag verlangt, und wenn man zu detailliert einreicht, kann das eher als „mangelnde eigenständige Umsetzungskraft“ interpretiert werden. Dann wird die Codequalität bedeutungslos.
      Ich finde, das Unternehmen hätte den Bewerber an diesem Punkt nicht weiter Zeit verschwenden lassen, sondern die Aufgabe dann beenden sollen.
    • Ich finde es bedauerlich, dass in der Branche heutzutage mangelnde Fähigkeit zur Anforderungsdefinition dazu führt, Entwickler nach Gedankenlese-Fähigkeiten auszusortieren.
    • Problematisch war auch, dass der Bewerber die Deadline nicht eingehalten hat. Eine Verzögerung ohne Erklärung besonderer Umstände bedeutet bereits Absage. Der Zweck der Aufgabe war, innerhalb der Frist eine angemessene Lösung zu entwerfen.
    • Zu Punkt 4 mit dem Terminal-Bezug: In der vollständigen Version, die der Autor geteilt hat, gibt es dazu eine Erklärung.
    • Solche Diskussionen sind im Nachhinein immer leicht zu führen. Auch mit der gegenteiligen Strategie (Anforderungen nicht abklären, nur das Minimum erfüllen) wäre wahrscheinlich dasselbe Ergebnis herausgekommen. In solchen Situationen kann man immer im Nachhinein sagen, „man hätte die Anforderungen proaktiver klären müssen“, und genauso gut das Gegenteil behaupten.
  • Als ich den Code und dann das Demo-Video gesehen habe, war mein Eindruck: Dafür, dass in einer Woche eine Web-App mit zwei Seiten gebaut wurde, ist ziemlich viel Zeit draufgegangen.
    Es gab nicht einmal die grundlegendsten E-Mail-Funktionen (wie das Öffnen einer Mail), und obwohl es eine Bewerbung auf eine Backend-Engineer-Stelle war, wurden in der Praxis externe Produkte wie postmark und turso genutzt; außerdem fehlten grundlegende Features (Plaintext-Formatierung, Anzeige, Ordner usw.).
    Es gab zwar Zusatzfunktionen wie eine Admin-Seite und Login, aber selbst minimale Datenstrukturen wie ein Map für Mail-Header fehlten.
    Er mag ein guter Engineer sein, aber ich halte ihn für diese Position für ungeeignet.
    Auch den Take-Home-Vorschlag fand ich zu ungewöhnlich.
    Als ich die ursprüngliche Ausschreibung erneut gelesen habe, stand dort ausdrücklich „minimaler von Terminals inspirierter E-Mail-Client“ und es wurden Referenzen wie aerc, mutt und himalaya genannt. Das ist ein klares Scheitern bei der Interpretation der Anforderungen.
    • Zu der Formulierung „Scheitern bei der Interpretation der Anforderungen“ würde mich interessieren, welche Anforderungen genau nicht erfüllt wurden.
      Es wurde ein E-Mail-Client in Terminal- oder Web-App-Form mit grundlegenden Funktionen verlangt, und ich denke, das wurde erfüllt.
      Der Teil, sich von terminalbasierten Tools inspirieren zu lassen, ist subjektiv. Wenn es eine Backend-Position ist, könnte es auch ineffizient sein, zu viel Energie in die UI zu stecken.
    • Es ist frustrierend, wenn ein Bewerber Zeit investiert und dann nur eine Absage-Mail bekommt.
      Wenn man wenigstens Feedback bekommen könnte, wäre das hilfreich für die persönliche Entwicklung, aber selbst das ist in der Realität oft schwer.
      Deshalb bin ich gegenüber Take-Home-Aufgaben skeptisch. Sowohl Bewerber als auch Einstellende sollten die Zeit des jeweils anderen respektieren.
    • Es gibt den Satz: „Email client can either be in the terminal (i.e. a TUI) or a web app“.
  • Die Bewertung per Take-Home kann sinnvoll sein, aber sie muss unbedingt zeitlich begrenzt sein.
    Mit 2 bis 3 Stunden kann man einen Bewerber gut genug bewerten. Mit einem Zeitlimit hätte auch der Bewerber innerhalb dieses Rahmens eine passende Lösung präsentieren können, und für das Unternehmen wäre klarer gewesen, was es eigentlich will.
    Außerdem muss das Unternehmen klar kommunizieren, ob wirklich „jede Antwort okay“ ist oder ob „die bestmögliche Antwort“ erwartet wird.
    Die Absicht einer Take-Home-Aufgabe kann je nach Art sehr unterschiedlich sein — ob es ums Bestehen eines Tests geht, um den Erfüllungsgrad einer Mission oder um Codequalität — und das kann Bewerber leicht verwirren.
    • Aus Sicht eines Recruiters ist Kagi-Aufgabe viel zu umfangreich und respektlos gegenüber der Zeit der Bewerber.
      Sie birgt vielmehr das Risiko, Menschen auszusortieren, die keine freie Zeit haben und beschäftigt sind.
      Unser Unternehmen stellt einfach eine kleine ETL-Aufgabe und setzt ein Limit von 4 Stunden.
      Wir legen es so an, dass auch unvollständige Lösungen okay sind, und im Follow-up machen wir Code-Review und Fragen.
      Die eigentlichen Fähigkeiten erkennt man in diesem Folgetermin.
    • Bewerber können in der Praxis weit mehr Zeit investieren, als vorgesehen ist, und ich frage mich, wie Hiring Manager das überhaupt wissen sollen.
      Anders als bei einer Vor-Ort-Aufgabe mit fair gleicher Zeiteinheit kann Take-Home wegen unterschiedlich verteilter Zeit unfair sein.
      Dann ist eine einstündige Vor-Ort-Coding-Aufgabe vielleicht besser. Wenn Bewerber und Interviewer dieselbe Zeit investieren müssen, respektiert man eher den Wert der Zeit des anderen.
    • Ich denke, ein Live-Review ist viel besser als Live-Coding. Falls man Live-Coding macht, wäre es besser, wenn ich 45 Minuten allein auf meinem Laptop arbeite und dann zurückkomme, um gemeinsam zu reviewen.
  • Die Antwort des Unternehmens war tatsächlich unfreundlich und wenig hilfreich, aber in den Anforderungen stand „von Terminals inspiriert“ eindeutig drin.
    Im Demo-Video sieht man nur eine gewöhnliche Web-App. Es wurde ausdrücklich gesagt, man solle sich von bestehenden Terminal-Mail-Clients wie aerc, mutt und himalaya inspirieren lassen.
    Ich frage mich, ob ich etwas übersehe.
    • Es wäre besser gewesen, wenn in der Absage klar der Grund genannt worden wäre, aber schon im Design der Aufgabe wurden Referenzen auf Terminal-Clients direkt verlangt.
      Da die terminalspezifische UX noch kein Bereich mit einer klaren „richtigen Antwort“ ist, ist es sogar gut möglich, dass genau das ein Bewertungskriterium war.
    • Wenn man bedenkt, dass der Fokus auf der Sprache Go lag, wirkt es seltsam, sich aufwendig in eine Web-GUI zu vertiefen, obwohl man ein CLI in weniger als 20 Zeilen bauen kann.
    • Es gibt den Hinweis: „Email client can either be in the terminal (i.e. a TUI) or a web app“.
  • Ich hatte kürzlich in einem Interview eine ähnliche Erfahrung. Ich habe ein sehr gutes Aufgabenprojekt eingereicht, bekam aber sofort eine Absage, ohne überhaupt über das Projekt zu sprechen.
    Wenn man eine Aufgabe verlangt, sollte es meiner Meinung nach unbedingt ein Follow-up-Gespräch geben.
    Ich habe Kagi bereits als zahlender Kunde genutzt, überlege jetzt aber wegen dieser Sache, mein Konto zu kündigen.
    Wenn man nicht einmal Zeit für ein Gespräch mit dem Kandidaten hat, sollte man von Anfang an keine solche Aufgabe verlangen.
    • Take-Home-Aufgaben bedeuten nicht nur für Bewerber, sondern auch für die beurteilenden Interviewer erheblichen Aufwand.
      Wenn man sogar ein Review macht, denke ich, dass der Bewerber ein Recht auf Feedback hat.
      Aber in der Realität wählt man unter Dutzenden hervorragender Kandidaten nur einen aus, daher bedeutet eine Absage nicht automatisch „du bist nicht gut genug“.
      Auch rechtlich führt eine offizielle Antwort auf „Warum wurde A eingestellt und B abgelehnt?“ in der Praxis oft nur dazu, nach Schwächen zu suchen.
    • Es wäre besser gewesen, wenn das Unternehmen klare Bewertungskriterien veröffentlicht oder Feedback gegeben hätte. Zeit ohne Feedback in einer Fehlsituation zu verschwenden, finde ich inakzeptabel.
      Viele Unternehmen handhaben diesen Punkt gut.
    • Ich frage mich, ob es wirklich eine „großartige Lösung“ war. Es wirkt, als seien die Anforderung eines minimalen, von Terminals inspirierten E-Mail-Clients und die zugehörigen Referenzen vollständig ignoriert worden.
      Wenn das Missverständnis der Anforderungen groß ist, kann die Diskussion selbst wegfallen.
  • Dieser Fall ist ein typisches Beispiel dafür, den verborgenen Sinn im Aufgabentext falsch zu lesen.
    Das Unternehmen wollte jemanden, der eigenständig handelt und sich selbst Ziele setzen kann.
    Die Unklarheit sollte die Fähigkeit des Bewerbers zeigen, die Antwort aus mehreren Blickwinkeln zu erforschen und daraus eine Lösung zu entwickeln.
    • Die Aufgabe war für jemanden gedacht, der eine möglichst einfache, clevere und funktionierende Lösung liefern kann.
      Weil das zu einem prototypenorientierten Unternehmen passt, hätte ein passender Kandidat vielleicht 10 Minuten nachgedacht und dann in 60 Minuten das Maximum herausgeholt.
    • Wenn es sich um ein R&D-Projekt handelt und nur „minimieren“ betont wird, dann ist unklar, ob es ein Prototyp ist, für Nutzer gedacht ist, ob UX wichtig ist usw.; am Ende ist es nur ein Ratespiel darüber, was der Bewertende wichtig findet.
    • Bei solchen Aufgaben nach dem Motto „interpretiere es selbst“ kann jemand durchfallen, weil er die Anforderungen nicht präzisiert oder keine Zusatzfragen gestellt hat.
      Aber gerade für Entwickler ist die Fähigkeit, solche Fragen zu stellen, eine sehr wichtige Eigenschaft. Deshalb kann man an das Hiring-Verfahren hohe Erwartungen haben und am Ende nur enttäuscht sein.
    • Ich denke, „misreading the subtext“ trifft es nicht — es stand schon in der Aufgabe selbst.
    • Im Bildungsbereich nur den Studierenden vorzuwerfen, sie hätten etwas nicht verstanden, ist ein allzu bequemer Schluss.
      Tatsächlich liegt es an der unklaren Erklärung.
      Ein großartiger Lehrer sorgt dafür, dass möglichst viele es verstehen. Wenn viele Lernende verwirrt sind, liegt das Problem beim Aufgabenersteller.
      Studierende an der Universität sollten keine Koans wie ein Zen-Mönch lösen müssen.
  • Da der Verfasser selbst den Beitrag gepostet hat, möchte ich auf Basis meiner Erfahrung bei Kagi etwas Kontext liefern.
    Früher hat Vlad die Bewerber direkt bewertet, und die Aufgaben waren auch so aufgebaut.
    Mit dem Wachstum des Unternehmens scheinen nun andere Leute zu bewerten.
    Vlad hat einen HN-artigen Stil und möchte mit Bewerbern arbeiten, die er als „cool“ empfindet.
    Wenn man zum Beispiel ein langes Design-Dokument schreibt und sagt: „Wir werden Galactor verwenden und das Projekt ist flop-ready“, hat das den komplett gegenteiligen Effekt.
    Bei der Anforderung „von Terminals inspiriert“ gibt es die Tendenz, Details wie alle Tastaturkürzel und andere konkrete Eigenheiten echter Terminal-Apps zu erwarten.
    Ob das ein guter Filter ist, kann man diskutieren, aber wenn man diesen Kontext versteht und die Fähigkeit hat, durchzukommen, wirkt die Aufgabe leicht.
    Ich wünschte, Kagi hätte diesen Kontext besser kommuniziert. Es ist schade um die verschwendete Zeit, aber ich hoffe, du findest ein Unternehmen, das besser zu dir passt.
    • Viele Unternehmen suchen nach Menschen mit einer ähnlichen Denkweise wie sie selbst.
      Teams ohne Vielfalt können stagnieren, weil alle an dieselbe Wand stoßen.
      Dieses Phänomen ist besonders in Startups häufig, und ich denke, es hängt auch damit zusammen, warum 9 von 10 scheitern.
    • Ich empfinde das Problem so, dass Vlad zu viel Zeit von zu vielen Menschen verschwendet, um „coole Leute“ zu finden.
      Eine Aufgabe ohne klare Kriterien zu bewerten, ist unfair.
      Letztlich ist es kaum etwas anderes als eine implizite Aufgabe nach dem Muster „Errate die Antwort in meinem Kopf“.
      Das wirkt wenig rücksichtsvoll gegenüber Menschen.
    • Ich frage mich: „Hätte ich so etwas wirklich im Voraus wissen müssen?“
      Bei so einer Kultur ist unklar, ob jeder erst wie undercover recherchieren musste, um das herauszufinden.
      Es wäre besser, wenn auch Bewerber wie ich, die nicht „cool“ genug sind, ein klares Signal bekämen und schnell andere Unternehmen suchen könnten.
  • Nachdem ich den Code direkt geprüft habe, habe ich schon in der ersten Datei Kommentare gesehen, die wie ziellos kopierter Beispielcode wirkten, dazu unpassende Erklärungen und Formulierungen, die auf mangelnde Sorgfalt schließen lassen.
    Wegen solcher Details würde ich das Review abbrechen.
    • Ich habe die App auf meiner Domain deployed, und es gab keine Performance-Probleme. Auch backendtypische Dinge wie Auth und Infrastruktur waren gut umgesetzt. Dem Hinweis, ich hätte mehr auf Code-Kommentare achten sollen, stimme ich aber nicht zu.
    • Das Kernproblem in diesem Fall ist nicht die Absage selbst, sondern dass ein Hiring-Verfahren ohne klare Leitlinien und ohne Feedback überhaupt keinen Respekt vor der Zeit des Bewerbers zeigt.
  • Ich hatte bei DuckDuckGo eine ähnliche Erfahrung, bekam aber in allen Bewerbungsphasen eine kleine Vergütung.
    Von einem einfachen Design-Vorschlag bis zur Implementierungsaufgabe lief alles mit klarem Zeitlimit.
    Am Ende wurde ich nicht genommen und bekam keinen klaren Grund genannt.
    Vermutlich gab es einfach zu viele Bewerber, aber diese Erfahrung hat mich emotional noch lange beschäftigt. Ich kann die Gefühle des OP nachvollziehen.
  • Ich spreche aus Sicht eines technischen Interviewers. Sowohl LeetCode als auch Take-Home-Aufgaben kosten viel Zeit und liefern zu wenig Information.
    Trotzdem hätte ich als Hiring Manager den Autor wahrscheinlich ebenfalls abgelehnt.
    Startups wollen Leute, die schnell und pragmatisch arbeiten.
    Ich hatte früher einen Kollegen, der erst tagelang allein tief eintauchte, nachdem er sich Meinungen aus dem Umfeld eingeholt hatte — und bis dahin hatten sich die Anforderungen schon geändert, was für niemanden gut war.