Braintrust AIR Interview: Prepare Technical Examples for Adaptive Follow-Up Questions

An invitation to a Braintrust AIR interview calls for more than a polished project introduction. A technical claim can become the next question: why did you choose that design, what did you personally implement, and what evidence supports the result? Prepare a project you understand well enough to expand, qualify, and correct in conversation.

For an adaptive interview, build an answer around evidence you can explain under follow-up. This guide separates current official descriptions from candidate observations and gives you an original resumable-upload exercise. The example numbers are fictional practice data, not a project you should claim as your own.

What an AIR invitation establishes

Official product description, checked October 6, 2026: Braintrust describes AIR as conversational voice interviewing with adaptive follow-up questions and role-specific scoring. This is the interview platform; an employer using it can be a different organization. A Braintrust marketplace application and an AIR invitation do not establish the same hiring process. Braintrust AIR product page

Official integration documentation, updated August 20, 2026: Greenhouse explains that employers can add questions and criteria manually or generate them from a job description, then review and edit them. An invitation can show the employer's branding. In the documented Greenhouse integration, completion moves a candidate from the AIR Interview stage to AIR Interview Completed; that transition does not establish selection for a subsequent technical round. Greenhouse AIR integration

There is also a date boundary. The vendor's candidate guide, updated December 9, 2025, describes on-demand video interviews, typically 15–20 minutes, with generally one chance per question. Its qualified wording is not a guaranteed timer, question count, or answer-reset policy for your invitation. Confirm the displayed instructions before starting. Candidate guide

Candidate report: a recent anonymous comment, visible as four days old when checked October 6, names AIR and says a semiconductor-company screen explored technical experience deeply. The commenter believed it was a recruiter screen; the employer, role, and outcome were not independently verified. We did not establish two independent same-cycle reports for one hiring process, so this article makes no prediction about a fixed question set or passing score. Candidate discussion

Our preparation inference: employer-specific criteria and adaptive follow-ups make an evidence-backed project useful. They do not tell us the private rubric for your role.

Choose a project with inspectable ownership

Choose a real project that intersects the job description and exposes a decision you made. For a backend role, an upload, migration, or service-reliability project may work. For a frontend role, use interaction state, accessibility, rendering, or API integration. Choose an example where you can explain a concrete failure and how you checked the repair.

Write a short ownership statement before practicing: “I implemented the upload coordinator and completion check. Another engineer owned object storage configuration. I reviewed its interface but did not operate that infrastructure.” This gives the interviewer a reliable boundary for deeper questions.

Prepare four facts: the user problem, the constraint, your decision, and the observed result. Attach a small piece of evidence to each. Evidence can be a sanitized test case, a design diagram, a deployment record, or a measured observation. A personal project is usable when you describe its scale and limitations honestly. Do not upgrade a local experiment into a production deployment or claim a teammate's work because you can explain it.

Worked exercise: faster uploads with missing chunks

The following is an original hypothetical rehearsal, not a reported AIR question. Suppose your team built resumable uploads. A file is divided into 1,200 equal chunks of 8 MiB, so its logical size is 9,600 MiB, or 9.375 GiB. A sequential version took 20 minutes in a controlled trial. A parallel version took eight minutes under the same stated conditions.

The apparent improvement is a 60% reduction in elapsed time. Dividing logical bytes by elapsed seconds gives 8 MiB/s before and 20 MiB/s afterward, a 2.5× ratio. These are arithmetic interpretations of fictional observations. They are not independent throughput measurements or proof of network capacity.

Now add the failure: the coordinator records 1,200 receipts and the nominal byte sum still equals 9,600 MiB. Yet chunk IDs 17, 401, and 1199 are missing. IDs 6, 88, and 900 appear twice. There are only 1,197 distinct chunk IDs. A receipt count and a nominal byte total can both pass while the file is incomplete.

Technical claim	Evidence to inspect	Follow-up it should survive
The transfer completed	All required chunk indices and an integrity check	Could duplicate receipts conceal a missing index?
The new design was faster	Same file, environment, timing boundary, and completion rule	Did the timer stop before final validation?
Resuming was safe	Upload identity and per-chunk retry behavior	Could a receipt for upload A be accepted by upload B?
I owned the repair	Completion-check change and regression case	Which components remained someone else's responsibility?

A minimal identity check illustrates the problem:

expected = set(range(1200))
missing = {17, 401, 1199}
receipts = [i for i in range(1200) if i not in missing]
receipts += [6, 88, 900]

assert len(receipts) == 1200
assert len(set(receipts)) == 1197
assert expected - set(receipts) == missing

We ran this small Python model locally. It does not upload a file, validate object-storage behavior, or reproduce an AIR assessment. Its purpose is to expose the difference between receipt count and identity coverage.

A fuller completion contract requires the exact expected index set, correct per-chunk lengths, association with the intended upload, and validation of the assembled file's integrity before publication. A set alone cannot detect corrupted payloads. Likewise, correct lengths cannot establish correct contents. State which check your actual system used and why.

An honest opening might be: “Parallel transfers reduced the trial time from 20 to eight minutes, but our initial completion counter accepted duplicate receipts. I changed the completion condition to track chunk identity and added a missing-chunk regression case. We withheld the result until assembly validation passed.” Replace every detail with your own evidence. Do not claim the repaired performance result unless you measured it after the repair.

Rehearse branches, not a memorized sequence

Use the worked example to practice several independent branches. A follow-up can revisit an assumption rather than follow your planned order. These prompts are our rehearsal suggestions, not an AIR question bank.

Identity branch: “Why isn't the receipt count enough?” Explain the three duplicates and three missing indices. If asked about duplicate chunks, distinguish repeated delivery from two different payloads claiming the same identity. A retry of the same chunk should not advance unique progress twice; otherwise progress can reach 100% while a required chunk is absent. A conflicting payload needs an explicit handling rule.

Concurrency branch: “What if two workers both mark completion?” Name the shared state and the point at which one validated result becomes publishable. Explain how your implementation coordinates concurrent updates. Saying “we used locks” is incomplete without identifying the protected invariant. If your project used a transactional update, explain the condition checked inside it.

Measurement branch: “How do you know it was faster?” Give the file size, timing boundary, environment, parallelism, and number of runs you actually observed. A single trial supports a limited observation. It does not establish a stable percentile or a universal improvement. Include failures and validation time in the result users care about.

Ownership branch: “Did you design the storage layer?” Identify what you implemented, what you reviewed, and what you would need to ask its owner. This is stronger than filling an unfamiliar boundary with invented implementation detail.

Alternative branch: “Why not retry the whole file?” Compare simpler state management with repeated transfer cost, then explain the conditions under which simplicity would win. A small file on a reliable connection may justify a different design from a large upload over intermittent connectivity.

For each branch, practice a direct answer, one concrete example, and one limitation. When a question changes the assumptions, say so before adapting the design. Otherwise you can accidentally contradict the contract you established a minute earlier.

Keep spoken answers easy to verify

An opening answer should establish the project's purpose and your contribution without consuming every detail. Then answer the requested follow-up first. If asked about a race, name the race before returning to business impact. If asked about results, give the measurement and its boundary before describing implementation.

Useful language separates confidence levels: “The test showed…”, “We observed this in one environment…”, and “I would investigate…” describe different kinds of evidence. Avoid turning a plausible explanation into a confirmed root cause. In the upload example, missing indices demonstrate incomplete identity coverage; they do not by themselves identify which worker, timeout, or storage fault caused it.

If a question misstates your contribution, correct it briefly: “I owned the completion check, not the transport protocol. The check rejected incomplete manifests; the transport team handled connection retries.” If your earlier number was wrong, correct the number and the conclusion affected by it. An uncorrected number can make the next measurement answer inconsistent.

You can also acknowledge an unknown: “I didn't measure tail latency. We measured end-to-end completion time for these trial uploads.” That is a useful boundary, not a reason to invent a percentile. Keep confidential identifiers, customer data, and proprietary diagrams out of practice recordings and interview examples.

Check the session and recover deliberately

Official integration requirements: Greenhouse describes a device with a camera, microphone, and internet connection, without an app installation. The employer-configured welcome page is the place to confirm the instructions for that invitation. Greenhouse requirements

Our practical recommendation is to check the selected input device, audio playback, stable connection, and a quiet setting before entering the actual interview. Read the rules for notes, external tools, and recording. Do not assume live assistance is allowed because the interviewer is automated. Arrange any needed accommodation with the hiring team before the session.

If a prompt is unclear, ask for clarification when the interface permits it, then state the interpretation you are answering. If the interface does not support that exchange, make your assumption explicit in the answer. Repeating a prepared introduction does not resolve an ambiguous technical question.

For a connection failure, preserve the visible error and approximate time, then use the available recovery instructions. Do not assume refreshing will preserve the attempt. Describe the failure to the hiring contact or support without sending a private interview link to a public forum. The official retake FAQ describes a request reviewed by the hiring team after the configured limit is reached; approval is not automatic. A request, a resumed session, and a completed attempt are separate states. Retake request FAQ

Sources and Further Reading

• Braintrust AIR product description — current vendor description of adaptive voice interviews and role criteria.
• Braintrust AIR integration: Greenhouse — employer configuration, invitation, completion stage, and result packet.
• Candidates: What to Expect from a Braintrust AIR Interview — dated candidate guidance; check invitation-specific instructions.
• AIR Interview Retake Request FAQ — request and hiring-team decision boundaries.
• Braintrust AIR FAQ, June 25, 2025 — older vendor account of adaptive video screening.
• Recent anonymous candidate discussion mentioning AIR — unverified experience, not a universal hiring process.