A résumé can make this hire look easier than it is. When a candidate says forward-deployed engineer, I still need to know what they actually carried into an operating environment.
The stack on paper can look uniform. An engineer who shipped an integration, a solutions architect, and a consultant with a cloud certification may describe different work in the same words. The words needn't be dishonest to make the screen unhelpful.
So I've been paying attention to what the people who helped establish this role say about hiring for it. In an a16z Show conversation published on January 29, 2026, Palantir chief architect Akshay Krishnaswamy and a16z's Erin Price-Wright discuss how forward-deployed engineering shapes hiring and product development. The conversation is useful because it keeps the work in view, including the difficulty of building around a customer's actual problem. My question coming out of it is how much of that work an interview actually lets us see.
I'd add something from my own side of the table, because from the CIO chair I made this hiring call more than once, and I was wrong about people in both directions too. The trait I underestimated most is the willingness to be told your design is wrong by somebody with less authority and more context, in front of a client, and to change it that afternoon. Enterprise engineering selects fairly hard against that. It rewards being right in advance, and this work rewards being corrected quickly.
None of which is a reason to give up and hire on instinct.
Our answer at LockedIn Labs starts with a question I ask everybody, which is: show me your portfolio, not certifications or framework slides, but something you carried into production. Enterprise engineers usually can't show the code, and they were never being asked to. Name the systems, say what your hands did on them, and describe how the thing shipped. Keep confidential material out of the conversation and use only details you're authorized to share.
But a portfolio has the same limitation the résumé does, just further along. It tells you what happened once. It doesn't tell you what the person does when the context changes. If you're still learning and haven't shipped into production, say that plainly. A practice record gives us something to discuss without pretending it was customer work.
Here's the field in miniature that I want to see. Give the person a fictional warehouse and an assistant that answers dispatch questions from a supplied procedure. The first design retrieves a matching product code, quotes the instruction, and prepares a dispatch recommendation. Ask them to explain why that design is reasonable and write down what they're assuming before they improve it.
Then let the operator add the fact the brief left out. The same product code exists at two sites, but one site's customer contract requires an additional release check. The shared procedure doesn't record that exception. A correct-looking answer could send the wrong goods out of the door.
Now watch the next decision. Does the person ask who owns the exception and which source establishes it? Do they narrow the assistant's scope while that answer is missing? Can they explain why adding a more confident instruction to the prompt doesn't resolve an unknown operating rule? The operator should challenge the design respectfully and answer the questions the exercise has prepared. We're observing how someone uses new context, not how much mistreatment they'll tolerate.
Let them revise the design. It might now require the site identity before retrieval, separate shared guidance from local release authority, and stop short of recommending dispatch when those sources conflict. Have them retain the original version, the operator's correction, the new decision, and a case that would have passed before the correction but should now be refused. A person can draw the workflow and explain its checks before they have the coding skills to implement it. A developer can make those checks executable.
Keep the assistance in the record. If an AI assistant proposed the site boundary, record that contribution and ask the person to explain and test it. If the interviewer supplied a hint, retain the hint. A polished final answer without that history makes it impossible to distinguish the person's judgment from the help they received. Agree the available tools, time allowance, and accessibility arrangements in advance, and preserve changes to those conditions with the work.
Then change the task again. At a third fictional site, the release rule is clear but the stock feed is stale. Ask the person to handle that case without handing them the earlier solution. Reusing the same site filter won't repair the missing evidence. The useful observation is whether they find the new constraint, identify what can still be done, and explain who needs to decide what happens next. Keep their first response as well as their correction.
This is a proposed practice exercise, not a validated hiring instrument or a report of a benchmark run. Our public benchmark methodology is still a draft. The AI skills practice check helps people find a learning direction; it doesn't issue an official readiness rating. You can use the exercise above to make feedback more specific without turning it into a league table.
I'd rather tell you the boundary than have you find it. A score from this exercise cannot establish how someone will perform with a real customer, how they compare with people given different help, or whether they are ready for an unsupervised production engagement. It cannot make an individual responsible for a team's work. Even a strong transferred attempt is evidence about that attempt, under recorded conditions. Predicting job performance would require a separate validation study.
What a structured record does is narrower and still worth a great deal. You can point to the design that changed, the fact that changed it, and the reasoning the person could explain. You can give them a next assignment that addresses the gap you actually saw. That's a more useful conversation than asking them to defend the title on their résumé.
The training follows from there. In Show Me Your Portfolio, I develop the record a learner can build and discuss. The AI delivery readiness guide supplies broader starting paths. This exercise adds one demand to that preparation: let somebody with better context change your work, then show what you understood well enough to carry into a different task.
For a company choosing how to organize AI implementation, I make the wider argument in Everyone Has the Models. The delivery question continues in Faster at the Wrong Thing: speed only helps after the work is worth doing. These are companion essays across the LockedIn Labs portfolio, not independent endorsements of this benchmark.
And if you're the engineer reading this rather than the person hiring one, the path is the same one it's always been, which is why I find it encouraging rather than gatekeeping. Start with work you can explain, let the next constraint expose what you missed, and keep going until somebody else can depend on what you've built. The title is going to keep getting cheaper. That part never does.
Written September 6, 2026. Adapted for this public-draft field note and first published September 9, 2026. By Sam M. Sweilem, Founder & CEO of LockedIn Labs.
Source: a16z Show, How Palantir Scaled: Why the Best Software Is Built Backwards, Akshay Krishnaswamy with Erin Price-Wright, January 29, 2026; source identity and publication date checked September 9, 2026. The proposed exercise and its interpretation are ours. Palantir and a16z have not endorsed or reviewed this methodology.
AI-assisted source checking, editorial adaptation, and software production were used.