Remote AI developer roles: what employers screen for before the first call

"Senior AI developer" used to describe a research-adjacent specialism. It now appears on listings for ordinary product teams, which makes the market confusing: some of these roles are real, and some are a job description with a model name pasted in.

Here is how to separate them, and what actually gets you through the screening call.

Two kinds of AI role

The listings cluster into two groups.

Product integration roles. You embed models into an existing application: retrieval over the company's own data, evaluation harnesses, guardrails, cost control, latency. The hard part is engineering discipline, not model theory. Most of the open roles are this kind.

Platform and infrastructure roles. You own serving, fine-tuning pipelines, GPU scheduling, observability for inference. Fewer openings, deeper requirements, and a distinct interview loop.

If you have shipped software but never trained a model, the first group is the realistic entry point, and it is also the larger market.

The signals that survive screening

Recruiters cannot evaluate an AI portfolio, so they look for proxies. Give them the ones that hold up:

• A working demo you can explain in three sentences. What it does, what it costs per thousand requests, what happens when the model is wrong.
• An evaluation story. Anyone can wire an API call. The candidates who stand out can describe how they measured whether the output was good, and what they did when it was not.
• Cost and latency numbers. Real figures, from your own project. It is the fastest way to sound like an engineer rather than an enthusiast.
• Boring reliability work. Retries, caching, rate limits, fallbacks. This is what production AI work mostly consists of.

The question that separates candidates is rarely "what model did you use". It is "how did you know it was working".

What the listings ask for that you can start this week

Python remains the default, with TypeScript close behind for product-facing work. Familiarity with a vector store, an evaluation framework and at least one cloud's managed model service covers most requirements in the current roles. Depth in a second language matters less than being able to explain a system end to end.

Domain knowledge is undervalued. Several roles in the directory sit inside legal, security or healthcare products where knowing the domain is worth more than knowing the latest benchmark. If you are coming from one of those industries, lead with it.

The questions worth asking the employer

Before accepting, ask where the model calls actually run, who owns evaluation, and what the team does when a provider changes pricing or deprecates a model. The answers tell you whether the role is a real engineering position or an experiment someone started in a hack week and has not yet staffed.

Start with the engineering listings and read for words like retrieval, evaluation and guardrails. Those are the roles with a plan.