Hugging Face interview prep

Use the STAR format: describe the context and the decision you disagreed with, the specific concern you raised and how you raised it (data, an experiment, or a clear argument), the outcome, and what you would do differently. Show that you can advocate for your position while remaining constructive, and that you can commit to a decision once it has been made even when you disagree.

What a strong answer covers: The goal is to show technical judgment and professional communication, not to relitigate old grievances. Avoid framing the story as you versus them. A strong answer includes evidence you used to make your case.

Follow-up: What would you do if the team made the same decision again and the outcome was worse than you predicted?

Last reviewed 2026-10-07

Use STAR: explain the project goal, what you built, what happened, and what you did next. Own your share of the failure rather than attributing it entirely to data, compute, or other constraints. Name a specific technical mistake — a leaky split, a flawed evaluation metric, a mislabeled dataset — not a vague sense that the model was wrong. Describe what you learned and how you applied it on a subsequent project.

What a strong answer covers: A strong answer names a specific technical root cause, not bad luck or insufficient time. The retrospective action matters as much as the failure itself.

Follow-up: What would be the first thing you would investigate if you had three days to debug the same project now?

Last reviewed 2026-10-07

Compute the dot product of the two vectors divided by the product of their L2 norms. Handle the zero-norm edge case by returning 0.0 to avoid division by zero. Raise a ValueError if the vectors have different lengths.

def cosine_similarity(a: list[float], b: list[float]) -> float:
    if len(a) != len(b):
        raise ValueError("Vectors must have equal length")
    dot = sum(x * y for x, y in zip(a, b))
    norm_a = sum(x ** 2 for x in a) ** 0.5
    norm_b = sum(x ** 2 for x in b) ** 0.5
    if norm_a == 0.0 or norm_b == 0.0:
        return 0.0
    return dot / (norm_a * norm_b)

What a strong answer covers: The implementation should handle equal-length validation and the zero-norm case without importing math. Mention that floating-point precision can push results slightly outside [-1, 1] for normalised vectors.

Follow-up: How would you adapt this to compute all pairwise similarities for a matrix of N embeddings efficiently?

Last reviewed 2026-10-07

A model card describes: the intended use cases and explicitly out-of-scope uses, training data sources and known biases, evaluation metrics broken down by relevant subgroups, known limitations and failure modes, and recommendations for monitoring. It matters because downstream users make deployment decisions based on it — an incomplete card leads to misuse in contexts the model was not designed for. Include both what the model does well and where it is known to struggle.

What a strong answer covers: Subgroup-disaggregated evaluation is often the most critical section because aggregate accuracy can hide serious performance gaps on important demographics. A strong answer explains why omitting this is not just an oversight but a risk.

Follow-up: How would you keep a model card accurate and current as you retrain the model on new data?

Last reviewed 2026-10-07

Full fine-tuning updates all model weights: highest quality ceiling, highest compute and memory cost. LoRA freezes the base model and adds small trainable rank-decomposition matrices to attention layers, reducing trainable parameters by 10–100× while recovering most of the quality gain. Prompt tuning adds learnable input tokens and trains only those, but generally underperforms LoRA on complex tasks. Choose full fine-tuning when quality is critical and compute is available. Choose LoRA when you need multiple adapters on the same base model or must train efficiently at scale. Choose prompt tuning when even LoRA is too expensive.

What a strong answer covers: The three approaches form a spectrum of parameter efficiency versus quality. A significant operational advantage of LoRA is that adapters are small, composable, and easy to swap at inference time, enabling personalisation at scale.

Follow-up: How would you choose the rank hyperparameter r in LoRA for a new task with no prior experiments?

Last reviewed 2026-10-07

Common issues: benchmark contamination (training data contains benchmark examples), saturation (models already score near ceiling, leaving no signal), narrow coverage (a benchmark captures only a slice of real-world use), and metric mismatch (BLEU or accuracy does not reflect the quality users care about). Use task-specific evaluations on held-out data not in training, human preference studies for open-ended outputs, and red-teaming for safety properties. Track metrics that correspond to deployment objectives.

What a strong answer covers: Benchmark contamination is the most frequently underestimated problem: even accidental inclusion of benchmark data in pretraining can inflate scores significantly and makes fair comparison between models trained on different data very difficult.

Follow-up: How would you design an evaluation suite for a customer-support LLM that could not be gamed by training on public benchmarks?

Last reviewed 2026-10-07