Senior Software Test Engineer

We need to output HTML fragment with sections: About the role? Actually the posting includes "About Curative" (company description) then "Summary", "How We Build", "What You'll Own", "Foundational Skills", "Strongly Preferred", "Why this role", "Perks & Benefits". We need to use

for section headings like About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule. But we can only include sections when posting has real specific content. The headings we can use: About the role (maybe corresponds to Summary?), Responsibilities (What You'll Own?), Requirements/Qualifications/Skills (Foundational Skills, Strongly Preferred?), Benefits (Perks & Benefits). Pay and Schedule not present, so omit. We must not repeat job title as heading. Also we should not include Job ID etc. We need to preserve all substantive information, not invent or summarize away detail. Remove boilerplate: cookie/navigation/legal/EEO etc. There's none. We need to output only HTML fragment, no /, no markdown fences. We need to use

for section headings. Use

• for any list of duties/requirements/benefits, and

  for prose. We need to decide how to structure content. We have sections: - About Curative (company description) maybe not needed as a section? Could be part of About the role? The instruction: use

  for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). So we can have About the role heading, then content about role (summary). Could also include company description under About the role? Probably yes. But we also have "How We Build", "What You'll Own", "Foundational Skills", "Strongly Preferred", "Why this role", "Perks & Benefits". Those could map to Responsibilities, Requirements, Skills, Benefits etc. We need to avoid filler headings. So we should include sections only where there is real content. Let's map: - About the role: could include company description and summary (the "Summary" section). That seems appropriate. - Responsibilities: could be "What You'll Own" (list of duties). That's a list. - Requirements/Qualifications/Skills: could combine Foundational Skills and Strongly Preferred as requirements/qualifications/skills. Might need separate headings? The instruction says we can use those headings but we should prefer few substantive sections over many thin ones. So maybe combine into one "Requirements" section covering both foundational and strongly preferred. Or we could have "Skills" section for strongly preferred? But better to have one "Requirements" section with sublists? However we must use

  • for any list. Could have nested lists? Probably okay. - Benefits: "Perks & Benefits" section. - Pay and Schedule: not present, omit. We must not include headings with filler text. So we will output:

    About the role

    ... (company description + summary)

    Responsibilities

    • ... each bullet from What You'll Own

    Requirements

    • ... Foundational Skills bullets
    • ... Strongly Preferred bullets (maybe separate sublist? Could just continue list)

    Benefits

    • ... Perks & Benefits bullets
    We need to preserve all substantive information. Let's extract content. Company description paragraph: "About Curative Curative is building the future of health insurance with a first-of-its-kind employer-based plan designed to remove financial barriers and make care truly accessible: one monthly premium with $0 copays and $0 deductibles*. Backed by our recent $150M in Series B funding and valuation at $1.275B, Curative is scaling rapidly and investing in AI-powered service, deeper member engagement, and a smart network designed for today’s workforce. Our north star guides everything we do: healthcare only works when people can actually use it. That belief drives every decision we make: from how we design our plan, support our members, to how we collaborate as a team. If you want to do meaningful work with a team that moves fast, experiments boldly, and cares deeply, Curative is the place to do it. We’re growing fast and looking for teammates who want to help transform health insurance for the better." Summary paragraph: "We are hiring a Senior Software Test Engineer to help us deliver quickly with the right level of quality. If you're picturing test plans, sign-off gates, and sprint ceremonies, this is not that job. At Curative, every engineer owns what they ship. Your job is to make that possible at speed. A big part of that is our AI agents, which do real operational work in production. We're investing in the evaluation layer to match: eval suites, regression harnesses, and systematic measurement. But the role is not only infrastructure. You'll work directly with business teams, become a domain expert in corners of our business, test the way real users work, and catch the gap between what was asked for and what was shipped. Some days you're writing an eval harness; some days you're hunting a bug an operations teammate can feel but can't pin down; some days you're shaping what gets built next. You'll advise on quality concerns, and you'll jump in and fix things yourself: same day, not next sprint. If ambiguity sounds stressful, this is the wrong role. If moving between code, product, and people in the same afternoon sounds like the best part of the job, keep reading." How We Build section: maybe could be part of About the role? But we could incorporate into About the role as extra prose. However we need to preserve all substantive information. Could add another paragraph under About the role after summary. But the instruction: Prefer a few substantive sections over many thin ones. So we could keep About the role as a single section containing company description, summary, and How We Build. That's okay. Now Responsibilities: "What You'll Own" bullet list: - The eval platform. Harnesses, datasets, graders, and CI integration that let teams measure agent behavior: task success, tool-use correctness, drift, latency, cost. You'll build it and make it the thing teams reach for because it's useful, not because a process says so. - Hands-on, exploratory testing. You test the way members, operations teams, and providers actually use the product, end to end, weird paths included, and find what breaks before the real world does. - Validating we built the right thing. You sit with business stakeholders, understand the real workflow, and catch the gap between what was asked for and what was shipped. - Domain expertise. You go deep enough on our business that teams pull you in because you understand the workflow, not just the code. - Production signal and bug hunting. Traces, failure taxonomies, and dashboards that turn "the agent seems off" into a specific finding. In incidents you reproduce the failure, find the root cause, and fix it or hand off a diagnosis so precise the fix is obvious. - Product judgment when needed. Sometimes there's no PM in the room. You can write the requirement, propose the behavior, make the call, and hand it back gracefully when the right owner shows up. - Prioritization under chaos. Finite hours, wide surface. You decide where effort goes first, which agents carry the most risk, and which failures are expensive versus merely embarrassing, and you defend that call. We need to preserve each bullet as
  • . Now Requirements: Foundational Skills bullet list: - 5+ years in software quality, testing, or engineering with real range. You've written automation and done serious exploratory testing, moving between them as the problem demands. - Real fluency with LLM evaluation. Golden datasets, LLM-as-judge, programmatic graders, regression suites for prompts and agent loops. You can point to evals that caught real problems. - Hands-on experience with AI agents and the ways they fail: silent drift, tool misuse, compounding errors. - A tester's instincts. You find the bug nobody else does, and you have the track record to prove it. - Debugging depth. Logs, traces, queries, production forensics. You find the bug and can fix it yourself in Python or TypeScript. - Fluency with business stakeholders. You can run a session with a non-technical operations lead, extract what they actually need, and leave them feeling heard. - Comfort with ambiguity and speed. You've been effective without mature processes. You don't need a ticket or sprint boundary to start. - Pragmatic quality judgment. You can say "this risk is acceptable, ship it" as often as "this one isn't" - Sharp written communication. Your findings change what people do. - AI-first working style Claude Code, Cursor, or equivalent is already your primary development tool. You use AI to accelerate the quality work itself (eval cases, graders, triage) and know where AI judgment ends and yours begins. You review every AI-generated diff. You do not merge on vibes. Strongly Preferred bullet list: - Stood up eval or observability infrastructure from zero, and it stuck. - LLM observability tooling: LangSmith, Braintrust, Arize, or homegrown. - Defined what an agent may do unsupervised and built the guardrails. - Worn a product hat: requirements, behavior, de facto PM for a surface. - Built deep domain expertise from scratch in a complex operational business. We can combine these into Requirements section, maybe separate subheadings? But we should avoid many thin sections. Could just list all bullets together, maybe with a note "Strongly preferred:" but that would be extra text not in original? Might be okay as we preserve info. But we could just list them all as bullets; the distinction is not critical. However we need to preserve all info; we can keep them as separate bullet groups with a preceding

    indicating which are strongly preferred. That's extra text but not invented; it's just labeling. Might be acceptable. Better: keep two subsections: Foundational Skills and Strongly Preferred as separate

    ? But instruction only mentions

    for section headings. Could we use

    ? Not specified; but we could still use

    for each, but that would be many sections. The instruction says prefer a few substantive sections over many thin ones. So maybe combine. We'll combine:

    Requirements

    then a

    Foundational skills:

    then
    with those bullets, then

    Strongly preferred:

    then another
    . That's still a few sections (just one heading). That's okay. Now Benefits: Perks & Benefits bullet list: - Curative Health Plan (100% employer-covered medical premiums for you and 50% coverage for dependents on the base plan.) - $0 copays and $0 deductibles (with completion of our Baseline Visit ) - Preventive and primary care built in - Mental health support - One-on-one care navigation - Chronic condition programs (diabetes, weight, hypertension) - Maternity and family planning support - 24/7/365 Curative Telehealth - Pharmacy benefits - Comprehensive dental and vision coverage - Employer-provided life and disability coverage with additional supplemental options - Flexible spending accounts - Generous PTO policy plus 11 paid annual company holidays - 401K for full-time employees - Generous Up to 8–12 weeks paid parental leave, based on role eligibility. We need to preserve each bullet. Now we need to ensure we don't include any boilerplate like "*" footnote? The asterisk after $0 deductibles* maybe part of the benefit; we can keep it. Now we need to output only HTML fragment. Let's craft. We'll start with

    About the role

    then a

    containing company description