Rebuild the Interview: Hiring for What People Do With AI

On May 21, 2026, two days before the paper this piece draws on went to press, Elon Musk posted a hiring notice on X for SpaceXAI that read like a one-line referendum on how the rest of us hire. He wrote that SpaceX was hiring world-class engineers and physicists for SpaceXAI even with zero prior experience in AI, because smart humans figure it out fast, and added one qualifier about the candidate he wanted: if you have made a very complex thing do useful work, that is a major plus. Applicants were asked to send three bullet points demonstrating evidence of exceptional ability. He said he would read the qualifying ones himself.

Strip out the showmanship and there are three claims in that post that every CHRO should be ready to defend in the affirmative, or else explain why their own hiring loop disagrees. First, that AI domain experience is not a prerequisite, because capable engineers absorb the tooling fast. Second, that the right test of a candidate is whether they have made a complex thing do useful work, not whether they can solve a textbook puzzle on a whiteboard. Third, that the screening signal worth chasing is three bullet points of demonstrable achievement, not a resume keyword match. Most enterprise interview loops in 2026 disagree with all three.

That post landed in the middle of a rewrite. In May I presented at the Strategic Workforce Planning conference in Chicago on how organizations need to rethink their processes to match their AI ambitions. The session argued that workflows are being rewritten in front of us, that foundation models are powerful but jagged, that productivity is now coupled to AI availability, and that the realized impact of AI inside enterprises has trailed ambition for reasons that have little to do with the models themselves. Inside that argument sat six observations about the causes of the lag. One concerned the hiring bar. We argued, briefly, that companies still screen engineering candidates against a job description from 2015 by asking them to invert binary trees on whiteboards, while the actual job has moved to designing data pipelines between Workday and a data lake, defending against AI red teams, and orchestrating fleets of agents. Several people in the audience asked us to expand that point on its own. This is that expansion.

Why the interview is the highest-leverage move this quarter

Of the six observations from that session, recruitment is the one a talent function can act on immediately. Training programs take about 18 months to compound. Skills architectures take roughly 12 months to rebuild. The interview loop can be rewritten in 90 days, and the quality of every hire after that flows from it.

The change required is not a new competency framework but a reallocation of the screening hour. Algorithmic problem-solving now accounts for roughly 8% of engineering time, yet most interview loops still weigh it at more than 50%. The capabilities carrying the largest gap between what the job demands and what the interview measures are data-stack integration, AI orchestration, security under AI failure, and large-system design. Read that as a punch list; the new loop must spend its time at the top of it.

Ninety minutes, an IDE, and an agent in the room

The engineering exercise we recommend replaces the algorithmic round entirely. It runs as a 90-minute live session. The candidate has an IDE, the AI assistant of their choice, and a sandboxed copy of two real systems from your own stack.

The prompt is deliberately mundane. You are joining the platform team. Workday is our HRIS. We need a daily feed of employee data into a Snowflake-backed data lake, where downstream HR analytics jobs read it. PII must be encrypted in transit and at rest. The job must be idempotent. Late-arriving records must reconcile. The downstream team is non-technical and needs a contract. At minute 45, the interviewer announces the twist: the Workday schema just changed, one column renamed and one added. Show how your design detects, surfaces, and routes that without a 3 a.m. page.

Candidates are told they may use the assistant freely, and that how they drive it will be judged as heavily as the code. That instruction turns the exercise from a test of recall into a test of working method.

What the rubric actually scores

Six dimensions, 100 points. The weights matter more than the labels; they are what stop interviewers rewarding speed.

• System decomposition — Weight: 20% · What a strong answer looks like: Sketches the flow across HRIS, staging, and lake; identifies idempotency, retries, and a dead-letter queue unprompted.
• Data contract design — Weight: 15% · What a strong answer looks like: Asks about schema ownership, versioning, and PII boundaries; proposes a contract test before writing code.
• AI failure thinking — Weight: 20% · What a strong answer looks like: Names at least three failure modes, such as hallucinated output, rate limits, and schema drift, with an escalation path for each.
• Security posture — Weight: 15% · What a strong answer looks like: Treats encryption as the default rather than a stated requirement; raises secrets management and audit logging unprompted.
• Use of the agent — Weight: 15% · What a strong answer looks like: Drives the agent, verifies its output, catches an injected error, and explains where not to trust it.
• Communication — Weight: 15% · What a strong answer looks like: Narrates trade-offs in plain language and is willing to say, I do not know, here is how I would find out.

Give every interviewer the same short list of signals. Hire signals: asking who owns the source schema before writing any code, verifying agent output against a known case, naming what they would monitor after launch, designing an escalation path for AI failures, and asking about the cost and service-level objective of each call. Pass signals are the mirror image: writing code in the first two minutes, pasting whatever the agent generates without reading it, treating the exercise as finished when the code compiles, bluffing a confident answer with no underlying mechanism, and ignoring cost, latency, and rate limits.

The non-engineering variant matters just as much

The same principle transfers to finance, operations, HR, and service roles. Bring an agent into the room and watch how the candidate uses it, verifies it, and explains when not to trust it. The finance analyst version hands the candidate a folder of 18 vendor invoices and a copy of the procurement policy, permits any AI tool, and asks for a list of invoices to flag for review with reasons, in 45 minutes. Then comes the real question: walk me through one invoice where the AI tool told you something wrong and explain how you caught it. If they cannot find one, they design a spot-check for next month instead.

What that screens for is narrow and testable. Can the candidate decompose an ambiguous business question into a usable prompt? Do they verify output against a known reference before acting on it? Can they articulate where human judgment must stay in the loop? Do they explain trade-offs in plain language to a business stakeholder? Do they recognize their own bias and the model's bias as two separate problems?

The five moves, and what to do on Monday

Pick all five, in order. Choose two pilot roles, one engineering and one not, with an owner for each. Replace the algorithmic round with the live, AI-allowed systems exercise. Rewrite the senior rubric so that AI-failure thinking is scored rather than assumed. Reset sourcing weights toward portfolio depth and adjacent-industry experience. Then run the new loop in parallel with the old one for 60 days, so you have a comparison rather than an opinion.

• Pull the last 100 interview loops and score them against the six capabilities in the rubric. Most enterprises will land mostly red, and that scoring is the punch list.
• Name two pilot roles and two owners, and put names on the wall rather than titles.
• Pick one real integration in your own stack, a Workday-to-data-lake feed or its equivalent, and sandbox it for the exercise.
• Identify ten interviewers, half engineering and half hiring managers from the line of business.
• Book the kickoff. A workstream with no named owner by Friday will slip.

All of this changes the question the loop is built to answer. Stop asking what a candidate knows about AI. Ask what they can accomplish with an agent sitting next to them. That answer is a far better predictor of future performance than most of what we currently measure, and unlike a training program or a skills taxonomy, you can start measuring it next quarter.