/jobs

Content Engineer

Last updated:

We're looking for a Content Engineer to make Pydantic better, not just to describe it. When a concept is hard to write down or an API is hard to show in an example, that's usually a signal the product is wrong, and we want someone who fixes both.

For an open-source developer-tools company, docs aren't collateral bolted on after the fact. They are the product surface. Pydantic Validation is imported 500M+ times a month, Pydantic AI is the fastest-growing agent framework, and Pydantic Logfire is the observability platform the AI engineering ecosystem is converging on. Each is only as good as the docs that get a developer, or their coding agent, from zero to working.

This is not a technical-writing role in the traditional sense. Prose is the cheap part now; an LLM can draft it. The value is judgment: knowing what's true, deciding what to cut, and spotting where the product itself is the problem. We want an engineer who happens to write exceptionally well, ships to the same repos as everyone else, and has strong opinions about both the tooling and the product.

This role might appeal to you if you've worked as a:

  • Content Engineer or Docs Engineer
  • Developer Experience or DevRel engineer who kept drifting toward the product and the infrastructure
  • Technical writer who taught yourself to code and started opening PRs against the thing you were documenting
  • API or SDK owner who cares more about a developer's first hour than the fiftieth feature

You want to get in early at a company with genuine product-market fit, where the leverage on great docs, and on the product feedback that comes with them, is enormous.

Most companies hire someone to document that the product is good. We want the opposite: someone whose docs are a constant, honest pressure on the product to be good, for the humans who read them and the agents that increasingly do too.

1. Make the Product Better, Not Just Documented

  • Treat friction in the docs as a bug in the product. If a concept is hard to explain or an API is hard to demonstrate, don't paper over it: file the issue, propose the API change, redesign the onboarding step
  • Get close enough to engineering to influence design while it's still soft. The cheapest time to fix a confusing interface is before it ships, and the docs are often where the confusion shows up first
  • Be the first serious user of everything we ship, and the first to say when it's confusing
  • Know what to leave out. Deciding a feature shouldn't be documented, or shouldn't exist, is as valuable as explaining it well

2. Treat Docs as an Engineering System

  • Own the docs toolchain end to end (build, structure, linting, link-checking, previews, versioning) across Python, Rust, and TypeScript repos
  • Kill drift: wire docs to code so examples are tested, references are generated from source, and nothing goes stale silently
  • Instrument the docs. We build an observability platform, so use Logfire to see where readers and agents get stuck, then turn that into product and docs changes

3. Write for Humans and Machines

  • Author and edit reference, guides, and tutorials that a developer can follow without opening a support ticket
  • Make our content first-class for agents as well as people: llms.txt, retrievable and structured content, MCP-friendly surfaces, and docs that Pydantic AI agents themselves can consume
  • Build the pipelines that keep AI-assisted and human-written content honest, using LLMs to compress and check rather than to inflate

4. Set the Standard and the Playbook

  • We're early. There is no docs-platform team and no style-guide committee. You'll define what good looks like and the lightweight system that scales it
  • Titles don't bound the work. If the best fix is a script, a CI check, a docstring refactor, or a comment in a design review, it's yours to make
  • Hold a high bar and refuse slop, yours or an LLM's. If a doc or a tool wouldn't hold up in front of a real developer, it doesn't ship
  • An engineer who writes, or a writer who ships code. You're comfortable in a codebase, reading a design doc, and opening a PR with tests. You'd rather generate a reference from source, or fix the API, than hand-maintain prose.
  • You fix what you can't explain. A confusing concept or an awkward API nags at you until it changes, and you have the standing and the taste to push that change through.
  • Native to at least one of our stacks. Python especially; Rust or TypeScript is a bonus. You can read, and change, the code you're documenting.
  • Ahead of the curve on AI and docs. You already use LLMs for authoring, retrieval, evals, and agent-consumable content, and you're clear-eyed about where they help and where they produce slop.
  • Happy to work across boundaries. You connect product, engineering, and DX and go wherever the problem is, rather than stopping at the edge of your job description.
  • Comfortable with early-stage ambiguity. We're ~25 people. Priorities shift, roadmaps change, and there's no template library. You bring structure without rigidity.

Day to day:

  • Write and edit docs across Pydantic Validation, Pydantic AI, and Logfire, shipping to the same repos as engineering
  • Turn documentation friction into product change: file the issue, propose the API, fix the onboarding, and follow it through
  • Improve the docs toolchain: builds, linting, link-checks, tested examples, generated references, preview deploys
  • Build and maintain machine-readable surfaces (llms.txt, structured content, MCP) so agents get accurate answers instead of hallucinated ones
  • Join feature work early, review design docs, and push for the simpler interface before it ships
  • Use Logfire to measure how docs and APIs perform, find where readers and agents drop off, and act on it
  • Work async with a remote team across US and UK time zones

On bigger bets:

  • Design the documentation system for a fast-growing, multi-repo, multi-language product that is open source and commercial at once
  • Own the "docs for AI agents" strategy for a company whose own framework builds those agents
  • Be a standing voice for developer experience, partnering with the founder and engineers on API design, launches, and reference architectures

What success looks like:

  • Month 2: You've shipped visible docs improvements, closed the worst of the drift, and filed the product issues the docs exposed
  • Quarter 1: Something in the product is simpler because it was hard to document, and our docs are measurably easier to land in for humans and agents
  • Quarter 2+: Engineers reach for you when they design, not just when they've shipped, and "check the docs" becomes advice we're proud to give
  1. Required: Live and work in a timezone between PT (UTC-8) and CET (UTC+1)
  2. Required: Able to travel to the EU, UK, and US a few times per year for offsites
  3. Required: Fluent in English

Pydantic Validation is the data validation library that powers modern Python development - 500 million downloads per month, used by virtually every tech company you've heard of. Why? Because we obsess over developer experience and write code we'd actually want to use ourselves.

We're applying that same engineering mindset to Pydantic Logfire, our observability platform with first class support for AI engineering, built for today's development reality: AI workloads, multi-language environments, and cloud infrastructure that's designed to be straightforward to set up and maintain.

We build with technologies developers actually want to work with:

  • OpenTelemetry for standardized instrumentation
  • SQL for intuitive querying (no proprietary query language to learn)
  • Rust, Python, and TypeScript for performance and productivity
  • Postgres, DataFusion, and object storage for scalable backends

Unlike other companies that pay lip service to open source, we commit over 20% of our engineering team to maintaining and expanding our open source ecosystem. This includes the core Pydantic Validation library and Pydantic AI - our rapidly growing framework that's becoming the standard for AI application development. We're signatories of the open source pledge and build on open standards because we believe in interoperability, not lock-in. Use our OpenTelemetry-based SDK with any compatible backend - we're confident you'll choose us on merit.

We're backed by Sequoia Capital and run a fully remote team across multiple time zones (with regular in-person offsites - next one is June 2026 in London).

Join our team of exceptional engineers who value substance over hype, practical approaches over perfectionism, and meaningful progress over busyness. We've built a culture that balances technical ambition with sustainable practices—minimal meetings and respect for your expertise and time. We're creating tools that genuinely improve developers' lives, and we're looking for thoughtful contributors who share our commitment to quality and our passion for elegant solutions.

  • 💰 Compensation: Competitive salary and stock options
  • 🌍 Truly Remote: Work from anywhere within our timezone range - no office requirements
  • 🌐 Global & Diverse: Join a multi-cultural team of 8+ nationalities
  • 💪 Impact: Direct influence on tools used by millions of developers worldwide
  • 🎯 Focus on Growth: Regular opportunities for learning and professional development
  • 🤝 Team Gatherings: Connect with the team at our regular international off-sites
  • 🏥 Healthcare: Comprehensive health coverage for you and your dependents
  • 🎮 Flexible Hours: Work when you're most productive
  • 💻 Equipment: Budget for your home office setup
  • ⚖️ Work-Life Balance: flexible working hours and 33 days PTO no matter where you live (including public holidays, which you can choose to take or not)

To apply, email careers@pydantic.dev with the job title in the subject line. We'd also appreciate a few lines explaining why you think you'd be a good fit for the role and what you've done in the past that evidences that.

No recruiters or agencies please. Unsolicited recruiters will be marked as spam.

Explore Logfire.

Sign up

Explore our open source packages

Product shot