Interview experience | AI Agent / Automation | 🔥🔥 | TikTok
North America (San Jose) · Software Engineer, AI Agent and Automation · full-time · applied on the careers page · Recruiter Screen ~25 min → Technical Interview ~55 min → rejected.
Applied online. Recruiter call got moved once, then one technical interview, 55 minutes, then a rejection. So this is short — one screen, one technical round. Writing down what I remember.
Recruiter screen
About 25 minutes. Self-intro, why TikTok, graduation and start date, and whether I had actually shipped anything with LLMs instead of just read about it. I gave the short version of an internal automation project and we booked the technical.
Technical interview
55 minutes, one interviewer. No separate design round — the design stuff came out of the project and the harness part. Order below is approximate.
The project
Started from the first project on my resume: architecture, what I owned, why that stack. Then he stayed on state ownership — who owns a run's state, what happens if two workers touch the same run. I said one owner at a time, the holder writes the transitions, tool calls carry a run id so a retry doesn't create a second run. He asked what happens if the owner dies mid-step. It gets picked up and continues from the last committed step. The side-effecting call is the part you can't replay. That's the messy bit.
Harness
Then agent harness engineering, what a production harness has to cover. Roughly in this order:
- scheduling — which runs get a slot, what the concurrency ceiling is
- per-tool timeout and circuit breaking
- context injection — what the model sees each step, and how much
- observability
- error isolation, so one failed tool call doesn't take the worker down
He asked what I record. Trace per run and per tool call, tokens and cost per step, tool success and failure, latency, and enough of the request and response to reproduce the case. Internal ticket data can't go to a third-party provider, so that part is either redacted or judged by a model that's allowed to see it.
Execution control
This one I bombed. He asked: the agent keeps calling tools and makes no progress, what do you do.
I said cap the steps. He asked what if the cap is generous and every call is slightly different. I said detect repeats over the trajectory, not over the text. Then I had nothing — I couldn't say what I would hash, or how to tell "different words, same state" from actual progress. The answer I would redo.
Tool registry and description drift
MCP tools and skills: registration, versioning, schema compatibility, description governance, so a description change doesn't route the model to the wrong tool.
Roughly:
- the registry is the source of truth, every tool has an owner
- a published version doesn't change; a schema or description edit makes a new version, behind a compatibility check — adding an optional parameter is fine, removing or renaming is breaking
- descriptions get reviewed like prompts, because that is what they are
- a small labelled request set per tool catches a bad description edit before rollout
- the model only sees the tools the task needs, not everything on the platform
He also asked about cost. Cheap model for the easy steps, semantic cache for repeats, trim the context, stop early once the answer is decided, and give each run a budget that actually stops it instead of a dashboard.
Coding: coupons
Prices array, k coupons, each one halves the current price of any item, same item reusable, minimize the total.
Greedy — always spend the coupon on the most expensive item. Max-heap, pop the top, halve, push it back, k times, sum.
Follow-up was a fixed amount off instead, and a price can't go below zero. The heap still works, but the halving logic doesn't. Now it's spend where it saves the most, so min(amount, current price), and stop at zero. Took me a while to land that one.