ElevenLabs' two FDE listings: one wants strong Python, the other only the basics

ElevenLabs has posted two job listings with the same title, Forward Deployed Engineer, but the technical bar in each is very different. The first asks for strong Python, a grasp of software architecture and API integration. The second needs only basic Python, enough to write scripts and build demos.

Neither listing explains the difference. Read together, though, they suggest the voice AI company hires FDEs at two or more levels, which differ in both technical depth and the focus of the work.

If you are aiming for an FDE role at an AI company, both listings are worth reading closely. They help you pick the right one to apply for and prepare for what is actually assessed. Both have since been taken down from Built In: the Software Engineer version on 5 September 2025 and the Strategist version on 24 February 2026.

One title, two technical levels

The Software Engineer version describes an engineer who owns large projects end to end for ElevenLabs’ most strategic partners. This person works daily with both the customer’s engineering team and its leadership.

Anyone who has read a backend job ad will find the requirements familiar: strong Python and solid software development skills. The version posted on Working Nomads goes further, naming software architecture and API integration.

One detail is easy to miss: both versions accept customer-facing experience on a small scale, such as in a student club or a side project.

The Strategist version shifts the weight towards the customer. The person in this role meets strategic customers to understand their most important audio and voice AI needs, finds where they are struggling most, then builds demos. Python is needed only at a basic level, together with enough understanding of API integration to write scripts and build prototypes.

Aspect	FDE – Software Engineer	FDE – Strategist
Python level	Strong, plus software architecture	Basic, enough for scripts
APIs	Integrates them as a software engineer	Understands enough for prototypes and demos
Main work	Owns large projects end to end	Finds customer pain points, builds demos
Works with	Customer engineers and leadership, daily	Strategic customers
Customer experience	Accepted from student clubs, side projects	Same, but one posting asked for 3+ years

The “basic” bar does not stay put

The last row of the table deserves a slow read. A Deployment Strategist listing on Working Nomads is tagged Mid Level and asks for enough technical grounding to quickly understand the company’s voice and audio models.

Another listing for Europe, posted on Built In Dublin and taken down on 21 July 2026, asks for more than three years of customer-facing work in a technical role, along with familiarity with LLM and agent frameworks. That is a much higher bar than the “basic Python” of the earlier Strategist listing.

The lesson is not to treat a job listing as a fixed description of the role. Within the same track, requirements can rise between two rounds of hiring. If you are aiming for the Strategist track, prepare to the level of the hardest version: be able to build a small agent with a popular LLM framework yourself, not just write scripts that call an API.

Location is a requirement too

The FDE listing on Working Nomads states that the company strongly prefers candidates on the US East Coast or in Europe, naming New York, London, Warsaw and Berlin.

Read alongside the responsibilities, the reason is easy to guess. Working daily with a customer’s engineers requires plenty of overlapping hours. Picture an integration breaking at 10am in London: the customer needs someone to respond that same morning, not when you wake up.

For candidates in Asia or other distant time zones, this is worth weighing before you apply. The official careers page says visas are considered case by case, so if you are willing to relocate near those cities, say so clearly in the first round.

Case study: ask first, draw second

aced.io, an interview preparation site not affiliated with ElevenLabs, describes a five-round process. One round is an automated, timed 60-minute coding test on CodeSignal, made up of standard problem types.

Also according to aced.io, there is a case study round with diagramming in Excalidraw, where interviewers want to see you understand the customer’s needs before proposing a solution. HCL GUVI, another independent guide, gives similar advice: do not jump straight into system design; ask clarifying questions first.

Because these are third-party guides, treat them as a map for preparation rather than a process the company has confirmed. The official careers page does not mention FDE roles specifically, saying only that the process usually ends with a final round with a founder or a Bar Raiser.

Picture the case study round

Suppose the interviewer plays an insurance company that wants a voice agent to answer customer calls. A technically strong candidate will often start drawing at once: speech recognition, then a language model, then speech playback.

The diagram may be correct. But as both guides describe it, that candidate has skipped exactly the part being assessed.

A better approach is to spend the first few minutes asking questions. How many calls come in each day, and which type is most common? Which metric does leadership use to measure success: wait time, first-call resolution rate or cost per call? Which system does the agent need to read data from, and does that system have an API?

Once you have heard enough answers, then you draw, and every block on the diagram has its own reason to be there. You can explain why you chose to automate one type of call first, and why the rest stays with human staff.

That is also the daily work the listing describes: sitting with both the customer’s engineers and its leaders, each side caring about something different.

The final round asks what you did yourself

The founder or Bar Raiser round is where “my team built” will not help you much. For a role that requires owning projects end to end, the interviewer will most likely want to know which part was really yours.

Prepare two or three stories. Each should include a specific technical choice, an alternative you rejected, and why you rejected it.

Apply the same approach to your CV. A line such as “contributed to payment system integration” says very little. Rewrite it as “designed the API integration layer with the payment gateway, choosing asynchronous processing to avoid timeouts under high load”, and the reader sees both your skills and your decisions straight away.

Which listing should you apply for?

If you already write Python every day and are near the cities the company prefers, the Software Engineer version is a sensible target. Because the coding test aced.io describes is automatically graded and timed, you will need to practise speed: in that round, nobody is listening to your explanation.

If your customer-facing experience is thin, the point about student clubs and side projects is a useful hint. Pick a side project with real users, and write down what you asked them and how you changed the product after listening to them.

If you are stronger at communication than at code, the Strategist version gives you a way in. A lower technical bar does not mean skipping the technical work: you still need to write your own scripts and build your own demos rather than waiting for an engineer to do it for you.

The two listings differ in how deep the code goes, but both put the customer at the centre of the role. Whichever one you apply for, expect to be asked how well you understand the customer, not just how well you code.