The Deep Dive PM Interview
Make candidates write real async requirements and defend them — a two-way test for remote PM fit
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 94%
In an all-remote org, a PM's requirements must be right the first time — there is no daily standup to clarify them in. GitLab tests for this directly: candidates pick a topic, spend an hour on a Zoom call talking it through, then write the epic, the milestone, and the minimum viable change, and defend them asynchronously against follow-up questions on the issue from a GitLab product person role-playing engineering. It doubles as a realistic job preview that lets candidates self-select out.
Origin
GitLab's PM interview process, described by CPO David DeSanto, who went through it himself as a director candidate in 2019 and initially thought it was a weird step before concluding it was the best interview experience he'd had.
Core principles
- 01In an all-remote world your requirements have to be clear — you have to get it written right the first time.
- 02Test the actual job, not a proxy for it: written async requirements under interrogation.
- 03The candidate picks the topic — this is not a way to get free requirements written for your roadmap.
- 04The interview must be two-way: it lets the candidate discover whether async PM work is for them.
- 05Use product people, not engineers, to play the engineering side — don't tax the engineering team.
How to run it
- 1
Let the candidate choose a neutral topic
The candidate can write requirements for anything. One GitLab candidate chose bicycles: 'you're going to ship a new bicycle'. Neutral topics prove the process is a skills test, not unpaid work.
Pro tip Explicitly tell candidates the topic is theirs and that you are not harvesting the output — it changes how honestly they engage.
Watch out Using a live roadmap item makes this free labour and will be read that way.
- 2
Run a one-hour talk-through call
The candidate spends roughly an hour on a Zoom call with the GitLab product person who will run the exercise with them, talking through the topic before writing anything.
- 3
Have them write the full hierarchy
The candidate writes the epic (the higher-level vision), the first milestone/iteration, and the MVC — minimum viable change — toward it. This maps to how GitLab actually plans.
Pro tip Asking for the MVC specifically exposes whether the candidate can scope down without losing the point of the work.
- 4
Interrogate it asynchronously on the issue
The GitLab-side person — always someone in product, never an engineer — asks follow-up questions on the issue, prompting the candidate to rewrite or better define parts of it. This is the actual test: can they take async clarification and improve the written artifact?
Pro tip Watch how they respond to critique of the work — this is also a live short-toes test.
Watch out Pulling engineers in to role-play burns engineering time on every candidate; keep it inside product.
- 5
Let it work as a self-selection filter
Treat candidate withdrawal as a successful outcome. Some GitLab candidates finish the deep dive and conclude the async requirements-writing job isn't for them — which is far cheaper than discovering it in month three.
In the wild
A candidate chose bicycles as their topic. They were asked: you're going to ship a new bicycle — what's the epic, the higher-level vision? What's the first milestone? What's the minimum viable change toward it? After an hour's call they wrote it up and then fielded follow-up questions on the issue.
→ GitLab could see whether the candidate could operate in a written, asynchronous product environment — using a topic with zero relationship to GitLab's roadmap.
DeSanto went through the deep dive himself when interviewing as a director. He initially thought it was a weird extra step for someone coming in at that level.
→ He finished it and called it the best interview experience he'd had. He now uses it as a standard part of GitLab's PM hiring.
Common mistakes
Using the exercise to extract free work
DeSanto explicitly notes GitLab is not using it as a way to get free requirements written. If candidates suspect otherwise, the best ones walk and the signal is destroyed.
Testing the write-up but not the async iteration
The document is only half the test. The load-bearing part is the follow-up questions on the issue and whether the candidate improves the artifact in response — because that IS the job in a remote org.
Is it for you?
Best for
Hiring managers recruiting product managers into remote-first or heavily asynchronous organizations where written requirements are the primary interface with engineering.
Not ideal for
Co-located teams with continuous verbal clarification loops, or very senior hires where the process reads as insultingly junior (though DeSanto's own experience suggests otherwise).
From the transcript
“if you're in an all remote World your requirements have to be clear”
“as part of the interview process of G lab we do what's called a deep dive interview where we have the person try that out…”
“part of the interview process so like one candidate uh their topic was they chose bicycles”
“we've had candidates who go like you know this wasn't for me”
From the episode
The GitLab way: Kindness, transparency, and short toes
David DeSanto (CPO)