Sales Engineer (Founding)
for headings: About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule. Only include sections that have real specific content. We must not repeat job title. No metadata like Job ID. Remove boilerplate. We need to preserve all substantive information from the posting.
We need to parse the posting: It starts with "About Obin AI has made plenty of promises..." That's about the company. Then "The role" description. Then "What You Will Own" list of responsibilities. Then "What We Are Looking For" list of requirements. Then "Strongly Preferred" list.
We need to map to sections: About the role (maybe company overview?), Responsibilities (What You Will Own), Requirements (What We Are Looking For), Qualifications (maybe same as Requirements?), Skills (maybe from Strongly Preferred?), Benefits, Pay, Schedule (none present). We should only include sections that have real content. There's no explicit Benefits, Pay, Schedule mentioned. So we should not include those sections.
We need to use for each section heading. Use - for any list of duties/requirements/benefits. Use
for prose.
We must not invent or summarize away detail. Must preserve all substantive information. So we need to include all details from the posting, but we can format them.
We need to avoid repeating job title. The posting didn't explicitly give a job title besides "first sales engineer". We can maybe not repeat that heading.
We need to output only HTML fragment.
Let's extract content:
Company description (About Obin): "Obin AI has made plenty of promises. Regulated financial institutions need systems they can deploy, govern, and defend to a regulator. Obin is the agentic workforce for regulated finance. We build AI agents trained on how a specific firm actually works — its operating logic, its edge cases, its regulatory framework — that run inside the client's own cloud and governance boundary. Every agent we build belongs to the client: their cloud, their model, their IP. Outputs are auditable, traceable, and reversible. We help leading institutions rethink critical workflows across insurance, private credit, private equity, and commercial lending. Our founders are Apoorv Saxena (Global Head of AI at JPMorgan Chase, Managing Director at Silver Lake, Head of Product for Cloud AI at Google) and Lak Lakshmana (Data & AI operating executive at Silver Lake, Head of Data Analytics & AI at Google). Our advisors include Fei-Fei Li and Lukasz Kaiser. We are in production at institutions representing over $1 trillion in assets, profitable since seed, and closing a Series A."
That's about the company. Could be placed under "About the role"? Actually "About the role" heading is for role description, but we could use it for company overview? The instruction: use
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). So we should follow those headings. "About the role" likely refers to description of the role and maybe company context. We'll put the company overview under About the role.
Then responsibilities: "What You Will Own" bullet list. We'll put under Responsibilities.
Then requirements: "What We Are Looking For" bullet list. We'll put under Requirements.
Then qualifications: maybe we can combine with Requirements? But we need to decide if we need a Qualifications section. The posting doesn't have a separate qualifications list; the requirements are qualifications. Could we put Qualifications same as Requirements? Probably better to have Requirements and Qualifications both, but we must not create empty sections. Since we have content for Requirements, we can also have Qualifications with same content? That would be duplication. Better to treat Requirements as the list, and maybe Qualifications can be omitted if no distinct content. However the instruction says include a section ONLY when the posting has real, specific content for it. So we should not create Qualifications if there is no distinct qualifications list separate from Requirements. The posting has "What We Are Looking For" which is requirements. So we can put that under Requirements. Qualifications could be omitted.
Skills: The "Strongly Preferred" list could be considered Skills. It includes specific preferences: 5 to 12 years experience, insurance etc, hands-on ability, deployments, experience in services-plus-product model, early-stage or first-SE experience. That's more like preferred qualifications/skills. We could put under Skills.
Thus sections: About the role (company overview + role description?), Responsibilities (What You Will Own), Requirements (What We Are Looking For), Skills (Strongly Preferred). No Benefits, Pay, Schedule.
We need to ensure we preserve all substantive information. Let's capture the role description paragraph after "The role". That includes: "You are our first sales engineer. Today our CTO and our founders sit in every technical conversation, which does not scale and is the reason this seat exists. You will be the technical partner to our Client Partners and Account Executives across the full cycle: discovery, demo, architecture and security review, workflow scoping, and the handoff into delivery. You will translate in both directions — turning a client's operating problem into something our engineers can scope, and turning what we have built into something a business buyer understands. Be clear-eyed about what this is. No team, no library of demo assets, no discovery framework waiting for you. You will build the technical sales function while carrying it."
We should include that prose under About the role maybe after company overview.
Thus About the role section will contain two paragraphs: company overview and role description.
Now Responsibilities: list each bullet from "What You Will Own". Let's extract them:
- Technical discovery. Get underneath the stated requirement to the actual workflow, the exception paths, and where the current process breaks.
- The business-buyer demo. Own the flow, the narrative, and the data, including the Context Studio story. Build it so a Client Partner can run it without you.
- Architecture and security reviews. Lead conversations on data access, deployment model, controls, lineage, and auditability.
- Model risk and compliance. Support the questions that stall deals in regulated institutions.
- Accuracy and evals. Explain, credibly and specifically, how we get from a frontier model's baseline to production accuracy — ontology, encoded SOPs, edge-case handling, error correction, and the eval sets that prove it. Technical buyers will test this, and hand-waving ends the conversation.
- Scoping with engineering. Translate opportunities into estimates our delivery team can stand behind, and be honest with sellers about what capacity allows. You produce the opportunity brief, the ROI validation, and the scope that feeds the SOW.
- Clean handoff. The delivery pod inherits your scope. Make it something a forward-deployed engineer can build from without re-discovering the account.
- Technical enablement. Build the objection library, the proof points, and the talk tracks so the commercial team is not dependent on you for every call.
We need to preserve the exact phrasing. Use - for each.
Now Requirements: "What We Are Looking For" bullet list:
- Must have Enterprise sales engineering experience. You have supported seven-figure deals with long cycles and technical buying committees.
- Financial services fluency. You have been through security review, model risk, and third-party risk at a bank, insurer, or asset manager, and you know what actually blocks a deal.
- You can demo to a business buyer. Not just a technical audience. You know the difference and you can do both.
- Applied AI understanding. LLMs, RAG, agentic workflows, and where each is and is not appropriate. Enough depth to be credible with engineers, and enough honesty to say what we cannot do.
- Builder appetite. Comfortable with no playbook, no demo library, and no team.
- You have killed a deal on technical grounds, against sales pressure, and you can explain why you were right.
Now Skills (Strongly Preferred):
- Strongly Preferred 5 to 12 years in sales engineering, solutions consulting, or forward-deployed engineering
- Insurance, private credit, or asset management specifically
- Hands-on ability to build a prototype or manipulate data rather than only presenting
- Deployments into a client's own cloud (GCP especially), on-prem, or VPC-isolated environments
- Experience in a services-plus-product model rather than pure SaaS
- Early-stage or first-SE experience
We need to keep the bullet points exactly as given, maybe trim leading/trailing spaces.
Now we need to output HTML fragment only, no markdown fences.
Let's construct:
About the role
Obin AI has made plenty of promises. Regulated financial institutions need systems they can deploy, govern, and defend to a regulator. Obin is the agentic workforce for regulated finance. We build AI agents trained on how a specific firm actually works — its operating logic, its edge cases, its regulatory framework — that run inside the client's own cloud and governance boundary. Every agent we build belongs to the client: their cloud, their model, their IP. Outputs are auditable, traceable, and reversible. We help leading institutions rethink critical workflows across insurance, private credit, private equity, and commercial lending. Our founders are Apoorv Saxena (Global Head of AI at JPMorgan Chase, Managing Director at Silver Lake, Head of Product for Cloud AI at Google) and Lak Lakshmana (Data & AI operating executive at Silver Lake, Head of Data Analytics & AI at Google). Our advisors include Fei-Fei Li and Lukasz Kaiser. We are in production at institutions representing over $1 trillion in assets, profitable since seed, and closing a Series A.
You are our first sales engineer. Today our CTO and our founders sit in every technical conversation, which does not scale and is the reason this seat exists. You will be the technical partner to our Client Partners and Account Executives across the full cycle: discovery, demo, architecture and security review, workflow scoping, and the handoff into delivery. You will translate in both directions — turning a client's operating problem into something our engineers can scope, and turning what we have built into something a business buyer understands. Be clear-eyed about what this is. No team, no library of demo assets, no discovery framework waiting for you. You will build the technical sales function while carrying it.
Responsibilities
- Technical discovery. Get underneath the stated requirement to the actual workflow, the exception paths, and where the current process breaks.
- The business-buyer demo. Own the flow, the narrative, and the data, including the Context Studio story. Build it so a Client Partner can run it without you.
- Architecture and security reviews. Lead conversations on data access, deployment model, controls, lineage, and auditability.
- Model risk and compliance. Support the questions that stall deals in regulated institutions.
- Accuracy and evals. Explain, credibly and specifically, how we get from a frontier model's baseline to production accuracy — ontology, encoded SOPs, edge-case handling, error correction, and the eval sets that prove it. Technical buyers will test this, and hand-waving ends the conversation.
- Scoping with engineering. Translate opportunities into estimates our delivery team can stand behind, and be honest with sellers about what capacity allows. You produce the opportunity brief, the ROI validation, and the scope that feeds the SOW.
- Clean handoff. The delivery pod inherits your scope. Make it something a forward-deployed engineer can build from without re-discovering the account.
- Technical enablement. Build the objection library, the proof points, and the talk tracks so the commercial team is not dependent on you for every call.
Requirements
- Must have Enterprise sales engineering experience. You have supported seven-figure deals with long cycles and technical buying committees.
- Financial services fluency. You have been through security review, model risk, and third-party risk at a bank, insurer, or asset manager, and you know what actually blocks a deal
- for any list of duties/requirements/benefits. Use
for prose. We must not invent or summarize away detail. Must preserve all substantive information. So we need to include all details from the posting, but we can format them. We need to avoid repeating job title. The posting didn't explicitly give a job title besides "first sales engineer". We can maybe not repeat that heading. We need to output only HTML fragment. Let's extract content: Company description (About Obin): "Obin AI has made plenty of promises. Regulated financial institutions need systems they can deploy, govern, and defend to a regulator. Obin is the agentic workforce for regulated finance. We build AI agents trained on how a specific firm actually works — its operating logic, its edge cases, its regulatory framework — that run inside the client's own cloud and governance boundary. Every agent we build belongs to the client: their cloud, their model, their IP. Outputs are auditable, traceable, and reversible. We help leading institutions rethink critical workflows across insurance, private credit, private equity, and commercial lending. Our founders are Apoorv Saxena (Global Head of AI at JPMorgan Chase, Managing Director at Silver Lake, Head of Product for Cloud AI at Google) and Lak Lakshmana (Data & AI operating executive at Silver Lake, Head of Data Analytics & AI at Google). Our advisors include Fei-Fei Li and Lukasz Kaiser. We are in production at institutions representing over $1 trillion in assets, profitable since seed, and closing a Series A." That's about the company. Could be placed under "About the role"? Actually "About the role" heading is for role description, but we could use it for company overview? The instruction: use
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). So we should follow those headings. "About the role" likely refers to description of the role and maybe company context. We'll put the company overview under About the role. Then responsibilities: "What You Will Own" bullet list. We'll put under Responsibilities. Then requirements: "What We Are Looking For" bullet list. We'll put under Requirements. Then qualifications: maybe we can combine with Requirements? But we need to decide if we need a Qualifications section. The posting doesn't have a separate qualifications list; the requirements are qualifications. Could we put Qualifications same as Requirements? Probably better to have Requirements and Qualifications both, but we must not create empty sections. Since we have content for Requirements, we can also have Qualifications with same content? That would be duplication. Better to treat Requirements as the list, and maybe Qualifications can be omitted if no distinct content. However the instruction says include a section ONLY when the posting has real, specific content for it. So we should not create Qualifications if there is no distinct qualifications list separate from Requirements. The posting has "What We Are Looking For" which is requirements. So we can put that under Requirements. Qualifications could be omitted. Skills: The "Strongly Preferred" list could be considered Skills. It includes specific preferences: 5 to 12 years experience, insurance etc, hands-on ability, deployments, experience in services-plus-product model, early-stage or first-SE experience. That's more like preferred qualifications/skills. We could put under Skills. Thus sections: About the role (company overview + role description?), Responsibilities (What You Will Own), Requirements (What We Are Looking For), Skills (Strongly Preferred). No Benefits, Pay, Schedule. We need to ensure we preserve all substantive information. Let's capture the role description paragraph after "The role". That includes: "You are our first sales engineer. Today our CTO and our founders sit in every technical conversation, which does not scale and is the reason this seat exists. You will be the technical partner to our Client Partners and Account Executives across the full cycle: discovery, demo, architecture and security review, workflow scoping, and the handoff into delivery. You will translate in both directions — turning a client's operating problem into something our engineers can scope, and turning what we have built into something a business buyer understands. Be clear-eyed about what this is. No team, no library of demo assets, no discovery framework waiting for you. You will build the technical sales function while carrying it." We should include that prose under About the role maybe after company overview. Thus About the role section will contain two paragraphs: company overview and role description. Now Responsibilities: list each bullet from "What You Will Own". Let's extract them: - Technical discovery. Get underneath the stated requirement to the actual workflow, the exception paths, and where the current process breaks. - The business-buyer demo. Own the flow, the narrative, and the data, including the Context Studio story. Build it so a Client Partner can run it without you. - Architecture and security reviews. Lead conversations on data access, deployment model, controls, lineage, and auditability. - Model risk and compliance. Support the questions that stall deals in regulated institutions. - Accuracy and evals. Explain, credibly and specifically, how we get from a frontier model's baseline to production accuracy — ontology, encoded SOPs, edge-case handling, error correction, and the eval sets that prove it. Technical buyers will test this, and hand-waving ends the conversation. - Scoping with engineering. Translate opportunities into estimates our delivery team can stand behind, and be honest with sellers about what capacity allows. You produce the opportunity brief, the ROI validation, and the scope that feeds the SOW. - Clean handoff. The delivery pod inherits your scope. Make it something a forward-deployed engineer can build from without re-discovering the account. - Technical enablement. Build the objection library, the proof points, and the talk tracks so the commercial team is not dependent on you for every call. We need to preserve the exact phrasing. Use
- for each.
Now Requirements: "What We Are Looking For" bullet list:
- Must have Enterprise sales engineering experience. You have supported seven-figure deals with long cycles and technical buying committees.
- Financial services fluency. You have been through security review, model risk, and third-party risk at a bank, insurer, or asset manager, and you know what actually blocks a deal.
- You can demo to a business buyer. Not just a technical audience. You know the difference and you can do both.
- Applied AI understanding. LLMs, RAG, agentic workflows, and where each is and is not appropriate. Enough depth to be credible with engineers, and enough honesty to say what we cannot do.
- Builder appetite. Comfortable with no playbook, no demo library, and no team.
- You have killed a deal on technical grounds, against sales pressure, and you can explain why you were right.
Now Skills (Strongly Preferred):
- Strongly Preferred 5 to 12 years in sales engineering, solutions consulting, or forward-deployed engineering
- Insurance, private credit, or asset management specifically
- Hands-on ability to build a prototype or manipulate data rather than only presenting
- Deployments into a client's own cloud (GCP especially), on-prem, or VPC-isolated environments
- Experience in a services-plus-product model rather than pure SaaS
- Early-stage or first-SE experience
We need to keep the bullet points exactly as given, maybe trim leading/trailing spaces.
Now we need to output HTML fragment only, no markdown fences.
Let's construct:
About the role
Obin AI has made plenty of promises. Regulated financial institutions need systems they can deploy, govern, and defend to a regulator. Obin is the agentic workforce for regulated finance. We build AI agents trained on how a specific firm actually works — its operating logic, its edge cases, its regulatory framework — that run inside the client's own cloud and governance boundary. Every agent we build belongs to the client: their cloud, their model, their IP. Outputs are auditable, traceable, and reversible. We help leading institutions rethink critical workflows across insurance, private credit, private equity, and commercial lending. Our founders are Apoorv Saxena (Global Head of AI at JPMorgan Chase, Managing Director at Silver Lake, Head of Product for Cloud AI at Google) and Lak Lakshmana (Data & AI operating executive at Silver Lake, Head of Data Analytics & AI at Google). Our advisors include Fei-Fei Li and Lukasz Kaiser. We are in production at institutions representing over $1 trillion in assets, profitable since seed, and closing a Series A.
You are our first sales engineer. Today our CTO and our founders sit in every technical conversation, which does not scale and is the reason this seat exists. You will be the technical partner to our Client Partners and Account Executives across the full cycle: discovery, demo, architecture and security review, workflow scoping, and the handoff into delivery. You will translate in both directions — turning a client's operating problem into something our engineers can scope, and turning what we have built into something a business buyer understands. Be clear-eyed about what this is. No team, no library of demo assets, no discovery framework waiting for you. You will build the technical sales function while carrying it.
Responsibilities
- Technical discovery. Get underneath the stated requirement to the actual workflow, the exception paths, and where the current process breaks.
- The business-buyer demo. Own the flow, the narrative, and the data, including the Context Studio story. Build it so a Client Partner can run it without you.
- Architecture and security reviews. Lead conversations on data access, deployment model, controls, lineage, and auditability.
- Model risk and compliance. Support the questions that stall deals in regulated institutions.
- Accuracy and evals. Explain, credibly and specifically, how we get from a frontier model's baseline to production accuracy — ontology, encoded SOPs, edge-case handling, error correction, and the eval sets that prove it. Technical buyers will test this, and hand-waving ends the conversation.
- Scoping with engineering. Translate opportunities into estimates our delivery team can stand behind, and be honest with sellers about what capacity allows. You produce the opportunity brief, the ROI validation, and the scope that feeds the SOW.
- Clean handoff. The delivery pod inherits your scope. Make it something a forward-deployed engineer can build from without re-discovering the account.
- Technical enablement. Build the objection library, the proof points, and the talk tracks so the commercial team is not dependent on you for every call.
Requirements
- Must have Enterprise sales engineering experience. You have supported seven-figure deals with long cycles and technical buying committees.
- Financial services fluency. You have been through security review, model risk, and third-party risk at a bank, insurer, or asset manager, and you know what actually blocks a deal
- for each.
Now Requirements: "What We Are Looking For" bullet list:
- Must have Enterprise sales engineering experience. You have supported seven-figure deals with long cycles and technical buying committees.
- Financial services fluency. You have been through security review, model risk, and third-party risk at a bank, insurer, or asset manager, and you know what actually blocks a deal.
- You can demo to a business buyer. Not just a technical audience. You know the difference and you can do both.
- Applied AI understanding. LLMs, RAG, agentic workflows, and where each is and is not appropriate. Enough depth to be credible with engineers, and enough honesty to say what we cannot do.
- Builder appetite. Comfortable with no playbook, no demo library, and no team.
- You have killed a deal on technical grounds, against sales pressure, and you can explain why you were right.
Now Skills (Strongly Preferred):
- Strongly Preferred 5 to 12 years in sales engineering, solutions consulting, or forward-deployed engineering
- Insurance, private credit, or asset management specifically
- Hands-on ability to build a prototype or manipulate data rather than only presenting
- Deployments into a client's own cloud (GCP especially), on-prem, or VPC-isolated environments
- Experience in a services-plus-product model rather than pure SaaS
- Early-stage or first-SE experience
We need to keep the bullet points exactly as given, maybe trim leading/trailing spaces.
Now we need to output HTML fragment only, no markdown fences.
Let's construct: