Banning AI in a job interview doesn't test thinking. It just hides the part that matters most.
The picture is familiar to a lot of product managers. In the interview, the hiring manager points at the laptop and says: cannot use AI. On the job, the same manager sits back with a stack of work and says: must use AI.
The contradiction is funny, but it points at something real. The interview tests how a candidate works without the tools they will be expected to use from day one. It measures a version of the job that no longer exists, and it misses the skill that now separates strong product work from average product work.
For a product manager, setting up the work around AI is the thinking. And it is the layer most product managers never make visible.
The setup is a set of product decisions
Setting up AI work is not typing. It is a series of product decisions:
Structuring the context, so the machine starts from what matters about this product, this customer and this problem.
Breaking the problem down into parts that can be handed over and parts that can't.
Deciding what the machine handles and where it stops.
Checking what comes back, and changing course when it is wrong.
That is the thinking. The interview bans it. The job never asks for it. Between the two, the most important layer of modern product work goes unseen at both ends.
Encode your judgement into the system
The people pulling ahead are not the ones using AI the most. They are the ones who encode their judgement into the system.
I am not using AI to do the work faster. I design how the work runs, and I make that visible.
The difference matters for your career as much as for the work. Output on its own looks the same whoever produced it. The setup behind it shows which calls you made, what you trusted and what you kept for yourself. The setup is where a hiring manager, or your own leader, can actually see your judgement.
This cuts both ways. A candidate who can only show polished output gives the interviewer very little to assess. A candidate who can walk through how the work was set up, and why, gives them the conversation that matters: how this person thinks when the problem is messy and the tools are fast.
Four questions that show the setup
So show the setup, not just the output. Answer these four questions.
How did I set it up? Describe the context you gave, the structure you chose and the sources you pointed it at.
What did I hand over? Name the parts of the work the machine did.
What did I keep, and why? Name the decisions you held on to, and the reason each one needed you.
What did I check, and what changed? Say what you reviewed, what was wrong, and how you changed course.
In the interview, these four answers replace the demo. At work, they sit beside the output.
Why the setup matters beyond the interview
The setup makes the work easier for a teammate or an agent to pick up. A clear record of what was handed over and what was kept means the next person does not have to guess where the judgement sat.
The output shows what was produced. The setup shows the judgement behind it.
If you want the other half of this argument, about what AI bans at university are trying to protect, Product Manager Judgement and AI at /vault/product-manager-judgement-ai covers it. And for the line between what to hand over and what to keep, see /vault/hand-over-the-task-not-the-call.
What does your AI setup look like?
