Sales Engineer [NYC]
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). Do NOT repeat the job title as a heading (the page already shows it) and do NOT put Job ID / requisition numbers as headings — fold minor metadata into a short
or drop it. We need to preserve all substantive information, remove boilerplate, duplicate lines, application instructions, cookie/navigation/legal/EEO etc. The posting includes sections: About Concurrence (company description), About This Role (role description), What You'll Do (list of duties), What We're Looking For (requirements/qualifications), Nice to have (additional), Benefits (available To Full-Time Employees) (list), Core Values (maybe not needed as a heading? Not in list of allowed headings but could be considered as a section? The instruction says use h3 for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It doesn't forbid other headings, but says "include a section ONLY when the posting has real, specific content for it". Core Values is present, but not in the example list. Should we include? Possibly we could include as a section with heading like "Core Values". However the instruction says use h3 for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It doesn't say we cannot use other headings, but likely they expect only those standard headings. However we could map content: About Concurrence could be "About the role"? Actually "About the role" is typical heading for role description. But we have "About Concurrence" (company) and "About This Role". Could combine? Probably we should have sections: About the role (covering both company and role description?), Responsibilities (What You'll Do), Requirements (What We're Looking For), Skills (maybe Nice to have?), Benefits (Benefits). Pay: we have compensation range. Schedule: not mentioned. So we should include Pay section with compensation range. Also maybe include "Qualifications" separate from Requirements? The posting has "What We're Looking For" which includes experience, coding ability, etc. That's qualifications. Nice to have could be "Skills" or "Preferred Qualifications". We'll decide. We need to output only HTML fragment, no markdown fences. We must preserve all substantive information, not invent or summarize away detail. So we need to include the details from each bullet. Let's extract content: About Concurrence paragraph: description of company, mission, etc. About This Role: description of role. What You'll Do: bullet list (starting with "Build rapid POCs..."). What We're Looking For: bullet list (starting with "Experience in sales engineering..."). Nice to have: bullet list (starting with "Experience in healthcare technology..."). Benefits: bullet list (starting with "Health & Wellness"). Core Values: list of values with explanations. Compensation Range: "$170K - $200K". We need to format as
headings and appropriate - or
.
We must not include boilerplate like "We’re fresh off our Series A..."? That's substantive, keep.
We must remove duplicated lines, cookie/navigation/legal/EEO etc. There's none obvious.
We must not include application instructions.
Now decide sections:
- About the role: could combine About Concurrence and About This Role? But the instruction says use h3 for section headings (e.g. About the role...). So we can have
About the role
containing both company description and role description? Might be okay. However we might also have separate headings: About Concurrence and About This Role not in allowed list but could be considered as "About the role"? The instruction says "use for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule)". It doesn't forbid other headings but suggests those are typical. Safer to stick to those headings.
Thus we need to map content to those headings.
Possible mapping:
- About the role: includes company overview and role description.
- Responsibilities: What You'll Do.
- Requirements: What We're Looking For (mandatory).
- Qualifications: maybe Nice to have? Or we could treat Nice to have as "Skills". But we have both Requirements and Qualifications as separate headings allowed. Could put Requirements = mandatory, Qualifications = nice-to-have.
- Skills: maybe we could include technical skills like Python, LLMs etc. But those are already in Requirements. Could combine.
- Benefits: Benefits.
- Pay: Compensation range.
- Schedule: not present, so omit.
We must not create empty sections.
Thus we will output:
About the role
... company description + role description ...
Responsibilities
- ... each bullet ...
Requirements
- ... each bullet from What We're Looking For ...
Qualifications
- ... each bullet from Nice to have ...
Benefits
- ... each bullet from Benefits ...
Pay
$170K - $200K
We must ensure we preserve all substantive information. Let's extract each piece precisely.
Company description (About Concurrence):
"At Concurrence, we're building the clinical AI infrastructure that health systems, life sciences companies, payors, and government agencies run their patient-facing care on. Our agents work across the whole patient journey: pre-visit intake, care navigation, post-visit care plans, and ongoing monitoring. Our mission is to make excellent care accessible to every patient, not rationed by the limits of clinician time. This hasn’t been solved because the underlying record was never built for it. EHRs were designed for billing, not for systems that learn. So instead of layering another point solution on top, we’re rebuilding the medical record as a timeline of clinical events and running agents on top of it that improve with every patient interaction. Unlike single-purpose chatbots or scribes, Concurrence is the platform our customers use to build their own agents. That means our work has to hold up across specialties, workflows, and regulatory environments and not just one narrow use case. Our agents have supported more than 10 million patient encounters and are on track to grow tenfold this year. Our work is validated through partnerships with leading academic medical institutions. We’re fresh off our Series A, backed by Tier 1 VCs such as Madrona, General Catalyst, and Optum Ventures. We’re a small team of around 35 people, working in person in New York City and San Francisco. We care deeply about craft, clinical rigor, and the speed at which good ideas reach patients. If you want your work to be measured in outcomes rather than releases, we’d like to hear from you."
Role description (About This Role):
"As a Sales Engineer at Concurrence, you'll own the technical side of a deal from first conversation through signature. You'll work alongside the account executive with CIOs, chief medical officers, and their teams, establish what their environment supports, and build the demo that proves it. It's a hands-on role: our sales engineers write code, and the job is to show a prospect what's possible, not only what already exists. The role exists so our Applied AI Engineers can stay focused on production deployments. You own the pre-sales technical surface: scoping what we can do, building proof-of-concept agents, running technical discovery, and making the product feel real before anything is signed. You'll often be the only technical person in the room, so the role suits someone who can carry that without support. The standard we work to is that a demo should hold up as a product rather than a services engagement. We're building the team around two complementary strengths, and we'd rather someone be excellent at one than adequate at both. The first is building: you'd rather prototype five ideas in a week than polish one for a month, and you're happy being the first person to try the platform in a clinical domain we haven't touched. The second is domain depth: understanding how health systems operate, who signs, and who blocks. Over time we want coverage across the ecosystems our customers run on, including Epic, Cerner, Salesforce, and on-premise deployments."
Now Responsibilities (What You'll Do) list:
- Build rapid POCs and demo environments tailored to specific prospect workflows and clinical use cases
- Partner with account executives during technical discovery to scope what's possible and shape deal architecture
- Design and deliver live technical demonstrations that translate prospect pain points into working agent experiences
- Prototype experimental agent configurations that explore new use cases and push the boundaries of what our platform can do
- Run technical deep dives with prospect clinical, IT, and operations teams to understand integration requirements and workflow constraints, including EHRs and payor systems we haven't worked with before
- Create reusable demo assets and POC templates that accelerate future sales cycles
- Write the reference architectures, pricing and sizing models, and persona maps our cloud and data partners need to put us in front of their field teams
- Translate technical objections into solutions during the sales process, including security, compliance, and integration feasibility
- Collaborate with Applied AI Engineers to hand off won deals cleanly, documenting POC learnings and customer expectations
- Feed insights from the field back to product and engineering: what prospects are asking for, what patterns emerge, and where the platform should go next
- Stay current on AI and LLM developments and competitor capabilities
Now Requirements (What We're Looking For) list:
- Experience in sales engineering, solutions engineering, or a technical pre-sales role at a SaaS or AI company, with deals you can point to and describe your own technical contribution on
- Strong hands-on coding ability. You can build a working prototype, not just talk about one, and you're proficient in Python
- Experience with LLMs, prompt engineering, and building on AI platforms
- A hacker mentality: you're fast, scrappy, and energized by building things from scratch under time pressure
- Genuine excitement for AI innovation and exploring experimental use cases. You follow the space obsessively
- Ability to run a room, presenting to technical and executive audiences, handling objections live, and thinking on your feet
- Strong discovery skills: you ask the right questions to uncover real problems, not just stated requirements
- Experience working deals alongside account executives, and an understanding of sales cycles and buyer psychology
- Clear technical communication. You can explain complex systems to non-technical stakeholders without dumbing it down
- Comfort with ambiguity: prospects don't hand you clean requirements, and you thrive in that environment
- You're low ego, direct, and hold yourself to a high bar
- You can work on site in New York City
Now Qualifications (Nice to have) list:
- Experience in healthcare technology or another regulated industry
- Background as a software engineer who moved into a customer-facing role, or the reverse
- Deep knowledge of one ecosystem we sell into (Epic, Cerner, Salesforce, on-premise health systems), including how those organizations buy
- Familiarity with healthcare workflows, clinical terminology, and interoperability standards such as FHIR
- Understanding of healthcare compliance requirements such as HIPAA and SOC 2
- Experience building demo environments or sandbox platforms
- Experience with voice agents, and the latency and quality tradeoffs in speech to text and text to speech
- Experience building cloud partner motions, such as AWS or GCP marketplace listings and joint reference architectures
- A track record of directly influencing deal outcomes through technical work
Now Benefits list:
- Health & Wellness
-
. We must not include boilerplate like "We’re fresh off our Series A..."? That's substantive, keep. We must remove duplicated lines, cookie/navigation/legal/EEO etc. There's none obvious. We must not include application instructions. Now decide sections: - About the role: could combine About Concurrence and About This Role? But the instruction says use h3 for section headings (e.g. About the role...). So we can have
About the role
containing both company description and role description? Might be okay. However we might also have separate headings: About Concurrence and About This Role not in allowed list but could be considered as "About the role"? The instruction says "use for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule)". It doesn't forbid other headings but suggests those are typical. Safer to stick to those headings.
Thus we need to map content to those headings.
Possible mapping:
- About the role: includes company overview and role description.
- Responsibilities: What You'll Do.
- Requirements: What We're Looking For (mandatory).
- Qualifications: maybe Nice to have? Or we could treat Nice to have as "Skills". But we have both Requirements and Qualifications as separate headings allowed. Could put Requirements = mandatory, Qualifications = nice-to-have.
- Skills: maybe we could include technical skills like Python, LLMs etc. But those are already in Requirements. Could combine.
- Benefits: Benefits.
- Pay: Compensation range.
- Schedule: not present, so omit.
We must not create empty sections.
Thus we will output:
About the role
... company description + role description ...
Responsibilities
- ... each bullet ...
Requirements
- ... each bullet from What We're Looking For ...
Qualifications
- ... each bullet from Nice to have ...
Benefits
- ... each bullet from Benefits ...
Pay
$170K - $200K
We must ensure we preserve all substantive information. Let's extract each piece precisely. Company description (About Concurrence): "At Concurrence, we're building the clinical AI infrastructure that health systems, life sciences companies, payors, and government agencies run their patient-facing care on. Our agents work across the whole patient journey: pre-visit intake, care navigation, post-visit care plans, and ongoing monitoring. Our mission is to make excellent care accessible to every patient, not rationed by the limits of clinician time. This hasn’t been solved because the underlying record was never built for it. EHRs were designed for billing, not for systems that learn. So instead of layering another point solution on top, we’re rebuilding the medical record as a timeline of clinical events and running agents on top of it that improve with every patient interaction. Unlike single-purpose chatbots or scribes, Concurrence is the platform our customers use to build their own agents. That means our work has to hold up across specialties, workflows, and regulatory environments and not just one narrow use case. Our agents have supported more than 10 million patient encounters and are on track to grow tenfold this year. Our work is validated through partnerships with leading academic medical institutions. We’re fresh off our Series A, backed by Tier 1 VCs such as Madrona, General Catalyst, and Optum Ventures. We’re a small team of around 35 people, working in person in New York City and San Francisco. We care deeply about craft, clinical rigor, and the speed at which good ideas reach patients. If you want your work to be measured in outcomes rather than releases, we’d like to hear from you." Role description (About This Role): "As a Sales Engineer at Concurrence, you'll own the technical side of a deal from first conversation through signature. You'll work alongside the account executive with CIOs, chief medical officers, and their teams, establish what their environment supports, and build the demo that proves it. It's a hands-on role: our sales engineers write code, and the job is to show a prospect what's possible, not only what already exists. The role exists so our Applied AI Engineers can stay focused on production deployments. You own the pre-sales technical surface: scoping what we can do, building proof-of-concept agents, running technical discovery, and making the product feel real before anything is signed. You'll often be the only technical person in the room, so the role suits someone who can carry that without support. The standard we work to is that a demo should hold up as a product rather than a services engagement. We're building the team around two complementary strengths, and we'd rather someone be excellent at one than adequate at both. The first is building: you'd rather prototype five ideas in a week than polish one for a month, and you're happy being the first person to try the platform in a clinical domain we haven't touched. The second is domain depth: understanding how health systems operate, who signs, and who blocks. Over time we want coverage across the ecosystems our customers run on, including Epic, Cerner, Salesforce, and on-premise deployments." Now Responsibilities (What You'll Do) list: - Build rapid POCs and demo environments tailored to specific prospect workflows and clinical use cases - Partner with account executives during technical discovery to scope what's possible and shape deal architecture - Design and deliver live technical demonstrations that translate prospect pain points into working agent experiences - Prototype experimental agent configurations that explore new use cases and push the boundaries of what our platform can do - Run technical deep dives with prospect clinical, IT, and operations teams to understand integration requirements and workflow constraints, including EHRs and payor systems we haven't worked with before - Create reusable demo assets and POC templates that accelerate future sales cycles - Write the reference architectures, pricing and sizing models, and persona maps our cloud and data partners need to put us in front of their field teams - Translate technical objections into solutions during the sales process, including security, compliance, and integration feasibility - Collaborate with Applied AI Engineers to hand off won deals cleanly, documenting POC learnings and customer expectations - Feed insights from the field back to product and engineering: what prospects are asking for, what patterns emerge, and where the platform should go next - Stay current on AI and LLM developments and competitor capabilities Now Requirements (What We're Looking For) list: - Experience in sales engineering, solutions engineering, or a technical pre-sales role at a SaaS or AI company, with deals you can point to and describe your own technical contribution on - Strong hands-on coding ability. You can build a working prototype, not just talk about one, and you're proficient in Python - Experience with LLMs, prompt engineering, and building on AI platforms - A hacker mentality: you're fast, scrappy, and energized by building things from scratch under time pressure - Genuine excitement for AI innovation and exploring experimental use cases. You follow the space obsessively - Ability to run a room, presenting to technical and executive audiences, handling objections live, and thinking on your feet - Strong discovery skills: you ask the right questions to uncover real problems, not just stated requirements - Experience working deals alongside account executives, and an understanding of sales cycles and buyer psychology - Clear technical communication. You can explain complex systems to non-technical stakeholders without dumbing it down - Comfort with ambiguity: prospects don't hand you clean requirements, and you thrive in that environment - You're low ego, direct, and hold yourself to a high bar - You can work on site in New York City Now Qualifications (Nice to have) list: - Experience in healthcare technology or another regulated industry - Background as a software engineer who moved into a customer-facing role, or the reverse - Deep knowledge of one ecosystem we sell into (Epic, Cerner, Salesforce, on-premise health systems), including how those organizations buy - Familiarity with healthcare workflows, clinical terminology, and interoperability standards such as FHIR - Understanding of healthcare compliance requirements such as HIPAA and SOC 2 - Experience building demo environments or sandbox platforms - Experience with voice agents, and the latency and quality tradeoffs in speech to text and text to speech - Experience building cloud partner motions, such as AWS or GCP marketplace listings and joint reference architectures - A track record of directly influencing deal outcomes through technical work Now Benefits list: - Health & Wellness -