---
title: Job Search Strategies
description: A practical way to find DevRel roles, read past inconsistent job titles, build evidence, and run a focused job search.
url: https://pr-2-5bfc5f2f5cb7.thally.app/job-search-strategies
---

# Job Search Strategies

A practical way to find DevRel roles, read past inconsistent job titles, build evidence, and run a focused job search.

Looking for a Developer Relations job can be confusing because the title does not always tell you what the job actually is.

One company hires a **Developer Advocate** to speak, write, build demos, and represent developer feedback. Another uses the same title for a role that is mostly technical content. A third might call similar work **Developer Experience Engineer**, **Developer Educator**, **Community Lead**, or **Developer Marketing**.

So do not search by title alone. **Search for the work you want to do.**

## Start with the kind of DevRel work you want

Before opening a job board, write down the work you want more of.

| If you enjoy... | Search for roles such as... | Evidence to show |
| --- | --- | --- |
| Building demos, teaching APIs, speaking | Developer Advocate, DevRel Engineer | Apps, talks, tutorials, GitHub projects |
| Writing technical education | Technical Writer, Developer Educator, Content Engineer | Articles, docs, tutorials, sample repositories |
| Improving onboarding and tooling | Developer Experience Engineer | DX audits, integrations, SDK/CLI work, docs improvements |
| Growing communities | Developer Community Manager, Community Lead | Programs, events, engagement systems, community outcomes |
| Positioning technical products | Developer Marketer, Developer Marketing | Launches, campaigns, technical content, adoption work |
| Leading the function | DevRel Lead, Head of DevRel | Strategy, measurement, cross-functional leadership, team development |

The labels overlap. Read the responsibilities, success measures, reporting line, travel expectations, technical requirements, and audience.

## Treat the job description like a specification

Do not start by rewriting your résumé.

First, turn the job description into an evidence map.

```text
Job requirement
      ↓
What skill is really being tested?
      ↓
What evidence do I already have?
      ↓
What is missing?
      ↓
Strengthen evidence or build a small project
```

For example, if the role says:

> Create technical content and demos that help developers adopt our API.

Your evidence could include:

- a tutorial that uses a real API;
- a public repository with a working integration;
- a video walkthrough;
- documentation you improved;
- adoption or engagement evidence, if you can verify it;
- lessons from developer questions after publishing.

That is stronger than simply writing "technical content" in a skills section.

## Build public proof before you need it

DevRel is unusually portfolio-friendly.

A hiring manager can often see your work before meeting you: a talk, article, GitHub repository, documentation contribution, workshop, community project, or product demo.

You do not need to become an influencer. You need enough public evidence to answer a simple question:

> **Can this person already do some version of the work we are hiring them to do?**

Good proof can include:

- two or three strong technical articles;
- one recorded talk or workshop;
- one useful open-source contribution;
- a small integration project;
- a documentation improvement with a clear before-and-after story;
- a community initiative you can explain honestly;
- a short case study showing the problem, your role, what you did, and what changed.

## Search in more than one place

Do not depend on a single job board.

Use several channels together:

- company careers pages;
- LinkedIn and other job platforms;
- DevRel communities and newsletters;
- conference and meetup networks;
- people you have worked with or learned from;
- open-source communities around products you already use;
- posts from DevRel leaders and hiring managers.

The goal is not to "network" with everyone. It is to participate where your interests and useful work are visible.

## Research the company before applying

For a developer-facing company, try the product.

Read the documentation. Install the SDK. Watch a recent talk. Join the public community if appropriate. Look at the API, examples, GitHub issues, changelog, and developer content.

Then ask:

- Who are their developers?
- What are those developers trying to build?
- Where does the product seem easy to understand?
- Where does the experience feel confusing?
- What does this DevRel role appear to own?
- How would success probably be measured?

This gives you better applications and better interview questions.

## Tailor evidence, not your identity

A tailored application does not mean becoming a different person for every company.

It means choosing the most relevant evidence.

If the role is community-heavy, lead with community work. If it is technically deep, lead with code, APIs, architecture, and technical education. If it is content-heavy, make the best writing easy to find.

A useful résumé bullet answers:

```text
What did you own?
+ What did you do?
+ Who did it help?
+ What changed?
```

Use numbers only when you can defend them.

## Keep a simple opportunity tracker

You do not need an elaborate CRM.

| Company | Role | Why it fits | Evidence to lead with | Contact / source | Stage | Next action |
| --- | --- | --- | --- | --- | --- | --- |
| ExampleCo | Developer Advocate | API education + speaking | API tutorial + workshop | Careers page | Applied | Follow up if appropriate |

This helps you notice patterns instead of repeatedly starting from zero.

## Build a weekly rhythm

A focused search is easier to sustain than random bursts of applications.

One example:

- **Research:** identify a small number of genuinely relevant roles.
- **Evidence:** improve one public artifact each week.
- **Apply:** send fewer, better-matched applications.
- **Participate:** contribute to communities where you already have something useful to add.
- **Review:** track which applications get responses and why.

If twenty applications produce no conversations, do not automatically send another hundred. Check the role fit, résumé evidence, portfolio, positioning, and application quality first.

## Evaluate the role too

An interview is not only the company evaluating you.

Ask questions such as:

- Why does this DevRel role exist now?
- Who does DevRel report to?
- Which developer audience matters most?
- What would success look like after six months?
- How much of the role is content, code, community, events, feedback, or strategy?
- How is travel handled?
- How does DevRel work with Product and Engineering?
- What happened to the person who previously owned this work?
- Which metrics does leadership care about?

A famous company with a vague DevRel mandate can be a worse fit than a smaller company that knows exactly what problem it wants you to solve.

## From the DXMentorship community

Ekemini Samuel and Joy Ndukwe's public work demonstrates one part of a strong search strategy: make your evidence inspectable before an application asks for it.

Ekemini's technical articles show product education, implementation depth, and the ability to explain emerging technology. Joy's community article and [Zencoder walkthrough](https://www.youtube.com/watch?v=m5v8K1LrUmI) show community communication and product education in written and video formats.

These artifacts do not tell us which channel produced an interview or job outcome. They show how a candidate can give a hiring team concrete work to evaluate.

Joy's final firsthand insert should document the roles she targeted, channels she used, how she positioned her experience, what she changed during the search, and what she would advise now. Employer names, response rates, and outcomes should only appear with her confirmation.

{/* CONTRIBUTOR REVIEW: Add Joy's verified job-search sequence and lessons after firsthand review. */}

## Job search checklist

- [ ] I know which kind of DevRel work I want more of.
- [ ] I search responsibilities, not only titles.
- [ ] My strongest public evidence is easy to find.
- [ ] I can map each major job requirement to evidence.
- [ ] I have tried the product before a serious interview.
- [ ] My résumé describes outcomes without exaggerating attribution.
- [ ] I use more than one discovery channel.
- [ ] I track applications and follow-ups.
- [ ] I evaluate the company's DevRel mandate, not just whether it wants me.
- [ ] I keep improving my body of work while searching.

## Further reading

- [How to get a job in DevRel](https://developerrelations.com/guides/how-to-get-a-job-in-devrel/)
- [Get hired in DevRel roundtable](https://developerrelations.com/talks/get-hired-in-devrel-roundtable/)

## Related pages

- [Interview Guide](/interview-guide)
- [Project Portfolio Examples](/project-portfolio-examples)
- [DevRel Resume](/devrel-resumes)