Interviewfragen für Engineering Manager, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Die meisten dieser Fragen sind Verhaltensfragen: Der Interviewer will einen Fall aus deiner eigenen Arbeit hören. Beschreib die Lage in ein oder zwei Sätzen, dann was du getan hast und warum, dann das Ergebnis und dann, was du gelernt hast. Lass Namen und vertrauliche Details weg; es zählt der Aufbau der Geschichte.

Was ein Engineering Manager können muss

• Menschen: FührungIn 8 % der Anzeigen für Engineering Manager gefragt (Stand 05.11.2026).Menschen führen, die ihren Code besser kennen als du: Richtung geben, Feedback geben, sie wachsen lassen, entscheiden. von Entwicklern, Einzelgespräche, Feedback, Entwicklung und Recruiting, und KommunikationIn 36 % der Anzeigen für Engineering Manager gefragt (Stand 05.11.2026).Das Schwierige klar und freundlich sagen, im Einzelgespräch, schriftlich und vor der Geschäftsleitung., die in beide Richtungen klar ist.
• Lieferung: agileIn 0 % der Anzeigen für Engineering Manager gefragt (Stand 05.11.2026).Die Arbeitsweise eines Teams so steuern, dass es oft ausliefert und aus jedem Release lernt, egal wie die Methode heißt. Arbeitsweisen, Planung über Teams hinwegIn 36 % der Anzeigen für Engineering Manager gefragt (Stand 05.11.2026).Größere Lieferungen über Teams hinweg planen: Meilensteine, Abhängigkeiten, Risiken und eine ehrliche Terminspanne., Schätzungen mit ehrlichen Spannen und Ziele, die manche Firmen als OKRs setzen.
• Das Geschäft: Stakeholder-ManagementIn 10 % der Anzeigen für Engineering Manager gefragt (Stand 05.11.2026).Produkt, Design, Vertrieb und Geschäftsleitung informiert und einig halten, was das Team tut und warum. mit Produkt, Vertrieb und Geschäftsleitung, und einen Plan oder ein Problem vorstellenEinen Plan, einen Vorfall oder eine Anfrage nach mehr Stellen der Geschäftsleitung in wenigen klaren Folien vorstellen..
• Genug Technik: was die Delivery-PipelineIn 7 % der Anzeigen für Engineering Manager gefragt (Stand 05.11.2026).Die Delivery-Pipeline gut genug verstehen, um das Risiko eines Releases einzuschätzen und die Investition des Teams darin zu stützen., die Architektur und die Cloud-Rechnung für Risiko und Tempo bedeuten, damit du Abwägungen mit den Entwicklern beurteilen kannst.

Die Anzeigen nennen die Werkzeuge nebeneinander, und keines ist überall Pflicht: Jira, Linear oder Azure DevOps, um Arbeit zu verfolgen, Confluence oder Notion für Dokumente und in manchen Firmen Lattice oder Culture Amp für Beurteilungen und Feedback. Im Interview wird geprüft, wie du sie genutzt hast, um dem Team zu helfen, nicht das Werkzeug selbst.

Menschen: Einzelgespräche, Feedback und Entwicklung

Wie führst du Einzelgespräche, und was tust du, wenn ein Entwickler nichts zu sagen hat?

Worauf sie achten: dass Einzelgespräche dem Entwickler gehören und kein Statusmeeting sind.

Kurze Antwort: „Ein Einzelgespräch ist ein regelmäßiges Gespräch unter vier Augen, meist wöchentlich oder alle zwei Wochen, und es gehört dem Entwickler. Ich lasse ihn die Themen setzen, führe Notizen, die wir beide sehen, und lasse den Status in den Kanälen des Teams. Hat jemand nichts zu sagen, frage ich nach Energie, Blockaden, was er lernen will und was er im Team ändern würde.“

Die ausführliche Antwort: Schweigen heißt oft, dass noch kein Vertrauen da ist oder dass die Person den Sinn nicht sieht. Behalte den Termin, verkürze ihn und greif auf, was beim letzten Mal gesagt wurde: Wer bei kleinen Dingen handelt, bekommt auch die großen erzählt. Verlege Karrieregespräche alle paar Monate in einen eigenen Termin.

Schwache Antwort: „Wir gehen zusammen die Tickets durch.“ Nachfrage: „Woran merkst du, dass deine Einzelgespräche wirken?“ Nenn ein Signal, etwa Probleme, die früh angesprochen werden.

Erzähl von einem Mal, als du einem starken Entwickler schwieriges Feedback gegeben hast.

Worauf sie achten: Mut, Fürsorge und eine klare Botschaft.

Kurze Antwort: „Die Code-Reviews eines Senior-Entwicklers waren schroff, und neuere Kollegen baten ihn nicht mehr darum. Ich habe ihm unter vier Augen gesagt, kurz nach einem Beispiel, was ich gesehen habe, welche Wirkung es auf das Team hat und was ich stattdessen brauche, und habe gefragt, wie er es sieht. Wir haben eine Änderung vereinbart, und zwei Wochen später habe ich nachgefragt.“

Die ausführliche Antwort: Gutes Feedback ist konkret, betrifft Verhalten und seine Wirkung, kommt früh und unter vier Augen. Starke Leute hören oft nur Lob, deshalb brauchen gerade sie ehrliches Feedback. Bleib dran: Bemerke die Veränderung und sag es.

Schwache Antwort: „Ich habe auf das Jahresgespräch gewartet.“ Nachfrage: „Er war anderer Meinung als du.“ Sag, wie du zuhören und trotzdem bei deiner Linie bleiben würdest.

Ein Entwickler bringt seit zwei Monaten schwache Leistung. Was tust du?

Worauf sie achten: Fairness, Tempo und Dokumentation.

Kurze Antwort: „Zuerst finde ich heraus, warum: unklare Erwartungen, die falsche Arbeit, eine Lücke im Können oder etwas außerhalb der Arbeit. Ich benenne die Lücke mit Beispielen, vereinbare, wie gut aussieht und bis wann, und unterstütze mit Pairing oder einem Mentor. Ändert sich nach einer fairen Zeit nichts, arbeite ich mit HR an einem formalen Plan.“

Die ausführliche Antwort: Die meisten Leistungsprobleme lösen sich durch Klarheit und Unterstützung; manche brauchen eine andere Rolle. Schreib von Anfang an mit, damit die Person nie überrascht wird. Schütz das Team davor, die Lücke monatelang mitzutragen. In manchen Ländern legen ein Gesetz oder eine Betriebsvereinbarung mit dem Betriebsrat die formalen Schritte fest, deshalb führt HR sie.

Schwache Antwort: „Ich würde ihn in ein anderes Team versetzen.“ Nachfrage: „Die Person erzählt dir, dass sie mit einer Krankheit zu kämpfen hat.“ Erklär, wie das den Plan verändert.

Wie würdest du das Recruiting für dein Team aufsetzen, und wie sorgst du für ein gutes Onboarding?

Worauf sie achten: ein fairer, strukturierter Prozess und neue Leute, die schnell produktiv sind.

Kurze Antwort: „Ich kläre mit dem Team, was die Rolle braucht, und führe dann einen strukturierten Prozess: dieselben Fragen für jeden Kandidaten, eine realistische Arbeitsprobe und Interviewer, die bewerten, bevor sie sich austauschen. Fürs Onboarding bereite ich einen Buddy vor, Zugänge am ersten Tag, eine kleine Änderung, die in der ersten Woche live geht, und klare Ziele für die ersten drei Monate.“

Die ausführliche Antwort: Gut einzustellen ist das Nachhaltigste, was eine Führungskraft tut. Achte auf Vorurteile: gemischte Panels, schriftliche Kriterien und dieselben Chancen für jeden Kandidaten. Miss das Onboarding daran, wie schnell ein neuer Entwickler selbstständig arbeitet, und frag ihn, was gefehlt hat.

Schwache Antwort: „Ich stelle Leute ein, mit denen ich gern ein Bier trinken würde.“ Nachfrage: „Du brauchst drei Entwickler in einem schwierigen Markt.“ Sag, wo du Kompromisse machen würdest und wo nicht.

Wie entscheidest du, wer bereit für eine Beförderung ist, und wie nutzt du eine Karriereleiter?

Worauf sie achten: dass Beförderungen auf Belegen beruhen, nicht darauf, wer am lautesten ist.

Kurze Antwort: „Eine Karriereleiter beschreibt, was jede Stufe an Verantwortungsbereich, Wirkung und Verhalten bedeutet. Ich nutze sie in Karrieregesprächen, um mit jedem Entwickler den nächsten Schritt zu vereinbaren, helfe ihm, Arbeit auf dieser Stufe zu finden, und sammle unterwegs Belege. Zeigen die Belege, dass er schon auf der nächsten Stufe arbeitet, setze ich mich für ihn ein.“

Die ausführliche Antwort: Eine Beförderung sollte bestätigen, was schon passiert. Gleich die Einstufungen mit anderen Managern ab, damit die Stufen in allen Teams dasselbe bedeuten. Sprich Lücken früh ehrlich an, damit niemand von einem Nein überrascht wird.

Schwache Antwort: „Nach zwei Jahren ist man dran.“ Nachfrage: „Zwei Entwickler wollen dieselbe Senior-Rolle in einem kleinen Team.“ Erklär, wie du damit umgehen würdest.

Zwei Senior-Entwickler sind sich bei einem Design überhaupt nicht einig, und das Team ist gespalten. Wie gehst du mit dem Konflikt um?

Worauf sie achten: dass du Konflikte löst, ohne selbst zum Engpass zu werden.

Kurze Antwort: „Ich sorge dafür, dass beide Seiten die Optionen und die Abwägungen nach denselben Kriterien aufschreiben, etwa Kosten, Risiko und wie schwer sich etwas später ändern lässt. Oft wird die Wahl dann klar. Wenn nicht, benenne ich, wer entscheidet, oft der Tech Lead oder der Architekt, setze einen Termin und bitte alle, die Entscheidung mitzutragen, auch wenn sie anderer Meinung waren.“

Die ausführliche Antwort: Trenn die technische Frage von der persönlichen Reibung und kümmere dich um beides. Ein Entscheidungsprotokoll hilft dem Team, sich zu erinnern, warum. Geraten dieselben zwei Leute immer wieder aneinander, ist das ein Thema für die Einzelgespräche.

Schwache Antwort: „Ich nehme die Option, die mir am besten gefällt.“ Nachfrage: „Die Entscheidung erweist sich sechs Monate später als falsch.“ Sag, wie das Team reagieren sollte.

Wie erkennst du Burnout in einem Team, und was änderst du?

Worauf sie achten: ein Blick für die Grenzen der Menschen und für die Ursachen, nicht nur die Symptome.

Kurze Antwort: „Anzeichen sind späte Nachrichten, gereizte Stimmung, mehr Fehler, Leute, die in Meetings verstummen, und mehr Krankheitstage. Ich frage in den Einzelgesprächen direkt nach und behebe dann die Ursachen: zu viel parallele Arbeit, eine unfaire Rufbereitschaft, ständige Unterbrechungen oder unklare Prioritäten.“

Die ausführliche Antwort: Psychologische Sicherheit, das Gefühl, etwas ansprechen zu können, ohne bestraft zu werden, sorgt dafür, dass die Leute es dir sagen, bevor es zu spät ist. Schütz Zeit für konzentrierte Arbeit, verteil die Rufbereitschaft fair und widersprich Terminen, die Überstunden schon einplanen.

Schwache Antwort: „Alle haben viel zu tun; das gehört zum Job.“ Nachfrage: „Die Geschäftsleitung will das Release trotzdem nächsten Monat.“ Sag, was du anbieten würdest.

Lieferung: Schätzungen, Prioritäten, Schulden und Vorfälle

Wie schätzt du ein großes Vorhaben, und wie nennst du den Stakeholdern einen Termin?

Worauf sie achten: ehrliche Spannen und frühe Warnungen.

Kurze Antwort: „Ich lasse die Entwickler die Arbeit in kleinere Teile zerlegen und diese schätzen, vergleiche mit ähnlicher früherer Arbeit und nenne eine Spanne mit den wichtigsten Risiken, keinen einzelnen Tag. Ich sage, was den Termin früher oder später machen würde, und passe die Spanne an, während wir dazulernen, damit eine Verzögerung nie eine Überraschung ist.“

Die ausführliche Antwort: Feste Termine sind manchmal echt, etwa durch ein Gesetz oder ein Ereignis; dann bewegt sich der Umfang. Kläre früh, welche Teile Pflicht sind. Ein kurzer erster Teil, der live geht, sagt dir mehr über die Schätzung als jedes Meeting.

Schwache Antwort: „Ich schlage fünfzig Prozent auf alles, was das Team sagt.“ Nachfrage: „Nach der Hälfte siehst du, dass der Termin nicht hält.“ Sag, wann und wie du es den Leuten sagst.

Das Produktmanagement will drei Features in diesem Quartal, und das Team schafft zwei. Wie setzt du mit dem Produktmanager die Prioritäten?

Worauf sie achten: Partnerschaft mit dem Produktmanagement und ein begründetes Nein.

Kurze Antwort: „Der Produktmanager verantwortet, was für die Kunden am wichtigsten ist; ich verantworte, was das Team schaffen kann und zu welchen Kosten. Wir schauen gemeinsam auf Nutzen und Aufwand jedes Features, und ich biete Optionen an: zwei vollständige Features oder drei kleinere Versionen. Die Wahl liegt bei ihm, mit klarer Abwägung.“

Die ausführliche Antwort: Halte eine sichtbare Roadmap, den Plan dessen, was als Nächstes kommt und warum, damit Abwägungen offen getroffen werden. Schütz einen Anteil für Zuverlässigkeit und Schulden, auf den ihr euch beide geeinigt habt. Eskaliert gemeinsam, nicht gegeneinander.

Schwache Antwort: „Wir arbeiten einfach mehr.“ Nachfrage: „Der CEO hat das dritte Feature einem Kunden versprochen.“ Erklär, was du tun würdest.

Wie viel Zeit sollte ein Team in technische Schulden stecken, und wie argumentierst du dafür?

Worauf sie achten: dass du technische Bedürfnisse in der Sprache des Geschäfts erklären kannst.

Kurze Antwort: „Technische Schulden sind die Kosten früherer Abkürzungen, die heute jede Änderung bremsen. Ich argumentiere mit ihrer Wirkung: langsamere Releases, mehr Vorfälle, längeres Onboarding. Viele Teams reservieren dafür einen festen Anteil jedes Sprints oder Quartals und beheben die Schulden in den Teilen, die sie am häufigsten ändern.“

Die ausführliche Antwort: Nicht jede Schuld muss abbezahlt werden. Verfolge die wenigen Punkte, die wirklich wehtun, verknüpfe jeden mit einer Kennzahl und berichte, was sich nach der Behebung geändert hat. Das bringt dir das Vertrauen für die nächste Runde.

Schwache Antwort: „Wir schreiben es neu, wenn wir Zeit haben.“ Nachfrage: „Das Produktmanagement sagt, Arbeit an Schulden habe keinen sichtbaren Wert.“ Antworte in einem Satz.

Erklär mir, wie dein Team mit einem Vorfall umgeht, vom Alarm bis zur Nachbesprechung.

Worauf sie achten: ein ruhiger Ablauf und Lernen ohne Schuldzuweisung.

Kurze Antwort: „Der Entwickler in Rufbereitschaft, also die Person, die in dieser Woche Dienst hat, bekommt den Alarm, übernimmt die Leitung oder holt Hilfe, und jemand hält Nutzer und Stakeholder auf dem Laufenden. Ist es behoben, halten wir ein Postmortem ohne Schuldzuweisung: was passiert ist, warum unsere Systeme es zugelassen haben und welche Maßnahmen es unwahrscheinlicher machen, jede mit einem Verantwortlichen.“

Die ausführliche Antwort: Meine Aufgabe während eines Vorfalls ist vor allem, die Leute zu schützen, die ihn beheben: klare Rollen, keine Traube von Managern, die nach dem Stand fragen, und eine Pause für den, der nachts wach war. Danach sorge ich dafür, dass die Maßnahmen erledigt werden und nicht hinter neuen Features verloren gehen.

Schwache Antwort: „Wir finden heraus, wer den Fehler gemacht hat.“ Nachfrage: „Dieselbe Art von Vorfall passiert noch einmal.“ Sag, was dir das verrät.

Welche Kennzahlen nutzt du, um die Lieferung zu verstehen, und welche lehnst du ab?

Worauf sie achten: dass du das System misst, nicht einzelne Menschen.

Kurze Antwort: „Ich schaue auf den Fluss auf Teamebene: die DORA-Kennzahlen, benannt nach einem Forschungsprogramm und nicht nach den gleichnamigen Finanzregeln der EU, also wie oft wir deployen, wie lange eine Änderung bis zu den Nutzern braucht, wie oft eine Änderung scheitert und wie schnell wir uns erholen, dazu die Durchlaufzeit und wie viel Arbeit gerade läuft. Ich lehne es ab, Menschen nach geschlossenen Tickets oder geschriebenen Codezeilen zu reihen.“

Die ausführliche Antwort: Kennzahlen eröffnen Gespräche; sie beenden sie nicht. Nutze sie als Trends für das Team, verbinde sie damit, wie es den Leuten geht und was die Kunden sagen, und sei vorsichtig, wo ein Betriebsrat oder örtliche Regeln die Erfassung begrenzen.

Schwache Antwort: „Story Points pro Entwickler.“ Nachfrage: „Die Geschäftsleitung will eine einzige Zahl für die Produktivität.“ Erklär, was du anbieten würdest.

Wie führst du ein Remote-Team oder ein verteiltes Team gut?

Worauf sie achten: bewusste Gewohnheiten statt Hoffnung.

Kurze Antwort: „Alles aufschreiben: Entscheidungen, Pläne und Protokolle. Ein paar gemeinsame Stunden für Gespräche live halten und den Rest für konzentrierte Arbeit schützen. Darauf achten, dass nicht immer die Kollegen in anderen Zeitzonen spätabends dazukommen müssen, und sich ab und zu persönlich treffen.“

Die ausführliche Antwort: Remote-Teams verlieren den Smalltalk, in dem Probleme auftauchen, deshalb zählen Einzelgespräche und offene Kanäle mehr. Achte darauf, dass Leute weit weg vom Büro dieselbe sichtbare Arbeit und dieselben Chancen auf eine Beförderung bekommen.

Schwache Antwort: „Ich prüfe, ob die Leute online sind.“ Nachfrage: „Ein Entwickler sagt in Calls nie etwas.“ Sag, was du versuchen würdest.

Runden für Senior-Rollen: Manager, Budgets und Stakeholder

Wie würdest du Stellen und Budget für das nächste Jahr planen?

Worauf sie achten: die Verbindung von Menschen und Geld zum Plan.

Kurze Antwort: „Ich gehe davon aus, was das Geschäft nächstes Jahr will, was die Teams heute liefern können, und von der Lücke dazwischen. Daraus ergibt sich ein Antrag auf Stellen mit einer Begründung für jede Rolle, dazu Werkzeuge, Cloud-Kosten und Weiterbildung. Ich zeige, was wir mit weniger schaffen und worauf wir verzichten würden.“

Die ausführliche Antwort: Einstellen dauert Monate, also plane, wann die Leute anfangen, nicht nur wie viele. Halte die Führungsspanne, die Zahl der Menschen, die an eine Führungskraft berichten, vernünftig, während die Teams wachsen; bei etwa acht bis zehn ist es Zeit für einen Lead oder einen weiteren Manager.

Schwache Antwort: „Ich verlange so viele Leute wie möglich.“ Nachfrage: „Das Budget wird um ein Fünftel gekürzt.“ Sag, was zuerst wegfällt.

Du übernimmst ein Team mit wenig Vertrauen und verpassten Terminen. Was tust du in deinen ersten neunzig Tagen?

Worauf sie achten: zuhören, bevor du handelst, dann wenige klare Veränderungen.

Kurze Antwort: „In den ersten Wochen höre ich zu: Einzelgespräche mit allen, mit dem Produktmanager und den wichtigsten Stakeholdern, und ich schaue, wie die Arbeit wirklich fließt. Dann wähle ich mit dem Team zwei oder drei Veränderungen, etwa klarere Prioritäten oder kleinere Releases, und zeige frühe Ergebnisse.“

Die ausführliche Antwort: Vertrauen kommt durch gehaltene Versprechen zurück, also gib wenige und halte sie. Sei gegenüber den Stakeholdern ehrlich, wenn die Termine neu gesetzt werden. Liegt die Ursache bei einer Person, kümmere dich darum, aber prüf zuerst das System.

Schwache Antwort: „Ich führe am ersten Tag meinen eigenen Prozess ein.“ Nachfrage: „Dein bester Entwickler kündigt in der dritten Woche.“ Sag, was du tun würdest.

Wie arbeitest du mit Stakeholdern außerhalb der Entwicklung, etwa Vertrieb oder Geschäftsleitung, wenn sie auf eine Zusage drängen, die du nicht geben kannst?

Worauf sie achten: bestimmt, freundlich und mit Optionen.

Kurze Antwort: „Ich finde heraus, was sie wirklich brauchen und bis wann, und biete an, was wir schaffen: eine kleinere Version, einen späteren Termin oder einen Tausch gegen andere Arbeit. Ich halte die Vereinbarung schriftlich fest und halte sie auf dem Laufenden, damit sie auch der nächsten Antwort trauen.“

Die ausführliche Antwort: Zu allem Ja zu sagen zerbricht Teams und Vertrauen. Bau Beziehungen auf, bevor du sie brauchst, lern die Geschäftssprache von Vertrieb und Finanzen und hol den Produktmanager in jedes solche Gespräch.

Schwache Antwort: „Ich verspreche es, und das Team findet einen Weg.“ Nachfrage: „Der Deal ist groß, und der CEO sitzt mit im Raum.“ Antworte in zwei Sätzen.

Dein Lebenslauf für diese Fragen

Jede Stelle in deinem Lebenslauf lädt zu den Fragen oben ein: wie viele Menschen, was du verändert hast, was live gegangen ist und was du gelernt hast. Gib jeder dieser Geschichten eine Zeile, so geschrieben, dass ein Director mehr hören will:

Prüf deinen Lebenslauf mit der kostenlosen Bewertung an einem Job als Engineering Manager, den du willst; jeder Bereich, den sie als dünn erkennt, ist der, den du zuerst üben solltest, mit einer Geschichte aus deiner eigenen Arbeit.