Tech Lead (70 % .NET, 30 % React)

Stellenbeschreibung:

Projektinformationen:

Next Generation Audit (NGA) ist die Audit-Plattform. Die Arbeit ist in Wertströme gegliedert. Jeder Wertstrom besteht aus Pods. Ein Pod liefert einen Produktbereich, zum Beispiel Administration und Freigaben, Inhaltssuche, Vorlagen für Audit-Positionen, den Datenkatalog, die Einzelfallprüfung oder die Festlegung des Umfangs und den Testplan.

Die Auslieferung ist agil. Die Pods arbeiten mit Kanban oder in Sprints. Der Tech Lead ist die technische Stimme eines Pods. Der Product Owner legt die Prioritäten fest. QA ist Teil derselben Auslieferung und kein Schritt, der erst nach der Entwicklung beginnt.

Die Plattform läuft auf Microsoft Azure. Die Services sind in .NET geschrieben. Die Benutzeroberfläche besteht aus React und TypeScript. Die genauen Bibliotheken unterscheiden sich je nach Wertstrom. Siehe den Abschnitt zur Technologie weiter unten.

Die Rolle:

Sie leiten die technische Arbeit eines Pods und schreiben weiterhin Produktionscode. Sie sind die Person, die der Pod fragt, wenn ein Entwurf, ein Review oder eine Release-Entscheidung unklar ist.

Sie arbeiten mit dem Product Owner, mit QA und mit Leads in der US-Zeitzone zusammen. Sie erklären eine technische Entscheidung in klarer Sprache, auch gegenüber Menschen, die keinen Code schreiben. Sie sagen auch, wenn eine Anforderung noch nicht bereit ist: Die Anforderung ist unklar, die Frist ist nicht realistisch, oder die Änderung hat keinen Nachweis, dass sie funktioniert.

Sie hören zu und bieten dann Optionen an. Sie erzwingen keine Entscheidung, wenn der Pod sie selbst treffen kann. Sie bemerken, wenn jemand ohne Arbeit ist oder wenn sich die Arbeit bei einer Person häuft, und verteilen sie um.

Ihre Aufgaben:

Änderungen an den Services und an der Benutzeroberfläche des Pods entwerfen und umsetzen. Den Entwurf prüfen, bevor eine große Änderung beginnt.

Die Repositories des Pods konsistent halten: API-Struktur, Swagger, Sicherheitsprüfungen und Beschreibungen der Pull Requests.

Pull Requests selbst prüfen. Eine Änderung ablehnen, die der Autor nicht erklären kann. Generierten Code, den niemand gelesen oder getestet hat, nicht freigeben.

Bei jeder Lieferung einen Nachweis verlangen. Das kann die Benutzeroberfläche sein, ein Backend-Endpunkt oder ein Integrationstest. Er soll zeigen, dass die Person das Problem und die Auswirkung versteht und dass die Änderung funktioniert.

QA einbinden, wenn das Backlog-Item geschrieben wird, nicht erst, wenn der Build eine Testumgebung erreicht. Die Abnahmeprüfungen frühzeitig vereinbaren. Entwickler unterstützen, die automatisierte Happy-Path-Tests schreiben, damit QA sie prüfen und die Randfälle abdecken kann.

Festlegen, wie der Pod KI-Werkzeuge zum Programmieren einsetzt. Regeln und Skills im Repository pflegen. Einen nützlichen Skill über einen Pull Request teilen. Eine gemeinsame Vorlage an die Domäne dieses Pods anpassen. Ein einzelnes Setup nicht für jeden Wertstrom verbindlich machen.

Das Werkzeug mit Urteilsvermögen nutzen. Ihm Kontext geben. Den Plan lesen, bevor die Umsetzung beginnt. Alles, was das Repository verlässt, wie ein Push, ein Ticket-Kommentar oder eine Freigabe eines Pull Requests, bleibt unter menschlicher Kontrolle.

An der Release-Arbeit teilnehmen. Releases werden podübergreifend koordiniert. Sie helfen dabei, den Anteil des Pods verlässlich zu machen: Umgebung, Konfiguration und eine Prüfung, dass die Änderung tatsächlich ausgerollt ist.

Einen Anteil am genehmigten Bereitschaftsdienst übernehmen, wenn der Pod es braucht. Der Bereitschaftsdienst wechselt rotierend. Er ist keine dauerhafte Wochenendverpflichtung für eine einzelne Person.

Einem neuen Teammitglied helfen, in den ersten Wochen nützlich zu werden. Das Onboarding auf dieser Plattform ist langsam, weil das System groß ist. Sie weisen die Menschen auf die Repository-Regeln, die lokale Domäne und die Person hin, die ihnen Blockaden aus dem Weg räumen kann.

Ein Risiko früh ansprechen: QA-Kapazität, eine defekte Umgebung, eine Abhängigkeit von einem anderen Pod oder eine Umfangsänderung, die zu spät kam, um gut umgesetzt zu werden.

Wie das Team arbeitet:

Das Backlog-Item ist die Einheit der Auslieferung. Ist die Anforderung dünn, halten Sie an und klären sie, bevor der Pod beginnt.

Arbeit mit kurzer Vorlaufzeit kommt vor. Sie verlangen trotzdem eine klare Anforderung und eine Frist, die der Pod einhalten kann.

Im wöchentlichen Lead-Sync berichten die Pod-Leads über den tatsächlichen Stand der Arbeit. Sie halten Ihren eigenen Pod auf dem Laufenden.

Programmieren mit KI ist normal. Cursor ist die übliche IDE. GitHub Copilot prüft Pull Requests. Manche nutzen auch Claude oder Claude Code. Es gibt keine einzelne verbindliche Werkzeugliste. Es gibt eine gemeinsame Erwartung: Der Autor versteht die Änderung.

Eine bereits genutzte, praktische Skill-Abfolge beginnt mit einer Prüfung, ob das Feature dokumentiert und bereit ist, dann folgen ein Plan, die Umsetzung, ein Branch, ein Pull Request, ein Code-Review und ein Sicherheitsdurchgang. Die Pods passen diese Abfolge an ihre Arbeit an.

Anforderungen:

Sie müssen nicht am ersten Tag jede Bibliothek kennen. Sie müssen aber im gängigen Stack produktiv sein und die Besonderheiten des Pods erlernen können.

Sie benötigen:

C# und .NET, einschließlich ASP.NET Core Web APIs

React und TypeScript

REST, Swagger / OpenAPI und Sorgfalt bei Änderungen, die aufrufende Systeme brechen

Microservices und eine in Micro-Frontends aufgeteilte Benutzeroberfläche

Microsoft Azure: mindestens App Service oder Azure Kubernetes Service, Azure Functions und Service Bus

Eine relationale Datenbank und eine Dokumentendatenbank. Die Plattform nutzt in verschiedenen Services SQL Server, Azure SQL, MongoDB und Azure Cosmos DB

Git, Pull Requests und entweder Azure DevOps oder GitHub. Dieses Programm nutzt beides

Docker, für lokale Läufe und für Service-Images

Automatisierte Tests, die Sie lesen und erweitern können. Entwickler verantworten kleine Integrationstests und Happy-Path-UI-Tests. Playwright ist das eingesetzte UI-Werkzeug

Täglichen Einsatz eines KI-Coding-Assistenten, mit der Gewohnheit, dessen Ergebnisse zu prüfen. Cursor ist das Werkzeug, das die Pods derzeit nutzen

Architektur, die Sie anwenden können sollten:

Ein dünnes Backend-for-Frontend vor den Services

Clean Architecture bei den .NET-Services, die sie bereits verwenden

Ereignisse über Service Bus, einschließlich eines Outbox, wenn der Service eine Nachricht veröffentlicht

Feature Flags. LaunchDarkly ist im Einsatz. Einige Anwendungen wechseln zu einer gemeinsamen Bibliothek für Feature-Management

API-Versionierung und Verträge, die für andere Pods stabil bleiben

Repository-Regeln, denen ein Agent folgt: Sicherheit, Swagger und die eigene Domäne des Pods

Nützlich in einem bestimmten Wertstrom, nicht für jeden Pod erforderlich:

Squidex Headless CMS, Azure Functions, Inhaltssuche

Arbeitsweise:

Arbeitssprache ist Englisch. Sie sprechen und schreiben es täglich klar.

Sie können Abwägungen, Risiken und vorgeschlagene Änderungen Ingenieuren ebenso erklären wie Menschen, die keinen Code schreiben.

Sie übernehmen die Verantwortung für das technische Ergebnis des Pods. Sie bitten um Hilfe, wenn die Entscheidung außerhalb des Pods liegt.

Sie bleiben ruhig, wenn ein Release oder eine späte Änderung den Pod unter Druck setzt. Sie benennen das Risiko früh.

Sie arbeiten zu Zeiten, die sich mit den USA überschneiden. Ein normaler Tag dauert bis etwa 18:00 Uhr MEZ. Ein Tag von 09:00 bis 18:00 oder von 10:00 bis 19:00 Uhr MEZ passt. Eine größere Überschneidung hilft. Der Zeitunterschied zur US-Ostküstenzeit beträgt etwa sechs Stunden.

Sie fühlen sich in einem Remote-Team wohl. Treffen vor Ort in Prag finden gelegentlich statt, in etwa einmal pro Quartal.