Vom Praktikanten zum Principal Product Engineer: Wie Side Projects meine Karriere beschleunigt haben

Ich bin mein ganzes Leben lang leidenschaftlich an Technologie interessiert gewesen. Als Kind habe ich mit Turbo Pascal angefangen und seitdem an Embedded-Systemen, Frontend-/Backend-Entwicklung und Machine-Learning-Projekten gearbeitet.

iOS/macOS kamen im Rahmen eines kurzen Universitätskurses ins Spiel. Innerhalb eines Monats hatte ich eine neue Sprache gelernt und ein Praktikum bei Readdle bekommen. Fünf Jahre später wurde ich Principal Engineer. Trotzdem betreue ich weiterhin neue Teammitglieder, nehme an Bewerbungsgesprächen teil und entwickle meine Führungsqualitäten weiter, um mich weiterzuentwickeln.

Mein Weg von null Erfahrung mit Apple-Plattformen bis zu meiner heutigen Rolle hat mich dazu inspiriert, meinen Lernansatz zu reflektieren und die wichtigsten Richtungen aufzuzeigen, die mir beim Wachsen geholfen haben. Ich glaube, dass meine Erfahrung für andere Engineers wertvoll sein kann, die feststecken oder sich bei ihren nächsten Schritten unsicher fühlen.

Hier sind die wichtigsten Ansätze und Ressourcen, die mir geholfen haben und dir vielleicht auch helfen können.

Wie Side Projects mein Wachstum beschleunigt haben

Nachdem ich das Mid-Level erreicht hatte, geriet ich beruflich auf ein Plateau. Ich hatte das Gefühl, Aufgaben schnell und effizient zu erledigen, Bugs problemlos zu beheben und ein solides Verständnis dafür zu haben, wie man die Architektur für neue Features entwirft. Aber ich konnte nicht genau begreifen, was mich davon trennte, ein echter Senior Engineer zu sein.

Die Veränderung geschah schrittweise. Rückblickend wurde mir klar, dass der Unterschied weder ein großes Projekt bei der Arbeit noch eine Beförderung war. Es war all die Zeit, die ich außerhalb der Arbeit mit Programmieren verbracht hatte.

Abends und an Wochenenden habe ich kleine Projekte gebaut, manchmal nur zum Spaß, manchmal um eine Idee zu testen. Diese Side Projects haben mich mit realen Problemen außerhalb meines üblichen Aufgabenbereichs konfrontiert. Diese praktische Erfahrung wirkte sich direkt auf meine Arbeit aus und verschaffte mir einen Vorteil, wenn ich unbekannte Probleme angehen musste.

Die wichtigste Lektion war, dass die meisten Fähigkeiten in der Softwareentwicklung nicht an eine einzelne Sprache oder Plattform gebunden sind. Ein paar Beispiele:

• Selbst wenn du über die Architektur von iOS-/macOS-Apps liest, erkennst du wahrscheinlich ähnliche Muster in der Webentwicklung oder in eingebetteten Systemen wieder.
• Python-Kenntnisse im Kontext von Machine Learning können dir helfen, in einer völlig anderen Domäne schnell das nötige Skript zur Automatisierung von CI-Prozessen zu schreiben.
• Grundlagen von Betriebssystemen helfen dir dabei, ganze Problemklassen in jeder Programmiersprache zu verstehen. Letztlich interagiert jedes Programm, unabhängig von der Sprache, auf ähnliche Weise mit dem Betriebssystem.
• Eines der ersten Bücher, die ich gelesen habe, war Effective Java—eine Sprache, die ich seit Jahren nicht mehr verwendet habe. Aber dieses Buch hat mir objektorientierte Prinzipien beigebracht, die überall gelten. Das ist die Art von Wissen, die bleibt.
• Wenn du gerne programmierst, werden sich diese Nebenprojekte nicht wie Arbeit anfühlen. Meiner Erfahrung nach sind die besten Engineers diejenigen, die coden, weil sie es lieben, Dinge zu bauen und zu lernen.

Wege, alles zu lernen

Manche Menschen scheinen schneller zu lernen als andere. Das kann eine neue Programmiersprache, ein Muster, eine Architektur oder sogar etwas sein, das mit Entwicklung gar nichts zu tun hat, wie Schachspielen zu lernen. Ich glaube, das liegt daran, dass Lernen selbst eine Fähigkeit ist—eine Meta-Fähigkeit, die du trainieren kannst.

Wenn ich über meinen eigenen Lernweg nachdenke, fallen mir wiederkehrende Muster beim Herangehen an neue Themen auf. Ich glaube, das stammt aus meiner Zeit in der Schule und an der Universität, wo das Jonglieren mit mehreren Disziplinen mein Gehirn dazu gebracht hat, ähnliche Muster zu optimieren. Dadurch konnte ich schneller lernen.

Heute habe ich einen konkreten Prozess, um etwas Neues zu lernen. Ich glaube nicht, dass dieser Prozess bahnbrechend ist, aber er hat mir ermöglicht, sowohl beim Lernen als auch in meiner persönlichen Weiterentwicklung fokussiert und bewusst zu bleiben. In diesem Abschnitt führe ich dich durch die drei Phasen meines Lernansatzes: Sichtung, Strukturierung und Praxis.

Sichtung

Eine gute Informationsquelle ist ein entscheidender erster Schritt beim Erlernen einer neuen Fähigkeit. Hier sind ein paar Empfehlungen aus meiner Erfahrung:

• Die meisten Informationen zu jedem Thema sind kostenlos verfügbar. Es gibt selten einen Grund, für Kurse oder Vorlesungen zu bezahlen, es sei denn, du bist absolut sicher, dass die Inhalte einzigartig sind. Aber wenn du gerade erst anfängst, hast du noch nicht die Erfahrung, um den Unterschied zwischen echten Erkenntnissen und minderwertigem Material zu erkennen.
• Textbasierte Ressourcen sind in der Regel prägnanter und leichter zu erfassen als Videos, besonders wenn du schnell liest. Mit der Zeit habe ich gelernt, Informationen schnell zu überfliegen und Irrelevantes herauszufiltern, etwas, das bei Videoinhalten schwieriger ist.
• Mit der Zeit habe ich die Fähigkeit entwickelt, Informationen zu überfliegen und Irrelevantes herauszufiltern, was mit Videomaterial nicht möglich ist, weil es linear und zeitaufwendig ist. Es ist außerdem einfacher, in einem Text eine Stelle zu markieren oder einen Ausschnitt zu kopieren, als in einem Video nach dem richtigen Moment zu suchen.
• Englischsprachige Ressourcen sind viel leichter zu finden als Ressourcen in anderen Sprachen, besonders wenn es um Programmierung und Technologie geht. Deshalb ist es ein Muss, Englisch schnell lesen und verstehen zu können!
• Überspring die Klassiker nicht. Bücher, die immer wieder empfohlen werden (wie Clean Code oder Design Patterns), sind oft immer noch das beste verfügbare Material.
• Ich empfehle außerdem, dir deine eigene persönliche Bibliothek mit Büchern zu verschiedenen Themen aufzubauen. So hast du immer verlässliches Material griffbereit. Ich persönlich bewahre dafür einfach einen Ordner auf meinem Computer auf.

Strukturierung

Sobald ich ein paar solide Quellen gesammelt habe, strukturiere ich die Informationen. Dazu gehört:

1. Die Quellen verarbeiten. Während ich ein Buch oder einen Artikel lese, markiere ich wichtige Punkte mit Lesezeichen oder kopiere sie zur späteren Referenz in meine Notizen.
2. Informationen abgleichen. Gerade wenn das Thema subjektiv ist, ist es sehr wichtig, mehrere Lösungen und Perspektiven miteinander zu vergleichen. Informationen, die in mehreren unterschiedlichen Quellen übereinstimmen, sind wahrscheinlich zutreffend. Wenn sich Quellen widersprechen, verschiebe ich eine Entscheidung meist, bis ich mehr eigene Erfahrung mit dem Thema gesammelt habe. Später, mit tieferem Verständnis, kann ich den besten Ansatz wählen.
3. Wissen zentralisieren. Um alle erhaltenen und gefundenen Informationen zu analysieren, müssen sie an einem Ort gespeichert werden. Ich nutze Obsidian, um mein Wissen zu zentralisieren. Es ist kostenlos, und ich finde das Markdown-Format sehr praktisch.
4. Speichern. Ich speichere Artikel und nützliche Links normalerweise in einfachen Markdown-Listen. Das hilft mir, eine bestimmte Ressource schnell zu finden, ohne mich durch den Browserverlauf zu wühlen. Außerdem habe ich, wenn ich später zu dem Thema zurückkehre, bereits eine gute Grundlage gespeichert.

Praxis

Lesen reicht nicht aus. Wirklich lernen tust du erst, wenn du etwas baust. Ich versuche, jedes Thema, das ich lerne, durch das Erstellen kleiner Projekte zu festigen. Wenn es ums Programmieren geht, bedeutet das normalerweise, eine einfache Anwendung zu erstellen, die zeigt, dass ich die nötigen Fähigkeiten anwenden kann. Schnelle Praxis deckt außerdem sofort alle Verständnislücken auf. Ich dachte oft, ich hätte alles verstanden, was ich wissen musste, nur um schon 10 Minuten nach Beginn der Umsetzung auf unerwartete Probleme zu stoßen.

Ein Beispiel, das mir besonders im Gedächtnis geblieben ist, ist das Lernen von UI-Architekturen. Als ich MVVM zum ersten Mal im Kontext der iOS-Entwicklung gelernt habe, dachte ich, die Architektur sei einfach und geradlinig. Aber als ich versucht habe, eine einfache To-do-Listen-App zu bauen, bin ich sofort auf eine Wissenslücke gestoßen. Die Ressourcen erklärten, wie die View mit dem ViewModel kommuniziert und wie das ViewModel mit dem Model interagiert, aber keine davon ging darauf ein, wer was erstellen sollte und wie!

Meine Anwendung hatte eine Tabelle, in der die aktuellen To-do-Aufgaben angezeigt wurden. Sollte ich für jede Aufgabe ein separates ViewModel erstellen? Oder ein einziges ViewModel für die gesamte Tabelle? Und was, wenn ich beide ViewModels brauchte? Wer erstellt dann welches? Diese Fragen haben mir die Tür dazu geöffnet, zu verstehen, wie man Komponenten in ähnlichen Architekturen koordiniert.

Später, als wir an PDF Expert arbeiteten, entschied unser Team, MVVM auszuprobieren. Ich konnte die Architektur aufbauen und dem Team dabei helfen, die Entwicklung dieses Features zu leiten. Das ist genau die Art von Erfahrung, die ich nicht gemacht hätte, wenn ich nicht zuerst selbst diese kleine, chaotische To-do-App gebaut hätte.

Meine Empfehlungen für Side Projects

• Finde Inspiration und eine Idee. Die Idee kommt normalerweise zuerst, danach verknüpfe ich sie mit einem konkreten Lernziel. Die Idee muss weder einzigartig noch besonders nützlich sein, denn der Hauptzweck ist es, Erfahrung zu sammeln. Zum Beispiel könnte ich mich entscheiden, eine Habit-Tracker-App zu bauen. Von dort aus kann ich entscheiden, ob ich mich auf die Architektur konzentriere oder diese Idee nutze, um ein beeindruckendes UI mit Animationen zu entwerfen. Oder muss ich vielleicht einen Server für diese App bauen? Das könnte eine großartige Gelegenheit sein, neue Backend-Technologien auszuprobieren.
• Definiere “fertig.” Wenn du versuchst, jedes Projekt bis zur Produktionsreife zu bringen, musst du für jedes sehr viel Zeit einplanen. Deshalb glaube ich, dass du die Meilensteine definieren musst, die du mit jedem Projekt erreichen willst.
• Perfekt ist der Feind des Guten. Wenn du dich zu sehr darin verlierst, nach der “perfekten” Lösung zu suchen, verlierst du womöglich komplett die Motivation.
• Minimiere unnötige Aufgaben. Spielt die exakte Farbpalette in einer App wirklich eine Rolle, wenn sie dir etwas über Architektur beibringen soll? Oder das Logging-System? Die wertvollsten Projekte waren diejenigen, die auf ein einziges Lernziel fokussiert waren. Je weniger Zeit ich für Details mit niedriger Priorität aufwende, desto mehr kann ich in das investieren, was wirklich zählt.

10 Themen, die verändert haben, wie ich Software entwickle

Hier sind 10 Bereiche, die ich eigenständig erkundet habe und die sich auf meine Karriere ausgewirkt haben.

UI-Anwendungsarchitekturen

Jeder Engineer, der an UI-basierten Projekten gearbeitet hat, kennt die klassischen Muster der Codeorganisation. Wer hat noch nie von MVC, MVP oder MVVM gehört? Meiner Erfahrung nach kann einfaches theoretisches Wissen dir das Selbstvertrauen geben, ein neues Projekt zu beginnen, aber ohne praktische Erfahrung bricht es oft beim ersten Anzeichen von Komplexität auseinander.

Ich dachte einmal, ich würde vollständig verstehen, wie MVVM funktioniert, aber mir fehlte die Erfahrung, es tatsächlich auszuprobieren. Das wurde mir klar, als ich versucht habe, eine kleine MVVM-Anwendung zu entwickeln. Es wurde deutlich, dass ich Coordinators und Router brauchte, um das Durcheinander von Klassen zu navigieren und zu einer kohärenten Struktur zusammenzufügen. Diese Erfahrung hat mir eine wichtige Lektion beigebracht: Es gibt keine Architektur, die für alle Fälle passt. Eine Architektur, die in einem Projekt (oder sogar auf einem einzelnen Screen) gut funktioniert, kann an anderer Stelle ungeeignet sein.

Design Patterns

Wer schon einmal Entwicklerinterviews geführt oder durchlaufen hat, ist wahrscheinlich Fragen zu Design Patterns begegnet. Viele Engineers scheinen bestimmte Muster theoretisch zu erkennen, haben aber Schwierigkeiten, sie in der Praxis anzuwenden. Der einfachste Weg, diese Lücke zu schließen, ist, ein kleines Projekt zu bauen, das sich auf die Implementierung eines bestimmten Musters konzentriert.

Das Originalbuch verwendet oft einen Texteditor als Beispiel. Meiner Erfahrung nach erfordern Editoren für unterschiedliche Dokumente den Einsatz vieler Design Patterns. Das kann ein Texteditor, ein Bildeditor oder sogar ein Diagrammprogramm sein.

Tests

Das Testen von Code ist ein Grundpfeiler stabiler Codebasen. Und obwohl die Idee einfach klingt – “schreib einfach Tests!” – ist das Schreiben nützlicher Tests oft alles andere als trivial.

Die größte Herausforderung ist, dass die Pflege von Tests Teamressourcen verbraucht. Wenn du nach jedem Refactoring des Codes die Tests neu schreiben musst, wird der Gesamtwert dieser Tests fraglich. Dieses Konzept ist als Test Fragility bekannt, und meiner Erfahrung nach ist es nicht so bekannt, wie es sein sollte. Du kannst die Theorie des Testens zum Beispiel in diesem Buch lernen.

Ein starker Fokus auf Testing wirkt sich auch auf die Codequalität aus. Generell wird Code, der mit Blick auf Tests geschrieben wurde, modularer sein und eine sauberere, einfachere API bieten. Es ist leicht, Tests in der Praxis auszuprobieren – integriere sie einfach in ein bestehendes Projekt oder starte ein neues mit dem Fokus auf das Schreiben von Tests.

Algorithmen und Datenstrukturen

Algorithmen zu kennen ist in der modernen Softwareentwicklung keine zwingende Voraussetzung. Viele Unternehmen bauen trotzdem algorithmische Aufgaben in ihre Interviews ein, obwohl diese Fähigkeiten im Arbeitsalltag vielleicht nicht gebraucht werden. Trotzdem glaube ich, dass es sich lohnt, Zeit in das Lernen von Algorithmen zu investieren, weil es Spaß macht und interessant ist. Außerdem kannst du diese Themen heute interaktiv über Plattformen wie LeetCode erkunden.

Wenn du jemals die Möglichkeit hast, an algorithmischen Programmierwettbewerben wie dem ACM ICPC teilzunehmen, kann ich nur sehr empfehlen, es auszuprobieren. Selbst wenn dieses Wissen zunächst nicht direkt nützlich erscheint, lassen sich Techniken zur Codeoptimierung auf jedes Projekt anwenden, und die Teilnahme an einem teambasierten Wettbewerb ist eine Erfahrung, an die du dich wahrscheinlich gern erinnern wirst.

Multithreading

Multithreading ist ein faszinierendes Thema. Man kann jahrelang Code schreiben, ohne auch nur die grundlegenden Konzepte zu verstehen. Jede Entwicklerin und jeder Entwickler weiß, dass das Blockieren des Main Threads die App einfrieren lässt. Aber wenn etwas schiefläuft, können nur Entwicklerinnen und Entwickler, die Multithread-Code wirklich verstehen und die gesamte zeitliche Abfolge der Ereignisse visualisieren können, diese schwer greifbaren Phantom-Bugs diagnostizieren.

Meiner Meinung nach ist das Verständnis von Synchronisationsprimitiven, Threads und den Folgen, wenn man diese Konzepte vernachlässigt, einer der Schlüsselfaktoren, die Mid-Level- von Senior-Entwicklerinnen und -Entwicklern unterscheiden. Um die Grundkonzepte zu verstehen, empfehle ich das kostenlose Buch The Little Book of Semaphores.

Für praktische Erfahrung kannst du versuchen, ein Programm zu schreiben, das im Hintergrund aufwendige Verarbeitung durchführt und die Ergebnisse mit dem UI synchronisiert – besonders wenn die Hintergrundarbeit selbst mehrere Threads umfasst. Die Simulation physikalischer Prozesse kann ein großartiger Ausgangspunkt für ein solches Projekt sein.

Grafikprogrammierung

Grafikprozessoren gehören zu den wenigen Teilen eines Computers, mit denen die meisten Entwicklerinnen und Entwickler nur selten direkt interagieren müssen. Bei den meisten Anwendungen findet das UI-Rendering entweder auf der CPU statt oder ist vom eigentlichen GPU-Gerät abstrahiert, sodass du nicht einmal darüber nachdenken musst. Aber sobald die Zahl der Elemente auf dem Bildschirm groß genug wird und High-Level-Abstraktionen die erforderlichen Bildraten nicht mehr halten können, musst du tiefer einsteigen. Zu verstehen, welche Probleme GPUs lösen sollen, und ihnen gewissermaßen “zu erklären”, was gerendert werden muss, kann dir helfen, in ähnlichen Situationen schnell Lösungen zu finden.

Ein klassisches Projekt, um Grafikprogrammierung zu lernen, ist der Bau einer Game Engine. Wenn du Computerspiele so sehr liebst wie ich, hast du dich wahrscheinlich schon gefragt, wie sie programmiert werden. Online gibt es Unmengen an Ressourcen, um Metal, DirectX, OpenGL oder Vulkan zu lernen. Erwarte nur nicht, dass dein Projekt zur nächsten Unreal Engine wird. Aber wenn du den Punkt erreichst, an dem du ein kleines Spiel auf deiner eigenen Engine gebaut hast, garantiere ich dir, dass du auf faszinierende Herausforderungen stoßen und wertvolles Wissen gewinnen wirst.

Embedded-Programmierung

Als ich zum ersten Mal erfuhr, dass selbst die kleinsten elektronischen Geräte um uns herum ihre eigenen Programme und Prozessoren ausführen, war ich sofort fasziniert und wollte versuchen, etwas Ähnliches zu bauen. Die Entwicklung für Mikroprozessoren bringt jedoch viele Einschränkungen mit sich. Solche Systeme haben normalerweise weniger als 128 Kilobyte Speicher, und dynamische Speicherallokation kommt in der Regel nicht infrage.

Das Schreiben und Debuggen von Embedded-Code bringt viele Herausforderungen mit sich. Aber dafür kannst du sehen, wie dein Code in der realen Welt zum Leben erwacht. Schon eine einfache LED zum Blinken zu bringen, fühlte sich für mich wie ein Durchbruch an. Zu verstehen, wie Mikrocontroller funktionieren, ist ein bedeutender erster Schritt, um zu begreifen, wie moderne CPUs und Betriebssysteme funktionieren. Wenn man mit Embedded Devices arbeitet, muss man möglicherweise sogar in plattformspezifische Assemblersprache eintauchen (typischerweise ARM).

Heute ist es einfacher denn je, mit Embedded-Entwicklung anzufangen. Preisgünstige Mikrocontroller wie die STM32-Reihe sind ein großartiger Einstieg, und viele sofort einsatzbereite Boards kommen mit integrierten Programmern, die per USB verbunden werden. Die Möglichkeiten sind endlos – von dynamischer Raumbeleuchtung bis hin zum Bau deines eigenen Smart-Home-IoT-Hubs.

Disassembler

Manchmal kann es unschätzbar wertvoll sein, eine Ebene tiefer in deinen Code blicken zu können. Zum Beispiel arbeiten wir in der Entwicklung für Apple-Plattformen oft mit größtenteils Closed-Source-Bibliotheken von Apple. Wenn sich etwas nicht wie erwartet verhält, muss man normalerweise ein Ticket über den Feedback Assistant einreichen und auf eine Antwort warten (manchmal jahrelang!). Aber mit Hilfe eines Disassemblers kann man oft unter die Haube schauen und verstehen, wie der Closed-Source-Code tatsächlich funktioniert.

Auch das Verständnis des Assembly-Codes deines eigenen Programms kann nützlich sein, besonders im Kontext von Optimierung. Nur durch die Untersuchung des kompilierten Codes kannst du wirklich wissen, was dein Code tut. Ich persönlich nutze dafür auf macOS Hopper Disassembler.

Compiler

Die Welt der Programmierung hat ihre eigenen “Geheimclubs.” Wenn wir an die Menschen denken, deren Produkte die meisten Engineers beeinflussen, landen wir unweigerlich bei denen, die die Compiler hinter unseren Lieblingsprogrammiersprachen bauen. Bis ich selbst Zeit damit verbracht habe, Compiler zu studieren, wirkten diese Programme auf mich wie pure Magie. Aber selbst wenn man nur die Grundlagen lernt, lichtet sich der magische Nebel noch immer nicht genug, um die Brillanz derjenigen vollständig zu begreifen, die ganze Programmiersprachen erschaffen haben.

Die gute Nachricht ist, dass es zu diesem Thema viele Ressourcen und Bücher gibt. Zwei meiner Favoriten sind Engineering a Compiler und natürlich der Klassiker Dragon Book. Du kannst in die Entwicklung deiner eigenen Programmiersprache eintauchen, indem du mit dem Kaleidoscope-Tutorial von LLVM beginnst. In der “realen Welt” der Softwareentwicklung kann dir dieses Wissen, sofern du kein Compiler-Engineer bist, ein viel tieferes Verständnis für das Verhalten von Sprachen und schwer nachvollziehbare Fehler vermitteln. Außerdem sind die meisten Compiler Open Source, was es dir ermöglicht, zu riesigen Projekten mit großer Wirkung beizutragen. Zum Beispiel wertet ein Beitrag zum Swift-Repository das Portfolio jeder Entwicklerin und jedes Entwicklers erheblich auf.

Grundlagen von Betriebssystemen

Wenn es Projekte gibt, die noch komplexer sind als Compiler, dann kommen einem Betriebssysteme in den Sinn. Als Entwicklerinnen und Entwickler, die den Großteil unserer Zeit an Computern arbeiten, vergessen wir erstaunlich leicht, dass ein Betriebssystem auch nur ein weiteres Programm ist, so wie die, die wir selbst schreiben. Eine gewaltige Schicht von Abstraktionen über der Hardware erzeugt die Illusion, dass jedes Programm im User Space auf seinem eigenen Prozessor mit eigenem Speicher läuft. Diese Abstraktionen sind so präzise, dass einmal geschriebener und kompilierter Code zuverlässig auf einer enormen Vielfalt von Hardwarekonfigurationen laufen kann.

Das Buch Operating Systems: Three Easy Pieces ist ein großartiger Einstieg, um zu verstehen, wie Betriebssysteme funktionieren. Und wenn dich speziell die Interna von iOS oder macOS interessieren, empfehle ich die kostenlose Ressource MacOS X and iOS Internals. Einblick darin zu gewinnen, wie ein Betriebssystem funktioniert, schließt die letzte Lücke zwischen Hardware und dem Code, den wir schreiben. Für Entwicklerinnen und Entwickler bedeutet das fast vollständige Kontrolle und Verständnis darüber, was passiert, wenn dein Programm läuft.

Zum Abschluss

Rückblickend bin ich keinem strikten Plan gefolgt. Ich habe einfach weiter gelernt, gebaut und verfolgt, was mich interessiert hat. Diese Neugier wurde zu einer Karriere.

Wenn du dich wohlfühlst, aber dich fragst, was als Nächstes kommt, versuch, dich breiter aufzustellen. Entdecke etwas Neues. Die Zeit, die du in Nebenprojekte und Lernen investierst, wird sich auszahlen, und die Abstände zwischen den Levels—Junior, Middle, Senior und Principal—werden schneller kleiner werden, als du denkst.

Es gibt immer mehr zu lernen. Aber mit jedem Projekt, jedem Fehler und jedem neuen Konzept kommst du voran. Bau weiter.

— Andrii Zinoviev, Principal Product Engineer

Möchtest du Teil unseres Engineering-Teams werden und Millionen Menschen beeinflussen? Sieh dir unsere offenen Stellen an!