Staff Software Engineer

Job description

It all started when engineer Fred Luddy wrote code that automated a tedious task for his coworker, Phyllis. She cried tears of joy. That moment inspired Fred to build a company that could do that for everyone—freeing people from busywork so they could focus on meaningful work. Today, ServiceNow is the AI control tower for business reinvention. Our ServiceNow AI platform brings together any AI, any data, and any workflow— helping 85% of the Fortune 500® work smarter, faster, and better. We're building an AI-native culture where technology and talent are unstoppable together. And we're just getting started. Join us to put AI to work for people.   Role summary The Staff Software Engineer (IC4) on HR Service Delivery designs, builds, ships, and operates capabilities whose core behavior is model-driven rather than explicitly authored: agentic and conversational experiences that interpret an employee's, manager's, or HR agent's intent, reason over employee profile, case, catalog, policy, and knowledge context, invoke tools, and act on the user's behalf across the employee lifecycle. This is not a machine learning or AI research role; the engineer does not train foundation models. It is also distinct from traditional 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, all of which must be engineered, versioned, and reviewed with the same discipline as code. Second, because behavior is probabilistic, correctness is established by measuring behavior at scale rather than by asserting fixed outputs, making automated evaluation a first-class engineering activity rather than a quality-assurance afterthought. 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. Access boundaries have to be enforced in the retrieval and tool layer rather than requested of the model. At IC4 the engineer owns AI design decisions across the domain, not within a single feature, and owns the correctness of what ships whether a person or an agent produced it. What you do Build AI-native capability across the employee lifecycle Design and ship features built around agentic behavior — intent interpretation, multi-step reasoning, tool invocation, and action on the user's behalf — together with the data models, integrations, and channels that make them usable in production. In HRSD this spans guided service selection and intake, natural-language case creation and enrichment, conversational case status and in-flight change, tiered resolution of payroll and benefits inquiries, case triage, routing, and deflection, eligibility and entitlement inquiry, and agent-driven execution of onboarding, transfer, and offboarding lifecycle events. Design AI-driven autonomous workflows Decompose HR processes into the steps and decision points an agent can execute: determining where autonomy is appropriate, where a checkpoint with a person is required, and how exceptions, retries, and hand-back are handled. Anything that changes pay, employment status, or a restricted record, and anything touching employee relations or investigation, needs a human decision point by construction. The design must make that distinction structural rather than advisory. Author and maintain agentic instructions as engineering artifacts Write, structure, and version the system instructions, role definitions, tool descriptions, guardrails, and escalation paths that govern agent behavior in the domain, under code review, source control, and regression coverage. Own the shared instruction and tool-description surface that adjacent teams build against. Because HRSD ships as product, customers configure, extend, and override that surface on their own instances: treat it as public API, with upgrade-safe extension points and versioning discipline to match. Build automated evaluation and test non-deterministic behavior Design and operate the evaluation that makes change safe: golden datasets, multi-turn conversation suites, model-as-judge scoring calibrated to human review, CI gates, and drift detection, plus adversarial, jailbreak, grounding, and tool-selection testing. Extend that coverage to the HR-specific failure classes — access-boundary violations in retrieval and citation, PII leakage across scopes, and jurisdictional and policy-variant correctness — and keep evaluation meaningful across customer configurations rather than against a single reference dataset. Own the resolution, containment, and quality metrics the domain is measured on, including whether they are instrumented correctly in the first place. Design conversational experiences across channels Build experiences that hold context across turns, hand off cleanly between automated and live HR agents, and behave consistently across employee-facing portals, chat shells, workplace messaging clients, agent workspace, and voice — accounting for what voice imposes: latency budgets, barge-in, speech recognition error on names and plan terminology, disambiguation, and explicit confirmation before conse