Developer relations (DevRel)

What does a developer relations (DevRel) do?

A developer relations (DevRel) professional helps outside developers use a company's product.

The role mixes software skills with teaching, writing and speaking. Common titles include developer advocate, developer evangelist and developer experience engineer.

In Singapore, DevRel roles sit in software vendors, cloud and data companies, fintech firms and start-ups that sell APIs or developer tools. The team may report to engineering, product or marketing, depending on the company.

You work with product managers, engineers, technical writers, marketers and sales engineers. Outside the company, you work with developers, meetup organisers, universities and partner firms. You also carry developer feedback back to the product team.

What the work involves

• Write sample apps, tutorials and code snippets that show how to use the product's APIs.
• Answer developer questions in community channels, forums and issue trackers.
• Prepare and give talks, demos and workshops at meetups, conferences and company events.
• Review API documentation and report gaps or errors to the engineering and documentation teams.
• Summarise developer feedback and bring it to product meetings.
• Track simple programme numbers, such as sign-ups, first API calls and event turnout.

Pay in Singapore

Back to top

Skills a developer relations (DevRel) needs

Back to top

Developer relations (DevRel) job description

A developer advocate helps developers in Singapore build with a company's APIs and tools.

You write sample code and guides, speak at meetups and conferences, and run community events. You also take developer feedback back to product and engineering teams.

Responsibilities

• Build and maintain sample projects, quickstarts and tutorials that run on a clean machine.
• Write blog posts, guides and videos that help developers solve real problems with the product.
• Give talks, live demos and workshops to developer audiences, both in person and online.
• Run and support developer communities, including meetups, hackathons and online channels.
• Review API reference pages and OpenAPI specifications, and suggest fixes.
• Answer developer questions and route bugs to the right engineering team.
• Collect developer feedback and present it to product managers with clear examples.
• Work with marketing and sales teams on launches, campaigns and partner events.
• Set goals for the developer programme and report on progress each quarter.
• Keep up with competing tools and with changes in how developers work.

Requirements

• A diploma or degree in computer science, information technology or a related field, or equivalent hands-on experience.
• Typically 2 to 5 years in software development, solutions engineering, technical writing or a similar technical role.
• Working skill in at least one programming language, plus Git, REST APIs and OpenAPI-based documentation.
• Proven public speaking, such as meetup talks, internal demos or conference sessions.
• Clear written English, shown through published articles, tutorials or documentation.
• Willingness to travel within Singapore for events and to work some evenings.

Back to top

Developer relations (DevRel) career path

DevRel careers in Singapore often start from software engineering, technical writing or solutions roles.

Titles vary by company, and the ladder below shows common ones.

1. Junior developer advocate

   Entry

   You build samples, write tutorials and support community channels, with guidance from a senior advocate.

2. Developer advocate

   Mid

   You own content, talks and events for a product area and report developer feedback to product teams.

3. Senior developer advocate

   Senior

   You lead larger programmes, speak at major events and coach newer advocates.

4. Developer relations manager

   Lead

   You manage a team, set goals, plan budgets and agree priorities with product and marketing.

5. Head of developer relations

   Head

   You set the developer strategy for the organisation and show its effect on product adoption.

The titles are ones commonly used in Singapore; employers may name the levels differently.

Related jobs and their pay

Back to top

Developer relations (DevRel) interview questions

We wrote these questions from the skills this job needs. They are not an official question bank.

1. How would you explain API authentication with OAuth 2.0 to a developer who has never used it?

   What a good answer covers

   • Starts with the problem it solves, such as letting an app act for a user without sharing passwords
   • Contrasts API keys with access tokens
   • Walks through one flow with a working request
   • Names common mistakes, such as leaking secrets in public repositories
   • Points to the right section of the documentation

2. What does an OpenAPI specification contain, and how would you use it to improve API documentation?

   What a good answer covers

   • Lists paths, operations, parameters, request and response schemas and authentication
   • Explains that reference pages and SDKs can be generated from it
   • Suggests checking the spec in CI so docs stay in step with the code
   • Adds descriptions and examples that the generated output lacks
   • Mentions linting the spec for consistency

3. A developer opens a pull request on your sample code repository with a fix. How do you review and merge it?

   What a good answer covers

   • Thanks the contributor and checks the change fits the sample's purpose
   • Runs the code locally and runs any tests
   • Reviews style, dependencies and licence implications
   • Uses clear review comments and a branch-based workflow
   • Notes the fix in release notes or a changelog

4. How do you structure a sample app so a developer can run it within ten minutes?

   What a good answer covers

   • Keeps dependencies and setup steps to a minimum
   • Provides a README with exact commands and expected output
   • Uses an example environment file instead of real credentials
   • Tests the steps on a clean machine
   • Pins versions and updates the sample when the API changes

5. How would you use Claude Code to help build and maintain sample projects, and how do you check its output?

   What a good answer covers

   • Uses it for scaffolding, tests, refactors and updating samples after API changes
   • Gives it clear context, such as the spec and coding conventions
   • Reads every diff and runs the tests before committing
   • Checks for hard-coded secrets and unsuitable licences
   • Publishes only code that they can explain themselves

6. How do you choose between a guide, a video, a sample app or a blog post for a new API feature?

   What a good answer covers

   • Starts from the audience and what they need to do
   • Puts a quickstart and reference docs first
   • Uses video or talks for concepts that are hard to show in text
   • Reuses one piece of work across several formats
   • Checks page views, completion and developer questions afterwards

7. Which metrics would you track for a developer programme, and which would you leave out?

   What a good answer covers

   • Tracks time to first API call, active developers and return usage
   • Looks at documentation search terms and common support questions
   • Treats event attendance and social media follower counts as weak signals
   • Links programme work to product adoption where possible
   • Sets a baseline before starting a new activity

8. How do you plan a 30-minute talk that includes a live demo?

   What a good answer covers

   • Picks one clear message for the audience
   • Scripts the demo and removes anything that is not needed
   • Prepares a recorded backup in case the network fails
   • Rehearses with the venue's equipment where possible
   • Leaves time for questions

1. Developers say in your community channel that a new API version broke their apps. What do you do?

   What a good answer covers

   • Acknowledges the problem quickly and asks for examples
   • Reproduces the issue and raises it with engineering
   • Posts a clear status update and a workaround
   • Helps write or improve a migration guide
   • Follows up with the people who reported it and shares what changed

2. Your live demo fails on stage in front of 200 people. What do you do?

   What a good answer covers

   • Stays calm and says plainly what has happened
   • Switches to the recorded backup or screenshots
   • Keeps to the time and makes the main point anyway
   • Fixes the cause afterwards and shares a follow-up with attendees
   • Adds an offline rehearsal to the next preparation

3. Product wants you to promote a feature that you tested and found unreliable. How do you respond?

   What a good answer covers

   • Shares reproducible evidence instead of opinion
   • Explains the effect on developers who try it
   • Proposes a fix date or an honest label such as beta
   • Refuses to publish content that misleads developers
   • Escalates to a manager if the team cannot agree

4. You have budget for either one hackathon or a series of small meetups next quarter. How do you choose?

   What a good answer covers

   • Starts from the goal, such as new sign-ups or deeper usage
   • Compares cost, effort and follow-up for each option
   • Considers partners such as universities or local community groups
   • Plans how to keep in touch with attendees afterwards
   • Sets a measure of success before the event

1. Tell us about a time you taught a technical topic to someone who was struggling.

   What a good answer covers

   • Describes the situation and the learner's level
   • Explains how you changed your approach, such as using an example or a diagram
   • Gives the result for the learner
   • Says what you would reuse in future tutorials

2. Describe a time when feedback from developers changed a product or documentation decision.

   What a good answer covers

   • Names the feedback source and how you gathered it
   • Shows the evidence you took to the decision-makers
   • Explains how you handled disagreement
   • States what changed and how you checked the result

1. You collect names and email addresses at a meetup in Singapore. How do you handle that data under the Personal Data Protection Act (PDPA)?

   What a good answer covers

   • Tells attendees why the data is collected and gets consent
   • Collects only what the event needs
   • Gives a clear way to opt out of marketing emails
   • Stores the list securely and limits who can see it
   • Deletes the data when it is no longer needed, and checks with the company's data protection officer

Common questions about a developer relations (DevRel) job

Sources