Unitree AI Agent Interview: Real Engineering Beats Theory, Why You Should Apply Anyway

A fan of the author, a graduate from a non-prestigious university (双非普本), interviewed for an AI Agent development position at Unitree (宇树). Before the interview, he was intimidated by the job requirements and prepared extensively by reviewing standard interview questions (八股).

During the interview, he found the atmosphere surprisingly relaxed. The questions were highly concrete engineering problems:

How to integrate RAG into business workflows?

How to design tool calling mechanisms?

How to stop an Agent that keeps repeating execution?

These questions had depth but were grounded in real implementation: "Have you actually done this? How do you handle problems when they arise?"

RAG: Beyond the Basic Pipeline

Knowing the standard RAG flow — chunking, vectorization, retrieval, generation — is only the start. Real projects face follow-up issues:

When documents update, how to handle stale content?

When retrieval results look relevant but fail to answer the question, how to debug?

When the knowledge base lacks the answer, how should the system respond?

Tool Calling: From Demo to Production

In demos, a single tool call succeeds smoothly. In production, parameters may be wrong, APIs may time out, and results may deviate from expectations. Handling these failure modes is where the real engineering effort lies.

The interview heavily probed the candidate's resume projects. Every detail listed must be understood deeply, as most questions derive directly from the resume.

Interviewers Are Engineers Too

The candidate initially imagined interviewers as all-knowing authorities. In reality, they also face deadlines, debug logs, and unclear requirements. When a candidate explains a real problem clearly — how it occurred, how it was diagnosed, how it was solved — the interviewer can assess: "Can this person work with me to solve problems?"

AI Agent Engineering Is a Collection of Concrete Tasks

AI Agent sounds imaginative, but implementation means wrestling with prompts, tools, memory, task flows, and failure handling:

When should the model continue vs. stop?

When a tool errors, should we retry?

After several steps with no progress, how to exit?

If a task is interrupted midway, how to record completed portions?

Each item is explainable in isolation; stitching them into a stable system requires meticulous iteration. Much development time is spent debugging: inspecting call traces, adding exception handling, tweaking prompts, observing results, and codifying edge cases into regression tests. The user sees a smooth operation; behind it are many repetitive, tedious fixes.

Value Lies in the Details

After the interview, the candidate began to respect his own daily work. Tasks once deemed too ordinary for a resume turned out to be strong evidence of capability when he could articulate the problem, diagnosis, and solution.

"Makeshift team" (草台班子) is how the world actually works. Imperfect processes and tools don't make work easier; they create the need for someone to bridge gaps, resolve issues, and deliver results. Succeeding in such an environment is genuine skill.

The candidate now dares to apply more broadly because he can map his experience to job requirements: what he has done, what needs learning, what deserves deeper study. Job postings are no longer intimidating checklists.

The author advises: prepare fundamentals, but invest extra time in explaining your projects clearly. Fill knowledge gaps where needed, but don't pre-reject yourself based on degree, company name, or a daunting job description. The candidate's biggest takeaway: "Now I dare to apply." He will wait for the result, continue learning, but next time he sees an interesting role, he will send the resume first.