FDEBench Join us live

Q
15 / 159

Serving & inference

How would you design a GenAI system that rewrites a user's resume based on a job description with a latency of under 2 seconds?

question bank FDEBench bank Source

01
Ask

What a strong candidate asks first

Before designing anything. Skipping this is the most common way the round is lost.

  • Is 2s to first token, or 2s to the complete rewritten resume?
  • Is that p50 or p99?
  • Is the resume already uploaded, or does it arrive with the request?

02
Rubric

What earns the points

7 criteria, 100 points total. Scored independently, partial credit allowed.

Splits the 2 seconds by stage 25 pts

Explicitly divides the 2s across stages and names roughly what each gets — parse, retrieve/embed, generate, network. Any breakdown that leaves headroom counts; the numbers do not have to match ours. Full credit requires them to notice generation is the dominant term.

If you miss it You never decomposed the 2s budget. A latency target is the entire question here — before designing anything, say what each stage is allowed to spend and where the headroom is.
First token vs finished answer 15 pts

Distinguishes time-to-first-token from total completion, either by asking which the 2s refers to or by designing for perceived latency via streaming.

If you miss it You treated 2s as a single number. With a generative system, time to first token and time to completion are different problems with different solutions — establish which one you're being held to.
Parses the resume at upload 15 pts

Moves resume parsing out of the request path — pre-parsed at upload, cached structured form, or any equivalent amortization. Parsing the JD in parallel with the resume also earns partial credit.

If you miss it You parsed the resume inside the 2s window. That work is identical on every request for the same user — do it once at upload and store the structured form.
Picks a model fast enough 15 pts

Picks the model against the latency budget rather than by capability alone — a small/distilled/fast-tier model, or a large model justified by measured latency. Naming a specific model is not required.

If you miss it You chose a model without connecting it to the budget. Model selection is a latency decision here, not just a quality one.
Rewrites sections in parallel 10 pts

Splits the rewrite into independently generatable units (sections, bullets) that run concurrently, or gives a defensible reason not to.

If you miss it You generated the resume as one sequential call. Sections are largely independent — rewriting them in parallel cuts wall-clock time substantially.
Caches what actually repeats 10 pts

Proposes caching AND says what the key is and why it would hit. Bare "add a cache" earns nothing — resume+JD pairs are near-unique, so credit requires caching at a level that actually repeats (JD-derived signals, per-section, embeddings).

If you miss it You added a cache without saying what the key is. Resume-and-JD pairs are almost never repeated — a naive cache here has a hit rate near zero. Cache the reusable sub-parts instead.
Falls back when time runs out 10 pts

Says what ships when the budget is blown — partial result, template fallback, or a queued async completion.

If you miss it You didn't say what happens when a request exceeds 2s. Under a hard latency SLO, the degradation path is part of the design.

03
Flags

Red flags

Reported separately, not subtracted — this is the "what would have ended the interview" note.

  • Chains multiple LLM calls sequentially inside a 2s budget.
  • Never mentions network or TTFB at all.
  • Proposes a multi-agent architecture for a single-shot rewrite.

—