One title, three jobs: reading Together AI's FDE job posts like a spec

Across Together AI’s job posts in 2026, the same Forward Deployed Engineer title leads to three jobs. The first engineer validates GPU clusters before they are handed to customers. The second selects and tunes inference engines. The third helps customers choose a post-training approach and build a data strategy.

If you skim the posts and then prepare for “FDE in general”, you can spend a month on system design and algorithm drills while the posts themselves turn on questions such as why an engine runs slowly on a particular kind of hardware.

Reading a job post is a skill in its own right. It is close to what an FDE does at a customer: take a request written in business language and translate it into measurable technical work.

Together AI’s three posts are good material for practising this skill because all three are specific, and the same way of reading works for FDE posts at any AI infrastructure company.

Three posts, three different jobs

The Strategic Inference post asks the FDE to select, configure and optimise an inference engine for each customer. It requires expert-level, hands-on experience with engines such as vLLM, TensorRT-LLM or SGLang.

The GPU Clusters post centres on infrastructure: running test suites before a cluster is handed over to a customer, and debugging low-level bottlenecks in InfiniBand networks and NVLink topologies. The post was taken down on 8 June 2026, but it remains a useful reference for understanding the infrastructure-leaning FDE variant.

According to Together AI’s product page, its clusters range from self-service ones that can be spun up immediately to deployments of thousands of GPUs. At that scale, a faulty node that slips through validation is no longer an internal matter; it becomes an incident in the customer’s system.

The Post-Training post asks the FDE to recommend the right post-training approach for each use case and to help customers build the data strategy that goes with it.

The Inference and Post-Training posts list the same US base salary range: $270,000–300,000 OTE. The pay is the same, but the work and the preparation are entirely different.

The verbs in the post are your daily work

When reading a post, look at the verbs first and the nouns second. The Inference post says the FDE selects, configures and optimises inference engines according to hardware, model architecture and workload characteristics.

One sentence, three verbs and three variables. So when preparing, practise answering this: if only one of those three variables changes, what would you tune first, and why?

The GPU Clusters post uses the verbs “design and execute” for pre-handover test suites, and names NCCL, DCGM and GPU Burn. The phrase “pre-handover” shows that this test suite is the final checkpoint before the cluster reaches the customer.

NCCL tests check communication bandwidth between GPUs through operations such as all-reduce. DCGM runs health diagnostics on each GPU. GPU Burn pushes GPUs through sustained heavy load so that faults surface before the customer hits them.

Worked example: turning the Inference post into a practice project

Imagine your customer runs a high-traffic customer-support chatbot. Every prompt is long because it carries the conversation history, while the answers are short. This is a concrete workload profile: heavy on prefill, light on decode. With a workload like this, what would you tune first?

The Inference post names three levers: tuning the KV cache, applying speculative decoding and choosing the optimal degree of tensor parallelism. The KV cache stores the keys and values of tokens already processed so they need not be recomputed, at the cost of GPU memory.

Speculative decoding lets a small model guess a few tokens ahead, so the large model only has to verify them. Tensor parallelism splits each layer’s matrices across several GPUs.

One detail stands out: the two techniques best suited to this chatbot are not named in the post.

The vLLM documentation explains that automatic prefix caching only shortens the prefill phase, and that in multi-turn conversations it lets results already computed be reused instead of reprocessing the entire chat history each time.

Prefill is the heaviest part of this workload, so turning on prefix caching is the first move.

The second move is chunked prefill. According to the vLLM documentation, this technique batches large prefills together with requests that are decoding and prioritises decode, which improves inter-token latency. With long prompts, it keeps other users from stalling mid-answer every time a heavy prompt arrives.

Speculative decoding comes later. The vLLM documentation says it mainly helps reduce inter-token latency at medium to low QPS when the workload is memory-bound. A high-traffic chatbot with short answers does not fall in that range, so enabling it first costs effort with little visible gain.

A good answer therefore looks like this: measure current time to first token and inter-token latency, enable prefix caching and measure again, add chunked prefill and measure once more, and only try speculative decoding if the numbers show decode is the real bottleneck. From there, you can turn each requirement line in the post into a preparation table:

Line in the post	Question the customer will ask	Evidence to have
Select an engine for the hardware and workload	“Should we use vLLM, SGLang or TensorRT-LLM?”	A benchmark of two engines on the same model with the same prompt set
KV cache tuning	“Why do we run out of memory when concurrent users go up?”	A throughput chart as the memory limit reserved for the cache changes
Speculative decoding	“How do we get answers out faster?”	Latency measured with the draft model on and off, stating clearly when it does not help
Tensor parallelism	“What if the model doesn’t fit on one GPU?”	A comparison of latency and throughput with the model split across different numbers of GPUs
Optimisation by workload profile	“What should my chatbot turn on first?”	TTFT and ITL measured after each step, in the order above

The third column matters most. “Used vLLM” does not prove expert-level, hands-on experience. A repo with a benchmark script, measurements and a paragraph explaining why the results came out as they did does.

Applying the same method to the other two posts

For the GPU Clusters post, the customer’s question is almost always: “Is this cluster ready?” Good evidence is a handover checklist you have written yourself, stating which tests run in which order, what thresholds count as a pass and how failures are handled.

If you have no large cluster to experiment on, renting a few GPUs for a few hours is enough to run NCCL tests and DCGM diagnostics and then explain each result. All-reduce bandwidth below expectations is a natural starting point for practising the InfiniBand and NVLink debugging the post asks for.

For the Post-Training post, two phrases stand out: “the right post-training approach for each use case” and “data strategy”. They suggest that the hard part lies more in choosing the right approach and the right data than in the model itself.

The evidence to have is one fine-tune of a small model, with an eval set built before training, a before-and-after comparison table and a short paragraph explaining why you chose that approach for that use case.

Across all three posts, the CV advice is the same. Replace “Experience with vLLM, KV cache” with a sentence giving the context, what you changed and the measured numbers before and after. A line like that shows the reader cause and effect, not a list of keywords.

Common preparation mistakes

The most common mistake is preparing for a generic variant. A candidate for the Inference role who talks only about RAG and prompts is off-topic, just as a candidate for a GPU Clusters-style role who has never read the output of an NCCL test.

The second mistake is stopping at the architecture level. If your interview answers contain only system diagrams and never get down to engine configuration, you have probably not reached the work the post describes: select, configure and optimise.

The third mistake is memorising the list of techniques in the post and applying it to every workload. The chatbot example above shows that a named technique is not necessarily the first move; interviewers want to hear you reason from the workload to the choice, with measurements.

Next time you open an FDE job post, don’t ask whether you are qualified. Ask, for each line in the post, what evidence you already have on GitHub to show.