Panik auf dem Arbeitsmarkt

• Der Arbeitsmarkt für Tech-Jobs verschiebt sich durch das Zusammenspiel von steigenden Zinsen, schrumpfenden VC-Mitteln, zurückhaltenderen Kundenausgaben und standardisierten Einstellungsverfahren zu Ungunsten von Entwicklern
• Je nach Finanzierung, Umsatz und Wachstumsphase eines Unternehmens unterscheiden sich Vergütung und Stabilität; in einem Hochzinsumfeld geraten vor allem Unternehmen mit hoher VC-Abhängigkeit ins Wanken oder schrumpfen in den Überlebensmodus
• Moderne Tech-Rekrutierung ist stärker auf Coding Tests und Verhaltensinterviews ausgerichtet als auf echte Berufserfahrung; vom kleinen Startup bis zum großen Tech-Konzern kopieren alle ähnliche Verfahren
• Stellenanzeigen im Stil eines „Everything Bagel“ bündeln Anwendungsentwicklung, Infrastruktur, Security, Kundensupport, On-Call, Kostenoptimierung und Dokumentation – also die Arbeit mehrerer Abteilungen – in einer einzigen Rolle
• Tech-Rollen wandeln sich von Aufgaben, die Produkt und Organisation gemeinsam verbessern, zu Ausführendenrollen, in denen man mit wenig Entscheidungsspielraum die Prioritäten anderer abarbeitet; Erfahrung und Urteilsvermögen erfahrener Entwickler spiegeln sich darin kaum wider

---

Der Zusammenhang zwischen Zinsen und Tech-Jobs

• Das Umfeld niedriger Zinsen, das fast „kostenlosem Geld“ glich, ist vorbei; da die Zinsen auf über 5 % gestiegen sind, gilt die Grundannahme, dass Geld selbst teurer geworden ist
• Wenn die Zinsen steigen, können Organisationen mit Bargeld ihr Geld statt in unsichere Unternehmen eher in sichereren Anlagen wie staatlich garantierten Zinsprodukten parken
• Investitionen in Tech-Unternehmen gelten als Risikoanlagen auf eine ungewisse Zukunft; in Hochzinsphasen brechen schwache Unternehmen zusammen, und selbst starke Unternehmen bauen unter dem Vorwand des „clean house“ Personal ab
• Daraus ergibt sich die Beobachtung, dass Hunderttausende hoch vergütete Tech-Beschäftigte über zwei bis vier Jahre hinweg einem Markt mit zu wenigen Jobs gegenüberstehen
• In Phasen steigender Zinsen können Mindestlohn-Teilzeitjobs oder Baujobs zunehmen, Tech-Jobs hängen jedoch stärker von VC-Finanzierung und Kundenausgaben ab

Unternehmenstypen und Vergütungsstruktur

• Tech-Unternehmen lassen sich nach Finanzierung und Wachstumsstatus in vier Kategorien einteilen
  • nepo company: ein Unternehmen, das mit Kapital aus Familie, persönlichen Beziehungen oder ähnlichen Quellen, das weit von einer realen Validierung entfernt ist, unrealistische Produkte bauen kann
  • speculation company: ein Unternehmen, das Geld erhält, um eine Idee zu testen, ohne Produkt-, Kunden- oder Marktvalidierung
  • initial growth company: ein Unternehmen, das nach erster Nachfrage Wachstumskapital erhält und versucht, den Umsatz auszuweiten
  • stable era company: ein stabiles Unternehmen mit wiederholbarem Markteintrittspfad, Kundenzugang und wiederkehrenden Umsätzen
• In einem Hochzinsumfeld sind weniger erfolgreiche Unternehmen stärker von VC-Geld abhängig und geraten am stärksten ins Schwanken, wenn der Kapitalfluss langsamer wird oder versiegt
• Auch Kunden unterliegen eingeschränkten Ausgabebedingungen, sodass Kundenabwanderung oder Ausgabenkürzungen gleichzeitig auftreten können
• Eine speculation company wird als Ort beschrieben, der 50–80 % der marktüblichen Vergütung zahlt und zugleich 200–500 % mehr Arbeit erwartet
• Eine initial growth company kann zur Kombination aus hohem Risiko und niedriger Vergütung werden; scheiternde Wachstumsunternehmen können in einem Zustand aus niedriger Vergütung und wiederholten Entlassungen verharren
• stable era companies lassen sich wiederum in drei Typen aufteilen
  • Unternehmen, die stabil wachsen und Gewinne erzielen
  • Unternehmen, die je nach Neigung eines bekannten CEOs zwischen Wachstum und Schrumpfung pendeln
  • Unternehmen, die einen oder mehrere Wirtschaftssektoren beherrschen und nicht leicht zu erschüttern sind
• Moderne große Wachstumsunternehmen können erfahrenen Mitarbeitern inklusive jährlicher Aktienvergütung Vergütungen im Gegenwert von 10.000 bis 50.000 US-Dollar pro Tag zahlen, während andere Unternehmen über zehn Jahre hinweg kein reales Lohnwachstum oder keine wirksame Aktienvergütung bieten

Das Problem, dass Einstellungsverfahren tatsächliche Fähigkeiten nicht erkennen

• In der Tech-Rekrutierung wiederholen sich drei Widersprüche
  • Die Anforderungen sind kaputt
  • Der Interviewprozess ist kaputt
  • Die meisten Unternehmen folgen denselben Anforderungen und derselben Interviewmethode
• Interviewer können Kandidaten, die bessere Antworten liefern als die erwarteten, möglicherweise nicht zuverlässig einschätzen
• Moderne Tech-Interviews verlangen improvisierte Aufgaben, die mit der tatsächlichen Arbeit nichts zu tun haben; scheitert jemand daran, gilt die Person als weniger fähig, während höheres Erfahrungsniveau möglicherweise nicht erkannt wird
• Coding Tests nach Google-Art und Verhaltensinterviews nach Amazon-Art werden branchenweit kopiert; vom kleinen Startup bis zum Großunternehmen verlangen alle ähnliche Verfahren
• Verhaltensinterviews wiederholen Fragen wie „Wie haben Sie einen Konflikt gelöst?“ oder „Welche Erfahrung haben Sie damit gemacht, einen Fehler zu machen und sich zu entschuldigen?“; tatsächlich wird der Prozess als Versuch verstanden zu sehen, wie Kandidaten Fortschritt und Freundlichkeit ausbalancieren
• Wenn kulturelle Passung als Frage-Antwort-Schema codiert wird, kann das zu Persönlichkeitshomogenisierung führen, bei der Menschen herausgefiltert werden, die vom durchschnittlichen Charakter des Unternehmens abweichen
• Wenn Unternehmen immer weitere Interviewstufen hinzufügen und sich damit von echter Arbeit, Erfahrung, Fähigkeit und Einsicht entfernen, kann die gesamte Tech-Industrie ineffizient werden

„Everything Bagel“-Stellenanzeigen

• „Everything Bagel“-Stellenanzeigen verlangen von einem einzelnen Software Development Engineer zu viele Verantwortlichkeiten gleichzeitig
• Beispielanforderungen umfassen unter anderem
  • Anwendungen mit React, Vue, TypeScript, Node, Python, Rust, Go usw. schreiben
  • Bestehende Anwendungen auf Basis von PHP, Ruby und C warten
  • Infrastruktur mit AWS, Docker, Kubernetes, Terraform, Lambda, EventBridge, Step Functions usw. bereitstellen
  • AWS-Kosten optimieren, CI/CD, 24/7-On-Call sowie Logs, Monitoring, Alerts und Observability sicherstellen
  • Anwendungssicherheit, Dependency Security und SOC-2-bezogene Infrastruktursicherheit
  • Kundensupport, interner Mitarbeitersupport, Code Reviews, Mentoring und Dokumentation
  • 37 JavaScript-SaaS-Plugins und zusätzliche Tracking-Skripte warten
• Solche Anforderungen an eine einzelne Rolle entsprechen in Wirklichkeit eher der Arbeit von 5 Abteilungen und 20 Personen
• Teile der Branche haben offenbar die Vorstellung aufgegeben, dass Techniker Spezialisierung brauchen, und laden Entwicklern ohne Betriebserfahrung nach dem Motto „devops means DEVS DO OPS“ auch den Betrieb auf
• In einer Struktur, in der Anwendungsentwickler zusätzlich Teilzeit-AWS-Architekt sein sollen, sind gute Ergebnisse schwer zu erwarten; die Position ist, dass solche Fähigkeiten normalerweise über mindestens fünf Jahre konzentriert aufgebaut werden müssen
• Überzogene Anforderungen machen die Arbeit physisch unmöglich; jeder Punkt kann mehrere Tage Arbeit pro Woche bedeuten, sodass man schon am ersten Arbeitstag im Rückstand ist

Organisations- und Infrastrukturprobleme aus Praxiserfahrung

• Mehrere Unternehmen sagten, „die Website ist langsam“, doch tatsächlich wurden grundlegende AWS-Metriken und Systemadministration nicht betrachtet, sodass Probleme wiederholt liegen blieben
• Ein Unternehmen betrieb den gesamten Service auf einer einzigen MySQL-Instanz mit 2 Kernen und 16 GB RAM; die Datenbank wuchs auf 3 TB, und die CPU lief zwei Jahre lang bei 99,99 %
  • Nach dem Wechsel auf einen ARM-Server mit 64 GB und reserved IOPS sank die Laufzeit einer Batch-Datentransformation von 16 Stunden auf 20 Minuten, und der Replikationsverzug ging von 4–6 Wochen auf Echtzeit im Sub-Second-Bereich zurück
• Ein anderes Unternehmen gab monatlich 5.000 US-Dollar für einen ungenutzten Forschungscluster aus, während der tatsächliche Produktionscluster nur Ressourcen im Wert von 500 US-Dollar pro Monat nutzte
  • Nachdem Ressourcen in den Produktionscluster verschoben und auf ARM umgestellt wurden, sank die Antwortzeit für Nutzer von 7 Sekunden auf 200 ms
• Bei einem Unternehmen lief eine interne Datenverarbeitungs-API auf denselben zwei 2-Core-EC2-Instanzen wie die Kunden-Webserver; die Batch-Verarbeitung dauerte 20 Stunden
  • Nach der Migration auf automatisch skalierende Container auf Basis von ECS-on-EC2 verarbeiteten 20–50 Container parallel, und die Verarbeitungszeit sank auf 30 Minuten
• Bei einem Unternehmen, dessen Tool zum Verschieben von Daten aus MySQL nach Redshift 80 Stunden brauchte, führte das System zuerst SELECT COUNT(*) auf einer Tabelle mit 3 Milliarden Zeilen aus und durchlief dann die gesamte Tabelle mit LIMIT/OFFSET
  • Durch den Einsatz von Datenbank-Cursorn, Streaming-Schreiben nach S3 und In-Memory-Kompression sank die Extraktionszeit von 80 Stunden auf 40 Minuten
• Wenn Systemadministrations- und Architekturerfahrung wegen „Cloud Native“ geringgeschätzt werden, gibt es nicht einmal jemanden, der Probleme erkennt; dieselben Probleme können über lange Zeit unbemerkt bleiben
• Selbst wenn Kunden abwandern, gibt es Fälle, in denen VCs „mehr Vertriebspersonal“ verlangen, sodass auf 5 Entwickler 50 Personen in Sales und Marketing kommen
• Wenn ein Unternehmen mit sinkendem Umsatz statt Produktwandel oder Verbesserungen an der bestehenden Idee und einer vertriebszentrierten Strategie festhält, können Entwickler nicht das gewünschte Produkt bauen, und das führt zum Scheitern des Unternehmens

Ein Arbeitsmarkt, der Erfahrung und tatsächliche Ergebnisse ignoriert

• Zugrunde liegt die Wahrnehmung, dass sich Tech-Einstellungen in den letzten 10–20 Jahren von einer einfachen Bewertung „kann gut mit Computern umgehen“ hin zu einer Struktur rund um sozialen Status und Interviewspiele gewandelt haben
• Der Prozess, spontan Probleme zu lösen und darüber zu sprechen, wiegt stärker als tatsächliche Arbeit, Erfahrung und Fähigkeit
• Auch persönliche Projekte und reale Ergebnisse werden nach dieser Sicht in Interviews nicht ausreichend berücksichtigt
  • mpreg: ein Datenverarbeitungssystem zur automatischen Abhängigkeitsauflösung per verteilter hierarchischer topologischer Sortierung
  • CRC-Verarbeitungsverbesserung: erwähnt als Code, der zur Validierung globaler Dateiformate und von Informationen der Raumstation verwendet wurde
  • icli: CLI für manuellen und automatisierten Aktienhandel
• Die Branche sei stärker zu sozialem und politischem Status und Macht geworden als zu tatsächlicher Fähigkeit; es besteht das Problembewusstsein, dass Einstellung darauf ausgerichtet sein sollte, mehr „us“ zu schaffen
• Tech-Rollen legen einer einzelnen Person zu breite Aufgaben auf, während die Rekrutierung zugleich tatsächliche Erfahrung nicht ausreichend betrachtet; dadurch entsteht eine Struktur, in der Arbeitssuchende kaum durchhalten können

Entscheidungsspielraum von Entwicklern und produktgetriebene Arbeit

• Die Schlussfolgerung lautet, dass Jobs in der Tech-Industrie an übermäßiges spekulatives Kapital gekoppelt waren und mit dem Rückgang von Kapital und Kunden auch verschwunden sind
• Viele Tech-Rollen hätten sich in eine Struktur verwandelt, in der man wie ein „software servant“ Aufgaben und Prioritäten abarbeitet, die nichttechnische Produktteams festlegen
• Bei Engineering-led management definieren diejenigen, die die Arbeit ausführen, das Produkt, sprechen mit Nutzern, legen Anforderungen fest und implementieren Funktionen
• Die Entwicklerrolle bestand einst darin, Probleme aus Sicht des gesamten Geschäfts zu lösen; heute wird sie eher als Projektmanagement-Arbeiter wahrgenommen, der die Ideen und Prioritäten anderer umsetzt
• Für dieselbe Rolle und denselben Aufwand erhält man in einem Unternehmen 400 US-Dollar pro Tag, in einem anderen 20.000 US-Dollar pro Tag; diese Vergütungsschere verstärkt das Gefühl der Ohnmacht bei Jobsuchenden
• Gute Produkte, gute Systeme sowie wachsende Produkte und Volkswirtschaften zu schaffen, bleibt die Richtung, auf die Techniker hinarbeiten sollten

[GN⁺]

Hacker-News-Meinungen

• Das ist kein Problem, das nur Software Engineering oder angrenzende Branchen betrifft. Bekannte in Europa versuchen ebenfalls, in völlig anderen Branchen von Finanzwesen bis Mode den Job zu wechseln oder vertikal bzw. lateral aufzusteigen, scheitern aber ziemlich deutlich daran.
  Die meisten Einstellungsprozesse laufen heutzutage so ab, dass sie nicht auf den Lebenslauf einer Person oder ihren möglichen Beitrag schauen, sondern einen einfach immer weiter durch Gateways schleusen. Lebensläufe, die in Jobportalen landen, sind eher Sediment, das ganz unten im Stapel versinkt; deshalb ist es besser, so weit wie möglich das eigene Netzwerk und Bekannte zu nutzen.
  Auch mich hat der Rückgang von Tech-Jobs getroffen, und als ich bei einer Software-Consulting-Firma anfangen wollte, blieb ich acht Monate lang auf der Bench. Am Ende habe ich gekündigt und bin zur Unternehmens- und Steuerbewertung zurückgekehrt; selbst Unterbeschäftigung ist, besonders mental, besser als gar nichts.
  In der Originalquelle steht auch die kleine Formulierung: „slipped on this banana like a lazy monkey“.

  • Der Kern ist die Aussage, dass „heutige Einstellungsprozesse nur noch viele Gateways haben und nicht auf den Lebenslauf einer Person oder ihren möglichen Beitrag schauen“. Als ich mich früher beworben habe, bekam ich Fragen wie „Haben Sie Erfahrung mit C++ oder fortgeschrittenen Graphalgorithmen?“, obwohl in meinem Profil oder Lebenslauf davon überhaupt nichts stand.
    Trotzdem wurde so reagiert, als wären zehn Jahre Software- und verwandte Erfahrung plötzlich ungültig. Es ist seltsam, jemanden, der mehrere Sprachen gelernt und eingesetzt hat, so zu behandeln, als könne er überhaupt kein C++, nur weil er C++ nur implizit ein wenig verwendet hat.
    Ein Unternehmen schrieb in die Anzeige, dass keine Python-Erfahrung nötig sei, und bombardierte mich dann im ersten Telefoninterview mit Low-Level-Fragen zur Python-Implementierung. Wenn das so ist, weiß ich nicht, wozu man überhaupt interviewt; es ist Zeitverschwendung für alle.
    Letztlich wissen Unternehmen überhaupt nicht, wie man einstellt, und aus demselben Grund wissen sie auch nicht, wie Mentoring und Ausbildung funktionieren. Für Bewerber kann das allerdings auch ein natürlicher Filter sein: Orte, die nicht einstellen können, sind wahrscheinlich keine guten Arbeitsplätze.
  • Ich habe in den vergangenen Jahren Absolventen der Informatik betreut, und gelegentlich gibt es Unternehmen, die im Interviewprozess überzogene Aufgaben verlangen, etwa eine komplette App oder Website zu bauen. In solchen Fällen rate ich dazu, abzulehnen, aber in der Praxis ist das eher selten.
    Viele beklagen sich auch darüber, dass der Interviewprozess zu lang sei; hört man genauer hin, sind es aber häufig insgesamt etwa vier bis fünf Stunden. Die Zeit vor ein paar Jahren, als man Leute schon nach kurzen Interviews einstellte, hat die Erwartungen verzerrt, und junge Engineers, die damals eingestiegen sind, scheinen inzwischen jedes Interviewpensum als unangemessen zu empfinden.
    Weil Reddit dazu rät, alle Aufgaben abzulehnen, muss ich oft Leute davon überzeugen, auch einfache Aufgaben von höchstens 60 Minuten nicht zu verweigern. Es ist frustrierend zu sehen, wie jemand seit Monaten arbeitslos ist und dann erneut eine Aufgabe, mit der sich die Bewerbung mit minimalem Zeiteinsatz voranbringen ließe, „mutig“ ablehnt.
    Ein weiteres Problem sind Menschen, die die Jobsuche einstellen, sobald sich ein einziges Unternehmen zurückmeldet. Man muss ihnen immer wieder sagen: Jobsuche ist keine sequenzielle Verarbeitung, sondern Parallelverarbeitung. Wenn man mit einem langsamen Unternehmen interviewt und monatelang auf eine Antwort wartet, ist das für Kandidaten stark nachteilig.
    Überlange Interview-Loops gibt es definitiv, aber im Durchschnitt ist es meiner Ansicht nach nicht so schlimm, wie man es im Internet liest.
  • Beim Titel scheint es einigermaßen funktioniert zu haben, beim Minions-Teil aber offenbar nicht so gut.
    Die Beispielausgabe fasst angeblich „Panic! at the Tech Job Market“ zusammen, erzeugt dabei Formulierungen wie LIKE SLUGS THROUGH THE HOURGLASS, THESE ARE THE DAYS OF OUR TECH TRIUMPHS und ordnet Zinsen, Tech-Recruiting und Unternehmenstypen ein, reagiert aber offenbar nicht richtig auf die Minions-Anweisung.
  • Die Europäische Union befindet sich in gewissem Maß in einer Rezession, und der Zusammenhang zwischen Zinsen und Arbeitslosigkeit ist ebenfalls bekannt. Dass es in Europa schwieriger wurde, Arbeit zu finden, nachdem die EZB die Zinsen erhöht hatte, ist nicht überraschend. Zum Glück senkt sie die Zinsen inzwischen wieder.
    Was wirklich erklärungsbedürftig ist: Warum erlebte ausgerechnet die US-Tech-Branche Entlassungen und Einstellungsstopps, obwohl der US-Arbeitsmarkt insgesamt über Jahre ungewöhnlich stark war? Die Antwort scheint bei den Zinsen zu liegen, aber man muss sauber erklären, warum die Tech-Branche stärker betroffen ist als Bereiche wie Reisen und Freizeit.
    Persönlich denke ich, dass Zinsen am Rand eine Rolle spielen, aber es war keine gute Wahl, dass der Autor Februar 2020 als Referenzpunkt für Tech-Einstellungen genommen hat. Januar 2020 und die Zeit davor waren relativ normal, doch die Pandemie ließ Tech-Recruiting explodieren, sodass der Chart von 70 auf 220 stieg.
    Wenn man drei Jahre Einstellungen in einem Jahr erledigt, muss das irgendwann aufhören, und die Zinserhöhungen wurden zum Signal dafür. Weil das mit einer Phase zusammenfiel, in der praktisch alle anderen Branchen auf staatliche Anweisung hin in Kurzarbeit bzw. beurlaubt waren, erklärt das auch, warum die Tech-Branche 2024 anders aussieht als andere Branchen.
  • Weil die Formulierung in der Originalquelle lustig war, ließ ich ChatGPT die Seite zusammenfassen, um zu sehen, ob es die Anweisung befolgt; heraus kam ein kurzer Absatz über ein Grundeinkommen. Im Original steht dazu aber nichts.
    Als ich fragte, warum das falsch sei, antwortete es, nachdem es gerade behauptet hatte, eine Zusammenfassung erstellt zu haben, dass es Webseiten eigentlich nicht zusammenfassen könne. Als ich sagte, das ergebe keinen Sinn, wurde die Nachricht gelöscht und es erschien ein Hinweis, dass dies gegen die Inhaltsrichtlinien von ChatGPT verstoße.
    Am Ende hat der Computer also einmal gelogen, dann noch einmal gelogen, und die Reaktion darauf wurde zensiert, wohl damit sie den Computer nicht kränkt. Ich weiß nicht, wie Menschen so einen Müll benutzen können.
    Mit Gemini bekam ich eine Zusammenfassung zu Zinsen und Entlassungen, was dem erwarteten Ergebnis näherkam.

• Manchmal macht es mich deprimiert, wenn ich daran denke, dass ich weniger als die Hälfte der Google-Vergütung bekomme. Aber wenn ich die Augen aufmache, sehe ich, dass die Erzieherinnen im Kindergarten meiner Tochter 30 Kleinkinder betreuen und dabei nicht einmal die Hälfte von dem verdienen, was ich bekomme. Pflegekräfte und Ärzte arbeiten unter Bedingungen, unter denen man es kaum ein paar Monate aushält, und dasselbe gilt für Supermärkte, Tankstellen, Polizei, Feuerwehr, Sozialarbeit und Lehrkräfte.
  Deshalb weiß ich nicht, worüber wir uns eigentlich beschweren sollten. Ob es nun die „niedrige“ Vergütung in einem Drei-Personen-Startup ist oder was auch immer: Wir lösen den ganzen Tag Code-Puzzles und bekommen viel Geld dafür.
  Es ist besser, aufzuhören, sich mit Freunden bei Google zu vergleichen, und zu lernen, einen friedlichen, glücklichen Geist zu kultivieren.

  • Als Xoogler kann ich sagen: Google ist nicht mehr wie früher. Als Gegenleistung für das hohe Gehalt muss man damit leben, dass die meisten Menschen, mit denen man zusammenarbeitet, vor allem daran interessiert sind, wie sie noch mehr Geld aus Google herausholen können.
    Sich um Kleinkinder zu kümmern, wirkt schon auf den ersten Blick wie eine bessere Richtung, in die man sein einziges Leben investieren kann.
  • Manchmal fällt es mir schwer zu glauben, dass es ethisch ist, mit so wenig Einsatz so viel Geld zu verdienen. Als ich im Homeoffice mit meiner Frau durch die Stadt lief und sah, wie eine Kellnerin bei einer Rechnung über 360 Kč und einer Zahlung von 500 Kč ratlos war, wie viel Wechselgeld sie herausgeben sollte, hatte ich sofort meine Antwort.
  • Mein Vater ist kürzlich in Rente gegangen, nachdem er als Hausmeister an einer Schule gearbeitet hatte, und sagte, er sei erst jetzt erleichtert, weil die Arbeit einen so zermürbt habe. Mein Ehepartner ist Pflegekraft und fürchtet sich regelmäßig davor, zur Arbeit zu gehen. Ich dagegen fürchte mich nicht vor der Arbeit; im Gegenteil, ich habe das Gefühl, daran zu wachsen.
    Selbst wenn ich kein Geld bräuchte, würde ich diese Arbeit wahrscheinlich weiter machen. Ich kann tun, was ich wirklich mag, meine Fähigkeiten einsetzen, um nützlich zu sein, und andere Menschen glücklich machen. Außerdem verdiene ich ungefähr dreimal so viel wie mein Vater und mein Ehepartner.
    Viele HN-Leute leben in einer Blase. Sie haben keine Ahnung, wie die Welt da draußen aussieht. Denn sie sind faktisch wie Adel behandelt worden. Menschen wollen, egal wo sie stehen, nicht verlieren, was sie haben, und nicht zurückweichen. Selbst wenn sie weiter vorn gestartet sind als der Endpunkt eines anderen.
    Glaubt ihr, Programmieren sei nutzlos? Glaubt ihr, es gebe keine Unternehmen, die Technologie brauchen? Ihr werdet nur nicht bei Tech-Firmen arbeiten, die süchtig machende Dinge bauen, um Werbung zu verkaufen, sondern in nützlichen Unternehmen, die tatsächlich zur Gesellschaft beitragen.
  • Über alles, was gerade gesagt wurde, sollte man sich beschweren. Das gesamte System ist kaputt.
    Alle sollten das Recht haben, nicht unter solchen schrecklichen Bedingungen leben zu müssen, aber wir lassen es gesellschaftlich weiter zu, weil wir sie nicht als gleichwertige Menschen ansehen. Wenn man persönlich damit zurechtkommt, lässt sich das Leid, das andere ertragen, leicht ausblenden.
    Wenn alle ein besseres Leben führen könnten, wäre ich gern bereit, mit weniger zu leben. In Wirklichkeit ist die Anhäufung von Reichtum so groß, dass man gar nicht so viel opfern müsste. Es würde schon reichen, diesen Reichtum umzuverteilen.
    Wir sollten nicht versuchen, Systemprobleme mit individualistischen Lösungen zu lösen. Ich weiß nicht, wie man einen friedlichen, glücklichen Geist haben kann, wenn alle außerhalb unserer kleinen Blase leiden.
    Die Haltung „Unsere Blase ist weniger schlimm als andere Blasen, also sollten wir glücklich sein“ ist tragisch. Wir müssen uns daran erinnern, dass wir alle im selben Boot sitzen.
  • Da ich in der Spielebranche arbeite, war mein Ziel nie, auf eine Gesamtvergütung von über 300.000 Dollar hinzuarbeiten.
    Aber in der Spielebranche zu arbeiten bedeutet auch, dass man die Vorstellung von einem „friedlichen, glücklichen Geist“ von vornherein ein Stück weit aufgeben muss.

• Früher dachte ich, Coding-Interviews seien ein Initiationsritus, der mit der täglichen Arbeit überhaupt nichts zu tun hat. Aber nachdem ich nach langer Zeit wieder als Senior-/Staff-Level-Engineer auf dem Arbeitsmarkt bin, neige ich widerwillig zu der Ansicht, dass sie vielleicht doch nicht ganz so schlecht sind.
  Ich habe das Gefühl, dass ich sie dank der Fähigkeiten bestehe, die ich in den letzten Jahren aufgebaut habe, und wenn das stimmt, könnten Coding-Interviews zumindest bis zu einem gewissen Grad ein Signal erfassen. Je senioriger ich werde, desto weiter entferne ich mich von der Vorstellung, Coding-Interviews seien völlig sinnlos.

  • Es gibt verschiedene Arten von Coding-Interviews. Es ist in Ordnung, grundlegende Fragen zu stellen, die direkt auf die Arbeit anwendbar sind, Basiswissen zu filtern, um zu prüfen, ob jemand seine Erfahrung nicht vorgetäuscht hat, oder den Denkprozess zu beobachten und zu sehen, ob jemand funktionierenden Code erstellt.
    Aber extrem obskure Aufgaben, die mit der täglichen Arbeit nichts zu tun haben, unter Zeitdruck spontan lösen zu lassen und Kandidaten durchfallen zu lassen, wenn die Antwort falsch oder nicht optimal ist, ähnelt eher einem Filter für billige Berufseinsteiger.
  • Ich denke, es gibt zwei Arten von Programmierern: Menschen, die Code schreiben können, um etwas zu bauen, und Menschen, die etwas bauen können und zugleich so sprachgewandt sind, dass sie die Theorie des Codes im Gespräch erklären können. Die zweite Gruppe ist fünfmal nützlicher als die erste, und Coding-Interviews prüfen, zu welcher Gruppe man gehört.
    Die erste Gruppe denkt oft, theoretische Sprachgewandtheit sei nicht wichtig, aber wenn echte Probleme gelöst werden müssen, sucht man nach der zweiten Gruppe. Teams, die nur Code schreiben können, aber nicht über Code theoretisieren können, häufen leicht Berge von Müll an, die später jemand anderes neu bauen muss.
    Natürlich gibt es auch Menschen, die nicht schnell theoretisieren können, nicht vor anderen oder nicht in einer belastenden Interviewsituation. Solche Formatprobleme muss man lösen. Obskure Trivia-Fragen sind ebenfalls sinnlos.
    Trotzdem ist der grundlegende Einwand „Coding-Tests prüfen keine Fähigkeiten, die man im Arbeitsalltag braucht“ seltsam. Es sind keine Fähigkeiten, die man jeden Tag einsetzt, aber man muss sie hervorholen können, wenn man sie braucht, und sie stützen die Arbeit, die man täglich macht. So wie ein Mechaniker nicht jeden Tag Motortheorie anwendet, man sein Auto aber ungern lange einem Mechaniker anvertrauen würde, der nicht weiß, wie ein Motor funktioniert.
  • Ich habe nie verstanden, warum Leute Coding-Interviews so sehr hassen. Aus Arbeitgebersicht ist es selbstverständlich, die tatsächlichen Fähigkeiten bis zu einem gewissen Grad zu überprüfen, statt sich nur auf den Eindruck aus Gesprächen zu verlassen.
    Ich habe von Kandidaten schon viele absurde Lösungen gesehen. Wir geben ihnen eine sehr einfache Kata: ein kleines Programm, das Konsolenausgabe erzeugt, hübsch refaktorieren und eine Funktion hinzufügen. Die Hälfte schafft es nicht einmal, es zum Laufen zu bringen. Viele geben sich überhaupt keine Mühe mit sauberem Code. Verlangt wird nur, dass es funktioniert und gut aussieht.
  • Als ich zuletzt Interviews hatte und ein paar LeetCode-Aufgaben löste, ließen sich die meisten trivial mit einer Kombination aus Iterator-Implementierung, Fold-Operation und, falls nötig, zusätzlicher Memoisierung lösen.
    Nicht alle Aufgaben sind so, aber die meisten einfachen und mittelschweren Coding-Interview-Fragen scheinen durch diese drei Schritte ziemlich allgemein abgedeckt zu sein. Als ich meinen ersten Job suchte, wusste ich von all dem nichts, deshalb fühlten sich Coding-Interview-Aufgaben mit der Zeit leichter an.
    In der Praxis habe ich Python nicht viel benutzt, aber das Schlüsselwort yield ist bei LeetCode-Aufgaben fast schon ein Cheatcode.
  • Persönlich sind Coding-Runden für Senior- und Staff-Rollen einfacher geworden. Selbst bei derselben Frage haben Interviewer andere Erfahrung und suchen nach anderen Signalen: Problemlösung, Kommunikation, Tests usw.
    Coding-Runden auf Junior- und „SDE II“-Niveau haben die Toxizität frisch beförderter SDEs, die daraus einen Wettbewerb zwischen dem Kandidaten und sich selbst machen. Es kam auch vor, dass jemand beleidigt war, als ich eine einfachere Lösung vorlegte, als der Interviewer im Sinn hatte.

• Der Text an sich ist im Großen und Ganzen gut, aber der Autor scheint die Vergütungshöhe stark aufzublähen. Es gibt eine Stelle, an der er sagt, ein stabiler, nicht-technischer Traktorenhersteller zahle 5.000 bis 10.000 Dollar pro Tag.
  Selbst wenn das inklusive Steuern ist und man es halbiert, und selbst wenn es nur für Software-Mitarbeiter gilt, ergibt eine durchschnittliche Vergütung von fast 1 Mio. Dollar pro Jahr keinen Sinn. Der Durchschnitt für Software Engineers in den USA liegt bei etwa 135.000 bis 150.000 Dollar, und in diesem Durchschnitt sind auch FAANG-Engineers aus den höchsten Vergütungsbändern enthalten.

  • Dem ganzen Text lässt sich über „Wenn die Zinsen steigen, sinkt das Venture-Capital-Funding“ hinaus nicht viel hinzufügen; er wirkt eher übertrieben. Selbst inklusive Benefits sind die Zahlen massiv aufgebläht.
    Es gibt zwar einzelne Personen, die so viel bekommen, aber soweit ich früher gehört habe, war eine Total Compensation von über 1 Mio. Dollar pro Jahr das Niveau früher Unicorn-Engineers bei Google.
  • 5.000 bis 10.000 Dollar pro Tag entsprechen bei 250 Arbeitstagen im Jahr 1,25 bis 2,5 Mio. Dollar. Woher so etwas bei einem Traktorenhersteller kommen soll, weiß ich nicht.
    Wahrscheinlich war es ein Tippfehler mit einer Null zu viel. 500 bis 1.000 Dollar pro Tag wären 125.000 bis 250.000 Dollar pro Jahr und deutlich plausibler.
  • Vermutlich verwendet er eine Berechnung wie „durchschnittliche Tagesvergütung, geteilt durch die tatsächlichen Arbeitstage über die gesamte Karriere, einschließlich des exponentiellen Wachstums der Aktien“.
    Im Original steht, dass stabile „Hyperscale-Hypergrowth“-Unternehmen im heutigen Tech-Umfeld erfahrenen Leuten jedes Jahr Gegenwerte von 10.000 bis 50.000 Dollar pro Tag zahlen, wenn man den Wert der exponentiell wachsenden Aktienvergütung einbezieht.
    Bei einem Jahresgehalt von 250.000 Dollar sind das nur etwa 1.000 Dollar pro Tag, aber wenn man über eine 40-jährige Karriere durch Aktienvergütung von wachstumsstarken Unternehmen 50 Mio. Dollar ansammeln kann, kommt man im Schnitt auf 5.000 Dollar pro Tag.
    Das ist eine etwas fragwürdige Rechnung, hätte klarer erklärt werden müssen und bleibt eine ziemlich ambitionierte Annahme, aber den Andeutungen im Text nach scheint das gemeint zu sein.
  • Unter „available for employment“ in seinem Lebenslauf finden sich ein Link zu Google-L10-Gehältern und ein Amazon Distinguished Engineer. Er scheint also jemand zu sein, dessen erwartete Vergütung auf der Software-Engineer-Leiter bei den obersten 0,01 % oder noch darüber liegt.
  • Das ist absurd. Er hat kein Gefühl für Marktvergütung, und wenn seine Erwartungen so danebenliegen, ist es nicht überraschend, dass er nicht eingestellt wird.
    Das sieht man auch im Lebenslauf: Er scheint L10 bei FAANG für das passende Level zu halten. Das ist ein extrem seltenes Level, und die Wahrscheinlichkeit, dass er mit seiner Laufbahn dort eingeordnet wird, liegt bei 0 %.
    Der ganze Text lässt sich als massiv aufgeblasenes Anspruchsdenken zusammenfassen.
    https://matt.sh/files/a-resume/resume.html

• Dieser Autor ist für ein erstaunliches Maß an Anspruchsdenken bekannt. Er hat ein paar kleinere Beiträge zu Redis geleistet und danach versucht, eine feindliche Übernahme zu starten.
  Vor diesem Hintergrund ist es nicht besonders überraschend, dass er Schwierigkeiten hat, eine Stelle zu finden, die seinen Erwartungen entspricht.
  https://news.ycombinator.com/item?id=9176800

  • Wenn antirez sagt: „Die Leute, die wesentliche Beiträge zur Redis-Codebase geleistet haben, kann man an einer Hand abzählen, und es bleiben noch Finger übrig; Matt Stancliff ist einer davon“, dann sieht es schon so aus, als habe er Kernbeiträge geleistet.
    Allerdings ist der angeführte Vorfall ziemlich alt und für das aktuelle Thema nur begrenzt relevant. Dass er ein starkes Anspruchsdenken hat, ist allerdings etwas peinlich.
    https://groups.google.com/g/redis-db/c/PxFeA0fHgO4/m/zD4IWbXlMOgJ
  • Weil es ein langer Text ist, hatte ich anfangs Mitgefühl, aber nach ein paar Hundert Wörtern wirkte es eher wie eine Beschwerde nach dem Motto: „Warum führt meine offensichtlich ausreichende Arbeit nicht zu Einstellungen?“ Das ist weniger ein Beleg für den gesamten Arbeitsmarkt als vielmehr ein logischer Fehlschluss und ein etwas zu großes Ego.
  • Inzwischen scheint er ein gewisses Maß an Selbsterkenntnis entwickelt zu haben. Zu der Zeit, als er auf der Konferenz diesen seltsamen Vorschlag machte, war das aber vermutlich nicht der Fall.
    Wenn man den GitHub-Sponsors-Link oben im Text ansieht, scheint er überzeugt zu sein, dass irgendjemand ein Sponsoring von 12.000 Dollar pro Monat abschließen wird.
  • Diese Beiträge waren nicht geringfügig. Ich weiß nicht, wovon du redest.

• Nach dem Motto „Wenn es dumm aussieht, aber funktioniert, ist es nicht dumm“: Wenn er klug genug war, alle Probleme seiner früheren Arbeitgeber zu sehen, diese Unternehmen aber trotzdem gescheitert sind, war er vielleicht nicht der ideale Mitarbeiter, für den er sich hält. Wenn er glaubt, Programmierinterviews seien für ihn zu niedrig angesetzt und nur minderwertige Leute kämen durch, er aber seine Miete nicht zahlen kann, dann sind diese Interviews vielleicht doch nicht so niedrig angesetzt.
  Mit AWS-Kenntnissen eine Query von 7 Sekunden auf 40 ms oder einen Batch-Job von 40 Stunden auf 20 Minuten zu reduzieren, entscheidet nur selten über Erfolg oder Scheitern eines Unternehmens. Dysfunktionales Management macht diesen Unterschied oft aus; wenn man das aber nur als Stoff für zynische Blogposts in Erinnerung behält, liefert das keinen Grund, einen einzustellen.
  Bis zu einem gewissen Punkt ist es gut, sich zu wünschen, dass Unternehmen ihre Systeme besser verwalten, aber wenn man sich zu sehr auf Datenbankdesign und AWS-Kostensenkungen konzentriert, ist man der mittlere Steinmetz in der McKinsey-Fabel.

  • Heißt das, er hätte als Systemadministrator auch die Produkt-, Sales- und Marketingprobleme lösen sollen? Von einer bestimmten Position aus sind die Handlungsmöglichkeiten begrenzt. Selbst wenn man Leuten sagt, dass sie teure Fehler machen, kann es wirklich schwer sein, sie zu überzeugen.
    Wenn das Marketingteam alles vermasselt, kann man sagen: „Das Marketing ist Mist“, aber viel mehr als darauf hinzuweisen, kann man kaum tun. Egal wie diplomatisch man es formuliert: Wenn man in der Organisationshierarchie nicht hoch genug steht, ist es schwer, das von der Engineering-Seite aus zu korrigieren.
    Früher kam ein Freund des CEO als neuer Marketingleiter, und als ich höflich Bedenken zu seinen Marketingentscheidungen äußerte, wurde ich vom CEO zurechtgewiesen. Danach ruinierte dieser Leiter die Marke und verwirrte die Kunden.
  • Wenn jemand klug genug ist, alle Probleme zu sehen, und das Unternehmen trotzdem scheitert, könnte er im Gegenteil sogar ein idealer Mitarbeiter gewesen sein.
    In den meisten Rollen, ob technisch oder nicht, bevorzugen Hiring Manager jemanden, der auf „Spring!“ fragt: „Wie hoch?“, und nicht jemanden, der „Nein“ oder „Warum?“ fragt.
    Man muss senior genug sein, um die Arbeit gut zu machen, aber nicht so senior, dass der eigene Vorgesetzte sich wie ein Junior fühlt.
  • Eine niedliche Interpretation, als kämen das Erkennen von Problemen und die Befugnis, sie zu lösen, immer gemeinsam.
    Du bist wahrscheinlich einer der Interviewer oder Mitarbeiter, von denen im Text die Rede ist.
  • Ich frage mich, was die McKinsey-Fabel ist.
  • Sein Tonfall und dieser Tonfall scheinen aus demselben Stoff geschnitten zu sein.

• Die Lage ist derzeit wirklich schlecht, aber meinem Verständnis nach leiden frische Absolventen und Juniors am meisten. Weil die Branche sehr profitabel wirkte, strömten viele Menschen in die Softwareentwicklung, und es wurden zu viele Informatikabsolventen hervorgebracht.
  Es ist schwer, ein Startup davon zu überzeugen, auf jemanden ohne Erfahrung zu setzen, und auch reifere Unternehmen wollen lieber einen Senior zum Preis von 1,5 Personen einstellen und ihn ähnliche Arbeit machen lassen, als zwei Juniors zu bezahlen. Früher gab es selbst bei C-Klasse-Unternehmen eine Pipeline vom Praktikum zur Festanstellung, aber heute scheint das viel seltener zu sein.
  Wegen steigender Zinsen, Investoren, die nur dem gerade Hype hinterherlaufen, und der Unsicherheit der nahen Zukunft scheint es schwieriger geworden zu sein, Investoren von neuen Produkten und Features und dem dafür nötigen Wachstum bei Engineers zu überzeugen.
  In den letzten Jahren wurden viele talentierte Leute entlassen, wodurch Unternehmen beim Recruiting einen großen Vorteil haben. Viele von ihnen sind bereit, deutliche Kürzungen hinzunehmen, also gibt es weniger Gründe, durchschnittliche Leute auszuwählen.

  • Bei mir war es genau umgekehrt. Die letzten zwei Jahre waren die beste Zeit, seit ich seit Anfang der 2010er in der Tech-Branche arbeite.
    Um 2019 herum dachte ich ernsthaft darüber nach, die Branche zu verlassen. Die ganze Branche war zu LeetCode-Pauken, Jagd nach Gesamtvergütung und gewöhnlichen Drohnen geworden. Es war schwer, Leute zu finden, die an herausfordernden und interessanten Problemen arbeiteten, geschweige denn an echten Problemen, und die Menschen, mit denen ich arbeitete, interessierten sich überhaupt nicht für Programmierung oder Informatik.
    In den letzten zwei Jahren habe ich jedoch mit mehreren Teams gearbeitet, die wirklich großartige Dinge tun, und auch Teams kennengelernt, in denen nur hartnäckige und kluge Leute waren. Insbesondere begannen sie, mit neuen Kniffen und Techniken rund um AI Projekte zu bauen.
    Jetzt bekommen viele kleine Teams, die schwierige Probleme lösen, Geld, und interessante, talentierte und wirklich merkwürdige Programmierer tauchen wieder auf. Menschen, die gern Dinge bauen und Probleme lösen, bekommen wieder Arbeit.
    Inflationsbereinigt bekomme ich wohl so wenig wie seit Langem nicht mehr, aber endlich macht die Arbeit wieder Spaß. Ich kann mit Leuten hacken, die vom Bauen besessen sind.
  • Aus Sicht eines Unternehmens, das Junior-Talente einstellt, ist das Wertversprechen wegen des zuletzt verbreiteten Jobwechsels im 1- bis 2-Jahres-Takt besonders unattraktiv. Wenn man sie ausbildet und sie dann gehen, oder wenn sie von Anfang an ein Gehalt verlangen, für das man auch Erfahrene bekommen kann, sinkt der Wert der Investition.
  • Ob es zu viele Informatikabsolventen gibt, weiß ich nicht, aber zumindest sehe ich überhaupt keinen Überschuss an Junior Engineers, wie ich sie erwarten würde.
    Nach meinem Maßstab ist ein Junior Engineer jemand, der Algorithmen und Datenstrukturen kennt, mindestens eine Programmiersprache wirklich gut beherrscht und in dieser Sprache schnell kleine Programme schreiben kann. Er hat keine Berufserfahrung, hat vielleicht noch nie an einem Projekt mit mehr als 10.000 Zeilen gearbeitet und kennt vielleicht weder CI/CD noch Docker, aber programmieren können muss er.
    Die meisten, die sich für Junior-Interviews vorstellen, können jedoch nicht coden. Sie können im Interview nicht einmal fünf Zeilen Code in der Sprache schreiben, von der sie behaupten, sie sei ihre Lieblingssprache. Das ist nicht anders, als sich als Junior-Koch zu bewerben, ohne kochen zu können, oder als Junior-Taxifahrer, ohne fahren zu können.
    Junior sollte „viel Wissen, aber keine Erfahrung“ bedeuten, doch in der IT glauben seltsamerweise viele, es bedeute „weder Wissen noch Erfahrung“.
    Wenn mir jemand sagt, wo ich die im Übermaß vorhandenen Junior Engineers finde, stelle ich sie gern ein.
  • Ein weiterer Grund, warum es für Junior Engineers schwieriger geworden ist: Es gibt heute viel mehr Nearshore- und Offshore-Outsourcing als früher. Zoom und Ähnliches sind viel besser als vor zehn Jahren, und alle sind an Remote Work gewöhnt.
    Ich habe mit hervorragenden Engineers aus Lateinamerika und Osteuropa gearbeitet, und heute ist das fast dasselbe wie die Arbeit mit Engineers in den USA. Ihr Englisch ist gut, die Arbeitszeiten überschneiden sich ausreichend, und vor allem Lateinamerika ist das genaue Gegenteil des Albtraums des Indien-Outsourcings Mitte der 2000er.
    Da ohnehin 99 % der Interaktionen mit Menschen über Zoom oder Meet stattfinden, macht es kaum einen Unterschied, wo jemand sitzt. Deshalb wird es schwieriger, US-Junior-Entwicklern US-Gehälter zu zahlen. Für dasselbe Geld oder weniger kann man hervorragende Senior-Entwickler aus Lateinamerika oder Osteuropa bekommen.
  • Früher hieß es „ein Senior zum Preis von 1,5 Personen statt zwei Juniors“, aber heute ist es eher: „Man nimmt die Stellenausschreibung ganz herunter und lässt die vorhandenen Seniors härter arbeiten. Weil man weiß, dass auch sie keine Optionen haben.“
    Positionen, auf die ich mich beworben oder für die ich Interviews hatte, wurden mehrfach gestrichen, und zwei Freunde sagten, in ihren jeweiligen Unternehmen passiere dasselbe. In einem Fall wurde aus einem Fünferteam ein Zweierteam, das einen Kernservice einer Airline betreibt.
    Für Einsteiger ist es definitiv schlecht, und es könnte noch schlimmer sein, als man denkt.

• In den letzten 15 Jahren habe ich Vollzeit Menschen eingestellt, überwiegend Engineers, und ich stimme vielen von Matts Kritikpunkten am modernen Recruiting stark zu.
  Die meisten technischen Interviews haben ungefähr so viel mit der Arbeitsleistung zu tun, wie wenn man einen Bäcker einstellt, ihn fragt, wie Elektronenorbitale Glutenbindungen erzeugen, und ihn ablehnt, wenn er nicht sofort eine gültige Orbitalkonfiguration zeichnen kann.
  Matts Analogie passt gut zu transaktionalem Recruiting wie der Einstellung von Auftragnehmern, aber weniger zu Situationen, in denen beide Seiten erwarten, in den kommenden Jahren länger zusammenzuarbeiten. Unternehmen, die Engineers einstellen, müssen Menschen normalerweise dazu bringen, als Team Brot zu backen, und dieses Team ist manchmal sehr groß.
  Wenn Verantwortlichkeiten immer stärker ausdifferenziert werden, braucht man tatsächlich mindestens einen Bäcker, der eine gültige Orbitalkonfiguration zeichnen kann. Und wenn man einen Bäcker gefunden hat, der stark in Quantenmechanik ist, muss man nun auch prüfen, ob diese Person für die Zusammenarbeit furchtbar ist.
  Deshalb ist Recruiting über Empfehlungen früher wie heute König. Der beste Test dafür, ob jemand gute Arbeit leistet, ist, ein paar Jahre mit ihm zusammenzuarbeiten.

  • Recruiting über Empfehlungen existiert praktisch nirgendwo wirklich.
    Selbst wenn ich Leute empfohlen habe, von denen ich wusste, dass sie wirklich hervorragende Software Engineers sind, und für die ich mit meiner eigenen Anstellung bürgen konnte, wurden sie nicht anders behandelt als andere Kandidaten.
  • Inzwischen ist genau das die Realität. Auch Bäcker werden so interviewt.
  • Wenn es sich nicht um ein Tech-Unternehmen der obersten 1 % handelt, passt diese Logik nicht gut. Jedes Tech-Unternehmen denkt, es müsse „das beste Brot“ backen und brauche deshalb die besten Bäcker.
    Realistisch ist das nicht, aber wenn Investoren einem Millionen von Dollar geben, damit man sie ausgibt, muss man sie irgendwie ausgeben.
  • Ein Denken wie „wir brauchen einen Bäcker, der Orbitalkonfigurationen zeichnen kann“ trägt zu diesem toxischen Arbeitsmarkt bei.
    Es läuft einzig darauf hinaus, dass es zu viele Bewerber und zu wenige Jobs gibt. Geschichten über Inflation, Brotbacken, Zinsen und Teambuilding sind alles Symptome eines Anspruchsdenkens.
    Wenn es nur zwei Bewerber gegeben hätte, hätte man nicht so gedacht.

• Die Überschlagsrechnungen in diesem Artikel waren für mich allesamt verwirrend.
  Ich weiß nicht, wo die Grundlage „pro Tag“ herkommt. Unklar ist, ob es um Vergütung für Führungskräfte oder für Mid-Level-/Senior-Engineers geht. 5.000 bis 10.000 Dollar pro Tag entsprechen 1 bis 3 Millionen Dollar pro Jahr; das ist vor allem in Jahren mit stark gestiegenem Aktienkurs möglich, aber nicht so üblich, wie es der Artikel darstellt.
  Dass solche Zahlen „nicht von Google oder Apple, sondern von einem Traktorenhersteller oder einem Schwerindustrieunternehmen kommen, das seit Jahren konstant gute Ergebnisse liefert“, ist ebenfalls schwer zu glauben. Es heißt zwar, es seien versteckte Unternehmen, aber ich frage mich, ob es Beispiele gibt. In Nicht-Tech-Unternehmen gelten Software Engineers normalerweise als Kostenstelle, und die Vergütung ist deutlich niedriger.
  Auch die Fußnote „wenn man reale Inflation und Lebenshaltungskosten mit 7 bis 13 % pro Jahr ansetzt“ müsste eine Berechnungsgrundlage liefern, wenn sie für die letzten zehn Jahre eine derart außergewöhnliche Inflation behauptet.

  • Da der Autor angibt, mehr als 20 Jahre Erfahrung zu haben, scheint er faktisch mit VP-Rollen zu vergleichen. Viele der über 40-Jährigen, die ich bei FAANG getroffen habe, waren tatsächlich Senior Staff oder höher bzw. Director oder höher, daher sind die Zahlen vielleicht nicht ganz so verrückt, wie sie auf den ersten Blick wirken.
    Um auf diese Zahlen zu kommen, müsste man allerdings auch den Anstieg des Aktienwerts berücksichtigen. Und ich denke, dass deutlich mehr Leute FAANG ganz verlassen, als dort auf VP-Niveau aufzusteigen.

• Es mag in dem Artikel gute Punkte geben, die darin vergraben sind, aber was beim Lesen ankommt, ist vor allem Bitterkeit mit wenig Selbstreflexion. Er wirkt wie jemand, mit dem die Zusammenarbeit schwierig ist und der die Verantwortung dafür anderen zuschreibt.

  • Ich habe angefangen zu lesen, aber schon früh kam dieser bittere Ton eines 115.000-Wörter-Beschwerdetextes rüber.
    Es wirkt weitschweifig, etwa wenn er sogar Fotos von sich zeigt, um zu beweisen, dass er trainiert. Jeder hat seinen eigenen Stil, aber es drängt sich der Gedanke auf, dass das Scheitern in Interviews vielleicht kein Kompetenzproblem ist, sondern ein Einstellungsproblem.
  • Bei einer Stelle im Sinne von „Ich habe noch nie ein Coding-Interview bestanden. Coding-Interviews stellen die falschen Leute ein!“ habe ich aufgehört.
  • Ich verstehe nicht, warum Vergütung im ganzen Text der einzige Faktor ist. Geld ist gut, aber ist nicht auch wichtig, was man baut?
  • Das Zitat „Vergleich ist das schlimmste Gefühl und der Tod des Glücks. Ich vergleiche meine Position mit Leuten, die vor 20 Jahren zu Apple oder Microsoft gegangen sind und nie wieder weggegangen sind“ kann ich nachvollziehen.
    Aber wenn man das Glück hat, solche Leute zu kennen, könnte man diese Verbindungen nicht auch nutzen, um die eigene Karriere zu stärken?
    Es gibt Leute, die zur richtigen Zeit beim richtigen Unternehmen einsteigen und Millionen verdienen; wenn ich in meinem nächsten Job 150.000 Dollar bekäme, wäre ich je nach Region ziemlich zufrieden. Es wäre schön, wenn Remote-Arbeit weiterhin breit möglich bleibt, sodass man an einem Ort mit niedrigen Lebenshaltungskosten wohnen kann.
    Allerdings scheint der Autor 150.000 Dollar nicht als viel Geld zu betrachten, und dem Artikel nach hat er mehr Erfahrung und Seniority als ich.