## About PostHog
PostHog is your product’s context layer. It ingests and stores your analytics, errors, replays, and business data so you and your agents can query and act on it.
[We launched out of Y Combinator's W20 cohort](https://posthog.com/handbook/story). We've since shipped more than a dozen products, including:
- A suite of analytics and observability tools, including [product analytics](https://posthog.com/product-analytics), [replay vision](https://posthog.com/replay-vision), [AI observability](https://posthog.com/ai-observability), and [error tracking](https://posthog.com/error-tracking)
- [PostHog MCP](https://posthog.com/mcp) for users and their agents to query and act on their product and business data
- [Data warehouse](https://posthog.com/context-warehouse/managed-warehouse) so users can query product and customer data together using custom SQL insights.
We are:
1. **Product-led**. More than 500K organizations have installed PostHog, mostly driven by word-of-mouth. We have intensely strong product-market fit.
2. [**Default alive**](https://paulgraham.com/aord.html). Revenue is growing incredibly quickly, and we're very efficient. We raise money to push ambition and grow faster, not to keep the lights on.
3. **Well-funded.** We've raised more than $180m from some of the world's top investors. We're set up for a long, ambitious journey.
We're focused on building an awesome product for end users, hiring exceptional teammates, shipping fast, and [being as weird as possible](https://posthog.com/deskhog).
## Things we care about
- **Transparency:** Everyone can read about our roadmap, how we pay (or even let go of) people, our strategy, and how we work, in our [public company handbook](https://posthog.com/handbook). Internally, we share revenue, notes and slides from board meetings, and fundraising plans, so everyone has the context they need to make good decisions.
- **Autonomy:** We don’t tell anyone what to do. Everyone chooses what to work on next based on what's going to have the biggest impact on our customers, and what they find interesting and motivating to work on. [Engineers lead product teams](https://posthog.com/handbook/wide-company) and [make product decisions](https://posthog.com/handbook/which-products). Teams are flexible and easy to change when needed.
- **Shipping fast:** [Why not now?](https://posthog.com/handbook/values#why-not-now) We want to build a lot of products; we can't do that shipping at a normal pace. We've built the company around small teams – autonomous, highly-efficient groups of [cracked engineers](https://posthog.com/founders/cracked-manifesto) who can outship much larger companies because they own their products end-to-end.
- **Time for building:** Nothing gets shipped in a meeting. We're a natively remote company. We default to async communication – PRs \> Issues \> Slack. Tuesdays and Thursdays are [meeting-free days](https://posthog.com/handbook/company/culture#were-on-the-makers-schedule), and we prioritize heads down building time over perfect coordination. This will be the most productive job you've ever had.
- **Being weird:** Weird means redesigning an already world-class website for the 5th time. It means shipping _literally_ every product that relates to customer data. It means building an [objectively unnecessary developer toy](https://posthog.com/deskhog) with dubious shareholder value. Doing weird stuff is a competitive advantage. And it's fun.
## **Who we’re looking for**
We're looking for a Technical Support Engineer who loves helping customers and can't leave a problem alone until it's solved.
You're an engineer who happens to do support. You pick up new things fast and you're comfortable with a problem nobody has seen before. That matters more to us than your previous job title, and people on our team came to support from various backgrounds.
You care about how a customer feels when they leave the conversation, not only whether the ticket closed. You take feedback well, say when you don't know something yet, and learn from anyone on the team.
## **What you’ll be doing**
- Helping customers across all of PostHog's products, in the app and in shared Slack channels with our bigger customers
- Owning your tickets from beginning to end, and keeping customers updated along the way
- Shipping fixes to the PostHog codebase and docs when you find something broken or unclear
- Becoming the support expert for a product area: owning its queue, working closely with the engineering team behind it, and spotting the patterns that turn into fixes
- Improving how we do support, including the tooling and workflows we build on PostHog itself
- Passing customer pain points and feature requests to engineering teams with enough context for them to prioritize
### **What you won’t be doing**
❌ You won't be routing tickets, or forwarding hard questions to engineering because they look hard.
❌ You won't say "that's not my job". If you can't solve something, you find who can and make the connection.
❌ You also won't be pasting AI answers back to customers. We use AI every day, but we expect you to test things out for yourself and write a reply to the customer that's better than the one it would write. [Here's more on how we think about that](https://www.linkedin.com/pulse/stop-adding-ai-between-you-your-customers-posthog-gkxle/).
### **How we work**
You'll be the face of PostHog for many of our customers. Most of them are engineers, so they want help from someone who understands the technical detail and writes back like a person.
We want support to be part of why people choose PostHog.
We provide support across EU and US time zones, and we're hiring in both. We work in public by default, so you'll ask for help, share what you learn, and discuss problems in team channels rather than DMs.
Read more about [how the support team works](https://posthog.com/handbook/support/support-team) and [our company values](https://posthog.com/handbook/values).
## **Requirements**
- Experience in at least two programming languages, whether from a previous role, side projects, or something else
- Experience debugging unfamiliar code or systems, and checking your fix works
- Clear, concise writing that explains a complex fix without burying the customer in options
- Thorough investigations that don't slow down your reply to the customer
- Good at prioritizing and context switching across a busy queue that spans many products
_Nice to have_
- Experience supporting similar products, e.g. analytics, session replay, feature flags, experiments, or LLM observability
- A background in support, teaching, product, or another role where you explain technical things to people
_If you have a disability, please let us know if there's any way we can make the interview process better for you - we're happy to accommodate!_
_#LI-DNI_
Visa sponsorship is not available for this role.
