AI Engineering Interview Questions: Evaluation, Safety & Guardrails
Reviewed by Mark Dickie · Last updated
AI guardrails are validation and enforcement layers placed around a model's inputs and outputs to keep a system's behavior within defined safety and quality boundaries. Interviews in this area test whether you can design evaluation pipelines, catch failure modes before they reach users, and make principled trade-offs between over-restriction and under-restriction. You should be comfortable with both offline evaluation (benchmark datasets, human rating) and online evaluation (live traffic scoring, shadow mode). A strong candidate can articulate why a guardrail failed — not just that it did.
What does an AI Engineering interview on guardrails actually test?
Interviewers are not checking whether you have memorized a list of safety principles. They want to see how you reason when a guard is wrong in either direction: a false positive that blocks a legitimate user request, or a false negative that lets harmful content through. You will likely be asked to design a system end-to-end, justify your latency budget for an inline classifier, and explain how you measure whether an evaluation method is itself trustworthy.
The domain sits at the intersection of ML engineering, product judgment, and applied ethics. Knowing the theory is not enough — you need to have opinions about real trade-offs.
Core concepts you should know before the interview
| Concept | What it is | Why interviewers ask about it |
|---|---|---|
| Input guardrails | Filters applied before the prompt reaches the model | Prevent prompt injection, jailbreaks, PII leakage |
| Output guardrails | Checks run on the model's response before delivery | Catch hallucinations, toxicity, policy violations |
| LLM-as-judge | Using a second language model to score outputs | Fast scalable eval, but introduces its own bias |
| Retrieval-augmented eval | Grounding evaluation against a known source | Reduces hallucination scoring errors |
| Red-teaming | Structured adversarial probing of a system | Finds edge-case failures before launch |
| Harm taxonomies | Structured categories of unsafe content (e.g., OpenAI's usage policies, Meta's Llama Guard labels) | Lets you define and measure what you are guarding against |
| Latency budget | The maximum added delay a guardrail layer can introduce | Inline guards must fit; async guards can be looser |
How to structure your thinking when asked to design a guardrail system
- Define the threat model first. What are you guarding against, and who is the adversary? A children's education app has different requirements than an internal developer tool.
- Separate input and output concerns. Input filters are cheaper and catch intent-level problems; output filters catch generation-level problems. You usually need both.
- Pick your evaluation signal. Choose between rule-based checks (regex, keyword lists), classifier-based checks (fine-tuned or zero-shot), or LLM-as-judge, based on your latency and accuracy constraints.
- Set thresholds deliberately. Decide your acceptable false-positive rate before you tune. Optimizing recall without a precision floor will annoy users; optimizing precision without a recall floor will let harm through.
- Plan for drift. Adversarial users adapt. Build monitoring that alerts when refusal rates or harm-detection rates shift unexpectedly, and schedule periodic red-team exercises.
What makes LLM-as-judge evaluation tricky in practice?
LLM-as-judge is an evaluation approach where a language model scores or ranks another model's outputs, often against a rubric. It is fast and scales easily, but it carries three well-documented problems. First, the judge model can share the same biases as the model under test — if both were trained on similar data, the judge may miss the same blind spots. Second, position bias is real: when shown two outputs side by side, most judge models prefer whichever response appears first more often than chance would predict. Third, the judge's own context window and instruction-following quality limit how reliably it applies a complex rubric. Mitigation usually involves calibration against human labels, swapping response order across runs, and decomposing a complex rubric into smaller, single-criterion prompts.
Key facts
- Tarmac has 30 AI Engineering interview questions on this topic, 10 of them on this page, at difficulty 2–5 of 5.
- Tarmac last reviewed these AI Engineering interview questions on 20 July 2026.
At a glance
| Questions | 10 shown · 30 in the bank |
|---|---|
| Difficulty | 2–5 of 5 |
| Formats | True / false, Fill in the blank, Ordering, Multiple answer, Find the bug, Short answer, Flashcard, Multiple choice, Design exercise |
What you'll review
- guardrails
- prompt injection
- agent loops
Practice questions
AI Engineering/evaluation-safety/guardrails
A prompt injection attack occurs when a malicious user embeds instructions inside their input (e.g., inside a document the LLM is asked to summarize) that override or hijack the system prompt's intended behavior.#
Options
Show answer
True. Prompt injection is the attack where malicious instructions are embedded in user-supplied content (e.g., a document the model is asked to summarize), causing the model to treat those instructions as authoritative and override the legitimate system prompt. It is a key concern in LLM safety because models do not inherently distinguish between trusted instructions and data they are processing.
This statement is true. Prompt injection is precisely the attack class where adversarial content—often hidden in user-supplied data such as documents, web pages, or tool outputs—contains instructions that the model interprets as authoritative, potentially causing it to ignore safety rules, leak information, or take unintended actions.
AI Engineering/evaluation-safety/guardrails
Complete the following sentence about LLM evaluation safety frameworks:#
Show answer
Complete the following sentence about LLM evaluation safety frameworks:
"A LLM-as-a-judge judge is an LLM used to automatically score another model's outputs for quality or safety, while a red-team dataset is a curated collection of adversarial prompts used to test whether a model's guardrails can be bypassed."
The 'LLM-as-a-judge' pattern refers to using one LLM to evaluate the outputs of another for criteria like helpfulness, harmlessness, or factual accuracy—a scalable alternative to human evaluation. A 'red-team' dataset contains adversarial or boundary-pushing prompts specifically crafted to probe whether safety guardrails can be circumvented, and it is a standard tool in model safety evaluation pipelines.
AI Engineering/evaluation-safety/guardrails
Arrange the following components of a defense-in-depth LLM guardrail pipeline into the correct order of execution, from first to last.#
Put these in order
Show answer
The correct order is: (1) Input sanitization/normalization, (2) Prompt-injection/jailbreak detection, (3) LLM generation, (4) Response policy evaluation, (5) Deliver to user. Sanitizing first ensures the injection detector sees clean text; detecting attacks before generation prevents the LLM from ever processing a malicious prompt; output evaluation catches policy violations in the model's reply before it reaches the user.
The correct order of a defense-in-depth LLM guardrail pipeline is: (1) sanitize/normalize the raw input, (2) run the input through a prompt-injection / jailbreak detector, (3) pass the clean prompt to the LLM to generate a response, (4) evaluate the response for policy violations (toxicity, PII, off-topic content), and finally (5) deliver the approved response to the user. Placing the content-policy check before generation makes no sense because there is no model output yet; placing injection detection after generation leaves the model exposed to the attack.
AI Engineering/evaluation-safety/guardrails
You are building an automated evaluation pipeline that uses GPT-4 as an LLM-as-a-judge to score candidate model responses on a benchmark. Which of the following are documented, systematic biases that LLM judges exhibit and that you must account for when designing this pipeline?#
Options
Pick every one that applies.
Show answer
The three documented systematic biases are position bias (higher scores for the first-presented answer), verbosity bias (longer answers rated higher regardless of quality), and self-enhancement bias (same-family model outputs rated more favourably). These are empirically demonstrated in the MT-Bench and Chatbot Arena literature. Calibration drift from temperature sampling and sycophancy leakage are not the same phenomenon — they describe target-model behaviour, not judge-model structural bias.
LLM-as-a-judge is a popular evaluation technique, but it has well-documented systematic biases. Studies (e.g., from Zheng et al. 2023 on MT-Bench) show that GPT-4 and similar judges exhibit (1) position bias — preferring the first answer shown, (2) verbosity bias — favouring longer answers regardless of correctness, and (3) self-enhancement bias — rating outputs from models of the same family higher. Calibration drift and sycophancy are real but are properties of the target model, not the judge. The key insight for senior engineers is that using a single LLM judge without positional swapping, length normalization, or multi-judge consensus will silently skew evaluation results.
AI Engineering/evaluation-safety/guardrails
The following Python guardrail function uses the OpenAI Moderation API (SDK v1+) to block policy-violating user messages before they reach an LLM. It contains one bug that causes a runtime error on every call. Identify the buggy line.#
import openai
def moderate(user_message: str) -> str | None:
client = openai.OpenAI()
results = client.moderations.create(input=user_message)
if results[0]['flagged']:
return None # block the message
return user_message
def chat(user_message: str) -> str:
safe_message = moderate(user_message)
response = openai.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": safe_message}]
)
return response.choices[0].message.contentShow answer
The bug is on line 6.
The FIND_THE_BUG here targets a subtle but critical mistake: the moderate function calls openai.Moderation.create but then checks results[0]['flagged'] using dict-style access on a Pydantic model object returned by the newer OpenAI Python SDK (v1+). The correct attribute access is results.results[0].flagged (dot notation on the model object). Additionally, the guard short-circuits on None return but the caller never checks for None, meaning a flagged message silently disappears without raising an error or returning a meaningful response — but the primary code-level bug is the results[0]['flagged'] dict access which raises a TypeError at runtime with the v1 SDK. The buggy line is line 6.
AI Engineering/evaluation-safety/guardrails
In a production LLM application with a RAG pipeline, your security review flags two distinct failure modes:#
Show answer
A single input guardrail catches malicious user queries (prompt injection) but cannot intercept PII that the model extracts from retrieved documents and embeds in its response — the violation happens after the LLM call. Conversely, a single output guardrail can redact PII in responses but allows the injected prompt to reach the model, risking system-prompt override or data exfiltration during generation. The minimum architecture requires: (1) an input guardrail applied before the LLM call that detects prompt-injection patterns, validates query intent, and sanitises user input; and (2) an output guardrail applied after the LLM call that scans the generated response for PII (using regex, NER, or a classifier), policy violations, and hallucinated citations before returning to the user. Both layers must be independent so a bypass of one does not compromise the other.
This question tests deep knowledge of layered guardrail architecture. Input guardrails run before the LLM call to block malicious or off-topic prompts. Output guardrails run after the LLM response to catch hallucinations, PII leakage, or policy violations before delivery to the user. A correct defence-in-depth pipeline therefore needs both layers. Relying only on input guardrails misses prompt-injection-induced unsafe outputs; relying only on output guardrails still allows prompt injection to reach the model, wasting compute and risking data exfiltration. Grounding checks (RAG relevance) are an output-side concern. Rate limiting is an infrastructure concern orthogonal to content safety. A well-designed system applies: (1) input validation → (2) LLM call → (3) output validation, with each stage having independent failure modes.
AI Engineering/evaluation-safety/prompt-injection
What layers make up a realistic defense-in-depth strategy against prompt injection, since no single fix closes it?#
Show answer
No single technique is sufficient, so combine several: least-privilege tool scopes (give the model only the narrow permissions a task needs, e.g. a scoped API key, not admin credentials); privilege separation / dual-LLM patterns (isolate the component that reads untrusted content from the component that can take action); sandboxing tool execution (run code/shell tools in an isolated, resource-limited environment with no access to secrets); input filtering (heuristics or classifiers that flag likely-injected content before it reaches the model); output filtering (scan the model's response and tool calls before they're executed or rendered, e.g. block auto-fetched images or unexpected destinations); human-in-the-loop approval for high-impact or irreversible actions; and delimiting/labeling untrusted content so it's at least marked as data. Each layer is bypassable alone; together they bound the damage even when one layer fails.
Treat every individual defense as reducing probability, not proving safety — the strategy is redundancy across independent layers so that one bypassed control (a fooled classifier, an overridden system-prompt rule) doesn't translate directly into a successful attack, because a later layer (a scoped credential, a sandbox boundary, a human check) still has to be defeated too.
AI Engineering/evaluation-safety/guardrails
Anthropic's Constitutional AI (CAI) framework trains a model to be helpful, harmless, and honest without relying on human-labelled preference comparisons for harmlessness. Which sequence of steps most accurately describes the CAI training pipeline?#
Options
Show answer
The correct sequence is: the model generates a response, then critiques and revises it according to the constitutional principles (producing SL-CAI supervised fine-tuning data), then uses the model itself to generate preference labels from those revisions, and finally runs RLHF/RLAIF on those AI-generated preference pairs to update weights (RL-CAI). No human preference labels are needed for the harmlessness component; the preference signal is entirely AI-generated from the constitution.
Constitutional AI (CAI) uses a two-phase process: (1) a 'critique-revision' loop where the model critiques its own response according to a set of principles (the 'constitution') and rewrites it, and (2) RLHF/RLAIF using preference data generated from those revised outputs. The key distinction is that the preference labels in phase 2 are produced by the AI itself using the constitution, not by human labellers — hence 'AI feedback' (RLAIF). This makes it fundamentally different from standard RLHF (human-labelled preferences) and from simple output filtering (which doesn't update weights). The constitution is not a runtime prompt filter injected per-query; it is a training-time mechanism.
AI Engineering/evaluation-safety/guardrails
You are designing a LLM-as-judge evaluation pipeline to score free-form RAG answers on a 1–5 helpfulness scale. Which of the following statements about LLM-as-judge reliability are well-evidenced findings that your pipeline design must account for? Select all that apply.#
Options
Pick every one that applies.
Show answer
The well-evidenced findings are verbosity bias (judges rate longer answers higher regardless of accuracy), self-enhancement bias (same-family models favour their own outputs), and sycophancy toward assertive language (confident-sounding answers receive inflated scores). Position independence is false — position/order bias is a documented problem requiring answer-order randomisation in pairwise evals. Reference-free purity is also false — switching judge providers reduces but does not eliminate systematic bias, so calibration against human ratings remains necessary.
LLM-as-judge evaluation has several well-documented systematic biases. 'Verbosity bias' (longer answers rated higher regardless of correctness) and 'self-enhancement bias' (a model rates its own outputs higher) are both empirically confirmed. 'Position bias' is real — judges favour the first or last presented option depending on architecture, but it is NOT always 'first' universally; the direction is model-dependent and sometimes reverses, so 'always prefers the first presented answer' is too absolute. 'Calibration via chain-of-thought' has mixed evidence and is not a confirmed consistent de-biasing technique at the level the other facts are established. Stating that reference-free LLM judges are unbiased when the judging model is different from the evaluated model is false — bias persists across models.
AI Engineering/agents/agent-loops
Design the agent loop behind a support assistant that answers billing questions. It can read invoices, read the customer's plan, and issue refunds up to a limit. Runs take anywhere from 2 to 40 iterations. Cover how the loop terminates, what happens when a tool fails, how context is kept under the window, how refunds are controlled, and how you would debug a bad run a week later. State your assumptions.#
Show answer
Assume a few thousand runs a day, a refund ceiling of $200, and 30-day trace retention. Most tickets follow a handful of shapes, so I would route: a classifier sends the common ones down fixed workflows and only the tail reaches the agent, which cuts cost and shrinks the surface where things can go wrong.
The loop terminates on four conditions, not one: the model returns a final answer that passes a goal check; a cumulative token budget for the run is exhausted; a step cap fires as a backstop; or a repeated-call detector sees the same (tool, arguments) hash twice with nothing new in context. Budget is the primary control because steps are a poor proxy for cost — each iteration re-sends the transcript, so late steps cost far more than early ones. On any stop without an answer the agent hands the ticket to a human with its partial findings attached, rather than replying with something it is not sure of.
Tool failures go back into the context as tool results flagged as errors, so the model can adapt — try a different lookup, or tell the user. Retry policy is per-tool, not global: reads retry with exponential backoff, and the refund call never retries blindly, because a 5xx there is ambiguous rather than failed. Refunds carry an idempotency key so a duplicate collapses server-side.
For a 40-iteration run I pin the system prompt, tool schemas and goal, summarise older turns into a running recap once the transcript passes a threshold, clear stale tool results while keeping the calls that produced them, and keep large invoice payloads in storage behind a reference the agent re-reads on demand.
Refunds are gated in code. The loop intercepts the call before execution, verifies the amount against the invoice server-side, and requires human approval above a threshold — the model's authority is whatever the loop grants it, and the system prompt is a hint, not a control. Invoice text is untrusted: it reaches the context as data, and instructions inside it have no privilege, which is exactly why enforcement cannot live in the prompt.
Every run writes a trace keyed by run id and ticket id, one span per iteration, capturing the rendered prompt, the tool calls and arguments, results, token counts, and the stop reason. A week later I can open the ticket, find the run, and see which iteration went wrong and what the model was looking at when it did.
The main tradeoff is autonomy against friction: a lower approval threshold means fewer bad refunds and more human load. I would start conservative, measure the approval queue, and raise the threshold only against evidence.
This exercise separates people who have run an agent in production from people who have read about them. The tells are consistent. A weak answer treats max_steps as termination, wraps every tool in one retry, plans to 'use a bigger context window', and puts the refund limit in the system prompt. A strong answer knows that a step cap does not bound cost, that retry policy is a property of the tool rather than of the loop, that trimming has to pin the instructions it must never drop, and above all that a prompt instruction is not an authorization boundary — the loop executes tools, so the loop is the only place a refund limit can be enforced. The prompt-injection probe is the sharpest discriminator: any design where the model's instructions are the sole control fails it, because the invoice is attacker-influenced text arriving in the same context. The debuggability criterion is what makes the whole thing operable — without per-iteration traces tied to a run id, nobody can answer 'why did it do that' a week later, and every incident becomes a guess.
Related interview questions
The other 20 questions
This page shows 10. A free account opens the rest and marks your answers, which a page of answers can't do. Miss one and it returns a few days later, then a week after that, until you stop missing it.
Free · the whole bank · 100 graded answers per 30 days · written feedback and job-ad quizzes on the paid plan