Tools, Interviews & Hiring
You don't need to memorize tools. You need to know the categories well enough to map any company's stack onto ideas you already understand. Then you build the whole thing once yourself, and you'll have something to show.
How Dana got the offer
Dana had never held the title "evaluation engineer." What she had was one repo: an eval harness on a real public task, with a sliced dataset, deterministic scorers, and an LLM judge that corrected for position and length bias. The results came with sample sizes and a breakdown by segment. Her write-up started with a finding: the judge looked 91% accurate overall and only 58% accurate on the hardest slice, and she showed how she'd caught and fixed it.
In the interview she was asked to evaluate a chatbot. She named the quality dimensions, described a sliced dataset, chose scorers, proposed an offline gate plus online monitoring, and reported everything with a sample size. Then she opened her own dashboard to show she'd done it before.
Tools, by category
- Eval frameworks and harnesses define datasets, run tasks and score them. Open-source and vendor versions all standardize the dataset, task, scorer and report loop.
- RAG evaluation tools ship faithfulness, relevance and context metrics (Chapter 7).
- Observability and tracing platforms log every prompt, response, tool call, latency and cost, and let you sample and score production traffic. Online evals usually live here.
- Experiment tracking versions prompts, datasets and eval runs so results can be compared.
- Annotation and red-team tools provide labeling interfaces and attack suites.
Every one of these implements the four parts from Chapter 2 plus a way to track results over time. Once you understand those, switching tools is mostly a matter of reading the docs.
The broad opener, answered in three parts
The most common screening question is also the vaguest: "How do you evaluate the quality and reliability of AI systems? What tools or metrics do you use?" The interviewer wants to hear a system. Three parts cover it in about ninety seconds:
- Offline, before release. Golden datasets with normal, edge and adversarial cases. Deterministic scorers where there's an answer key, and a validated model judge where there isn't (Chapters 4 and 5). For RAG, the Triad plus retrieval recall@k (Chapter 7). A gate in CI (Chapter 11).
- Online, in production. Sampled live traffic with an online judge, implicit signals such as acceptance, edits and retries, explicit ratings, guardrail classifiers such as Llama Guard, observability through tools like LangSmith, Phoenix or Langfuse, and drift detection (Chapters 9 and 10).
- Operational. TTFT, tokens per second, cost and latency per request, utilization, and the routing trade-off between a small model and a frontier model, proven with the eval harness (Chapter 10).
"I evaluate in three places. Offline, with golden datasets, deterministic scorers and a validated LLM judge, gated in CI. Online, with sampled production traffic, user behavior signals, guardrails and drift monitoring. And operationally, with TTFT, cost and latency, so quality is always weighed against what it costs to serve." Then let the interviewer choose which part to dig into.
Assemble the whole framework
Put it all together in a minimal framework: dataset, task, scorer and report, with a mock task and mock judge producing a sliced report. Set USE_REAL_API and the same code grades real model output with a real judge. Every tool you'll meet looks like this inside.
Capstone code · runs free (mock by default)
"""Minimal eval framework: dataset -> task -> scorer -> report.
Every tool you'll meet is a version of these four parts."""
from statistics import mean
USE_REAL_API = False # free mock by default; True needs a key
DATASET = [
{"q": "refund window?", "ctx": "Returns accepted within 30 days.", "slice": "policy"},
{"q": "reset password?", "ctx": "Use the 'Forgot password' link.", "slice": "howto"},
{"q": "data export?", "ctx": "Export lives on the Settings page.", "slice": "howto"},
]
if USE_REAL_API:
import anthropic
from pydantic import BaseModel
client = anthropic.Anthropic()
class G(BaseModel):
reason: str
grounded: bool
def task(c): # 2. TASK (system under test)
r = client.messages.create(model="claude-opus-4-8", max_tokens=200,
messages=[{"role": "user", "content": f"{c['ctx']}\n\nQ: {c['q']}"}])
return next(b.text for b in r.content if b.type == "text")
def judge(ans, c): # 3. SCORER (LLM-as-judge)
r = client.messages.parse(model="claude-opus-4-8", max_tokens=200,
messages=[{"role": "user", "content":
f"Grounded in context? true/false.\nCTX:{c['ctx']}\nANS:{ans}"}],
output_format=G)
return float(r.parsed_output.grounded)
else:
def task(c): return c["ctx"] # stub: answer = the context
def judge(ans, c): return float(c["ctx"] in ans) # grounded if it quotes ctx
def report(dataset): # 4. REPORT (overall + slices)
rows = [{"slice": c["slice"], "score": judge(task(c), c)} for c in dataset] # 1. DATASET
by_slice = {s: mean(r["score"] for r in rows if r["slice"] == s)
for s in {r["slice"] for r in rows}}
return {"overall": mean(r["score"] for r in rows), "by_slice": by_slice, "n": len(rows)}
print(report(DATASET))
{'overall': 1.0, 'by_slice': {'policy': 1.0, 'howto': 1.0}, 'n': 3}
With the stub task, each answer simply repeats the context, so every answer is grounded and the report shows a perfect score. That's what should happen, and it's a useful check that the harness is wired correctly before you plug in a real model that makes mistakes. Set USE_REAL_API = True and the task and judge functions call real models while the report code stays exactly the same. Keeping the four parts separate so you can swap each one is how professional eval tools are built, and now you've built one.
Look back at what Meridian built around Remi: a sliced dataset with extra refund cases, deterministic and judge scorers with bias checks, human-labeled ground truth, trajectory scoring once Remi could act, a red-team suite, a CI gate and live monitoring. They bought the observability tooling and built the parts that encode their own idea of quality. Then they hired one evaluation engineer to own the question "how do we know Remi is good, and safe?"
Build one real project. Point the capstone at a public dataset from Hugging Face. Score a real task, handle judge position bias, report by slice, and put it on GitHub with a short write-up of what you measured, what you found and what you'd fix next. Almost no other new grad will have one.
Search broadly. Titles vary: AI Evaluation Engineer, LLM Evaluation, AI Quality Engineer, Applied AI (Evals), Model Quality, AI Test Engineer. Evaluation is also a large part of many "AI Engineer" and "Applied ML" roles that don't mention it in the title.
Lead your resume with results. Write what you built and what you measured. Recruiters skim past lists of courses. For example: "Built an LLM-as-judge eval harness with position-bias correction; measured RAG faithfulness and retrieval recall@k on a 500-case sliced dataset."
A two-week plan. In the first week, read Chapters 1 to 6 and do every lab. In the second, read Chapters 7 to 12, do every lab, and build the portfolio project. Practice the appendix questions out loud, then apply.
This field is only a few years old, so there aren't veterans with a decade of experience to compete with. A new grad who has built a harness and can talk comfortably about slices, judge bias and sample sizes is a real candidate.
Build or buy. A sensible default is to buy observability and tracing, which is plumbing you don't want to maintain, and to build your own eval sets and scorers, which encode your definition of quality. How far to go depends on how much quality and safety matter to your business. A small team with a low-stakes feature can buy an off-the-shelf tool and get back to the product. A healthcare company with sensitive outputs should build its own datasets, judges and gates and hire someone to own them. Either way, measure on your own data, and make sure someone is accountable for the number.
Who to hire. Strong evaluation engineers often come from ML, data science or search quality. The measurement habits carry over directly, and the LLM-specific parts take weeks to learn. Picture two candidates. One lists five eval tools and the newest models. The other asks what your product does, what a wrong answer looks like for your users and how you'd know quality dropped, then sketches a sliced dataset and a validated judge. Hire the second one. Tools change every quarter; turning "is it good?" into a plan you can measure is the scarce skill.
What to ask. Give candidates a real feature and ask how they'd evaluate it. Ask how they'd know a model judge is trustworthy, what they'd suspect if the offline eval says 95% while customers are unhappy, and how big an eval set should be. Then ask them to show you something they've built. Strong answers mention real data, slices, sample sizes, validating the judge against people, an offline gate and live monitoring. Weak answers stop at "I'd try some examples" or a list of vendors.
A one-page scorecard. Rate each from 1 to 3. Does the candidate think in measurements, slices and sample sizes? Do they treat a model judge as something to check? Do they start from your data and failure cases instead of a tool? Have they built an eval system? Do they connect metrics to business cost? Can they tie offline results, production signals and operating limits into one release decision? A candidate who scores high on the first four is a strong hire, however few buzzwords they use.
Quiz · Chapter 12
- What do all eval tools have in common?
- Asked "how do you trust an LLM judge?", the strongest answer starts with:
- In the capstone, what had to change to use a real model?
- What's a sensible default for building versus buying eval tooling?
- Which candidate signal matters most when hiring an evaluation engineer?