Composio New Grad Fullstack Engineer Interview Experience — AI-Assisted Take-Home Plus a One-Take Code Walkthrough Video

I'm an OSU CS master's student, graduating in December 2026.

Process. It's on a platform called Litmus. You run litmus init and that starts a 150-minute timer that can't be paused. The problem: you're given an API catalog with a few hundred tools (each with full input/output JSON Schema), and you write a generator that automatically infers the dependency graph between tools — i.e. which tool's missing parameter can be pulled from which other tool's output. It has to generalize to any catalog, no hardcoding. As soon as you submit, you immediately record a video walkthrough.

Some notable things about it.

1. They explicitly encourage using AI — the platform gives you LLM API credentials, and token usage counts against the problem's budget.
2. Everything is tracked: file changes, git history, and your entire conversation with the AI tool all get uploaded along with your submission.
3. Small, incremental git commits are explicitly called out as a grading criterion ("small, incremental commits show your problem-solving process").
4. Side note: since your whole prompt history and behavior trace gets collected, I felt like I basically became free human-AI collaboration training data. You know what I mean.

Let me actually talk about how I used the AI, because that's what this test is really testing. Honestly my GitHub API knowledge is at the "get by, look it up when needed" level, and it took me over 30 minutes to fully understand the problem — but by then the AI had already written most of a first draft. So my actual work was almost entirely in the second half, and it came down to three things:

One, verification. Don't take anything the AI says at face value. It told me "fixed, all tests green," I spot-checked it myself, and the very first thing I checked turned out to be exactly the untested noisy edges. After that I made a rule: it saying "done" doesn't count — only the fixed eval script exiting 0 counts.

Two, catching mistakes. Anywhere I didn't understand something, I made it explain until I did. Halfway through the scoring rules I realized it hadn't actually used the context info at all — that turned out to be the root cause of a whole category of bugs. If you don't understand the code, you can't keep it in check.

Three, setting the standard. This is what took the most time by far: manually reading through the descriptions of 90-plus parameters and building a ground-truth test set (which edges must exist, which must not exist, which nodes must have zero incoming edges). Once that test set was in place, the AI actually became useful — it fixed things against the tests, I accepted things against the tests, and neither of us could fool the other.

Also, the official API quota (1M tokens) burned through fast — spoiled by Claude Max, I genuinely found it not enough, haha. Once it ran out, everything was backstopped by rules plus tests.

The real hard part: the video after submission. No AI allowed, your external monitor gets forcibly unplugged, the timer starts the second you see the question, roughly 1.5 minutes per question, one continuous take with no re-recording.

Q1 was "explain the code logic and design to a coworker," Q2 was "what difficulties did you run into."

I'd fully internalized the design through the whole back-and-forth with the AI, so I could talk through that part fine. But the code itself was AI-written and I hadn't had time to read it line by line, so walking through it piece by piece, pointing at the actual code, was rough. "Understanding the logic" and "being able to point at the code and explain it" are two different skills, and the video round tests exactly that gap.

Suggestions.

1. Get your entire environment set up before you run init (node/git/editor) — don't waste a single second of the timer on environment setup.
2. The prompt explicitly says it's graded on "quality and structure" — output quality matters more than feature count, and building your own eval is the single biggest point-scorer.
3. Force yourself to leave 10–15 minutes before submitting to read through the final code start to finish. The video comes right after submission, so that's your only prep window — learned this one the hard way.
4. Commit at the end of every small milestone, with a clear message.

I'll come back and update this thread with any progress (pass or fail, next round).

Update (2026-08-21): adding some question details for anyone reading this later. The catalog they gave us was their own product's GitHub toolkit — 893 tools, each with a full input/output JSON Schema. The task was to write a generator that automatically infers, from the catalog, "tool B's missing parameter can be obtained from tool A's output," and output a dependency graph plus a visualization. Their own example: GITHUB_CREATE_AN_ISSUE_COMMENT needs issue_number, and its prerequisite is GITHUB_LIST_REPOSITORY_ISSUES. A few key design points: first, a parameter like owner/repo that's required by half the tools should be classified as "ask the user for context" rather than a dependency edge; second, parameter names and output field names don't line up (issue_number vs. issues[].number), so you have to split it into entity matching plus field matching; third, and the biggest trap — a schema match doesn't mean it's semantically correct. A workflow run's output has a PR number embedded in it, but nobody's going to query CI status just to get a PR number, and you have to suppress that kind of noise with rules plus your own eval set. It had to generalize to any toolkit, no hardcoding. After finishing it, I felt like this problem wasn't invented for the test — it's a real problem their product actually needs solved. I half-suspect they're crowdsourcing a solution on the side. XD