The loop mixes three very different formats, so preparation has to be split the same way. The first is a recorded, time-boxed video assessment, where candidates describe a short planning window, a short answer window and often a single retake. The second is a live coding session with screen sharing. The third is a conversation about your own past work and about code review. A candidate who only grinds algorithm problems will be underprepared for the first and third stages.
The role, as candidates describe it, centres on production web applications: JavaScript or TypeScript, Python or a similar language, plus database management and API design. Cloud familiarity (AWS or GCP), startup experience and decentralized or blockchain-adjacent exposure are listed as nice to have rather than required. That shapes what you should be able to talk about: how you would model data, shape an API, find a bottleneck and keep a change safe to ship.
Reported question topics fall into two groups. The behavioral group asks you to introduce yourself, describe a disagreement with a peer over a technical decision, describe delivering a feature under pressure, explain why you want to work at Braintrust specifically, and describe how you manage several high-priority tasks. The technical group asks how you debug a complex production issue, to write a function from an input and output description, how you keep code scalable, to discuss a challenging project you led and its architectural decisions, and how you approach testing and quality assurance.
Because the spoken stages reward compact answers, build a small bank of stories first and then trim each one until it fits a short window. Then spend the rest of your time on working code written aloud, and on being able to defend a past design and review someone else's change. The plan below follows that order.
Asynchronous Video Assessment
reportedCandidates report an automated video format in which you answer prompts under strict time limits. Reports mention about a minute to plan, an answer window of roughly two minutes, and often only one retake, and describe it as a first impression where clear communication counts alongside technical background. There is no back-and-forth, so the answer has to stand alone: a direct opening, two or three concrete points, and a finish. Use the planning minute to pick a frame such as Problem, Action, Result (a structure candidates are advised to use) and write three keywords, not a script.
What to demonstrate
- Whether you can give a clear, concise answer without a conversation to lean on
- Whether your answer has a visible structure inside a short window
- Professional presentation on camera in a remote setting
How to prepare
- Record yourself on a phone answering one prompt per sitting with a one-minute plan and a two-minute cap, then watch it back for filler and for where the answer wandered
- Build a story bank of four or five projects, each reduced to Problem, Action, Result with one number or concrete outcome
- Test camera, microphone, lighting and a quiet room before the session, because a retake may not be available
Technical Interview
reportedCandidates report a Zoom-based technical interview with screen sharing and live coding. The reported focus is working, maintainable code: coding under time constraints, writing code from a prompt, programming fundamentals and algorithmic problem solving. Reports mention Big O and memory use, explaining your thinking before implementing, and handling inputs that could break the code. The stack listed for the role is JavaScript or TypeScript and Python, so choose the one you can write fastest and stay in it. A good rhythm is to restate the problem, give a worked example, name the brute-force approach and its cost, then write the better version and trace an example through it.
What to demonstrate
- Working code written live under time pressure
- How you decompose a problem and explain it aloud before implementing
- Complexity awareness (time and memory) and edge case handling
How to prepare
- Practise a mix of array, string, hash map, sorting and two-pointer problems in a plain editor with no autocomplete, narrating as you go
- After every solution, test empty input, a single element, duplicates and very large input, and state the final time and space complexity
- Run a screen-share rehearsal: check sharing permissions, font size, microphone and a stable connection so setup does not cost minutes
Code Review Discussion
reportedCandidates describe a Code Review Discussion focused on past project decisions and code reviews. The reports do not specify whether you review a supplied change or discuss reviews from your own history, so prepare for both. Expect to explain what you built, which alternatives you weighed, how the code was tested, and what you would change now. The stack candidates describe includes production web applications, databases and API design, and reports mention scalability, maintainability and defending trade-offs between technologies.
What to demonstrate
- Ownership of past project decisions and the reasons behind them
- Quality of judgment when reading and commenting on code
- Ability to discuss scalability, maintainability and trade-offs
How to prepare
- Write a one-page decision record for two projects: context, options considered, choice, outcome and what you would change
- Practise reviewing a short diff aloud in a fixed order: correctness, edge cases, tests, security, naming and readability, then performance
- Prepare an example of a review comment you received and one you gave, including how the discussion ended
PracHub editorial advice for the preparation topics above.
Rambling through the video answer and getting cut off before reaching the result
Use the planning minute to write three keywords (problem, action, result), practise with a timer and a phone recording, and rehearse stopping on your conclusion rather than filling the remaining time.
Coding silently in the Zoom session, then handing over a solution with no explanation
Restate the problem, give a worked example, name the brute-force cost, and narrate each decision. Finish by tracing one example through the code and stating time and space complexity.
Writing a function that handles the happy path and never testing empty, single-element, duplicate or oversized input
Keep a fixed edge case checklist and run it out loud after every solution. State the inputs you assume and what the function does for anything outside them.
Describing a past project in the code review discussion as 'the team decided' with no personal decision, rejected alternative or lesson
Prepare a decision record for two projects: the options, why you chose one, how it was tested and what you would change. Be ready to criticise your own code as readily as someone else's.
Giving a reason for wanting to work at Braintrust that would fit any company
Read how the talent network works, pick one engineering problem from the role (marketplace liquidity, platform security or user experience) and link it to a project you have done.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Write a function to solve [specific input/output challenge].
Write a function to solve [specific input/output challenge].
Approach
- Pin down the contract before coding: write the signature with types (TypeScript types or Python type hints), then walk two or three concrete input/output examples, including empty input, a single element, duplicates, negative values and the largest size allowed.
- State the brute-force solution and its complexity out loud, then find the repeated work it does. Map that work to a known tool: a hash map turns repeated lookups into O(1) average (pair sum goes from O(n^2) to O(n) time and O(n) space), sorting plus two pointers gives O(n log n) with O(1) extra space, a sliding window covers contiguous-range problems, and a heap gives top-k in O(n log k).
- Write it in small, clearly named pieces, and handle invalid or boundary input explicitly instead of hoping it never arrives. Say what each block does as you type it.
- Trace your own example through the code by hand, then the edge cases, and fix off-by-one errors before saying you are done. Finish by stating the final time and space complexity.
- If time allows, describe the unit tests you would write: normal case, boundaries, and one input built to break the obvious mistake.
Follow-up
- How would this change if the input arrived as a stream or did not fit in memory?
- Can you cut the extra space, and what does that cost in time?
- Which tests would you write for this function, and which input is most likely to break it?
How do you approach testing and quality assurance in your development process?
How do you approach testing and quality assurance in your development process?
Approach
- Describe a layered test suite: many fast unit tests on pure logic, fewer integration tests that hit real boundaries (a real Postgres in a container, the HTTP layer of an API), and a small set of end-to-end tests on the user flows that matter most.
- Name tools from your stack: pytest with fixtures and parametrize for Python, Jest or Vitest for JavaScript/TypeScript, Playwright or Cypress for browser end-to-end tests, and static checks (TypeScript strict mode, mypy, a linter) to catch whole classes of bugs before runtime.
- Say what you test, not just how: boundary values, error and timeout paths, API contracts between services, and a failing test that reproduces each bug before you fix it.
- Run everything in CI on every pull request and block merges on failures. Pair that with code review, and treat coverage as a way to find untested code, not as a target to hit.
- Add production safety nets, since tests will miss some bugs: feature flags, canary or staged rollouts, error tracking and alerts tied to the change you shipped.
Follow-up
- How do you deal with a flaky test that fails one run in twenty?
- What do you mock, and what do you insist on testing against the real dependency?
- How do you test code that depends on the current time or on randomness (for example, by injecting a clock or seeding the generator)?
Diff a projection against the primary without per-row point reads
The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.
Approach
- Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
- Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
- For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
- Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.
Follow-up
- The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
- Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?
Hold a per-tenant active cap against concurrent creates
A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.
Approach
- Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
- Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
- Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
- State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.
Follow-up
- A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
- The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?
Explain why the owner filter ignores the listing index
The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.
Approach
- Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
- For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
- Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
- Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.
Follow-up
- 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
- A dashboard runs this for 40 owners in one page load. What changes about the design?
How do you ensure the scalability of the code you write?
How do you ensure the scalability of the code you write?
Approach
- Start from measurement, not instinct: set a target (p95 latency, requests per second, job runtime), find the hot paths with a profiler and a load test, and optimise only what the numbers point at.
- Keep code paths from growing badly with data: avoid nested loops over collections that grow, stream or batch large datasets instead of loading them whole, and paginate list APIs with keyset (cursor) pagination, since OFFSET still reads and discards every skipped row.
- Treat the database as the usual first bottleneck: index the columns used in WHERE, JOIN and ORDER BY and confirm with EXPLAIN, remove N+1 query patterns by batching or joining, and use a connection pool sized to what the database can handle.
- Keep request handlers stateless so the service can scale horizontally behind a load balancer, cache read-heavy data with a TTL plus explicit invalidation on writes, and move slow work (emails, reports, third-party calls) onto a queue with idempotent, retryable workers.
- Name the trade-offs: a cache adds staleness and invalidation bugs, denormalising speeds reads but makes writes costlier, and optimising before there is load data wastes effort and makes code harder to maintain.
Follow-up
- A list endpoint is fine today but slows badly at ten times the traffic. Where do you look first?
- When a record changes, how do you keep its cached copies from serving stale data?
- How do you make a background job safe to retry without double-processing (for example, with idempotency keys)?
Discuss a challenging technical project you led and the architectural decisions you made.
Discuss a challenging technical project you led and the architectural decisions you made.
Approach
- Pick one project where you owned the design, not one where you implemented someone else's. In two sentences, give the constraint that made it hard: scale, a deadline, a legacy system or a small team.
- Present two or three decisions in the same shape: the options you considered, the one you chose, why, and the cost you accepted. Examples: a module in the monolith versus a separate service, a relational schema versus a document store, a synchronous API call versus a queue.
- Show how you reduced risk: a prototype or load test before committing, rollout behind a feature flag, an incremental migration that runs old and new side by side, and backward-compatible schema changes (add the column, backfill, switch reads, then remove the old one).
- Close with measurable results (latency, error rate, delivery time, on-call load) and say which decision you would change now, and why.
- Say "I" for your own decisions and credit the team's part separately, so it is clear what you personally decided.
Follow-up
- Which part of that architecture would break first at ten times the load?
- Which decision would you reverse with hindsight, and what would the migration cost?
- Someone disagreed with your design. How did you settle it?
Explain your approach to debugging a complex system issue in a production environment.
Explain your approach to debugging a complex system issue in a production environment.
Approach
- Size the impact before theorising: which endpoints or users fail, since when, and whether it is errors, latency or wrong data. If users are hurting, mitigate first (roll back, turn off the feature flag, shed load) and root-cause after.
- Line up a timeline of every change near the first bad data point: deploys, config edits, schema migrations, dependency upgrades, traffic shifts. Correlation narrows the search; a rollback that clears the symptom gives stronger evidence.
- Follow one failing request end to end with a trace or correlation ID across services and compare it with a healthy one. Check the usual shared bottlenecks: database slow-query log and EXPLAIN plans, connection-pool saturation, queue depth, memory and GC.
- Reproduce it outside production with a failing test or a staging replay. When there is a known good and a known bad version, git bisect finds the offending commit in about log2(n) steps.
- Close the loop: ship the fix together with a regression test, add the alert or log line that would have caught it sooner, and write a blameless postmortem with owners for the follow-up items.
Follow-up
- The bug only appears in production and only intermittently. How do you get enough signal to reproduce it?
- How would you show that the recent deploy caused the issue and did not just coincide with it?
- What would you add to monitoring so the next incident like this is diagnosed faster?
The plan starts with the spoken, time-boxed format, then moves to live coding, production thinking and design discussion, and ends with a full mock. Days point at the reported questions and at PracHub practice questions on indexing and concurrency, which are practice material rather than Braintrust questions.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and build a story bank
- Write out the three reported rounds (Asynchronous Video Assessment, Technical Interview, Code Review Discussion) and mark which format you are least used to.
- List four or five past projects and reduce each to Problem, Action, Result with one concrete outcome.
- Write your answer to the 'Tell me about yourself' question as present, past, future, using two of those projects.
Deliverable: A one-page round map, a story bank of four or five Problem, Action, Result entries, and a written self-introduction.
Practice prompt ↗02Timed spoken answers on camera
- Record the self-introduction and the 'Why do you want to work for Braintrust specifically?' answer with a one-minute plan and a two-minute cap, then watch both.
- Read about the Braintrust business model, choose one problem area from the role and rewrite the 'why' answer around it.
- Re-record each answer once to simulate a single retake and compare the two.
Deliverable: Two recorded answers, each re-recorded once, and a note on the filler words and run-over you found.
Practice prompt ↗Practice prompt ↗03Conflict, pressure and priorities
- Write the disagreement story with the evidence you used and what happened if the peer's option won.
- Write the tight-deadline story with what you cut, what you protected and how you told the product manager.
- Write a prioritisation method for multiple high-priority tasks and record all three answers within the time cap.
Deliverable: Three recorded answers and a one-paragraph prioritisation method.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Live coding in a shared screen
- Solve four problems in a plain editor in JavaScript, TypeScript or Python, narrating aloud: restate, example, brute force, improved version, trace.
- Attempt the PracHub practice question on diffing a projection against the primary, a practice exercise on comparing two data sets efficiently.
- Write the 'write a function from an input and output description' routine: clarify types and size, name edge cases, code, test, state complexity.
Deliverable: Four solved problems with complexity notes and a reusable checklist for the function-writing prompt.
Practice prompt ↗Practice prompt ↗05Debugging, testing and database behavior
- Write a production debugging sequence you can say aloud: what changed, scope, reproduce, bisect, fix, add a test, follow up.
- Write your testing strategy by layer: unit, integration and end-to-end, plus what you test around API contracts and database writes.
- Work the PracHub practice questions on concurrent creates against a per-tenant cap and on an index that a filter ignores.
Deliverable: A debugging runbook, a testing strategy page and written answers to the two database practice questions.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗06Scalability and the code review discussion
- Write the scalability answer for one past service: read and write paths, the first bottleneck, the database load and how you would measure it.
- Write the decision record for the project you led, with options considered, the trade-off you accepted and what you would change.
- Review a short diff aloud in a fixed order: correctness, edge cases, tests, security, naming, performance.
Deliverable: A scalability note, a decision record for the led project and a spoken review of one diff.
Practice prompt ↗Practice prompt ↗07Full mock of all three stages
- Run the video stage: three prompts back to back with a one-minute plan and a two-minute cap each.
- Run a live coding session with a friend over screen share, including the full setup check.
- Walk through your decision record and review a diff, then write two questions you want to ask the team.
Deliverable: One complete mock of all three stages and two written questions for your interviewers.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report that the behavioral questions cover your background, disagreement with peers on technical decisions, delivering under pressure, why you want to work at Braintrust specifically, and managing several high-priority tasks. In a timed video format each answer needs a structure that holds together without follow-up questions, so rehearse each story as a short Problem, Action, Result.
Tell me about yourself and your background in software engineering.
Tell me about yourself and your background in software engineering.
Approach
- Use a present, past, future shape: what you do now, the two or three experiences that led there, and why this role is the next step. Spoken, that is roughly a minute or two, which also suits a timed video format.
- Pick two projects and give each a result in a clause, for example 'I rebuilt the checkout API so p95 latency dropped' with your real numbers. Choose the ones that touch the role's stack: JavaScript or TypeScript, Python, databases, API design.
- Open with your current role in one sentence, not your degree. Name your strongest language and the kind of system you work on so the listener knows what to ask next.
- End by connecting forward: what you want to build next and why a talent marketplace fits that. Do not recite your CV in date order; that is the common way this answer fails.
Follow-up
- Which of those projects are you proudest of, and what was your own contribution?
- What is the weakest part of your background for this role, and how are you closing it?
- What do you want from your next role that your current one does not give you?
How do you handle situations where you disagree with a technical decision made by a peer?
How do you handle situations where you disagree with a technical decision made by a peer?
Approach
- Choose a real technical disagreement with a small blast radius, such as a schema design, sync versus queued processing, or a library choice. Say what each side wanted and why both positions were reasonable.
- Show how you resolved it with evidence, not persistence: a quick prototype, a benchmark, a written comparison of failure modes, or a look at how similar code behaved in production.
- Describe the decision rule: who owned the call, and how you agreed to proceed. If your peer's option won, say so and say what you committed to. 'Disagree and commit' only works when you then back the decision.
- Close with the outcome and what you changed in how you disagree afterwards. The story that sinks this answer is one where you were right and the peer was simply wrong.
Follow-up
- What if the peer was more senior and still would not move?
- Tell me about a time you turned out to be the one who was wrong.
- How did you keep working with that person afterwards?
Describe a time you had to work under tight pressure to deliver a feature.
Describe a time you had to work under tight pressure to deliver a feature.
Approach
- State the constraint in a sentence: the feature, the deadline and what was at stake. Then spend most of the answer on decisions, not on hours worked.
- Show scope control: what you cut or deferred, what you refused to cut (for example tests on the money, auth or data-write path, or a rollback plan), and who agreed to the cut. Mention that you worked with the product manager to rank requirements.
- Name how you de-risked the delivery: a feature flag, a staged rollout, a daily checkpoint with the stakeholder, or a smaller first version that shipped on time.
- Report the result and the aftermath: what shipped, what debt you recorded, and when you paid it down. A pure heroics story with no trade-off is the answer that falls flat.
Follow-up
- What would you cut differently if you ran it again?
- How did you decide what not to test?
- What did the shortcut cost later, and who noticed?
Why do you want to work for Braintrust specifically?
Why do you want to work for Braintrust specifically?
Approach
- Build the answer from three parts: what the product is, which engineering problems interest you, and what you bring. Candidates describe a talent network and marketplace described as decentralized, with marketplace liquidity, platform security and user experience as challenge areas. Read about the business model before you answer.
- Tie one problem to your own experience, for example matching or search quality, trust and fraud controls on a two-sided marketplace, or reliability of payments and onboarding flows. Give a specific project of yours that touched something similar.
- Say what attracts you about a decentralized approach to work in your own words, and be honest about the limits of what you know. Do not claim inside knowledge of the team or its roadmap.
- Avoid a generic reason such as 'great culture' or 'fast-growing company'. Keep it short enough for the timed video format, then finish with one question you would ask.
Follow-up
- What do you think is the hardest trade-off for a decentralized talent network?
- What would you want to build or fix first?
- What concerns do you have about joining, and how would you test them?
How do you manage your time when working on multiple high-priority tasks?
How do you manage your time when working on multiple high-priority tasks?
Approach
- Describe a system, not a feeling: list everything open, estimate the effort, rank by impact, deadline and who is blocked, and write the ranking down where stakeholders can see it.
- Show that you negotiate priorities. When two requests both claim top priority, ask the owners or the product manager to rank them rather than silently picking, and say what you would give up to fit both.
- Give a concrete episode with numbers from your own experience: how many items, what you moved, what you deferred and who you told. Include protecting blocks of focused time and handling interrupts such as a production incident.
- Close with what you missed or learned, such as checking the ranking daily or splitting a large task so a smaller piece could ship. The weak version is 'I work harder and stay organized'.
Follow-up
- Two stakeholders both say their task is the top priority. What do you do?
- Tell me about a deadline you missed and how you communicated it.
- How do you handle an urgent production issue in the middle of planned work?
- 01
Tell me about yourself and your background in software engineering.
- 02
How do you handle situations where you disagree with a technical decision made by a peer?
- 03
Describe a time you had to work under tight pressure to deliver a feature.
- 04
Why do you want to work for Braintrust specifically?
- 05
How do you manage your time when working on multiple high-priority tasks?
- 06
Describe a code review comment you received that changed how you wrote the change.
How long does the Braintrust interview process take?
Candidates report three rounds spread over roughly 3-5 weeks, from the Asynchronous Video Assessment through the Technical Interview to the Code Review Discussion. Some candidates report waiting for feedback between stages, so follow up politely if you have heard nothing after a reasonable gap.
Braintrust Software Engineer candidate reports ↗How does the asynchronous video assessment work?
Candidates report prompts answered on camera under strict time limits, with about a minute to plan, an answer window of around two minutes and often just one retake. Practise with a timer, use the planning minute to pick Problem, Action, Result, and test your camera and microphone beforehand.
PracHub Software Engineer practice ↗What does the technical interview involve?
Candidates report a Zoom-based session with screen sharing and live coding. Topics reported include algorithmic problem solving, programming fundamentals, implementing under time constraints and writing code from a prompt. Prepare in the language you write fastest, whether JavaScript, TypeScript or Python, and narrate your reasoning.
Braintrust Software Engineer candidate reports ↗What is the Code Review Discussion?
Candidates describe a conversation about past project decisions and code reviews. The reports do not say whether you review a supplied change, so prepare for both: a decision record for two projects, and a method for reviewing a diff covering correctness, edge cases, tests, security and readability.
PracHub Software Engineer practice ↗Which languages and skills should I be ready to use?
The requirements candidates describe list modern languages, typically JavaScript or TypeScript and Python, experience with production web applications, and a solid grasp of databases and API design. AWS or GCP, startup experience and decentralized or blockchain-adjacent work are listed as nice to have, so do not treat them as required.
PracHub Software Engineer practice ↗Will I be asked about system design?
Candidates describe design topics such as scalability, maintainability and defending why you chose one technology over another, particularly for more senior roles. Even if no design round is announced, be ready to discuss how a past service handled more traffic or database load and what you would change.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01Braintrust Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Cognition Software Engineer Interview Guide
What Cognition asks Software Engineer candidates, from reported rounds and questions.
XCMG Software Engineer Interview Guide
What XCMG asks Software Engineer candidates, from reported rounds and questions.
Viber Software Engineer Interview Guide
What Viber asks Software Engineer candidates, from reported rounds and questions.
Venmo Software Engineer Interview Guide
What Venmo asks Software Engineer candidates, from reported rounds and questions.