Customer Support Engineer

What You'll Do

• Triage incoming customer issues across our Dashboard, email, Slack Connect, and Discord. Be the first technical responder during US hours.
• Reproduce reported bugs against the E2B SDK and sandbox runtime. Capture the failing input, isolate the variable that breaks, and document repro steps before escalating.
• Read logs and traces. Pull sandbox logs, parse SDK telemetry, and correlate with platform metrics to figure out where in the stack a problem actually lives.
• Write fixes for documentation, examples, and SDK error messages. When a customer hits a confusing failure mode, the doc gets clearer the same week.
• Own the docs site. Keep our documentation accurate as the product evolves. Land changes alongside engineering releases, not weeks after.
• Escalate cleanly. When an issue is genuinely product, hand off to engineering with a complete repro, suspected root cause, and customer impact summary. No throw-it-over-the-wall tickets.
• Catch patterns. If three customers hit the same edge case in a week, that's a product signal. Surface it in the engineering and product channels with data and evidence.
• Build internal tooling for support. Scripts, dashboards, runbooks. If something is repeatable, automate it.

What We're Looking For

• 2+ years in a technical support, customer engineering, or developer support role at a cloud, PaaS, or DevTools company.
• Strong Linux fluency. You're comfortable on a shell, can read systemd logs, follow tcpdump output, and reason about networking (DNS, routing, firewalls, proxies) without Googling every command.
• Comfortable in Python and TypeScript. You don't need to be shipping production features, but you should be able to read the SDKs, write a 50-line reproduction script, and patch a doc example.
• Strong written communication. Most customer interactions are async and text-only. You write tight, scannable, technically precise replies.
• Documentation instincts. You've owned or maintained public docs before, or you've left a clear paper trail in internal wikis or runbooks. You see undocumented behavior as a bug.
• Calm under pressure. Production incidents, angry enterprise customers, and ambiguous repros don't rattle you.
• Excited to work in person from San Francisco.

Nice-to-Have

• Experience supporting an SDK or API product with usage-based pricing. The mechanics of metering, quotas, and rate limits come up constantly.
• Familiarity with virtualization or container isolation models. Knowing why "my container can't see /dev/loop0" is interesting helps a lot.
• Past contributions to open-source projects, especially in the developer-tools or AI agent ecosystem.
• Experience using AI agent frameworks (LangChain, CrewAI, Vercel AI SDK) on the building side, not just supporting them.
• Prior work supporting customers running in BYOC or on-prem deployments.