Support Engineering at Inngest is a unique combination of hands-on investigation, deep product knowledge, and human connection.

Inngest is solving long-standing developer problems in a novel way, which means our customers are often doing things that haven't been done before. That makes developer support not just important — it's mission-critical.

As a Support Engineer, you'll be the bridge between our product and the developers who build on top of it. You'll work directly with our customers: debugging complex issues, investigating root causes, and ensuring they get the most out of Inngest. Just as importantly, you'll feed those learnings back into the engineering and product.

This role is equal parts investigation and communication. You'll deeply understand how Inngest works under the hood, how our customers push it to its limits, and what's standing in their way.

You won't be flying solo. Our product engineers stay close to users and rotate support duties — but you'll own the L2 layer: the investigation, the customer relationship, and the handoff to engineering when something needs to go deeper or be fixed. You will also collaborate closely with the support engineers working on our L1 layer.

What you'll do

• Own escalated support from L1: investigate, reproduce, and resolve complex technical issues before they ever need to reach an engineer.

• Debug hard problems — read logs, trace execution, reproduce issues locally, and get to root cause. Use modern tools (including AI agents where helpful) to accelerate investigation.

• Write clear, well-documented Linear tickets when bugs need engineering attention: repro steps, impact, hypothesis, everything an engineer needs to jump in without context.

• Communicate directly with users throughout an investigation — setting expectations, sharing findings, and closing the loop.

• Spot patterns across tickets and bring them to product discussions — recurring issues are product signals.

• Contribute to internal debugging tooling, including APIs, dashboards, triage AI agents or similar.

• Improve internal and public-facing documentation based on what you learn every day.

Ideal candidate

• Experience in a customer-facing technical role — support engineering, solutions engineering, or similar.

• 2–4 years of software engineering experience — you've written production code and you're comfortable reading someone else's. Preferably in TypeScript or Golang.

• SQL experience and strong debugging instincts: you know how to work backwards from a symptom to a cause, and you don't give up when something doesn't reproduce cleanly.

• Outstanding written communication — you can write a crisp customer reply and a precise bug report, and those are different skills.

• Deep empathy for developers. You know what it feels like to be blocked, and you take that seriously.

• You find broken things interesting, not frustrating.

Bonus points

• Knowledge and experience with queueing systems.

• Familiarity with observability tooling (Datadog, Sentry, etc.).

• Familiarity with Postgres, ClickHouse, or similar systems.

• You've used Inngest.

What your first 90 days will look like

• First week: You'll learn how we work and dive into the product. You'll shadow the existing L1 and L2 support rotation, get access to our tooling (Plain, Linear, logs), and start building a mental model of how things break. You’ll also make at least one small, targeted contribution to the codebase to improve debuggability.

• By day 30: You'll be handling escalated tickets end-to-end — owning the investigation, the customer communication, and the handoff to engineering. You'll have filed your first real bug tickets and probably found a few things worth fixing yourself.

• By day 90: You'll have a point of view on where our biggest recurring pain points are, and you'll have brought that to the team. You'll have contributed to at least one improvement — whether that's documentation, a runbook, or a sharper view in the admin UI that makes the next investigation faster. And you'll be the person engineers trust to hand off a fully-investigated, well-scoped bug.

What we build with

• Support: Plain and Slack.

• SDKs: TypeScript, Go, Python, Kotlin

• Backend: Go, Postgres, Redis, FoundationDB, Clickhouse, PubSub/Kafka, k8s

• APIs: gRPC internally, GraphQL and REST APIs for UI

• Hosted on AWS, GCP and Bare Metal

• Github, Linear, Notion

Interview process

1. Application. Tell us about a hard bug you tracked down — what made it hard, how you approached it, what you found.

2. Screen interview. An introductory call to talk about the role, what we're building, and whether our expectations are aligned.

3. Take-home exercise. A few realistic support/debugging tickets they’d work through using our docs. You'll investigate, write up your findings, draft the customer reply.

4. Technical interview. A deeper interview with a couple of our engineers, focused on your past experience.We'll talk about how you debug, how you write code, and how you'd approach problems you'll actually face in this role.

5. Collaboration interview. A chance to meet more of the team and talk about how you work and how you'd fit into the day-to-day rhythm of a small, fast-moving team.