Intro call.
A short conversation about your background, what we are building, and whether the role is likely to be a serious fit. We will ask about agent systems you have built or modified, how you use AI-assisted development, and what kinds of context, memory, retrieval, or infrastructure problems you like owning.
The goal is to avoid wasting anyone’s time. If the shape of the work sounds wrong for you, it is better to find that out early.
Practical working session.
We will give you a realistic engineering problem and ask you to make progress on it with the tools you would naturally use, including AI coding tools. The problem may involve context selection, memory behavior, retrieval quality, environment setup, bootstrap reliability, tool access, isolation, observability, privacy-preserving artifacts, or quality automation that only becomes clear after tracing the path end to end.
Afterward, we will walk through what you changed, what you trusted, what you verified, what evidence you used, and what you would do next if this were going to production.
Team conversation.
You will meet one or more people on the team for a conversation about judgment, taste, operating style, and what kind of company we are trying to build.
This is not a trivia round. We are trying to understand whether we would trust each other with hard, underspecified work.
What we look for.
- You can get oriented in an unfamiliar codebase and identify the real state boundary quickly.
- You use AI tools aggressively, but you do not outsource judgment to them.
- You can tell the difference between a demo that works once and infrastructure that can be trusted repeatedly.
- You can reason about knowledge graphs, embeddings, retrieval, or semantic systems as production infrastructure, not research decoration.
- You verify behavior from code, state, logs, requests, or a focused repro instead of guessing.
- You can turn a one-off failure into a fixture, test, check, or runbook that improves the shared system.
- You have opinions about agent loops, harnesses, tool use, memory, context windows, and evals because you have worked with them directly.
- You can discuss isolation, durability, privacy, and operational recovery without hiding behind buzzwords.
- You explain tradeoffs without hiding uncertainty.
- You care about production behavior, not just code shape.
We expect real ownership quickly.
If we work together, the first week should not be onboarding theater. You should be able to ship something real, take responsibility for a live surface, and start improving the system you now own.
After the final conversation.
If there is a fit, we will move quickly. We are building a small team and would rather make clear decisions than stretch the process across weeks.
Before you apply, you may also want to read about what working at Tenor is like.