Tacit Testbench

• Tacit Testbench turns a company's real codebase, tickets, and issues into a technical interview
• It serves as a coding environment that captures the entire session: every command, commit, prompt, and artifact
• Testbench allows companies to assess candidates on real engineering problems and based on how they thought through the problem, not just the solution

At Tacit, we do high-touch hiring. On the candidate side, that means helping people find roles that align with their North Star. On the company side, it means finding candidates who fit the culture and can pass the technical bar. Today we're advancing the latter by progressing how we judge a candidate's ability to do the job at any company, with Tacit Testbench.

Tacit Testbench is a platform that turns a company's real codebase, tickets, and issues into a technical interview. We do this because a generic problem like a leetcode-style interview doesn't inform how great a candidate would perform on the actual job. It doesn't show whether they can move through the company's codebase. It doesn't show whether they can make progress on the company's hardest engineering tasks. And, ultimately, it doesn't show what a hiring team would want to know: whether this person can do the job at their company.

Interviews conducted through Tacit Testbench are done through a sandbox that tracks the entire session. Every command, commit history, prompt, and artifact is captured for review. What comes back is a record of how someone worked: what they explored, where they backed out, how they directed their tools, and how they checked they were right. This allows us to thoroughly evaluate how a candidate worked through the codebase and solved the problem.

Creating Role-specific Assessments

We build each assessment from the client's own material. An assessment in Testbench is comprised of five things:

1. An artifact from the company. A slice of the real codebase, a ticket, an open issue, or a problem the company is solving. Using an agent, we automatically turn this into something a candidate can start coding in minutes.
2. An environment. The container image, dependencies, services, and fixture data, pinned so every candidate gets the same starting state.
3. A time budget. How long the assessment runs and what's explicitly out of scope for the problem.
4. A tool policy. Tools like AI coding agents on (and logged), restricted, or off.
5. A rubric. Test cases auto-generated for the problem, evaluation criteria where interviewers can weigh the importance of different aspects of the project, and questions the candidate answers about their implementation.

Example. An example assessment we generated was for a gaming company whose product records gameplay, hiring engineers to work on that capture pipeline. We had candidates implement recording software from scratch: pull frames off a running session, keep audio and video in sync, encode to a playable file, and hold up when frames arrive late.

Assessments are versioned and reusable. Running ten candidates through the same pinned environment means a review is comparative rather than anecdotal. We can point at two sessions at the same timestamp and say what separated them.

Candidate's Assessment Experience

A candidate gets a link, provided by the interviewer.

That link opens a sandbox with the repo already cloned, dependencies installed, and services running. They can work in the browser or connect their own editor over SSH. Their own tools, their own keybindings, their own AI assistant — the setup they would actually use on the job.

Before the timer starts, a consent screen states exactly what is captured and what happens to it. Then they work.

What we deliberately do not do: no lockdown browser, no keystroke-level surveillance, no blocking AI (unless requested). Those measures assume the goal is to catch someone cheating. Our goal is the opposite. We want to see how the candidate actually operates. For example, we believe that a candidate who uses AI well should be rewarded, not penalized.

Candidate's Submission Experience

Submitting freezes the sandbox. Testbench takes a snapshot of the final tree, closes the session timeline, and produces a single reviewable object: the code, the commits, the command log, the prompt log, and the recording, all aligned on one clock.

Then the candidate talks about their implementation. We generate several prompts about how they approached the problem, and the candidate answers each one out loud: what they would do with two more hours, what they deliberately cut, where they are least confident. This allows us to assess how much they actually understood the problem and the solution they built out.

Because the environment is pinned, a reviewer, or the client's engineer, can boot the exact final state and run it. "Works on my machine" is not a category that exists here.

Reviewing Candidate's Submission

A reviewer opens the submission and can examine the candidate's performance in five different ways.

1. Evaluation. Did the code pass the provided test cases and the hidden ones? This is the floor. It tells you that the code functions properly, which is where most interviews stop and where ours starts.
2. Code. A replay of how the code got built. You see what they wrote first, what they rewrote, and what they never touched. A diff only shows where they ended up.
3. Activity. Commits and commands as they happened. This is where you see whether they ran what they just wrote, or wrote for 60 minutes and hoped.
4. Agent activity. The prompts they sent and what came back. It is the most direct read we get on judgment: whether they handed the model the failing output and checked what it returned, or took the first answer whole.
5. Recordings. The session itself, plus their spoken answers at submission. Hearing someone explain a decision is the fastest way to tell whether they made it themselves and understood the problem.

All five are stored per candidate, so a submission can be reopened at any point: while the process is still running, when a second reviewer wants their own read, or months later when the team is comparing someone new against the last person they hired.

Tacit Testbench Availability

Testbench is currently being dogfooded but will eventually run every technical interview we conduct today. If we are running your hiring, your candidates are already going through it, and the sessions come to you alongside our read on each one.

At Tacit, we provide all this information to our clients. The assessment, the session, our read, and the decision we made on it, all attached to the candidate. Companies can open the session and check the read against what actually happened, and the final hiring decision stays where it belongs, with the team.