Sales Engineer

How to hire a Sales Engineer for your SMB

Before you write the job posting, settle three framing questions. They decide whether a new hire is the right lever and which profile you actually need.

Question 1: Do you need a Sales Engineer or another Account Executive? The Sales Engineer is a technical reinforcement role, not a closer with their own quota. They support 2-5 AEs with demos, proof-of-concept support and architecture discussions. A rough rule of thumb: from 3-4 Account Executives with complex technical deals (B2B SaaS with API, security, compliance requirements) a Sales Engineer pays off; below that it is usually more sensible to hire another AE with technical affinity. If your AEs run the demos themselves today and only struggle in deep architecture discussions, a Sales Engineer is the right lever.

Question 2: How deep does the technical depth really need to be? A Sales Engineer for an API-driven B2B SaaS product (workflow automation, data integration, developer tooling) needs engineering or implementation experience with concrete code contact. A Sales Engineer for a classic Mittelstand product (an ERP module, industrial control, an industry-specific solution) needs consulting and process-understanding depth more than pure code. The ideal profile and the expected compensation differ strongly. Write the depth level explicitly into the ad; otherwise you attract Solutions Architects from hyperscale SaaS who lack the patience for long discovery cycles in the Mittelstand.

Question 3: What share of POC support do you expect? In the DACH B2B Mittelstand the proof-of-concept often decides the deal: 3-4 weeks with concrete success criteria, stakeholder mapping and a clean handover to Customer Success. A good Sales Engineer at an SMB spends 30-50 % of the time on POCs (not demos). If your sales motion knows almost no POCs (transactional sales, standard software without customizing), you need an extended AE with demo depth more than a real Sales Engineer. Clarify the demos vs. POCs ratio in the ad.

If the three answers converge on a full-time Sales Engineer (and not another AE or a Solutions Architect), use the template below.

Sales Engineer (m/w/d) in B2B SaaS sales

Mission. Technical reinforcement of [X] Account Executives in a B2B SaaS sales team: tailored demos, proof-of-concept support, architecture discussions, compliance and security answers. You report to the [Head of Sales / Head of Pre-Sales / CTO] .

Key responsibilities.

• Prepare and run tailored discovery demos on an average cycle of [X] days and a deal size of [Y] k€.
• Support proof-of-concept phases over 3-4 weeks with clearly defined success criteria, in coordination with engineering, product and Customer Success.
• Answer technical questions in board and architecture meetings (API, integration, scalability, security, GDPR, ISO 27001).
• Hand over the technical requirements to Customer Success in a structured way after closing.
• Weekly pipeline reviews with the [2-5] assigned Account Executives; structured feedback on technical qualification.
• Structured handover of prioritized feature requests to product with a documented business case.

Profile.

• Required : 4 to 8 years of experience, of which at least 2 years in pre-sales, solutions engineering, technical consulting or a comparable technical-commercial role; demonstrated POC responsibility; confident with API concepts (REST, webhooks), authentication (SSO, SAML), database fundamentals.
• Disqualifying : purely commercial prior experience with no demonstrable technical depth, or purely technical prior experience with no sales exposure (such as a Solutions Architect with no pre-sales practice).

What we offer.

• Gross annual compensation: fixed [58-88] k€ + variable [10-20] k€ at OTE (an 80/20 model, tied to team quotas or AE performance). Details of the variable plan are shared in the interview.
• Model: [full-time, hybrid 2-3 days / week on-site, based in [city]] .
• Benefits: [company pension, bike leasing, employee shares, vacation, home-office policy, professional-development budget, hardware budget] .
• Stack: [CRM, demo environment, POC tooling, pipeline intelligence, security documentation, compliance platform] .

Salary band

Base salary, gross annual

25th percentile €58,000

Median €70,000

75th percentile €88,000

Variable at OTE €15,000 – €22,000 80/20 typical in Germany; variable often tied to AE quota

Gross fixed salary per year for a mid-level Sales Engineer (4 to 8 years, of which at least 2 in pre-sales or technical consulting) at a German B2B SaaS SMB. SaaS scale-up profiles in Berlin or Munich trend toward the top of the range (80-95 k€ fixed); classic Mittelstand sales-engineering profiles (industrial software, ERP, cybersecurity) often sit between 58-75 k€. The variable component (typically 80/20 rather than the 70/30 of pure Account Executives) is often tied to Account Executive quotas or to shared team targets. Note: the Sales Engineer title is established in the DACH region; many Mittelstand companies advertise the same role as Pre-Sales Consultant, Solutions Engineer or Technischer Vertrieb.

The most important channel for Sales Engineers at German SaaS and tech SMBs. Active sourcing via Recruiter Lite plus personalized InMails is markedly more effective than pure job posts: good sales-engineering profiles are rarely actively job-hunting. Filter for prior experience in the matching technical area (API-driven SaaS vs. on-premise enterprise vs. embedded hardware) before reaching out. Expect 50-70 % of qualified applications from here when you source actively.

• 02

  Still strong in the classic Mittelstand and in technical B2B industries outside the Berlin startup scene, especially for Sales Engineers in mechanical engineering, industrial automation, ERP, cybersecurity, logistics software. On par with LinkedIn or better in NRW, Bavaria and Baden-Württemberg. Tends to be weaker than LinkedIn for SaaS-native sales-engineering profiles under 35.

• 03

  The largest classic job market with a broad applicant pool. For Sales Engineer roles you get good volume, especially from industry and the Mittelstand, with many profiles moving into the pre-sales role from engineering or service. Slightly less signal than LinkedIn or XING on senior profiles from pure B2B SaaS, but useful when you search nationwide without strong tech branding. Expect heavier filtering in the first screen.

The Sales Engineer role reveals itself across five evaluation stages. The live-demo exercise in stage 4 is the most predictive; it shows whether the candidate combines technical depth with discovery discipline and storytelling. Validation comes from accumulating signals, never from a single stage.

• 01

  Stage 1: CV review

  Look for consistency between the technical background and sales exposure: a good Sales Engineer has either an engineering or consulting background plus 2-4 years of documented pre-sales practice, or 5+ years of AE practice with a clear technical focus (demo ownership, RFP handling, proof-of-concept support). Minimum tenure of 18 months per position; several 12-month stints signal an industry or stack mismatch. The depth of demo and proof-of-concept responsibility counts more than the number of deals supported.

• 02

  Stage 2: Phone screen (30 min)

  Three questions only: (1) Describe the last technical deal where your demo or POC was decisive, (2) Which technical question from a prospect could you most recently not answer, and how did you handle it?, (3) Why a change now? Outcome: go/no-go in a 5-minute debrief. Avoid deep technical gotcha questions at this stage.

• 03

  Stage 3: Structured interview (90 min)

  Work through the 15 questions below, alternating behavioral, situational, case, technical and values. Pay particular attention to the balance between technical precision and discovery discipline: a strong Sales Engineer can explain a complex architecture without tipping into a product monologue. At least 2 interviewers (one from sales, one from engineering), independent scoring before the debrief.

• 04

  Stage 4: Live demo and proof-of-concept exercise (90 min)

  Give the candidate a brief for a fictional prospect one week before the session (industry, use case, 3-4 technical requirements, one hidden showstopper). In the session: 15 min of live discovery with a team member in the prospect role, then 30-min product-focused demo (your own product or a close open-source equivalent), then 30 min of Q&A on the architecture and the POC strategy, then a 15-min debrief. This is the most predictive stage: the quality of the discovery questions before the demo deep-dive and the handling of the hidden showstopper determine the later win-rate impact.

• 05

  Stage 5: References (structured check)

  Call two references: a former Account Executive the candidate worked with, and a former engineering or product colleague. Ask both the same four questions: What is she/he strongest at? Where would you hire someone complementary? Would you want them again tomorrow as a pre-sales partner, why or why not? A concrete example of a technical deal where the candidate made the difference? The fourth question delivers the most signal.

Structured interview questions

Describe the last technical deal you lost even though your product was technically suitable. What happened?

What a strong answer surfaces
The ability to diagnose a lost deal beyond the purely technical question: stakeholder misalignment, a missing economic sponsor, a 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.

Tell me about the most complex technical proof-of-concept you supported. What was the scope, who was involved, what was the main difficulty?

What a strong answer surfaces
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.

Describe a situation where you had to tell an Account Executive that a deal is not technically qualified. Why, and how did you communicate it?

What a strong answer surfaces
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.

An Account Executive asks you 24 hours before a board demo for a special adaptation that the product does not actually cover. How do you react?

What a strong answer surfaces
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.

During a live demo the technical sponsor asks a question whose answer you do not know. How do you handle it?

What a strong answer surfaces
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.

You have three parallel POCs in different phases. POC A (3 weeks old, success criteria clear, technical sponsor engaged), POC B (5 weeks old, success criteria diffuse, shifting sponsor), POC C (1 week old, clear, a very engaged team). How do you prioritize?

What a strong answer surfaces
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 prospect demands a native integration with a system we currently support only via CSV import. The roadmap plan for it: 9 months. The deal is worth 120 k€ per year. How do you proceed?

What a strong answer surfaces
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.

Prepare a 10-minute discovery demo of our product (or a comparable tool) for a fictional prospect: a logistics SMB with 80 employees that currently uses Excel and an in-house build for order tracking. How do you structure it?

What a strong answer surfaces
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).

Architecture: a prospect asks how our product handles 500 concurrent users and 2 million records per day. You do not know the exact numbers of our current setup off the top of your head. How do you answer?

What a strong answer surfaces
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.

Explain to me how a REST API technically differs from a GraphQL API. When would you recommend one to a prospect, and when the other?

What a strong answer surfaces
Confident technical vocabulary: REST as resource-oriented with fixed endpoints and 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.

A prospect from healthcare asks how your product handles the GDPR and a planned ISO 27001 certification. Which questions do you ask back, and how do you structure the answer?

What a strong answer surfaces
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.

You are to learn a new product module that engineering is just shipping. How do you proceed methodically to be demo-ready in 2 weeks?

What a strong answer surfaces
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.

How do you take feedback from an Account Executive when they say your demo was too technical and endangered the deal?

What a strong answer surfaces
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.

How do you work with engineering and product when a prospect requests a feature that is not on the roadmap?

What a strong answer surfaces
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.

Describe a decision where you weighted the long-term technical health of an account higher than a short-term close.

What a strong answer surfaces
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.

How to recognize a great hire

Below bar

On bar

Above bar

Technical depth Stays at buzzword level in the demo (modern, scalable, secure) without precise mechanisms. Stumbles on architecture or API questions, looks for solutions by trial and error with no clear mental model. Masters the current stack and the own product independently. Can learn a new product feature to demo readiness in 1-2 weeks. Understands the fundamentals well enough to step into architecture discussions when needed. A reference person in the team for technical depth; can discuss as an equal with engineering, the customer's architecture teams and product. Anticipates classic technical objections (performance, security, integration) and has documented standard answers.

Discovery and demo narrative

Discovery and demo narrative Starts the demo without clarifying questions, goes through the feature list in order. The demo runs 45 min, 80 % of it a monologue. No concrete before-and-after scenarios. Asks 5-8 discovery questions before the demo, adapts the order of the features shown to the named pain points. The demo runs 20-30 min, lets the prospect speak 30-40 % of the time. Runs discovery like an investigation: 10-15 structured questions, identifies 2-3 stakeholders with different priorities. The demo becomes a narrative: 3-4 features in a logical order, each tied to a concrete prospect pain, with active pausing for questions.

POC and demo strategy

POC and demo strategy The POC starts without clear success criteria, drags over 8-12 weeks, with shifting stakeholders. Extends POCs out of hope rather than discipline. The demo setup is generic and not prospect-specific. Defines success criteria before the POC start (typically 3-5 measurable points), holds the time window to 3-4 weeks, escalates on diffuse sponsors. The demo setup is adapted before each demo (industry, use case, stakeholders). Runs the POC portfolio like an own pipeline model: knows the own win rate per POC phase, disqualifies confidently on diffuse criteria, documents POC templates per industry use case. Demo setups are highly prospect-specific and version-controlled.

Credibility and honesty

Credibility and honesty Answers technical unknowns with a bluff or a generic reassurance. Tries to answer every question in real time, even when the information is not available. Says clearly when they do not know something; clarifies with engineering or product and follows up. Separates clearly between what we can do today and what we plan. Quoted in the team and with customers for radical honesty. Actively brings up showstoppers before the prospect finds them (We are weaker in X today, if that is a must you should know). This posture becomes a win-rate impact in the lower funnel.

Cross-functional collaboration

Cross-functional collaboration Escalates feature requests without a business case to product, complains publicly about engineering velocity, does not hand over POC results cleanly to Customer Success. Structures feature requests with business data to product, keeps clean handovers to engineering on escalations, documents POC results for Customer Success. Quoted in engineering and product as a reliable partner; brings structured market signals without lobbying as a pure sales voice. Is the bridge between sales and engineering and reduces friction in both directions.

Coachability and AE partnership

Coachability and AE partnership Hears AE feedback and returns to the same behavior. Works in a silo, sees AEs as distributors of their own demos. Defends every technical decision to AEs as engineering reality. Integrates AE feedback within a few weeks. Holds weekly pipeline reviews with the 2-4 assigned AEs, documents shared insights from lost deals. Actively asks for AE feedback (observed demos, debriefed deals), structures the AE partnership as a documented ritual (a discovery briefing before the demo, a debrief after the demo, a weekly pipeline review). Acts as a technical coach for junior AEs.

30 / 60 / 90 day success plan

By day 30

• Full product onboarding and internal demo certification passed; able to run a standard demo independently
• Shadowing of 5-8 calls (discovery, demo, POC kickoff, technical deep-dive) with different AEs
• Map of the 2-4 assigned Account Executives with documented expectations per AE partnership
• First 2-3 independent discovery calls and 1-2 standard demos run, with post-call coaching from the manager

By day 60

• First independent custom demo for a mid-market prospect, without the manager's support
• First independently owned POC with documented success criteria and a clean handover to Customer Success
• Weekly pipeline review with the assigned AEs held, first structured technical qualification disqualification documented
• First feature-request handover to product with a structured business case

By day 90

• At least 2 full POCs supported successfully (start, success criteria, closing) with documented win-rate impact
• A stable operating cadence: discovery briefings before demos, demo debriefs, weekly AE reviews held consistently
• A first informal coaching relationship with a junior AE or a new colleague in the team
• A formal review with the manager: ramp validated, an improvement plan on 1-2 priority areas for the next quarter

Common hiring mistakes for this role

• 01

  Blending Sales Engineer and Account Executive in one ad

  Both roles need sales exposure, but the Sales Engineer carries no individual quota; they support 2-5 Account Executives with technical depth, POC support and tailored demos. Blending both profiles in one ad leads to two classic outcomes: either you pay an AE salary for a Sales Engineer who then sees too little closing responsibility and leaves after 9 months, or you hire an AE as a Sales Engineer and notice in month 3 that they lack the technical depth for architecture discussions. Describe the quota structure and the expected technical depth level explicitly.

• 02

  Hiring on pure technical depth without discovery maturity

  A Solutions Architect from a large corporation often has impressive technical depth but little practice in the discovery-first approach. In Mittelstand deals this leads to architecture lectures instead of pain-point-focused demos and lowers the win rate. Assess discovery discipline in the interview (stage 4, the live-demo exercise) just as hard as technical depth. A good Sales Engineer at an SMB has 70 % of the depth of a Solutions Architect and 200 % of the discovery maturity.

• 03

  Not testing the AE partnership in the interview

  Sales Engineers work 60-80 % with Account Executives, not directly with customers. Anyone who cannot give concrete examples of an AE partnership in the interview (joint pipeline reviews, mutual feedback, shared disqualification decisions) will create friction in the team. Ask at least one values question explicitly about the AE relationship; let an AE from the team speak with the candidate.

• 04

  Confusing POC experience with demo experience

  Many profiles with pre-sales experience in transactional SaaS environments have run hundreds of demos but rarely supported a real proof-of-concept with success criteria and engineering involvement. In the DACH Mittelstand and in technical B2B industries the POC is often the central win lever. Ask concretely about the number and depth of POCs supported (not demos) and about the method for defining the success criteria.

• 05

  Underestimating the technical compliance and security share

  A Sales Engineer in the German B2B Mittelstand spends 15-25 % of the time on security and compliance questions: GDPR data processing, ISO 27001, BSI Grundschutz, industry-specific requirements (KRITIS, BAFIN, the Medical Device Regulation). Anyone from pure hyperscale SaaS often has no depth in German compliance patterns. Assess this in the interview (technical question 11) and calibrate the requirements to your industry.

Frequently asked questions

• What does a Sales Engineer earn at an SMB in Germany?

  The reference range for a mid-level Sales Engineer (4 to 8 years, of which at least 2 in pre-sales or technical consulting) at a German B2B SaaS SMB is 58-88 k€ fixed salary per year (median around 70 k€), plus a variable component of 10-20 k€ at OTE (a typical 80/20 model). SaaS profiles in Berlin or Munich trend toward the top; classic Mittelstand and industrial-software profiles usually sit in the lower third. For a solid mid at 100 % OTE, expect 70-105 k€ total target compensation.

• What is the difference between a Sales Engineer and an Account Executive?

  The Account Executive carries an individual quota and is the primary commercial contact. The Sales Engineer is the technical reinforcement: they support 2-5 AEs with tailored demos, proof-of-concept support, architecture discussions and compliance answers. Sales Engineers usually have no individual quota; the variable often ties to team targets or to AE quotas. Blending the two roles in one ad is one of the most common hiring mistakes in DACH B2B SaaS.

• What is the difference between a Sales Engineer and a Solutions Architect?

  The Sales Engineer works in pre-sales: demo, POC, technical qualification, architecture discussion before closing. The Solutions Architect works in post-sales and in deep implementation projects: detailed architecture designs, migration, customizing, sometimes code. At an SMB the roles are often fluid, but the emphases differ: a Sales Engineer needs more discovery maturity and demo storytelling, a Solutions Architect more technical depth and implementation experience. Anyone who hires an SE should communicate the 70/30 sales/engineering weighting honestly.

• How long does it take to hire a Sales Engineer in Germany?

  Expect 50-80 days between posting and signed contract for a mid-level position at a German B2B SaaS SMB. Slightly longer than for pure Account Executives, because the profile is rarer and the live-demo exercise (stage 4) needs an additional time window. In the classic Mittelstand the timeline tends to lengthen, because decision processes run through more stakeholders and technical references carry more weight. Cutting below 50 days usually sacrifices the live-demo exercise and markedly reduces hiring quality.

• What technical depth should a Sales Engineer bring?

  A good Sales Engineer in the DACH Mittelstand must command API concepts (REST, GraphQL, webhooks), database fundamentals, authentication (SSO, SAML, OAuth), security mechanisms (encryption at rest and in transit, audit logs) and compliance vocabulary (GDPR, ISO 27001, industry-specific requirements) at a level that holds its own in architecture discussions with the prospect's technical sponsor. They do not need to write production code themselves, but scripting level (Python, JavaScript, SQL) is a clear advantage. Hands-on experience in a prior engineering, consulting or implementation role is the strongest signal.

• What legal requirements apply to Sales Engineer job postings in Germany?

  Three central requirements: (1) a gender-neutral job title with (m/w/d) or colon spelling (§ 11 AGG), (2) the obligation of pay transparency in the ad or before the first interview (EU Pay Transparency Directive 2023/970, implementation by 7 June 2026), (3) transparency about the use of AI tools for pre-selection and guaranteed human oversight (EU AI Act, from 2 August 2026). In the interview itself, questions about age, origin, marital status or religion are not permitted under § 7 AGG. In tariff-bound industries (e.g. mechanical engineering, insurance) the relevant collective agreements additionally apply.

Legal disclosures for this market

Gender-neutral job posting (m/w/d)

Job postings and contract documents must be worded gender-neutrally (§ 11 AGG). Concretely: Sales Engineer (m/w/d) or Sales Engineer:in are permitted; Sales Engineer (m/w) is not enough. Violations can trigger compensation claims of up to three months' salary.

EU Pay Transparency Directive from 2026

EU Directive 2023/970 on pay transparency enters national law on 7 June 2026. Obligation: the salary range (fixed and target variable) must be communicated at the latest before the first interview, ideally directly in the job posting. Asking about the candidate's current or previous salary is prohibited from that date.

No discriminatory questions in the interview (§ 7 AGG)

Questions about age, origin, marital status, pregnancy, religion, sexual orientation or disability are not permitted in the interview (§ 7 in conjunction with § 1 AGG). Structure the interview exclusively around observable competencies and professional experience. Violations can trigger compensation and damages claims.

If you use an AI tool to score or pre-select applications, the EU AI Act (applicable from 2 August 2026) classifies this use case as high-risk. Obligations: transparency toward applicants, logging of decisions, effective human oversight. A fully automated rejection without human oversight triggers employer liability.

Check the collective agreement (Tarifvertrag)

In the classic SaaS and tech SMB, sales-engineering roles are usually not tariff-bound, so free agreement is possible. In certain industries (mechanical engineering, industrial automation, banking, insurance), however, a generally binding collective agreement may set minimum salary, special payments, working time and notice periods bindingly. Check the applicable sector agreement before fixing compensation.

Run this hire in Join Source, screen, and interview in one place.

In which language should we get back to you?

We'll get back to you within one business day.

Couldn't send.

Please try again in a moment.