Sr Staff Software Engineer

Role summary

The Senior Staff Software Engineer (IC5) on HR Service Delivery sets and owns the technical direction for model-driven capability across the HR domain and the surfaces adjacent domains build on top of it. The work is agentic and conversational experiences that interpret an employee's, manager's, or HR agent's intent, reason over profile, case, catalog, policy, and knowledge context, invoke tools, and act on the user's behalf — but the unit of ownership is the architecture, the standards, and the evaluation infrastructure that let multiple teams ship those experiences safely, not a set of features.

This is not a machine learning or AI research role; the engineer does not train foundation models. It is also distinct from traditional staff-level full-stack engineering, where systems follow deterministic logic rather than selecting execution paths at runtime. Two consequences shape the work. First, the most important logic often lives in natural language — instructions, prompts, tool descriptions, guardrails, escalation rules — which must be engineered, versioned, and reviewed with the same discipline as code, and which needs an architecture once more than one team is authoring it. Second, because behavior is probabilistic, correctness is established by measuring behavior at scale rather than by asserting fixed outputs, which makes evaluation a platform investment rather than a per-feature activity.

HR sharpens both points along two independent axes.

Accuracy. An agent answering on payroll, benefits, leave, or a lifecycle event touches statutory entitlement, jurisdiction-specific policy, and an employee's pay. A confidently wrong output is not a bad answer; it is a missed enrollment window or an incorrect leave balance acted on in good faith.

Audience. HR data is among the most sensitive on the platform, and correctness of content is not sufficient. An answer grounded in a record or knowledge article the requestor is not entitled to read is a data exposure even when every fact in it is true, and manager-scope and employee-scope views of the same question have different correct answers. Enforcement belongs in the retrieval and tool layer, not in a request to the model, and at this level you own that being true by construction across every team building in the domain.

The distinguishing expectation at IC5 is that the hardest problems arrive unframed. You decide what the domain should do about them, commit the organization to an approach, and are accountable for that approach across releases — including for the decisions that turn out wrong.

What you do Set the AI architecture for the domain

Own the architecture of model-driven capability across the employee lifecycle: how agents are decomposed and composed, where reasoning happens, how context is assembled and bounded, how tools are exposed and described, and how autonomy is delegated and revoked. Establish the reference patterns other teams build against, and the boundaries between what is a shared platform concern and what each product area owns. Make the calls with multi-release consequences — model selection and migration, orchestration approach, build-versus-adopt, and the cost, latency, and quality tradeoffs behind each — and own the outcome.

Define where autonomy goes, and where it does not

Decide, as a matter of domain policy rather than per-feature design, which HR actions an agent may take, which require a human decision point, and which no agent should attempt. Anything that changes pay, employment status, or a restricted record, and anything touching employee relations or investigation, needs a human in the path by construction. Then build the mechanisms that make those constraints structural and hard to violate accidentally, so that a team shipping a new capability inherits the boundary instead of re-deriving it. You hold the authority to refuse a shipping decision on these grounds, and are expected to use it.

Own the shared instruction and tool-description architecture

HRSD ships as product: customers configure, extend, and override the instruction and tool surface on their own instances, and adjacent domains build against it. Treat it as a versioned contract with upgrade-safe extension points, deprecation paths, and compatibility guarantees. Own how that surface is structured, reviewed, and evolved across teams — including the authoring standards, the review bar, and the regression coverage that make natural-language logic maintainable at organizational scale rather than only within one codebase.

Build the evaluation infrastructure the organization ships against

Own evaluation as leverage: the golden datasets, multi-turn suites, judge calibration, CI gates, and drift detection that let many teams change behavior safely and quickly. Extend coverage to the HR-specific failure classes — access-boundary violations in retrieval and citation, cross-scope leakage, jurisdictional and policy-variant correctness — and keep it meaningful across the range of customer configurations rather than a single reference environment. Define the resolution, containment, and quality metrics the domain is measured on, be the person who can say whether they are instrumented correctly, and raise the standard of evidence required before a behavioral change ships.

Frame problems the organization has not yet framed

Identify the risks, gaps, and structural weaknesses in model-driven behavior that no one has articulated yet, quantify them, and drive them to a decision. This includes the failure classes that only appear at scale or in specific customer environments, the second-order consequences of a model or platform change, and the places where current practice will not survive the next generation of capability. Bring these to product and engineering leadership with the analysis and the recommendation, not the problem alone.

Direct AI coding agents, and set how the organization does

Convert ambiguous problem statements into testable specifications with explicit scope, constraints, non-goals, and acceptance criteria; decompose work into agent-sized tasks; and supervise parallel workstreams. Beyond your own delivery, define what accountable agent-assisted engineering looks like for the domain — specification standards, review expectations, verification harnesses — and hold the line on it. You own the result regardless of what produced it, and you own the norm.

Own production quality, safety, and reliability across the domain

Own the observability and safety posture for agentic behavior: conversation quality, containment, hallucination rate, tool-selection error, unsafe or unauthorized action, and the paths where user-supplied content — case notes, inbound email, attachments, authored knowledge — enters agent context as an injection vector. Because HR conversation content is itself restricted, design diagnosis that works without exposing what was said. Lead root-cause analysis on the incidents no one else can resolve, hold the distinction between a genuine model failure and a platform or configuration failure presenting as one, and close the loop from production failure back into specification and evaluation.

Deliver hands-on where it matters

Stay in the code on the load-bearing parts: the hard integration, the risky migration, the prototype that settles an architectural argument, the incident nobody else can unblock. Delivery at this level is selective and deliberate rather than continuous, and the expectation is that your hands-on work resolves uncertainty for others rather than absorbing feature scope.

Influence beyond the team

Represent the domain's technical position to engineering and product leadership, to customers, and to partner organizations. Communicate capability and risk to non-engineering audiences without flattening either. Build alignment across teams that do not report to you and whose priorities compete. Grow staff-level engineers, raise the bar in technical review and hiring, and make the domain's practices around instruction authoring, evaluation, and accountable agent use durable enough to outlast your involvement in any one project.

Required experience and skills

 

• Experience in leveraging or critically thinking about how to integrate AI into work processes, decision-making, or problem-solving. This may include using AI-powered tools, automating workflows, analyzing AI-driven insights, or exploring AI's potential impact on the function or industry.
• 12+ years software engineering experience (backend, frontend, or full stack) 
• Strong JavaScript/Node.js, React and API integration skills  
• Automated testing (unit + integration) and CI/CD pipeline experience 
• Solid understanding of data modelling and query optimization 
• Agentic delivery experience: 
• Hands-on experience with AI/GenAI or ML-driven features (LLM prompting, NLU, classification models, or similar) 
• Hands-on experience with LLM-integrated features: prompt design, context injection, output tuning,                    guardrails.  
• Experience with NLU/intent classification or conversational AI systems 
• Familiarity with ML-driven automation (classification, clustering, recommendation systems) 
• Production AI integration. Experience integrating large language model APIs and retrieval-grounded features, including agent orchestration, tool and function calling, and structured output enforcement. 
• Applied machine learning literacy. A working command of the concepts that govern how these systems behave — evaluation, embeddings, and the probabilistic output and failure modes of modern models — sufficient to reason about, debug, and verify model-driven behaviour in production. 
• Accountable use of AI coding agents. Current, effective use of AI coding assistants and agents with evidence of accountable delivery: precise specification, critical review of generated output, and verification harnesses. 
• Operational experience. Hands-on CI/CD, containerized workloads, and observability experience, plus direct on-call and incident-command experience with customer-facing systems. 
• Mentorship. Demonstrated mentorship of less-experienced engineers and a record of raising quality through code review. 
• Education. Bachelor's degree in computer science, software engineering, or a related technical field, or equivalent practical experience. Advanced degrees are a plus but not a substitute for a record of shipping reliable AI-native applications.

Preferred experience 

• HR domain depth. HR case management, the employee lifecycle, or payroll, benefits, leave, and absence, at a depth sufficient to challenge a requirement rather than only implement it — including why the same policy question resolves differently by jurisdiction, employment type, or plan year. 
• HCM and downstream integration. Integration with core HR, payroll, and benefits systems of record, including the reconciliation and eventual-consistency problems that come with treating an external system as the authority on employment data. 
• Extensible product engineering. Building capability that customers configure, extend, and override on their own instances, where instruction and tool surfaces are versioned contracts rather than internal implementation. 
• Evaluation and observability tooling. Evaluation frameworks, prompt and instruction management tooling, tracing for model-driven applications, and analysis of production transcripts at scale, particularly where transcript content is itself access-restricted. 
• Conversational channel breadth. Employee self-service portals, virtual agent or chat shells, workplace messaging clients, and voice, including handoff between automated and live agents. 
• Conversation design partnership. Working alongside conversation or content designers on dialogue flow, tone, and error-recovery design — with attention to how an HR answer is worded when the subject is the employee's own pay, health coverage, or employment status. 
• Forward deployed delivery. Building against a customer's data, integrations, and channels, and tuning instructions and evaluation sets in their environment. 
• Now Platform depth. Scoped applications, ACLs and platform security rules, Flow Designer, UI Builder, Automated Test Framework, and upgrade-safe extension patterns.