Practice Interview Questions

"I'd start with a clean separation: read tools are idempotent and safe to retry — get_worker, list_open_reqs, get_payroll_calendar. Write tools never commit directly; they 'propose' — propose_job_change writes to a proposed_actions table and returns a proposal_id. The agent's loop is gather context with reads, draft a structured plan, propose actions. A human approves in a HITL UI before commit. Every tool call is logged, the audit log is the regulator's view. Idempotency keys on commit. I'd build read-MCP and write-MCP as separate processes with separate credentials so access control lives at the protocol boundary, not per-agent."

"Single-agent with many tools is my default. I decompose when sub-tasks need different models (Haiku for triage, Sonnet for drafting, Opus for cross-jurisdictional synthesis), when the system prompt is exceeding 10K tokens and most isn't relevant per call, or when different sub-tasks need different evals. Survey synthesis is a good multi-agent case: clusterer, sentiment scorer, narrative writer — each has its own eval. Onboarding is usually single-agent — one supervisor with twelve tools."

"n8n is the orchestration layer for branching, retries, approval steps, scheduling, and connector glue. Three HR-specific reasons it fits: HRKX operators can read the visual flow when I hand off; the approval nodes are first-class, which matters because HITL is the dominant pattern here; and it's self-hostable, which matters for EU PII residency. I put heavy AI logic in Python — tool definitions, prompt construction, eval harness, structured-output validation — and call it from n8n. That keeps the visual flow readable and the AI behavior testable."

"MCP is a protocol for standardized agent access to tools, resources, and prompts from external systems. In HR it lets me build one Workday read-MCP that any agent can reach — instead of every agent re-implementing Workday access. I split it: a read-MCP exposes get_worker, list_supervisory_org, schema as a resource. A write-MCP, separate process and credentials, exposes only propose_* tools that don't commit — they queue to a proposed_actions table for HITL approval. Single audit-trail discipline across all agents; access control at the protocol boundary; HRKX can compose existing servers without writing Python."

"Job Profile is the template — title, comp grade, FLSA classification, comp range; many workers can share one profile. Position is a specific slot in the org — has a position ID, lives in a supervisory organization, filled by at most one worker at a time. Job is the instance — a worker filling a position with a profile from an effective date. Position management is the configuration most mature tenants run; it's the model where reorgs and headcount planning work cleanly. A subtle point: a reorg moves the position between sup orgs, not the worker — the worker just inherits the position's new location."

"Three pieces. One: I'd start with the EIB template in the tenant — fixed column order, exact headers, mapping to the Job Change web service. Two: my agent assembles proposed_actions and emits an EIB-shaped CSV — strict Pydantic validation, snapshot-tested column shape, idempotency keys encoded into the comment field for traceability. Three: the upload runs the Job Change BP once per row, so I expect partial failure as the normal case. The agent receives the run summary, marks successes committed, fails the failures back to ops for review with the original proposal context. Critically: I never re-run the whole batch on partial failure — only the failed rows, with same idempotency keys. And I check the payroll calendar before submitting at all."

"Workday is effective-dated end-to-end. Every change creates a new version with an effective date; prior versions remain queryable. For an agent, 'what is Jane's salary?' is incomplete — it has to be 'as of what date?' Three implications: every read tool propagates an effective_date parameter, never silently defaulting to today; historical queries (headcount on 2025-12-31) require effective-dated reads, not 'current'; retro changes are real and trigger retro pay, so my agent flags any past effective date as higher-tier HITL."

"RaaS is my go-to for custom reads — define a report in Workday with the right calc fields, expose it as a service endpoint, consume from my agent. Single source of truth, the People team can edit the report without code changes. Core Connector when there's a pre-built outbound integration template that fits — benefits provider, payroll feed. Studio for complex outbound integrations needing transformation, branching, and orchestration, but Studio is typically owned by the integrations team, not the AI architect. I avoid raw web services unless RaaS doesn't fit or I need transactional reads at low latency."

"Four tiers. T1 low — pipeline summaries, draft welcome emails, scheduling. Sampled review. T2 moderate — policy Q&A drafts, survey synthesis. Approve-or-edit per output. T3 high — Workday writes, comp drafts, leave proposals. Approve-with-diff, payroll co-approval where comp/FTE moves. T4 critical — severance, equity acceleration, anything legally negotiated. Two-key approval with Legal sign-off. The tier determines HITL pattern, audit retention, model selection, eval rigor, and the approver pool. Tiering happens in a governance review before code; the artifact is a one-page proposal with data classification, named Process Owner, halt criteria, and rollback plan."

"First check: is there a DPA with the vendor and a valid transfer mechanism — Standard Contractual Clauses, an adequacy decision, or BCRs. If yes, proceed with caution and document. If no, either route to an EU-hosted endpoint or pseudonymize to remove the directly identifying fields before the call. I treat this as a Legal partnership question, not an engineering call. I flag for privacy review; I don't unilaterally decide that Article 46 mechanisms apply. Practically: I'd build the integration so the residency choice is a config flag, not a code change."

"The audit log has to be subject-searchable — every entry that referenced this worker's data, across agents and across time. My design carries an affected_subjects field on every entry, indexed for lookup. The DSAR job aggregates entries, redacts what's classified for Legal review, and produces an exportable artifact. Retention is a separate question — DSAR right to erasure runs into employment-data retention obligations. Operational data may be redacted-in-place; audit entries usually stay because retention obligation wins. Legal owns the call on what's retained vs erased; I provide the technical handle."

"It's not a refusal to ship — it's a refusal to ship the high-risk path while shipping the safe parts. Concrete example: I was asked to build an end-to-end onboarding automation that would write to Workday directly. The right answer was 'yes for everything except the Workday write — that needs HRBP approval-with-diff. Here's the phased plan that gets you 80% of the value this sprint, with the high-risk write behind a gate, and we'll revisit autonomy when the eval baseline justifies it.' Halt the risky path. Ship the safe path. Bring the stakeholders along. That's the senior move."

"Detect: alert fired or HRBP noticed. Contain: kill switch the agent, freeze in-flight writes, preserve audit logs untouched. Communicate: HRBP first, Payroll Ops second (because any pay impact escalates fast), Legal if PII or regulated. Diagnose: pull the run_id from the audit log, reproduce — was it identity confusion (two Janes), a stale Slack-handle mapping, a rehire-detection gap? Fix the immediate harm — reverse the change with Payroll's coordination, communicate to the affected worker. Then prevent: tighten the identity-anchoring code, add the named test to the eval set, update the HITL preview to surface identity more prominently. Blameless postmortem, action items tracked. The first 30 minutes are about not making it worse — halt and preserve."

"Halt and escalate. Not retry, not queue silently. Specifically: any proposed action affecting pay, comp, FTE, employment status, leaves, or worker type — within the lock window for the worker's payroll country — defaults to halt + escalate. The escalation goes to the named Process Owner and Payroll Ops with the proposed action context. They decide whether to push the effective date or process under exception. The exception path is rare and explicit, not the default. The cost of one missed automation is one missed automation; the cost of a botched payroll-window write is paid in real exceptions and lost team trust."

"This is the normal case, not the exception. Reconcile: the EIB run summary correlates back to my proposed_actions table via the proposal_id I embedded in the comment field. Mark the 47 committed, the 3 failed with their per-row Workday reason. Surface the 3 to ops on a per-row dashboard with the proposal context, not a generic 'see Workday summary.' Re-run only the 3 — with the same idempotency keys, so a partial-success retry doesn't create duplicates. For payroll-affecting failures, never auto-retry — a human owns the decision to reattempt or cancel."

"I'd build it with HRKX, not for them. Start from the last 6 months of real tickets — input question, country, the correct answer the team gave, and the policy chunk they cited. That's my gold corpus. I score on three axes: retrieval recall@k (did the right chunk surface in top-k), answer correctness (factual accuracy against reference, LLM-as-judge with rubric calibrated against human scores), and citation fidelity (every claim in the answer maps to a real chunk that supports it). Plus jurisdictional cross-talk tests — UK question never answered with US policy. PII leakage tests are zero-tolerance and run in CI."

"Can't ground-truth themes the way you can policies. Four signals. One: two-rater agreement — two humans independently theme + sentiment a sample of 100 responses; if Cohen's kappa is below ~0.7, the task isn't well-defined and neither humans nor agents can succeed. Two: agent-vs-human consensus on that calibrated sample. Three: stability — temperature 0, three runs, do clusters stabilize. Four: coverage on the long tail — 3 mentions of harassment in 500 responses must surface, regardless of cluster size. Recall on rare-but-important themes matters more than precision in HR."

"Edit rate. The percentage of HITL proposals where the human approved only after editing. It's the closest proxy to operator trust. High edit rate means the agent isn't drafting what humans want; low edit rate means I have room to consider loosening HITL. Approval/reject ratios matter too, but edit rate catches the case where 'approved' is hiding 'rewritten.'"

"Trigger: Ashby webhook on offer-accepted. Context gather (read-MCP, concurrent async): Ashby application + offer, Workday position + sup org, payroll calendar, rehire check by email+DOB hash, country policy chunks. Agent (Sonnet) drafts proposed actions: Workday hire as EIB row, Okta provisioning, equipment order, welcome email, calendar invites, benefits enrollment window. HITL gates: HRBP approves the Workday payload with diff view; Payroll Ops approves if start date within 5 business days of cutoff; IT auto-approves Okta because it's reversible. Approved proposals execute via n8n with idempotency keys. Audit log captures every step. Halt criteria: rehire match found, country not in evaluated set, schema validation fails. Process Owner: HRKX onboarding lead, named in the risk register."

"Wrong-worker termination is catastrophic; payroll-cutoff misalignment is the silent killer. For wrong-worker: anchor on Workday Worker ID, never name or Slack handle, and the HITL preview shows full identity context — name, ID, hire date, current team, country, last day. For payroll cutoff: get_payroll_calendar is one of the first tool calls; if termination effective date is within 3 business days of cutoff for the worker's payroll country, halt and escalate to Payroll Ops. Two-key approval for any pay-affecting step — HRBP plus Payroll Ops on the final pay calc, separately."

"Two layers. Stable knowledge — policy library, Workday schema, role rubrics — goes in the system prompt as prompt-cached content. Stable, version-controlled, 90% discount on cached tokens. Per-run context — the specific worker, the specific ticket, the specific application — comes via concurrent async tool calls in the agent loop. The model never sees the full warehouse; it sees what it asks for. Tool returns are typed and small. For analytics-shaped questions, the agent consumes pre-computed marts (headcount-by-org, cohort-retention) via RaaS, not raw worker dumps."

SELECT COUNT(*) AS headcount
FROM workers
WHERE hire_date <= DATE '2025-12-31'
  AND (termination_date IS NULL OR termination_date >= DATE '2025-12-31');

"I'm treating termination_date as the last day worked — inclusive of the as-of date. If your convention is termination_date = first day NOT employed, switch to strict greater-than. Either way, state your convention up front; mismatched conventions cost real headcount."

"The key encodes business intent, not just request hash. I'd take applicant_id, position_id, and a bucket of the hire_date (e.g., 7-day buckets) — then hash. Two retries of the same logical hire produce the same key; an operator nudging the start date by a day stays in the same bucket; a rehire 3 years later lands in a different bucket. The senior tell here is articulating the failure modes of naive hashing — collapsing real rehires, or splitting near-equal retries — and showing the bucket choice resolves both."

"Normalize emails, then union-find: any two emails that appear on the same record across systems get unioned. Each root is one logical worker. Then collapse with a deterministic tiebreak — prefer Workday's record as the canonical one. Edge: stronger identity dedup needs a stronger key — government-ID hash or DOB+name hash — because email-based dedup misses people who left and rejoined with a different email. I'd state the limit explicitly in the answer."

"I'm a [generalist engineer / People Engineering lead / applied AI engineer] with [N] years building software, and the last [M] focused on agentic AI. The two threads I keep coming back to are tool-use patterns and the operational craft of running systems that touch payroll and identity. The reason this role caught me is that the constraints — HITL on payroll-adjacent actions, employee PII, cross-jurisdictional privacy — force good architecture. I'd rather build AI in that environment than one where autonomous demos are the bar."

"[Your concrete story — show: the named risk you flagged, the phased alternative you proposed, the stakeholder you looped in, how the decision landed.] The pattern: I'm not refusing to ship; I'm refusing to ship the high-risk path. Show the alternative, name the risk specifically — payroll exposure, PII boundary, fairness exposure — and bring the right stakeholder in so the decision is jointly owned, not unilateral."

"[Your concrete story.] The structure that lands: the runbook I left them with, the training cadence (not 'I sent a doc' — 'I shadowed them for two cycles and answered their questions live'), and the measurable adoption signal — they later extended the workflow themselves without me writing code. That's the multiplier outcome. 'Drive adoption, not just delivery' lives in the handoff, not in the demo."

"Weeks 1-3: shadow HRKX, sit through ticket triage, payroll cycle, an onboarding cohort, an offboarding case. Read the existing Workday tenant config — BPs, calc fields, integrations. Identify the 20% of HRKX work that consumes 80% of the time. Weeks 4-6: bring two opportunities to a governance review — risk-tiered, with proposed Process Owners. Ship one T1 build for momentum. Weeks 7-10: build the one T2/T3 build with the HITL and audit posture I've described, run it in shadow against current ops, measure edit rate. Weeks 11-12: deliver the runbook and training to the Process Owner; track usage and edit rate. Output by day 90: one production agent owned by HRKX, two more in the governance pipeline, and an eval discipline I've socialized."