Senior / Staff ML Ops Engineer
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). Use - for any list of duties/requirements/benefits, and
for prose. Do NOT repeat the job title as a heading. Do NOT put Job ID / requisition numbers as headings — fold minor metadata into a short
or drop it. Preserve ALL substantive information; do NOT invent or summarize away detail. Remove cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, duplicated lines, and application instructions. IMPORTANT: include a section ONLY when the posting has real, specific content for it — never emit a heading followed by filler/placeholder text (e.g. "commensurate with experience", "not specified", "N/A", "varies", "TBD") and never create Pay/Schedule/Benefits sections unless the posting actually states them. Prefer a few substantive sections over many thin ones. Output ONLY the HTML fragment — no /, no markdown code fences.
Thus we need to decide which sections to include. The posting includes:
- Intro about Waabi (company description). Could be "About the role" or maybe "About the company". But they said use headings like About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule. So we can have "About the role" for the description of what you'll do? Actually responsibilities are separate. The "You will.." list is responsibilities. So we can have
Responsibilities
with a of each bullet.
- Qualifications: there is a "Qualifications:" section with bullet list of required qualifications. Also there is a "Bonus/nice to have:" list. Could combine into Requirements? Or we could have "Qualifications" for required, and maybe "Preferred Qualifications" for bonus. But they only listed certain headings as examples; we can use others if needed? The instruction says use for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It gives examples but not exclusive. We can add other headings if needed, but better to stick to those. We have Qualifications (required). We could also have Skills (maybe from qualifications). But we can just use Qualifications for required, and maybe "Preferred Qualifications" as a subsection? But they said prefer a few substantive sections over many thin ones. Could combine required and bonus into one Qualifications section with two lists? Might be okay.
- Pay: The posting includes salary range: $184,000 - $272,000 USD plus equity, bonus. So we should include a Pay section.
- Benefits: The posting includes perks/benefits list: Competitive compensation and equity awards, Health and Wellness benefits, Unlimited Vacation, Flexible hours and Work from Home support, Daily drinks, snacks and catered meals, Regularly scheduled team building activities, etc. So we should include Benefits.
- Schedule: Not explicitly mentioned. There's no mention of schedule like full-time, hours. There's "Flexible hours and Work from Home support". That's more about benefits. No explicit schedule like "Full-time". So we should not create a Schedule section because no specific schedule stated.
- About the role: Could include the introductory paragraph about Waabi and the role's mission. That is substantive. So we can have About the role with a
summarizing the company and role mission.
- Requirements: Could be same as Qualifications? The instruction includes both Requirements and Qualifications as possible headings. We could use Requirements for the required qualifications, and Qualifications for the bonus? But better to follow typical pattern: Requirements = required qualifications, Qualifications = preferred? However they gave both as examples; we can decide. Since we have a "Qualifications:" heading in the posting for required, and a "Bonus/nice to have:" for preferred. We could map Required to Requirements, Bonus to Qualifications (or Skills). But they said "Use
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule)." So we can use Requirements for required qualifications, Qualifications for bonus/nice to have, and maybe Skills for specific technical skills? But we already have many skills in qualifications. Might be redundant.
Simplify: Use About the role (intro), Responsibilities (the "You will.." list), Qualifications (required), Benefits, Pay. That's five sections. That seems good.
We must not include boilerplate like EEO, AI tools statement, etc. Remove those.
We must preserve all substantive information: include the intro about Waabi, the "You will.." bullets, the qualifications list (required), the bonus/nice to have list? Should we include bonus? It's substantive. If we omit, we lose info. So we need to include bonus somewhere. Could add a "Preferred Qualifications" section. But they didn't list that as example but we can still use it? The instruction says use those headings as examples, not exclusive. It says "Use for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule)." The "e.g." suggests those are examples, not an exhaustive list. So we can add other headings if needed. However they also say "Prefer a few substantive sections over many thin ones." So adding a Preferred Qualifications section might be okay if we keep sections few. We could merge bonus into Qualifications section as a sublist labeled "Bonus/nice to have". But we need to use - for any list. We could have a
with items, and within items we could note bonus? But better to separate.
We could have Qualifications (required) and then a separate section "Preferred Qualifications" (or "Bonus"). That adds another section, making total sections: About the role, Responsibilities, Qualifications (required), Preferred Qualifications, Benefits, Pay = 6 sections. That's still few.
Alternatively, we could have Qualifications include both required and bonus, with a note inside each item? Might be less clear.
I'll go with: About the role, Responsibilities, Qualifications (required), Preferred Qualifications, Benefits, Pay.
Now we need to extract the content.
About the role: The first paragraph: "Waabi, founded by AI visionary Raquel Urtasun, is the leader in Physical AI. With a world-class team, we're unlocking the next era of autonomous transportation with technology that's powering commercial autonomous trucks and robotaxis. Waabi is backed by and partners with world leaders in AI, automotive, logistics, and deep tech. With offices in Toronto, San Francisco, Dallas, and Pittsburgh, Waabi is growing quickly and looking for diverse, innovative and collaborative candidates who want to impact the world in a positive way. To learn more visit: www.waabi.ai". That's about the company. Could be About the role. We'll keep that as a .
Responsibilities: The "You will.." block. It's a long paragraph with many sentences separated by periods. We need to turn into list items. Each sentence after "You will.." seems to be a responsibility. Let's parse:
"You will.. Build and evolve our training infrastructure on Kubernetes with Infrastructure — GPU scheduling, autoscaling, multi-node distributed jobs, capacity strategy, and the operators and workflow engines that keep long-running training reliable.Shape the developer-facing surface — CLIs, SDKs, job submission, templates, paved paths — designed with the teams who'll use them. Make the common case one command and keep the uncommon case possible.Shorten the inner loop. Time to first training run, edit-to-signal latency, local iteration before a job hits the cluster, fast failure over slow mystery. Measure it, publish it, drive it down.Evangelize best-in-class tooling and frameworks. Track what the ecosystem is shipping, evaluate honestly, and make the case with working prototypes and migration paths — or say plainly when a shiny thing isn't worth the switching cost.Strengthen the data and artifact layer. Dataset versioning, sharding, and high-throughput loading of large multimodal sensor data, so jobs saturate GPUs instead of waiting on I/O.Turn one-off Python into durable tooling — tested, documented, observable libraries, CLIs, and services with sane defaults, and deletions where they're overdue.Make experiments legible, with the teams who live in them: experiment hygiene, dashboards researchers trust, a real model registry, and lineage from dataset to checkpoint to simulation result.Ship CI/CD for models alongside autonomy and simulation, so a model change is validated the same way a code change is.Build observability across the ML stack — utilization, throughput, failure modes, queue times, cost per experiment. When a job fails at 3am on node 47, the researcher should find out why without you.Treat docs, onboarding, and support as product surface — golden-path guides, a new researcher productive on day two, office hours that turn repeat questions into shipped fixes.Drive adoption, not just availability. Prototype with real users, watch them work, iterate. A tool nobody adopts didn't ship.Make the platform boringly reliable — fewer failures, faster recovery, and none of the manual steps that quietly cost a team days.Build guardrails that don't feel like walls, with Security, IT, and Infrastructure: access controls, data handling, and cost governance that hold up in an IP-sensitive environment while staying self-serve."
We need to split into sensible list items. Each sentence seems to be a responsibility. Let's split by periods that end a sentence. However some sentences have em dashes and colons. We'll just make each distinct responsibility as a
- . We'll try to capture each bullet.
I'll list them:
1. Build and evolve our training infrastructure on Kubernetes with Infrastructure — GPU scheduling, autoscaling, multi-node distributed jobs, capacity strategy, and the operators and workflow engines that keep long-running training reliable.
2. Shape the developer-facing surface — CLIs, SDKs, job submission, templates, paved paths — designed with the teams who'll use them.
3. Make the common case one command and keep the uncommon case possible.
4. Shorten the inner loop. Time to first training run, edit-to-signal latency, local iteration before a job hits the cluster, fast failure over slow mystery. Measure it, publish it, drive it down.
5. Evangelize best-in-class tooling and frameworks. Track what the ecosystem is shipping, evaluate honestly, and make the case with working prototypes and migration paths — or say plainly when a shiny thing isn't worth the switching cost.
6. Strengthen the data and artifact layer. Dataset versioning, sharding, and high-throughput loading of large multimodal sensor data, so jobs saturate GPUs instead of waiting on I/O.
7. Turn one-off Python into durable tooling — tested, documented, observable libraries, CLIs, and services with sane defaults, and deletions where they're overdue.
8. Make experiments legible, with the teams who live in them: experiment hygiene, dashboards researchers trust, a real model registry, and lineage from dataset to checkpoint to simulation result.
9. Ship CI/CD for models alongside autonomy and simulation, so a model change is validated the same way a code change is.
10. Build observability across the ML stack — utilization, throughput, failure modes, queue times, cost per experiment. When a job fails at 3am on node 47, the researcher should find out why without you.
11. Treat docs, onboarding, and support as product surface — golden-path guides, a new researcher productive on day
for prose. Do NOT repeat the job title as a heading. Do NOT put Job ID / requisition numbers as headings — fold minor metadata into a short
or drop it. Preserve ALL substantive information; do NOT invent or summarize away detail. Remove cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, duplicated lines, and application instructions. IMPORTANT: include a section ONLY when the posting has real, specific content for it — never emit a heading followed by filler/placeholder text (e.g. "commensurate with experience", "not specified", "N/A", "varies", "TBD") and never create Pay/Schedule/Benefits sections unless the posting actually states them. Prefer a few substantive sections over many thin ones. Output ONLY the HTML fragment — no /, no markdown code fences. Thus we need to decide which sections to include. The posting includes: - Intro about Waabi (company description). Could be "About the role" or maybe "About the company". But they said use headings like About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule. So we can have "About the role" for the description of what you'll do? Actually responsibilities are separate. The "You will.." list is responsibilities. So we can have
Responsibilities
with a- of each bullet.
- Qualifications: there is a "Qualifications:" section with bullet list of required qualifications. Also there is a "Bonus/nice to have:" list. Could combine into Requirements? Or we could have "Qualifications" for required, and maybe "Preferred Qualifications" for bonus. But they only listed certain headings as examples; we can use others if needed? The instruction says use
- for any list. We could have a
- with items, and within items we could note bonus? But better to separate.
We could have Qualifications (required) and then a separate section "Preferred Qualifications" (or "Bonus"). That adds another section, making total sections: About the role, Responsibilities, Qualifications (required), Preferred Qualifications, Benefits, Pay = 6 sections. That's still few.
Alternatively, we could have Qualifications include both required and bonus, with a note inside each item? Might be less clear.
I'll go with: About the role, Responsibilities, Qualifications (required), Preferred Qualifications, Benefits, Pay.
Now we need to extract the content.
About the role: The first paragraph: "Waabi, founded by AI visionary Raquel Urtasun, is the leader in Physical AI. With a world-class team, we're unlocking the next era of autonomous transportation with technology that's powering commercial autonomous trucks and robotaxis. Waabi is backed by and partners with world leaders in AI, automotive, logistics, and deep tech. With offices in Toronto, San Francisco, Dallas, and Pittsburgh, Waabi is growing quickly and looking for diverse, innovative and collaborative candidates who want to impact the world in a positive way. To learn more visit: www.waabi.ai". That's about the company. Could be About the role. We'll keep that as a
- . We'll try to capture each bullet. I'll list them: 1. Build and evolve our training infrastructure on Kubernetes with Infrastructure — GPU scheduling, autoscaling, multi-node distributed jobs, capacity strategy, and the operators and workflow engines that keep long-running training reliable. 2. Shape the developer-facing surface — CLIs, SDKs, job submission, templates, paved paths — designed with the teams who'll use them. 3. Make the common case one command and keep the uncommon case possible. 4. Shorten the inner loop. Time to first training run, edit-to-signal latency, local iteration before a job hits the cluster, fast failure over slow mystery. Measure it, publish it, drive it down. 5. Evangelize best-in-class tooling and frameworks. Track what the ecosystem is shipping, evaluate honestly, and make the case with working prototypes and migration paths — or say plainly when a shiny thing isn't worth the switching cost. 6. Strengthen the data and artifact layer. Dataset versioning, sharding, and high-throughput loading of large multimodal sensor data, so jobs saturate GPUs instead of waiting on I/O. 7. Turn one-off Python into durable tooling — tested, documented, observable libraries, CLIs, and services with sane defaults, and deletions where they're overdue. 8. Make experiments legible, with the teams who live in them: experiment hygiene, dashboards researchers trust, a real model registry, and lineage from dataset to checkpoint to simulation result. 9. Ship CI/CD for models alongside autonomy and simulation, so a model change is validated the same way a code change is. 10. Build observability across the ML stack — utilization, throughput, failure modes, queue times, cost per experiment. When a job fails at 3am on node 47, the researcher should find out why without you. 11. Treat docs, onboarding, and support as product surface — golden-path guides, a new researcher productive on day
. Responsibilities: The "You will.." block. It's a long paragraph with many sentences separated by periods. We need to turn into list items. Each sentence after "You will.." seems to be a responsibility. Let's parse: "You will.. Build and evolve our training infrastructure on Kubernetes with Infrastructure — GPU scheduling, autoscaling, multi-node distributed jobs, capacity strategy, and the operators and workflow engines that keep long-running training reliable.Shape the developer-facing surface — CLIs, SDKs, job submission, templates, paved paths — designed with the teams who'll use them. Make the common case one command and keep the uncommon case possible.Shorten the inner loop. Time to first training run, edit-to-signal latency, local iteration before a job hits the cluster, fast failure over slow mystery. Measure it, publish it, drive it down.Evangelize best-in-class tooling and frameworks. Track what the ecosystem is shipping, evaluate honestly, and make the case with working prototypes and migration paths — or say plainly when a shiny thing isn't worth the switching cost.Strengthen the data and artifact layer. Dataset versioning, sharding, and high-throughput loading of large multimodal sensor data, so jobs saturate GPUs instead of waiting on I/O.Turn one-off Python into durable tooling — tested, documented, observable libraries, CLIs, and services with sane defaults, and deletions where they're overdue.Make experiments legible, with the teams who live in them: experiment hygiene, dashboards researchers trust, a real model registry, and lineage from dataset to checkpoint to simulation result.Ship CI/CD for models alongside autonomy and simulation, so a model change is validated the same way a code change is.Build observability across the ML stack — utilization, throughput, failure modes, queue times, cost per experiment. When a job fails at 3am on node 47, the researcher should find out why without you.Treat docs, onboarding, and support as product surface — golden-path guides, a new researcher productive on day two, office hours that turn repeat questions into shipped fixes.Drive adoption, not just availability. Prototype with real users, watch them work, iterate. A tool nobody adopts didn't ship.Make the platform boringly reliable — fewer failures, faster recovery, and none of the manual steps that quietly cost a team days.Build guardrails that don't feel like walls, with Security, IT, and Infrastructure: access controls, data handling, and cost governance that hold up in an IP-sensitive environment while staying self-serve." We need to split into sensible list items. Each sentence seems to be a responsibility. Let's split by periods that end a sentence. However some sentences have em dashes and colons. We'll just make each distinct responsibility as a
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It gives examples but not exclusive. We can add other headings if needed, but better to stick to those. We have Qualifications (required). We could also have Skills (maybe from qualifications). But we can just use Qualifications for required, and maybe "Preferred Qualifications" as a subsection? But they said prefer a few substantive sections over many thin ones. Could combine required and bonus into one Qualifications section with two lists? Might be okay. - Pay: The posting includes salary range: $184,000 - $272,000 USD plus equity, bonus. So we should include a Pay section. - Benefits: The posting includes perks/benefits list: Competitive compensation and equity awards, Health and Wellness benefits, Unlimited Vacation, Flexible hours and Work from Home support, Daily drinks, snacks and catered meals, Regularly scheduled team building activities, etc. So we should include Benefits. - Schedule: Not explicitly mentioned. There's no mention of schedule like full-time, hours. There's "Flexible hours and Work from Home support". That's more about benefits. No explicit schedule like "Full-time". So we should not create a Schedule section because no specific schedule stated. - About the role: Could include the introductory paragraph about Waabi and the role's mission. That is substantive. So we can have About the role with a
summarizing the company and role mission. - Requirements: Could be same as Qualifications? The instruction includes both Requirements and Qualifications as possible headings. We could use Requirements for the required qualifications, and Qualifications for the bonus? But better to follow typical pattern: Requirements = required qualifications, Qualifications = preferred? However they gave both as examples; we can decide. Since we have a "Qualifications:" heading in the posting for required, and a "Bonus/nice to have:" for preferred. We could map Required to Requirements, Bonus to Qualifications (or Skills). But they said "Use