Evaluate Developer Relations (DevRel) Strategist candidates across 4 weighted areas: campaigns that performed, measurement and testing, audience and segmentation, and working with the business. Campaigns that performed leads at 30%, so ask which developer programs they ran end to end: hackathons, SDK launches, docs overhauls, conference CFP pushes. Look for adoption numbers. Use the rubric to compare role-specific evidence consistently.
For campaigns that performed, look for evidence the candidate names specific launches with before and after figures, for example cutting time-to-first-successful-call from days to under 20 minutes. For measurement and testing, look for evidence the candidate distinguishes vanity signals (stars, event headcount) from activation and retention data, and cites a program they killed on evidence.
Apply the written 1–5 anchors to every answer, record the evidence behind each rating, and use the factor weights to reach a consistent overall assessment.
Complete evaluation framework
What to assess and how to score it
Review the evidence signals before interviewing. Then use the anchored descriptions—not instinct alone—to choose the score that best matches each answer.
01
Evaluation factor
Campaigns that performed
30% weight
Ask which developer programs they ran end to end: hackathons, SDK launches, docs overhauls, conference CFP pushes. Look for adoption numbers like signups, npm installs, or active API keys.
Evidence to listen for
Names campaigns or programmes they ran, with the metric they moved and the baseline it moved from
Distinguishes their own work from the team's or the agency's
Knows the audience and the offer, not just the channel
Can describe a campaign that failed and why
Five-point scoring guide
1
Poor
No numbers; describes activity rather than results.
2
Needs Improvement
Vanity metrics only; attribution to their own work is unclear.
3
Satisfactory
Real campaigns with some numbers; baselines often missing.
4
Very Good
Named campaigns with metric, baseline, and clear personal ownership.
5
Excellent
Names specific launches with before and after figures, for example cutting time-to-first-successful-call from days to under 20 minutes.
02
Evaluation factor
Audience and segmentation
25% weight
Probe how they segment developers: hobbyists versus platform teams, JavaScript versus Go users, evaluators versus production integrators. Check whether messaging and content changed per segment.
Evidence to listen for
Describes real customer segments and what differs between them, not demographic guesses
Has built lifecycle stages, journeys, or nurture logic that reflect actual behaviour
Knows where the audience data comes from and its limits
Writes for the segment rather than for everyone
Five-point scoring guide
1
Poor
One message for everyone; no segmentation thinking.
2
Needs Improvement
Segments by demographics only; no behavioural insight.
3
Satisfactory
Workable segmentation; lifecycle logic is basic.
4
Very Good
Behaviour-driven segmentation and lifecycle design with evidence behind it.
5
Excellent
Maps distinct developer personas to concrete artefacts: quickstarts for evaluators, reference architectures and migration guides for enterprise integrators.
03
Evaluation factor
Measurement and testing
30% weight
Test their metrics stack: Orbit or funnel models, docs analytics, GitHub and Discord activity, DevRel qualified leads, retention of integrated accounts. Ask what they stopped doing after seeing data.
Evidence to listen for
Tests deliberately rather than changing everything at once
Understands attribution limits and does not overclaim
Knows what sample size and duration a test needed
Can name a test whose result contradicted what they expected
Five-point scoring guide
1
Poor
No testing; claims credit for correlation.
2
Needs Improvement
Runs tests but reads them badly; overclaims attribution.
3
Satisfactory
Tests sensibly; rigour drops under deadline pressure.
4
Very Good
Disciplined testing with honest attribution and a result that surprised them.
5
Excellent
Distinguishes vanity signals (stars, event headcount) from activation and retention data, and cites a program they killed on evidence.
04
Evaluation factor
Working with the business
15% weight
Assess how they worked with product, engineering, and sales: feeding API feedback into roadmaps, sourcing engineers as speakers, defending DevRel budget without pure lead-gen framing.
Evidence to listen for
Works with sales, product, or operations rather than throwing campaigns over a wall
Briefs designers and writers well enough to get usable work
Manages agencies or freelancers to a standard
Reports results to leadership without spin
Five-point scoring guide
1
Poor
Works in isolation; reports only flattering numbers.
2
Needs Improvement
Limited coordination; briefs are thin.
3
Satisfactory
Coordinates adequately; reporting is honest if basic.
4
Very Good
Strong partner to sales and product; briefs and reports clearly.
5
Excellent
Describes a documented feedback loop that changed a product decision, plus a credible budget case made to executives.
Evidence-led prompts
Interview questions for a Developer Relations (DevRel) Strategist
Use these prompts to surface evidence for the weighted factors above and compare candidates against the same role-specific criteria.
01
What experience do you have building and nurturing developer communities?
02
Can you describe a successful developer relations strategy you have implemented?
03
Describe your experience organising developer events, online and in person.
04
How do you approach content creation for developer audiences?
05
What tactics do you use to engage developers at different stages?
