Take-home review desk that runs candidate code in a sandbox

I want an app that my engineering hiring panel opens to review take-home submissions, instead of everyone cloning candidate code onto their own laptops. It has three surfaces: a review queue, a submission reader, and a per-role compare view.

The review queue is the landing page. It lists every candidate currently sitting at the take-home stage. Pull the open roles with the Greenhouse List Jobs action, then pull their applications with List Applications, and keep the ones whose current stage is the take-home or assignment stage. For each of those, call Get Candidate and read the embedded attachments and custom fields to find the submission repository link the candidate provided. Each row shows the candidate, the role, how many days they have been waiting since they entered the stage, and the state of the automated run: never run, running, or finished with a headline result. Sort the longest waiters to the top, let reviewers filter by role, and flag rows where no repository link could be found on the candidate record so a recruiter can chase it.

Opening a row shows the submission next to its run report. On the left, render the repository from GitHub: Get a Repository for the basics such as default branch, primary language and last push, List Files in a Directory to walk the tree, and Get a File to load the contents of whatever file the reviewer clicks. Decode the base64 file contents and display them with syntax highlighting and line numbers. Preload the README, the dependency manifest and the test directory so a reviewer lands on something readable rather than an empty pane. On the right, show the run report for this submission if one exists, and a Run button if it does not.

The Run this submission button kicks off a background agent. It creates a fresh Daytona sandbox with Create Sandbox, then polls Get Sandbox until the state is started, because sandbox creation is async and toolbox calls fail before then. It clones the candidate repository with Git Clone Repository and does the rest of its work with Execute Command in Sandbox, falling back to Create Session and Execute Command in Session for anything long running like a dependency install or a full build. It reads the README and follows the candidate's documented setup steps exactly as written rather than guessing at a better path, then installs dependencies, runs the build, runs the test suite, and runs the linter. It also inspects the commit history by running git log inside the sandbox after the clone, since there is no GitHub list-commits action to call. When the work is done, or the time cap is hit, it deletes the sandbox with Delete Sandbox.

The agent writes a structured scorecard back into the app so the reader and the compare view can both display it. The scorecard records whether the project builds, whether the candidate's own documented instructions actually worked end to end and exactly where they broke if they did not, which tests passed and which failed with the failing output attached, what the linter reported, what the commit history suggests about how the work was done, and a short list of notable strengths and notable risks. Every claim cites the command that produced it, and the raw command output is expandable so a reviewer can check the agent's reading rather than take it on trust.

Underneath the report, the reviewer writes their own verdict, picks pass or no pass, and presses File to Greenhouse. That posts the combined writeup, meaning the reviewer's verdict plus a summary of the run, as a note on the candidate with Add Candidate Note. On a pass it also moves the candidate forward with Advance Application. Then it announces the outcome in the hiring channel using the Slack Send a Message action, naming the candidate, the role, the verdict and the reviewer who made the call.

Bake in these rules. Candidate code only ever executes inside the Daytona sandbox and never on a reviewer's machine, so the app should never offer a local clone or a download of the submission. Every run is time capped, and the sandbox is disposed of when the run ends or the cap is reached, whether it succeeded, failed or hung. The agent's scorecard is advisory only: the app never files anything on its own, and a human always presses the decision button. The rubric is stored per role and the same one is applied to every candidate on that role, so two submissions for the same job are always scored against the same list. And there is a side by side compare view of all the runs for one role, with build result, test results, setup-instructions result and reviewer verdict in a row per candidate, so the panel can calibrate against each other instead of grading in isolation.

Persist runs, scorecards, per-role rubrics and reviewer verdicts inside the app, so the queue and the compare view keep working long after a sandbox is gone. Keep a record of who filed which verdict and when, and show on each row when the last run happened so nobody reruns a submission that was already reviewed this morning.