- Im Gegensatz zur Freude am Programmieren selbst fühlt sich der Software-Arbeitsplatz wie eine Umgebung an, die mehr Codeproduktion verlangt, statt nach dem Zweck von Design und den Kriterien für Erfolg zu fragen
- Die Erfahrung, 2023 mehrere Wochen lang Stellenanzeigen zu lesen, zerstörte die Erwartung an einen „besseren Ort“; besonders die Startup-Kultur zeigt unverblümt die Haltung: „weniger fragen, mehr produzieren“
- Auch in großen Tech-Unternehmen werden Entwickler anhand von Zahlen wie Größe des Backend-Stacks, Interview-Scores und Leistungsbeurteilungen behandelt; das persönliche Urteil darüber, wie Code geschrieben werden sollte, wird noch bedeutungsloser
- Die Haltung „mehr bauen und weniger fragen“ kann die Menge an Code erhöhen, führt aber zu schlechterer Software; Trendtechnologien und Trägheit sickern bis in Sprachen, Bibliotheken, Frameworks und Code-Patterns ein
- Die Arbeit, die der Autor sich wünscht, besteht darin, Engineering-Probleme zu lösen, die aus bereits existierenden gesellschaftlichen Bedürfnissen entstehen; das „Warum“ eines Systems sollte Sprache, Paradigma, Architektur und Syntax bestimmen
Die Diskrepanz am Software-Arbeitsplatz
- Der Autor sagt, dass er in keine der Software-Engineering-Rollen, die er durchlaufen hat, wirklich gepasst habe
- Sobald er die innere Logik einer Codebase einigermaßen verstanden hatte, wurde der technische Aspekt langweilig; danach wollte er nicht mehr mehr machen, sondern anders machen
- Bei Designentscheidungen und Zielen kamen ihm immer wieder folgende Fragen in den Sinn
- Warum machen wir diese Arbeit?
- Warum machen wir sie auf diese Weise?
- Gibt es keinen besseren Weg?
- Welche Kennzahlen verwenden wir, um Erfolg zu beurteilen, und warum diese?
- Auch wenn er solche Fragen nicht immer laut stellte, hörte er, er „denke zu viel“ oder „kümmere sich zu sehr“ – in Zeit, in der er mehr Code hätte ausstoßen können
- Es ging nicht einfach darum, dass Talent und Rolle nicht zusammenpassten; vielmehr fiel es ihm schwer, der Art zuzustimmen, wie Organisationen betrieben werden, und er wollte sie verändern, statt sie aufrechtzuerhalten
Startup-Stellenanzeigen und „mehr bauen, weniger fragen“
- Die Erfahrung, 2023 mehrere Wochen lang Stellenanzeigen zu prüfen, ließ die Erwartung zerbrechen, dass es „irgendwo etwas Besseres“ geben müsse
- Er bewertet, dass 90 % der Jobbeschreibungen Code betrafen, den erfolgreiche Bewerber schreiben würden, der nicht nur von den Problemen der Menschheit, sondern auch von wichtigen persönlichen Problemen entkoppelt wirkte
- Startup-Kultur wird als das deutlichste Beispiel für die Haltung der Branche dargestellt: „mehr Code produzieren und weniger Fragen stellen“
- Viele Startups werden dafür kritisiert, Investorengeld zu verschieben und Nutzer davon überzeugen zu wollen, dass sie ein nur begrenzt nützliches Produkt brauchen, um zahlende Kunden zu gewinnen
- Startups scheitern in der Regel, und zurück bleibt schwer wartbarer Spaghetti-Code, der unter dem Druck entstanden ist, ihn nicht in Monaten, sondern in Wochen zu schreiben
- Solcher Code wird, abgesehen vielleicht als Beispiel für schlechte Coding-Praktiken, nie wieder angesehen; die Zeit der Engineers ist verschwendet, während Risikokapital an Menschen fließt, die bereits über erhebliches Kapital verfügen, und dann wieder in andere Startups investiert werden kann
- Der Autor kritisiert, dass Stellenanzeigen solche Arbeit als spannend verpacken, als würde sie das Leben von Menschen bereichern und Engineering-Wachstum anregen
Auch in großen Tech-Unternehmen verschwindet Autonomie
- Etablierte Tech-Unternehmen unterscheiden sich organisatorisch und finanziell von Startups, stehen kulturell aber nicht in starkem Kontrast dazu
- Code, der bei FAANG geschrieben wird, kann echte Nutzer erreichen, doch die persönlichen Gedanken darüber, irgendeinen Aspekt des Codes zu gestalten, werden noch irrelevanter
- Der Autor kritisiert, dass Entwickler auf folgende Weise zu Zahnrädern in der Maschine werden
- Das Produkt kann die schlimmsten Seiten des Kapitalismus auf immer heimtückischere Weise automatisieren
- In der Praxis wird man zu Zahlen wie der Größe des Backend-Stacks, dem Score im technischen Interview oder der Leistungsbewertung
- Das Problem ist nicht nur diese Realität selbst, sondern auch, dass von Engineers erwartet wird, eine leere, erniedrigende Wiederholungsarbeit stärker zu begehren als andere Arbeiter – und dass sie noch stärker davon abgehalten werden, irgendeinen Aspekt davon zu hinterfragen
Engineering ohne kritisches Denken
- Programmierer konzentrieren sich nur auf das Wie, sind nur selten daran beteiligt, was gebaut wird, und dürfen fast nie fragen, warum es gebaut wird
- Selbst Entwicklern, die die Systeme, die sie produzieren, kritisieren können und wollen, wird die Botschaft vermittelt, diese Haltung außerhalb des Arbeitsplatzes zu lassen
- Der Autor empfindet, dass Entwicklern sogar verboten wird, den Mangel an Autonomie und Kreativität zu benennen, der ihrer Rolle innewohnt; sie können zwar mehr bauen, aber kaum anders oder besser bauen
Eine Struktur, in der die Menge an Code wächst, die Software aber schlechter wird
- Die do-more-ask-less-Haltung der Tech-Branche kann mehr Code hervorbringen, führt aber zugleich zu schlechterer Software
- Selbst wenn Kapital und äußere Bedingungen Raum lassen, nachhaltige, positive oder zumindest praktisch nützliche Software zu schaffen, geschieht das wegen Trägheit oft nicht
- Es ist einfacher und meist praktikabler, Trends zu folgen und den bestehenden Zustand zu reproduzieren
- Dieselbe Trägheit sickert auch in den gesamten Tech-Stack ein, auf dem gesellschaftlich nutzlose Produkte laufen
- Sprachen
- Bibliotheken
- Frameworks
- Code-Patterns
- Die Tendenz, Neuheit und Gimmicks über echte Innovation zu stellen, plagt die gesamte Branche; wenn man keine untypischen Probleme löst, braucht man auch kein untypisches Engineering
Kriterien für das gewünschte Engineering
- Die interessantesten Engineering-Probleme sind nicht solche, die technologischen Fortschritt um seiner selbst willen anstreben oder künstlich nicht vorhandene Marktnachfrage erzeugen wollen, sondern Probleme, die innerhalb der Gesellschaft natürlich entstehen
- Gesellschaftliche Bedürfnisse sind der beste Motor für Innovation, und auch frühe bahnbrechende Leistungen der Informatik entstanden im Dienst eines größeren öffentlichen Nutzens
- Die gewünschte Arbeitsweise besteht darin, dass das Warum des Aufbaus eines Systems jedes Wie leitet
- Programmiersprache
- Paradigma
- Architektur
- jede einzelne Codezeile
- Syntaxelemente
- Dieses „Warum“ sollte keine Geschäftskennzahl sein, die um ihrer selbst willen existiert, sondern ein tatsächlich bestehendes, reales Bedürfnis widerspiegeln
Auf der Suche nach Menschen mit denselben Werten
- Der Autor hat bislang niemanden getroffen, der diese Werte in sinnvoller Weise teilt und solche Engineering-Arbeit machen möchte
- In der Interaktion mit der Branche fühlt er sich häufig isoliert, ist aber von seinen Arbeitswerten und von der Bedeutung dessen, was gesagt werden muss, überzeugt
- Er bittet solche Menschen, sich zu melden; er möchte wissen, ob es bereits einen solchen Ort gibt, und hält es andernfalls für sinnvoll, ihn gemeinsam aufzubauen
- Für Consulting-Arbeit in seinen Interessengebieten, die vernünftig zu seinen Werten passt, ist er offen
1 Kommentare
Hacker-News-Kommentare
Was OP hasst, ist weniger die „Programmierbranche“ als vielmehr die Unternehmenswelt. Ich habe mit Entwicklern gearbeitet, deren Erwartungen daran, was die „Realität“ von Entwicklern verlangt, nicht mit der Wirklichkeit übereinstimmten, und ich war selbst auch einmal so
Unternehmen interessieren sich nicht für Raffinesse, Abstraktion, geistreichen oder schönen Code. Sie wollen Entwickler, die entsprechend den geschäftlichen Anforderungen Features am Fließband liefern
Einzelne Zahnräder im Getriebe wie Manager, Führungskräfte oder Kollegen können sagen, sie würden einem erlauben, die „Kunst“ des Programmierens auszuleben, aber wenn man wirtschaftlich nichts zum Unternehmen beiträgt, wird man am Ende als Belastung betrachtet
Es ist besser, Freude und Kunst im Programmieren außerhalb der Unternehmenswelt zu suchen und nicht zu erwarten, dass sich die „Branche“ dafür interessiert, wie oder warum programmiert wird. Sie schaut nur darauf, ob die auf den Bildschirm getippten Zeichen in Geld verwandelt werden. Wenn man das akzeptiert, wird das Leben viel weniger frustrierend, und man kann auch bei der Arbeit Spaß finden. Es muss dann nur nicht unbedingt „Kunst“ sein
Bei der Aussage „Unternehmen interessieren sich nicht für Raffinesse, Abstraktion, Witz oder schönen Code“ denke ich allerdings: Bin ich dann etwa die Unternehmenswelt?
Was ich meinen Kollegen sagen möchte, ist: Sorgt erst einmal dafür, dass es gemäß der Spezifikation funktioniert, bevor ihr versucht, Raffinesse, Abstraktion, Witz oder Schönheit einzubringen. Sonst ist all das wertlos
Erst wenn man einigermaßen geübt darin ist, es richtig zum Laufen zu bringen, kann man es korrekt machen und vielleicht auch schnell
Selbst wenn man das, was man liebt, zum eigenen Geschäft macht, etwa Möbel herstellt, wollen Kunden manchmal das „Falsche“ oder sind nicht bereit, für bessere seltene Materialien zu zahlen
Es ist immer besser, das, was man wirklich liebt, als reines Hobby ohne Arbeitselemente zu machen
Bezahlt wird man dafür, etwas abzuliefern. Ob es effizient ist, ob es ein Problem gelöst hat, ob es Geld eingebracht hat oder ob es nur eine Checkbox angehakt hat, ist weder mein Sorgenfeld noch in meiner Kontrolle. Man plant seine Aufgaben, erledigt sie, behandelt die Leute freundlich und geht um 17 Uhr nach Hause
Das heißt nicht, dass man schlampig schlechten Code schreiben oder sich nicht um die nachgelagerten Auswirkungen von Entscheidungen kümmern sollte. Dafür werden Leute auch entlassen
Wichtiger ist, es nicht zu übertreiben. Man sollte nicht versuchen, jede mögliche Zukunft des Produkts vorherzusehen und alle Szenarien abzudecken, nicht mit Gewalt ein offensichtlich besseres Design durchdrücken, nicht versuchen, noch schneller zu liefern, und auch nicht andere Bugs beheben, die man nebenbei bei der eigenen Aufgabe entdeckt. Einer Beförderung hinterherzujagen war eine der schlimmsten Stressquellen, die ich mir selbst geschaffen habe
Man muss erkennen, ob das eigene Projekt hochintensiv ist, stark wächst, in einer reifen Phase steckt oder kurz vor Entlassungen steht, und sich entsprechend verhalten
Und man muss Sichtbarkeit bekommen und Erfolge für sich verbuchen. Einmal pro Quartal eine Demo machen, den Code anderer reviewen, an Design-Meetings teilnehmen und Fragen stellen, auf E-Mails oder Messenger-Nachrichten, die vor 17 Uhr eingehen, schnell antworten und die Dinge liefern, die man zugesagt hat. Wirke wie eine nützliche Ressource, aber sobald sich auch nur die geringsten Anzeichen von Lieferdruck zeigen, dränge sie mit deinem Verhalten zurück
Und schließlich ist es gut, immer so vorbereitet zu sein, dass man innerhalb von zwei Wochen das nächste Vorstellungsgespräch führen könnte
Ein Arbeitsplatz ist nur ein Arbeitsplatz. Keine Familie und auch keine Leiharbeitsfirma
Nach dem Motto: Dass die Flügel während des Flugs am Flugzeug bleiben, verbessert keine Key Performance Indicators, also entlassen wir alle, die ihre Zeit mit solchen irrelevanten Sorgen verschwenden
Das implizite Ziel ist, dass es populär genug wird, damit Programmierer sich kollektiv darauf einigen, in der „Unternehmenswelt“ mehr Mitspracherecht zu haben. Zum Beispiel, indem sie verlangen, das „Ausspucken“ neuer Features zu verlangsamen und mehr in Softwarequalität zu investieren
Obwohl ich seit über 30 Jahren als Entwickler arbeite, gibt es in OPs Beitrag leider nicht vieles, dem ich entschieden widersprechen könnte. Ich wünschte, ich könnte es.
Junge Leute lernen, dass es bei Technik und beim Bauen von Software um eine kreative Tätigkeit geht, in der man angeborene Leidenschaft ausleben kann. Eine bestimmte Art zu denken, die sich zu Symbolen, Abstraktion und Wiederholung hingezogen fühlt, sammelt sich in diesem Beruf. Die Jahre vergehen, und die Aktionäre werden fetter.
Die Wahrheit ist, dass Softwareentwicklung fast vollständig eine wirtschaftliche Tätigkeit ist, und zwar eine mit ausbeuterischem Charakter. Die Arbeitsumgebung ist sicher besser, als Gold oder Bauxit aus dem Boden zu holen, aber die meisten von uns hacken Code aus einer Code-Ader, um andere reich zu machen. Die Leute in den Eckbüros, und die über ihnen mit den Yachten.
Sie interessieren sich nicht dafür, was wir tun, nicht für unsere Pose, es als Kunst oder Handwerk zu sehen, und nicht für das, was wir für wichtig halten. Tatsächlich halten sie uns meist für Verlierer, die ihre Zeit verschwenden https://ribbonfarm.wpenginepowered.com/wp-content/uploads/2009/10/hughMcLeodCompanyHierarchy.jpg
Wie andere hier schon gesagt haben, liegt der grundlegende Fehler darin, in Unternehmensarbeit Sinn finden zu wollen. Aber Menschen brauchen Sinn, und wenn man zu viel von seinem einzigen Leben mit Arbeit verbringen muss, gibt es nicht viele Alternativen. Ich kenne die Antwort nicht.
Es gibt mindestens zwei Arten von Leuten, die die Software-„Unterschicht“ für Verlierer halten.
Die einen sehen darin eine Tätigkeit, die Können erfordert, bei der die Arbeiter wertvolle Fachkenntnis haben und es wert sind, angehört zu werden. Trotzdem seien sie nur bezahlte Ware und keine echten Player, die wie sie selbst „die klügste Person im Raum“ oder „Führungskraft“ werden und große Belohnungen einstreichen, also eben Verlierer.
Die anderen halten Softwarearbeit für gering qualifizierte Drecksarbeit, die Arbeiter für ein vorübergehendes notwendiges Übel und in Fragen von Vergütung und Loyalität für anmaßend, weil sie ihren Platz nicht kennen. Ihre Meinung sei nichts wert. Natürlich gelten Softwarearbeiter in der Business-Welt auch deshalb als Verlierer, weil sie nicht wie echte Player agieren und sich nicht persönlich bereichern können.
Letzteres ist die deutlich schlimmere Lage.
Wenn das, was ich baue, andere reich macht, ist das gut. Es bedeutet, dass das, was ich gebaut habe, Wert hat. Ich möchte, dass alles, was ich baue, Wert hat.
Irgendwann habe ich vielleicht genug geübt, gelernt und genug Erfahrung und Ersparnisse gesammelt, um andere verantwortungsvoll beschäftigen zu können.
Wenn ich eine gute Idee habe und sie richtig umsetze, besteht auch für mich die Möglichkeit auf diese Yacht. Das nennen wir wirtschaftlichen Anreiz oder Motivation.
„Die Richtung, in die sich die Branche bewegt“, ist meiner Ansicht nach schon seit Langem ein Prozess der Unterwanderung durch Hochstapler. Der Wert, den man durch das Schreiben von Software schaffen kann, ist enorm, und die hohen Gehälter in der Tech-Branche spiegeln das wider. Dieser Reichtum zieht alle möglichen Hochstapler an.
Am deutlichsten sieht man das bei dem Katz-und-Maus-Spiel, qualifizierte Engineers einzustellen. Das Verhältnis von oben zu unten im Hiring-Funnel ist höher als je zuvor.
Weniger offensichtlich ist, dass ganze „Hochstapler-Rollen“ wie Produktmanager und Scrum Master entstanden sind. Sind sie erst einmal drin, holen sie mehr davon rein, weil Sicherheit in der Zahl liegt.
Kluge Menschen, die innovieren können, müssen heute den Prozess von Kreativität, Innovation, Forschung, Entdeckung und Engineering an die Hand nehmen und inkompetente Personen hindurchführen. Oft haben genau diese inkompetenten Personen am Ende die Entscheidungsgewalt darüber, wofür die klugen Leute ihre Zeit aufwenden.
Wenn du erlebt hast, dass Engineers schon in den ersten 10 Minuten eines Meetings wissen, wie man das Kundenproblem löst, und Produktmanager dann der Reihe nach zu genau demselben Schluss geführt werden müssen, dann sieht das genau so aus.
Dann bekommt man Performance-Probleme, Sicherheitslücken, fehlende Observability, schlechte Skalierbarkeit sowie absurde Konfigurations- oder Abhängigkeitsprobleme.
Gerade FAANG-Unternehmen sind voll von diesem Müll. Das ist Code, der für „Prahler-Posts“ zur Beförderung geschrieben und dann faktisch sich selbst überlassen wurde, weil die Leute weitergezogen sind, bevor die billigen Abkürzungen sichtbar wurden.
Glattes Gerede ist für Software-Engineers zu einer wertvolleren Fähigkeit geworden als solides Design, und die Folgen sieht man überall.
Nach über 10 Jahren in der Entwicklung von Unternehmenssoftware ist mir das Ergebnis oder wohin dieser Zirkus steuert inzwischen egal.
Was mich jetzt interessiert, ist nur noch das Gehalt, auf dem eine absurd hohe Zahl steht.
Ich nenne das Entwicklung, bei der man sich jetzt genau genug kümmert, damit es einem später nicht allzu sehr egal sein muss.
Ich habe 40 Jahre als Programmierer verbracht, aber ich habe immer Wege gefunden, Kreativität und Vorstellungskraft einzusetzen, und versucht, nicht zu jemandem zu werden, der bloß mechanisch Code eintippt.
In meinem letzten Job habe ich ein kleines Team geleitet, strategisch wichtigen Code gebaut und dabei auch Erfolg gehabt. Wenn dieser Code nicht jederzeit funktionierte, waren jeden Tag 100.000 Menschen wütend, und dazu eine ganze Reihe wütender Führungskräfte.
Am Ende war ich es leid, zu hart zu arbeiten, und beschloss, in Rente zu gehen.
Wenn dich die Arbeit nicht motiviert, musst du einen neuen Weg oder einen neuen Ort finden, Programmierer zu sein. Zum Beispiel dein eigenes Unternehmen gründen oder etwas Neues ausprobieren. Andernfalls musst du dir einen anderen Beruf suchen.
Sich neu zu erfinden ist nicht leicht und heute viel schwieriger, aber wenn man es wirklich will, kann man es schaffen.
Selbst wenn ich für Unternehmensherrscher arbeite, gibt mir Programmieren Energie. Maschinen zu überzeugen, sich nach meinem Willen zu bewegen, wird mir nie langweilig. Ich könnte das den ganzen Tag tun, ohne müde zu werden
In seltenen Phasen, in denen viel Programmierung anfällt, merke ich oft erst hinterher, dass ich 15 Stunden am Stück daran gesessen habe, ohne die Zeit zu bemerken. So ist es seit fast 20 Jahren
Leider ist Programmieren nur ein kleiner Teil der Arbeit. Je weiter die Karriere voranschreitet, desto deutlicher wird das. Manchmal verbringe ich tatsächlich nur ein oder zwei Stunden pro Woche mit echtem Coden
Der Rest geht für absurde Meetings drauf, dafür, Menschen an die Hand zu nehmen, die sowieso nicht lesen, andere Leute dazu zu bringen, Maschinen so zu überzeugen, wie sie es brauchen, für „Planung“ und ähnlichen Lärm. Der einzige andere lohnende Teil ist das Mentoring junger Programmierer
Ich mache weiter, weil es ein sicherer Weg bis zur Rente ist und ich fast da bin. Mein Plan für danach ist, aus purer Freude das zu programmieren, was ich selbst bauen möchte
Ein Teil des Problems ist meiner Meinung nach, dass viele Entwickler an sinnvollen Projekten mit guten Leuten arbeiten wollen und dabei trotzdem das Gehalt behalten möchten, das sie jetzt bei $FAANG bekommen, oder die Beteiligung, die sie bei einem $STARTUP hätten
In der Praxis behandeln Angestellte Sinn, Unabhängigkeit, Eigenverantwortung und Work-Life-Balance wie eine Währung und nehmen sogar Gehaltskürzungen in Kauf, um sinnvolle Arbeit zu bekommen
Es gibt bessere Jobs. Ich habe selbst einen gefunden. Aber wenn man gerade in einem Ad-Tech-Unternehmen oder einem KI-Startup arbeitet, muss man fast sicher damit rechnen, deutlich weniger Gehalt zu sehen als man gewohnt ist
Ich bin in einem einkommensschwachen Haushalt aufgewachsen und habe auch als Erwachsener mehrmals mit sehr wenig Geld gelebt, deshalb fühlt sich das für mich ganz natürlich an. In mancher Hinsicht ziehe ich es fast sogar vor
Meine psychische Gesundheit wird eher durch übermäßigen Stress oder Sinnlosigkeit bedroht als durch ein knappes Budget
Es ergibt für mich nur dann Sinn, weiter etwas zu tun, bei dem ich mich nicht besonders positiv fühle oder schlimmer noch nur negative Gefühle habe, wenn es einen sehr konkreten Plan für das zusätzliche Geld gibt und ich diesen Plan mit sehr hoher Wahrscheinlichkeit auch umsetzen werde
Diese Lebensweise passt nicht für alle, aber wenn man weniger materialistisch ist als der Durchschnitt oder keine Angst vor einem sparsameren Leben hat, würde ich sehr dazu raten, das in Betracht zu ziehen. Erst recht, wenn man sich heutzutage mehr als einmal pro Woche fragt, wie lange man „diesen guten Job“ noch aushält, ohne daran zu zerbrechen
Die Werkzeuge, die wir bauen, helfen Menschen, die echte Dinge errichten, sicherer und effizienter zu arbeiten. Zu sehen, wie greifbare Projekte entstehen, bei denen einem wirklich die Augen aufgehen, ist großartig
Es stimmt zwar, dass die FAANG-Vergütung viel höher ist, aber ich mag meinen aktuellen Arbeitsplatz wirklich sehr, und zum ersten Mal seit Langem verspüre ich nicht den Drang, nach ein paar Jahren wieder etwas anderes suchen zu müssen
Die meisten können sich keine hohen Gehälter leisten. Sie brauchen interessierte und stark intrinsisch motivierte Menschen. Man muss auch bereit sein, in vielerlei Hinsicht flexibel zu sein, und in kleinen Firmen ist viel mehr verhandelbar
Solche Firmen tauchen nicht einfach vor einem auf, man muss selbst nach ihnen suchen
Die Lösung ist, unabhängig zu werden, eigene Ideen umzusetzen und an Verbraucher zu verkaufen. Das kann das eigene Startup sein, aber bei mir bedeutete es, Indie-Game-Entwickler zu werden
Eines meiner Spiele, YOYOZO, wurde in Ars Technicas „Best Video Games of 2023“ aufgenommen, daher fühlt sich meine Entscheidung für mich richtig an
Das ist wie Sex zu mögen, aber keine Prostituierte werden zu wollen. Egal was man tut, wenn man es nicht zu den eigenen Bedingungen tun kann, kann einen das unglücklich machen
Mit LeetCode geht es mir ähnlich
Ich mag Software Engineering, aber LeetCode bringt mich dazu, Software Engineering zu hassen
Ich will einfach coole Dinge bauen. Ich will nicht einen LRU-Cache oder noch eine mittelschwere bis schwere LeetCode-Aufgabe auswendig lernen und in 40 Minuten implementieren
Natürlich wird es deswegen Firmen geben, die gar nicht erst mit mir sprechen wollen, aber das ist in Ordnung. Ich habe solche Interviews ohnehin nie bestanden und musste immer Jobs finden, bei denen ich im Gespräch kein Live-Coding machen musste
Die Erwartung ist in Wirklichkeit, die optimale Lösung perfekt auswendig zu können. Diese optimale Lösung wurde wahrscheinlich von irgendeiner promovierten Person gefunden, die Algorithmen erforscht hat
Am Ende implementiert man ohnehin nur Endpunkte für ein CRUD mit 1.000 monatlich aktiven Nutzern