Sales Engineer
Strukturierte Interviewfragen für Sales Engineer — mit dem Signal, auf das eine starke Antwort jeweils hinweist.
VerhaltensbezogenDiagnose und Lernfähigkeit Beschreiben Sie den letzten technischen Deal, den Sie verloren haben, obwohl Ihr Produkt technisch geeignet war. Was ist passiert?
Worauf eine starke Antwort hinweistFähigkeit, einen verlorenen Deal über die rein technische Frage hinaus zu diagnostizieren: Stakeholder-Misalignment, fehlender wirtschaftlicher Sponsor, schlechtes Timing, Procurement-Blockade. Bonus: die:der Kandidat:in identifiziert ein Frühsignal, das sie:er heute anders aufnehmen würde (etwa Ich habe in der Discovery zu wenig zu den Build-vs-Buy-Diskussionen gefragt). Kandidat:innen, die alles auf Preis oder Konkurrenz-Feature schieben, zeigen schwache Discovery-Reife.
VerhaltensbezogenPOC- und Demo-Strategie Erzählen Sie mir vom komplexesten technischen Proof-of-Concept, den Sie begleitet haben. Was war der Scope, wer war beteiligt, was war die größte Schwierigkeit?
Worauf eine starke Antwort hinweistFähigkeit, einen POC zu strukturieren: klare Erfolgskriterien vor dem Start, Zeitfenster begrenzt (typisch 2-4 Wochen, nicht 3 Monate), Stakeholder-Mapping (technischer Sponsor, wirtschaftlicher Sponsor, Anwender:innen). Konkrete Angaben zu Dauer und Etappen. Kandidat:innen, die einen POC ohne Erfolgskriterien beschreiben, haben in Wirklichkeit eine erweiterte Demo geführt, keinen echten POC.
VerhaltensbezogenTechnische Qualifizierung Beschreiben Sie eine Situation, in der Sie eine:m Account Executive sagen mussten, dass ein Deal technisch nicht qualifiziert ist. Warum, und wie haben Sie das kommuniziert?
Worauf eine starke Antwort hinweistReife in der Sales-Engineering-AE-Partnerschaft: Fähigkeit, einen Deal zu disqualifizieren oder zu re-scopen, ohne die Beziehung zur:zum AE zu beschädigen. Konkretes Beispiel mit Auftragswert, Begründung und Reaktion der:des AE. Kandidat:innen, die nie disqualifiziert haben, sind entweder zu defensiv (nicht trauen, gegenzuhalten) oder hatten keine Verantwortung für die technische Qualifizierung.
SituativPragmatismus und Ehrlichkeit Ein:e Account Executive bittet Sie 24 Stunden vor einer Vorstands-Demo um eine Spezial-Anpassung, die das Produkt eigentlich nicht abdeckt. Wie reagieren Sie?
Worauf eine starke Antwort hinweistSauberes Abwägen: Diagnose des wahren Bedarfs (ist die Anpassung wirklich nötig oder will die:der AE den Deal nur retten?), Optionen anbieten (Workaround in der Demo, expliziter Hinweis im Vorstands-Termin, ehrlicher Zeitplan zur künftigen Lieferung), Beteiligung von Engineering oder Produkt, wenn nötig. Antworten der Marke ich baue das schnell zusammen oder ich blocke die Demo sind beide rote Flaggen.
SituativGlaubwürdigkeit Während einer Live-Demo stellt die:der technische Sponsor:in eine Frage, deren Antwort Sie nicht kennen. Wie gehen Sie damit um?
Worauf eine starke Antwort hinweistSouveränität im Nicht-Wissen: explizite Anerkennung (Das ist eine gute Frage, da bin ich nicht sicher, ich kläre das bis morgen und melde mich), konkrete Nachverfolgung mit Termin, kein Bluffen. Bonus: die:der Kandidat:in nennt einen realen Fall, in dem dieser ehrliche Umgang Vertrauen geschaffen hat. Kandidat:innen, die antworten ich erfinde nie etwas, ohne ein konkretes Beispiel zu nennen, sind vorsichtig zu gewichten.
SituativPOC- und Demo-Strategie Sie haben drei parallele POCs in unterschiedlichen Phasen. POC A (3 Wochen alt, Erfolgskriterien klar, technischer Sponsor engagiert), POC B (5 Wochen alt, Erfolgskriterien diffus, wechselnder Sponsor), POC C (1 Woche alt, klar, sehr engagiertes Team). Wie priorisieren Sie?
Worauf eine starke Antwort hinweistPriorisierung nach Wahrscheinlichkeit und Aufwand, nicht nach Alter: POC A und C sollten Priorität haben (klare Kriterien, engagierte Stakeholder); POC B braucht Klärung oder Cut. Antworten der Marke ich arbeite an dem POC, der am ältesten ist sind ein Bias zu Sunk Cost; Antworten der Marke ich arbeite parallel an allen drei zeigen mangelnde Priorisierung.
CaseCross-funktionale Zusammenarbeit Ein Prospect fordert eine native Integration mit einem System, das wir aktuell nur über CSV-Import unterstützen. Roadmap-Plan dafür: 9 Monate. Der Deal hat einen Auftragswert von 120 k€ pro Jahr. Wie gehen Sie vor?
Worauf eine starke Antwort hinweistStrukturiertes Vorgehen: (1) Klärung des wahren Bedarfs (Echtzeit-Sync oder Tages-Sync?, welches konkrete Volumen?), (2) Workaround-Optionen prüfen (CSV-Import mit Automatisierung, Drittanbieter-Integrationen wie Zapier oder Workato, kundenspezifische Lösung), (3) Eskalation an Produkt zur Roadmap-Prüfung mit klarer Business-Begründung, (4) ehrliche Kommunikation der Zeitleiste an die:den Prospect. Kandidat:innen, die einfach eine Roadmap-Zusage in 3 Monaten machen, ohne mit Produkt zu sprechen, sind eine rote Flagge.
CaseDemo-Erzählung Bereiten Sie eine 10-minütige Discovery-Demo unseres Produkts (oder eines vergleichbaren Tools) für einen fiktiven Prospect vor: ein Logistik-KMU mit 80 Mitarbeitenden, das aktuell Excel und einen Eigenbau zur Auftragsverfolgung nutzt. Wie strukturieren Sie?
Worauf eine starke Antwort hinweistDemo als Erzählung, nicht als Feature-Tour: Einstieg über den Schmerz des Prospects (Excel-Chaos, fehlende Sichtbarkeit, manuelle Übergaben), dann gezielte Features, die genau diesen Schmerz lösen, mit konkreten Vorher-Nachher-Szenarien. Nicht mehr als 3-4 Features in 10 Min. Bonus: die:der Kandidat:in stellt vor Beginn 2-3 Klärungsfragen (welche:r konkrete:r Anwender:in im Termin, welcher Schmerz hat den Termin ausgelöst, welche Konkurrenz-Tools sind im Spiel).
CaseGlaubwürdigkeit Architektur: ein Prospect fragt, wie unser Produkt mit 500 gleichzeitigen Nutzer:innen und 2 Millionen Datensätzen pro Tag umgeht. Sie kennen die genauen Zahlen unseres aktuellen Setups nicht im Kopf. Wie antworten Sie?
Worauf eine starke Antwort hinweistMethodisches Vorgehen: (1) klärende Rückfragen (handelt es sich um Lese- oder Schreiblast, welche Latenz-Anforderungen, welcher zeitliche Verlauf), (2) ehrliche Aussage zu dem, was Sie wissen vs. nicht wissen, (3) Bezug auf bekannte Referenzkund:innen oder veröffentlichte Benchmarks, (4) Vorschlag eines Performance-POCs mit dem realen Datenprofil. Antworten der Marke ja, das schafft das System locker ohne Datenbasis sind eine rote Flagge; Antworten der Marke ich weiß es nicht, frage Engineering und melde mich bis morgen sind reif.
FachlichTechnische Tiefe Erklären Sie mir, wie eine REST-API technisch von einer GraphQL-API unterscheidet. Wann würden Sie einer:m Prospect das eine, wann das andere empfehlen?
Worauf eine starke Antwort hinweistSicheres technisches Vokabular: REST als ressourcenorientiert mit festen Endpoints und HTTP-Verben, GraphQL als abfragebasiert mit einem Endpoint und flexibler Datenrückgabe. Anwendungsfälle: REST für einfache Server-zu-Server-Integrationen, GraphQL für komplexe Frontends mit variablen Anforderungen. Kandidat:innen, die nicht über Buzzword-Niveau hinauskommen (REST ist alt, GraphQL ist modern), haben ein Glaubwürdigkeitsdefizit gegenüber technischen Prospects.
FachlichCompliance- und Security-Tiefe Ein Prospect aus dem Gesundheitswesen fragt, wie Ihr Produkt mit DSGVO und einer geplanten ISO-27001-Zertifizierung umgeht. Welche Fragen stellen Sie zurück, und wie strukturieren Sie die Antwort?
Worauf eine starke Antwort hinweistVertrautheit mit Compliance-Vokabular ohne Anwaltston: Datenresidenz (EU oder nicht), Auftragsverarbeitungsvertrag, Subunternehmer-Listen, technische Maßnahmen (Verschlüsselung in Ruhe und in Bewegung, Audit-Logs), organisatorische Maßnahmen (Berechtigungskonzept, Schulungen), Zertifizierungsstatus. Bonus: die:der Kandidat:in benennt klar, was sie:er nicht beantworten kann, und verweist auf die Security- oder Legal-Ansprechperson. Wer ohne nachzufragen ja, sind wir komplett konform sagt, ist eine rote Flagge.
FachlichLerntempo Sie sollen ein neues Produktmodul lernen, das Engineering gerade ausliefert. Wie gehen Sie methodisch vor, um in 2 Wochen demo-fähig zu sein?
Worauf eine starke Antwort hinweistStrukturierte Lernmethode: (1) Roadmap und Release-Notes lesen, (2) Hands-on-Setup in einer Testumgebung, (3) zwei bis drei konkrete Anwender-Szenarien durchspielen, (4) Klärungssession mit Produkt-Owner oder Lead-Engineer, (5) Dry-Run der Demo mit einer:einem AE oder Kolleg:in vor dem ersten Kunden-Termin. Kandidat:innen, die nur die Dokumentation lesen, ohne hands-on zu üben, sind oft zu theoretisch in Demos.
WerteCoachbarkeit Wie nehmen Sie Feedback einer:eines Account Executive auf, wenn sie:er sagt, Ihre Demo war zu technisch und hat den Deal gefährdet?
Worauf eine starke Antwort hinweistOffenheit: Fähigkeit, das Feedback vom persönlichen Urteil zu trennen. Bonus: die:der Kandidat:in nennt ein konkretes Beispiel einer Verhaltensänderung nach unangenehmem AE-Feedback (etwa Discovery-First-Disziplin nach einer überladenen Demo). Kandidat:innen, die in der Antwort beschreiben, dem:der AE die technische Notwendigkeit erklärt zu haben statt zuzuhören, sind vorsichtig zu gewichten.
WerteTeamspiel Wie arbeiten Sie mit Engineering und Produkt zusammen, wenn ein:e Prospect ein Feature anfordert, das nicht auf der Roadmap steht?
Worauf eine starke Antwort hinweistPartnerschaftliche Haltung: strukturierte Übergabe an Produkt mit Business-Begründung (Auftragswert, Branche, Wettbewerbskontext), keine Aktivitäten hinter dem Rücken von Engineering, klare Erwartungssteuerung gegenüber dem:der Prospect. Kandidat:innen, die Engineering als Bremse oder Produkt als langsam beschreiben, zeigen eine Teamspiel-Schwäche, die in DACH-KMU-Strukturen schnell zu Reibung führt.
WerteTechnische Integrität Beschreiben Sie eine Entscheidung, in der Sie die langfristige technische Gesundheit eines Accounts höher gewichtet haben als ein kurzfristiges Closing.
Worauf eine starke Antwort hinweistVertriebsreife mit technischem Gewissen: Fähigkeit, einen Scope-Downgrade oder ein verschobenes Closing zu empfehlen, wenn die technische Eignung nicht passt. Konkret: die:der Kandidat:in nennt Auftragswert, Account und Langzeit-Wirkung (etwa weniger Churn im Folgejahr, kein technischer Eskalations-Fall, sauberer Upsell-Pfad). Kandidat:innen, die nie gegen ein kurzfristiges Closing entschieden haben, zeigen einen transaktionalen Bias.
Evaluations-Playbook
Die Rolle der:des Sales Engineer zeigt sich über fünf Evaluations-Stufen. Die Live-Demo-Übung in Stufe 4 ist die prädiktivste; sie zeigt, ob die:der Kandidat:in technische Tiefe mit Discovery-Disziplin und Erzählkunst verbindet. Validierung erfolgt durch Kumulation der Signale, nicht durch eine einzelne Stufe.
Stufe 1: CV-Lektüre
Suchen Sie nach Konsistenz zwischen technischem Hintergrund und Vertriebspraxis: ein:e gute:r Sales Engineer hat entweder eine Engineering- oder Beratungs-Vorgeschichte plus 2-4 Jahre dokumentierte Pre-Sales-Praxis, oder 5+ Jahre AE-Praxis mit klarem technischem Schwerpunkt (Demo-Verantwortung, RFP-Bearbeitung, Proof-of-Concept-Begleitung). Mindestverweildauer 18 Monate pro Position; mehrere 12-Monats-Stationen sind ein Signal für Branchen- oder Stack-Mismatch. Die Tiefe der Demo- und Proof-of-Concept-Verantwortung zählt mehr als die Anzahl unterstützter Deals.
Stufe 2: Phone Screen (30 Min.)
Nur drei Fragen: (1) Beschreiben Sie den letzten technischen Deal, bei dem Ihre Demo oder Ihr POC ausschlaggebend war, (2) Welche technische Frage einer:eines Prospects haben Sie zuletzt nicht beantworten können, und wie sind Sie damit umgegangen?, (3) Warum jetzt ein Wechsel? Ergebnis: Go/No-Go in 5 Min. Debrief. Vermeiden Sie tiefe technische Gotcha-Fragen auf dieser Stufe.
Stufe 3: Strukturiertes Interview (90 Min.)
Folgen Sie den 15 Fragen unten, abwechselnd behavioral, situational, case, technical und values. Achten Sie besonders auf das Gleichgewicht zwischen technischer Präzision und Discovery-Disziplin: ein:e starke:r Sales Engineer kann eine komplexe Architektur erklären, ohne in einen Produkt-Monolog zu kippen. Mindestens 2 Interviewer:innen (eine:r aus Sales, eine:r aus Engineering), unabhängiges Scoring vor dem Debrief.
Stufe 4: Live-Demo und Proof-of-Concept-Übung (90 Min.)
Geben Sie der:dem Kandidat:in eine Woche vor dem Termin ein Briefing eines fiktiven Prospects (Branche, Use-Case, 3-4 technische Anforderungen, ein versteckter Showstopper). Im Termin: 15 Min. Live-Discovery mit einer:einem Teammitglied in der Prospect-Rolle, dann 30 Min. produktbezogene Demo (Ihr eigenes Produkt oder ein nahes Open-Source-Äquivalent), dann 30 Min. Q&A zur Architektur und zur POC-Strategie, dann 15 Min. Debrief. Das ist die prädiktivste Stufe: die Qualität der Discovery-Fragen vor der Demo-Vertiefung und der Umgang mit dem versteckten Showstopper bestimmen die spätere Win-Rate-Wirkung.
Stufe 5: Referenzen (strukturierte Überprüfung)
Rufen Sie zwei Referenzen an: eine:n ehemalige:n Account Executive, mit der:dem die:der Kandidat:in zusammengearbeitet hat, und eine:n ehemalige:n Engineering- oder Produkt-Kolleg:in. Stellen Sie beiden dieselben vier Fragen: Worin ist sie:er am stärksten? Worin würden Sie eine ergänzende Person einstellen? Würden Sie sie:ihn morgen wieder als Pre-Sales-Partner:in haben wollen, warum oder warum nicht? Ein konkretes Beispiel eines technischen Deals, in dem die:der Kandidat:in den Unterschied gemacht hat? Die vierte Frage liefert das meiste Signal.
Woran Sie eine hervorragende Besetzung erkennen
| Kompetenz | Unter Anforderung | Auf Niveau | Über Anforderung |
|---|---|---|---|
| Technische Tiefe | Bleibt in der Demo auf Buzzword-Niveau (modern, skalierbar, sicher) ohne präzise Mechanismen. Stolpert bei Architektur- oder API-Fragen, sucht Lösungen durch Versuch und Irrtum ohne klares mentales Modell. | Beherrscht den aktuellen Stack und das eigene Produkt eigenständig. Kann eine neue Produktfeature in 1-2 Wochen demo-fähig lernen. Versteht die Fundamente gut genug, um bei Bedarf in Architektur-Diskussionen einzusteigen. | Referenzperson im Team für technische Tiefe; kann mit Engineering, Architektur-Teams der:des Kund:in und Produkt auf Augenhöhe diskutieren. Antizipiert klassische technische Einwände (Performance, Sicherheit, Integration) und hat dokumentierte Standardantworten. |
| Discovery und Demo-Erzählung | Startet die Demo ohne Klärungsfragen, geht durch die Feature-Liste in Reihenfolge. Demo dauert 45 Min., dabei 80 % der Zeit Monolog. Keine konkreten Vorher-Nachher-Szenarien. | Stellt 5-8 Discovery-Fragen vor der Demo, passt die Reihenfolge der gezeigten Features an die genannten Schmerzpunkte an. Demo dauert 20-30 Min., lässt die:den Prospect 30-40 % der Zeit sprechen. | Führt die Discovery wie eine Untersuchung: 10-15 strukturierte Fragen, identifiziert 2-3 Stakeholder mit unterschiedlichen Prioritäten. Demo wird zur Erzählung: 3-4 Features in einer logischen Reihenfolge, jede an einen konkreten Schmerz der:des Prospects gekoppelt, mit aktivem Pausieren für Fragen. |
| POC- und Demo-Strategie | POC startet ohne klare Erfolgskriterien, zieht sich über 8-12 Wochen, mit wechselnden Stakeholdern. Verlängert POCs aus Hoffnung statt aus Disziplin. Demo-Setup ist generisch und nicht prospekt-spezifisch. | Definiert Erfolgskriterien vor dem POC-Start (typisch 3-5 messbare Punkte), hält das Zeitfenster auf 3-4 Wochen, eskaliert bei diffusen Sponsor:innen. Demo-Setup wird vor jeder Demo angepasst (Branche, Use-Case, Stakeholder). | Pilotiert das POC-Portfolio wie ein eigenes Pipeline-Modell: kennt eigene Win-Rate pro POC-Phase, disqualifiziert souverän bei diffusen Kriterien, dokumentiert POC-Templates pro Branchen-Use-Case. Demo-Setups sind hochgradig prospekt-spezifisch und versionsgesteuert. |
| Glaubwürdigkeit und Ehrlichkeit | Antwortet auf technische Unbekannte mit Bluff oder generischer Beruhigung. Versucht, jede Frage in Echtzeit zu beantworten, auch wenn die Information nicht verfügbar ist. | Sagt klar, wenn sie:er etwas nicht weiß; klärt mit Engineering oder Produkt und meldet sich nach. Trennt klar zwischen Was wir heute können und Was wir planen. | Wird im Team und bei Kund:innen für radikale Ehrlichkeit zitiert. Bringt aktiv Showstopper ein, bevor die:der Prospect sie findet (Wir sind heute schwächer in X, wenn das ein Muss ist, sollten Sie das wissen). Diese Haltung wird zur Win-Rate-Wirkung im Lower-Funnel. |
| Cross-funktionale Zusammenarbeit | Eskaliert Feature-Requests ohne Business-Begründung an Produkt, beschwert sich öffentlich über Engineering-Velocity, übergibt POC-Ergebnisse nicht sauber an Customer Success. | Strukturiert Feature-Requests mit Business-Daten an Produkt, hält saubere Übergaben an Engineering bei Eskalationen, dokumentiert POC-Ergebnisse für Customer Success. | Wird in Engineering und Produkt als verlässlicher Partner zitiert; bringt strukturierte Markt-Signale, ohne als reine Sales-Stimme zu lobbyieren. Ist die Brücke zwischen Sales und Engineering und reduziert Reibung in beide Richtungen. |
| Coachbarkeit und AE-Partnerschaft | Hört AE-Feedback und kehrt zum gleichen Verhalten zurück. Arbeitet im Silo, sieht AEs als Verteiler der eigenen Demos. Verteidigt jede technische Entscheidung gegenüber AEs als Engineering-Realität. | Integriert AE-Feedback innerhalb weniger Wochen. Hält wöchentliche Pipeline-Reviews mit den 2-4 zugewiesenen AEs, dokumentiert gemeinsame Erkenntnisse aus verlorenen Deals. | Fordert AE-Feedback aktiv ein (beobachtete Demos, debriefte Deals), strukturiert die AE-Partnerschaft als dokumentiertes Ritual (Discovery-Briefing vor Demo, Debrief nach Demo, Pipeline-Review wöchentlich). Wirkt als technischer Coach für Junior-AEs. |
30/60/90-Tage-Plan
Bis Tag 30
- Vollständiges Produkt-Onboarding und interne Demo-Zertifizierung bestanden; eigenständige Standard-Demo möglich
- Shadowing von 5-8 Calls (Discovery, Demo, POC-Kickoff, technische Vertiefung) mit verschiedenen AEs
- Kartierung der 2-4 zugewiesenen Account Executives mit dokumentierten Erwartungen pro AE-Partnerschaft
- Erste 2-3 eigenständige Discovery-Calls und 1-2 Standard-Demos geführt, mit Post-Call-Begleitung durch die:den Manager:in
Bis Tag 60
- Erste eigenständige Custom-Demo für eine:n Mid-Market-Prospect, ohne Begleitung der:des Manager:in
- Erster eigenständig betreuter POC mit dokumentierten Erfolgskriterien und sauberer Übergabe an Customer Success
- Wöchentliches Pipeline-Review mit den zugewiesenen AEs gehalten, erste strukturierte technische Qualifizierungs-Disqualifikation dokumentiert
- Erste Feature-Request-Übergabe an Produkt mit strukturierter Business-Begründung
Bis Tag 90
- Mindestens 2 vollständige POCs erfolgreich begleitet (Start, Erfolgskriterien, Closing) mit dokumentierter Win-Rate-Wirkung
- Stabile operative Kadenz: Discovery-Briefings vor Demos, Demo-Debriefs, wöchentliche AE-Reviews konsequent gehalten
- Erste informelle Coaching-Beziehung mit einer:einem Junior-AE oder neuer:m Kolleg:in im Team
- Formales Review mit der:dem Manager:in: Ramp validiert, Verbesserungsplan auf 1-2 Achsen für das nächste Quartal