Explain your contribution and the claim's boundary

A research engineering interview often asks you to discuss a project. The interviewer needs to understand the problem, your contribution, the evidence, and what remains uncertain. A polished story without these distinctions makes it hard to assess your work. Use a specific decision and show how your implementation changed what the team could learn.

Separate engineering results from scientific results. Reducing training time under an unchanged protocol is an engineering result. Improving held-out accuracy is a model result. Demonstrating that an architectural mechanism causes the gain requires a controlled scientific comparison. One project can include all three, but they need different evidence.

Quantify with denominators and conditions. "Twice as fast" needs the workload, hardware, precision, warm-up policy, and correctness status. "One point better" needs the metric, dataset, split, and run variability. If you cannot share proprietary numbers, describe the measurement structure and use a clearly labelled normalized example. Do not invent exact figures to make the story sound stronger.

Own failures. Explain a wrong initial hypothesis and the observation that changed your view. This is useful evidence of judgment when it stays concrete. Avoid blaming another team for a vague data issue. Describe the boundary you checked, the defect you confirmed, and the prevention step that followed.

An invented project story says: "I found that padded tokens entered the loss denominator. I built a single-device reference and a two-rank fixture with unequal token counts. The old implementation averaged rank means and returned 2.25 in the fixture; the correct global token mean was 2. I changed the normalization and added the fixture. We reran the affected comparison."

This story identifies an engineering contribution and its evidence. It does not claim that the corrected method beats all alternatives. The scientific conclusion remains pending until the rerun finishes. If the correction changes published numbers, the team needs a transparent update under its publication process.

Rewrite this claim: "I made our model amazing by optimizing training and fixing the research." Use only these facts: step time fell from 100 ms to 80 ms on one GPU, reference tests passed, and final accuracy has not yet been rerun.

A strong version says that you reduced measured step time by 20%, equivalent to 1.25x throughput under the stated workload, while preserving the tested reference outputs. It states that final accuracy and time-to-quality remain unverified. Award one point each for the measured change, correct speedup interpretation, correctness scope, and explicit remaining evidence. Do not convert a step-time result into an unmeasured quality claim.

Turn a project story into statements that a reviewer can verify. The table below uses original normalized examples.

The distinction between the last two rows matters. A clear engineering contribution does not need an exaggerated scientific conclusion to be valuable. Repairing an experiment can prevent the team from drawing the wrong conclusion, even if the final comparison later shows no method improvement.

Suppose five runs were planned. Four completed with scores [80,81,80,82]; one diverged after two hours. A slide showing only the mean of completed runs, 80.75, omits stability information. The mean can be reported as a completed-run statistic if labelled, but the planned study also had one failure in five attempts. A method-level claim should state how failures enter the evaluation and avoid silently conditioning on success.

1run R5:2planned seed: 473status: diverged4last completed update: 8125cost: 2 GPU-hours6observed issue: gradient norm became non-finite7confirmed cause: unresolved8reporting treatment: retained as a failed planned attempt9follow-up: inspect saved finite-input and gradient trace

This record does not call the failure an infrastructure outage without evidence. If logs later confirm an unrelated hardware interruption, record that finding and apply the stated retry rule. Preserve the original attempt and retry link instead of overwriting history. The audit trail lets a reviewer distinguish technical failure, method instability, and outcome-based exclusion.

An optimization reduces median step duration from 200 ms to 160 ms under a fixed workload. The measurement contains one hundred completed steps after ten warm-up steps, on the same hardware. The candidate uses twenty percent more peak memory. Full training quality has not been rerun.

A supported summary says measured median step duration fell twenty percent, corresponding to 1.25 times reciprocal median-step throughput under these conditions, while peak memory rose twenty percent. Do not equate reciprocal median duration automatically with measured aggregate throughput if step distributions differ; report the actual total completed steps over elapsed time for a throughput claim. Quality and time-to-quality remain unverified. Award one point for time reduction, one for ratio, one for the aggregation caveat, and two for memory and quality limits.

This is a deliberately more careful version of the earlier simple constant-step example. It shows how adding a distribution changes the claim. Median, mean, p95, and total elapsed time are not interchangeable summaries.

“Mentioning limits weakens the story” fails because unsupported claims reduce the credibility of otherwise strong work. A precise limit shows what the experiment established. “The team shipped it, so every scientific claim is proven” confuses a product decision with controlled evidence about a mechanism. Shipping may balance quality, cost, latency, and operational constraints without isolating each cause.

For personal ownership, use specific verbs: implemented, measured, reviewed, proposed, or operated. Name collaborators' roles when relevant without attributing their work to yourself. If the interviewer changes the requirement, update the conclusion rather than defending the original decision blindly. A speed gain that costs too much memory may be unsuitable under the new resource limit, even though the original timing measurement remains true.

The packet ends with unresolved questions and the next evidence needed. This is not a generic disclaimer. Each question should connect to a concrete action: rerun the fixed quality protocol, test the maximum shape, resolve the failed-run cause, or isolate the proposed mechanism with a matched control.

Original practice: What part of this research result was yours? A strong answer names implemented components, decisions, tests, and collaboration boundaries. Follow up with the strongest unsupported claim in the story. A weak answer uses team-level success to imply personal ownership of every result.