Full Stack Engineer (m/f/d) in Berlin

Schließen Sie sich GlassDollar an und helfen Sie, das System aufzubauen, das einige der größten Unternehmen Europas nutzen, um Startup-Technologie zu finden, zu testen und zu übernehmen. Wir suchen einen Ingenieur, der erheblich mehr Verantwortung übernehmen möchte als nur "das umzusetzen, was im Ticket steht". Sie werden ein unklar definiertes Problem anpacken, es gemeinsam mit dem Produktteam gestalten, wichtige technische Entscheidungen treffen, es umsetzen und eng genug dranbleiben, um zu sehen, ob es funktioniert.

Wir erwarten von Ihnen, dass Sie Meinungen haben. Wir erwarten auch, dass Sie gut genug sind, um diese zu ändern.

Das Problem, das wir lösen

Große Organisationen sind bemerkenswert gut darin, Probleme anzuhäufen. Ein Unternehmen mit 100.000 Mitarbeitern kann Tausende von operativen Herausforderungen in seinen Geschäftsbereichen haben. Irgendwo außerhalb dieser Organisation hat ein Startup wahrscheinlich bereits einen Teil der Lösung entwickelt. Diese beiden Dinge zusammenzubringen geschieht immer noch durch Tabellenkalkulationen, lange E-Mail-Threads und Meetings, deren primäres Ergebnis ein weiteres Meeting ist. Unsere Kunden sind einige der größten Organisationen Europas, daher muss die Software schnell arbeiten und sich wie etwas verhalten, auf das ein Unternehmen vertrauen kann. Diese Spannung schafft interessante Ingenieurprobleme.

Was wir suchen

• Sie können ein Problem weiterführen als nur das Ticket. Die Arbeit beginnt oft mit etwas Unvollständigem, wie "Kunden benötigen eine bessere Möglichkeit, X zu verwalten". Sie gestalten das Problem mit dem Produktteam, hinterfragen Annahmen und entscheiden, was in dieser Iteration enthalten sein sollte.
• Starke Meinungen darüber, was wir bauen, nicht nur wie, werden hier erwartet. Sie kümmern sich um das Produkt. Sie möchten wissen, für wen Sie bauen, warum das Problem wichtig ist und wie Erfolg aussieht.
• Der Kontext sollte Ihre technischen Entscheidungen prägen. Sie haben technisches Urteilsvermögen. Es gibt selten eine richtige Architektur. Sie wissen, wann die langweilige Lösung die ehrgeizige übertrifft, wann eine Abstraktion hilft und wann sie das Problem verbirgt, und wann ein kleines Feature sechs Monate technische Schulden verursachen könnte.
• Sie sollten in der Lage sein, über API-Grenzen, Datenmodelle, Berechtigungen, Leistung, Fehlermodi, Tests, Beobachtbarkeit und Rollouts nachzudenken und Bedenken mit einem klaren Argument zu äußern.
• Sie verbessern das System, nicht nur das Feature. Sie beheben das Verbreitungsmuster anstelle des einzelnen Vorfalls, machen eine API einfacher für die nächste Person und verbessern Tests, weil die aktuelle Einrichtung alle Angst macht, zu deployen.
• Ihr Einfluss sollte über die Pull-Requests hinaus sichtbar sein, die Ihren Namen tragen.
• Sie können über den gesamten Stack hinweg arbeiten. Ein Feature könnte von einer React-Interaktion über GraphQL in einen Node-Dienst, ein Schema-Redesign, ein Update der Berechtigungen und eine sichere Migration für bestehende Kunden laufen.
• Neugier, um dem Problem zu folgen, ist wichtiger als gleichmäßige Tiefe überall.
• Sie übernehmen Verantwortung für die Qualität. Wir haben QA. Dort beginnt die Qualität jedoch nicht. Was passiert, wenn diese Anfrage zweimal erfolgt? Was passiert mit alten Daten oder wenn die API mitten im Prozess ausfällt?
• Wir verwenden Playwright und Jest neben Überprüfungen und Monitoring. Das Ziel ist nicht die Abdeckung, sondern das Vertrauen.
• Sie kommunizieren so, als ob Ihre Entscheidungen später wichtig sein werden. Sechs Monate später sollte jemand eine wichtige Entscheidung verstehen, ohne durch siebzehn Slack-Nachrichten und einen gelöschten Notion-Kommentar graben zu müssen.
• Das bedeutet, Dinge aufzuschreiben, wenn sie wichtig sind, Trade-offs klar zu erklären, nützliche Code-Reviews zu geben und Risiken zu benennen, bevor sie zu Vorfällen werden.
• Sie heben die Ingenieurnorm um Sie herum an. Sie benötigen keinen Managementtitel, um Einfluss zu haben. Finden Sie das Loch in einer Architektur, befreien Sie jemanden, ohne ihm die Tastatur wegzunehmen, und widersprechen Sie, ohne jede Entscheidung zu einem Referendum zu machen.
• Wenn Sie Vertrauen gewinnen, werden Sie natürlich die Person, zu der die Leute schwierigere Probleme bringen.

Woran Sie arbeiten werden

• Enterprise-Integrationen: in die Systeme, Daten, Identitätsanbieter und Workflows unserer Kunden. Dies verwandelt GlassDollar von einer Software, in die sich jemand einloggt, in die Infrastruktur, auf der ihre Organisation arbeitet.
• APIs und MCP: öffentliche REST-APIs und MCP-Server für unsere Kunden, deren Ingenieure und zunehmend deren KI-Agenten. Der interessante Teil besteht nicht darin, Endpunkte bereitzustellen, sondern eine externe Plattform zu entwerfen, die wir auch in Jahren noch gerne unterstützen.
• KI in realen Workflows: Embeddings, Vektorsuche und LLMs über eine große Datenbank von Startups und Unternehmensinnovationsdaten. Wir sind weniger daran interessiert, überall einen Button hinzuzufügen, als herauszufinden, wo KI echte Arbeit abnimmt.
• Workflow-Automatisierung: Trigger, Benachrichtigungen und Automatisierung, die Menschen ersetzen, die Informationen zwischen Systemen bewegen.
• Kernproduktentwicklung: React-Schnittstellen, APIs, PostgreSQL-Abfragen, Berechtigungen, Migrationen, Leistungsoptimierung und gelegentlich ein Bug, dessen Ursache alle zum Schweigen bringt.

Unser Stack

• Infrastruktur: AWS, Terraform, GitHub Actions, Sentry
• Immer mehr: LLM-APIs, Embeddings, Vektorsuche, MCP, KI-unterstützte Ingenieur-Workflows

Sie benötigen keine Erfahrung mit jedem Punkt. Das Nachdenken über Systeme ist uns wichtiger als das Auswendiglernen unseres genauen Stacks.

Sie könnten gut passen, wenn

• Sie umfangreiche Produktionsanwendungen mit TypeScript, React und Node.js entwickelt haben und wissen, dass der schwierige Teil normalerweise nach dem glücklichen Pfad beginnt.
• Sie denken über Daten nach, anstatt das ORM als die Datenbank zu behandeln, bringen ein Feature von einem unklaren Ausgangspunkt bis zur Produktion und lesen unbekannten Code, ohne sofort einen Rewrite vorzuschlagen.
• Sie kümmern sich um Wartbarkeit, verwenden aber "sauberen Code" nicht als Ausrede, um drei Wochen an etwas zu arbeiten, das die Kunden gestern benötigten.
• Und wenn etwas in der Produktion kaputt geht, ist Ihr Instinkt, das System zu verstehen, nicht die Person zu finden, die schuld ist.

Sie könnten diese Rolle nicht genießen, wenn

• Sie vollständig spezifizierte Tickets bevorzugen, möchten, dass die wichtigen Entscheidungen für Sie getroffen werden, lieber auf einer Seite der Frontend-/Backend-Grenze bleiben, für das Schließen von Aufgaben anstatt für Ergebnisse optimieren, sich über sich ändernde Anforderungen frustriert fühlen oder möchten, dass die Verantwortung sorgfältig innerhalb Ihrer Stellenbeschreibung bleibt.

Es gibt hervorragende Ingenieurteams, die so aufgebaut sind. Wir versuchen nicht, eines davon zu sein.

Wie wir arbeiten

Wir sind ein kleines Ingenieurteam, daher gibt es weniger Orte, an denen Verantwortung verschwinden kann, und keine Kette von fünf Personen zwischen Ihnen und einer Entscheidung. Wir bevorzugen schriftlichen Kontext über Meetings, die der Kalender erfunden hat, und funktionierende Software über aufwendige Prozesse. Schnell bedeutet nicht nachlässig. Manchmal ist der schnellste Weg die einfache Version heute, manchmal ist es ein weiterer Tag auf einem Fundament, auf dem zwanzig zukünftige Funktionen sitzen werden. Zu wissen, in welcher Situation Sie sich befinden, ist Teil des Jobs. Erwarten Sie, sehr früh in die Produktion zu liefern.

Wie wir einstellen

Kein siebenstufiger Ausdauertest. Keine Algorithmus-Trivia, die von der Arbeit losgelöst ist. Einführung. Sie, wir und ob dies die Umgebung ist, die Sie tatsächlich suchen. Technisches Gespräch. Wir gehen tief auf etwas Schwieriges ein, das Sie gebaut haben: die Entscheidungen, die Alternativen, was Sie jetzt anders machen würden. Technische Bewertung. In der Regel Live-Coding zu einem realistischen Problem, manchmal stattdessen ein kleiner Proof of Concept. Uns interessiert, wie Sie denken, nicht, ob Ihre Lösung mit unserer übereinstimmt. Angebot. Wenn es eine starke gegenseitige Überzeugung gibt, handeln wir.

Eine letzte Sache

Stellenbeschreibungen haben die Angewohnheit, Kandidaten zu produzieren, die sich gegen Aufzählungspunkte optimieren. Bitte tun Sie das nicht. Wenn Sie dies lesen und denken: "Ich kann das meiste davon, aber ich habe nicht mit MCP gearbeitet", bewerben Sie sich. Starke Grundlagen, bedeutende Software, die ausgeliefert wurde, und eine Neigung zur Eigenverantwortung sind das, wonach wir suchen. Der Rest ist erlernbar.