Sales Engineer

The ability to diagnose a lost deal beyond the purely technical question: stakeholder misalignment, a missing economic sponsor, bad timing, a procurement blockage. Bonus: the candidate identifies an early signal they would read differently today (such as I asked too little about the build-vs-buy discussions in discovery). Candidates who blame everything on price or a competitor feature show weak discovery maturity.

The ability to structure a POC: clear success criteria before the start, a bounded time window (typically 2-4 weeks, not 3 months), stakeholder mapping (technical sponsor, economic sponsor, users). Concrete on duration and stages. Candidates who describe a POC without success criteria actually ran an extended demo, not a real POC.

Maturity in the sales-engineering-AE partnership: the ability to disqualify or re-scope a deal without damaging the relationship with the AE. A concrete example with deal size, the reasoning and the AE's reaction. Candidates who have never disqualified are either too defensive (afraid to push back) or had no responsibility for technical qualification.

A clean trade-off: diagnose the real need (is the adaptation truly necessary or does the AE just want to save the deal?), offer options (a workaround in the demo, an explicit note in the board meeting, an honest timeline for future delivery), involve engineering or product where needed. Answers along the lines of I'll quickly cobble it together or I'll block the demo are both red flags.

Composure in not knowing: an explicit acknowledgment (That's a good question, I'm not sure, I'll clarify it by tomorrow and get back to you), a concrete follow-up with a deadline, no bluffing. Bonus: the candidate names a real case where this honest handling built trust. Candidates who answer I never make anything up, without a concrete example, are worth weighting carefully.

Prioritization by probability and effort, not by age: POC A and C should have priority (clear criteria, engaged stakeholders); POC B needs clarification or a cut. Answers along the lines of I work the oldest POC are a sunk-cost bias; answers along the lines of I work all three in parallel show a lack of prioritization.

A structured approach: (1) clarify the real need (real-time sync or daily sync?, what concrete volume?), (2) examine workaround options (CSV import with automation, third-party integrations such as Zapier or Workato, a customer-specific solution), (3) escalate to product to check the roadmap with a clear business case, (4) communicate the timeline honestly to the prospect. Candidates who simply make a roadmap commitment in 3 months without talking to product are a red flag.

A demo as a narrative, not a feature tour: an entry through the prospect's pain (Excel chaos, missing visibility, manual handovers), then the targeted features that solve exactly that pain, with concrete before-and-after scenarios. No more than 3-4 features in 10 min. Bonus: the candidate asks 2-3 clarifying questions before starting (which concrete user in the meeting, what pain triggered the meeting, which competitor tools are in play).

A methodical approach: (1) clarifying questions (is it read or write load, what latency requirements, what time profile), (2) an honest statement of what you know vs. do not know, (3) a reference to known reference customers or published benchmarks, (4) a proposal of a performance POC with the real data profile. Answers along the lines of yes, the system handles that easily without a data basis are a red flag; answers along the lines of I don't know, I'll ask engineering and get back to you by tomorrow are mature.

Confident technical vocabulary: REST as resource-oriented with fixed endpoints and HTTP verbs, GraphQL as query-based with one endpoint and flexible data return. Use cases: REST for simple server-to-server integrations, GraphQL for complex frontends with variable requirements. Candidates who cannot get past buzzword level (REST is old, GraphQL is modern) have a credibility deficit with technical prospects.

Familiarity with compliance vocabulary without a lawyer's tone: data residency (EU or not), a data processing agreement, subprocessor lists, technical measures (encryption at rest and in transit, audit logs), organizational measures (an authorization concept, training), the certification status. Bonus: the candidate clearly states what they cannot answer and points to the security or legal contact. Anyone who says yes, we are fully compliant without asking back is a red flag.

A structured learning method: (1) read the roadmap and release notes, (2) hands-on setup in a test environment, (3) play through two or three concrete user scenarios, (4) a clarification session with the product owner or lead engineer, (5) a dry run of the demo with an AE or colleague before the first customer meeting. Candidates who only read the documentation without practicing hands-on are often too theoretical in demos.

Openness: the ability to separate the feedback from a personal judgment. Bonus: the candidate cites a concrete example of changing behavior after uncomfortable AE feedback (such as a discovery-first discipline after an overloaded demo). Candidates who describe having explained the technical necessity to the AE instead of listening are worth weighting carefully.

A partnership posture: a structured handover to product with a business case (deal size, industry, competitive context), no activities behind engineering's back, clear expectation management toward the prospect. Candidates who describe engineering as a brake or product as slow show a teamwork weakness that quickly creates friction in DACH SMB structures.

Sales maturity with a technical conscience: the ability to recommend a scope downgrade or a deferred close when the technical fit is wrong. Concrete: the candidate names the deal size, the account and the long-term impact (such as less churn the following year, no technical escalation case, a clean upsell path). Candidates who have never decided against a short-term close show a transactional bias.