I sat across from a DevRel candidate with forty thousand followers and a conference reel that made our own product demo look amateur, and I almost hired him on the strength of the stage presence alone. Three months in, I realized I'd tested for the wrong skill entirely.
Most founders interview their first DevRel hire like they're booking a keynote speaker: talk history, follower count, polish under lights. That's the wrong evaluation. At the first-hire stage, the job isn't reach — it's translation. Someone who can take what's in your head about the product and turn it into content, community, and a feedback loop that runs without you. Stage presence and that skill overlap less than you'd think.
Here are the five prompts that actually separate a good first DevRel hire from an expensive personal brand, and why each one works.
Make Them Show Their Work, Not Describe It
Ask this instead of "tell me about your DevRel philosophy": "Show me one piece of technical content you're proud of, and walk me through every step from idea to publish — including the part where you almost gave up."
What you're testing for is whether they can personally produce, not just manage a pipeline of other people's work. A generalist first hire needs to code well enough to be credible with your engineering team, write clearly enough to publish without three rounds of editing, and talk to strangers without a script. Candidates who've only ever run programs — booking other speakers, coordinating other writers — will describe process fluently and struggle the moment you ask where they personally got stuck. Getting stuck and pushing through is the actual job at headcount of one.
Listen for Whose Growth They're Optimizing For
Ask: "Tell me about the community you got the most value from being part of, and what made it work." Don't ask about DevRel communities specifically — ask about any community they've actually belonged to.
The signal isn't the answer's polish, it's where their attention goes. Candidates who talk about what the community gave its members — the people who got unstuck, the questions that got answered, the trust that built up over time — are describing the mechanics your first hire needs to replicate for your developers. Candidates who talk mostly about their own status or visibility within that community are telling you, politely, that they'll optimize your program for their own reach once they own it. That's a slower, more expensive failure mode than a bad hire who just doesn't work out, because it looks like activity the whole time.
Have Them Draw the Funnel
Give them five minutes and a blank page. Ask them to sketch how a stranger becomes a paying customer at your company, then mark every point where developer relations could plausibly touch that path.
A first DevRel hire who can't do this defaults to vanity output — talks, threads, swag runs — because they have no model for what actually moves the business and no way to defend their roadmap when someone on the leadership team asks what the function is for. The ones worth hiring will mark two or three specific, defensible touchpoints: technical content that gets found during evaluation, a community answer that prevents a support ticket, a conference conversation that starts a sales cycle. Specificity here is the whole signal. Vague answers about "brand awareness" or "developer love" mean they've never had to justify a headcount line to a board.
Put Them In Your Product, Live
Screen-share your own signup flow and have them use it in real time, narrating out loud as if they were a developer evaluating you for the first time. Then ask what they'd change and why.
This is the closest you can get to watching them do the actual job in the room. You'll see whether their technical judgment is real or borrowed — whether they notice the error message that doesn't explain itself, the docs page that assumes context a new user doesn't have, the onboarding step that exists for your team's convenience rather than the developer's. Rehearsed opinions about "great developer experience" fall apart fast against a live product; genuine instinct doesn't.
Make Them Say It Twice
Pick one real technical concept from your product. Ask them to explain it to you as a non-technical founder, then ask them to explain the identical concept as if you were a senior engineer on your team.
If the two explanations sound the same, that's the clearest disqualifying signal in this whole list. Developer relations is fundamentally an audience-adaptation job — the same person will explain your API to a hackathon beginner in the morning and defend an architecture decision to a staff engineer in the afternoon. Panels who've hired DevRel people badly, across enough interviews to have a pattern, consistently name failure to adapt the message to the room as the single most common reason a strong-sounding candidate turned into a weak hire.
Run the Whole Set Before You Post the Job
None of these five prompts requires a portfolio review, a take-home assignment, or a second interview round. Total time is under an hour, and it will tell you more than a resume, a follower count, or a conference reel ever will. Run "show me the work," "who were you optimizing for," "draw the funnel," "use the product live," and "say it twice" before you write the offer — not after you've already fallen for the stage presence.