~/bewerbung/maibornwolff$cat application.md

ZEHN JAHRE BACKEND TRIFFT PRODUKT-PLATTFORM

Max Mustermann

Backend Engineer @ MaibornWolff

Ich baue Backends, die auch um 3 Uhr nachts unter Last leise bleiben.

Ich baue seit zehn Jahren Server-Systeme, die nicht nur im Demo laufen, sondern in Produktion - unter echter Last, mit echten Kunden, mit Bereitschaft am Wochenende. Mein Anspruch ist nicht die cleverste Zeile Code, sondern das System, das man versteht, überwacht und ruhigen Gewissens deployt. Ihr sucht jemanden, der Verantwortung für Kern-Services übernimmt und sie wartbar hält. Das ist genau die Arbeit, die ich mag.

10+ Jahre BackendGo · TypeScript · PythonKubernetes & ObservabilityAPI-DesignRemote/Hybrid

Zehn Jahre Backend - bringt Kern-Services stabil und wartbar in Produktion.

  • Monolith → event-getriebene Services, 99,9 % Uptime
  • Latenz −40 %, Kosten/Anfrage −50 %
  • MTTR halbiert durch Observability

## Passungreq → evidence

Ihr sucht Backend Engineer - hier ist, Punkt für Punkt, was ich konkret mitbringe:

Skalierbare, verteilte Services
Das Kern-Backend eines B2B-Marktplatzes von einem Monolithen auf event-getriebene Services umgestellt - bei laufendem Betrieb, ohne Big-Bang, mit 99,9 % Uptime über das Jahr.
Sauberes API-Design
Öffentliche REST- und gRPC-APIs für Partner entworfen, versioniert und dokumentiert; Breaking Changes über eine klare Deprecation-Policy vermieden.
Observability & Betrieb
Verteiltes Tracing und aussagekräftige Metriken eingeführt - die mittlere Zeit bis zur Fehlerbehebung (MTTR) dadurch halbiert.
Performance unter Last
Antwortlatenz eines heiß laufenden Dienstes um 40 % gesenkt und die Kosten pro Anfrage halbiert - durch Caching, Query-Tuning und ein saubereres Datenmodell.
Mentoring
Vier Junior-Engineers begleitet, bis sie Features eigenständig verantworten - über Pairing, Reviews und wenig Ego.

▸ Stationengit log --reverse

seniorb

Senior Backend Engineer

@ Acme GmbH · 2020 – heute

Technische Verantwortung für die Kern-Services einer B2B-Plattform: Architektur, Umsetzung, Betrieb und Bereitschaft. Enge Abstimmung mit Produkt und Frontend.

  • Monolith → event-getriebene Services
  • Latenz −40 %, Kosten/Anfrage −50 %
  • MTTR halbiert
  • 99,9 % Uptime
backend

Backend Engineer

@ Beispiel AG · 2015 – 2020

Microservices für einen B2B-Marktplatz, von der ersten Zeile bis zum Produktionsbetrieb. Aufbau der CI/CD-Pipeline und der Test-Kultur.

  • CI/CD von 0 auf 100
  • Integrationstests eingeführt

## Fähigkeiten--list

Sprachen

GoTypeScriptPythonSQL

Daten & Infra

PostgreSQLKafkaRedisKubernetesTerraform

Praktiken

API-DesignObservabilityCI/CDTestautomatisierung

// Beitrag

Was ich bei MaibornWolff konkret übernehmen würde - eure Anforderungen, meine Antwort: 01 · Services in Produktion bringen Saubere APIs, aussagekräftige Tests, echte Observability. Ich baue so, dass man am Freitagnachmittag deployen kann. 02 · Skalierung mit Augenmaß Last- und Kostenprofile im Blick behalten und dort optimieren, wo es zählt - nicht dort, wo es Spaß macht. 03 · Kundennah & pragmatisch Ich übersetze fachliche Anforderungen in tragfähige Schnittstellen und rede früh mit den Menschen, die das System nutzen. 04 · Wartbarkeit als Feature Dokumentation und Standards, damit das Team auch ohne mich schnell bleibt.

## Projektels -la

Ein paar Dinge in der Richtung habe ich schon gemacht - mit belegbaren Ergebnissen.

Event-Bus-MigrationArchitektur

Monolith schrittweise zu event-getriebenen Services migriert, ohne Big-Bang und ohne Downtime für die Kunden.

API-Gateway

Zentrales Gateway mit Auth, Rate-Limiting und Versionierung - eine Anlaufstelle statt zehn Sonderlocken.

Eval-/Load-Harness

Automatisiertes Last- und Regressions-Setup, das Performance-Rückschritte vor dem Release fängt.

▸ Fahrplan// 30 · 60 · 90

Tag 1–30 · Verstehen

Ich lese Code und Dashboards, bevor ich meine ersten Zeilen schreibe.

Ein Backend versteht man nicht aus dem README, sondern aus dem laufenden System. Zuerst schaue ich, wie es wirklich läuft.

  • Codebasis und Deploy-Pipeline durcharbeiten.
  • Die wichtigsten Services und ihre Abhängigkeiten kartieren.
  • Mit dem Team die typischen Schmerzpunkte im Betrieb klären.
Ergebnis: ein belastbares mentales Modell des Systems statt Raten.
Tag 30–60 · Liefern

Ich liefere ein Feature end-to-end - mit Tests und Monitoring.

Um den echten Weg von Ticket bis Produktion einmal zu gehen, übernehme ich früh ein abgegrenztes Feature komplett.

  • Ein Service-Feature inkl. Tests und Metriken umsetzen.
  • Den ersten eigenen Deploy sauber durchziehen.
  • Reviews geben und Doku ergänzen.
Ergebnis: ein produktives Feature und Vertrauen im Team, dass ich abliefere.
Tag 60–90 · Verstärken

Ich baue Observability und API-Standards aus.

Jetzt hebe ich das Niveau: wiederkehrende Schmerzpunkte automatisieren, damit das Team schneller bleibt.

  • Tracing/Metriken für kritische Pfade ergänzen.
  • API-Standards und Deprecation-Policy schärfen.
  • Wissen streuen (Pairing, kurze Docs).
Ergebnis: ein System, das man ruhigen Gewissens am Freitag deployt.

// Zusammenarbeit

Kleine, gut beschriebene Pull Requests, klare Reviews ohne Ego, Dokumentation, die das Team ohne mich weiterbringt. Ich frage lieber einmal zu viel bei Produkt und Frontend nach, als am Bedarf vorbeizubauen.

// Ehrlichno overpromise

Ehrlich gesagt: euren spezifischen Cloud-Stack kenne ich noch nicht im Detail. Das ist für mich eher eine Frage von Tagen als von Monaten - meinen letzten Kubernetes-Stack hatte ich in zwei Wochen produktiv, und die Grundprinzipien sind übertragbar.

$ Kontakt// maibornwolff

Lassen Sie uns sprechen - ich bringe für ein erstes Gespräch gern konkrete Beispiele mit.

email   max.mustermann@example.com
LinkedIn

Alle Angaben stammen aus dem echten Profil - nichts erfunden, nichts geschönt.