An honest description of this role starts with what it does not have. There is no public API yet, no SDK, no launched product to demo and no developer community to convene. Hiring for this before any of that exists is deliberate, and it means the first stretch of the job is writing rather than speaking.
What you'll work on
Documentation as the primary output, owned end to end: not only written but structured, maintained, and defended against the slow rot that sets in when the system changes and the page does not. Deciding what belongs in a reference, what belongs in a guide, and what should have been an error message instead of either is an editorial job as much as a technical one.
Then the thing everybody skips: being the first person to use what we build, from the outside, with no context, and reporting honestly on how bad it is. Time from signing up to a first working call. Error messages that say what to do instead of what happened. Naming that survives contact with somebody who was not in the room. That feedback reaching engineering with enough force to change the interface is the real value of the role.
The community work comes later, when there is something to build a community around, and it will be shaped by whoever holds this seat. Talks and events are not the job in year one, and anybody who takes this expecting a conference calendar will be disappointed.
What we're looking for
Someone who writes with precision and with patience for the reader. You have explained hard technical things to developers before and you know the difference between writing that informs and writing that teaches. You can read an interface, build something real with it, and then explain the experience in a way that saves the next person an afternoon.
You code well enough to build real projects rather than toy examples, and you have worked with developer tools professionally. Background in AI or infrastructure helps, but the writing and the technical honesty matter more.
You are comfortable being early, which mostly means being comfortable writing documentation for something that will change under you and rewriting it without complaint when it does.
How to apply
Email careers@neuraphic.com with the subject line "Developer Advocate." Send a resume, a link to the best technical writing you have produced in any format, and a short note on what most developer documentation gets wrong.