This page is for anyone interviewing for a solutions engineer or presales role at a software or AI company. Expect a few questions on why you want a job that sits between engineering and sales, stories about demos, lost evaluations and working with account executives, and what-would-you-do scenarios like a demo breaking live. You will also meet technical checks: running discovery, scoping a proof of concept, drawing an integration on a whiteboard and answering security questions honestly. Each question shows what the interviewer is listening for, a shape for your answer and a sample you could say out loud. Swap in your own stories and your target company's product.
Search all questions by round, difficulty and level, or save the ones you want to practise.
Path: the two or three steps that took you from a technical start to customer-facing work.
The pull: a concrete moment where explaining or shaping a solution for someone felt better than building alone.
Fit: why this role uses both skills better than either pure path.
"I started as a backend developer on an internal billing team. The part I liked most turned out to be the meetings where I sat with the finance people, figured out what they were actually stuck on, and sketched a fix on the spot. Later I got pulled into a couple of customer calls because I knew the integration side, and I noticed I was more energised after those calls than after a week of tickets. I still like being hands-on, so pure sales wouldn't suit me, but I want my technical work to end in someone saying yes, this solves our problem. Solutions engineering is the job where I get to go deep on the tech and then use it to help a buyer make a real decision."
Saying you want to escape coding, or that you like sales because of the commission, with nothing about helping customers solve problems.
Owns: technical discovery, the demo, objections, the proof of concept and the technical win.
Shares: deal strategy and the relationship with the account executive.
Hands off: implementation and ongoing success to the teams built for them.
"I'd say the solutions engineer owns the technical side of the buying decision. The account executive owns the deal overall, the commercial terms and the relationship with the economic buyer. I own understanding the customer's environment, showing them how our product solves their specific problem, answering the hard technical questions, running any proof of concept and getting the technical team to say this will work for us. That's what people call the technical win. Where it stops is delivery. Once they sign, implementation and customer success take over, and my job is a clean handover so nothing I learned gets lost. I might stay close on a big account, but I shouldn't quietly turn into their support engineer."
Describing the job as just doing demos, or as doing the account executive's selling for them.
What it does: the problem it solves, in one or two plain sentences.
Who buys: the economic buyer, the technical evaluator and the daily user.
Learning plan: product depth, common integrations and the objections the team hears most.
"From your site, your docs and a trial account, I understand the product helps operations teams automate approval workflows that live in email and spreadsheets today. The person signing is usually a head of operations or finance, but the person who can kill the deal is the IT or security lead who has to connect it to single sign-on and the ERP. In my first month I'd want to go deep on three things. The integrations customers ask about most, so I can whiteboard them without notes. The top objections the team hears and how the best engineers here answer them. And I'd like to shadow a few discovery calls and demos before I run my own, so I learn the story the way customers hear it."
Having never opened the product or its documentation, or describing it only in marketing phrases.
Situation: where the deal stood and what was blocking it.
What you changed: the customer's data, their workflow or their words in the demo.
Result: what the buyer did next and what you took away.
"At my last company we were stuck with a logistics prospect. They'd seen our standard demo twice and kept saying it looked nice but wasn't for them. On a discovery call I asked their dispatch lead to walk me through a bad Monday morning, and it turned out their real pain was reassigning drivers when a truck broke down. So I rebuilt the demo around that one story. I loaded sample data shaped like theirs, used their depot names, and started with the breakdown alert instead of the dashboard. I showed three screens, not fifteen. Halfway through, their operations head asked if we could run it on real data the following week. That became a proof of concept and they signed a quarter later. The lesson I kept is to open a demo with the customer's worst day, not our best feature."
Describing a demo where you showed every feature and the deal moved for reasons you can't explain.
The room: who was there and why they doubted you.
Your approach: less pitch, more architecture, limits stated plainly.
Turning point: the moment the room changed, and the result.
"I once presented to a platform team who'd built something similar in-house and clearly thought we were there to replace them. I dropped the slide deck after the first minute and said I'd rather show you how it works under the hood and where it's weak, and you tell me if it fits. I drew the architecture on the whiteboard, showed the API and the logs, and when they asked about a limit on batch sizes I just said yes, that's a real limit, here's how customers work around it. That honesty changed the tone. Their lead started asking how they could keep their own tool for one part and use ours for the rest. We ended up with a smaller first deal than planned, but they became an easy reference later."
Talking about winning the argument or out-talking the engineers, rather than earning their trust.
In the moment: name it calmly, don't debug live for long.
Keep going: a backup path, recording or a different workflow.
After: find the cause, tell the customer plainly, prevent a repeat.
"First, I'd say it out loud and stay calm, something like, that's not what should happen, let me take a quick look. I'd give it maybe thirty seconds. If it's something obvious like an expired session, I'd fix it and carry on. If not, I wouldn't debug in front of their leadership. I'd switch to my backup, which is usually a second demo environment or a short recording of the same workflow, and keep the story going, because the story is what they came for. After the call I'd find out the cause with our engineers and send the prospect a short note saying what happened and whether it could affect them in production. Then I'd fix my own prep, because a demo environment that breaks is usually a setup problem I could have caught with a dry run that morning."
Pretending nothing happened, blaming the engineering team in front of the prospect, or spending ten minutes debugging live.
Start with the pain: open with their problem in their own words.
Show the outcome first: the result, then how you got there.
Cut hard: three or four workflows tied to their criteria, nothing else.
"I start from my discovery notes and pick the two or three problems that matter most to this buyer. I open the demo by saying them back in the prospect's own words, so they know I listened. Then I show the end result first, like the finished report or the alert their manager would get, and after that I show how it's set up. People care more once they've seen the payoff. I use data that looks like theirs, their terms, and their team's roles, even if it's just renamed sample data. And I cut everything that doesn't map to their criteria, even features I love. I leave time for questions in the middle, not just the end, and I finish by asking whether what they saw would solve the problem they described, which tells me where we really stand."
Showing every feature in menu order, or running the same demo for every prospect regardless of what discovery found.
The deal: what was being evaluated and against whom.
Why you lost: the real reason, including your part.
What changed: a habit you now use because of it.
"We lost a data platform evaluation to a competitor, and for a while I told myself it was a feature gap. When I got feedback from the prospect, the real story was different. Their data engineering lead had never been in our meetings. I'd been demoing to a manager who liked us, while the engineer who had to run the thing each day was quietly testing the other product and hit no blockers. By the time we met him, he'd already decided. What I'd do differently is map the evaluation team in the first week and ask directly who will use this every day and who can veto it. Now I won't start a trial until I've spoken to the hands-on evaluator at least once, and I ask them what a failed test would look like."
Blaming the whole loss on price, the product or the account executive, with nothing you would change yourself.
The gap: what you didn't know and how soon the call was.
How you learned: docs, a hands-on test, a colleague who knew it.
On the call: how you used it and where you were honest about limits.
"A prospect told us two days before a call that their whole stack ran on a message queue I'd only read about. I spent the first evening on the official docs to understand the basic ideas, topics, consumers and how delivery and retries work. The next morning I ran it locally and wired up a tiny test that pushed events from it into our product's API, so I'd at least seen it work once. I also found a colleague on another team who'd used it in production and asked what usually goes wrong. On the call I explained how we'd connect, and when their architect asked a deep tuning question I said I didn't know that part yet and would come back after checking with our engineers. I sent the answer the next day, and they told me later that the honesty helped."
Saying you bluffed through the call, or that you simply avoided the topic until someone else could handle it.
Business problem: what hurts, for whom, and what it costs them today.
Current setup: systems, data, integrations, security and who runs it.
Decision: criteria, evaluators, timeline and what else they're considering.
"I split it into three parts. First, the problem. I ask what's not working today, who feels it most, and what happens if they do nothing for another year. I try to get a real example rather than a general complaint. Second, their environment. What systems are involved, where the data lives, how people log in, what security rules apply, and who would own our product day to day. Third, the decision. What would make them say this works, who's involved in the evaluation, and what else they're looking at. I talk less than they do and repeat back what I heard at the end, so they can correct me. Before I build a demo, I need at least one concrete workflow to show and the two or three criteria they'll judge it on."
Treating discovery as a checklist of yes-or-no questions, or spending the call pitching instead of listening.
Baseline: what the problem costs today, in time, errors or lost revenue, from their numbers.
Change: what realistically improves, using cautious assumptions they agree.
Compare: total cost including setup and people, and when it breaks even.
"I'd build it with them, not for them, because a finance head trusts their own numbers more than mine. First, the baseline. From discovery I'd find out how many people do the manual work today, how many hours a week it takes, and what errors or delays cost them. Then the change. I'd use cautious assumptions, like saving a third of that time rather than all of it, and I'd ask them to agree or adjust each one. I'd include the full cost on our side, the licence plus setup time, training and any integration work, because leaving those out kills credibility. Then I'd show roughly when it pays back, with a best and worst case. I'd keep it to one page and label every assumption, so they can defend it in their own budget meeting."
Using a generic calculator with inflated assumptions the customer never agreed to, or ignoring setup and people costs.
Setup: the goal, the criteria and the timeline you agreed.
Warning sign: the specific thing that told you it was drifting.
Recovery: the reset conversation and what happened after.
"We had a three-week trial with a retailer to prove our product could sync their product catalogue within an hour of changes. By the end of week one, their team hadn't given us access to the test environment, and my check-in notes kept saying waiting on IT. I realised that at that pace we'd spend the last week rushing and the result would look weak. So I asked the account executive to set up a short call with our champion and their IT lead together. I showed the timeline, what was blocked, and asked whether we should pause the clock or cut the scope. They chose to extend by a week and IT gave us access two days later. We hit the criteria. Since then I build a weekly status note into every trial so a stall is visible on day three, not day fifteen."
Saying the trial failed because the customer was slow, without showing that you noticed early or tried to fix it.
Understand: why they added them, and who asked.
Refer back: the written criteria both sides signed off.
Trade-off: swap, extend or park for after purchase, agreed in writing.
"First I'd find out where the new criteria came from, because it tells me a lot. If a new stakeholder has joined, that's useful, and I want to meet them. Then I'd go back to the success plan we both agreed and say, these are the three things we said would decide this, and we're on track for them. The new asks are fair, so let's decide together. Either one of them replaces an existing criterion, or we extend the timeline, or we agree they're for the implementation phase after purchase. I'd also check with the account executive, because constant new criteria can mean they're not ready to buy or they're using us to benchmark another vendor. Whatever we agree, I'd write it down and get their sign-off again, so the finish line doesn't keep moving."
Quietly accepting every new request, or flatly refusing without understanding why the customer is asking.
Why it matters: a trial costs real engineering time on both sides.
Ask for a trade: criteria, decision process and a meeting with the decision maker.
Alternatives: a guided demo, sandbox or reference call if they won't commit.
"I'd be friendly but clear that a proof of concept is a real investment for both of us. I'd say something like, we're happy to do a trial, and to make it worth your team's time we'd like to agree what success looks like and what happens if we hit it. Then I'd ask for a few things in return: written success criteria, who signs off on the result, a rough timeline for the decision, and a short meeting with the person who'll approve the purchase. If they won't share any of that, I'd offer something lighter, like a guided session in a sandbox, a deeper technical workshop, or a call with a similar customer. I'd agree the approach with the account executive first, so we're asking for the same things."
Agreeing to a long unscoped trial just to keep the prospect happy, or refusing outright without offering another path.
Criteria: three to five measurable tests, agreed in writing.
Scope and time: the smallest setup that proves them, with a fixed end date.
People and next step: owners on both sides and what happens if it passes.
"I treat a proof of concept like a small project with a decision at the end. Before anything starts, I agree three to five success criteria with the customer that are specific enough to test, like syncing changes from their CRM within a set number of minutes, or a report their analyst can build without help. I keep the scope to the smallest setup that proves those, usually one team and one use case, and I fix an end date, often two to four weeks. I name owners on both sides and book check-ins weekly. And I get agreement up front on what happens if we pass, for example a commercial conversation the following week. Without that last part, a trial can end with everyone saying it went great and nothing happening."
Describing a proof of concept as giving the customer access and waiting to see what they think.
The disagreement: what each of you wanted and why.
How you raised it: in private, with facts from the account.
Outcome: what you agreed and how the relationship held up.
"An account executive I worked with wanted to skip discovery and go straight to a full demo for a large prospect, because the quarter was ending and he wanted momentum. I thought that was risky, because we didn't know which of their three business units was buying or what systems they used. I didn't argue on the call. Afterwards I showed him my notes and said I think we're about to demo the wrong product to the wrong people. I offered a middle path: a forty-five minute call where I'd ask discovery questions for the first half and show one relevant workflow in the second. He agreed. That call surfaced that their real need was in the finance unit, which changed the whole demo. We're still happy to work together because I never made him look bad in front of the customer."
Describing an argument in front of the customer, or simply doing whatever sales wanted without raising the risk.
Pattern: how often it came up and in what kind of deals.
Evidence: deal names, stage, lost or stalled revenue in plain terms, customer quotes.
Result: what product did, or why they said no and how you handled that.
"In about a third of my enterprise deals one year, security teams asked whether we supported automatic user provisioning, and we didn't. Each time we lost a week while they decided whether manual user management was acceptable, and twice it pushed a deal out of the quarter. Instead of posting another request, I collected the list of deals, what stage they were at and the exact words security teams used, and asked the other solutions engineers to add theirs. I took that to the product manager with a one-page summary. It went onto the roadmap for the next half-year. In the meantime I wrote a short answer for the security questionnaire explaining our workaround, so the team stopped reinventing it every deal."
Describing product feedback as forwarding every customer request, or complaining that product never listens.
On the call: soften or clarify without contradicting harshly.
Right after: a private conversation with the account executive.
Fix the record: get the customer an accurate written answer before they rely on it.
"I wouldn't let it stand, but I also wouldn't correct him bluntly in front of the prospect. On the call I'd step in with something like, just to be precise, that's an area we're looking at, and I want to confirm the timing with our product team before you plan around it. Right after, I'd talk to him privately and say I don't think that's on the roadmap, and if they buy based on it we'll have an angry customer and a hard renewal. Then I'd check with product to be sure I'm right. If I am, we'd send the prospect a clear written follow-up with what exists today, any workaround, and what we can honestly say about the future. It might slow the deal, but a promise we can't keep costs far more later."
Staying silent to protect the deal, or openly contradicting the account executive in a way that embarrasses them in front of the customer.
Criteria: deal size, stage and whether a technical person is truly needed.
Alternatives: a colleague, a recording, prep for the account executive to run it, a new slot.
Communicate: tell all three early, with the reason.
"I'd look at each call and ask two things: how important is this deal, and is it a call where the technical person changes the outcome? A late-stage technical deep dive with the prospect's architects needs me. A first intro call with a manager often doesn't, and I could prep the account executive with a short demo flow and the likely questions. For the third, I'd see if another solutions engineer can cover or if the customer can move by a day. Then I'd tell all three account executives the same day what I'm doing and why, rather than letting them find out on Monday. If this clash happens every week, I'd raise it with my manager, because it's a sign the coverage model needs changing, not that I should work harder."
Going wherever the loudest or most senior account executive pushes, or not telling anyone until the day.
Definition: the technical evaluators agree the product meets their requirements.
Evidence: criteria met, stated in writing or clearly by the evaluators, open risks closed.
Hand-off: tell the account executive and help with the remaining commercial steps.
"To me, the technical win is when the people who evaluate the product technically agree it meets their requirements and they'd recommend it. The key word is agree. A great demo or a friendly champion isn't the same thing. I know I have it when we've met the success criteria we set together, the evaluators confirm that in writing or say it clearly in a wrap-up meeting, and there are no open technical blockers like an unanswered security issue. I'd ask them directly, is there anything technical that would stop you recommending us? Once I have it, I tell the account executive exactly what was confirmed and by whom, and I stay available for procurement or legal questions, because deals can still stall there even after the technical side is settled."
Saying you know you've won because the demo went well, without any confirmation from the evaluators.
Be honest: say what you do know and what you'll confirm.
Capture: write down the exact question so nothing is lost.
Close the loop: a written answer from the security team, with a date.
"I'd tell them what I'm confident about, and be clear about where my knowledge stops. Something like, I can walk you through what's in our published security overview, but key management is exactly the kind of detail I want our security team to give you in writing, not me paraphrasing it. Then I'd write the question down word for word, ask if there's anything else on their list so I can get everything in one go, and promise an answer by a specific day. After the call I'd go to our security team or the documented security pack, get the written answer, and send it on time. Security people remember who guessed. A slightly slower but exact answer builds far more trust than a fast one that later turns out to be wrong."
Guessing or giving a confident answer you later have to take back, on a security topic of all things.
Reuse: start from the answer library and standard security reports.
Route: send what's new to security, legal or engineering with a clear deadline.
Review and track: one owner, consistent answers, and log new answers for next time.
"First I'd check what we already have. Most teams keep a library of approved answers, and many buyers will accept standard evidence like a SOC 2 report or an ISO 27001 certificate, if we have them, in place of dozens of individual questions. So I'd ask the prospect whether our security pack can cover some sections. Then I'd work through the rest, answer what's already approved, and send anything new to the right person, security, legal or engineering, with a clear deadline well before theirs. I'd never write a guess on a security question, because these answers can end up in the contract. Before it goes out, one person reviews the whole thing for consistency. And any new answers go back into the library so the next questionnaire is faster."
Guessing on security answers to hit the deadline, or treating the questionnaire as paperwork rather than part of the sale.
Understand the weight: how much that area really matters against everything else.
Shape criteria: make sure the test covers the whole job, not one feature.
Stay honest: concede the strength, show where you're better, never run them down.
"I'd start by finding out how much that area really matters. Sometimes it's the thing a champion noticed in a demo, not the thing that decides success in a year. I'd ask them to rank their criteria and describe a normal week using the tool. If the evaluation is only about the competitor's strong point, I'd push gently to include the rest of the job, like integration effort, admin time and security, where I think we're stronger. I'd never run the competitor down. I'd say plainly, yes, they're strong there, here's how our customers handle that need, and here's where we're clearly better for you. And if the gap truly matters most to them, I'd tell the account executive early. Sometimes the right move is to lose quickly rather than slowly."
Attacking the competitor, or pretending the gap doesn't exist when the prospect can see it in the trial.
Clarify: is it a law, a contract, an internal policy or a preference, and for which data?
Options: data region choice, encryption, private connectivity, minimising the data sent, other deployment models if offered.
Proof: security documentation and a meeting with their security or legal team.
"First I'd ask what's behind it, because that objection means different things. It might be a data protection law, such as GDPR in Europe or similar rules elsewhere, a clause in a client contract, an internal policy, or just a worry. I'd also ask which data it covers, because often only some fields are sensitive. Then I'd walk through what's actually possible with our product. That might be choosing the region where data is stored, encryption in transit and at rest, private network connections, or only sending the fields we need and keeping identifiers on their side. If we offer a dedicated or self-hosted option, I'd mention it, but I'd never invent one. Then I'd offer our security documentation and a call with our security team, because the architect usually needs something they can show their own compliance people."
Arguing that the cloud is safe anyway, or promising an on-premises version the company doesn't actually sell.
Be honest: these models can produce wrong answers; say so.
Mitigations: grounding in their own data, showing sources, human review, testing on their cases.
Data use: quote the written policy and contract terms, and offer the documents.
"I'd start by being honest: AI models can produce confident answers that are wrong, and no vendor can promise that never happens. Then I'd explain what we do to reduce it. For example, grounding answers in the customer's own documents and showing the sources, so a person can check them, limiting the feature to tasks where it's been tested, and keeping a human approval step for anything important. I'd suggest we test it on a set of their real questions during the evaluation, so they can judge accuracy themselves. On training, I wouldn't answer from memory or give a vague reassurance. I'd point to our written data policy and the relevant contract terms, and if their legal team needs more, I'd bring in our security or legal team. That question deserves an exact answer."
Claiming the AI never makes mistakes, or saying 'we don't train on your data' without checking the actual policy and contract.
Identity: SSO through SAML or OpenID Connect, user provisioning through SCIM.
Operational data: API and webhooks with the CRM, direction and frequency of each flow.
Analytics: batch export or a connector into the warehouse, plus how each connection is authenticated.
"I'd draw our product in the middle and the three systems around it. On the left, their identity provider. Users sign in through single sign-on, using SAML or OpenID Connect, so their IT team controls access and passwords stay with them. If they want accounts created and removed automatically, that's usually SCIM provisioning. At the top, the CRM. I'd draw arrows in both directions and label them. Maybe new deals flow to us through a webhook or a scheduled sync, and status updates flow back through the CRM's API, authenticated with OAuth or a service account. On the right, the warehouse. Here it's usually a scheduled batch export or a connector, because analytics rarely needs real time. Then I'd ask them to correct the picture, because the best whiteboard is the one the customer starts drawing on."
Drawing boxes without direction, timing or authentication, or treating single sign-on and user provisioning as the same thing.
Polling: simple, you control the pace, but delayed and wasteful.
Webhooks: near real time and efficient, but you need a public endpoint and must handle retries.
Good practice: verify signatures, handle duplicates, keep a periodic check as a safety net.
"Polling means their system asks our API every few minutes whether anything changed. It's simple and works behind a firewall, but updates are delayed and most calls come back empty, which also eats into rate limits. Webhooks flip it: we call their endpoint when something happens, so it's near real time and far less wasteful. The catch is they need an endpoint we can reach, and they have to handle the realities of delivery. Most webhook systems retry on failure, so the same event can arrive twice, and their code should be idempotent. They should also verify the signature so they know the call really came from us. For important data I'd suggest webhooks for speed plus a light periodic check to catch anything missed during an outage."
const crypto = require('crypto');
// Check that a webhook really came from the sender who holds the shared secret.
function isValidSignature(rawBody, signatureHeader, secret) {
const expected = crypto.createHmac('sha256', secret).update(rawBody).digest('hex');
const a = Buffer.from(expected);
const b = Buffer.from(signatureHeader || '');
return a.length === b.length && crypto.timingSafeEqual(a, b);
}Saying webhooks are always better, or ignoring retries, duplicate events and signature checks.
Auth: how they get and send a token, and where it should be kept.
Request: method, endpoint, headers and body, then the response.
Real life: status codes, errors, rate limits and where the docs live.
"I'd open a terminal or an API client and keep it simple. First I'd show how they get an API token from the admin settings and say it belongs in a secrets store, not in code. Then I'd send a POST request to the endpoint for the object they care about, with the token in the Authorization header and a small JSON body. I'd show the response, point out the new record's ID, and then open the product so they see the same record appear. After that, I'd deliberately send a bad request, like a missing required field, so they see what a validation error looks like, usually a 400 or 422 status with a message saying which field is wrong. Finally I'd mention rate limits and share the link to the docs, so they can try it themselves after the call."
curl -X POST https://api.example.com/v1/contacts \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"email": "ana@example.com", "name": "Ana Silva"}'Only showing the API through slides, or getting lost in front of developers on basic things like headers and status codes.
Your line: what you will and won't say to win a deal.
Why it pays: trust, renewals and references.
Example: a time you said the honest thing and what happened.
"For me the line is simple. I'll present our product in the best honest light, but I won't say it does something it doesn't, and I won't let a customer buy on a wrong understanding. I don't see that as against the sales number. Customers who buy on a promise we can't keep become churn and bad references, and that hurts the next deal. Honesty also makes me more believable when I say we're strong at something. At my last company I told a prospect our reporting wouldn't meet one of their needs without a workaround. They bought anyway, because they trusted the rest of what I'd said, and they renewed. If I ever felt pushed to cross that line regularly, I'd raise it with my manager."
Saying whatever it takes to close, or treating honesty and selling as enemies.
Comfort: you like being tied to real outcomes.
Your part: what you control and how you'd track it.
Team view: shared credit with the account executive.
"I'm comfortable with it, and honestly I like it. It means my work is tied to whether customers actually buy, not just how busy I was. I know I don't control everything, like pricing or timing, so I focus on the parts I do control: good discovery, a demo that fits, a proof of concept that ends in a clear decision, and answers that come back on time. I'd also keep my own record of the technical wins and losses I was part of, so I can learn from the pattern. And I see the account executive as a partner, not a rival for credit. If we win, we both did our jobs. If we lose, I want to know which part of it was mine."
Showing discomfort with any sales target, or talking only about personal credit and commission.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your resume and notes are never stored on our servers. It stays out of screen share on every plan; only you can see it.