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

Tl;dr: Schließe dich GlassDollar an und hilf dabei, 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 "implementiere, was im Ticket steht". Du wirst ein unklar definiertes Problem anpacken, es gemeinsam mit dem Produktteam gestalten, wichtige technische Entscheidungen treffen, es umsetzen und nah genug dran bleiben, um zu sehen, ob es funktioniert.

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.

GlassDollar OS ist das Betriebssystem für Venture Clienting: Problem → Startup-Entdeckung → Bewertung → PoC → Übernahme, in einem wiederholbaren Workflow.

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

• Du kannst ein Problem weiterführen als nur das Ticket. Die Arbeit beginnt oft mit etwas Unvollständigem, wie "Kunden benötigen einen besseren Weg, um X zu verwalten". Du wirst das Problem mit dem Produktteam gestalten, Annahmen herausfordern und entscheiden, was in dieser Iteration dazugehört.
• Du kümmerst dich um das Produkt. Du möchtest wissen, für wen du baust, warum das Problem wichtig ist und wie Erfolg aussieht. Dieser Kontext sollte deine technischen Entscheidungen prägen.
• Du hast technisches Urteilsvermögen. Es gibt selten eine richtige Architektur. Du weißt, wann die langweilige Lösung die ambitionierte übertrifft, wann eine Abstraktion hilft und wann sie das Problem verbirgt, und wann ein kleines Feature sechs Monate technische Schulden verursachen könnte.
• Du machst das System besser, nicht nur das Feature. Du behebst das Verbreitungsmuster anstelle des einzelnen Vorfalls, machst eine API einfacher für die nächste Person und verbesserst Tests, weil die aktuelle Einrichtung alle Angst macht, zu deployen.
• Du kannst über den gesamten Stack hinweg arbeiten. Ein Feature könnte von einer React-Interaktion über GraphQL in einen Node-Dienst, ein Schema-Redesign, ein Berechtigungsupdate und eine sichere Migration für bestehende Kunden laufen.
• Du übernimmst Verantwortung für die Qualität. Wir haben QA. Das ist nicht der Ort, an dem die Qualität beginnt. Was passiert, wenn diese Anfrage zweimal erfolgt? Was passiert mit alten Daten oder wenn die API mitten im Prozess ausfällt?
• Du kommunizierst so, als ob deine Entscheidungen später wichtig sein werden. Sechs Monate von jetzt an sollte jemand eine wichtige Entscheidung verstehen, ohne durch siebzehn Slack-Nachrichten und einen gelöschten Notion-Kommentar graben zu müssen.
• Du hebst die Ingenieurnorm um dich herum an. Du benötigst keinen Managementtitel, um Einfluss zu haben. Finde das Loch in einer Architektur, befreie jemanden, ohne ihm die Tastatur wegzunehmen, und widerspreche, ohne jede Entscheidung in ein Referendum zu verwandeln.

Was du tun wirst

• Enterprise-Integrationen: in die Systeme, Daten, Identitätsanbieter und Workflows unserer Kunden. Das ist es, was GlassDollar von Software, in die man sich einloggt, zu Infrastruktur macht, 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.
• KI in realen Workflows: Einbettungen, Vektorsuche und LLMs über eine große Datenbank von Startups und Unternehmensinnovationsdaten.
• 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

• Frontend: TypeScript, React, Material UI, Apollo Client, Playwright
• Backend: Node.js, GraphQL, Prisma, PostgreSQL, Jest
• Infrastruktur: AWS, Terraform, GitHub Actions, Sentry
• Immer mehr: LLM-APIs, Einbettungen, Vektorsuche, MCP, KI-unterstützte Ingenieur-Workflows

Du musst nicht mit jedem Punkt Erfahrung haben. Das Nachdenken über Systeme ist uns wichtiger als das Auswendiglernen unseres genauen Stacks.

Anforderungen

• Umfangreiche Produktionserfahrung mit TypeScript, React und Node.js
• Komfortables Nachdenken über relationale Datenbanken, nicht nur das ORM
• Kann unabhängig ein Feature von einem unklaren Ausgangspunkt bis zur Produktion bringen
• Kann unbekannten Code lesen, ohne sofort einen Rewrite vorzuschlagen

Nice to have:

• Erfahrung mit GraphQL, Prisma oder PostgreSQL in großem Maßstab
• Exposition gegenüber LLM-APIs, Einbettungen oder Vektorsuche
• Erfahrung im Besitz von Systemen, nicht nur Features

Hast du nicht jeden Punkt erfüllt? Bewirb dich trotzdem. Wir würden lieber das Gespräch führen, als jemanden wegen eines Bullet Points zu verlieren.

Wie wir einstellen

Wir sind ein kleines Ingenieurteam, daher gibt es weniger Orte, an denen Verantwortung verloren geht, und keine Kette von fünf Personen zwischen dir 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 du dich befindest, ist Teil des Jobs. Erwarten, sehr früh in die Produktion zu liefern.

Wie wir einstellen

• Kein siebenstufiger Ausdauertest. Keine Algorithmus-Trivia, die vom Job losgelöst sind.
• Einführung. Du, wir und ob dies die Umgebung ist, die du tatsächlich suchst.
• Technische Unterhaltung. Wir gehen tief auf etwas Schwieriges ein, das du gebaut hast: die Entscheidungen, die Alternativen, was du jetzt anders machen würdest.
• Technische Bewertung. In der Regel Live-Coding zu einem realistischen Problem, manchmal ein kleiner Proof of Concept. Uns interessiert, wie du denkst, nicht ob deine Lösung mit unserer übereinstimmt.
• Angebot. Wenn es eine starke gegenseitige Überzeugung gibt, machen wir weiter.

Eine letzte Sache

Stellenbeschreibungen haben die Angewohnheit, Kandidaten zu produzieren, die sich gegen Bullet Points optimieren. Bitte tu das nicht. Wenn du das hier liest und denkst: "Ich kann das meiste davon, aber ich habe nicht mit MCP gearbeitet", bewirb dich.

Starke Grundlagen, bedeutende Software, die ausgeliefert wurde, und eine Neigung zum Eigentum sind das, wonach wir suchen. Der Rest ist erlernbar.