Developer Relations Engineer
Citation is building a workspace for people who turn research into something worth reading. We bring sources, notes, drafts and references together so a writer can follow an idea from the material that inspired it to the document they share. Our work serves the everyday decisions behind a paper, an article, a report or a longer research project.
We care about the connections between those decisions. Finding a source is only useful when its details can be reviewed. An AI suggestion needs to fit the writer’s intention and remain theirs to accept or reject. A finished document should carry its references with it. We want the product to make those steps easier to understand while leaving room for the judgment that good writing requires.
As a startup, we value people who can follow a problem across disciplines and stay close to the person using the result. A clear explanation, a dependable interaction and a thoughtful technical decision all contribute to the same experience. Joining Citation means helping shape both the product and the way we build it, with care for the details and a willingness to learn from the work.
The opportunity
Citation should fit into the places where people already research and write. Our developer experience connects the product to external tools through APIs, agent connections and integrations. We are looking for a Developer Relations Engineer who can understand those interfaces deeply, build with them and help another developer reach a useful result without having to reconstruct the product from scattered clues.
This role combines engineering, technical writing and direct conversation with developers. A useful guide needs working code, a clear permission model and an explanation of what happens when a request fails. A good integration needs a reason to exist beyond demonstrating that two systems can exchange data. You will help people connect sources, documents and writing workflows in ways that respect the person whose work is involved.
You will also represent the integration experience inside the product team. A repeated setup question, an unclear error or a surprising response is evidence about the interface itself. We want someone who can distinguish a documentation gap from an API design problem, propose a practical improvement and stay involved until the path is easier to follow.
What you’ll work on
- Build and maintain complete integration examples that start with a specific user task. Show the setup, necessary permissions, a successful request and the expected result, with enough context for a developer to adapt the example to their own application.
- Improve API and agent connection documentation alongside the implementation. Keep request shapes, response examples, limits and error guidance consistent with current behavior, and verify instructions from a fresh environment instead of relying on an existing setup.
- Investigate the first experience of connecting to Citation. Follow authentication, workspace selection and the first useful action, identify where people lose confidence and work with engineering to simplify the parts that cause repeated confusion.
- Help developers troubleshoot integrations through precise questions and reproducible examples. Separate configuration issues from service behavior, protect credentials and private content, and turn a resolved issue into reusable guidance when that would help others.
- Bring developer feedback into product decisions with the relevant technical context. Explain who is affected, what they are trying to accomplish and whether the problem concerns reliability, missing capability, unclear behavior or the effort required to get started.
- Create technical articles, walkthroughs and small reference projects that teach a coherent workflow. Show how to handle pagination, retries, permissions and recovery where relevant, and avoid suggesting that a successful first request is enough for a dependable integration.
- Coordinate changes that affect existing integrations. Review developer facing release information, test important examples against the change and help the team communicate migration steps in a way that makes the required action clear.
What you’ll bring
- You have built and debugged integrations with web APIs, and you can explain the request lifecycle beyond copying a code snippet. You understand HTTP, authentication, structured data and common failure conditions well enough to investigate an unfamiliar service.
- You can write readable code in TypeScript or another language commonly used for integrations. Your examples are small enough to understand and complete enough to run, with sensible handling of configuration, errors and sensitive information.
- You have a record of making technical material easier to use. This could be documentation, developer support, tutorials, internal enablement or an open source project where people relied on your explanations to complete their work.
- You can communicate with developers at different levels of familiarity without losing precision. You know when to explain a concept, when to provide a working example and when the most useful response is a focused debugging question.
- You pay attention to permissions and the boundaries around user content. You can discuss what an integration is allowed to read or change, how access can be revoked and why a convenient example must still handle credentials carefully.
- You are comfortable owning a problem across documentation and code. You can reproduce an issue, read the relevant implementation, propose a change and work with an engineer to confirm that the explanation and behavior now agree.
Useful, but not required
- Experience with MCP, command line tools or agent integrations would help you contribute to the ways developers bring Citation into an existing AI workflow.
- Experience maintaining an SDK, a public API or an open source project would be useful when balancing a clear first experience with compatibility and the needs of existing integrations.
- An interest in research tools, document formats or reference management would help you recognize the practical tasks that make an integration valuable to a writer.
Your first few months
- Begin by connecting to Citation from a clean environment and completing a small research workflow. Record the decisions a new developer has to make, verify the documentation against actual behavior and resolve a focused set of confusing or incomplete steps.
- Build a complete reference integration around a real task, such as moving selected sources into a writing workflow. Publish clear setup and recovery guidance, review the permission model with engineering and ask another contributor to follow the instructions independently.
- Establish a maintainable way to review developer feedback and keep examples current. Identify the next important gap, explain its impact and work with the product team on an improvement that benefits both new and existing integrations.
Who you’ll work with
You will work with product and AI engineers on interface behavior, with research editors on clear technical explanations and with customer experience on the questions that recur in support. Your contribution is strongest when those conversations share a concrete reproduction and a clear description of the developer’s goal.
You will also help product and growth contributors understand what an integration can actually deliver. Keep demonstrations close to working behavior, make limitations understandable and bring feedback from external developers into decisions while there is still time to improve the experience.
What good work looks like
- A developer can follow the main integration path from setup to a useful result, understand the access they are granting and recover from the most common mistakes without guessing.
- Documentation and examples remain dependable as the product changes, and recurring integration problems lead to improvements in the underlying experience.
- The team has a clearer understanding of developer needs because your feedback connects specific technical friction to a meaningful research or writing task.
How we work
We start with a concrete user problem and choose a focused piece of work that can make it better. Important decisions should be understandable in writing, with the relevant context, tradeoffs and open questions available to the people contributing. We share unfinished work when feedback can still change the outcome and protect enough time to think, investigate and build.
Ownership includes asking for help, explaining a constraint and following through after the first version is delivered. We expect people to care about the whole experience and to challenge an assumption with evidence and consideration for the person who made it. Clear communication and dependable follow through matter more than how visible someone can make their activity.
Each working arrangement is discussed individually. We clarify responsibilities, location, availability, compensation and the practical support needed for the role before agreeing to start. You do not need to match every optional experience listed here. Show us the work you can do, the judgment behind it and the areas you are ready to learn.
Getting to know each other
1. Introduce yourself
Tell us which area interests you, how you prefer to work and where we can see a relevant example. Include your location, time zone and availability.
2. Discuss the fit
We review the introduction against the work we need to do. When there is a relevant opportunity, we arrange a conversation about your experience and the problem.
3. Explore the work
Walk through a project and explain your decisions. If a practical exercise would help, agree on its scope and expectations before it starts.
4. Agree on the details
Clarify responsibilities, working arrangement, compensation and start date together. An introduction does not require you to share confidential work or customer data.
Apply for this role
Share a technical guide, integration or developer facing project you helped create. Explain the intended audience, the task it supports and a point where people struggled. Include working code or a public walkthrough when available, and describe how feedback changed the example, documentation or interface. Remove credentials and private customer details from anything you share.