Joye Personal Blog (EN)

From Interviews to Agent Engineering: Why I Stay Calm

Mon, 15 Jun 2026 00:00:00 GMT

import TalkEpisodeCard from '@/components/blog/TalkEpisodeCard.astro' import TalkSlideFigure from '@/components/blog/TalkSlideFigure.astro'

Last week I gave a technical sharing session in my follower group. The video is already out, but some people prefer reading, so I turned it into this post. The structure maps one-to-one to the talk, just rewritten from spoken notes into an article, with a few arguments filled in more fully. All links referenced in the post are collected at the end.

The talk started from an offhand observation: the words around "Agent development" keep changing, and job descriptions on Boss Zhipin update painfully fast. What I wanted to discuss was this: when the field iterates this quickly, whether you are looking for an internship or already building agents, what mindset should you use to keep up with it?

TL;DR

Terms change faster than models - Prompt -> Context -> Harness -> Loop - but they are all doing the same thing: building more system around the stable model core.
Do not drown in new terms. Do not hoard links and never read them. Send them through your personal agent first; when learning a new area, scrape job descriptions and primary sources instead of letting AI teach you from zero.
The real moat is not knowledge. Knowledge is abundant and AI can mass-produce it. The moat is your judgment, taste, and context; context comes from initiative - building, publishing, getting tested.
In one sentence: do not chase every term; build a system that keeps running. Technically, that is a persistent personal agent. For your growth, it is a loop of build -> hit real problems -> distill -> publish.

This post has four parts: what these terms are really about, how I avoid getting overwhelmed, how I learn deliberately, and what the real moat is.

1. A year of terms: four engineering waves and a year of open-source agents

There are too many new words. Feeling anxious when you see them is normal. So let us first align on what these words actually mean.

If you put the keywords from the past few years on one line, you get a clear relay:

'22-'23 Prompt Engineering - write the instruction well. The focus was on prompting an LLM to return better and more stable answers. Back then, people were still obsessed with magic words like "think step by step" and "reflect before answering." See Prompt Guide.
'25.6 Context Engineering - manage everything the model sees. As tasks get longer, model attention drifts, so the problem becomes: how do we keep attention focused and feed only the context that matters? Shopify CEO Tobi Lutke proposed it, and Karpathy made it catch fire.
Early '26 Harness Engineering - wrap the model in scaffolding. The OpenAI Codex and Anthropic posts share one important word: long-running. If you want an agent to work on longer tasks, you need a harness.
'26.6 Loop Engineering - stop manually prompting and design the loop instead. A tweet by Steinberger, the creator of OpenClaw, roughly argued that you should not be typing prompts for coding agents anymore; you should design the loops that prompt them. It hit 1.7M views and started a broader discussion. Addy Osmani then systematized and named it.

These four terms are one relay of engineering vocabulary: Prompt -> Context -> Harness -> Loop. In between sits the broader industry backdrop: 2025 was widely treated as year one for Agent / multi-agent systems. Open-source frameworks bloomed everywhere - LangChain deepagents, Goose, and many more. Big companies and startups all built agents and pushed multi-agent architectures, until by the end of the year people started questioning whether multi-agent was sometimes fake complexity. Multi-agent itself is not a new "engineering term" in this chain; it is the soil that made the four waves happen.

The timeline makes the compression obvious: Prompt to Context took three or four years. After Context, Harness and Loop, plus the 2025 open-source agent wave, almost all arrived in one dense year. It moved so fast that Tencent's 30,000-word report from two weeks ago was still centered on Harness Engineering; Loop only appeared this week. I would not be surprised if Xiaohongshu and Boss Zhipin start showing "Loop Engineering Intern" roles in two weeks. Right now the job descriptions are still stuck in the OpenClaw and harness era.

The pattern: the engineering target keeps expanding outward

Put these waves together and one thing becomes clear: the model basically stays the same; what changes is the layer you operate on.

In one line: words -> context -> environment -> mechanism. The names change, but the work is the same: build a system outward around the model core. In other words, the history of these terms is a history of the system boundary expanding.

This is not just hype: same model, better outer layer

Here is a hard number. LangChain's coding agent did not change the model at all (gpt-5.2-codex, still a closed model). They only rebuilt the harness, and on Terminal-Bench 2.0 they jumped from outside the top 30 (52.8%) into the top 5 (66.5%), a gain of 13.7 points - almost the kind of lift you would expect from a new model generation. Vivek Trivedy, who leads open-source agents and harness work at LangChain, put it well in that post:

"Agent = model + harness. You are either the model, or you are the harness - everything outside the model is harness."

There is a subtler example too. When I used Grok's coding model before, its tool calling kept failing because arguments did not match the expected schema. I remember seeing research where simply aligning parameter formats made the same model perform nearly an order of magnitude better. So many problems that look like "the model is bad" are really harness problems.

Small caveat: I cannot find the original source for that experiment right now, so I am writing from memory. I will add the link if I find it, and if you know the source, please point me to it.

The essence: the name changes, the work does not

Go backward and you will see that earlier prompt and context work were also harness work; the word "harness" just did not exist yet.

And the previous layer never disappears. It becomes a component of the next layer. Prompting did not die; it became one component inside a loop. Before, humans manually refined a better prompt. With Loop Engineering, agents refine prompts, run tests, and iterate inside the loop. It is layers wrapping layers. Often the old layer was already being used; it just had not been named separately.

So why do the terms keep changing? Partly because there are real increments - Loop does add something beyond harness, and we should admit that. But a large part is also marketing. There is no need to panic every time a new term appears. They are doing the same underlying job: without changing the model itself, make an agent steadier and make the experience better than directly using ChatGPT or Claude. I call that Agent Engineering.

2. Why I am not anxious

When people see a pile of new terms, their first reaction is often: "I have so much to learn." But the problem is usually not that there are too many terms. The problem is that you save them and never read them.

New terms pile up like deadlines. Most people only bookmark them and never spend the time to understand them. They quietly pretend that "saved" means "read." I have done this too. But if you calculate the actual cost, understanding a new concept like Loop Engineering is much cheaper than it feels. Anxiety comes from the unknown itself. What piles up is not knowledge; it is unknowns. Once you see that, the solution is straightforward.

Practice 1: send new things to my personal agent first

For example, when I saw Loop Engineering, the original tweet was long and I did not have time to read it closely. I sent it straight to my agent: "Read this and explain what it is. It seems to be getting popular."

With AI, the cost of quickly and partially understanding something new is extremely low. From its explanation alone, I roughly understood what the thing was. That was enough. If it looked important, I could read the original carefully; if not, I could skip it. Most new material does not deserve a line-by-line read. Let AI do the first pass.

It often tells me something useful along the way: many cron jobs, skills, and workflows I built on my own devices were already basically Loop Engineering. That validates the earlier point: new terms often just label things many people were already doing.

Practice 2: do not ask "what is it"; ask "how is it different from what I already do?"

This requires your agent to know you, either through memory or by being placed inside your codebase.

Then ask it: how is this new thing different from what I am already doing? That lets you sort new terms into three buckets: a real thing worth chasing; something I am already doing; or pure hype I can skip. Even if you do not fully understand the new thing yet, you need to know the gap between it and your own work, what you would need to learn, and what practice would close that gap. If you can sort terms this way, they stop dragging you around.

3. How to learn and where to find information

People are afraid of information gaps: "I cannot reach primary sources" or "am I already behind?" Meanwhile, the internet keeps telling you that you are doomed if you do not learn some new Claude Code / Codex trick. Most of that is anxiety manufacturing.

The first step in learning is not studying. It is scraping job descriptions.

I learn very pragmatically: for employability and for building real things. So when I enter a new direction, I first scrape a pile of job descriptions and look at the terms the market is using. Recently, when I wanted to learn agentic RL, I searched for roles from recognizable large companies and top startups.

Why start from job descriptions? Because once you know the vocabulary, you can search and talk to AI precisely, and you can start building a basic map of the field. This works when the direction already has real jobs, which is true for a relatively mature and fast-moving area like agents. If there are no jobs yet, you have to fall back to search and blogs.

One trap: do not take very early-stage tiny-company job descriptions too seriously. Their JDs are often vibe-generated and not very useful.

For information sources, I recommend X/Twitter and official blogs first - OpenAI, Anthropic, and so on. There are good Chinese newsletters too, but many of the ones I see have clickbait titles and low information density. Primary signals are on X and official blogs; WeChat articles are often second-hand retellings.

Do not let AI teach you a new field from zero

This is a trap worth spelling out. Current large models have two common limitations. First, they tend to follow your framing. However you ask, they continue along your assumptions. Second, when you have no foundation at all, you cannot detect hallucinations. This is a general limitation of current models, not one model's fault.

Combined, these two problems are dangerous. If you are starting from zero and hand the entire "teaching" job to AI, it is easy to drift. It gives you a polished-looking learning path, you cannot judge whether it is right, and then it reinforces the direction you asked for. You end up with a self-consistent but distorted map.

The correct order is the reverse:

Wrong: let AI teach from zero - ask it for a learning path -> you lack the foundation to judge it -> it follows your framing -> you drift.
Right: capture primary sources first - scrape job descriptions or ask for a few good blogs -> read the originals and build your own source of truth -> when stuck, ask AI specific questions.

When I learn a new field, I ask AI to recommend a few good blogs, not to lecture from scratch. There will definitely be parts I do not understand. I then send those parts back and ask for help. That way, the model is anchored to my learning path and can understand my current stage.

Give the manual labor to agents

Instead of reading the information stream all day, let your agent act as a filter. You only receive the small set worth reading:

One common pitfall: if you ask an LLM to "recommend a few papers," it may invent titles and links. The safer approach is to connect it to real, trusted tools - for example, an arXiv skill that extracts data from the source site. Then the results are real links and real metadata, not model imagination. After collecting candidates, add a verification step: have the agent confirm that each link is reachable and that the title and abstract match before summarizing and filtering.

Another simple heuristic: to decide whether a paper is worth tracking, first check whether it has an open-source repo. Crude, but useful.

To be clear, not everything should be handed to AI. Precisely because AI exists, independent learning and deep thinking matter more. You still have to decide which blogs and papers deserve careful reading, and which tasks can be fully delegated to an agent.

Everyone should have a personal agent with long-term memory

If you have used OpenClaw or Hermes Agent, you know the shape: a persistent agent that you talk to through WhatsApp or Telegram. The architecture roughly looks like this:

It is a persistent gateway running on your machine, turning the apps you already use into command surfaces. It has persistent memory, hundreds of skills, and a heartbeat that wakes itself up on a schedule to help you follow up on email and calendar items.

I think everyone should have this kind of long-memory personal agent now, even if long-term memory is still rough today. When you write your own skills and use it deeply over time, you hit real problems. Those experiences are exactly what carry weight in interviews and technical conversations. This is the technical-system version of the main theme: something that runs on its own and helps you process the information flood.

4. The real moat: initiative

This part starts from something my mentor once said: "Interviewing is the only moat in our field."

I still agree, but I now understand it differently. I used to take it literally and grind interviews. Now I read "interviewing" more as a learning method. Its real core is forcing yourself into external evaluation instead of building behind closed doors. If that is the core, interviews are not the only path: group discussions, hackathons, and workshops are all versions of the same thing. Of course, I also admit that some interviews, especially at small companies, are tiring and not worth doing just for practice.

Behind all these actions - pushing yourself out to be tested - is one thing: initiative. That is the real moat.

Knowledge is the foundation. Context is the moat.

Here I want to borrow a distinction from Dan Koe. You can treat some of his writing as motivational fluff, and I often do, but this point is right: we should become context creators, not just content creators.

Knowledge / content - fact-based and mass-producible. AI supplies it almost infinitely. It is increasingly like cabbage: everyone can get it, so it does not differentiate you.
Context - your judgment, taste, path, and scars. This is the part AI cannot replace or mass-produce.

One misunderstanding needs to be cleared up: saying knowledge is "cabbage" does not mean knowledge is unimportant. It means knowledge is easy to obtain and therefore not the differentiator. When learning a new area, you still need a solid foundation. Without it, you cannot read primary sources and cannot tell whether AI is hallucinating. Foundational knowledge is the ticket. The real moat is the context you grow on top of it around your own path. Knowledge is easy to get; context is hard. Do not reverse the order.

In interviews, this becomes concrete. "What are skills?" AI can answer that perfectly. What you can answer is: which skills you have actually used, what was good and bad about them, what pitfalls you hit, and how you made tradeoffs. AI cannot replace that. Tencent's report puts it more brutally: AI replaces "the reason you were hired."

That is why I am skeptical of bootcamp projects and open-source projects with no substantial second-pass development. AI can produce those. Why would I hire someone who only proves they can build what AI can already build? I want to see the parts AI cannot replace, including taste. A very practical example: people with stronger visual taste often build better frontends, even if they use tools like Google AI Studio that developers may consider "less advanced." Many PMs and designers produce better-looking interfaces than pure developers. So we developers need to train taste too.

The winner is not always the most technical. It is the most proactive.

Tencent's Super Individual Era report breaks "super individuals" into four capabilities. I think the framing is useful:

AI First - AI is the default starting point for work. In an interview a few days ago, the interviewer asked me whether I still hand-write code. I said: honestly, not much. My university years overlapped with AI becoming extremely capable, so AI First feels natural to me. People who lived through the older era of traditional programming often find this mindset shift harder.
Capability leap - order-of-magnitude improvement plus cross-domain loops. This is similar to why teams now hire full-stack engineers instead of neatly separating frontend and backend. AI has lifted the scope one person can cover. Later, we may see more "product development engineers" who build and also understand growth.
Active exploration - this is the most important one: proactively pushing toward the boundary of AI capability.
Influence spillover - making the whole team faster.

The report also says something I strongly agree with, and it matches what Fan Ling, the founder of Tezign where I interned, has observed: the people who use AI best are often not engineers, but product managers and designers. I felt this directly during my internship. The first person to think of using AI for video was an editor. Often you really do need to jump outside the engineering frame.

AI has pulled almost everyone back toward the same starting line. In that world, initiative becomes the scarce thing.

Make your learning trail public and turn it into a loop

So how do you become proactive? Make your learning path and traces public, and turn them into a loop:

Build a small thing first. You will hit real problems. Distill those problems into articles, skills, or notes, then publish them - on a blog, in videos, on social media, or simply in a community group. After publishing, you either receive feedback or start the next thing, and you return to the beginning.

This is the growth-system version of the main theme. It has the same shape as your personal agent, except it runs on you. The key is: do not only output content; output your judgment, pitfalls, and path - your context. Publishing also forces clarity. It is like solving a science problem: if you really understand it, you should be able to explain it to someone else. This talk itself is me forcing myself to distill less than a year of experience into something public.

Why this is good news for young people: faster iteration flattens the starting line

Many companies do not only filter by school; they also filter by age - "we only want people born after 2000," or "only post-90s." A weaker school background can sometimes be compensated for with strong external projects. Age cannot be compensated for.

But the reverse is also true: no one has ten years of Loop Engineering experience. The most senior engineer and you are reading the same tweet this week.

Credentials expire. Curiosity compounds. That is what overtaking on a curve looks like.

A concrete way to overtake: do evaluation

Here is a very recent example. Vercel's AI SDK update this week (6/12) lets you swap harnesses the way you swap models - Claude Code, Codex, Pi, all behind the same API, each running in its own sandbox:

const agent = new HarnessAgent({
  harness: claudeCode, // can also be codex / pi
  sandbox: createVercelSandbox()
})

For the first time, harness is being standardized as an official engineering layer. The real chain reaction is this: once harnesses can be swapped as easily as models, comparing which harness is better becomes both easy and valuable. In other words: evaluation. And agent evaluation is still scarce. This opening has barely been explored systematically.

So "do evaluation" is a very practical entry point. I have said this repeatedly on my blog: for your internship project or personal project, if you have the time and ability, do evaluation. Evaluation forces you into real problems. Without evaluation, your agent is a black box and you do not know whether it works. Evaluation is also valuable in the job market. Last week, a student working in automotive, a very vertical domain, had done evaluation and accumulated many real cases and lessons. Those could directly feed into his next job.

Finally: turn anxiety into two actions

Build a real thing - even a tiny agent is enough. Let it touch real problems first.
Publish your learning trail - blog, Xiaohongshu, GitHub, anything. Output context, not just content.

Terms will keep changing. But technically and personally, what you need is the same thing: a system that keeps running. Technically, it is a persistent agent with memory, skills, and a heartbeat. Personally, it is a loop of "build something -> hit a real problem -> distill -> publish -> build the next thing." Same shape, two systems. Once you build it, it helps you fight the noise that never stops changing.

Terms are noise. Systems are signal. That is the talk. If you have questions, come chat in the group or comments.

Joye · joyehuang.me

References

Prompt Engineering: promptingguide.ai
Context Engineering (Karpathy): x.com/karpathy
Open-source Agent / deepagents: github.com/langchain-ai/deepagents
Harness Engineering - OpenAI Codex: openai.com
Harness Engineering - Anthropic: anthropic.com
Loop Engineering - Steinberger original tweet: x.com/steipete
Loop Engineering - Osmani's naming post: addyosmani.com
LangChain harness benchmark post: langchain.com
Terminal-Bench 2.0 leaderboard: tbench.ai
Dan Koe on context vs content: letters.thedankoe.com
Tencent Research Institute, Super Individual Era: news.qq.com
Vercel AI SDK Harness: vercel.com

I Grilled Another Agent Candidate: 46-Minute Mock Interview

Thu, 28 May 2026 00:00:00 GMT

import WechatReveal from '@/components/WechatReveal.astro'

Date: May 28, 2026 | Duration: 46 min 41 sec Interviewer: Joye (me) | Candidate: H Format: paid mock interview · built around two personal Agent projects + Agent fundamentals + a reverse-question/debrief round

Author: Joye | joyehuang.me | GitHub | WeChat joye050604

Before we start

My last post, A 1-Hour-19-Minute Agent Engineer Mock Interview, was also a debrief from my seat as the interviewer — except that one had two interviewers, whereas this time it was just me grilling H one-on-one.

H booked a paid mock interview, targeting an Agent engineer role. I ran it at the same intensity as a real interview — digging deep into the two personal projects on his résumé, then filling in Agent fundamentals in the back half, and finally reserving nearly 20 minutes for a debrief and some sharing.

Compared with the last post, this one is more focused on the deep-dive-into-projects + exposing-fundamentals-gaps thread. The back-half material — reverse questions, the "vibe coding gear" playbook, résumé advice — is stuff I cover in every interview, but I always tune it to the candidate's weak spots. This time I specifically reinforced the areas H couldn't answer (RAG, Agent evaluation, the engineering tradeoffs around prefix caching).

⚠️ Annotation key for this post:

🟢 H answered well | 🟡 H answered partially / off-target | 🔴 H couldn't answer / got it wrong

💡 = the standard answer / correct line of thinking I gave on the spot

🔧 = corrections I made afterward against Anthropic's official docs (I did a pass before publishing; there were a few spots where I wasn't precise enough during the interview either, and I'm flagging them honestly — knowledge moves so fast that this is just the nature of the field)

Part 1 · Project One: a long-term personal assistant Agent

H's project is similar to Hermes — a long-term personal AI Agent deployed on EC2, centered on a memory system (consolidation + memory.md) and prefix-cache optimization. This was H's strongest area, so I probed it the deepest.

1.1 How often does consolidation (memory distillation) trigger? 🟢

My question: You said you do consolidation. After each conversation, how frequently does consolidation run? How do you decide?

H's answer:

Consolidation isn't triggered on a time basis, but on a "new-information-count" threshold.
He set a threshold on the count of new information; once it's hit, consolidation triggers once.
The information counted toward that total has three parts: ① the user's input ② the assistant's output after the ReAct loop ③ some tool output.
Once the accumulated count reaches a certain number, consolidation runs a round of summarization.

1.2 What exactly is the input to consolidation? 🟢

I confirmed repeatedly: The stuff you feed in includes both assistant messages and user messages, right? You consolidate both of them?

H's answer:

Everything goes in — user messages and the AI's responses are both added to the running total.
The consolidation step uses a separate LLM (large language model) of its own.
It extracts some long-term facts and the like from this information, then stores them in a memory-like DB.

1.3 Is consolidation a standalone agent? 🟡

My question: So is this consolidation done by another standalone agent with its own system prompt?

H's answer:

It shouldn't count as an agent; it's just a very simple tool call.

I pressed: Does this consolidation step live inside your main conversation agent, or somewhere else? Who initiates the API call that runs consolidation — the main agent, or that extra standalone module?

H's answer:

Not the main agent. It's a fixed process hardcoded into the workflow.
At the end of a ReAct loop, it makes a judgment about whether to trigger consolidation.

🟡 My debrief: H's phrasing here was a bit tangled, and it took me several follow-ups to nail down "who actually initiates the API call." His design is actually correct — consolidation is a fixed step in the workflow, independent of the main conversation agent, triggered by orchestration logic that checks the threshold at the end of each ReAct loop, using a separate LLM call (with a dedicated extraction prompt). He just didn't articulate it cleanly. Clarity of expression is itself an interview criterion — especially when the interviewer is probing a core ownership question like "who initiates the call," a vague answer makes people wonder whether you actually implemented it yourself.

1.4 What happens when the context overflows? 🟡

My question: People usually handle context overflow. How do you handle it on your end?

H's answer (two parts):

Inside the ReAct loop, after each call he runs a check, hanging a test: whether it has hit 80% of the context window.
The history isn't summarized-after-it-overflows; instead, history holds a fixed number of entries that stay fixed — pulling the latest N rounds from the full record into the prompt.
If it overflows, he just deletes: e.g. cut from 40 entries straight down to 20, and if that's still not enough, down to 10.
Summarization is already handled in consolidation (consolidation summarizes this information and stores it in the memory base), so he doesn't do a separate summarization for "overflow" — the two are kept separate.

I pressed: Why just delete? 🔴

🔴 H couldn't answer.

💡 My standard line of thinking at the time: The biggest problem with FIFO-deleting old messages is information loss — the rounds you cut may contain key facts that later turns still need to reference. A better approach:

Before cutting, do a summarization-compression pass (compress the old rounds you're about to drop into 1-2 summary lines that stay in context) instead of mindlessly deleting.

But summarization introduces a prefix-cache-invalidation cost (see 1.6), so engineering-wise it's a tradeoff.

Actually, there's a good reason H's project gets away with deleting directly — because consolidation has already extracted the long-term facts into storage, so what gets deleted is only the short-term conversation. He could absolutely have raised this argument himself, but in the moment he didn't realize he needed to connect "my consolidation design already provides a backstop" with "so deleting directly is reasonable." This is the classic case of "did the right thing but can't explain it."

1.5 Is memory.md fixed-length, or can it grow without bound? 🟢

My question: Is your memory.md (the user-profile document) fixed-length, or can it keep growing?

H's answer:

memory.md is tied to the padding layer (the cache layer).
If it gets updated at the end of every conversation, the cache won't hit.
So consolidation asynchronously writes the long-term user preferences, profession/job info, etc. into the padding-layer file.

My question: Does this document have a cap? Like, only so many entries? Or can it accumulate indefinitely?

H's answer:

It has no cap set.
Because it's not all dumped into the prompt — there's a retrieval round that pulls out the relevant info before injecting it into the prompt, so overflow shouldn't be a concern.

1.6 "memory.md in the middle of the prompt" = full injection? 🟡

My question (asking against his résumé/project doc): You wrote "memory.md, as the user profile, sits in the middle of the prompt." Do you put the entire memory.md in there?

H's answer:

Not the whole thing — what's written there is wrong (the résumé/doc phrasing is inaccurate).
In the actual project it should be a retrieval round first, then "memory retrieval results + user profile" both get injected — what goes in is the relevant portion that was retrieved.

🟡 My debrief: This is a textbook résumé landmine. The wording on the résumé/doc ("sits in the middle of the prompt") didn't match the real implementation (inject-after-retrieval), and I caught it on the spot. Every single sentence on your résumé has to map to a real implementation, otherwise it's a vulnerability that will get dug into — especially since an Agent-track interviewer will almost certainly latch onto every technical term you wrote and grill you on the implementation details.

1.7 Should memory.md have a cap? (open design question) 🟢

My question: Suppose, like Hermes agent, memory.md is fixed-length and stuffed in full into the system prompt. I give you two choices — ① with a cap (say 3000 tokens) ② can grow without bound. Which do you think works better?

H's answer:

I think a cap is better.
Because unbounded growth wastes resources no matter what, and may contain duplicate information, which means the model can't focus its attention.

🟢 The direction here is right (a cap is better).

1.8 You have a cap, but a genuinely useful new memory comes in — now what? 🟢

I pressed: If there's a cap and I've already hit it, but I now detect a genuinely useful memory that needs to be stored, what do you do?

H's answer:

First do dedup detection — which existing memories does the new one overlap with, and is there any overlap at all.
If business needs require a real-time update, update it in.
If there's no overlap, merge (consolidate) with the existing content — merge what can be merged, rather than dumping it in verbatim.

I pressed: Do you think merging is a good operation?

H's answer:

Merging will definitely cause information distortion.
But if there's a token-count limit, I think merging is a necessary operation (distortion is an acceptable price paid for space).

🟢 This set was well answered — he gave both a plan (dedup → update/merge) and pointed out the trade-off (merge vs. distortion). This is an answer structure I appreciate: a plan plus a tradeoff.

1.9 Any more techniques to improve the prefix cache? 🟢

My question: For prefix cache, what other techniques do you have to improve it?

H's answer:

Core idea: find the parts of each conversation round that don't change, and put the unchanging content where the prefix cache can hit, to cut token consumption.
Example: if the user profile updates frequently, it definitely won't hit the cache; but if it's updated asynchronously on a schedule via a function (so it changes infrequently), it can go in the cache-hit region.
So it's a relative, depends-on-how-you-set-it-up problem — separate volatile content from stable content, and front-load the stable part as much as possible.

🟢 Well answered — he caught the core of "front-load the stable, update the volatile asynchronously."

1.10 In Plan mode, how do you avoid breaking the prefix cache? (Claude Code scenario) 🔴

My question: You know Claude Code / Codex has a Plan mode, right? In Plan mode we want to restrict tools — it can't have edit permissions. But I also want to guarantee the prefix cache stays alive, so I can't change the tool list (otherwise switching from plan mode back to work mode would invalidate the cache). How do you handle this?

🔴 H started with "I genuinely don't know this one." Then he tried to answer, but his thinking was wrong — he assumed "the tools visible each round change, and you reassemble the currently active tools on every call."

I corrected him on the spot: if the tools differ, the prefix cache invalidates. His résumé also says "40+ tools, full schema injection," and that tool schema should sit in the prefix-cache section and be touched as little as possible.

H even pushed back, saying "the prefix-cache section and this are separate; the tools section is rewritten every time" — which is actually his project's design, but I'd argue that design is wasteful instead.

💡 The standard answer (I wasn't precise enough live; filling it in here based on Anthropic's official blog Lessons from building Claude Code: Prompt caching is everything):

What Claude Code does: the tool list is completely identical in plan and non-plan mode, byte-identical, with no disable flags or schema changes whatsoever.
The way Plan mode is implemented: EnterPlanMode and ExitPlanMode themselves exist as two tools in the tool list. When the model calls EnterPlanMode, a <system-reminder> is injected via the tool result (appended as a subsequent message, rather than modifying the system prompt), telling the model "you're in plan mode now, you MUST NOT do any edits."
This is a "soft-constraint / trust-based" design — the model can still physically call Edit, Bash, and all other tools; it's just been explicitly instructed "don't use them right now." By contrast, GitHub Copilot's plan mode physically removes 43 tools (a hard constraint); Claude Code chose to keep all the tools + constrain behavior with a system reminder, for the core purpose of not blowing through the prefix cache.
A related design worth adding: Claude Code also has a defer_loading tool-search mechanism — a large set of MCP tools isn't injected with full schemas; instead only lightweight stubs are sent (just the tool name + defer_loading: true), and the model "discovers" and loads full schemas on demand via the tool-search tool. This is another way to protect prefix-cache stability.
The core principle: Tools are part of the cache prefix; any change to a tool schema blows through the entire cache — so engineering-wise, everything revolves around "the tool list never changes."

🔧 My own correction on review: During the interview I said "marked as disabled / inert," which isn't entirely accurate — Anthropic's actual approach is to leave the tool list completely untouched and switch modes via the extra EnterPlanMode/ExitPlanMode tools + a system-reminder soft constraint. The direction was right (both are about preserving the prefix cache), but I got the specific implementation detail slightly off. This is also a reverse example — as the interviewer, you have to be willing to admit when you weren't precise; knowledge moves too fast.

Part 2 · Project Two: a music-radio Agent

Core: a song semantic-retrieval pipeline + vector recall + async TTS narration, packaged into an "interactive radio experience."

2.1 Which vector database do you use? Looked into others? 🟡

My question: Your project implements a song semantic-retrieval pipeline and vector recall — which vector database do you use? Have you looked into others?

H's answer:

He uses something very lightweight: SQLite.
He's heard of Neoverse / the Neo family (a slip of the tongue; he probably meant some other vector store).
And PostgreSQL (PGSQL) probably has a vector store too (meaning pgvector) — he'd seen it before.

🟡 My debrief: His knowledge of vector stores is clearly thin. The common ones should roll off the tongue: Pinecone, Milvus, Qdrant, Weaviate, Chroma, pgvector, FAISS, etc., along with their respective use cases (local/cloud, scale, whether hybrid retrieval is needed). I didn't keep pushing, because he couldn't answer the RAG pain points at all afterward, so I just skipped this part.

2.2 The biggest difficulty in vector recall / the biggest pain point of RAG? 🔴

My question: What do you think is the biggest difficulty in the vector-recall process? Or what do you think is the biggest pain point of RAG technology today?

🔴 H couldn't answer. He only said "it might recall some irrelevant stuff," and for pain points he "hasn't really looked into it."

💡 I've put the complete answer to this in the big RAG primer in Part 4 (in the debrief I added a whole section on this), see 4.5.

2.3 What is the "120-second black-box wait"? How did you solve it? 🟢

My question (pointing at his résumé): You wrote here "unsolved / agent's synchronous 120-second black-box wait" and "users can confirm or skip after each round of recommendation, paired with async TTS" — what is this?

H's answer:

The problem: the whole pipeline is generated as one chunk. If you pick a song, you have to wait for the entire pipeline to finish generating before it returns, so the user has to sit there waiting (the 120-second black box).
His fix: it tells you the song as soon as it generates one; if you decide to add it to the upcoming playlist, you click "confirm" and it's added to the playlist, with the subsequent steps pushed to the background.
This turns "synchronous waiting on a long pipeline" into "return first + user confirms + process asynchronously in the background," eliminating the black-box wait.

🟢 After hearing this I said "oh, I get it" — this async interaction design is the highlight of Project Two, and he explained it clearly.

After that I stopped asking about Project Two, my exact words: "I feel like there's nothing worth asking about the project — let's do fundamentals." → Project Two lacked depth overall and got skipped through quickly. This is also a hint: if a project has only one highlight, ten minutes is enough to grill it dry; a project that genuinely holds up to grilling needs at least 3-5 design decisions you can discuss in depth.

Part 3 · Agent fundamentals

3.1 How does an Agent become aware that Skills exist? 🟡→🔴

My question: Skills — how does an agent become aware that skills exist?

H's answer:

There should be some upfront toggle, like how in a client you can switch certain skills on or off ahead of time.
During use, you definitely don't dump them all in; you put some of their describe (description) in, and if you think this round of conversation will need it, you read out the full skill like calling a tool.

🟡→🔴 My on-the-spot verdict: "Said a lot, didn't hit the point."

💡 The standard answer I gave (verified against the official Claude Skills docs, mostly accurate):

A skill has a fixed template, and the first three lines are its frontmatter — containing its name and description.
This part (name + description) is loaded into the system prompt at session startup — so the LLM can "see" the existence of all skills from the start. In Anthropic's own words: "Provides just enough information for Claude to know when each skill should be used without loading all of it into context."
Only once the LLM decides which skill to use does it load the full body of SKILL.md into context via a file read (bash Read) (the second level of progressive disclosure).
If SKILL.md further references specific files under references/ or scripts/, the model can load them on demand one more level (the third level). This is why a project can mount dozens of skills with tiny startup overhead — each skill only costs ~30-60 tokens (frontmatter) at startup.
Conclusion: this puts a lot of weight on how well you write your skill description — because the model relies on the description to decide "should I trigger this skill this round." Write the description imprecisely and the model will either misfire or miss the trigger.

3.2 Should a skill's description be long or short? 🟢

I followed up: Suppose a skill is "do frontend design" — do you think its description should be detailed (long) or concise (short)?

H's answer:

It depends on the skill's internal content:
- If it's high-level guidance, write a brief description — that way it gets pulled in for reference as long as there's "a bit of relevance."
- If it targets a very specific scenario, write it more detailed — that way it only gets used when a scenario "matches more closely."

🟢 Well answered — he caught the core that "the verbosity of the description determines the granularity at which a skill triggers." He couldn't answer 3.1 but caught 3.2, which shows he actually has a feel for the underlying logic; he just hasn't encountered the concrete implementation.

3.3 Do you know Agent Evaluation? 🔴

My question: Have you looked into the Agent evaluation part at all?

🔴 H flatly said "haven't really looked into it." This is one of the key things I told him to fill in (see the debrief checklist in Part 4).

3.4 What's the relationship between MCP and Skills? 🟡

My question: What do you think the relationship is between MCP and Skills?

H's answer:

MCP provides some methods/tools; a Skill is a methodology.
The two are a methodology vs. practice relationship.

🟡 My debrief: This answer is fairly vague. A more accurate distinction:

MCP (Model Context Protocol): a standardized protocol that lets an agent connect to external tools/data sources (essentially "a standard for plugging in tools/capabilities").

Skills: a set of packaged, progressively loadable capability bundles (SKILL.md + resources) that solve "when and how to use a certain class of specialized capability."

In short: MCP solves "what to plug in and how to plug in external capabilities"; Skills solve "in what scenario the model should invoke which packaged approach." The two can be combined.

3.5 To save tokens / cut costs on an Agent project, what methods are there? 🟡

My question: Suppose a business-research agent whose goal is to save tokens and cut costs — what specific methods do you generally use?

H's answer (two points):

Progressive tool loading: don't put all the tools in context; build a tool-ingestion (retrieval) tool that progressively pulls out the tools you need.
Forced formatted output: add constraints in the prompt so the model outputs formatted data, reducing the tokens consumed in interaction (a hard constraint).

I pressed: Besides relying on the prompt, what other methods are there for hard constraints?

H's answer:

Add a validation layer after output finishes — validate whether it output in the required format, and if it doesn't pass, send it back for another round (retry).

🟡 My debrief: Both points are correct, but not comprehensive. Other token-saving levers worth adding: prefix-cache-hit-rate optimization, context compression / summarization, using cheaper models for subtasks (model tiering), retrieval injection instead of full injection, trimming a redundant system prompt, batching, capping max_tokens and reasoning length, etc. Among these, model tiering and prefix-cache optimization are the two biggest items, and he didn't bring them up unprompted — a bit of a shame, especially since he's already doing prefix caching in his own project.

3.6 Multi-Agent vs. single-Agent — when do you use which? 🟡

My question: Multi-agent vs. single-agent — in what situations would you use each? Why? Pros and cons?

H's answer:

Projects where the functions can't be cleanly separated → single agent: e.g. a personal assistant or a radio, where the functions aren't separated, a single agent is enough. Plus the context is shared across the various calls, so it works better too.
Big projects where responsibilities are cleanly separated → multi-agent collaboration: e.g. one side does docs, another writes code, another does review, with each module's function clearly separated; if you merge them all together, the context gets messy.

I pressed: For something like a research workflow (research first → read the literature → draft one → draft two → review), do you think that counts as multi-agent?

H's answer:

I think it probably doesn't / wouldn't use multi-agent, because its workflow is fairly fixed — there's no need for multiple agents to negotiate who goes first, and no need for a master agent to decide which agent to call.

I didn't reject this; I added "things orchestrated like a workflow" (i.e. a fixed-orchestration workflow is another form, sitting between a single agent and a true multi-agent setup).

I kept pressing: Besides "separating responsibilities," what other advantages does multi-agent have? Give me one advantage and one disadvantage.

H's answer:

Disadvantage (he said first): in multi-agent collaboration, how to coordinate the interactions between each agent is a very hard point.
Advantage: it can accomplish complex tasks.

🟡 I rejected the "accomplish complex tasks" advantage, my exact words: "After all that, all you've said is multi-agent is complex and single-agent is simple." This is a textbook "looks like an answer but actually says nothing" answer — a single agent plus workflow orchestration can equally accomplish complex tasks, so that's not a differentiating advantage of multi-agent.

💡 The two core advantages of multi-Agent (my answer + post-hoc refinement):

You can swap models / combine multiple models: for a company project, multi-model is very important —
- Different features use different models: text features, reasoning features, image-generation features each use the appropriate model.
- The real logic of saving money: it's not that "multi-agent itself saves money," but that "multi-agent lets you sensibly use cheap models for grunt work, so you don't pay top-tier-model prices for every subtask." For example, Claude Code's Research system uses Opus 4 for orchestration and Sonnet 4 for subagents — total token volume goes up, but the per-token price comes down, and on balance it's reasonable.
You can run things concurrently in the background: multiple agents can run at the same time, saving wall-clock time. A single agent, even on the same task, can only run serially to completion; multi-agent can process things concurrently.
- Anthropic's official data: their Research system (Opus 4 lead + Sonnet 4 subagents) outperforms a single-agent Opus 4 by 90.2%, and the core mechanism is exactly concurrent decomposition + an independent context window per sub-agent.

🔧 A one-line post-hoc refinement: In the interview I presented "saving money" as the core advantage of multi-agent, and that point is strictly speaking skewed — according to Anthropic's official data, a multi-agent system consumes roughly 15× the total tokens of a single agent; it is by no means a "money-saving" architecture. Its real value is "spending more tokens to buy better results + shorter wall-clock time," and "swapping in cheaper models" is merely an optimization for lowering the per-token cost. So the more precise statement is: the advantage of multi-agent is concurrent performance and the flexibility of model combination, not absolute cost savings.

3.7 What orchestration / communication patterns does multi-Agent have? 🟡

My question: Roughly what orchestration or communication patterns does multi-agent have?

H's answer (three):

Master-slave: a master agent decides which agent to call right now, with several agents below it in parallel.
Sequential orchestration: like a fixed workflow, run the agents in order.
Loop-style: like ReAct — run, check, and if it's not done, run another round.

🟡 I said "I roughly get what you mean, but it's not quite right," and gave a clearer classification:

💡 Multi-Agent orchestration / communication patterns (my answer):

Call a sub-agent like calling a tool: the master agent tells the sub-agent what to do and hands it the task. In Claude Code / Codex you'd use a cheap model for tasks like searching and reading code, and once the sub-agent is done it returns a simple summary to the master agent.
Agents talk to each other / share a document: build a shared intermediate document and constrain them to "write whatever ideas you have into this document," communicating through the document.
Peer or hierarchical: the core is whether there's a hierarchy — it can be master-slave, or peer-to-peer.

3.8 What are your own techniques for writing code with AI? 🟢

My question: When you write code with AI yourself, what are your techniques?

H's answer:

Have the AI first produce something like a requirements doc, so it's clear about what we're doing right now, and go step by step.
Have it lay out the work pipeline first, then go do it, so it's less likely to get halfway through and lose track of what it's doing.
Put repetitive conventions straight into a file like CLAUDE.md as fixed context, so you don't have to re-declare them each time — it reads them itself.

🟢 This was answered pragmatically, with real feel for it (requirements-first + pipeline planning + crystallizing conventions in CLAUDE.md). It's an open-ended question with no standard answer, but the way he answered made me feel he'd genuinely used it.

Part 4 · Debrief + reverse-question round (my "exclusive stash")

After the interview ended, I spent nearly 20 minutes on a debrief and sharing real-world experience. This part is the most valuable content of the whole session for H, and it's also the part I cover in every mock interview but that very few people have written out systematically.

4.1 The to-study checklist for H

🔴 RAG: completely doesn't understand it; his biggest weakness.
🔴 Agent Evaluation: needs to fill it in.
🟡 Newer things like OpenClaw / Hermes / Skills: skim them lightly, enough to "hold your own / get by" in an interview.
Overall feedback: he was suddenly a bit unfamiliar with his projects (he said himself he'd been fluent on them just two days ago); he needs another pass.

4.2 The reverse-question round: be "aggressive"

I've stressed this repeatedly — your reverse-question time absolutely must be aggressive, especially when facing a founder / CEO, where you can challenge them directly.

① Ask directly about product competitiveness (prerequisite: you understand the space and the product)

Ask straight up: "What advantages does your product have over competitors?"
I asked exactly this in my own second-round interview, and discussed it with them for half an hour.
The logic: if a founder isn't even confident in their own product and can't articulate how it differs from competitors, you can write this company off (they may just be there to bait funding).

② Ask about the project's release cycle (especially for startups)

Get clear on it: is the product in development, in closed beta (round one / round two of closed beta), or already launched?
By analogy to how games split closed-beta rounds, ask down to the specific stage.

③ Ask about the business model / revenue projections (note: not everyone is willing to answer)

You can ask about next quarter's expected ARR (annual revenue), MRR (monthly revenue) magnitude, target user count, target revenue.
The revenue model has nuances too: you can't price out of thin air — you look at competitors' pricing logic — is it subscription or usage-based (API metering).

④ Ask about team size

Ask about the company's total headcount + the engineering team's headcount.
Ask who your mentor will be — definitely get this clear, because many roles claim to be agent development but once you're in you do traditional development, never touching agents.

⑤ Talk about growth (my personal preference)

I like talking about growth and target customers.
My view: an early-stage startup's engineering team doesn't need that many people; what it needs more is a growth team — building the product isn't the finish line; how to publicize it and get everyone to know about and use it is what matters.

4.3 How to "soft-handle" questions you can't answer

I shared a few moves for dealing with questions you can't answer:

① Pivot via "room for improvement"

For example, when asked about your memory system, you can say: "I do think my memory system isn't done that well, and there's a lot of room for improvement." Then ride that into your thinking.

② Proactively bring up things not on your résumé

I discussed this in the interview — what's written on the résumé is only 30%-50%; what I'd rather do in this hour is draw out the things that aren't on the résumé.
So: if a project has iterated (it's already at v2, v3, but the résumé is still stuck at v1), you can absolutely bring that up unprompted.
On a cutting-edge topic like memory, you can proactively say: "I recently read some fairly new papers and have some ideas..."
- Benefit one: it proves you've thought deeply about the project and are continuously iterating, rather than finishing it and dumping it on the résumé.
- Benefit two: it shows you follow the frontier.
- ⚠️ But read the room and manage the pacing — I got interrupted plenty of times myself this morning.

③ For brain-dead fundamentals, just admit it + dissolve it with an AI angle

An example I gave: asked "the difference between threads and processes" or "how to do inter-process communication," I just say I forgot / don't know.
But add: "There's AI now; if I hit this problem in engineering practice / an internship, I'd definitely use AI to search and solve it. If it's a domain I've never touched at all, I'd worry about a single AI hallucinating, so I could use multi-agent to cross-verify."
This kind of answer sounds very pleasant and cleverly dodges the brain-dead fundamentals question.
My attitude: fundamentals questions are brain-dead to begin with; who still asks traditional fundamentals now that there's AI (but some interviewers still test them, see the résumé advice).

4.4 Other questions worth asking in the reverse-question round

① Ask about the development program (depends on the company, depends on your own performance)

Prerequisite: first assess your performance in this interview. If even you don't think you're a sure pass, there's no point asking this kind of question — better to ask something else.
When you're confident, you can ask: does the company have a complete intern development program? Who's the mentor?

② Reverse-engineer your interview performance via a "challenge question"

Ask: "For the role you're hiring for, what do you think the biggest challenge of the internship would be?"
This kind of question suits big/mid-sized companies (they usually won't directly reveal your performance at the end of the interview).
You can reverse-engineer the interviewer's assessment of today's performance from the answer to this question.

③ "Besides money, what else can I get from joining the company?" — ask with caution

This question is better asked once you have plenty of offers, otherwise it's a bit inappropriate.

4.5 The big RAG primer (filling in everything H couldn't answer)

Because H completely doesn't understand RAG, I gave a whole long section on it. This is the complete RAG knowledge map, and it's the checklist I personally run through every time I prep RAG questions:

RAG's overall flow has three steps: ① vectorize → ② store in a vector DB → ③ recall. Every step can be dug into.

Step one: how to store vectors (vectorization + chunking)

Dimension choice: more dimensions = more information, but storage cost is higher too — that's a trade-off.
Key insight: vector distance is only an "approximation" of semantic distance (in the interview I said "close vectors ≠ close semantics," which strictly speaking isn't entirely accurate — embedding models are trained precisely to make "close vectors ≈ close semantics"; but this approximation frequently distorts: homonyms, negation semantics, domain mismatch, content outside the training distribution all decouple vector distance from true semantic distance. A large part of RAG's pain points hides in this "approximation distortion").
Chunking strategy:
- chunk size: the strategy for how big to cut a chunk.
- chunk overlap: there should be overlap between chunks, to avoid "cutting on the dotted line" and breaking the semantics. A common practice is 10-20% overlap (e.g. a 500-token chunk with 50-100 tokens of overlap).
  - The "apple" example I gave in the interview — the two characters of "苹果" getting split — is strictly not quite right; modern chunking is token-level or character-level and won't actually cleave the two characters of "苹果" apart. A more accurate example: "Apple released a new product. This product is powered by the M5 chip" — if you cut between the two sentences, the latter chunk loses its subject, so you can't recall the semantics of "Apple released the M5." That's the real problem overlap solves.
- late chunking: vectorize the whole document first (with a long-context embedding model), then chunk — that way each chunk's embedding "knows" the full-document context and preserves long-range semantic signal.
- how to chunk PDFs / images: this is a dedicated difficulty (some tools/solutions handle it).
- embedding model selection: which embedding model to use is also a point you can go deep on.

Step two: storing (not much to say at the moment)

Step three: recall (retrieval), where there's the most to optimize

query optimization: before the user query comes in, you can do rewriting/expansion.
recall count + rerank: e.g. recall Top 50 — do you re-rank? What's the re-rank based on? All optimizable.
recall quality evaluation (two dimensions):
- recall rate (completeness): suppose there are 100 correct answers — did you recall all 100?
- ranking quality: how good is the ordering of what you recalled.

Engineering level

Model fallback strategy (LiteLLM): run LiteLLM in the project for model fallback — if the first model provider goes down, automatically switch to the second.

💡 This whole section maps directly to that "biggest pain point of RAG" question in 2.2 that H couldn't answer — the pain points hide in the trade-offs at every step: close vectors ≠ close semantics, chunk boundaries breaking semantics, recall rate vs. ranking, dimensions vs. cost.

4.6 Treat the interview as "making friends / exchanging ideas," don't get one-sidedly interrogated

This field is very new, so an interview can be treated as a chance to make friends — don't put too much pressure on yourself; go exchange ideas like you're chatting.
Manage the interview's pacing — don't let it become a one-sided interrogation. Grilling for the answer itself is pointless; getting grilled for an hour and not even landing the offer is a pure loss.
A reverse-question technique: when the interviewer asks you something (say "what are your vibe coding techniques"), after you answer in three sentences, turn around and ask the interviewer for their take: "I'm not too familiar with this; I'd love to hear your insights."
- Flatter them a little — as long as the interviewer isn't out of their mind, they'll basically be happy to share.

4.7 The "gear" techniques for the live vibe coding round

I shared practical techniques for doing screen-shared vibe coding problems:

Typical format: share your screen and vibe code live.
The core mindset: no matter how simple the problem, pile on all the advanced gear.
- Open your most expensive vibe coding software.
- Definitely install skills (never mind whether they're useful — installing them earns you big points with the interviewer).
- Or use MCP — basically pile on all the fancy stuff.
- To install skills, don't install from GitHub; install from skills.sh (that website Vercel put out).
Use the waiting time: vibe coding has wait time, during which you can open another model on the side (Claude / ChatGPT — don't use Gemini, too bush-league) and chat about technical choices or search for competitors' solutions.
My real case: I was asked to whip up a "video-editing framework" (a project my co-founder and I are building), and during the wait I chatted with the interviewer about other players in the space and searched the web for competitors.

4.8 Résumé revision advice (the scattered tips at the end)

Put a tech stack on the résumé (H left it out).
Put professional skills at the bottom and projects up top.
You can write a bit more for professional skills.
Get your projects live where possible: build a website or get it deployed; if all else fails, put the repo link on there.
- (H's situation: Project Two isn't done yet; he plans to finish it before summer and then attach a link. It's a client tool, possibly with no frontend/backend.)
You still have to memorize some backend fundamentals — some interviewers (the "moronic interviewers" I griped about) will test them.

One-line summary (my assessment as the interviewer)

| Dimension | H's performance | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 🟢 Answered well | the memory-system consolidation mechanism, the stable-front-loading idea for prefix caching, the dedup/merge trade-off for the memory cap, the async interaction design, judging skill-description verbosity, the AI-coding methodology | | 🟡 Off / incomplete | tangled phrasing on consolidation, thin vector-store knowledge, vague MCP vs. Skills, incomplete token-saving, didn't fully answer multi-agent advantages, imprecise orchestration patterns | | 🔴 Couldn't answer | why delete context directly, preserving the prefix cache in Plan mode, the Skills awareness mechanism (frontmatter), Agent Evaluation, the full RAG stack |

The three areas I'd most recommend H fill in: RAG (the whole flow from vectorization to recall reranking), Agent Evaluation, and the engineering trade-offs between prefix caching and the tool list.

The core mindset I most want to share: be aggressive in the reverse-question round, soft-handle questions you can't answer with an "AI angle + room for improvement," treat the interview as an exchange rather than an interrogation, and pile on all the advanced gear for vibe coding.

A final word (a few feelings as the interviewer)

With every candidate I mock-interview, I understand one layer deeper —

The core of an Agent engineer interview has never been "how much you know," but "whether you can clearly explain the things you've done."

H's project is actually well made — the consolidation mechanism shows thought, the prefix caching has real feel, the async interaction is a genuine highlight. But several times he clearly did the right thing yet couldn't explain "why he did it that way" (e.g. that question about cutting context directly — he could absolutely have defended it with "I have consolidation as a backstop," but didn't realize it).

This is a problem most candidates share: they finish and stop, missing the "reverse-SSH-into-your-own-brain" debrief step.

If you're also prepping for an Agent-track interview, my advice:

Ask "why" of every single design decision in every project — only if you can say it clearly in one sentence do you actually understand it.
For every sentence you write on your résumé, ask yourself "if this gets dug into three layers deep, can I answer?" — if you can't, don't write it.
RAG / Agent Evaluation / prefix caching — these three are the high-frequency deep-dive zones in 2026 Agent interviews — don't wait to be asked before filling them in.
Being aggressive in the reverse-question round isn't about one-upping the interviewer; it's about screening the company — many people don't dare do this, but the effect is striking.

About the paid service

Going forward I'll keep compiling these kinds of paid mock-interview debriefs. Each one will try to preserve the real follow-up chain, the candidate's raw answers, my on-the-spot judgments, and the standard thinking I add afterward.

A mock interview isn't just "practicing answers"; more than that, it lets you go through a complete experience of "being seriously interrogated" at the lowest possible risk. Once you've been through it once, your fear of the real interview drops by an order of magnitude.

If you're also prepping for an Agent-track job search but don't know how to revise your résumé, how to pitch your projects, or how to prepare for the interview, I currently offer these three 1v1 services (please get in touch for specific pricing):

| Service | Price tier | Who it's for | | ------------------------------ | ---------- | ----------------------------------------------------------------------- | | Résumé revision | ￥ | you have a résumé but don't know how to "pitch" it so the interviewer's eyes light up | | 1v1 mock interview | ￥￥ | interview coming up, need a complete live run-through + debrief | | Learning roadmap / onboarding companion | ￥￥￥ | total beginner or lacking direction, need a 1-3 month weekly companion |

Contact: WeChat

(note "paid consult" or "mock interview").

—— Joye · joyehuang.me

Interviews Aren't Exams, They're Mutual Selection

Sat, 23 May 2026 00:00:00 GMT

import WechatReveal from '@/components/WechatReveal.astro'

Before we start

This is my fourth blog post about getting into Agent work, job hunting, and interviewing. The first three were:

A Sophomore Intern's Field Guide to Agent Engineering Interviews — a full retrospective of my own job search, leaning toward "methodology"
What We Actually Talked About in a 1-Hour-19-Minute Mock Agent Engineering Interview — a complete walkthrough of a mock interview I did with interviewer W, leaning toward "hands-on breakdown"
For Everyone Who Wants to Get Into Agents but Doesn't Know Where to Start — an Agent engineer onboarding guide, leaning toward "the lay of the land"

The first three were about how to get started, how to prepare, how to answer questions, how to present your projects — they leaned toward roadmaps and hard skills.

But over these past few months of taking consulting calls, I noticed something: what actually trips most people up isn't skill, it's mindset.

Rewriting your resume eight times and never daring to send it. Finishing one interview and immediately moving on to the next without any review. Asking "so what does your company actually do?" in the closing questions. Walking into a founder interview positioning yourself as "an intern candidate on trial"... none of these are skill problems. They're a fundamental misunderstanding of what an interview even is.

So this post is specifically about mindset — more precisely, about how to redefine what an "interview" is, and how your techniques should change under that new definition.

1. An interview isn't an exam, it's mutual selection

I know this line has been repeated to death, but most people say "mutual selection" out loud while still putting themselves in the seat of the accused.

When I take consulting calls, I keep seeing the same state of mind: rewriting the resume eight times and still not daring to send it; treating every interview as "an exam I must pass"; caring only about "did I pass?" afterward instead of "what did I learn?"

This mindset is the root of every other problem.

Relax. Seriously.

Especially in the Agent space — it's too new. So new there are no standard answers, so new that interviewers are still figuring it out themselves, so new that a lot of interviews end up being two peers swapping workflows. You're not there to "pass" an exam. You're there to talk with someone who might become your colleague, and to confirm whether you both want to build the same thing.

If you never send the resume, you'll never know what's wrong with it

A lot of people rewrite their resume eight times and still won't send it. The excuses are "let me polish it a bit more," "let me finish one more project first," "applying now would waste the opportunity."

But here's the reality: only an interviewer can tell you everything that's wrong with your resume.

Read your own resume eight times and you'll have fixed everything you're capable of catching. The remaining issues — the ones that "look fine but are actually problems" — you'll only discover when someone actually books an interview off that resume, asks you questions, drills into a detail until you get stuck, and ultimately rejects you.

My own first Agent-focused resume wasn't bottled up until perfect before I sent it either — I just shipped it out. What actually turned my resume from "I think it's okay" into "it lands interviews and offers" wasn't closed-door polishing before applying. It was the real feedback from the first three or four interviews — which project interviewers drilled into most, which technical term they found least interesting, which detail suddenly made their eyes light up.

So treat your first few interviews as practice. Put the companies you love in the middle-to-late slots, and use 2–3 "warm-up companies" up front to expose the problems. This is the most efficient way to debug a resume, bar none.

Treat the interview as debugging — your resume is the code, the interviewer is the test case. Without running the test case, you'll never know where the bug is.

What you're really afraid of: you overestimate the cost of "failure"

The deeper reason a lot of people won't interview is: they're afraid of rejection.

But think it through — in the Agent space, what's the real cost of getting rejected?

Not money (interviews are free). Not time (one interview is an hour). Not opportunity (there are plenty of companies). The only real "cost" is a momentary bruise to your ego.

And what's the upside of getting rejected? Real, external feedback — where you weren't clear enough, which project lacked depth, which technical point you hadn't prepared for, what signals the interviewer's reactions gave you.

The cost is a few hours of frustration; the upside is a real calibration far more useful than "carrying your resume around online asking people how to fix it." Because when you edit it back and forth online, what you're changing is ultimately just the content on the page. But in a real interview, the resume might only account for 50–70% of what's being assessed — the rest is how you present, how you handle follow-ups, how you explain your trade-offs on the spot. No matter how you do the math, this is a guaranteed win.

2. Interviewing continuously is the moat in this field

This is the point I most want to emphasize, and the one I talk about most in consulting calls — yet it's also the most counter-consensus.

By "interviewing continuously" I don't mean job-hopping. I mean regularly putting yourself in front of the external market to calibrate.

Most people's attitude toward "interviewing while employed" is either "looking around while still on the payroll feels dishonorable" or "I just started, I'd feel awkward going to interviews." But let me offer a completely different angle:

Interviewing is one of the few opportunities you have to forcibly calibrate yourself against the outside world.

I'm currently interning at a unicorn, but I've kept interviewing throughout my time employed — something I've explicitly discussed with my current company, and which the company permits. I'm not just interviewing to "find the next job"; more than that, I'm doing it to confirm what the work I'm doing right now is actually worth out there.

Inside a company, your level is "encapsulated"

When you write code inside a company day to day, your level is encapsulated by your desk, your project, and your colleagues' perception of you.

Stay on the same team long enough and it's easy to take the current project's evaluation system, tech choices, and workflow as the default frame of reference. It's not that they're bad — it's that your coordinate system narrows. It becomes hard to know how outsiders would judge the same project, the same technical trade-off, the same way of collaborating.

These "assumptions" are very hard to fully verify from inside the company.

I'm not saying there's no growth environment inside a company. A good team will of course keep sharing AI developments, discussing new tools and workflows, and people will give you feedback. But internal discussion has an inherent problem: everyone is facing the same kind of business, the same tech debt, the same organizational context, so thinking easily ends up circling within the same framework.

So you need outsiders. That's exactly where the value of interviewing lies — it forces you to re-explain your projects, your tech stack, and your way of articulating things in a different environment.

After one interview, you immediately learn:

The project you're proud of — what will peers out there ask after hearing about it? Which point do they drill into most?
The technical point you thought was rock-solid — has it already been replaced by a newer approach?
The workflow you take for granted at your company — are peers outside using something completely different?
What's the current salary range for this kind of role (if it comes up)?

More importantly, the interview itself is an output test: having built something doesn't mean you can explain it clearly; being able to drive a project on your team doesn't mean an outsider will understand your judgment the first time they hear it. An interview forces you to reorganize your projects, trade-offs, and thinking into language other people can follow.

The Agent space especially needs this calibration

There's no textbook for the Agent space. Every company's path is different.

You might think at Company A that "memory should obviously be done this way," then interview at Company B and find their thinking is completely different — and it's not necessarily a matter of who's right or wrong, just a different path.

You might use LangGraph smoothly at Company A, then interview at Company B and hear "we've already dropped all frameworks and built our entire Agent Loop in-house"; you might use RAG to solve the knowledge-base problem at Company A, then interview at Company B and hear "we've moved entirely to LLM Wiki + Prefix Cache."

So what really matters isn't "you must keep interviewing forever" — it's that you need to keep taking in new things and learning new things. Interviewing is one method. Reading frontier articles is one method. Talking with peers outside is one method.

But for students and interns who haven't graduated yet, interviewing has an exceptional return on investment. It compresses external information, articulation practice, project feedback, and market judgment into a single hour, forcing you through one high-density calibration.

A few of my own observations:

If someone only learns inside their company, it's easy to see only their current team's problems and solutions
The Agent space changes too fast — a completely different engineering paradigm can emerge in just six months

When interviews end up discussing "how you use AI," it's really peer exchange

The further into the interview process I go, the more I notice one thing: interviewers care less and less about "assessing" you, and more and more about "aligning your understanding" with theirs.

In my most recent interviews, the closing stretch almost always covers questions like:

"How do you use Claude day to day?"
"How do you manage your Skills?"
"When you write code, is the AI in the lead or are you? What's the rough split?"
"What's the most inspiring Agent-related article you've read recently?"
"What do you think of XX company's product?"

These questions aren't "assessing" you anymore — they're aligning worldviews with you.

The value of this kind of exchange isn't to replace internal company sharing sessions — good internal sharing is of course very useful — it's to give you a completely different external perspective. You learn how other teams use AI, how they organize Skills, how they understand product and engineering trade-offs; even if you don't walk away with one directly reusable workflow, the alignment of understanding itself is valuable.

A note on boundaries

I have to add one thing here: the premise of all this is that your company permits it, or that you exercise good judgment about the boundaries yourself.

Don't interview on your company laptop/network
Don't interview during work hours (take leave, or do it after work)
Don't interview with direct competitors (this is a bottom-line ethics issue)
Don't leak your current company's sensitive information during interviews

This is basic professional ethics. "Continuous calibration" is not the same as "disloyalty" — as long as you keep those boundaries in place, your current employer generally won't have a problem with it. My own employer explicitly knows I do this and is supportive of it.

3. Record and review: let AI be your personal interview coach

Record your interviews (for personal use only — never share them). Almost everyone will tell you this, but how you use the recording is what matters.

Many people listen to the recording trying to remember from memory "where did I just stumble?" — which is very inefficient and genuinely painful (hearing your own voice is one of the most awkward things in the world).

The more efficient approach is: use AI to turn the recording into a reviewable interview log.

How to actually do it

Today's mainstream tools — ChatGPT, Claude, Gemini — all support audio input. You don't need to transcribe first; just drop the entire interview recording in.

The most basic use is having it produce a list of interview questions — in chronological order, each question paired with the key points of your answer. But the genuinely valuable uses are these:

1. Have the AI infer where you stumbled. You don't have to tell it where you got stuck — it can judge, from the pauses, filler words, and signals like "um," "uh," "how do I put it" in the audio, exactly which questions you struggled with. Far more accurate than your own recollection.

2. Have the AI play that company's interviewer and grade you. Give it the interview recording + company background (the role you applied for, a rough picture of the company), and have it grade each of your answers from the angle of "if I were this company's interviewer," pointing out where your logic jumped, where you missed the point, where you actually over-egged it.

3. Have the AI ask you again. Have it re-ask the extracted questions in a different phrasing — it's basically a free practice partner. You can say your answers out loud in your own room, then have it critique them — a complete iteration loop.

4. Find systemic problems across interviews. This is the most valuable approach — after three to five interviews, drop all the recordings in together and have it find the "recurring weak points."

A single-interview review only shows you "where I answered poorly in this one"; a cross-interview review shows you "every time I'm asked about Memory design, I can't explain it clearly" — that's a systemic problem, ten times more important than a one-off slip.

5. Have the AI teach you the questions you couldn't answer. When you hit a question you can't answer in the interview, write it down first. Afterward, have the AI give you a reference answer — it's free, tailored to your specific interview context, and the most relevant study material there is. Far more useful than opening Google and searching "common Agent interview questions."

Two things to focus on when reviewing

Whether your answers are precise.

Take a recent example from a student I did a mock interview with — the interviewer asked him "what are Claude's Skills," and his initial answer went like this:

"Um, Skills are a product form Anthropic introduced, it's in the shape of a folder that contains a SKILL.md and some tool scripts, and Claude can load these Skills when needed to augment its capabilities, like generating PPTs, Excel, that kind of thing..."

Only during the review did we realize: that took 60 seconds to say, but the core information was really just three keywords — progressive disclosure, SOP standardization, easy to share.

Trimmed down, it should be:

"Skills are Anthropic's product form for packaging an Agent's capabilities into loadable modules. They solve three problems — progressive disclosure (capabilities aren't all loaded into context up front, only when needed), SOP standardization (writing out 'when to use which tool, and how' clearly in natural language), and easy to share (a single folder is a complete capability package that can be distributed, reused, and versioned)."

Same two minutes, but the second version is three times as information-dense as the first — that's the difference precision makes.

The interviewer's reactions.

What you can hear in the recording isn't only your own answers — it's also the interviewer's reactions. Those reactions often tell you more about what needs fixing than your own answers do:

Where did they follow up? A follow-up means the point either hit their interest or you didn't explain it clearly — both cases are worth revisiting
Where did they go "mm-hm" and move on? That usually means they didn't follow, or weren't interested — phrase it differently next time
Where did they start talking themselves? That's a golden signal — you hit a topic they wanted to discuss, and you can reuse it at similar companies next time

My own experience: the interviewer's reactions carry 2–3x more information than your own answers. Learning to "listen to the interviewer" is the biggest dividend of reviewing recordings.

4. Closing questions: the information gap is your leverage

The closing-questions segment is absolutely not a "throw in a question for the sake of it" segment — it's the highest-information-density part of the entire interview, and the part where you show how seriously invested you are in this interview and this role.

Why? Because during the forward Q&A, the interviewer is evaluating you; during the closing questions, you're evaluating the company. The pace of the former is controlled by the other side, so it's hard to proactively learn the company's true state; what you can mine in the latter is information that's never made public but that insiders face every single day.

The essence of closing questions is information-gap arbitrage

The JD and the website are the company's external messaging — repeatedly polished by legal, HR, and marketing, the information in them is a packaged version. But the information that comes out of the interviewer's mouth is what the company actually looks like.

So your closing questions should target the things that "won't be written publicly, but that an insider can explain clearly the moment they open their mouth."

Ask for the real details of the business.

For example, I personally lean toward 2C and overseas business, so I'll directly ask whether they're 2B or 2C, domestic or overseas, what the main profile of their paying users is, whether they're comfortable sharing ARR/MRR at an order-of-magnitude level (you won't necessarily get a specific number, but you can read the rough tier from their reaction).

The JD won't necessarily spell these out, but they're crucial for judging "should I go?" — a team doing overseas 2C and a team doing domestic 2B differ in everything: culture, pace, tech choices, promotion paths.

On "will asking such detailed questions come across as abrupt?" — it absolutely won't. Someone who genuinely wants to join should be asking these things in the first place. The more specific your questions, the more the interviewer will think "this person is actually evaluating our company, not mass-applying."

Ask for the team's real state.

"After this role joins, what's the most important problem to solve in the first three months?"
"Is this a newly created role or a backfill? If it's a backfill, what capability does the team hope the new person fills?"
"What type of person does the team most lack right now?"
"If I join the team, which business line or module am I most likely to be involved in early on?"

These questions look ordinary on the surface, but the answers hide a lot of information. Take "what problem needs solving in the first three months" — it directly tells you whether the team has a real, clearly defined gap or is just vaguely "wanting to hire someone." Same with the backfill reason: if they can candidly explain what the team lacks and what problems the previous person left behind, that itself is a real signal.

Ask for performance feedback.

Big companies usually have compliance requirements that make it inconvenient to evaluate candidates directly, but interviewers at small companies and startups are often very willing to talk.

Direct version: "How do you think I did in this interview? What did I present well, and what not so well?"
Tactful version: "If I wanted to join the team and excel at this job, where do you think I still need to improve?"

The tactful version is more universal — it turns "evaluate me" into "how should I improve," which is easier for the other side to answer, and the answer often carries more information than a direct score.

My own success rate with this trick is very high — about 80% of interviewers give at least 2–3 concrete pieces of feedback. Once you have that feedback, it's a precise upgrade manual for your next interview.

5. When interviewing at startups, ask these extra questions

A startup isn't a "shrunk-down big company" — the things that matter are completely different.

Many people still apply the big-company closing-question template when interviewing at startups — asking about the tech stack, overtime, benefits — all of which are secondary for a startup. The factors that truly decide whether you should join a startup are different ones entirely.

The team

Because headcount is small, you absolutely must get clear on:

Who's your mentor? This person is the single biggest variable affecting your growth at a startup. Whether the actual mentor on a 0-to-1 project is the founder themselves or some engineer with one year of experience are two entirely different experiences
Exactly how many people are on the team? "The engineering team has 20 people" and "the AI team has 3 people and you'd be the 4th" are completely different signals
Who do you report to? Reporting directly to the CEO and reporting to some middle leader are two completely different work rhythms

The difference between one person and five is enormous. On a team of five you might own a sub-module; on a team of one you are the entire AI of the company — the former lets you specialize, the latter lets you sweep across the whole line. Both paths have value, but you need to know which one you're choosing.

Pay attention to the GTM team, not just the engineering team

This is something a lot of people overlook: at big and mid-sized companies you can ask about the engineering team's makeup, but at a startup, the GTM (Go-to-Market) team is just as worth paying attention to.

Why? Because for a startup product, "how to sell it / get it out there" is often harder than "how to build it."

Teams that can technically build an Agent product are everywhere in 2026; but the teams that can get that Agent product in front of users, build word of mouth, and drive retention or customer conversion — those are the ones that actually survive.

For a ToC product, you can ask:

"How many people are on your growth team? What are their backgrounds?"
"What channels is customer acquisition mainly relying on right now? SEO? KOLs? Community? Paid acquisition?"
"Roughly what's the ratio of overseas to domestic users?"
"If you're comfortable sharing, roughly what level are your customer acquisition cost (CAC) and retention numbers for the most recent quarter?" (Very few people dare to ask this, but if you do and they're willing to answer, the information density is extremely high)

For a ToB product, you'd switch to a different set of questions:

"Do you have customers already using it? Is it a pilot, a POC, or paying for real?"
"Who are the target customers? Who's the buyer, the user, and the decision-maker, respectively?"
"Is sales mainly the founder doing BD personally right now, or is there already a sales / customer-success team?"
"From a customer's first contact to actually going live, roughly how long does it take? Where are the bottlenecks usually?"

If a startup's engineering team is 30 people but GTM is just 1 full-timer + 1 contractor — that's not an instant death sentence, but you absolutely must keep probing: what exactly are they relying on to push the product into the market?

Product status

Is the product already launched, or still in development? If the latter, be sure to confirm the specific launch plan, down to the month or quarter.

I've seen far too many startups say "we're almost there" — and then "almost there" drags on for two years without launching.

The right way to ask:

"Is the product currently live, in closed beta, or still in development?"
"If it hasn't launched yet, what's the expected launch date? To the quarter?"
"Who's the first batch of target users after launch? How will you acquire them?"
"If two months after launch you haven't hit expectations, what's the team's Plan B?"

That last question is especially important — a founder who has thought about Plan B and a founder who hasn't are two completely different tiers of leader.

6. The killer move for interviewing founders

If you're interviewing the founder, and you understand the space, you can ask directly:

In this space, how do you plan to beat your competitors?

If a startup founder doesn't have a clear understanding of their own product and their competitors, that's a very strong risk signal.

The prerequisite for using this move: you genuinely have to have studied the space

Otherwise, when the founder turns it around and asks "well, what do you think we should do," it gets awkward if you can't field it.

So this is essentially a small-scale battle, not a one-way question.

The right posture is:

Spend 30 minutes doing homework before the interview — who are the company's two or three main competitors, what are their respective strengths and weaknesses, how do others in the market view this company
Throw out "how do you plan to beat your competitors" during the closing questions
Have your own answer ready — even if they turn it around and ask "what do you think," you can lay out 2–3 logically sound points

This posture instantly upgrades the founder's read on you from "intern candidate" to "potential early member."

How I talk with founders

In my own second-round interviews with CEOs or founders, I basically don't talk about tech.

Instead I talk about:

The prospects of the product's space — where's the ceiling for this space over the next 2–3 years? What stage is it at now?
Competitors' strengths and weaknesses — why is A better than B? What's B's moat?
The technical direction and goals for the next quarter — what's the team's priority right now? Why this one?
Growth strategy — is the product's biggest bottleneck right now technical, growth, or funding? How will you solve it?

I especially love talking growth with founders, because I do growth-related work myself (inside my company I've been involved in user growth, content strategy, building out Tracking & Analytics, and so on), so I have a real feel for it.

Talking growth with a founder is essentially demonstrating your "founder mindset."

What a startup founder lacks most isn't people who can write code — people who can write code are everywhere, especially in the AI era. What they truly lack is someone who can think alongside them about "once it's built, how do we sell it."

If an undergrad can talk growth with a founder for half an hour, market for half an hour, competitor strategy for half an hour — the founder's read on you shifts from "intern candidate" to "potential early member." Conversion to full-time, getting handed core projects, even early-hire treatment — it all starts from that judgment.

The smoothest interviews I've had myself — all of them, without realizing it, ran past 1.5 hours, the whole conversation more like two partners discussing how to grow the company than an interview. The offers I got in that state were all very high quality.

The "reverse evaluation" at overseas startups

Also, a lot of overseas startup CEOs will chat with you about plenty of personal topics — behavioral questions, what you're proudest of, your personal interests, and so on.

Don't deal with these questions like they're an exam. All of them are worth going deep on.

Why? Because for early-stage startups overseas (especially Silicon Valley ones), what matters most is "Founding Team Fit" — whether your vibe meshes with the founding team, whether your values align, whether your long-term vision is consistent.

They're not worried about tech — everyone started from zero; but "are you the person who'll still be on Slack discussing an idea with me at 0:11 in the morning" — that can only be judged through behavioral questions.

So when you hit a behavioral question, don't phone it in. Tell a real story, share how you genuinely felt, talk about what you truly care about — this matters more than any technical question.

The flip side: if the founder won't talk about these things with you

If you're interviewing the founder, but the whole interview he only wants to quiz you on technical questions and won't talk product, space, or vision with you — this company may not be worth going all in on.

Because at the very least it shows that, in this conversation, he's more inclined to treat you as "current labor" than as "a future person."

A founder who genuinely wants to grow big, when interviewing a potential early member, will proactively talk vision, roadmap, and ideas — because he knows this is the most effective weapon for attracting talent.

If a founder doesn't even have the interest to talk vision during an interview, then this company's ceiling is probably right there. Of course, don't draw conclusions from a single question; look at whether, across the whole conversation, he proactively revealed his own judgment, roadmap, and ambition.

7. Some peculiarities of Agent roles

Finally, let's talk about the role itself. The Agent space has a few traits that shape how interviews play out:

No standard answers

So the interview is more like a two-way exchange. You can absolutely turn it around and discuss a design choice with the interviewer — "I used to use ReAct, but I found that once the number of tools exceeds 10, selection accuracy drops, so we later switched to Skill routing + subagents. How does your team handle this problem?"

Expressing "I have my own judgment" matters ten times more than "I memorized this knowledge point."

The Agent space is too new — interviewers are still figuring it out themselves. If you can voice an opinion with judgment behind it (even one that differs from theirs), they'll immediately reclassify you from "applicant" to "peer."

Interviewer quality varies wildly

Some interviewers haven't done Agent work themselves, so their questions may be very surface-level ("are you familiar with ReAct?" "have you used LangChain?"); others are very deep and will directly ask you "how do you handle context explosion," "how do you do Eval," "how do Subagents share Memory."

Mindset-wise: don't get cocky with the former, don't panic with the latter.

When you hit a surface-level question, don't phone it in just because "the question is too easy" — this is your chance to show

how clearly you can explain a fundamental concept

. Being able to explain ReAct clearly in three sentences impresses an interviewer more than being able to rattle off 10 framework names.

When you hit a deep question, don't panic just because "you can't answer it" — nobody understands everything. Being able to say "I haven't done this in depth, but my understanding is XXX, and our team handles it with YYY — what do you think?" — that kind of answer beats faking it 100 times over.

Your project experience will be drilled on, detail by detail

The biggest trait of Agent projects is that

they look impressive but are easily just a wrapper

— an "AI health assistant" vibe-coded with Cursor + Claude Code and an Agent project where real engineering trade-offs were made look identical on the surface, but the interviewer can tell them apart the instant they start drilling.

So interviewers use detail questions to distinguish them. Prepare three questions for each of your projects in advance:

Why did you design it this way? (Why) — why RAG and not LLM Wiki? Why LangGraph and not Vercel AI SDK? Why Claude and not GPT?
What pitfalls did you hit? (How it failed) — what problems did you run into? How did you spot them? How did you ultimately solve them? This question is hugely important — it can even distinguish at a glance whether this was a bootcamp project, a reworked open-source project, or something you genuinely built yourself. A project you really built will always have pitfalls, and those pitfalls are the most valuable experience.
If you redid it, what would you change? (What you learned) — looking back now, which decision did you get wrong? Why was it wrong?

If you can explain all three questions for every project for 5 minutes or more, you're already ahead of 80% of applicants.

When you hit a question you can't answer, just admit it

The Agent field updates too fast — nobody understands everything.

The best answer isn't to wing it, but:

"I haven't done this in depth, but my understanding is XXX — how does your team handle it?"

This move is especially effective in startup interviews — because the other side may be looking for the answer too, and by riding that you turn the interview into a discussion, which actually scores points.

The cost of being caught faking it far outweighs admitting you don't know. I've seen far too many cases of people getting drilled into a meltdown because they faked it — at first they can bluff their way through, but every layer the interviewer probes, you spring another leak, until the whole project's credibility is gone.

The full-stack requirement of the AI era

Why are so many Agent roles effectively full-stack by default? Because from Prompt design, Tool calling, and Memory architecture to frontend presentation, user experience, and the feedback loop — every layer is part of the product experience, mutually coupled, and very hard to cleanly separate.

An engineer who can only call APIs but doesn't understand the frontend can't build a good Agent; an engineer who can only write UI but doesn't understand model behavior can't build a good Agent either. Every experience problem in an Agent is coupled up and down the stack — one interaction detail on the frontend might send you back to change a Prompt, one model hallucination might require a fallback UI on the frontend.

So what the interviewer is looking for isn't "an expert in some single domain," but "someone with a feel for the entire Agent system."

That feel can't be ground out by grinding practice problems — it can only come out in conversation from having genuinely built projects. That's also why interviews in the AI era look more and more like a chat — what the other side is gauging isn't your stock of knowledge, it's your systemic intuition.

A final word

If you've read this far — thank you for taking the time. If this post helped you, feel free to like it at the bottom of the article, or leave a comment with the specific problems, closing-question strategies, and mindset blockers you've run into in Agent interviews; I'll pick the representative ones and keep writing.

Back to this post's core thesis:

An Agent development interview is fundamentally not "assessing / being assessed," but "two people who want to build the same thing confirming with each other whether they're a fit."

This mindset shift looks tiny, but it changes every concrete behavior of yours:

Shift the mindset and you'll dare to send the resume — because this isn't an "exam," it's "finding a fit"
Shift the mindset and you'll dare to interview continuously — because this isn't "looking around on the payroll," it's "continuous calibration"
Shift the mindset and you'll seriously record and review — because this isn't "torturing yourself," it's "deliberate practice"
Shift the mindset and you'll boldly ask hard questions — because this isn't "throwing in a question," it's "information-gap arbitrage"
Shift the mindset and you'll dare to battle with the founder — because this isn't "being put on trial," it's "two-way fit verification"

See the interview as a peer exchange, and you'll find the whole experience is different.

One last thing — if you're already preparing for Agent interviews but stuck on mindset-level problems like "not daring to send the resume," "not daring to interview," "not knowing how to review afterward," I do 1-on-1 mock interviews myself. The biggest value of a mock interview isn't "practicing answers" — it's letting you go through the complete experience of "being seriously drilled" at the lowest possible risk. Once you've been through it once, your fear of real interviews drops by an order of magnitude.

If you need it, add me on WeChat

, with a note saying "paid consulting."

—— Joye

For Everyone Who Wants Into Agents But Doesn't Know Where

Sun, 17 May 2026 00:00:00 GMT

import WechatReveal from '@/components/WechatReveal.astro'

Joye's Agent Engineer Onboarding Guide · v1.0 · Free edition for followers

Updated: 2026-05-17

Opening | Before You Read On

Who this document is for

If your situation lately looks like this — people around you are talking about Agents, about MCP, about Vibe Coding, you see a swarm of unfamiliar terms floating by, you have a vague sense that this is a direction worth getting into, but every time you try to start you get scared off, either because you don't know which term to look up first, or because you open a "30-day crash course" tutorial and close it by page three — then this document is written for you.

I roughly divide readers into two groups, and this material is useful for both:

People with zero programming or zero LLM background: what you need is a "map" — something that shows you what the whole field looks like and where to start walking.
People with some programming background but who haven't really touched LLM applications yet: what you need is a "translation table" — something that builds the bridge between what you already know and this new direction.

After reading this document, you should be able to:

Explain in three sentences what an Agent is and how it differs from an ordinary LLM application;
Know what to learn, and in what order, over the next 1–2 months;
Stop feeling lost when you hear the jargon;
Stop being anxious — knowing that this path has a direction, that it can be walked, and that it's not too late to start now.

Estimated reading time: about 11,000 Chinese characters in the original. At a rate of 350 characters per minute for technical Chinese content, reading it straight through takes about 30 minutes; if you read while looking things up and pause to think, it's more like 1–1.5 hours in practice.

What this document is not

So your expectations land in the right place, let me also be clear about what this material is not:

Not a code tutorial — there won't be large blocks of Python / TypeScript code.
Not a framework manual — it won't walk you through the LangChain / Vercel AI SDK APIs one by one.
Not a paper survey — it won't push Transformer formulas at you or walk you through papers.

If those three things are what you came for, this material isn't for you — I'd suggest going straight to the official docs of a top-tier company. If what you need is "first help me figure out what kind of field I'm even facing" — you've come to the right place.

About the author

My name is Joye. I'm an undergraduate in Computing and Software Engineering at the University of Melbourne, currently in my second year.

I'm currently doing a full-stack Agent development internship at a unicorn company in Shanghai.

Over the past few months I've intensively interviewed for Agent-related roles at 100+ AI companies and received 30+ offers. I wrote these experiences up into two blog posts that are also the "prequels" to this document:

"A Second-Year Intern's Agent Development Interview Playbook" (March 2026, 440 reads) — a complete retrospective of my own job hunt. This post is where I started taking on consulting.
"A 1-Hour-19-Minute Agent Engineer Mock Interview: What Did We Actually Talk About" (May 2026, 199 reads) — a full retrospective of an 80-minute paid mock interview I did together with another interviewer, W. After this one went out I got a ton of reader feedback: some people reorganized and deep-dived their projects using the methods in it and then landed offers at big companies, and others used this post to genuinely understand for the first time how to prepare for Agent development.

Open-source projects (GitHub @joyehuang):

minimind-notes (109+ Stars): a detailed annotated tutorial for building an LLM from scratch.
Learn-Open-Harness: a beginner-friendly interactive OpenHarness tutorial that walks you through the implementation of a real Agent Harness.
skills: my personal collection of Skills built on the Anthropic Skills paradigm.

I'm not the most senior person in the industry, but I've just finished walking the exact path you're about to walk — and that "just walked it" perspective is sometimes a better fit for a guide than the "walked it long ago" perspective.

About the paid services

This document is free. But everyone's situation is different — how your résumé should be rewritten, how your projects should be pitched, how your learning pace should be set, all of these need a specific 1-on-1 discussion. If you need that kind of in-depth help, I offer the following three services (please contact me for specific pricing):

| Service | Price tier | Who it's for | |------|---------|--------| | Résumé revision | ￥ | You have a résumé but don't know how to "tell the story" so the interviewer's eyes light up | | 1-on-1 mock interview | ￥￥ | You're about to interview and need a full live run-through + debrief | | Learning roadmap / onboarding coaching | ￥￥￥ | You're a complete beginner or lack a sense of direction and need weekly coaching over 1–3 months |

A detailed description of each service is at the end of the document. Contact: WeChat

(with the note "paid consulting").

How to use this document

I suggest you read it through in order the first time to build an overall sense of the shape of things. After that, go back to the chapter that resonated most and read it closely a second time.

Read with hands-on practice — after each chapter, pick the one point that struck you most and go search for a related open-source project, read a bit of official docs, or just open an LLM and have it explain it to you. Reading without doing is the single biggest trap in this field.

If you find this helpful, feel free to share it on Xiaohongshu / X with friends who are also preparing. This document gets updated periodically (roughly one version every 3–6 months), and future versions will continue to be free.

Let's begin.

Chapter 1 | Getting to Know AI Agents

Before you can "develop Agents," you first have to be able to "read Agents." This chapter helps you explain in three sentences what an Agent is and how it differs from the things you already know (ChatGPT, APIs, chatbots).

1.1 An imprecise but easy-to-grasp definition

If the large language model (LLM) is a "brain," then an Agent is that brain with eyes, hands, memory, and a body that lets it work in a loop on its own.

A slightly more rigorous statement: an Agent is a system with an LLM as its decision-making core that can perceive its environment, call tools, maintain memory, and complete multi-step tasks through an autonomous loop. Four keywords: LLM, perception, tools, loop.

1.2 What an Agent is not: three common misconceptions

Misconception 1: Agent ≠ chatbot. The core of a chatbot is "conversation"; the core of an Agent is "completing a task" — conversation is just one of the ways it receives a task.

Misconception 2: Agent ≠ a single LLM API call. A single-turn call is "input → output"; an Agent has to have at least one of these to count as an Agent: a loop, tools, state.

Misconception 3: Agent ≠ a form-filling app wrapped around an LLM. Stuffing an LLM into a product where the user fills out a form is no different in essence from "a search box with GPT-4 bolted on." A real Agent should let the model decide for itself "what to do next," rather than running through a human-prescribed flow from start to finish.

One thing to add: back in the early ChatGPT of 2023, you gave it an input and it gave you an output, and that was it. By 2025–2026, the mainstream web versions of ChatGPT, Claude, and Gemini have built quite a few Agent-ified capabilities into the product — web search, code execution, file read/write, MCP tool calls. But this is "vendors packaging Agent capabilities at the product layer for users to use," not "the LLM itself becoming an Agent." The underlying model is still that brain; it can act because there's a whole stack of Agent engineering wrapped around it — and that whole stack is exactly what you're going to learn.

1.3 The Agent four-piece set

Understand these four pieces and you've understood 80% of the engineering substance of Agents.

Brain (LLM): thinking and decision-making. It takes in the current state and outputs the next action (answer the user / call a tool).

Memory: build the intuition in two layers first — short-term memory is the context of the current task (what the user just said, what tool was just called); long-term memory is persistent information across sessions (user preferences, key facts). In engineering practice it's actually further divided into three layers — Working / Short-term / Long-term — which Chapter 5 expands on.

Hands (Tools / Function Calling): the Agent's interface for interacting with the outside world — search engines, code execution, email APIs, database queries are all tools. All the major LLM vendors provide native Function Calling.

Loop (Agent Loop): perceive → think → act → perceive → ... The most classic implementation is called ReAct (Reason + Act). The termination condition is usually: the model decides it's done / it hits a max step count / the user interrupts.

1.4 A minimal Agent workflow: using "order me lunch" as an example

You say to an Agent: "Order me a lunch, under 30 yuan, ideally Cantonese." Internally it runs roughly like this:

Round 1: thinks "first look up nearby Cantonese restaurants" → calls search_restaurants(cuisine="Cantonese") → gets 8 restaurants.

Round 2: thinks "filter by budget" → calls filter_by_price(max_price=30) → 3 left.

Round 3: thinks "I have enough info, give it to the user" → answers directly: "I found 3 — A, B, C. Which would you like?"

Note three key points:

Every step is decided by the model itself — it judges on its own whether to call a tool, which one, and when to stop. This is the most central difference between an Agent and a "hardcoded workflow."
The tool execution is not done by the model — the model only outputs "I want to call this tool"; the actual execution is your program's job.
Memory runs through the whole flow — by the time it's thinking in round 3, the model still remembers the original budget and taste requirements.

1.5 This chapter in one sentence

Agent = an LLM in a loop, repeatedly "thinking a bit, doing a bit," until the task is done.

Chapter 2 | A Map of the Agent Ecosystem

This chapter is written for the people who "have to go look up 10 terms halfway through reading a job description." We won't dig deep into each concept, but we'll lay the terminology map of this field flat, so that afterward, when you read any JD, blog post, or open-source project README, you'll know roughly what each term is talking about.

The whole Agent tech stack splits into five layers. We'll go from the bottom up.

2.1 The model layer: which brain to choose

As of May 2026, the model landscape has split into two regional pools: the three overseas closed-source giants + five domestic open-source players.

The three big overseas closed-source models:

Claude (Anthropic): currently the strongest reputation in Agent engineering. Opus 4.7 is the flagship, Sonnet 4.6 is the everyday workhorse, and both natively support a 1M token context. Its handling of structured output, sustaining attention over long tasks, and tool-calling stability is very mature. For a Coding Agent or complex Multi-Agent work, Claude is the current default choice.
GPT (OpenAI): the all-rounder in overall capability, with the most complete ecosystem and the most stable Function Calling.
Gemini (Google): the strongest native multimodal capability (native understanding of images, video, audio). The top pick for multimodal Agent scenarios.

The five domestic open-source / semi-open-source players (by tier and differentiation):

Qwen (Alibaba Tongyi Qianwen): backed by the Alibaba Cloud ecosystem, Qwen3.6-Plus is strong on Chinese-language scenarios, tool-calling stability, and document processing; the open-source 35B MoE variant runs on a single GPU.
DeepSeek: the poster child for extreme cost-effectiveness. The V4 series is open-source, with prices so low they're nearly free (output pricing is about 1/10–1/30 of Claude's), and a 1M context. For getting started and practicing API calls, DeepSeek is the top pick.
Kimi (Moonshot AI): K2.6 briefly took the #1 spot in the world for open-source models on SWE-Bench Pro, and long context has historically been a strength.
GLM (Zhipu): GLM-5.1 is currently the only flagship coding model fully open-sourced under the MIT license, capable of sustained "8-hour-scale" Agent work. The default choice for on-premise deployment and academic research scenarios.
MiniMax: M2.7's killer feature is multimodality (voice, video) and the cost advantage from its extremely low activated parameter count.

Three pieces of honest advice on model selection:

Bigger isn't better — use models tiered by task. Use a cheap small model for simple intent recognition and routing; only use the flagship for complex code generation and reasoning. This is the key technique for controlling cost.
Most domestic models provide an OpenAI-compatible API endpoint — the same code can switch models just by changing base_url.
Don't bet everything on a single model — a mature project will plug into 2–3 vendors at once and route by task.

2.2 The framework layer: what scaffolding to build with

The mainstream choices fall into two categories: official SDKs and third-party frameworks.

Official SDKs:

OpenAI SDK: the oldest and most stable. But it can only call OpenAI's own models — though, because the OpenAI-compatible protocol is the de facto standard, domestic models like DeepSeek / Qwen / Kimi / GLM can all be called with it by changing base_url.
Anthropic SDK: Claude's official SDK, and the smoothest way to wire up native capabilities like Tool Use and Computer Use.
Google Gen AI SDK: Gemini's official SDK, with the most direct multimodal integration.

Third-party frameworks (in order of recommendation):

Vercel AI SDK (my personal top pick for getting started):

Model-agnostic — import { anthropic } from '@ai-sdk/anthropic' to use Claude, and switching to OpenAI / Google / DeepSeek only changes a single import while the rest of your code stays completely untouched.
It's just an SDK, not a framework — it gives you primitive-level capabilities like "streaming output," "tool calling," and "structured output," and it won't force you to organize your code around its abstractions (Chain / Graph / Node) the way LangChain / LangGraph do. How you orchestrate the Agent Loop is entirely up to you, and that degree of freedom is very friendly to anyone who genuinely wants to understand how Agents work.
The TypeScript / Next.js ecosystem is especially smooth.

LangChain / LangGraph: the most established, the biggest ecosystem, the most extensive docs — but also the most frequently criticized for "abstractions that are too heavy." Unless your project specifically needs LangChain's off-the-shelf components (200+ document loaders, LangSmith evaluation), I don't recommend it as a first stop.

CrewAI / AutoGen / Mastra: aimed respectively at multi-Agent collaboration, enterprise-grade orchestration, and TypeScript full-stack — pick one once you have a concrete scenario.

Advice for beginners: for your first Agent, I recommend going straight to the Vercel AI SDK or a vendor's official SDK — their abstractions are light enough that they won't get in the way of you seeing clearly "what the Agent Loop is actually doing." Don't learn a framework for the sake of "learning a framework" — the framework itself isn't a résumé asset; "what valuable thing I built with some framework" is.

2.3 The protocol layer: MCP and Skills

MCP (Model Context Protocol) is an open protocol Anthropic launched in late 2024 that gives "LLM applications" and "tools / data sources" a standardized way to talk to each other.

An analogy — in the past, every Agent that wanted to plug in a new tool had to write its own adapter code; MCP is like the "USB standard" of the Agent world. Anthropic, OpenAI, Cursor, Cline, and Claude Code all already support MCP — it has become the de facto standard.

The beginner advice is to first use MCP Servers other people have already written (Anthropic maintains a public list) and plug tools like Notion / GitHub / Slack directly into your Agent.

Skills is an equally important concept to understand. It's a product form that Anthropic officially launched in the second half of 2025 and that the industry gradually started following in 2026 — making a "packaged, reusable Agent capability module" a first-class citizen.

To understand Skills, first look at an engineering reality: a genuinely usable Agent often isn't just "a model + a few tools." It also needs — a set of dedicated tools (generating a PPT needs a pptx library), a piece of carefully tuned prompt guidance (when to use what, what the pitfalls are), some examples and reference materials (so the model knows "what good output looks like"), and sometimes specific code snippets as well.

If these are scattered across the prompt, tool descriptions, and code comments, two things happen: the model doesn't know when to use what; and these capabilities can't be reused, distributed, or versioned.

Skills turns this "capability package" into a product form that can exist independently, be loaded, and be shared. A Skill is usually a folder containing SKILL.md (describing what this Skill does and when it triggers) + related scripts, tools, and reference materials. The Agent automatically loads the corresponding Skill when it needs it.

A few key intuitions:

Skills are a "user manual" for the Agent to use, not documentation for humans to read — the language is written for the model.
Skills solve the problem of "infinite tools confusing the model." If an Agent plugs in 50 tools, the model is extremely likely to pick the wrong one; but if you group them into 10 Skills, the model only sees the corresponding tools in scenarios that match that Skill — this is on-demand exposure.
Skills and MCP are complementary: MCP solves "how a tool gets called" (interface standardization); Skills solves "how tools get organized and triggered" (capability packaging). A single Skill can internally call multiple MCP Servers.

If you've looked at Anthropic's official Skills repo, you'll find it has already turned common capabilities like "create docx," "create pptx," "create xlsx," and "fill out a PDF form" into Skills — these Skills are exactly what runs behind Claude.ai's "Create Files" feature. This trend of "turning general capabilities into Skills" is being followed by the whole industry in 2026.

The relationship among the three:

Function Calling / Tool Use actually refer to the same thing — OpenAI calls it Function Calling, Anthropic calls it Tool Use, and at bottom both are the underlying capability of "can the LLM output the instruction 'I want to call this tool.'"
Skill is another layer of abstraction — packaging a set of tools + prompt guidance + reference materials into a reusable, loadable capability module.

2.4 The data layer: RAG, Memory, LLM Wiki

This layer is changing fastest in 2026 — the traditional RAG paradigm is being partially replaced by several new forms.

RAG (Retrieval-Augmented Generation) was the most mainstream way of "giving an LLM its own knowledge" in 2023–2024. The core component is a vector database (Milvus, ChromaDB, Pinecone, pgvector, sqlite-vec).

But RAG is on the way out in 2026 — this is something that needs unpacking.

Go back to the era when RAG emerged (early 2023): mainstream LLMs had a context window of only 4K–32K tokens, long documents couldn't fit, and the only option was "chunk + vector retrieval + stitch back into the prompt." Today Claude Opus 4.7 / Sonnet 4.6 already natively support 1M tokens, and DeepSeek V4 Pro and Qwen3.6-Plus are also 1M — for many scenarios, the complex "retrieve first, then generate" pipeline isn't necessary at all, and stuffing the document straight into the context actually works better.

In May 2026, Karpathy explicitly promoted an alternative approach — LLM Wiki: for an individual's or small team's medium-scale knowledge base (under 100K tokens), you can completely give up vector retrieval, organize all the content into a "Wikipedia"-style structure in Markdown, and stuff the relevant sections directly into the prompt context on demand. The upsides: no chunking errors, no retrieval-recall problems, dead-simple debugging and editing, and — by hitting the Prefix Cache — a massive cost reduction too.

But RAG isn't dead. It's still the top choice in these scenarios:

Internal enterprise scenarios that emphasize data privacy — documents can't leave the corporate network.
Ultra-large-scale knowledge bases (millions of documents and up) — the context can't hold them.
Multi-user, multi-tenant scenarios — each user's data has to be isolated.

In short: for a personal project, try LLM Wiki first; for a toB enterprise project, RAG is still the default.

Memory (the memory system) overlaps with RAG but is different — Memory places more emphasis on "personalized memory of the current user / session" (user preferences, conversation summaries, key facts), usually divided into three layers: Working / Short-term / Long-term. Chapter 5 covers it specifically.

Agentic Retrieval / Agentic Memory is the new trend of 2025–2026: traditional RAG is a passive pipeline (retrieve first, then generate), whereas the Agentic mode lets the Agent decide for itself whether to retrieve, what to retrieve, whether to refine the retrieval results a second time, and whether to retrieve again. This "proactive retrieval" is rapidly replacing traditional RAG in complex scenarios.

2.5 The application layer: three mainstream landing scenarios

After nearly a year of observing the industry, the directions that get mentioned over and over and have proven out commercially are mainly these three:

AI search: from Perplexity to Metaso AI to Felo, all of these are essentially Agent-ified search — no longer "keyword matching + ranking," but "understanding intent + retrieval + synthesis + generation."

Chat-to-BI: letting business people query data, generate charts, and do attribution analysis in natural language.

Vibe Coding: from Copilot to Cursor to Claude Code to OpenCode to v0 — this direction has progressed the fastest over the past year and has most directly disrupted traditional software development.

If you're thinking about which vertical to pursue for an Agent, these three are the ones with the most commercial value and the largest talent demand right now.

2.6 Tech stack map

| Layer | Key components | Representatives | |------|---------|------| | Application layer | AI search, Chat-to-BI, Vibe Coding | Perplexity, Cursor, Claude Code | | Data layer | RAG, Memory, LLM Wiki | Pinecone, Milvus, pgvector | | Protocol layer | MCP, Skills, Function Calling / Tool Use | Anthropic MCP, Anthropic Skills | | Framework layer | Agent orchestration | Vercel AI SDK, LangChain, LangGraph | | Model layer | LLM | Claude, GPT, Gemini, DeepSeek, Qwen, Kimi, GLM |

Chapter 3 | How to Think About This Direction: Trends, Mindset, and Pitfalls

This chapter isn't about technology. It's about three things: why Agents are the most worthwhile direction to get into right now, why you don't need to be anxious, and how to avoid the opportunities that look beautiful but are actually traps.

3.1 "Am I too late" is a false question

The question I get asked most in consulting is: "Joye, am I too late if I'm only starting to learn now?"

My standard answer is: even the "veterans" on this track only have two years of experience.

A quick sketch of the timeline:

November 2022 ChatGPT released
Early 2023 open-source projects like AutoGPT take off, and "Agent" starts being widely discussed
June 2023 OpenAI launches Function Calling, and Agent engineering enters a new phase
2024 Cursor enters its commercial explosion period
Late 2024 Anthropic launches MCP, and the Agent protocol layer starts taking shape
2025 Agent products like Manus, Claude Code, and Devin burst onto the scene all at once
2025–2026 new paradigms like the Skills system, Agentic Search, and Agentic Memory evolve rapidly

In other words — the so-called "senior Agent engineers" in the industry today have at most two to three years from entry to now. That means if you start getting into it today, in three years you'll be a "veteran" too. Compared with those directions in traditional development where people have ten or twenty years of experience, this is a direction you can genuinely catch up on through speed of learning.

3.2 Why now: three judgments

Judgment 1: Agents are moving from the "Demo phase" to the "Production phase."

In 2023 and the first half of 2024, a huge number of Agent projects in the industry stalled at the Demo stage. Starting in the second half of 2024, "industrial-grade" problems like reliability, observability, Eval systems, and cost control started being taken seriously — this is the phase where an engineer can genuinely add value.

Judgment 2: a standardization window at the infrastructure layer.

The standards for infrastructure layers like MCP, Skills, and AI Gateway are still taking shape quickly. This means that if you enter now, you have a chance to genuinely participate in building the infrastructure of a new industry — and that kind of window is extremely rare in traditional development.

Judgment 3: talent demand is growing systematically.

Starting in 2026, China's top tech companies have begun systematically opening Agent engineer / LLM application engineer roles in their regular internships, summer internships, and fall recruiting — something that was a rarity just two years ago.

A more vivid signal comes from Y Combinator's W26 batch (Winter 2026): of 196 companies, about 60% are AI-native, and 41.5% are building Agent infrastructure outright — the "selling shovels" business of authentication, testing, security, observability, context management, billing, and other Agent-adjacent work. E2B (an AI code sandbox) officially mentioned that about 10% of W26 companies run Agents on its platform. When one of the most discerning incubators in the world places 40%+ of its bets on Agent infrastructure, the talent demand in this track is only going to keep growing.

3.3 A few reasons you don't need to be anxious

First, the industry has no "absolute authority." Traditional computer science has those "I've read his paper," "I've read his book" authority figures. This Agent direction is too new for that kind of figure to exist. OpenAI's and Anthropic's best practices are all written by engineers as they go — the gap between them and you is "accumulated practice," not "a gap in talent."

Second, the information asymmetry is tiny. OpenAI and Anthropic publish best practices on prompt engineering, Agent design, and the Skills system directly on their company blogs, free for anyone to read. That kind of transparency is unimaginable in traditional industries — most of what you want to learn has already been written down, and the only question is whether you're willing to spend the time reading it.

Third, the "easy part" of the tooling barrier is dropping, but the "deep part" is rising. This point needs to be told in two halves.

Looking at the easy side: three years ago, integrating an LLM required understanding GPU deployment; today you only need to know how to call an API. Vibe Coding has made "build a personal website" and "build a simple chatbot" nearly barrier-free.

But this is precisely why — when building a "barrier-less Agent project" becomes easy, a barrier-less project is itself worthless. You can find a thousand "AI health assistants" and "AI customer-service bots" on GitHub, because everyone can build one in a weekend with Vibe Coding. Put these projects on a résumé and the interviewer knows their worth at a glance.

The real entry barrier has been pushed to a deeper place: can you pick a problem that genuinely exists and can't be solved with off-the-shelf ChatGPT to build a project around? Can you make decent trade-offs at the engineering level? Can you clearly articulate, for every technical choice, "why this one"?

In short: this isn't "the barrier dropping," it's "the barrier shifting from coding ability to depth of thinking."

Fourth, your opponent isn't other people — it's the you from last year who didn't take action. What's truly "competitive" in the Agent field isn't your knowledge reserves, it's your "volume of doing." Reading 100 blog posts is worth less than writing one small Agent that actually runs yourself. Even if you only start today, as long as you take action, you're already outrunning the 90% of people who "watch but don't do."

3.4 Six common misconceptions

These six misconceptions are the ones I run into most often in consulting; let me debunk them one by one —

Misconception 1: "I'm bad at math, I can't do AI." What you want to do is AI applications, not AI algorithms. Engineering practice at the application layer basically doesn't need math.

Misconception 2: "I have to finish learning LLM theory before I can learn Agents." Backwards. The application layer and the underlying algorithms are two relatively independent tracks. Do applications first, and go back to fill in theory when you hit a specific problem — it's 10x more efficient.

Misconception 3: "Doesn't learning this require knowing a lot of frameworks?" A framework is a tool, not a goal. Once you understand the essence, you can pick up any framework in minutes; if you only know how to use a framework but don't understand the underlying layer, you'll be completely helpless the moment you hit a scenario the framework doesn't support.

Misconception 4: "I can't find a job without a big-company background." This Agent direction happens to be the domain of startups. What they value is "can you do the work right away" — your project experience, GitHub, and blog matter more than your school and your last employer.

Misconception 5: "AI is moving so fast, will what I learn be obsolete immediately?" What changes is the surface-level tooling; what stays is the underlying ideas. The ReAct paradigm, context engineering, memory systems, tool calling, Eval systems — these core concepts haven't changed in the past two years and won't change in essence in the next five.

Misconception 6: "Isn't Agent already a red ocean?" The truly "crowded" fields are the traditional ones that have been deeply developed for twenty years. Agent penetration in fields like Coding, Research, Customer Support, BI, and Marketing is still under 10% — we've barely scratched the surface.

Chapter 4 | How to Get Started and Prepare for the Job Hunt

This is the most hands-on chapter of this document. Everything you need to do — from "opening your IDE and writing your first LLM call" to "landing your first offer" — is here.

4.1 Prerequisite skills: what you need to know, and what you can skip

Let's start with languages. Agent development is currently mainstream in two ecosystems — Python and TypeScript / JavaScript — and knowing one of them already is enough to start:

For projects that lean backend, data, or algorithm integration, Python is more common.
For projects that lean frontend or toward web product forms, TypeScript is more mainstream.
In my own work, complex Agent projects are usually a Python backend + a TS frontend — knowing a bit of both is the most comfortable, but it's not required.

What you must know: either Python or TypeScript, with the ability to fluently write functions, handle JSON, and call an HTTP API.

What you don't need to know (set it aside for now): deep learning math, PyTorch / TensorFlow / model training / fine-tuning, the internals of the Transformer, and the APIs of Agent frameworks like LangChain / LangGraph (your first Agent should not start from any of these).

On Git and the command line: these are an engineer's "basic hygiene," but in 2026 their learning curve has been dramatically flattened by AI tools — when you hit something you don't know, just ask Cursor / Claude Code and it'll walk you through it step by step. Don't feel "not ready to start learning Agents yet" just because you're unfamiliar with Git — that's putting the cart before the horse.

4.2 A three-stage learning roadmap

At this point in 2026, I no longer recommend that newcomers hand-write a ReAct Loop from scratch — that kind of "hand-writing" was a necessary rite of passage three years ago, but today the abstractions of official SDKs like Vercel AI SDK and Anthropic SDK are light enough that the docs themselves are the best teaching material.

Stage 1: Get an SDK running (3–5 days)

If you're a complete beginner, the only goal for week one is to manually get a single LLM API call working: install Python or Node.js, sign up for an LLM vendor's API (I recommend DeepSeek — cheap enough that it won't hurt), write under 10 lines of code to send "hello" to the model, and then get it to hold a multi-turn conversation. The biggest asset you'll own at the end of this week isn't code — it's the visceral sense that "an LLM isn't a black box; it's just an HTTP service you can call."

Then I strongly recommend going straight to the Vercel AI SDK's official docs — the docs themselves are an excellent piece of "Agent teaching," progressing layer by layer from "call the model once" to "streaming output," "tool calling," "multi-step loops," and "structured output." Why not start with the OpenAI Cookbook or Anthropic Cookbook? Because each of those only covers its own model, whereas the Vercel AI SDK is model-agnostic and has the lowest migration cost.

The Python route: use the OpenAI SDK + base_url pattern to connect to OpenAI-compatible domestic models, or use the Anthropic SDK to connect to Claude. Pydantic AI is a lightweight Python SDK that's the counterpart to the Vercel AI SDK.

Stage 2: Understand the mechanics (1–2 weeks)

Add a few real tools to the Stage 1 Agent — web search (Tavily / SerpAPI), file read/write, third-party APIs. Focus on observing the model's "selection behavior" under multiple tools: when does it pick the wrong one? when does it fall into an infinite loop? Write down every failure case — these notes are the best résumé material.

Then run two comparison experiments: try LLM Wiki mode once (organize a body of material into Markdown and stuff it straight into the system prompt), and then try RAG mode once (vectorize and chunk the same material with pgvector / ChromaDB). Doing this comparison with your own hands is worth more than reading 10 blog posts.

Stage 3: A real project (1–2 months)

Pick a real scenario you yourself would use every day — don't build a played-out project like a "general-purpose Q&A assistant."

The standard for judging whether a project is "good enough" — refer to W's soul-searching question in my "Mock Interview" post: "If it were me, I could solve this directly with Doubao / ChatGPT — so why does this have to be built?" If you can't answer, please change the scenario.

A few entry-level project directions with "résumé value": an AI topic-selection assistant (scraping trending content from Xiaohongshu / Twitter for topic suggestions), a personal Newsletter assistant (auto-summarizing your subscriptions weekly), a simple Chat-to-SQL, a personal email-classification Agent, a lightweight code-review assistant (hooked up to a GitHub Webhook).

After finishing each project, write a blog retrospective — "what I built," "what pitfalls I hit," "how I solved them." This blog post is itself the strongest material for your résumé.

4.3 Job-hunt prep: tell your project "to the extreme"

If you can only spend your prep time on one thing, it's pitching your project to the extreme — making four things clear:

What you did (What): the project background, your role, the overall architecture
Why you did it this way (Why): the rationale behind every key decision
What pitfalls you hit (How it failed): failure cases + solutions
What you learned (What you learned): how you'd redo it

Counter-example: "I used LangChain to build a RAG customer-service system." — a description like this says nothing; it's an interview killer.

Positive example:

"I built a customer-service RAG system. At first I used simple vector retrieval, and recall was only 60% — analysis showed customer questions were colloquial and worded very differently from the source documents. We introduced Query Rewriting: first use a lightweight model to rewrite the user's question into multiple candidate Queries, then retrieve each separately and merge with deduplication. This change lifted recall to 85%, but Token cost went up 30%. To balance the cost, we later added caching — the rewrite results for the same class of questions could be reused. In the end, while keeping recall above 80%, cost only went up 5%."

This passage has: a metric (60% → 85%) + a decision (Query Rewriting) + a trade-off (cost vs. recall) + a follow-up optimization (caching). That's what "telling it to the extreme" means.

Three points at the résumé level: don't pile up technical terms ("proficient in LangChain, LangGraph, Vercel AI SDK, CrewAI…" — a résumé like that is laughable; the genuinely strong candidates actually have fewer technical words on their résumés); structure each project entry as "problem — solution — result"; quantify your results (even an estimate beats no number).

At the interview level — Agent roles don't test rote memorization, they test "what you've been through." Four concrete dimensions:

Foundational understanding: the essential differences between LLM / Agent / Chatbot, how Function Calling works, what MCP is…
System design: context engineering approaches, memory layering, tool-calling reliability, multi-Agent collaboration…
Engineering trade-offs: the basis for model selection, balancing cost and quality, judgment in framework selection, failure-retry strategies…
Industry awareness: the design philosophies of Manus / Claude Code / OpenCode, what you've read lately, which open-source projects you follow…

The first layer relies on experience, the second on understanding, the third on judgment, and the fourth on taste and how much you read. The further down you go, the more it separates candidates. In my "Mock Interview" post I gave concrete examples for each category — go take a look if you need them.

4.4 Five detours not to take

Detour 1: gnawing on the LangChain source code right away. The design is complex and the source is extremely unfriendly to newcomers. Once you've shipped a few projects with an SDK and then go look at it, the experience will feel completely different.

Detour 2: rushing into model fine-tuning too early. 99% of application scenarios don't need fine-tuning; prompt engineering + RAG / LLM Wiki already solves most problems.

Detour 3: chasing new frameworks without building your fundamentals. There's a new framework every two weeks. Once you form a "chase the new" habit, you'll forever be learning new things and never have a project of your own.

Detour 4: thinking you've got it just from finishing a tutorial. In this Agent field, every concept that "looks simple" turns out to have a pile of details once you actually do it. Watching without writing equals zero.

Detour 5: doing without producing output. Building a project but not writing docs, not writing a blog, not open-sourcing it — that's as good as not having done it. Output is the most effective way to force input, and it's also your strongest differentiating asset when you later look for a job.

4.5 Recommended learning resources (curated)

Official docs (read in order): the Vercel AI SDK official docs (the best starting point for getting into TypeScript) → the Tool Use / Skills / Prompt Engineering chapters of the Anthropic official docs → the OpenAI Cookbook (a Python hands-on supplement) → the docs of whichever domestic model vendor you chose (any of DeepSeek / Qwen / Kimi / GLM).

Frontline blogs (skim weekly): the Anthropic Engineering Blog, the AI sections of Sequoia / a16z, and the AI section of Hacker News.

Community: on Twitter / X, follow @karpathy, @AnthropicAI, @simonw, @_philschmid, @jxnlco.

I don't recommend any LLM-internals resources at this stage (Karpathy's "Let's build GPT" series, the various minimind-style source-code tutorials — including my own minimind-notes). They're all excellent, but they solve the problem of "understanding how an LLM is trained," which is a different track from building Agent applications. Once you've finished your first real project and have specific curiosity, going back to them will land much better.

Chapter 5 | The Few Things That Truly Matter

The first four chapters made clear "what it is, how to start, how to get a job." This last chapter is for those who've already finished their first project and want to know "what does going deeper look like" — and it's the true inner skill of an Agent engineer.

Each section uses an everyday analogy to help you build intuition. After reading this chapter, you'll have a shared language for talking with senior engineers.

5.1 Context engineering

Analogy: when you hand off work to a colleague, do you give them a 100-page project archive, or a 1-page concise brief?

An LLM's attention is finite — the longer the context and the lower the information density, the more easily it "loses focus," and at the same time Token cost goes up and responses slow down. Context Engineering is exactly about "presenting the information that most deserves to be seen, in the most effective way, within a finite space."

In a real project, a commercial-grade Agent might process dozens of interactions and call dozens of tools in a single conversation. Without context management, you'll blow the context out within 10 minutes. Common techniques —

Structured Prompt: use XML tags, JSON blocks, and clear delimiters instead of a stream-of-consciousness natural-language dump.
Front-loading / back-loading key information: the model pays more attention to the beginning and the end (the "Lost in the Middle" phenomenon). Put important constraints at the top of the System Prompt or at the end of the User message.
Replacing verbatim history with a summary: compress early conversation in a long dialogue into a summary.
Prefix-Cache-friendly context design: put unchanging content first and changing content last, which can massively reduce cost.

5.2 Memory systems

Analogy: how do people remember things? Short-term memory (things that just happened), long-term memory (important experiences from years ago), retrieval cues (seeing an old photo and suddenly recalling a story). An Agent's memory architecture basically mimics this.

Three-layer architecture:

Working Memory: the context the current task is actively using
Short-term Memory: the history of the current session
Long-term Memory: persistent information across sessions

There are three key decision points for long-term memory —

Write strategy: what kind of information is worth writing? A temporary preference like "I feel like eating spicy today" shouldn't be remembered; a long-term fact like "I'm allergic to peanuts" must be. This classification is usually judged by a dedicated "Memory Agent."

Read strategy: when to retrieve, and how? Retrieve once on every turn or only under a specific intent? Use vector similarity, keywords, or graph retrieval?

Forget strategy: more long-term memory isn't better. Stale, low-value, or contradictory memories should be cleaned up or decayed.

5.3 Tool calling

Analogy: getting a smart but handless person to complete a task for you — you have to tell them which tools are nearby, what each one does, and how to use it.

A few common engineering difficulties:

Tool Schema design: the clearer you write the parameter names and descriptions, the lower the chance the model misuses them.
Trade-off on the number of tools: too few isn't enough, too many and the model can't pick correctly. Generally 10 is the upper limit — beyond that you need "tool routing" (which is exactly the problem Skills solves, discussed earlier).
Failure retry and idempotency: retrying on failure is necessary, but it needs a cap — failing after 3 tries and reporting an error beats burning money on infinite retries.
Up-front constraints vs. after-the-fact fallbacks: making the tool-usage boundaries clear at the prompt layer is far more efficient than doing permission control at the tool-execution layer.

5.4 Reliability

Analogy: writing a Demo is like cooking in your own kitchen; writing Production is like running a restaurant — what you have to handle isn't just "how good the food is," but also "will it blow up at peak hours" and "will the occasional picky customer break the process."

A traditional application is a "deterministic system" — the same input always yields the same output. An Agent is a "probabilistic system" — the same input may yield different outputs, or even fail outright. This means the "test it once and it's OK" development model completely fails to work for Agents.

Common reliability problems: hallucination, instruction drift, unstable formatting, infinite loops, and cascading collapses from tool failures.

The core engineering ideas:

Up-front constraints: use the prompt to make "how it should be done" clear — lower cost than an after-the-fact fallback
Structured output + Schema validation: validate model output with Pydantic, Zod
State machine + Checkpoint: make the Agent flow explicit as a state machine
Degradation strategy: have a fallback path when a tool fails

5.5 Cost control

Analogy: driving — gas prices, distance, and the car model all affect the fuel bill. An Agent is the same: the model, context length, and number of calls together determine the cost of a single task.

An Agent's cost is far higher than a traditional application's. A single complex task might take dozens of LLM calls and accumulate tens of thousands to hundreds of thousands of Tokens — a single task could cost anywhere from a few yuan to a few dozen yuan. If your product is free and toC, poor cost control means losing money for the applause.

A few high-ROI optimization techniques:

Prefix-Cache-friendly design: both OpenAI and Anthropic offer caching discounts for "prefix hits" (Anthropic can save up to ~90% on a hit, OpenAI about 50%). Put unchanging content first.
Tiered model usage: use a cheap model for simple tasks, and only use the flagship for complex ones.
Reducing the number of Agent Steps: don't split something that can be said clearly in one step into multiple steps.
Context pruning: remove irrelevant tool results and stale conversation history from the context.

5.6 Evaluation (Eval)

Analogy: traditional software can use unit tests — input 1+1, expect output 2, and if it's wrong, it's a Bug. An Agent has no "standard answer" — how do you know it did "well"?

An Agent has no "right or wrong," only "good or bad." This means you need a mechanism to answer "is my new version of the Agent better or worse than the last one?" — without that mechanism, you can optimize all day and have no idea whether you're heading in the right direction. The Eval system is the marker of Agent engineering going from "workshop" to "industry."

Mainstream evaluation methods:

Offline evaluation: prepare a batch of test cases, run the Agent, and score by hand or with LLM-as-Judge
Online evaluation: collect real user feedback in production (thumbs up / down, dwell time, whether they keep following up)
LLM as a Judge: use a stronger model as the judge — but watch out for its own biases (a tendency to score high, a preference for long answers, etc.)
Controlled experiments: A/B Test, splitting the new and old versions to different users

5.7 These six things are an Agent engineer's true "inner skill"

To sum up —

Context engineering: maximize information density within a finite space
Memory systems: let the Agent remember things in layers, like a person
Tool calling: let the Agent "act" — and not run wild
Reliability: switch from deterministic thinking to probabilistic thinking
Cost control: the money really does burn
Evaluation: Agent optimization without Eval is all guesswork

If you can clearly articulate these six things in your résumé or interview, you're already ahead of 80% of applicants.

A Few Final Words

If you've read this far — thank you for taking the time.

This document is free, because I want to help everyone who wants to get into Agents. It will be updated periodically — roughly one version every 3–6 months, with "incremental patches" for major industry events. The version you're seeing is v1.0 (Updated: 2026-05-17).

But everyone's situation is different:

How your résumé should be rewritten — the document can't give specific paragraph-level advice;
How your project should be pitched — the document can't give a "problem — solution — result" rewrite tailored to your specific project;
How your learning pace should be set — the document can only give a generic three-stage plan, not a weekly plan calibrated to your starting point;
What the company you're about to interview with might ask — the document can only give a four-dimension framework, not a question bank tailored to your résumé.

If you need that kind of 1-on-1 specific help, I offer the following three tiers of service — all delivered by me personally, never outsourced, never mass-produced.

Detailed description of paid services

For the specific pricing of all services, please contact me — the consultation itself is free, I'll first understand your situation and then judge which service suits you best. If none fits, I'll tell you straight that it's not a fit and won't push.

Service 1: Résumé revision (￥)

Who it's for:

You already have a résumé and project experience, but you're not sure how to "tell the story" so the interviewer's eyes light up
You have projects on your résumé but can't articulate "problem — solution — result"
You want to pivot toward Agents, but you don't know how to retarget your old résumé

What's included:

A detailed review of your résumé
Revision suggestions down to the paragraph and sentence level — not vague "consider highlighting your strengths," but "this paragraph should be rewritten as XXX"
Help reorganizing your project narrative — polishing scattered work into a story you "can tell clearly in 5 minutes of an interview"
Keyword suggestions targeted at your goal direction (Agent engineering / LLM applications / Multi-Agent / RAG, etc.)
One 30–60 minute 1-on-1 session to go over the revised version once more

Service 2: 1-on-1 mock interview (￥￥)

Who it's for:

You're already preparing for an Agent engineer role but lack real interview experience
You've debriefed your own projects, but you'd like someone to professionally "grill" you on them once
You're about to interview at a company you really want, and you'd like to warm up in advance

What's included:

We communicate in advance about your résumé and target company's direction, and customize the question bank
A complete interview simulation covering all four dimensions: foundational understanding + system design + engineering trade-offs + industry awareness
Charged by time, with a 1-hour minimum — 1 hour is 1 hour, 1.5 hours is 1.5 hours, with the price scaling linearly with duration
Full audio / video recording (as you prefer)
If resources worth a further look (papers, blogs, open-source projects) come up during the interview, I'll compile them for you afterward

Service 3: Learning roadmap / onboarding coaching (￥￥￥)

Who it's for:

You're a complete beginner, or have a foundation but lack a sense of direction, and want someone to systematically guide you for a while
You tend to get stuck or give up when self-studying, and need external pacing, accountability, and Q&A
You want to hit a concrete goal within a fixed window (1–3 months), such as "build a first Agent project I can actually show off"

What's included:

Onboarding assessment: a 1-on-1 to understand your current foundation, goals, and available time
Customized learning roadmap: a personalized weekly study plan tailored to your situation
Weekly 1-on-1 Q&A: a 30–60 minute sync at a fixed time each week — reviewing last week's progress, answering questions, adjusting next week's plan
Project coaching: I follow the project you're building throughout the coaching period + review it at key milestones
Final deliverable: by the end of coaching, you'll have at least one complete Agent project you can put on your résumé, plus a complete retrospective document

Typical coaching cycles: 4 weeks / 8 weeks / 12 weeks — decided based on your goals and time.

How to get in touch

Add me on WeChat

, with the note "paid consulting".

Or through these other channels:

Personal website: joyehuang.me
GitHub: github.com/joyehuang

About future updates to this document

This document isn't a one-and-done deal:

Updated roughly every 3–6 months, revised according to the latest industry developments
Major industry events (a new major LLM version, a new protocol-layer standard) will get an "incremental patch"
For readers who've seen this document, all updated versions remain free

About feedback

If you have any opinions, suggestions, or spot any errors after reading this document, I'd really love for you to tell me. Through any channel — email, a comment on the site, a DM. Reader feedback is the single most important basis on which I revise this material.

Types of feedback I especially welcome:

A concept you feel wasn't explained clearly enough
A judgment you disagree with and want to discuss with me
You followed the roadmap in practice and found some piece of advice didn't quite apply
You worked out a good practice of your own that isn't in the document

A final blessing

Build fast, learn faster.

This is my own blog's slogan, and it's my blessing to you.

This document ends here — but your journey is only just beginning.

If it helped you even a little, then it was worth it. And if you really do end up entering this line of work as an Agent engineer, I hope someday we cross paths at some AI company, in some open-source project, or under some GitHub Issue. When that day comes, remember to tell me — "I read this document back then too."

—— Joye

Updated: 2026-05-17 · v1.0

A 1h19m Agent Engineer Mock Interview: What We Asked

Tue, 12 May 2026 00:00:00 GMT

This is a mock-interview retrospective. The candidate was a student from a 211 university, with two AI projects on his résumé: a multi-Agent healthy-eating assistant built on LangGraph, and a long-term memory engine for Agents. Another interviewer, W, and I interviewed him together for 80 minutes. Afterwards I felt this session was worth writing up as a blog post — not because the candidate did especially well or especially badly, but because it so completely exposed the problems with the mainstream "pad your résumé with AI bootcamp projects" path, while also walking through what an Agent engineer interview should test in 2026.

This is going to be a long piece. I'll write down every question we asked, the candidate's answers at the time, our feedback, and "how I would have answered." If future mock interviews turn out to be valuable, I'll write those up too.

A note up front: why I'm writing this

Lately I've been helping my mentor screen résumés for a full-stack Agent development internship and running first-round interviews, so I've interviewed quite a few candidates; I've also been booked by some followers for paid mock interviews. This was one of them. The candidate comes from a backend background and wants to pivot into Agent development; he listed two projects on his résumé. By the end, the overall verdict W and I reached was: learning Agent development by tweaking a bootcamp / open-source project makes it very hard for a candidate to form their own thinking — there's no depth, and one question from the interviewer makes it fall apart.

This isn't a personal failing of this particular candidate. Résumés produced by bootcamps, contract gig projects, or "grab an open-source repo off GitHub and tweak it" are pretty much all in this state. So this blog post isn't here to mock one specific résumé — it's an honest attempt to discuss: if you want to be an Agent engineer, how should you prepare your projects, how should you answer interview questions, and what do you need to think through before writing a single line of your résumé.

1. The problem with the projects themselves: what real problem did you solve?

The candidate's two projects:

Project one: an AI health assistant, with a diet-recommendation module underneath it. LangGraph orchestration, a Router + multi-Agent layered design; after intent recognition, it dispatches to a Text2SQL Agent / RAG Agent / knowledge-graph Agent, then aggregates. The retrieval layer has three hybrid pipelines including GraphRAG. A three-tier memory module. Fine-tuned on Qwen3-8B.
Project two: a long-term memory engine for Agents. Three-stage extraction (summary → entities → relations), written into ChromaDB + Neo4j; hybrid graph-vector retrieval (vector recall + BFS expansion + semantic re-ranking); memory decay based on the Ebbinghaus forgetting curve; at write time, it does semantic-similarity grading, contradiction detection, and similarity merging.

It all sounds very much the part. But after listening, W asked just one question that made the entire project collapse (this is aimed at project one — its input is only two kinds: unstructured recipe content, or a structured nutrition table):

"If it were me, I could just solve this with Doubao. Why does this have to be built at all?"

Why this question is so lethal

When hiring, what an interviewer wants to see is "you identified a real problem → picked the right technology → solved it better than the off-the-shelf option." A project's reason to exist = a real problem × the inadequacy of off-the-shelf solutions.

I genuinely suggest finding projects from two directions:

Start from a real need around you, something you personally ran into — if you can clearly explain "why I built this," the whole project's narrative stands on its own.
Deeply use an open-source Agent (e.g. Hermes), find its shortcomings, and do a transformative second-pass development — this is harder, but the value is extremely high.

Now that we have AI, the cost of building a project from scratch has dropped to almost nothing — there's no need to copy.

The candidate's project took the opposite path: first decide to use LangGraph / multi-Agent / GraphRAG / hybrid graph-vector retrieval / fine-tuning, then find a scenario to stuff all those technologies into. "AI diet recommendation" is a scenario that Doubao, ChatGPT, and Kimi solve directly out of the box, so all the architectural complexity he built had no corresponding payoff.

How to fix it

W's concrete advice was: "change the soup but not the medicine" — you can keep the tech stack, but the scenario has to change to one that genuinely needs an Agent. For example:

Deep-research type (the DeepResearch kind: multi-step retrieval, cross-source information integration, requires planning)
Multimodal content creation
Complex task automation in a vertical domain (not something QA can solve)

Don't title the project on your résumé "AI Health Assistant" — that name itself is telling the interviewer "this is a scenario that doesn't need an Agent." A scenario that genuinely needs an Agent also gives you a lot more to talk about in the interview — architecture, decisions, the pitfalls you hit, the improvements you made; there's plenty to discuss.

Advice for every Agent job seeker

Before writing up a project, ask yourself three questions:

Can this scenario be solved by just chatting directly with ChatGPT / Doubao / Claude? If yes, change the scenario.
What substantive benefit does the multi-Agent architecture I used give me over a single Agent? If you can't articulate it, switch to a single Agent.
For every tech choice I made (vector DB, graph DB, Redis, fine-tuning, RAG), can I clearly explain "why this one and not something else"? If you can't, either delete it or go do the homework.

2. All those "why" questions we kept asking

Throughout the interview, the single most common category of question W and I asked was "why did you choose X instead of Y." This is the Agent-role interviewer's favorite question type, because in one sentence it separates "actually used it, hit the pitfalls" from "read a blog and copied it onto a résumé."

The candidate was almost completely wiped out on this category. Below I'll expand each "why" question.

2.1 Why Milvus / ChromaDB? What's the difference between them?

The candidate's answer: "Milvus is for larger data volumes, ChromaDB is for smaller data volumes. I don't really know much about the others."

Why this question matters: the vector DB is the core storage of any RAG / Memory project, and the choice directly determines performance, cost, and operational complexity. The interviewer isn't asking this to hear you recite specs — they want to see "what technical comparisons you did for your project."

How you should answer: at minimum you should be able to name a few dimensions of comparison —

Deployment form: Milvus is an industrial-grade distributed deployment; ChromaDB starts single-node and can be used purely embedded
Ecosystem: Milvus has a full SDK / monitoring / ops toolchain; ChromaDB is simple but has a thin ecosystem
Alternatives: pgvector (essentially a Postgres extension, lets you cut out a whole piece of infrastructure), Qdrant, Weaviate, Pinecone
Lighter options: sqlite-vec / sqlite-vss also support vector retrieval — for a personal project's dataset, isn't SQLite enough?

A higher-scoring answer is to challenge the choice itself directly: "Honestly, for the data volume in my project, pgvector is plenty — there's no need to spin up a separate vector DB." That's the "engineering judgment" the interviewer wants to hear, rather than "I just happened to pick this technology, or the project already used it."

The actual direction to improve: I don't need you to explain the index details of HNSW versus IVF, but I want to hear that you did the comparison and gave it some thought before choosing this technology. Just go have an AI walk you through a comparison of the mainstream vector DBs and roughly know it. I'll also recommend the notes section of my blog, joyehuang.me/notes — there's a lot of relatively fragmentary knowledge there that I've accumulated over time, and one of them happens to be a comparison of vector databases.

2.2 Does each Agent in your multi-Agent setup use a different model?

Candidate: "No, they all use one model, Qwen."

Why this question matters: in a multi-Agent system, the model choice should be split by each Agent's responsibility. A simple classification task like intent recognition uses a small / cheap model, a complex reasoning task uses a large model, and long-text summarization uses a long-context model.

To put it more sharply: if your multi-Agent is essentially a workflow orchestration with no communication between Agents, and you don't do model tiering either, then what is the point of this multi-Agent? Conversely, if you do model tiering, you can at least name a few benefits:

Cost control — this is a must-consider for any production project
Capability matching — for multimodal scenarios you can plug in the Gemini family, for code scenarios Claude, for domestic-compliance scenarios Qwen
It shows you've tried quite a few models — at least you roughly know what each model is good at

A lot of people feel that "I used multiple models" is a mediocre answer, but I actually really endorse it — it shows you genuinely think about problems from a production perspective.

How you should answer: give a concrete scenario, e.g. "intent recognition uses Qwen3-7B because the latency requirement is low and the task is simple; the final aggregated output uses Claude Sonnet or GPT-4 because it needs language-organization ability; background async summarization uses the cheap Qwen-Turbo because there's no real-time requirement."

This connects to the "Agent cost control" topic we discussed later — I'll expand on it below.

2.3 Is there actually any "communication" between your Agents?

What I asked: "Is there any communication between your Agents? Besides the aggregation step, do they talk to each other at all?"

Candidate: "There's basically no communication, it's just a workflow, orchestrated ahead of time."

Me: "Then this isn't really multi-Agent."

Why this question matters: the industry has a shared definition of "multi-Agent" — Agents need to make autonomous decisions, call each other, and communicate with each other. A fixed router that dispatches a task to a few independent processors and then aggregates is called a Workflow, not Multi-Agent. These two terms basically settled after Anthropic's Building Effective Agents post.

How you should answer: honestly admit this is a Workflow, then discuss "how I'd refactor it into a real multi-Agent system" — e.g. letting an Agent call other Agents back, raise follow-up questions, and collaborate to complete a complex task.

Going further, you can reflect: "Actually my scenario doesn't need multi-Agent; a single Agent + tool calls would solve it." This kind of self-correction ability is worth far more than stubbornly insisting that what you built is multi-Agent.

Two things to remember for interviews:

Don't bluff. If you're asked about something you're not familiar with, admit it; bluffing just gets you fished to death.
Don't insist that a bootcamp project is your own work. The interviewer knows perfectly well whether you wrote the project yourself or copied it from a bootcamp, and if you keep insisting after being seen through, it escalates from "the project lacks depth" to "an integrity problem."

2.4 The pros and cons of single-Agent vs. multi-Agent / Router orchestration?

I followed up: "If you refactored this project into a single Agent, how would you design it? And what are the respective pros and cons of a single Agent versus your current orchestration?"

The candidate gave some stuff about "prompt isolation, focusing on its own task," but didn't hit the point.

How you should answer:

Advantages of multi-Agent / Router orchestration:

Context isolation — each Agent only sees the content relevant to its own task and isn't distracted by irrelevant information
Each subtask can have its prompt optimized separately and its model swapped separately
Parallelism — independent tasks can run concurrently
Good observability, you know which step went wrong — but this one requires you to actively design a whole observability system, otherwise when something goes wrong you're still flying blind. If your project did replay (replayable debugging), that's genuinely a big bonus

Disadvantages of multi-Agent / Router orchestration:

Higher overall latency (every extra call is another network round trip)
Token consumption multiplies (context has to be passed between Agents)
The routing itself can be wrong (if intent recognition is wrong, everything is wrong)

Advantages of a single Agent:

Simple, low latency, low cost
The model sees all the context itself and can make more global judgments
Modern large models' function calling is already strong enough that a single Agent is enough for most scenarios
Boosted by Skills — the single-Agent + Skills combo basically became the new paradigm after Claude Code (I'll expand on this in 3.5)

Disadvantages of a single Agent:

The context easily explodes
The model tends to lose early information in long contexts
Cramming all responsibilities into one prompt easily turns it into a pile of spaghetti

Remember one 2026 trend: the industry as a whole is regressing from "fancy multi-Agent orchestration" back toward "a single strong Agent + good tools + good context engineering." Claude Code, Cursor Agent, and Cline are all this paradigm.

2.5 How did you compute the 90.6% intent-recognition accuracy?

Candidate: "I built about 200 questions and compared them against the labeled answers."

Why this question matters: every "90%+ accuracy" on a résumé will get questioned. An Agent project with no evaluation system is just bluffing.

How you should answer: you need to clearly explain —

How was the test set built? What cases does it cover? What's the distribution? Why did you pick these cases? Do these cases reflect the ability you want to test? — this is the easiest thing to get probed on; "I just made up 200" and "I covered 5 common intent categories + 3 boundary cases + 2 adversarial samples" are two completely different leagues
What's the evaluation metric? Just accuracy? Or do you have precision / recall / F1?
How is the evaluation automated? After you change a prompt, how do you regression-test?
How are boundary cases handled? When it can't recognize something, how do you fall back?

The candidate mentioned that "when it can't recognize something it falls back to Text2SQL" — that's a bonus point, but he didn't elaborate.

Direction to improve: go look at the industry eval tools — LangSmith, Braintrust, Promptfoo — run one yourself, and understand what an eval platform actually solves.

2.6 Why Redis?

Candidate: "Because LangGraph node state can be stored in Redis, and Redis supports TTL for memory expiration."

W's rebuttal was direct and precise, roughly:

"If it's just for TTL, you shouldn't use Redis. Redis's TTL is designed for high-concurrency online business. User data is the most precious asset in the whole system — expiring a memory shouldn't mean deleting it, it should mean archiving it. Redis's real use is state consistency across service nodes — caching, distributed locks, session-level state isolation."

Why this question matters: this is a very typical case of "piling on technology without thinking." Redis is an old friend of backend developers; written on a résumé it looks professional, but using it in the wrong scenario instead exposes that you don't understand Redis's real positioning.

How you should answer: reasonable uses of Redis in an Agent project include —

Caching: caching model responses, caching vector-retrieval results
Distributed locks: locking when multiple Agents concurrently write the same memory
Session-level state isolation: synchronizing session state when a user is logged in on web and app at the same time
Rate limiting: API call quota management
Temporary checkpoints: runtime state snapshots for LangGraph (the candidate got this one, but didn't emphasize the "temporary" part)

The memory data itself should be stored in persistent storage — a vector DB, graph DB, or relational DB all work. Never treat "a user's long-term memory" as cache data that can be automatically evicted.

2.7 PostgreSQL vs MySQL — what's the biggest difference?

Candidate: "I haven't really compared them; PG is enterprise-grade, fairly powerful, and you can add pgvector to use it as a vector DB."

W's expansion was very practical:

"These days you basically don't use MySQL for a new project. The moment pgvector is in, it pretty much kills Milvus; jsonb is friendlier for storing JSON; geospatial and time-series support is good; in some scenarios it can replace Elasticsearch (though for tokenizer scenarios you still have to use ES)."

Why this question matters: this is a substantive shift in backend technology choices in 2025–2026. If your résumé says "familiar with MySQL" but you don't know Postgres's standing in new projects now, your understanding is out of date.

Direction to improve:

Spin up a new project with PostgreSQL and run RAG with pgvector
Learn about full-stack solutions built on Postgres like Supabase, and understand why Postgres has captured the "default database of choice for small projects" niche

2.8 Why use Neo4j instead of Redis to store graphs? And why not use Neo4j to store Agent state?

This stretch was W fishing. While explaining Redis's uses, the candidate unconsciously described "graph storage" as a Redis feature, and was immediately caught.

The lesson: don't give a divergent answer in a domain you're not familiar with. When asked about Redis, just honestly describe Redis's reasonable uses; don't, to look knowledgeable, expand into graphs, vectors, state-machine management, and other areas Redis isn't good at.

A more universal rule: every single point on your résumé is something you need to understand thoroughly, otherwise don't write it. As an interviewer, if you wrote it, I'll ask; if you can't answer, then it's "well, yeah, not great."

2.9 Why fine-tune Qwen3-8B, when the upstream data used Kimi K2.5?

Candidate: "Kimi K2.5 was used to build the QA-pair dataset, generating Q&A pairs from different angles."

W's critique:

"Kimi K2.5 is definitely stronger than Qwen3-8B on benchmarks. Using a stronger model to generate data to fine-tune a weaker model is logically sound (the data-distillation idea), but your scenario design here has a problem — you should write: use Claude Sonnet 4.6 + Kimi K2.6 to de-identify user privacy data and fill in multimodal training data, then do LoRA fine-tuning on the latest Qwen3 version (e.g. Qwen3.6-235B) on Alibaba's Bailian platform. Written that way, it makes sense."

Why this question matters: the justification for fine-tuning = data quality × task fit × cost. If you can't explain why you fine-tuned, don't write fine-tuning.

How to actually write it:

"For [specific task] in [vertical domain], used Claude Sonnet 4.6 and Kimi K2.6 to clean, de-identify, and complete multimodal data for the dataset, building a high-quality training set, and did LoRA fine-tuning on Qwen3-X on Alibaba's Bailian platform, improving [specific metric] by X% compared to directly calling a general-purpose model."

W and I also threw in an offhand gripe: Qwen3-8B is way too common in bootcamp projects — I get PTSD just seeing it. If you want to make the interviewer's eyes light up, at least use a latest model version from 2026.

3. Core Agent knowledge: context engineering, memory, Skills, MCP

3.1 Have you designed any context engineering?

The candidate described some things he'd done: a 128K context window; when it reaches the 75% threshold, a sliding window kicks in to keep the last 5 turns of dialogue; after the session ends, a large model summarizes the history and writes it into long-term memory.

My assessment: writing "context management" as one line on your résumé is empty fluff — because it's the default operation of every Agent project.

How to write it so it has substance:

Don't write "did context management," write —

How many layers of context I designed (system layer, task layer, user layer, session layer)
When each layer gets triggered
What trigger I use to decide to write to long-term memory / summarize old context / engage the sliding window
How I handle "noise" in the context (irrelevant messages, user slips of the tongue, contradictory information)
How I do prefix-caching-friendly context design (I'll cover this separately below)

3.2 Writing to long-term memory: if a user says "I feel like spicy food today," should it be recorded or not?

I asked:

"When a user says 'I like spicy food' today, how does that point get written into memory? Is it an explicit user call, or the Agent's own judgment? And it's possible he's just in a bad mood today and wants something spicy — that's a short-term preference, which is different from 'I'm someone who eats spicy food long-term.' How do you design the Agent to distinguish them?"

The candidate couldn't answer, and admitted "this was done pretty crudely."

Why this question matters: this is one of the most core design questions in a Memory system. "What to record, what not to record, how long to keep it, how to override it" is the soul of a memory engine. If your résumé lists a Memory project but you can't explain these questions, the whole project's credibility collapses.

How you should answer:

Memory writing needs to consider —

Factual vs. derived vs. preference:
- Factual: "My name is Joye, I study in Melbourne." → write directly, high confidence.
- Derived: "I often work overtime on weekends." → no need to write; it can be derived from historical sessions.
- Preference: "I like spicy food." → needs to be written, but tagged with confidence and recency.
Short-term vs. long-term:
- Short-term preference ("want spicy today") → write to session-level memory, decay or discard after the session ends.
- Long-term preference (mentioned multiple times, a stable preference) → promote to long-term memory.
- This promotion mechanism can be based on "number of occurrences + time span."
Contradiction detection:
- The user has said both "I like spicy food" and "I can't eat spicy food" — how do you handle it?
- Timestamps + context to judge which is the current fact.
Write triggers:
- Explicit trigger: "Please remember that I..."
- Implicit trigger: session end / message count reaches a threshold / a user statement of fact is detected
- Async trigger: a cheap model summarizes and extracts from the session in the background

3.3 How is Memory used? Where in the system prompt is it placed?

Candidate: "It should be added to the system prompt." Then he said "toward the back is better, because the model's attention mechanism is more sensitive to later content."

I corrected him immediately: that's exactly backwards — it goes at the very front, mainly for prefix caching.

Why this question matters: this is an engineering detail a 2026 Agent engineer must know.

Prefix caching: Anthropic / OpenAI / domestic model providers all support caching the prefix of a prompt; on a cache hit, the token price is much cheaper (with Anthropic, cache writes are more expensive than normal and cache reads are cheaper than normal).
Design principle: put the least-changing content at the very front (system prompt → long-term memory → tool descriptions → conversation history → current query). That way, most of the time only the last segment changes, and the prefix can all hit the cache.
If you put memory at the end, every memory update breaks the cache for the entire prefix, and token cost skyrockets.

Follow-up question: how often should your memory update?

Update too frequently → too many prefix-cache misses → cost skyrockets
Update too slowly → the user feels the Agent "can't remember things" → poor experience
This trade-off needs to be clearly explained in your project

3.4 How many versions has the Memory system of OpenAI / Claude / open-source Agents gone through? Pros and cons of each?

W asked this, and the candidate couldn't answer.

Why this question matters: this gauges whether you're "someone who genuinely follows this field." Someone researching Agents / Memory couldn't possibly have not seen these two companies' product iterations, or the approaches of the mainstream open-source Agents.

How you should answer: at minimum you should be able to name —

OpenAI's Memory evolution: from the earliest "Saved memories" (explicit user trigger, pure list storage) → automatic memory (the model judges what to write on its own) → cross-session memory ("reference chat history").
Anthropic / Claude's direction: Claude's Memory is implemented via the Skills system and the conversation_search tool; structurally it's closer to "tool calling + explicit storage" than to automatic writing.
Open-source CLI Agents' approaches: represented by Hermes, OpenCode, OpenClaude, Aider — basically all use Markdown files as the memory carrier (memory.md / user.md), and the Agent restores context by explicitly reading them. The biggest advantage of this route is that "memory is fully readable, editable, and versionable."

Direction to improve:

Actually use these companies' products for a while and feel the differences firsthand. If you don't use them, at least learn about them through blogs or explainer videos — to prove you're genuinely curious about Agents
Read Claude's Skills documentation and Anthropic's article on Building Effective Agents
Follow the code of open-source CLI Agents like Hermes / OpenCode / OpenClaude / Aider

3.5 The relationship between Skills, MCP, and Function Calling?

W's question; the original wording was "Skill plus MCP plus a CLI," but the candidate hadn't heard of CLI-type tools, so it focused on Skills and MCP.

The candidate answered reasonably well: MCP provides data-source connections, and Skill teaches the model how to use that data to complete a specific task; the two are complementary.

How you should answer (more complete):

Key insights:

MCP and Skill are complementary: MCP provides data, Skill provides methodology.
Skill's biggest advantage is turning things into SOPs / processes: encoding domain experts' best practices into a guide the model can read.
Skill uses Progressive Disclosure: the first layer only loads the skill's metadata (name + description); only after a hit does it load the full content, avoiding context explosion.

3.6 How does an Agent "perceive" that a Skill exists?

A detail question from W; the candidate answered vaguely. The concrete mechanism is —

The skill's metadata (name + description) is injected into the tool list in the system prompt (usually the tool-description area). At each decision step, the model sees this lightweight directory and judges whether the current task needs a particular skill. If it does, the model actively calls a "read skill content" tool (e.g. view SKILL.md) to load the full skill content into context.

Why it's designed this way: to avoid cramming all skills' full content into the context at once — a user might have dozens of skills, each several thousand words; stuffing them all in would blow up the prompt. Progressive disclosure is one of the core ideas of context engineering.

3.7 Is there an install limit for Skills / MCP?

Candidate: "There's definitely a limit. Too many skills make the tool list very large, and the model's selection precision drops."

He got this one. To add to it:

Products like Claude Code have a soft limit on the number of skills (usually a few dozen), precisely because loading the metadata into the system prompt makes it bloat.
The drop in selection precision also exists in tool calling ("too many tools causes hallucinated calls").
The solution: tiered loading (dynamically loading the relevant subset of skills by scenario).

It's worth specifically mentioning the tool_search mechanism in Claude Code — it essentially turns the "tool/skill list" itself into a searchable index: by default the model doesn't see the full definitions of all tools, and when it needs one, it queries by keyword via tool_search and loads on demand. This is a further generalization of progressive disclosure along the "tool dimension," and it's a paradigm very much worth borrowing in current Agent design.

4. How an Agent controls cost

W's question. Candidate: "You have to consider the number of large-model calls and merge some steps together."

The two of us griped on the spot: an answer like "reduce the number of calls" is the same as "I want to spend a bit less each month" — that's an outcome, not a method.

How you should answer (this section is the part of the interview I personally think is most worth writing down):

1. Prefix-caching-friendly context design

As described above. Put the least-changing content at the front so the cache hits as often as possible.

Concrete actions:

Put the system prompt, long-term memory, and tool descriptions at the front
Put the current query and the latest message at the end
Don't update memory too frequently — every update invalidates the prefix
Evaluate your model provider's cache billing policy: Anthropic is "explicit checkpoint + write expensive, read cheap"; OpenAI / Gemini auto-cache

2. Tiered model usage

Use a cheap small model for simple tasks (intent recognition, classification, summarization), and a large model for complex reasoning. This is why "all Agents using the same Qwen3-8B" is a big problem.

3. Reduce the number of Agent steps

An Agent's token cost grows exponentially — every extra step means the entire conversation history is sent as input again.

Concrete actions:

Don't split into two steps what can be done in one
Tool design should be "wide-aperture" — one tool solves a class of problems; don't make a separate tool for every fine-grained task
Make the Plan phase as complete as possible, avoiding "think as you go"

4. Context pruning

If an old tool-call result has already been used, delete it from the history (keep a summary)
For file-type content, keep only the diff
Use a tool to "read on demand" for large blocks of irrelevant context; don't stuff them into the prompt by default

5. Rate-limiting failed retries

Agents auto-retry on failure. If you don't limit the retry count + don't do exponential backoff, one bug can blow up your bill.

5. AI coding engineering practice: how do you write code and use AI?

W's question: "What AI coding techniques did you use while building these projects?"

The candidate answered: "I generally use Claude Code to help me write or read code."

The answer W was hoping for:

"I'd build a doc tree (project index) for the project, write AGENTS.md / CLAUDE.md / Cursor rules so the Agent doesn't re-explore problems it's already explored. I'd put the best practices for common frameworks (PostgreSQL, FastAPI, etc.) under .claude/skills/ as references."

Why this question matters:

"What we care about more is how you did things in between. The 'results' part on everyone's résumé is much of a muchness — everyone uses AI coding, everyone tweaks an open-source project, and the résumés all look alike. What truly distinguishes candidates is the process."

This holds for every job seeker in the AI era: when AI drives the cost of "writing code" way down, your differentiation has to show up in —

How do you use AI tools?
What kind of workflow have you established?
How do you get AI tools to keep producing high-quality output in your project?
How are your AGENTS.md / Skills / Memory designed?
Beyond coding scenarios, how else do you use AI? — this is a great extension question. I don't mean "asking GPT to do your homework," but rather things like: using Hermes to manage your schedule, using cronjob + Agent to push the AI world's hot topics to yourself every day, using an AI workflow to auto-edit videos, and so on. People who can show this are clearly a notch closer to the industry than those who've "only used Cursor."

6. The macro talk: how we view Agent development and this industry

In the last stretch of the interview, W and I gave the candidate some more macro stuff. This part is valuable for everyone who wants to break into the field.

6.1 Don't pile on technology — solve problems

"I've interviewed a lot of people, and they love to pile on technology — Redis, RAG, vector DBs, knowledge graphs, fine-tuning, all heaped together. Then for every technology written on the résumé, they can't answer 'why you used it.'"

This is the most common problem for Agent job seekers in 2026. Bootcamps, contract gig projects, and résumé templates copied off the internet all teach you to "pile on technology to look professional." But any experienced interviewer can see through it within 5 minutes.

What a truly competitive résumé looks like:

"The biggest problem with this résumé is there's no frontend, because when I hire, I only hire full-stack people."

"I'd suggest you don't have many projects — just one project, which has Agent and frontend and Agent context engineering and backend high-concurrency handling; plus your thinking process, like what your AI coding best practices are, what skills you used to assist development, how you wrote the docs for the project, how you did observability, how you did the Agent's evaluation, how you proved it's good, and how the fine-tuning was done."

One project done deeply and thoroughly >> five projects done superficially.

6.2 Don't do RAG-for-the-sake-of-RAG

I strongly recommend first reading Karpathy's LLM Wiki series — he explains very clearly "why traditional RAG is gradually losing ground in the long-context era," which is one of the underlying ideas of this section.

W asked a great question:

"RAG is meant to solve the knowledge-base problem. So how do the latest Agents solve problems? Does Claude Code have RAG?"

The candidate then realized: Claude Code has no RAG — it uses grep.

This observation is profound:

The traditional RAG paradigm is "chunk and vectorize documents first, then retrieve at query time" — that's the 2023 methodology, on the assumption that "the model's context is small, tokens are expensive, and retrieval must be precise."
The 2025–2026 paradigm is Agent + tools — a long-context model + grep / glob / file-reading tools, letting the Agent explore the codebase itself. This approach has higher precision, doesn't depend on vectorization quality, and doesn't require maintaining an index.
This isn't to say RAG is dead, but that RAG isn't the only answer. In many scenarios, letting the Agent use basic tools (grep, find, read) is actually better than reaching for RAG.

Job-seeking advice: "used RAG" on a résumé is no longer a bonus. If you write RAG, you'd better be able to clearly explain "why RAG is more suitable for this scenario than Agent + grep."

6.3 The project should be live — ideally let the interviewer try it

"If your project is something you built yourself but it's not live, I might not be very interested."

"I'd suggest you deploy the project to Vercel — it takes half an hour to deploy — you should have a production-grade project that people can actually use."

Why being live matters so much —

Only when it's live do you run into real problems (performance, concurrency, error handling, user behavior)
Only when it's live does your résumé get hard metrics like "traffic" and "user count" — though you might not have these, and I don't insist on it, since pulling in real users is a hard thing

But what I hope for is that you have at least a bit of deployment experience. The ideal case is: during or before the interview, I can go try your project myself — even if it's just a demo page that doesn't require login. A "project you can actually touch" is far more credible and adds far more points than a project described purely in a résumé.

6.4 The overseas developer ecosystem: a bonus many domestic candidates overlook

I think W's section here is especially worth pulling out on its own:

"The richest people in the world are all in the US, and the highest SaaS paying rates are in the US too. So the developer world should only be divided into China and overseas."

The specific skill stack:

How to integrate Google OAuth, AWS, and Stripe payments
Vercel deployment, Cloudflare attack protection (not the robot Turnstile kind)
How to write a Vercel template, how to make an open-source project one-click deployable for others
How to integrate into overseas developer communities (X, Hacker News, Reddit, Indie Hackers)

"Domestic big tech is all going overseas too, and the whole pool of domestic capital is going overseas as well."

If you want to be an Agent engineer and also land a good offer, an understanding of the overseas developer ecosystem is genuinely an ability that can open up a real gap.

6.5 Information-gathering ability = a soft skill

In the last stretch of conversation, I said:

"Now that we have AI, the value, or the significance, of the ability to write code itself is gradually decreasing. So you definitely need to develop some so-called soft skills."

W added:

"Do you usually scroll Twitter? You should scroll the AI Twitter more — you'll get a lot of inspiration. The more you scroll and the more you know, the more it's a dimensionality-reduction strike — you go from being a job seeker to being someone in the AI world who's actually taking part in this carnival of building."

This is the most important sentence of the whole interview.

In a field where technology changes on a weekly basis, your information sources determine your ceiling. If you only read WeChat public accounts, Zhihu, and CSDN, what you see is forever translated, filtered, lagged second-hand information. When a new model, framework, or paradigm appears, you find out a week later than practitioners in Silicon Valley and three days later than the earliest people in China to know; three months later, what you see is a chewed-over "explainer article."

To build first-hand information sources:

X / Twitter: follow Anthropic and OpenAI employees, well-known indie developers, founders of AI infra companies
Hacker News: scan the frontpage every day
Official docs / changelogs: the product pages and release notes of Anthropic, OpenAI, Vercel, Cursor
GitHub: follow projects that just launched and went viral; read the code, file issues, join the discussion
Personal blogs: of course, you're also welcome to follow my joyehuang.me hhh — I sediment the interesting things I read each day in the notes section

"You'll change — from being a job seeker to being someone in the AI world who's taking part in this carnival of building."

6.6 On "copying open-source projects"

At the end, the candidate asked: "Are there any recommended open-source projects I can pull down and work on?"

My answer:

"I really don't intend to recommend any project. Now that we have AI, the cost of building a project from scratch is already very low. I'd suggest you discover the needs in your daily life around you — that way, when you tell the whole story in an interview, it'll be more sincere and more convincing. Or you can heavily use Hermes Agent like I do, and wherever you think its code is bad, go change it — so far I haven't met an interviewer who understands the Hermes Agent source better than I do, and that kind of depth is itself scarce. But copying an open-source project directly is something I personally can't really accept."

The reasons:

A copied project — you can't explain "why it's designed this way," so all the "why" questions crash and burn
A copied project has no real motivation of your own for using it — you can't tell the use case
AI coding tools have already driven the cost of "writing from scratch" down to a few hours — there's no need to copy

7. Communication ability: answers that don't hit the point

Throughout the interview I repeatedly pointed out one problem with the candidate: before answering, there'd be a couple of meaningless filler sentences, and it took a long time to grab the core of the question.

The candidate realized it himself too: "I really do need to work more on my verbal expression."

This is actually a severely underrated job-seeking skill. With the same knowledge base, someone who can make a point clearly in 30 seconds versus someone who needs 3 minutes of beating around the bush get completely different interview ratings.

How to improve:

Record and replay: record every mock interview, listen back afterward, and you'll find you have tons of filler words like "um, like, that kind of thing"
Conclusion first, details second: the first sentence of every answer gives the conclusion directly, then you expand
Use technical terms: not "that thing" or "something like that," but "prefix caching," "AQS," "weak reference" — precise wording is itself a display of professionalism
If you're not clear, don't pretend to be — this is the more core point. A lot of the time, the reason you beat around the bush and pile on filler is fundamentally that you're not sure of the answer itself and want to cover it with "saying more." But saying more just gets more wrong; better to directly admit "I'm not too familiar with this." Admitting you don't know is far better than bluffing and getting fished to death.

One more thing W and I observed: sometimes the candidate had actually reached the answer, but just didn't say the term. He'd use an extra sentence or two to describe the concept. In that case, "the knowledge is there but the term isn't," and the interviewer instead judges it as "not familiar."

8. Summary: if you also want to be an Agent engineer

Condensing all the lessons from this interview into a checklist:

Project layer

[ ] Does my project solve a problem that chatting directly with ChatGPT / Doubao / Claude can't solve?
[ ] Does my multi-Agent design give a substantive benefit over a single Agent?
[ ] Is my project deployed and live? Can the interviewer try it?
[ ] Is my project complete with Agent + frontend + backend + evaluation + observability + docs?

Tech-choice layer

[ ] For every technology I used (Redis / vector DB / graph DB / fine-tuning / RAG), can I clearly explain "why this one and not X / Y / Z"?
[ ] Do I know that PostgreSQL + pgvector can replace a standalone vector DB in many scenarios?
[ ] Do I know why Claude Code uses grep instead of RAG?
[ ] Did I use different models tiered for different tasks?

Agent-knowledge layer

[ ] Can I clearly explain the relationship between Function Calling / MCP / Skills / CLI tools?
[ ] Do I know how Skill's progressive disclosure / Claude Code's tool_search work?
[ ] Can I clearly explain prefix-caching-friendly context design?
[ ] Can I clearly explain the memory system's "factual / derived / preference" classification, plus contradiction handling and decay mechanisms?
[ ] Have I studied the Memory evolution of OpenAI / Claude / Hermes / OpenCode?

AI-workflow layer

[ ] Do I have my own AI coding workflow? How do I use AGENTS.md / Skills / Memory?
[ ] Beyond coding scenarios, how else do I weave AI into daily life (scheduling, information feeds, content creation)?
[ ] Can I write Agent evaluations?

Soft-skill layer

[ ] What are my first-hand information sources? Do I read X, HN, and official changelogs every day?
[ ] Do I understand the overseas developer ecosystem (Vercel / Stripe / Cloudflare / OAuth)?
[ ] When answering, can I cut to the core in 30 seconds? Do I use technical terms?

A final note

This interview lasted 1 hour and 19 minutes, and the overall feedback W and I gave the candidate was "the projects need a rewrite, the information sources need to expand, the expression needs practice." It sounds harsh, but his own reaction was "knowing the problems is better than not knowing them."

I agree with that attitude.

"Knowing the problems is already much better than not knowing them; what comes next is your follow-through."

All the problems discussed in this blog post are ones I'm still continuously learning and stumbling through myself. Every day I'm changing Hermes's source, reading Anthropic's official docs, and watching the latest discussions in the AI world on X — not because I'm so great, but because this is the entry ticket for this industry, not a bonus.

If you're also preparing for an Agent-track job search, I hope this helps.

📮 About paid mock interviews / résumé coaching

I'm currently taking paid 1-on-1 mock interviews and résumé coaching for the Agent track, with questions customized to your specific projects and target role and concrete, actionable improvement directions (this blog post is the retrospective of one real mock interview). If you're interested, you can find me on my personal website joyehuang.me, or book directly through the contact info on the site.

I'll keep writing up more mock-interview retrospectives going forward — feel free to follow along.

All names and sensitive information in this article have been de-identified.

Reading OpenHarness: Inside an 11,733-Line Agent Harness

Fri, 10 Apr 2026 00:00:00 GMT

Before we start

I've been using Claude Code for almost half a year now — it's the main coding tool I reach for every single day. But one thing has always nagged at me: I've never actually seen what it looks like on the inside.

Claude Code is a closed-source product written in TypeScript, and the code is obfuscated on top of that. As a developer who wants to grow into full-stack AI Agent work, I know perfectly well that just being able to use it isn't enough — I need to understand how a production-grade Agent is actually built.

A few days ago, the HKUDS lab (the same University of Hong Kong team behind Nanobot) open-sourced OpenHarness, a project that reimplements Claude Code's core architecture in Python. It's only 11,733 lines of code, yet it delivers 43 tools, 54 commands, plus a complete Agent Loop, a permission system, a plugin system, and multi-Agent collaboration.

For me, this was manna from heaven.

What is a Harness? If you've read the recent papers from OpenAI and Anthropic on Agents, you'll recognize a shared premise: the model handles intelligence, the Harness handles everything else. The Harness is the full layer of infrastructure wrapped around the LLM — tools, memory, permissions, context, multi-Agent coordination. In the project author's own words: "The model is the agent. The code is the harness."

This post is my notes from a day spent chewing through OpenHarness's core architecture. I'll take you all the way through Phase 1: from the moment you type the oh command, right down to the beating heart of the Agent Loop.

Why is this project worth studying? Three reasons:

It's small enough: 11,733 lines of Python vs. Claude Code's 512,664 lines of TypeScript — 44x leaner.
It's complete enough: everything you'd expect is there — Agent Loop, Tools, Hooks, MCP, Plugins, Multi-Agent.
It's real enough: it's not a teaching toy, it's a production-grade implementation you can actually run.

Alright, let's hit the road.

1. Fourteen subsystems: the big picture first

Open the src/openharness/ directory and you'll find the whole project carved into 14 submodules. The first time I looked at it I was a little dazed — that's a lot of stuff, where do you even begin?

After spending a bit of time skimming each module's __init__.py, I sketched out this structure diagram:

src/openharness/
│
├── cli.py                 ← entry point: Typer CLI
│
├── engine/                ← 🧠 the core of the core: Agent Loop
│   ├── query_engine.py    ← while True: stream → tool_use → execute → loop
│   ├── query.py           ← the actual loop implementation
│   ├── messages.py        ← message formats
│   ├── cost_tracker.py    ← token billing
│   └── stream_events.py   ← streaming event types
│
├── tools/                 ← 🔧 43 Tools (Bash, Read, Write, Glob...)
│   ├── base.py            ← BaseTool + ToolRegistry
│   └── *_tool.py          ← one Tool implementation per file
│
├── permissions/           ← 🛡️ permission checks (default/plan/full_auto)
├── hooks/                 ← ⚡ lifecycle hooks (PreToolUse/PostToolUse)
│
├── prompts/               ← 📝 System Prompt assembly factory
├── skills/                ← 📚 on-demand .md knowledge files
├── memory/                ← 🧠 persistent cross-session memory
├── plugins/               ← 🔌 plugin system
├── commands/              ← 💬 slash command registry
├── mcp/                   ← 🌐 Model Context Protocol Client
├── tasks/                 ← 📋 background task management
├── coordinator/           ← 🤝 multi-Agent orchestration
│
├── config/                ← ⚙️ configuration management
├── state/                 ← state storage
├── services/              ← helper services
├── bridge/                ← Python ↔ React TUI communication bridge
├── ui/                    ← UI layer entry point
└── keybindings/           ← keybinding configuration

Here's a key observation: these 14 modules aren't all on the same level. They split into three layers:

Execution layer: engine, tools, permissions, hooks — how the Agent runs
Knowledge layer: prompts, skills, memory — what the Agent knows
Extension layer: mcp, plugins, coordinator, tasks, commands — how the Agent connects to the outside world

If this is your first time reading a project like this, I'd suggest reading in the order execution layer → knowledge layer → extension layer. Once you've grasped the trunk, everything else is just an ornament hanging off it.

2. From `oh` to a ready Agent: the full startup chain

Let's start the moment the user types uv run oh and follow the data all the way through.

Entry point: the Typer CLI

Open src/openharness/cli.py and you'll see the familiar CLI argument definitions. This project uses Typer — if you've written Python, think of it as the Python equivalent of yargs or commander:

# cli.py:12-21
app = typer.Typer(
    name="openharness",
    help="Oh my Harness! An AI-powered coding assistant.",
    invoke_without_command=True,
)

All the CLI arguments are defined inside the main() function (cli.py:179-334), including -p/--print, --model, --permission-mode, and so on. Once the arguments are parsed, the code reaches this point:

# cli.py:346-377
if print_mode is not None:
    # non-interactive mode
    asyncio.run(run_print_mode(...))
    return

# interactive mode
asyncio.run(run_repl(...))

Two paths: interactive mode (the default) and print mode (the -p flag). Print mode runs single-process with direct output, which is great for scripting and integration; interactive mode launches the pretty React TUI, which is the interface you see in everyday use.

The dual-process architecture that confused me for a while

Reading ui/app.py:27-47, I got stuck for a moment:

async def run_repl(...) -> None:
    if backend_only:
        await run_backend_host(...)
        return

    exit_code = await launch_react_tui(...)

What on earth is this backend_only branch? I kept tracing the code and opened ui/react_launcher.py:

# react_launcher.py:78-102
env["OPENHARNESS_FRONTEND_CONFIG"] = json.dumps({
    "backend_command": build_backend_command(...),  # ← python -m openharness --backend-only
    "initial_prompt": prompt,
})

process = await asyncio.create_subprocess_exec(
    npm, "exec", "--", "tsx", "src/index.tsx", ...
)

That's when it clicked: in interactive mode, OpenHarness actually runs two processes.

The full startup chain looks like this:

Step 1: you type `oh`
         → Python process A starts
         → its only job is to launch Node.js

Step 2: Node.js starts
         → it renders the TUI you see with React/Ink
         → but Node.js isn't where the AI logic lives
         → so it turns around and spawns Python process B (--backend-only mode)

Step 3: Python process B starts
         → this is the backend that does the real work
         → process A has fulfilled its purpose and exits

In the end only two processes are running: Node.js (the UI) and Python B (the Agent engine). They communicate over a JSON-lines protocol on stdin/stdout.

Why design it this way?

This is the most interesting architectural decision in the whole startup flow. Put plainly, it comes down to picking the right language ecosystem:

| Need | Best tool | |------|-----------| | Rich terminal UI (syntax highlighting, popups, animations) | React/Ink (Node.js ecosystem) | | AI Agent engine (LLM SDK, asyncio, filesystem) | Python ecosystem |

The best tools for these two needs live in different languages. Rather than make do within a single language, let two processes each do what they're best at and talk over JSON.

You'll find this pattern very familiar — when you write Next.js, the browser runs React, the server runs Node.js, and they talk over HTTP. OpenHarness swaps HTTP for the simpler stdin/stdout JSON-lines, because both processes run on the same machine, in the same terminal, with no need for a network stack.

What the communication protocol looks like

Look at ui/protocol.py — the message contract between frontend and backend is spelled out crisply with Pydantic models.

Frontend → backend (protocol.py:15-22):

class FrontendRequest(BaseModel):
    type: Literal[
        "submit_line",           # user typed a line
        "permission_response",   # answer to the permission popup
        "question_response",     # answer to the question popup
        "list_sessions",
        "shutdown",
    ]
    line: str | None = None
    allowed: bool | None = None
    answer: str | None = None

Backend → frontend (protocol.py:55-86): 14 event types, including assistant_delta (streaming text), tool_started/tool_completed (tool lifecycle), modal_request (popup requests), and more.

The essence of this protocol is: one JSON object per line, and reading/writing is just stdin/stdout. No ports, no handshake, no timeout-and-retry. When you're debugging, you can just tail the log and see the entire conversation between the two sides.

`build_runtime()`: the assembly line for the whole Harness

The very first thing backend process B does after it starts is call build_runtime() in ui/runtime.py:89. This is the single most important function in the whole project — it assembles every subsystem into one RuntimeBundle:

# runtime.py:89-176 (simplified)
async def build_runtime(...) -> RuntimeBundle:
    settings = load_settings().merge_cli_overrides(...)
    plugins = load_plugins(settings, cwd)

    resolved_api_client = AnthropicApiClient(
        api_key=settings.resolve_api_key(),
        base_url=settings.base_url,
    )
    mcp_manager = McpClientManager(load_mcp_server_configs(settings, plugins))
    await mcp_manager.connect_all()

    tool_registry = create_default_tool_registry(mcp_manager)
    hook_executor = HookExecutor(...)

    engine = QueryEngine(
        api_client=resolved_api_client,
        tool_registry=tool_registry,
        permission_checker=PermissionChecker(settings.permission),
        system_prompt=build_runtime_system_prompt(...),
        hook_executor=hook_executor,
        ...
    )

    return RuntimeBundle(
        api_client=resolved_api_client,
        tool_registry=tool_registry,
        hook_executor=hook_executor,
        engine=engine,
        ...
    )

Pay attention to how these dependencies are wired together:

First load settings and plugins (the config data).
Use settings to create the AnthropicApiClient.
Create the McpClientManager and connect to all external servers.
Create the ToolRegistry (registering all 43 tools into it).
Create the HookExecutor.
Finally, pass everything above into QueryEngine as arguments.

This is the classic dependency injection pattern. QueryEngine doesn't create any of its own dependencies — they're all passed in from outside. The benefits are immediate:

For testing: you can pass a mock api_client and a mock tool_registry.
For switching to Kimi: you just change settings.base_url, without touching a single line of QueryEngine.
For switching modes: headless/print/interactive can all share the same core.

RuntimeBundle: the container for every dependency

Look at runtime.py:35-48:

@dataclass
class RuntimeBundle:
    api_client: SupportsStreamingMessages   # LLM API client
    cwd: str                                 # working directory
    mcp_manager: McpClientManager           # MCP external tools
    tool_registry: ToolRegistry             # 43 Tools
    app_state: AppStateStore                # UI state
    hook_executor: HookExecutor             # lifecycle Hooks
    engine: QueryEngine                     # Agent Loop engine
    commands: object                        # slash commands
    external_api_client: bool
    session_id: str = ""

To put it in React terms you already know: RuntimeBundle is like packing all your Context Providers into a single object. From here on, no matter which function needs which subsystem, all it has to do is get hold of the bundle.

This pattern is so much better than global variables — every dependency is explicit, and for testing you can construct a mock bundle to run against without touching any business code at all.

3. The Agent Loop: the heart of the whole project

Finally we reach the core. Every critical question in Harness engineering boils down to one thing: how does the Agent Loop run?

The fundamental difference between a plain chatbot and an Agent

Anyone who's built a chat app with the Vercel AI SDK knows the simplest chat flow looks like this:

user sends a message → call the API → AI replies → done

But an Agent is different. The AI might say "I need to read this file first," then you hand it the file contents, and it says "okay, now I'm going to edit line 42," and after you run that and give it the result, it says "done."

A single user message can trigger multiple rounds of AI ↔ Tool interaction.

That loop is the Agent Loop. Its implementation is surprisingly simple — only 70 lines of code, all in src/openharness/engine/query.py.

A line-by-line walkthrough of `run_query`

I'll paste the key parts and we'll go through them section by section:

# query.py:53-86
async def run_query(
    context: QueryContext,
    messages: list[ConversationMessage],
) -> AsyncIterator[tuple[StreamEvent, UsageSnapshot | None]]:
    """Run the conversation loop until the model stops requesting tools."""
    for _ in range(context.max_turns):
        final_message: ConversationMessage | None = None
        usage = UsageSnapshot()

        async for event in context.api_client.stream_message(
            ApiMessageRequest(
                model=context.model,
                messages=messages,
                system_prompt=context.system_prompt,
                max_tokens=context.max_tokens,
                tools=context.tool_registry.to_api_schema(),
            )
        ):
            if isinstance(event, ApiTextDeltaEvent):
                yield AssistantTextDelta(text=event.text), None
                continue

            if isinstance(event, ApiMessageCompleteEvent):
                final_message = event.message
                usage = event.usage

        if final_message is None:
            raise RuntimeError("Model stream finished without a final message")

        messages.append(final_message)
        yield AssistantTurnComplete(message=final_message, usage=usage), usage

        if not final_message.tool_uses:
            return

This code has six key points:

① The turn loop (line 58)

for _ in range(context.max_turns):   # default 8 turns

A safety backstop. It keeps the AI from getting stuck in an infinite loop of tool calls.

② Passing every tool's schema into the API call (line 68)

tools=context.tool_registry.to_api_schema()

This is what lets the AI "know" what it's capable of. The names, descriptions, and parameter formats of all 43 tools are told to the AI in one shot, so it can decide when to call which one. This maps to the tools parameter in the Anthropic API.

③ Streaming handles two kinds of events (lines 71-77)

if isinstance(event, ApiTextDeltaEvent):
    yield AssistantTextDelta(text=event.text), None  # typing increment
    continue

if isinstance(event, ApiMessageCompleteEvent):
    final_message = event.message  # full message
    usage = event.usage

Delta events are yielded immediately so the UI can show the "typing" effect, while the Complete event records the full message and the token usage. This is the same playbook as the Vercel AI SDK's onToken + onFinish.

④ The watershed between an Agent and a chatbot (lines 85-86)

if not final_message.tool_uses:
    return

Just these two lines. If the AI's reply contains no tool_use request, it means it considers the task done, and the entire Agent Loop ends. If there is a tool_use, execution continues down to running the tools.

If someone ever asks you "what's the fundamental difference between an Agent and a chatbot," pointing at these two lines is all the answer you need.

Single tool vs. multiple tools: two execution strategies

Reading further, query.py:88-118:

tool_calls = final_message.tool_uses

if len(tool_calls) == 1:
    # Single tool: sequential (stream events immediately)
    tc = tool_calls[0]
    yield ToolExecutionStarted(tool_name=tc.name, tool_input=tc.input), None
    result = await _execute_tool_call(context, tc.name, tc.id, tc.input)
    yield ToolExecutionCompleted(
        tool_name=tc.name,
        output=result.content,
        is_error=result.is_error,
    ), None
    tool_results = [result]
else:
    # Multiple tools: execute concurrently, emit events after
    for tc in tool_calls:
        yield ToolExecutionStarted(tool_name=tc.name, tool_input=tc.input), None

    async def _run(tc):
        return await _execute_tool_call(context, tc.name, tc.id, tc.input)

    results = await asyncio.gather(*[_run(tc) for tc in tool_calls])
    tool_results = list(results)

    for tc, result in zip(tool_calls, tool_results):
        yield ToolExecutionCompleted(
            tool_name=tc.name,
            output=result.content,
            is_error=result.is_error,
        ), None

There's a very pragmatic design choice here:

A single tool: streaming events come first — started and completed arrive one after the other.
Multiple tools: speed comes first — they run concurrently via asyncio.gather.

Why make the distinction? It's a balance between performance and user experience.

Imagine the AI asks to read 3 files at once:

Sequential: 100ms + 100ms + 100ms = 300ms
Concurrent: max(100, 100, 100) ≈ 100ms

Running multiple tools in parallel collapses the latency down to the slowest single tool. That's exactly why Claude Code has increasingly favored letting the AI call several tools at once — the parallelism behind it is asyncio.gather, the equivalent of Promise.all in JS.

But for a single tool there's no point reaching for asyncio.gather; it would only cost you the immediate feedback — so the code deliberately splits into two branches.

The safety chain for tool execution

Before any tool actually runs, it passes through a complete chain of safety checks. This lives in the _execute_tool_call function at query.py:124-211:

AI requests to execute a tool
    │
    ▼
① PreToolUse Hook
   → e.g. the security-guidance plugin checks for dangerous commands
   → the Hook can block this execution outright
    │
    ▼
② find the tool implementation
   → tool_registry.get(tool_name)
    │
    ▼
③ validate input parameters (with Pydantic)
   → tool.input_model.model_validate(tool_input)
   → wrong type errors out immediately
    │
    ▼
④ permission check
   → permission_checker.evaluate(...)
   → check mode (default/plan/full_auto)
   → check path_rules (some paths are off-limits)
   → check denied_commands (some commands are off-limits)
   → if confirmation is needed → trigger the permission_prompt popup
    │
    ▼
⑤ actually execute the tool
    │
    ▼
⑥ PostToolUse Hook (logging, etc.)

That "Allow / Deny" popup you see every time in Claude Code is step ④. Here's the implementation in code (query.py:168-182):

decision = context.permission_checker.evaluate(
    tool_name,
    is_read_only=tool.is_read_only(parsed_input),
    file_path=_file_path,
    command=_command,
)
if not decision.allowed:
    if decision.requires_confirmation and context.permission_prompt is not None:
        confirmed = await context.permission_prompt(tool_name, decision.reason)
        if not confirmed:
            return ToolResultBlock(
                tool_use_id=tool_use_id,
                content=f"Permission denied for {tool_name}",
                is_error=True,
            )

context.permission_prompt is an async callback. In print mode it's a no-op (everything is allowed); in interactive mode it sends a BackendEvent.modal_request to the React frontend, the frontend renders the popup, and after the user clicks Allow/Deny the result is sent back via FrontendRequest.permission_response.

The dual-process architecture I described earlier shows itself most vividly right here — the permission popup is a cross-process async wait.

One full Agent loop, end to end

Let's tie it together with a concrete example. Suppose you ask the AI to "read README.md and then summarize it":

Turn 1:
  messages = [{ role: "user", text: "read README.md and then summarize it" }]
  → call the API, passing in all tool schemas
  → AI replies: "Let me read it" + tool_use: Read({ file_path: "README.md" })
  → tool_uses is non-empty, keep looping
  → execute the Read tool:
    ① PreToolUse Hook passes
    ② tool_registry.get("Read") finds the tool
    ③ Pydantic validates file_path
    ④ permission check (read-only operation, passes)
    ⑤ read the file
    ⑥ PostToolUse Hook
  → append the tool result as a user message
  → messages now has 3 entries

Turn 2:
  → call the API
  → AI replies: "This README covers three main points: 1... 2... 3..."
  → tool_uses is empty
  → return, loop ends

That's the Agent's complete lifecycle — two for-loops and one if-check. But those two lines, if not final_message.tool_uses: return, are the soul of the Agent.

4. A few design decisions worth remembering

After finishing Phase 1, there are a few design decisions I think are especially worth keeping in mind.

Decision 1: why use a `RuntimeBundle` instead of globals?

Over a session's lifetime, a lot of things (the api client, the tool registry, the permission checker...) get used all over the place. The laziest approach is to make them module-level globals and import them wherever you need them.

But OpenHarness chooses to pack them into a RuntimeBundle and pass it along the way. The cost is longer function signatures; the benefit is that every dependency is explicit, and it supports running multiple sessions at once.

This is the difference between writing production-grade code and a toy project.

Decision 2: why split single-tool and multi-tool into two branches?

You could perfectly well unify everything under asyncio.gather, treating a single tool as a one-element gather. The code would be cleaner.

But OpenHarness deliberately splits them, because in the single-tool case, immediate feedback matters more than parallelism. When a user's action runs just one tool, they want to see the complete "started → (running) → completed" stream.

This is an easy-to-miss UX decision, but it reflects how much the author cares about the details.

Decision 3: why use Pydantic to validate tool inputs?

You could absolutely let each tool write if not isinstance(x, str): raise inside its own execute. But OpenHarness mandates an input_model: type[BaseModel] in the BaseTool base class — every tool has to provide a Pydantic model.

The benefits run in several directions:

Auto-generated JSON Schema: the tools parameter sent to the LLM can be generated straight from the Pydantic model.
Unified error handling: a single try/except at query.py:150-157 catches the argument errors of every tool.
Type safety: the tool's execute method receives a strongly typed object, not a dict.

What you'd do with zod in TypeScript, you do here with Pydantic.

5. A suggested reading path

If you want to read this project yourself, here's the order I'd recommend:

Day 1: the trunk (Phase 1)

cli.py → see how the CLI arguments are organized
ui/app.py + ui/runtime.py → see the startup chain
ui/react_launcher.py + ui/backend_host.py → understand the dual-process architecture
ui/protocol.py → see the frontend/backend communication protocol
engine/query_engine.py + engine/query.py → the key part, read it over and over
engine/messages.py + engine/stream_events.py → the data structures

Day 2: the tool system

tools/base.py → the Tool base class
tools/__init__.py → the registry
Pick 3 representative tools and read them deeply:
- tools/bash_tool.py (shell execution)
- tools/file_edit_tool.py (file editing)
- tools/agent_tool.py (sub-Agent invocation)

Day 3: the knowledge system

prompts/system_prompt.py → how the System Prompt is assembled
skills/registry.py → how Skills are loaded on demand
memory/manager.py → how persistent memory works

Day 4: the extension system

permissions/checker.py → the details of permission checking
hooks/executor.py → the Hook executor
plugins/loader.py → plugin discovery and loading
mcp/client.py → the MCP protocol

6. Final thoughts

After finishing Phase 1, my understanding of the term "Agent Harness" changed completely.

I used to think of an Agent as something mysterious. Only after reading the code did I realize — it's just a for-loop plus an if-check. All the mystery lives in the model; what the Harness does is plain engineering: providing the model with tools, checking permissions, logging, managing sessions, assembling context.

This realization is valuable to me, because it means: if you understand the structure of a Harness, you can build one yourself. All those concepts the OpenAI and Anthropic papers keep mentioning — tool use, planning, reflection, memory, multi-agent — each one has a corresponding implementation you can find in the OpenHarness code.

Next I'll keep reading Phases 2-6 and chew through the remaining 15 topics. Once I've finished the whole project, I'll write a wrap-up.

If you want to learn Agent development too, I highly recommend spending a few days reading OpenHarness. It's not long, but it's real.

Project: HKUDS/OpenHarness

About the author

I'm Joye, a developer working toward full-stack AI Agent development, building internship projects day to day with TypeScript + Next.js + the AI SDK. This is the first post in my learning-notes series, and I'll keep updating it with the other Phases of OpenHarness.

Blog: joyehuang.me

If this post helped you, feel free to find me on Xiaohongshu to chat.

A Sophomore Intern's Field Guide to Agent Dev Interviews

Mon, 09 Mar 2026 00:00:00 GMT

After interviewing with nearly 10 AI startups, I want to talk about what Agent-role interviews actually test, and the things that matter a hundred times more than "memorizing answers."

Before We Start

I'm Joye, a sophomore at the University of Melbourne studying Computing and Software Engineering. For the past few months I've been doing an AIGC R&D internship at Tezign in Shanghai, working mainly on Atypica — a Multi-Agent system focused on business research.

I've recently been looking for new opportunities and have interviewed with close to 10 companies, all of them AI startups or overseas startups, with roles concentrated in Agent development and LLM application engineering. Looking back after the fact, I realized that interview experience for this field is pretty scarce on the Chinese internet — unlike frontend and backend, where there's a systematic body of canned interview questions to grind, Agent development interviews feel more like a deep conversation about "do you actually understand what you're building?"

So I'm writing this article partly to organize and review my own interview notes, and partly to offer a reference to others exploring the same direction.

But first I want to say one thing: this article isn't only for people preparing for interviews — it's just as much for people who are learning Agent development and building their own Agent projects.

Why do I say that? Because there's a fundamental difference between Agent development interview questions and frontend trivia — you might memorize frontend trivia and never use it in your life, but the questions you get asked in an Agent interview are design decisions you genuinely have to grapple with while building the project. "What do you do when the context overflows?" isn't an interview question; it's an engineering problem you're guaranteed to hit when your Agent reaches its 20th turn of conversation. "How do you stop the LLM from misusing tools?" isn't the interviewer being difficult; it's a bug report you'll receive in your first week after shipping to production.

Look at it from another angle: if you've already done serious context engineering in your own project, built in reliability safeguards for tool-calling, and thought through defenses against prompt injection — then these aren't interview questions you need to "prepare," they're hands-on experience you can naturally talk through, and that's what genuinely sets you apart. Going forward, I'll carry these same questions into the design of every new project I build.

What Agent-Role Interviews Actually Test

How It Differs from Traditional Dev Interviews

After this many rounds, my single biggest takeaway is that Agent development interviews have almost no "right answers."

In a traditional frontend interview you can memorize closures, the event loop, and the virtual DOM diff algorithm, and once you have, you're 70–80% covered. Agent interviews are different. A lot of the questions are open-ended — the interviewer isn't testing what you've memorized, they're testing what you've been through. "What did you do when your Agent got stuck in an infinite loop?" — you can't make up an answer to that if you've never fallen into the pit yourself.

From what I've observed, the things interviewers care about fall roughly into three layers:

Can you use it? — Have you used LangChain? How did you build the RAG? How did you design the MCP Server?
Do you understand why it's designed that way? — Why does a structured Prompt work better? Why do memory layers matter? Why did you pick the Vercel AI SDK?
Can you make trade-offs under engineering constraints? — What do you do when the token budget is tight? How do you balance response speed against quality? How do you guard against model hallucination?

The first layer comes from experience, the second from understanding, the third from judgment. Each one is harder to prepare for than the last, but each also reveals more about a person's engineering maturity.

A Full Map of the Interview Questions

I sorted the questions I ran into over this period by theme. Together they cover most of what gets probed in an Agent development interview:

RAG and Retrieval Augmentation

The difference between multi-RAG and single-RAG, and when each fits
How to do Retrieval Augmentation
When RAG should use vector retrieval versus graph-database retrieval
How to do data cleaning for RAG
The evolution path of RAG → Agentic Search → Agentic Memory

Agent Architecture and Orchestration

Agent routing design: how to decide which Sub-Agent to call
Designing the Agent's fallback mechanism
Are Sub-Agents parallel or asynchronous? Can they communicate with each other?
How to stop the LLM from misusing tools
How to handle the LLM calling tools in an infinite loop
How to design an MCP Server
Overall framework design for the Agent flow
How to build a callback mechanism

Context Engineering and Token Management

How to save tokens
What to do when the context overflows (beyond FIFO, what other options are there?)
How to convert short-term memory into long-term memory
Prompt compression strategies
Where to place Prompt Cache hits

Prompt Engineering and Security

Why a structured Prompt helps improve response quality
How to design a subtle, emotionally-aware CoT for affective tasks
How to prevent malicious prompt injection
How to translate abstract requirements into concrete ones (making the AI "smarter" and "more human")
Did you build prompt-injection protection at the start and end of the interview flow?
The downside of one-shot: examples that aren't differentiated enough constrain the model's thinking

LLM Fundamentals and Model Engineering

The Attention mechanism (general knowledge)
Pretraining and LoRA fine-tuning
The design and limitations of LLM-as-a-Judge
The trade-off between response speed and response quality
How to avoid OOC (Out of Character)
How to handle LLM hallucination

AI Infra and Productionization

Designing a model gateway / Agent gateway
Building an Eval platform
Evaluating DPO / APO algorithms
Why use the Vercel AI SDK

Industry Awareness and System Design

How Manus, OpenClaw, and OpenCode each approach their architecture
The main application scenarios for Agents: AI search, Chat-to-BI chart generation, Vibe Coding
The relationship and difference between Skill and MCP
Experience with LangChain / LangGraph

Once you've read this list, you'll probably notice that not a single one of these can be solved by "memorizing." What they test is your holistic understanding of the system and your judgment in real engineering.

The Questions That Made Me Grow the Most

Rather than listing a "model answer" for every question, I'd rather share a few moments in interviews that genuinely made me grow. Some of these I answered well at the time, some I didn't — but all of them kept reshaping how I think about Agent development long after the interview ended.

"What do you do when the context overflows? Besides FIFO, what else?"

Almost every company asked this, and the interviewer usually wasn't satisfied with just "FIFO — evict the oldest messages."

The first time I got asked this, I really did only come up with FIFO. The interviewer pressed further: what if the user stated a critical constraint at the very start of the conversation, and FIFO just threw it away? I froze.

It was only when I reviewed the interview afterward that I realized this question is fundamentally testing your big-picture grasp of Context Engineering. On the Atypica project we were actually already doing all of this — memory layering (Working Memory / Short-term / Long-term), summary compression, retrieval splicing, token-budget control — but I hadn't strung them together into a complete pipeline in my answer.

This experience taught me one thing: having done something isn't the same as being able to explain it clearly. A lot of the time you've already solved some problem in your project, but if you never abstracted it into a systematic approach, you'll fumble and fail to articulate it in the interview. From then on, I deliberately started re-mapping every design decision in Atypica using a "problem → solution → trade-off → result" framework.

"How do you stop the LLM from misusing tools?"

This sounds simple at first — just add some permission controls, right? But interviewers wanted far more than that.

In Atypica we built an asynchronous state machine for tool-calling, with mechanisms like checkpoints, retries, idempotency, timeout rollback, and state recovery. But "preventing misuse" isn't only about backstopping after the fact — what matters more is the upfront constraints: is the Tool Schema design clear enough? Are the Function Calling descriptions free of ambiguity? Does the routing logic correctly dispatch requests to the right tool?

In one interview the interviewer kept pressing: what if the LLM enters an infinite loop and keeps calling the same tool over and over? I mentioned the watermark and deduplication mechanisms we built, plus the checkpoint-resume design. The interviewer nodded, but then said something that stuck with me: "Have you ever considered that, rather than building so much defense at runtime, it might be better to spell out the boundaries of tool usage at the Prompt layer in the first place?"

That remark was a wake-up call. The root of many Agent reliability problems isn't in the runtime layer but in the Prompt layer — if the instructions you give the LLM are vague to begin with, no amount of engineering backstop is anything more than cleaning up after a bad Prompt. That's exactly why I've come to put more and more weight on structured Prompt design and front-loaded guardrails.

"Why does a structured Prompt work better than a natural-language Prompt?"

I thought this one was easy at first: "Because structured information is easier for the model to parse." But the interviewer followed up: "From the standpoint of the Attention mechanism, can you explain why?"

At the time my understanding of Attention was still stuck at "Q, K, V take dot products to compute relevance," and I'd never thought deeply about its relationship to Prompt format. The interviewer offered a genuinely illuminating line of thinking: a structured Prompt (using XML tags, a JSON Schema, or explicit delimiters, say) is actually helping the model allocate its attention — it gives key information clearer "anchors" within the token sequence, lowering the difficulty of the model "finding the point" in a long context. Natural-language phrasing, by contrast, tends to bury key information under a pile of modifiers and transitional sentences, scattering attention.

This conversation made me realize that a lot of the Prompt optimizations we do at the engineering level are actually backed by very solid model mechanics. Knowing the "what" matters, but knowing the "why" matters more — and that's especially true in interviews, where an interviewer can quickly tell whether you're "reciting experience" or "actually understand it."

"How do you translate abstract requirements into concrete ones?"

This might be the most "soft" hard question I ran into.

The interviewer's exact words were roughly: "The user says 'make the AI a bit smarter' or 'make it feel more like a real person' — how do you turn that kind of fuzzy requirement into a technical solution you can actually ship?"

This happened to be exactly what I'd spent a huge amount of time on in Atypica. We designed a Counter-Questioning system: when a user's requirement is vague, the Agent doesn't grit its teeth and guess — instead, through explicit and implicit intent recognition, it decomposes the fuzzy requirement into structured constraints: what's the goal, who's the audience, what are the style preferences, what are the limitations.

I walked through the full design rationale of this system in the interview, and after listening the interviewer asked a question I thought was really sharp: "So how do you judge the quality of the Counter-Questioning? How do you know the questions you're asking are effective and not just burning the user's patience?"

Honestly, I didn't answer that one well at the time. I thought about it for a long while afterward and figured it would probably need LLM-as-a-Judge or indirect indicators like user satisfaction to evaluate — but that's a direction I genuinely haven't yet explored in depth. That's just how interviews work: they pinpoint the exact edge of your knowledge.

"How do you prevent malicious prompt injection?"

This question came up in multiple interviews, but what really benefited me wasn't the interview itself — it was the homework I did afterward.

In the interviews I touched on some basic defensive ideas — input filtering, role locking, output validation, that sort of thing. But the interviewers were clearly hoping for a more systematic answer. So afterward I went and seriously read OpenAI's and Anthropic's respective technical blogs on prompt security, and found that the field actually has two very clear core ideas:

One is OpenAI's Instruction Hierarchy — the core idea is to assign priorities to instructions from different sources: System Prompt > developer instructions > user input, so the model knows whom to listen to when it hits conflicting instructions. The other is Anthropic's sandboxing approach — isolating untrusted external content inside a restricted execution environment, limiting the blast radius of malicious instructions at the architectural level.

Why do I single this out? Because I genuinely recommend that everyone doing Agent development spend time reading OpenAI's and Anthropic's technical blogs. These aren't academic papers stuck at the theoretical level — they're excellent, frontline engineering practice advice, and after reading them your understanding of many problems will level up. Papers are worth reading too, of course — I'll be putting out a curated paper series on my personal blog, picking out and breaking down the papers most valuable to Agent development practice. I'm also building an RSS subscription feed that aggregates the latest Agent development practices from the major AI labs, daily or weekly, with my own take and commentary added — not just reposting, but opinionated curation and interpretation. If you're interested, follow my blog at joyehuang.me for updates.

"Do you understand the design of Manus / OpenClaw / OpenCode?"

This isn't a question about technical depth — it's a question about industry breadth. What the interviewer wants to know is: are you paying attention to what's happening in this industry? Are you only heads-down grinding on your own project, or do you also look up and see how other people are solving similar problems?

At the time I had some familiarity with Manus and OpenCode (I'd studied OpenCode's architecture), but I didn't know much about OpenClaw and my answer was a bit weak. This question reminded me: Agent development is still in a phase of rapid evolution, and when interviewers probe industry awareness, they're essentially testing your learning speed and your sensitivity to new information.

If you don't regularly check GitHub Trending, don't follow the AI discussion on Twitter/X, and don't dig into newly released open-source projects, you'll be in a really weak position when this kind of question comes up. I later built a habit of spending a fixed block of time each week looking at the changelogs and design docs of projects like Manus and OpenCode — not necessarily deeply, but at least enough to know which way the industry wind is blowing.

The Things That Matter More Than "Grinding Questions"

On the Interview Itself

Reviewing afterward is the biggest lever in interviewing.

This is the point I most want to stress: an interview you don't review is meaningless. If recording isn't an option, then the moment the interview ends, find a place to sit down and — while your memory is still warm — write down every question and your own answer. Especially the ones you couldn't answer, or stumbled through — those are the most valuable review material. The list of interview questions you're reading in this article was recorded exactly this way, round after round.

Let the interviewer review you.

A lot of people overlook the value of the part at the end where you get to ask the interviewer questions. I later made it a habit to always ask two questions in that segment: "Where did I not do so well today, and what should I improve?" and "Where did I do reasonably well?" You might think asking this is too direct, but in practice most interviewers are very willing to answer. The feedback they give you is far more precise than your own guessing, and it also shows you're someone who actively seeks growth.

Besides those two questions, you can also ask "What would the first project be that I'd take on after joining?" — this shows your sincerity and also helps you judge whether the actual work matches the JD.

The interviewer is also part of your network.

After the interview, regardless of the outcome, try to add the person on WeChat or LinkedIn. You never know when that relationship will pay off. Here's a real story: I interviewed with a toB Fintech Agent company and passed the first round, but the interviewer felt their product direction might not fit my interests, so they proactively referred me to another company. I'm now in that company's written-test stage. Sometimes opportunities come exactly like this — you never know where a "failed" interview will lead.

On Choosing Offers: Advice for Interns and Startup-Bound Folks

Use one question to filter out unreliable startups.

When interviewing with a startup, I always ask one question in the Q&A segment: "Compared to your competitors, what's the core advantage of your product?" It sounds simple, but its filtering power is excellent — if a startup's interviewer can't even articulate their own product's differentiation, then that company's direction is probably fuzzy. If a startup doesn't even have confidence in its own product, what can you possibly learn there? Just steer clear.

Don't get suckered by "raised X million in angel funding."

The funding amount is only one dimension for judging a startup — it's absolutely not the only one. That said, a company with no funding at all does warrant extra caution. But having funding doesn't mean everything's fine — you still need to look at whether the product direction is sound, the team's background, whether you'll genuinely learn something there, and whether there's a mentor to guide you. An internship isn't just selling time; it's a learning investment, and you need to think clearly about where your time yields the highest return.

For me personally, the things I care about most when choosing an offer are: is the product interesting? Am I actually genuinely curious about it? Is it overseas-facing? Is it toC? These preferences vary from person to person, but the point is that you need your own framework for judgment, rather than being led around by the funding amount or a company's name.

Take the initiative — don't let the "full-time" label scare you off.

On Boss Zhipin and various recruiting platforms, a lot of postings say they're hiring full-time. But if you feel the role is a great fit, you can absolutely reach out proactively and explain your situation: "I'm still a student, but if your company has any need for interns, I hope you'll take a look at my résumé." The worst outcome is getting rejected, but a lot of the time the company actually does have intern headcount — they just didn't post it separately.

A tangent: if your internship experience is solid enough, you can even go straight for full-time roles. I interviewed for a full-time Agent development role, got grilled badly, and somehow passed — the interviewer only realized at the very end that I hadn't graduated yet. That made me realize that you shouldn't limit yourself; other people's expectations of you are often not as low as your own expectations of yourself.

Industry Observations: Reading the Agent Dev Winds from Interview Questions

Interview questions are themselves an industry weathervane — what interviewers ask reflects, to some degree, what the industry cares about most right now. Across these nearly 10 interviews, I observed a few clear trends.

RAG Is Evolving Toward Agentic

Almost every interview asked about RAG, but not a single one stopped at the basic "retrieval + generation" level. Interviewers cared more about Agentic Search and Agentic Memory — meaning retrieval is no longer a passive pipeline, but something the Agent itself decides: "when to search, what to search for, and how to use the results." This is a qualitative shift from a tool to a capability.

The Three Big Agent Use Cases Come Up Again and Again

In conversations with interviewers from different companies, three application scenarios came up most often: AI search (the upgrade from keyword matching to semantic understanding), Chat-to-BI (generating data-analysis charts from natural language), and Vibe Coding (using AI to assist or even lead the writing of code). Each of these places different demands on Agent architecture design, but their common thread is the pursuit of stronger "autonomy" and "reliability."

The AI Infra Layer Is Starting to Be Taken Seriously

In the early days of Agent development, everyone focused more on the upper-layer application logic — how to write Prompts, how to chain things together. But interviews increasingly feature AI Infra–layer questions: How do you design a model gateway? How does an Agent gateway handle routing and rate limiting? How do you build an Eval platform? How much do you know about alignment algorithms like DPO/APO? This signals that the industry is moving from the "demo stage" toward "production-grade," and infrastructure maturity is becoming a key factor in determining product reliability.

MCP and the Skill System Are Standardizing

MCP (Model Context Protocol) came up very frequently in interviews; it represents a direction toward standardizing how Agents invoke capabilities. At the same time, the concept of Skill is emerging from products like Manus — packaging an Agent's capabilities into reusable, composable modules. For developers, this trend means: future Agent development may no longer be building from scratch, but assembling and orchestrating within a standardized capability marketplace.

Tool-Chain Choices Reveal Engineering Taste

Why use the Vercel AI SDK instead of LangChain? A question like this looks like it's testing your tech-stack choices, but it's really testing your understanding of the tool-chain ecosystem and your own engineering judgment. Being able to clearly explain in an interview "why I chose this, what its trade-offs are, and in what scenarios I'd switch to something else" is far more convincing than simply saying "I've used X."

Closing Thoughts

After this many rounds, my biggest takeaway is: an interview is a mirror, and it won't lie to you.

It will pinpoint every gap in your knowledge, and it will make you discover the things you thought you understood but had really only "used." Going from "I've used Agents in my project" to "I can design a reliable Agent system" — what lies between them isn't more project experience, but deeper understanding and more systematic thinking.

As a student still in my sophomore year, I know I still have a lot to learn. But this stretch of intensive interviewing gave me a far clearer panorama of Agent development than I had before — not just technically, but in terms of industry judgment too.

Finally, a line for friends walking the same path:

Build fast, learn faster. An interview isn't the finish line; it's the starting line of the next stretch of growth.

If this article helped you, feel free to share your own interview experiences in the comments, and you can also find me on GitHub.

FeedForward: The Transformer's Other Half Beyond Attention

Fri, 19 Dec 2025 00:00:00 GMT

This is the fourth post (of four) in my MiniMind learning series. It takes a deep dive into the FeedForward network and shows how the four core components — RMSNorm, RoPE, Attention, and FeedForward — assemble into a complete Transformer Block. By the end, you'll have a thorough grasp of the full Transformer architecture.

About this series

MiniMind is a concise yet complete project for training a large language model, covering the full pipeline from data processing and model training to inference and deployment. As I worked through it, I distilled the core technical points into the minimind-notes repository and produced this four-part blog series, walking through the core components of the Transformer in a systematic way.

This series covers:

Normalization — why we need RMSNorm
RoPE positional encoding — how to make the model understand word order
The Attention mechanism — the core engine of the Transformer
FeedForward and the full architecture (this post) — how the components work together

1. Introduction

1.1 The neglected other half

When people think of the Transformer, the usual associations are:

✅ The Attention mechanism (the star component)
✅ Positional encoding (RoPE)
❓ FeedForward? What's that?

The facts:

FeedForward accounts for 40% of the code in a Transformer Block
FeedForward makes up two-thirds of the total parameters!
You can't train a good model with Attention alone, without FeedForward

1.2 Questions this post answers

What does FeedForward actually do?
Why "expand then compress" (768 → 2048 → 768)?
What makes SwiGLU better than a plain FFN?
How do Attention and FeedForward divide the labor?
How do the four components assemble into a complete Transformer Block?
What does the residual connection do?

1.3 Who this is for

You've studied Attention but FFN is still fuzzy
You want a complete understanding of the Transformer architecture
You're getting ready to implement a Transformer from scratch
You want to know why the Transformer "works"

2. What is FeedForward?

2.1 The core idea

"Apply a complex nonlinear transformation to each token's vector."

Key characteristics:

✅ Each token is processed independently (no token-to-token interaction)
✅ Input dimension = output dimension (768)
✅ But the content changes completely (it goes through a nonlinear transformation)
✅ It boosts expressive power by routing through a high-dimensional space

2.2 A typical structure

input:   [batch, seq_len, 768]
  ↓
expand:  Linear(768 → 2048)
  ↓
activate: a nonlinear function (ReLU/GELU/SiLU)
  ↓
compress: Linear(2048 → 768)
  ↓
output:  [batch, seq_len, 768]

2.3 A simple implementation

import torch
import torch.nn as nn
import torch.nn.functional as F

class SimpleFeedForward(nn.Module):
    def __init__(self, hidden_size=768, intermediate_size=2048):
        super().__init__()
        self.w1 = nn.Linear(hidden_size, intermediate_size, bias=False)
        self.w2 = nn.Linear(intermediate_size, hidden_size, bias=False)

    def forward(self, x):
        # x: [batch, seq_len, 768]
        h = self.w1(x)       # expand: [batch, seq_len, 2048]
        h = F.relu(h)        # activation
        output = self.w2(h)  # compress: [batch, seq_len, 768]
        return output

2.4 Comparison with Attention

# Attention
sentence: "I love coding"
# "love" can see "I" and "coding"
# → tokens interact, fusing context

# FeedForward
sentence: "I love coding"
# "love" only looks at itself, transformed independently
# → each token is independent, processed in depth

An analogy:

Attention = a meeting where everyone exchanges information
FeedForward = everyone thinking on their own, digesting that information independently

3. Why "expand then compress"?

3.1 A common question

"Why not just go 768 → 768 directly? Taking a big detour out to 2048 and back — isn't that wasted compute?"

That's a great question!

3.2 The intuition: expressive power

Option 1: a direct transformation

# 768 → 768
output = W @ x  # W is a [768, 768] matrix

# This is just a linear transformation!
# Expressive power = a single matrix multiply

Option 2: expand then compress

# 768 → 2048 → 768
h = W1 @ x           # [2048, 768] @ [768] = [2048]
h = activation(h)    # nonlinear!
output = W2 @ h      # [768, 2048] @ [2048] = [768]

# Expressive power = two matrix multiplies + a nonlinear activation
# Can fit far more complex functions!

3.3 The mathematical essence: the magic of high-dimensional space

Key insight: in a high-dimensional space, vectors have more "degrees of freedom."

A simplified view:

Direct transformation (768 → 768): can only form linear combinations, constrained by the original dimensionality
Expanding to high dimensions (768 → 2048): more degrees of freedom in the high-dimensional space
Nonlinear activation: introduces nonlinear transformation capacity
Compressing back to the original dimension (2048 → 768): retains the complex patterns learned in the high-dimensional space

Experimental verification: when fitting a complex function (such as y = sin(x) + cos(2x)):

Direct transformation Linear(1, 1): can only fit a linear function, large error ❌
Expand-compress Linear(1, 64) → ReLU → Linear(64, 1): can fit nonlinear functions, small error ✅
Conclusion: expand-compress = expressive power++

3.4 Analogies

Analogy 1: cooking

Direct transformation (768 → 768):
  raw ingredients → plated
  no processing, one-note flavor ❌

Expand-compress (768 → 2048 → 768):
  ingredients → chopped, seasoned, cooked (2048-dim high-dimensional space) → plated
  "processed" in a high-dimensional space, rich flavor ✅

Analogy 2: photo editing

Direct transformation:
  original → a simple filter → output
  limited effect ❌

Expand-compress:
  original → extract features (more dimensions) → complex transformation → compress back to original size
  enables complex operations like denoising and super-resolution ✅

3.5 Why 2048 dimensions (and not 1024 or 4096)?

Rule of thumb: intermediate_size ≈ hidden_size × 2.67 to 4

| Model | hidden_size | intermediate_size | Ratio | |------|-------------|-------------------|------| | BERT-Base | 768 | 3072 | 4.0 | | GPT-2 | 768 | 3072 | 4.0 | | Llama-7B | 4096 | 11008 | 2.69 | | MiniMind | 768 | 2048 | 2.67 |

Why not larger?

Larger = more parameters = slower and more memory-hungry
2.67–4× is the empirically validated sweet spot

4. SwiGLU: the modern Transformer's choice

4.1 The evolution of FeedForward

Generation 1 (GPT-2 / BERT, 2018–2019):

h = ReLU(W1 @ x)
output = W2 @ h

Generation 2 (GPT-3, 2020):

h = GELU(W1 @ x)  # a smoother activation function
output = W2 @ h

Generation 3 (Llama / MiniMind, 2023):

gate = SiLU(W_gate @ x)
up = W_up @ x
h = gate * up  # a gating mechanism! ⭐
output = W_down @ h

4.2 SwiGLU in detail

Full name: Swish-Gated Linear Unit

Core idea: use two branches, one controlling the other.

import torch
import torch.nn as nn
import torch.nn.functional as F

class SwiGLU(nn.Module):
    def __init__(self, dim=768, hidden_dim=2048):
        super().__init__()
        # three linear layers
        self.gate_proj = nn.Linear(dim, hidden_dim, bias=False)  # gating branch
        self.up_proj = nn.Linear(dim, hidden_dim, bias=False)    # up-projection branch
        self.down_proj = nn.Linear(hidden_dim, dim, bias=False)  # down-projection

    def forward(self, x):
        # two branches
        gate = self.gate_proj(x)  # [batch, seq, 2048]
        up = self.up_proj(x)      # [batch, seq, 2048]

        # SiLU activation + gating (element-wise product)
        hidden = F.silu(gate) * up

        # compress back to the original dimension
        output = self.down_proj(hidden)
        return output

Dimension changes:

input:  [batch, seq, 768]
  ↓
gate:  [batch, seq, 2048]  ← W_gate @ x
up:    [batch, seq, 2048]  ← W_up @ x
  ↓
hidden: [batch, seq, 2048]  ← SiLU(gate) * up
  ↓
output:  [batch, seq, 768]   ← W_down @ hidden

4.3 The SiLU activation function

# SiLU(x) = x * sigmoid(x)
def silu(x):
    return x * torch.sigmoid(x)

# also known as Swish

Compared with common activation functions:

| Activation | Formula | Characteristics | |---------|------|------| | ReLU | max(0, x) | simple, but the gradient can be 0 | | GELU | x * Φ(x) | smooth, but slightly slower to compute | | SiLU/Swish | x * σ(x) | smooth and fast to compute ✅ |

4.4 The power of the gating mechanism

Intuition: the gate branch controls which information from the up branch gets through.

# example
gate = torch.tensor([0.1, 0.9, 0.5, 0.2])  # gating values
up = torch.tensor([5.0, 3.0, 2.0, 8.0])    # up-projection values

# element-wise product
hidden = gate * up
# = [0.5, 2.7, 1.0, 1.6]

# observe:
# where gate=0.9: most of the information passes (2.7 ≈ 3.0)
# where gate=0.1: only a little passes (0.5 << 5.0)

An analogy:

Plain FFN:
  all information passes through the same "gate" (a single activation function)

SwiGLU:
  the gate branch acts like a "security guard," deciding which information from the up branch can enter
  a dynamic, more flexible choice!

4.5 Plain FFN vs SwiGLU

| Feature | Plain FFN | SwiGLU | |------|---------|--------| | Number of branches | 1 | 2 (gate + up) | | Activation | ReLU/GELU | SiLU | | Gating | none | yes (gate × up) | | Parameters | 2 × 768 × 2048 | 3 × 768 × 2048 (50% more) | | Compute | less | slightly more | | Performance | good | better (empirically proven) | | Models used in | GPT-2, BERT | Llama, MiniMind, PaLM |

4.6 Why the extra parameters are worth it

# parameter comparison (using MiniMind as an example)
plain FFN parameters:
  W1: 768 × 2048 = 1,572,864
  W2: 2048 × 768 = 1,572,864
  total: 3,145,728

SwiGLU parameters:
  gate_proj: 768 × 2048 = 1,572,864
  up_proj: 768 × 2048 = 1,572,864
  down_proj: 2048 × 768 = 1,572,864
  total: 4,718,592 (50% more)

# but!
# Attention layer parameters: 768 × 768 × 4 ≈ 2.4M
# SwiGLU parameters: 4.7M

# FeedForward share of total parameters: 4.7M / (2.4M + 4.7M) ≈ 66%
# improving this part has a big effect on the model as a whole!

Experimental results (the Llama paper):

At equal parameter counts, SwiGLU outperforms GELU by 5–10%
For equal performance, SwiGLU trains faster (gradients are more stable)

5. The division of labor: Attention vs FeedForward

5.1 The full comparison

| Feature | Attention | FeedForward | |------|-----------|-------------| | How it processes | tokens interact | each token independently | | Role | information exchange (a meeting) | deep thinking (digesting independently) | | Input | [seq, 768] | [seq, 768] | | Intermediate dimension | [seq, seq] (score matrix) | [seq, 2048] (expansion) | | Output | [seq, 768] | [seq, 768] | | Positional encoding | required (RoPE) | not needed | | Parameters | about 33% | about 67% | | Compute bottleneck | seq² (quadratic in sequence length) | batch×seq (linear) | | Analogy | looking up a dictionary, a meeting | solving a math problem, thinking |

5.2 Why you can't do without either one

Attention only:

✅ Tokens can interact
❌ Lacks "deep understanding"
It's like having meetings to discuss but never thinking on your own
The model can't learn complex patterns

FeedForward only:

✅ Each token can be transformed in complex ways
❌ Has no sense of context
It's like working in isolation, never listening to others' input
The model has no idea how tokens relate to one another

The two combined:

Step 1: Attention
  → lets the model know "which tokens are relevant"
  → fuses contextual information

Step 2: FeedForward
  → lets the model know "how to process that information"
  → a deep nonlinear transformation

Step 3: repeat N times
  → refine the understanding layer by layer

5.3 A full walkthrough

sentence: "I love coding"

# ========== Attention stage ==========
# "love" gathers information from "I" and "coding"
"love" ← "I" (29%) + "love" (36%) + "coding" (25%)
# "love" now knows: it connects "I" and "coding"

# ========== FeedForward stage ==========
# "love" thinks deeply based on the information it gathered
representation of "love" [768-dim]
  ↓ expand into a high-dimensional space
[2048-dim]
  ↓ gating mechanism + nonlinear transformation
[2048-dim]  # complex reasoning in the high-dimensional space
  ↓ compress back to the original dimension
[768-dim]  # the refined understanding

# in the end
# "love" has both fused context (Attention)
# and completed a deep understanding (FeedForward)

6. Assembling the Transformer Block

6.1 The four core components

A recap of the four components we've studied:

RMSNorm: stabilizes the numbers (normalization)
Attention: tokens interact (information exchange)
FeedForward: independent deepening (deep thinking)
Residual Connection: a safety net (the residual connection)

6.2 The complete Transformer Block structure

import torch
import torch.nn as nn

class TransformerBlock(nn.Module):
    def __init__(self, config):
        super().__init__()
        # RMSNorm #1: before Attention
        self.input_layernorm = RMSNorm(config.hidden_size)

        # Multi-Head Attention
        self.self_attn = Attention(config)

        # RMSNorm #2: before FeedForward
        self.post_attention_layernorm = RMSNorm(config.hidden_size)

        # FeedForward (SwiGLU)
        self.mlp = FeedForward(config)

    def forward(self, x, position_embeddings):
        # ========== Part 1: Attention ==========
        # 1. save the input (for the residual connection)
        residual = x

        # 2. RMSNorm #1 (normalization)
        x = self.input_layernorm(x)

        # 3. Multi-Head Attention
        x = self.self_attn(x, position_embeddings)

        # 4. residual connection
        x = residual + x

        # ========== Part 2: FeedForward ==========
        # 5. save the current state (for the residual connection)
        residual = x

        # 6. RMSNorm #2 (normalization)
        x = self.post_attention_layernorm(x)

        # 7. FeedForward (SwiGLU)
        x = self.mlp(x)

        # 8. residual connection
        x = residual + x

        return x

6.3 The data flow diagram

input x: [batch, seq_len, 768]
  ↓
  ├──────┐ (save residual)
  ↓      │
RMSNorm #1  ← normalization
  ↓
Multi-Head Attention (+ RoPE)  ← tokens interact
  ↓
  └──────┘ (add residual) ← residual connection
  ↓
  ├──────┐ (save residual)
  ↓      │
RMSNorm #2  ← normalization
  ↓
FeedForward (SwiGLU)  ← independent deepening
  ↓
  └──────┘ (add residual) ← residual connection
  ↓
output x: [batch, seq_len, 768]

6.4 The residual connection

The formula:

y = x + F(x)

# rather than
y = F(x)  # no residual

Three big benefits:

Benefit 1: a safety net

# worst case: F learns nothing
y = x + 0 = x  # at least you still have the input!

# without the residual
y = F(x) = noise  # completely broken ❌

Benefit 2: incremental learning

# with a residual: only need to learn the "adjustment"
y = x + Δx  # Δx is a small adjustment

# without a residual: need to learn the "full output"
y = F(x)  # F has to learn to build y from scratch

An analogy:

Without a residual: each edit fully overwrites the original
  original → filter → new image (the original is lost)

With a residual: original + each adjustment
  original → original + adjustment 1 → original + adjustment 1 + adjustment 2 ...
  all the information is preserved!

Benefit 3: a gradient highway

# backpropagation
dy/dx = 1 + dF/dx

# even if F's gradient vanishes (dF/dx → 0)
dy/dx = 1  # the gradient can still flow back! ✅

# without a residual
dy/dx = dF/dx  # once it vanishes, the path is cut entirely ❌

6.5 Pre-Norm vs Post-Norm

Post-Norm (the original Transformer, 2017):

# normalization comes after the sublayer
x = x + Attention(x)
x = Norm(x)
x = x + FeedForward(x)
x = Norm(x)

Pre-Norm (modern Transformers, Llama / MiniMind):

# normalization comes before the sublayer
x = x + Attention(Norm(x))
x = x + FeedForward(Norm(x))

Pre-Norm's advantages:

| Feature | Post-Norm | Pre-Norm | |------|-----------|----------| | Training stability | difficult for deep networks | more stable ✅ | | Gradient flow | can be interrupted by Norm | a cleaner residual path ✅ | | Learning rate | needs warmup | can use a larger learning rate ✅ |

/* | **Suitable for** | shallow networks (< 12 layers) | deep networks (> 12 layers) ✅ | */

Every modern LLM uses Pre-Norm (GPT-3, Llama, MiniMind, Mistral, …).

7. The complete MiniMind architecture

7.1 The overall structure

MiniMindForCausalLM
├─ lm_head: output layer (hidden_size → vocab_size)
│   maps a 768-dim vector to a probability distribution over 6400 tokens
│
└─ MiniMindModel
    ├─ embed_tokens: token embedding layer (vocab_size → hidden_size)
    │   converts a token ID into a 768-dim vector
    │
    ├─ layers: N TransformerBlocks (8 by default)
    │   └─ TransformerBlock × 8
    │       ├─ input_layernorm: RMSNorm
    │       ├─ self_attn: Multi-Head Attention
    │       ├─ post_attention_layernorm: RMSNorm
    │       └─ mlp: FeedForward (SwiGLU)
    │
    └─ norm: the final RMSNorm
        normalizes the last layer's output once more

7.2 The forward pass

# input
token_ids = [34, 128, 556, 89, ...]  # the IDs for "I love coding"

# ========== token embedding ==========
x = embed_tokens(token_ids)
# [batch, seq_len] → [batch, seq_len, 768]

# ========== precompute RoPE ==========
cos, sin = precompute_freqs_cis(...)  # positional encoding

# ========== TransformerBlock #1 ==========
x = block_1(x, position_embeddings=(cos, sin))
# [batch, seq_len, 768] → [batch, seq_len, 768]

# ========== TransformerBlock #2 ==========
x = block_2(x, position_embeddings=(cos, sin))

# ...

# ========== TransformerBlock #8 ==========
x = block_8(x, position_embeddings=(cos, sin))

# ========== final normalization ==========
x = self.norm(x)
# [batch, seq_len, 768]

# ========== output layer ==========
logits = lm_head(x)
# [batch, seq_len, 768] → [batch, seq_len, 6400]
# each position predicts the probability distribution of the next token

# ========== generation ==========
next_token_id = torch.argmax(logits[:, -1, :], dim=-1)
# pick the highest-probability token

7.3 Parameter breakdown

# MiniMind2 (104M parameters)

# token embedding
embed_tokens: 6400 × 768 = 4,915,200

# 8 TransformerBlocks
each Block:
  Attention:
    q_proj: 768 × 768 = 589,824
    k_proj: 768 × 768 = 589,824
    v_proj: 768 × 768 = 589,824
    o_proj: 768 × 768 = 589,824
    subtotal: 2,359,296

  FeedForward (SwiGLU):
    gate_proj: 768 × 2048 = 1,572,864
    up_proj: 768 × 2048 = 1,572,864
    down_proj: 2048 × 768 = 1,572,864
    subtotal: 4,718,592

  per-Block total: 7,077,888

8 Blocks: 8 × 7,077,888 = 56,623,104

# output layer
lm_head: 768 × 6400 = 4,915,200

# grand total
4.9M + 56.6M + 4.9M ≈ 104M ✅

Observations:

FeedForward parameters (4.7M) are 2× the Attention parameters (2.4M)!
FeedForward accounts for 67% of each Block's parameters

7.4 Configuration parameters

# MiniMind config (model/model_minimind.py)
class MiniMindConfig:
    hidden_size = 768           # hidden dimension
    num_hidden_layers = 8       # number of Transformer Block layers
    num_attention_heads = 8     # number of attention heads
    num_key_value_heads = 2     # GQA: number of KV heads
    intermediate_size = 2048    # FFN intermediate dimension
    vocab_size = 6400           # vocabulary size
    max_position_embeddings = 32768  # maximum sequence length
    rope_theta = 1000000.0      # RoPE base frequency
    rms_norm_eps = 1e-5         # RMSNorm epsilon
    use_moe = False             # whether to use MoE

8. Hands-on experiments

To really understand FeedForward, try the following experiments:

Compare a plain FFN with SwiGLU: implement both architectures and compare parameter counts (SwiGLU has 50% more) and training performance.
Verify the necessity of expand-compress: try a direct 768→768 transformation vs 768→2048→768, and observe the difference in fitting ability.
Test the residual connection: compare the training stability and convergence speed of networks with and without a residual connection.

See the MiniMind project's learning_materials/feedforward_explained.py for the complete experiment code.

9. Summary

9.1 Key takeaways

✅ What FeedForward does: independent deepening — a complex nonlinear transformation applied to each token
✅ Why expand-compress is necessary: a high-dimensional space has greater expressive power and can fit complex functions
✅ SwiGLU's advantage: a gating mechanism with two branches, 5–10% better than a plain FFN
✅ Attention vs FFN: interaction vs independence, a meeting vs thinking — you can't do without either
✅ The Transformer Block: four components combined perfectly (Norm + Attn + Norm + FFN + Residual)
✅ The residual connection: a safety net + incremental learning + a gradient highway
✅ Pre-Norm: the standard choice for modern deep Transformers

9.2 The Transformer Block mantra

Norm → Attention → residual
Norm → FeedForward → residual
repeat N times → a complete model!

9.3 A look back at the series

Congratulations on completing the study of MiniMind's core architecture!

A recap of the four posts:

✅ RMSNorm: the principles of normalization, and why it's 7.7× faster than LayerNorm
✅ RoPE: positional encoding, with an in-depth analysis of the multi-frequency mechanism
✅ Attention: Q, K, V, and a complete understanding of Multi-Head
✅ FeedForward + architecture: expand-compress, and the full assembly

What you now have:

✅ All the core components of the Transformer
✅ The mathematical principles and code implementation of each component
✅ How the components work together
✅ Why the Transformer "works"
✅ The ability to implement a small Transformer from scratch!

9.4 Suggested next steps

1. Get hands-on

# clone MiniMind
git clone https://github.com/jingyaogong/minimind
cd minimind

# train a small model
cd trainer
python train_pretrain.py

2. Go deeper

GQA (Grouped Query Attention): saves memory
Flash Attention: optimizes compute efficiency
MoE (Mixture of Experts): increases capacity
KV Cache: speeds up inference

3. The implementation challenge

# challenge: implement MiniMind from scratch
class MyMiniMind(nn.Module):
    def __init__(self):
        # over to you!
        pass

10. References

Papers

Attention Is All You Need - the original Transformer paper
GLU Variants Improve Transformer - the SwiGLU paper
Deep Residual Learning for Image Recognition - ResNet / residual connections

Code

MiniMind source: github.com/jingyaogong/minimind
This post's learning materials: learning_materials/feedforward_explained.py
Transformer Block: model/model_minimind.py:359-380

Understanding Attention: From Q, K, V to Multi-Head

Thu, 18 Dec 2025 00:00:00 GMT

This is the third post in my MiniMind learning series, a deep dive into Attention — the core engine of the Transformer. I'll use a database-query analogy to give you a thorough understanding of what Q, K, V actually mean, walk you through implementing Multi-Head Attention, and clear up the common confusion between Softmax and RMSNorm.

About this series

MiniMind is a concise but complete large-language-model training project, covering the full pipeline from data processing to model training to inference deployment. While working through it, I distilled the key technical points into my minimind-notes repo and produced this four-part series of blog posts that systematically explain the core components of the Transformer.

This series covers:

Normalization — why we need RMSNorm
RoPE positional encoding — how to make the model understand word order
Attention (this post) — the core engine of the Transformer
FeedForward and the full architecture — how the components work together

1. Introduction

1.1 The soul of the Transformer

If the Transformer is a building:

Normalization (RMSNorm) is the foundation — it stabilizes training
Positional encoding (RoPE) is the coordinate system — it distinguishes positions
Attention is the core engine — it understands meaning ⭐

Without Attention, there is no Transformer.

1.2 Questions this post answers

What exactly are Q, K, and V? (It's not magic!)
Why split into 8 heads?
What's the difference between Softmax and RMSNorm? (a common point of confusion)
How does Attention work together with RoPE?
How do the dimensions change in Multi-Head Attention?

1.3 Who this is for

You've heard of Attention but don't understand the computational details
You want to grasp the Multi-Head mechanism at the code level
You're getting ready to implement your own Transformer
You're not afraid of the math (this post explains it in detail)

2. The essence of Attention: relevance between words

2.1 The core question

"When understanding a word, which other words in the sentence should we pay attention to?"

Example:

Sentence: "Xiaoming loves his cat; it always sleeps by the window"

When the model interprets the word "it":
  "it" ← "Xiaoming"  relevance: 0.1   (unlikely — a pronoun rarely refers to a name)
  "it" ← "loves"     relevance: 0.05  (almost unrelated)
  "it" ← "cat"       relevance: 0.8   (highly relevant!) ✅
  "it" ← "window"    relevance: 0.05  (almost unrelated)

Final representation of "it" = 0.1×[Xiaoming] + 0.05×[loves] + 0.8×[cat] + 0.05×[window]
                             ≈ mostly information from "cat"

What Attention does:

Compute relevance scores (between every pair of words)
Normalize them into a probability distribution (Softmax — they sum to 1)
Take a weighted sum (fuse in the context)

2.2 Input vs output

# Input: isolated word vectors (each word knows nothing about its context)
input = [
    [768-dim vector for "I"],         # doesn't know whether "love" or "hate" comes next
    [768-dim vector for "love"],      # doesn't know who the subject or object is
    [768-dim vector for "programming"] # doesn't know whether it's loved or hated
]

# Attention processing

# Output: word vectors that have absorbed the context
output = [
    [new vector for "I"],          # now knows: "I" is the subject of the action "love"
    [new vector for "love"],       # now knows: it connects "I" and "programming"
    [new vector for "programming"] # now knows: it's the object of the action "love"
]

2.3 Self-Attention vs Cross-Attention

Self-Attention (used by MiniMind):

# The sentence attends to words "within itself"
sentence = "I love programming"
# Compute the relevance among: I ← → love ← → programming

Cross-Attention (used by translation models):

# Sentence A attends to sentence B
chinese = "我爱编程"
english = "I love programming"
# Compute: "我" ← "I", "爱" ← "love", "编程" ← "programming"

Why is it called "Self"?

Because it computes relationships within the same sentence
Not "a token with itself" (even though q_i · k_i is also computed)

3. Q, K, V in detail: the database-query analogy

3.1 The classic analogy: a database query

The best way to understand Q, K, V is to compare them to a SQL query:

SELECT value          ← return the Value
FROM memory_bank      ← the memory bank (all the words)
WHERE key MATCHES query  ← the Key matches the Query

The correspondence:

| SQL concept | Attention concept | Role | Analogy | |---------|---------------|------|------| | Query | Query (Q) | "What information am I looking for?" | search condition | | Key | Key (K) | "What information do I have here?" | index label | | Value | Value (V) | "My actual content" | data value |

3.2 A concrete example: understanding "love"

Sentence: "I love programming"

When interpreting the word "love":

Query (what "love" wants to know): Who are the subject and object? What action am I expressing?
Keys (what information the other words offer):
- Key("I") = "I'm the subject, a first-person pronoun"
- Key("programming") = "I'm the object, denoting an activity"
Compute similarity:
- Q of "love" · K of "I" = 0.6 (moderately relevant)
- Q of "love" · K of "programming" = 0.8 (highly relevant!)
Softmax normalization: [0.25, 0.15, 0.60] (60% attention on "programming")
Weighted sum of Values:
- New representation of "love" = 0.25×Value("I") + 0.15×Value("love") + 0.60×Value("programming")
- It has absorbed the context and knows it connects "I" and "programming"

3.3 Where do Q, K, V come from?

The key insight: Q, K, and V all come from the same input X, transformed by different weight matrices!

# Input X: [3, 768] (3 words, each 768-dimensional)
# Weight matrices W_Q, W_K, W_V: [768, 768]

Q = X @ W_Q  # Query: "What do I want to know?"
K = X @ W_K  # Key:   "What information do I have?"
V = X @ W_V  # Value: "My actual content"

Same dimensions, different meanings. The three matrices transform the input into three different "perspectives."

3.4 What the weight matrices really are

A common question: "Where do W_Q, W_K, W_V come from?"

The answer:

What they are: learnable parameters of the neural network
Where they come from: learned from training data via backpropagation
Where they're stored: saved in the model file (.pth, .safetensors)
What they do: transform the input into three different "perspectives"

In MiniMind they are three nn.Linear layers (q_proj, k_proj, v_proj). After training, W_Q learns to extract "query features," W_K learns to extract "index features," and W_V learns to extract "content features."

4. The Attention computation pipeline

4.1 The full formula

Attention(Q, K, V) = softmax(Q @ K^T / √d_k) @ V

This single formula captures the entire Attention mechanism!

4.2 Step by step

Step 1: Compute similarity (dot product)

scores = Q @ K.T  # [seq_len, seq_len]
# scores[i, j] = Q[i] · K[j] (the more similar two vectors are, the larger the dot product)

Step 2: Scale (divide by √d_k)

scaled_scores = scores / math.sqrt(head_dim)

Why scale? The larger the dimension, the larger the dot products. Without scaling, Softmax becomes too "peaked" and the gradients vanish. After scaling, the distribution is smoother and the gradients are more stable.

Step 3: Softmax normalization

attn_weights = softmax(scaled_scores, dim=-1)

This turns the scores into a probability distribution: every weight is ≥ 0, each row sums to 1, and the result can be read as "how much attention" to pay.

Step 4: Weighted sum of Values

output = attn_weights @ V

For example: new representation of "love" = 0.29×Value("I") + 0.36×Value("love") + 0.25×Value("programming")

4.3 Full code implementation

def attention(Q, K, V, mask=None):
    head_dim = Q.shape[-1]

    # 1-2. Compute similarity and scale
    scores = (Q @ K.transpose(-2, -1)) / math.sqrt(head_dim)

    # 3. Apply the mask (optional, for causal attention)
    if mask is not None:
        scores = scores.masked_fill(mask == 0, -1e9)

    # 4-5. Softmax + weighted sum
    attn_weights = F.softmax(scores, dim=-1)
    output = attn_weights @ V

    return output, attn_weights

5. Multi-Head Attention

5.1 Why do we need multiple heads?

The limitation of a single head: it can only attend to one aspect.

Sentence: "Xiaoming studies artificial intelligence at Tsinghua University in Beijing"

A single-head Attention might only attend to:

Subject-verb-object relations (grammar)

But we want to attend to all of these at once:

Grammatical structure (subject-verb-object)
Entity relations (Xiaoming–Tsinghua)
Geographic location (Tsinghua–Beijing)
Topic domain (artificial intelligence)
Semantic relevance (studies–artificial intelligence)
...

The solution: Multi-Head Attention!

5.2 The "multiple pairs of glasses" analogy

Head 1: grammar glasses 👓
  → attends to subject-verb-object relations and syntactic structure

Head 2: entity glasses 🕶️
  → attends to names of people, places, and organizations

Head 3: semantic glasses 👓
  → attends to synonyms and related concepts

Head 4: long-range-dependency glasses 🕶️
  → attends to words that are far apart but related

Head 5: sentiment glasses 👓
  → attends to emotional and attitudinal words

...

Head 8: topic glasses 🕶️
  → attends to topics and domain vocabulary

Finally: take off all the glasses and fuse the 8 perspectives!

5.3 The Multi-Head implementation pipeline

# MiniMind configuration
hidden_size = 768
num_heads = 8
head_dim = hidden_size // num_heads = 96

# Full pipeline
Input X: [batch, seq_len, 768]
  ↓
Generate Q, K, V: [batch, seq_len, 768]
  ↓
Split into 8 heads: [batch, seq_len, 8, 96]
  ↓
Transpose: [batch, 8, seq_len, 96]  # makes parallel computation convenient
  ↓
Each head computes Attention independently (in parallel)
  ↓
Output: [batch, 8, seq_len, 96]
  ↓
Transpose back: [batch, seq_len, 8, 96]
  ↓
Merge (reshape): [batch, seq_len, 768]
  ↓
Output projection: [batch, seq_len, 768]

5.4 Code implementation

class MultiHeadAttention(nn.Module):
    def __init__(self, hidden_size=768, num_heads=8):
        super().__init__()
        self.num_heads = num_heads
        self.head_dim = hidden_size // num_heads  # 96

        self.q_proj = nn.Linear(hidden_size, hidden_size, bias=False)
        self.k_proj = nn.Linear(hidden_size, hidden_size, bias=False)
        self.v_proj = nn.Linear(hidden_size, hidden_size, bias=False)
        self.o_proj = nn.Linear(hidden_size, hidden_size, bias=False)

    def forward(self, x, mask=None):
        batch, seq_len, _ = x.shape

        # 1. Generate Q, K, V and split into multiple heads
        Q = self.q_proj(x).view(batch, seq_len, self.num_heads, self.head_dim).transpose(1, 2)
        K = self.k_proj(x).view(batch, seq_len, self.num_heads, self.head_dim).transpose(1, 2)
        V = self.v_proj(x).view(batch, seq_len, self.num_heads, self.head_dim).transpose(1, 2)
        # [batch, num_heads, seq_len, head_dim]

        # 2. Compute Attention (8 heads in parallel)
        scores = (Q @ K.transpose(-2, -1)) / math.sqrt(self.head_dim)
        attn_weights = F.softmax(scores, dim=-1)
        output = attn_weights @ V

        # 3. Merge the heads and apply the output projection
        output = output.transpose(1, 2).contiguous().view(batch, seq_len, -1)
        return self.o_proj(output)

5.5 Tracking the dimensions

Input: [batch, seq_len, 768]
  → Q, K, V: [batch, seq_len, 768]
  → Split + transpose: [batch, 8, seq_len, 96]
  → Attention: [batch, 8, seq_len, 96]
  → Merge: [batch, seq_len, 768]
  → Output projection: [batch, seq_len, 768]

Key invariant: num_heads × head_dim = 768

5.6 Why concatenate after splitting?

Splitting: lets each head focus on a different aspect

# Head 1 learns to attend to grammar
# Head 2 learns to attend to entities
# ...

Concatenating: fuses the information from all perspectives

# Analogy: 8 experts each analyze the same case
# Each expert writes a 96-word report
# In the end they're stitched into one 768-word combined report

Why not just average?

Concatenating preserves all the information (768 dimensions)
Averaging would lose information (still only 96 dimensions)
The downstream FFN can learn how to fuse this information

6. A common point of confusion: Softmax vs RMSNorm

6.1 A question many people have

"The Softmax inside Attention and the RMSNorm in the Transformer block are both normalization. What's the difference?"

This is a common point of confusion!

6.2 The key differences

| Property | Softmax (inside Attention) | RMSNorm (between blocks) | |------|------------------------|---------------------| | Location | inside the Attention computation | before Attention/FFN | | What it normalizes | similarity scores (each row of the score matrix) | word vectors (the magnitude of each vector) | | Purpose | turn them into a probability distribution | stabilize the values, prevent exploding gradients | | Input | arbitrary scores (-∞ to +∞) | a 768-dim vector | | Output | values in [0, 1] that sum to 1 | a normalized vector (direction unchanged) | | Formula | exp(x_i) / Σexp(x_j) | x / sqrt(mean(x²)) | | Scope | each row is normalized independently | each vector is normalized independently |

6.3 Where they sit in the code

# Transformer Block
def forward(self, x):
    # ========== RMSNorm ==========
    residual = x
    x = self.input_norm(x)  # ← RMSNorm: normalizes the word vectors

    # ========== Inside Attention ==========
    Q, K, V = self.q_proj(x), self.k_proj(x), self.v_proj(x)

    # Split into heads...

    scores = Q @ K.T
    weights = F.softmax(scores, dim=-1)  # ← Softmax: normalizes the scores
    output = weights @ V

    # ==========  Residual connection ==========
    x = residual + output

    return x

6.4 A detailed side-by-side example

Softmax example:

# One row of the Attention score matrix
scores = torch.tensor([2.5, 1.3, 3.7, 0.8])

# Softmax normalization
weights = F.softmax(scores, dim=-1)
print(weights)
# Output: tensor([0.1722, 0.0518, 0.5678, 0.0082])
# Characteristics:
# - all values are in [0, 1]
# - they sum to 1
# - the large ones grow larger (3.7 → 0.5678, accounting for 56.78%)

RMSNorm example:

# One word vector
x = torch.tensor([2.5, 1.3, 3.7, 0.8])

# RMSNorm normalization
rms = torch.sqrt((x ** 2).mean())
x_norm = x / rms
print(x_norm)
# Output: tensor([1.0698, 0.5563, 1.5833, 0.3424])
# Characteristics:
# - values can be any positive or negative number
# - RMS ≈ 1
# - direction unchanged (only the magnitude is scaled)

6.5 A mnemonic

Softmax: normalizes a "score distribution" → turns it into probability weights
RMSNorm: normalizes a "vector's magnitude" → stabilizes training

Completely different kinds of normalization!
Different location, different purpose, different formula!

7. How RoPE is applied within Attention

7.1 Where it's applied

RoPE is applied after Q and K are generated but before Attention is computed:

def forward(self, x, position_embeddings):
    # 1. Generate Q, K, V
    Q = self.q_proj(x)
    K = self.k_proj(x)
    V = self.v_proj(x)

    # 2. Split into heads
    Q = Q.view(batch, seq_len, num_heads, head_dim)
    K = K.view(batch, seq_len, num_heads, head_dim)
    V = V.view(batch, seq_len, num_heads, head_dim)

    # 3. Transpose
    Q = Q.transpose(1, 2)  # [batch, num_heads, seq_len, head_dim]
    K = K.transpose(1, 2)

    # 4. ⭐ Apply RoPE (only to Q and K)
    cos, sin = position_embeddings
    Q, K = apply_rotary_pos_emb(Q, K, cos, sin)

    # 5. Compute Attention
    scores = Q @ K.transpose(-2, -1) / sqrt(head_dim)
    attn = softmax(scores, dim=-1)
    output = attn @ V

    return output

7.2 Why rotate only Q and K?

Recall what I covered earlier:

The reason:

Q and K compute similarity → they need positional information
V represents content → it doesn't need positional information

The flow:

1. scores = Q @ K.T  ← compute similarity (needs position)
2. weights = softmax(scores)
3. output = weights @ V  ← weighted sum of content (doesn't need position)

Analogy:

Q and K are "map coordinates" → they need RoPE
V is the "treasure content" → it doesn't need RoPE

8. Hands-on experiments

The full learning materials are open source, so you can run them and verify everything yourself:

# Clone the code
git clone https://github.com/joyehuang/minimind-notes
cd minimind-notes/learning_materials

# Experiment 1: the basics of Q, K, V
python attention_qkv_explained.py

# Experiment 2: implementing Multi-Head Attention
python multihead_attention.py

# Experiment 3: Softmax vs RMSNorm
python softmax_vs_rmsnorm.py

9. Summary

9.1 Key takeaways

✅ The essence of Attention: compute relevance between words and fuse in the context
✅ Q, K, V: a database-query analogy, not magic
✅ Weight matrices: parameters learned through training, stored in the model file
✅ The 4-step pipeline: similarity → scaling → Softmax → weighted sum
✅ Multi-Head: 8 pairs of glasses looking at the same sentence, fusing multiple perspectives
✅ Softmax ≠ RMSNorm: completely different kinds of normalization, different location and purpose
✅ RoPE is only for Q and K: similarity needs position, content doesn't

9.2 The 4-step Attention pipeline (to memorize)

1. Q @ K.T          → compute similarity
2. / √d             → scale
3. softmax(...)     → normalize into probabilities
4. @ V              → weighted sum

9.3 The Multi-Head dimension changes (to memorize)

[batch, seq, 768]
  → generate Q, K, V
  → split into 8 heads: [batch, seq, 8, 96]
  → transpose: [batch, 8, seq, 96]
  → Attention (in parallel)
  → transpose back: [batch, seq, 8, 96]
  → merge: [batch, seq, 768]

9.4 Key code locations (MiniMind)

Attention implementation: model/model_minimind.py:140-220
Q, K, V projections: model/model_minimind.py:159-161
RoPE application: model/model_minimind.py:182
Learning example: learning_materials/attention_qkv_explained.py

9.5 Going further

GQA (Grouped Query Attention):
- MiniMind uses GQA (num_key_value_heads=2)
- Saves memory and speeds up inference
Flash Attention:
- Optimizes Attention's computation and memory access
- 2-3× faster training
Sparse Attention:
- Not every word needs to attend to every other word
- An optimization for long-text scenarios

10. References

Papers:

Attention Is All You Need — the original Transformer paper
GQA: Training Generalized Multi-Query Transformer — the GQA paper
FlashAttention: Fast and Memory-Efficient Exact Attention

Code:

MiniMind source: github.com/jingyaogong/minimind
Attention implementation: model/model_minimind.py:140-220

Other posts in this series:

Author: joye Published: 2025-12-29 Last updated: 2025-12-29 Series: MiniMind learning notes (3/4)

If you found this helpful, feel free to:

⭐ Star the original project MiniMind
⭐ Star my learning notes minimind-notes
💬 Leave a comment with what you've learned
🔗 Share it with other friends learning about LLMs

RoPE: From Permutation Invariance to Multi-Frequency

Wed, 17 Dec 2025 00:00:00 GMT

This is the second post in my MiniMind learning series, a deep dive into RoPE (Rotary Position Embedding) — the standard position encoding for modern large language models. We'll go from the math to the engineering, including the floating-point precision issue that rarely gets discussed, so you can fully understand this elegant design.

About this series

MiniMind is a concise but complete LLM training project, covering the full pipeline from data processing and model training to inference and deployment. As I worked through it, I distilled the core technical points into my minimind-notes repo and produced this four-part blog series, walking through the core components of the Transformer in a systematic way.

The series includes:

Normalization - why we need RMSNorm
RoPE position encoding (this post) - how to make a model understand word order
Attention - the core engine of the Transformer
FeedForward and the full architecture - how the components work together

1. Introduction

1.1 Starting with a bug

Suppose you've implemented a simple Attention mechanism:

def simple_attention(query, key, value):
    scores = query @ key.T  # compute similarity
    weights = softmax(scores)
    output = weights @ value
    return output

# Test
sentence1 = tokenize("我喜欢你")
sentence2 = tokenize("你喜欢我")

# Compute Attention
output1 = simple_attention(Q1, K1, V1)
output2 = simple_attention(Q2, K2, V2)

# Surprisingly:
assert torch.allclose(output1, output2)  # True!?

The problem: two sentences with completely opposite meanings produce the exact same Attention output?

This is the permutation invariance problem of Attention.

1.2 What this post will answer

What is Attention's "permutation invariance," and why is it a problem?
Why do we need position encoding?
How does RoPE encode position using rotation?
Why do we need 32 frequencies? (the core difficulty, involving floating-point precision)
How does RoPE encode both absolute and relative position information at the same time?

1.3 Who this is for

People with a basic understanding of the Transformer
Anyone who wants to deeply understand position encoding
Researchers curious about the "engineering details"
Anyone about to implement their own Transformer

2. The problem: Attention's permutation invariance

2.1 What is permutation invariance?

Definition: for a set operation, the order of elements doesn't affect the result.

Mathematical statement:

f({a, b, c}) = f({c, a, b}) = f({b, c, a})

Classic examples:

Sum: sum([1, 2, 3]) = sum([3, 1, 2]) = 6
Mean: mean([1, 2, 3]) = mean([2, 3, 1]) = 2

2.2 Why is Attention permutation invariant?

Let's look at the core computation in Attention:

scores = Q @ K.T  # [seq_len, seq_len]
weights = softmax(scores, dim=-1)
output = weights @ V

Key observation: the result of the matrix product Q @ K.T depends only on the row vectors of Q and K, not on the order of the rows.

A simplified example:

Suppose we have two sentences:

Sentence 1: "我喜欢你" → Q1, K1
Sentence 2: "你喜欢我" → Q2, K2 (just a reordering)

Their Attention score matrices:

Sentence 1: [[1.25, 1.00, 0.95],
             [1.00, 1.25, 0.70],
             [0.95, 0.70, 0.73]]

Sentence 2: [[0.73, 0.70, 0.95],
             [0.70, 1.25, 1.00],
             [0.95, 1.00, 1.25]]

Observation: the two matrices contain exactly the same values, just in different positions (the rows and columns are reordered). After softmax, the weight distribution in each row is also just a reordering. The model has no way to tell which word is in which position!

/* ![Figure 1: Permutation invariance — comparing the Attention matrices of two sentences](placeholder_permutation_invariance.png) */

2.3 Why is this a problem?

In natural language, position information is crucial:

"猫追老鼠" vs "老鼠追猫"  ← completely opposite meanings
"我没说她偷了钱" vs "我说她没偷钱"  ← completely different semantics
"吃饭了吗" vs "饭吃了吗"  ← different tone

Conclusion: Attention needs some mechanism to perceive position information!

3. Three generations of position encoding

3.1 First generation: absolute position encoding (BERT, 2018)

Core idea: assign a fixed vector to each position.

class AbsolutePositionEmbedding(nn.Module):
    def __init__(self, max_len, hidden_size):
        super().__init__()
        # learnable position embedding
        self.position_embedding = nn.Embedding(max_len, hidden_size)

    def forward(self, x):
        batch_size, seq_len, hidden_size = x.shape

        # position IDs: [0, 1, 2, ..., seq_len-1]
        position_ids = torch.arange(seq_len, device=x.device)
        position_ids = position_ids.unsqueeze(0).expand(batch_size, -1)

        # look up the position vectors
        pos_embed = self.position_embedding(position_ids)

        # add directly
        return x + pos_embed

Pros:

✅ Simple and direct
✅ Learnable (adjusts to the data)

Cons:

❌ Can't extrapolate to unseen lengths (train on 512, test on 1024 and it falls apart)
❌ No explicit relative position information
❌ Requires storing a lot of parameters (max_len × hidden_size)

3.2 Second generation: relative position encoding (T5, 2019)

Core idea: encode the relative distance between two words.

# compute relative position
relative_distance = pos_j - pos_i  # -seq_len to +seq_len

# look up the bias for the relative position
bias = relative_position_bias[relative_distance]

# add to the Attention scores
scores = (Q @ K.T) + bias

Pros:

✅ Has relative position information
✅ Can extrapolate to some degree

Cons:

❌ Requires an extra bias matrix (O(seq_len²) space)
❌ Computationally complex
❌ Tedious to implement

3.3 Third generation: RoPE (Llama/MiniMind, 2021) ⭐️

Core idea: encode position by rotating vectors.

# apply rotation to Query and Key
Q_rot = rotate(Q, position × θ)
K_rot = rotate(K, position × θ)

# compute Attention (relative position is included automatically!)
scores = Q_rot @ K_rot.T

Pros:

✅ Naturally includes relative position information (a mathematical property)
✅ Can extrapolate to longer sequences (with YaRN)
✅ Computationally efficient (O(1) extra space)
✅ Clean, elegant implementation
✅ The standard for modern LLMs (GPT-3, Llama, Mistral, MiniMind)

Comparison table:

| Feature | Absolute | Relative | RoPE | |------|---------|---------|------| | Relative info | ❌ | ✅ | ✅ | | Extrapolatable | ❌ | △ | ✅ | | Compute efficiency | ✅ | ❌ | ✅ | | Space complexity | O(L×D) | O(L²) | O(1) | | Implementation difficulty | Simple | Complex | Medium | | Models | BERT | T5 | GPT-3+, Llama |

4. RoPE core principle: rotary encoding

4.1 The basic idea

"Encode position with a rotation angle"

Intuition:

position 0 → rotate 0°
position 1 → rotate θ°
position 2 → rotate 2θ°
position 3 → rotate 3θ°
...
position m → rotate m×θ°

Just like the hands of a clock, different moments point at different angles!

/* ![Figure 2: RoPE rotary encoding — vectors rotated for different positions](placeholder_rope_rotation.png) */

4.2 Mathematical derivation (simplified)

Rotating a 2D vector:

rotation matrix R(θ) = [cos(θ)  -sin(θ)]
                       [sin(θ)   cos(θ)]

vector v rotated by θ degrees:
v_rot = R(θ) @ v

Rotating the word vector at position m:

q_m = R(m × θ) @ q  # rotate Query by m×θ degrees
k_n = R(n × θ) @ k  # rotate Key by n×θ degrees

Computing the Attention score:

score = q_m · k_n
      = (R(mθ) @ q) · (R(nθ) @ k)
      = q^T @ R(mθ)^T @ R(nθ) @ k   # transpose of the dot product
      = q^T @ R(-mθ) @ R(nθ) @ k     # transpose of a rotation matrix = reverse rotation
      = q^T @ R((n-m)θ) @ k          # rotation angles add up
      = q^T @ R(Δθ) @ k              # Δ = n-m (relative distance)

The magical conclusion: the Attention score depends only on the relative distance (n-m)!

4.3 RoPE's twofold advantage

Advantage 1: it has absolute position information

Every position has a unique rotation angle:

Query at position 5: rotated to 5θ
Query at position 8: rotated to 8θ
The model can know "this word is at position 5"

Advantage 2: it has relative position information

The Attention score depends only on the relative distance:

Position 5 looking at position 8 = q @ rotate(k, 3θ) (distance 3)
Position 0 looking at position 3 = q @ rotate(k, 3θ) (distance 3)
The two scores are the same, so the model knows "these two words are 3 positions apart"

Best of both worlds! It has both absolute and relative position.

/* ![Figure 3: RoPE's twofold advantage — absolute and relative position](placeholder_rope_dual_advantage.png) */

5. The core difficulty: why do we need multiple frequencies? ⭐⭐⭐

5.1 Setting up the problem

By this point, you might be wondering:

"If rotating 360 degrees brings you back to the start, then aren't position 0 and position 360 indistinguishable?"

That's an excellent question!

5.2 The intuitive fix: lower the frequency

The idea: if it only completes one full turn every million tokens, wouldn't that cover all positions?

# ultra-low frequency
θ = 2π / 1_000_000  # one full turn every million tokens

# in theory
position_0 → 0°
position_1 → 0.00000628°
position_1000000 → 360° (back to the start)

# can uniquely identify a million positions!

Here's the catch: why don't we actually do this?

5.3 The real reason: floating-point precision limits ⭐⭐⭐

The key finding: it works in theory, but not in engineering!

When using an ultra-low frequency (one full turn every million tokens):

cos value at position 0: 1.0
cos value at position 1: 0.999999999980261
Difference: about 1.97e-11

Where the problem lies:

float32's precision is about 10^-7

/* - the difference between adjacent positions $1.97 \times 10^{-11} \ll 10^{-7}$ */

The computer can't distinguish adjacent positions!

After computing in float32, the cos values for position 0 and position 1 are both 1.0 — completely indistinguishable.

/* ![Figure 4: The floating-point precision problem — single frequency vs. multiple frequencies](placeholder_float_precision.png) */

5.4 Mathematical analysis

A Taylor expansion proves it:

Angle difference: θ ≈ 6.28e-6 radians
cos difference: Δcos ≈ θ²/2 ≈ 2e-11
float32 precision: about 10^-7

Conclusion: 2e-11 << 10^-7, the computer can't distinguish adjacent positions.

It's like measuring millimeter-scale differences with a meter stick — the markings are too coarse to read them.

5.5 The multi-frequency solution

Strategy: use 32 different frequencies (MiniMind, head_dim=64), one frequency per pair of dimensions.

Frequency range:

| Frequency type | Period (tokens) | Role | |---------|-------------|------| | High (0) | 6.3 | Precisely distinguish adjacent positions (angle difference 57.3°) | | Medium (15) | 6,283 | Balance precision and range | | Low (31) | 6,283,185 | Identify distant positions |

The combined effect:

Position 0 encoding: [1.0, 1.0, 1.0, ..., 1.0] (32 values)
Position 1 encoding: [0.5403, 0.9997, 0.9999, ..., 1.0]
The high-frequency components differ noticeably (0.5403 vs. 1.0), so adjacent positions can be distinguished
The low-frequency components cover long distances, so positions in the millions can be identified

The key point: high frequencies see the detail, low frequencies see the big picture — together they're both precise and comprehensive!

5.6 An analogy: the clock system

It's just like a clock's hour, minute, and second hands:

Second hand (high frequency):

Completes a turn every minute, precise to the second
But returns to the start after an hour, so it can't distinguish on its own

Minute hand (medium frequency):

Completes a turn every hour, precise to the minute
Together with the second hand it can distinguish 3,600 seconds

Hour hand (low frequency):

Completes a turn every 12 hours, covering a wide range

Combine all three → you can uniquely identify any moment! RoPE's multi-frequency mechanism works exactly the same way.

/* ![Figure 5: The clock analogy — the multi-frequency mechanism](placeholder_clock_analogy.png) */

6. The full RoPE implementation

The RoPE implementation breaks down into three steps:

6.1 Precompute the frequencies and cos/sin values

The core idea: precompute the cos and sin values needed for rotation, for every position and every frequency.

def precompute_freqs_cis(dim, end, rope_base=1e6):
    # 1. compute frequencies: freqs[i] = 1 / (rope_base ^ (2i / dim))
    freqs = 1.0 / (rope_base ** (torch.arange(0, dim, 2).float() / dim))

    # 2. build the angle matrix: positions × freqs
    t = torch.arange(end)
    freqs = torch.outer(t, freqs)  # [end, dim/2]

    # 3. compute cos and sin
    freqs_cos = torch.cos(freqs).repeat(1, 2)  # [end, dim]
    freqs_sin = torch.sin(freqs).repeat(1, 2)

    return freqs_cos, freqs_sin

6.2 Apply the rotation

The core formula: q_rotated = q * cos + rotate_half(q) * sin

def apply_rotary_pos_emb(q, k, cos, sin):
    q_embed = (q * cos) + (rotate_half(q) * sin)
    k_embed = (k * cos) + (rotate_half(k) * sin)
    return q_embed, k_embed

def rotate_half(x):
    # split the vector in half and swap: [x1, x2] → [-x2, x1]
    x1, x2 = x.chunk(2, dim=-1)
    return torch.cat((-x2, x1), dim=-1)

This is essentially the real-valued implementation of complex rotation: (a + bi) × (cos + i·sin)

6.3 Using it inside Attention

class Attention(nn.Module):
    def forward(self, x, position_embeddings):
        # 1. produce Q, K, V and split into heads
        q, k, v = self.q_proj(x), self.k_proj(x), self.v_proj(x)

        # 2. ⭐ apply RoPE (to Q, K only)
        cos, sin = position_embeddings
        q, k = apply_rotary_pos_emb(q, k, cos, sin)

        # 3. compute Attention
        scores = q @ k.T / sqrt(head_dim)
        output = softmax(scores) @ v

        return output

Full code: see the MiniMind source model/model_minimind.py:108-182

7. YaRN: long-context extrapolation

7.1 The problem

The model was trained with a maximum length of 2048, but at inference time you want to handle 8192 tokens — what do you do?

Extrapolating directly runs into trouble:

High frequencies: short period, seen many full turns, extrapolates well ✅
Low frequencies: long period, only a small slice of angles ever seen, so "unseen angles" appear and quality drops ❌

7.2 The YaRN solution

Core idea: dynamically adjust the low frequencies so that "unseen angles" become "seen angles," while leaving the high frequencies unchanged.

Results:

Llama 2: trained on 4k → extrapolated to 32k
Code Llama: trained on 16k → extrapolated to 100k

This is an advanced topic; for the full details see the YaRN paper.

8. Summary

8.1 Recap of the key points

✅ The permutation invariance problem: Attention can't tell word order apart, so it needs position encoding
✅ RoPE's advantage: encodes position with rotation, automatically including relative position information
✅ Why multiple frequencies are necessary: floating-point precision limits mean a single frequency can't distinguish adjacent positions
✅ The clock analogy: high frequencies see the detail, low frequencies see the big picture, and together they cover everything perfectly
✅ Twofold information: both absolute and relative position
✅ Rotate only Q, K: position is used for similarity and doesn't affect the content V

8.2 One sentence to remember

"RoPE is the perfect balance of mathematical theory and engineering practice"

8.3 Self-test questions

Why is Attention permutation invariant?
How does RoPE include both absolute and relative position?
Why can't we just use a single ultra-low frequency? (the core point)
How does YaRN achieve length extrapolation?

8.4 Key code locations (MiniMind)

RoPE precompute: model/model_minimind.py:108-128
RoPE application: model/model_minimind.py:131-137
Used in Attention: model/model_minimind.py:182

9. Hands-on experiments

The full learning materials are open source, so you can run and verify everything yourself:

# clone the code
git clone https://github.com/joyehuang/minimind-notes
cd minimind-notes/learning_materials

# Experiment 1: RoPE basics
python rope_basics.py

# Experiment 2: the multi-frequency mechanism
python rope_multi_frequency.py

# Experiment 3: the floating-point precision problem (core)
python rope_why_multi_frequency.py

10. References

Papers:

RoFormer: Enhanced Transformer with Rotary Position Embedding - the original RoPE paper
Llama 2: Open Foundation and Fine-Tuned Chat Models - the Llama technical report
YaRN: Efficient Context Window Extension of Large Language Models - the YaRN paper

Code:

MiniMind source: github.com/jingyaogong/minimind
RoPE implementation: model/model_minimind.py:108-182

Other posts in this series:

Author: joye Published: 2025-12-17 Last updated: 2025-12-17 Series: MiniMind learning notes (2/4)

If you found this helpful, feel free to:

⭐ Star the original project MiniMind
⭐ Star my learning notes minimind-notes
💬 Leave a comment with your own takeaways
🔗 Share it with others learning about LLMs

Why Transformers Need Normalization: Gradients to RMSNorm

Tue, 16 Dec 2025 00:00:00 GMT

This is the first post in my MiniMind learning series, a deep dive into why deep neural networks need normalization, and how RMSNorm became standard in modern LLMs.

About This Series

MiniMind is a concise but complete large language model training project, covering the full pipeline from data processing and model training to inference and deployment. As I worked through it, I collected the core technical points into the minimind-notes repo and produced this four-part blog series, walking through the core components of the Transformer systematically.

This series includes:

Normalization (this post) — why we need RMSNorm
RoPE positional encoding — how to make the model understand word order
The Attention mechanism — the core engine of the Transformer
FeedForward and the complete architecture — how the components work together

1. Introduction

1.1 A Common Question

If you open up the code for a Transformer, you'll find Normalization layers everywhere:

class TransformerBlock(nn.Module):
    def forward(self, x):
        x = self.input_norm(x)        # ← Norm layer
        x = self.attention(x)

        x = self.post_attn_norm(x)    # ← another Norm layer
        x = self.feedforward(x)
        return x

The questions:

Why do we need so much normalization?
Can't we just drop it?
What's the difference between RMSNorm and LayerNorm?

1.2 What This Post Answers

Why do deep networks suffer from vanishing gradients? (It's not magic — there's a mathematical proof.)
What does RMSNorm actually do? (It's not throwing away information.)
Why have modern LLMs all migrated from LayerNorm to RMSNorm?
Where exactly does RMSNorm sit inside a Transformer?

2. The Truth About Vanishing Gradients

2.1 A Demonstration: The Disaster of an 8-Layer Network

Let's use code to show what happens in an 8-layer network without normalization:

import torch
import torch.nn as nn

# An 8-layer network without normalization
class DeepNetworkWithoutNorm(nn.Module):
    def __init__(self):
        super().__init__()
        self.layers = nn.ModuleList([
            nn.Linear(512, 512) for _ in range(8)
        ])

    def forward(self, x):
        for i, layer in enumerate(self.layers):
            x = layer(x)
            x = torch.relu(x)
            print(f"Layer {i+1} std: {x.std().item():.4f}")
        return x

# Test
model = DeepNetworkWithoutNorm()
x = torch.randn(32, 512)
print(f"Input std: {x.std().item():.4f}")

output = model(x)

Output:

Input std: 1.0405
Layer 1 std: 0.8932
Layer 2 std: 0.6421
Layer 3 std: 0.4156
Layer 4 std: 0.2387
Layer 5 std: 0.1024
Layer 6 std: 0.0432
Layer 7 std: 0.0198
Layer 8 std: 0.0163  ← nearly zero!

2.2 Why Does It Keep Shrinking?

The mathematical explanation:

The matrix multiplication in each layer: y = Wx
- If the weights W are initialized as a normal distribution with mean 0 and standard deviation 1
- The standard deviation of the output is approximately: std(y) ≈ std(x) × sqrt(input_dim) / sqrt(output_dim)
The effect of the ReLU activation:
- ReLU(x) = max(0, x)
- All negatives become 0
- This shrinks the standard deviation further (roughly halving it)
The cumulative effect across layers:
- Each layer's standard deviation × k, where k < 1
- After 8 layers: std_8 = std_0 × k^8
- Exponential decay!

An analogy:

It's like photocopying a photocopy:

1st copy: slightly blurry
2nd copy: blurrier
8th copy: you can barely read the text anymore

2.3 The Consequences of Vanishing Gradients

What's worse is the gradient during backpropagation:

# Compute the loss and backpropagate
loss = output.sum()
loss.backward()

# Inspect the gradient magnitude of each layer
for i, layer in enumerate(model.layers):
    grad_norm = layer.weight.grad.norm().item()
    print(f"Layer {i+1} gradient norm: {grad_norm:.6f}")

Output:

Layer 1 gradient norm: 0.000012  ← nearly 0!
Layer 2 gradient norm: 0.000045
Layer 3 gradient norm: 0.000231
...
Layer 7 gradient norm: 0.123456
Layer 8 gradient norm: 0.432156  ← normal

Conclusion:

The gradients in the earlier layers are close to 0, so their weights barely update
Only the later layers are learning
A deep network degenerates into a shallow one!

2.4 What Happens with Even Deeper Networks?

If a network has 100 layers, or 1,000 layers (Transformers sometimes have 96):

100 layers → std ≈ 10^-10 (completely vanished)
1,000 layers → simply impossible to train

Without normalization, deep Transformers cannot be trained at all!

3. The Salvation of RMSNorm

3.1 The Core Idea

The design philosophy of RMSNorm:

"Don't change the direction, just control the magnitude."

The math:

x_norm = x / sqrt(mean(x²) + eps) × weight

Step by step:

Compute the "magnitude" of the vector (Root Mean Square)
Divide by that magnitude (normalizing it to roughly unit length)
Multiply by the learnable scaling parameter weight

3.2 The Implementation

import torch
import torch.nn as nn

class RMSNorm(nn.Module):
    def __init__(self, dim: int, eps: float = 1e-5):
        super().__init__()
        self.eps = eps
        # Learnable scaling parameter
        self.weight = nn.Parameter(torch.ones(dim))

    def _norm(self, x):
        # Compute the RMS and normalize
        # rsqrt(x) = 1/sqrt(x), which is more efficient
        return x * torch.rsqrt(x.pow(2).mean(-1, keepdim=True) + self.eps)

    def forward(self, x):
        # Normalize + scale
        output = self._norm(x.float()).type_as(x)
        return output * self.weight

Key points:

x.pow(2).mean(-1): computes the mean of the squares of each vector
torch.rsqrt(...): computes the reciprocal square root (1/√x)
keepdim=True: keeps the dimension so broadcasting works
self.weight: a learnable parameter that lets the model adjust the scaling ratio itself

3.3 Verifying the Effect

Now let's add RMSNorm to the 8-layer network:

class DeepNetworkWithNorm(nn.Module):
    def __init__(self):
        super().__init__()
        self.layers = nn.ModuleList()
        for _ in range(8):
            self.layers.append(nn.Linear(512, 512))
            self.layers.append(RMSNorm(512))  # add RMSNorm after each layer
            self.layers.append(nn.ReLU())

    def forward(self, x):
        for i in range(0, len(self.layers), 3):
            x = self.layers[i](x)      # Linear
            x = self.layers[i+1](x)    # RMSNorm
            x = self.layers[i+2](x)    # ReLU
            print(f"Block {i//3 + 1} std: {x.std().item():.4f}")
        return x

# Test
model = DeepNetworkWithNorm()
x = torch.randn(32, 512)
output = model(x)

Output:

Block 1 std: 0.9823
Block 2 std: 1.0142
Block 3 std: 0.9956
Block 4 std: 1.0089
Block 5 std: 0.9934
Block 6 std: 1.0023
Block 7 std: 0.9987
Block 8 std: 0.9956  ← stable around 1!

Conclusion: the standard deviation stays around 1, so the gradient can propagate smoothly!

3.4 The Key Properties of RMSNorm

RMSNorm normalizes while keeping the vector's direction unchanged, adjusting only its magnitude. This means:

Semantic information is preserved:

A vector's direction represents its "meaning"
The cosine of the angle is almost identical before and after normalization (difference < 10^-9)
It only adjusts the magnitude, not the meaning, so no information is lost

Training is stable:

Each layer's output standard deviation is roughly 1
Gradients neither explode nor vanish
You can stack very deep networks (96+ layers)

4. RMSNorm vs LayerNorm

4.1 Comparing the Formulas

LayerNorm (the BERT/GPT-2 era):

mean = mean(x)
var = mean((x - mean)²)
x_norm = (x - mean) / sqrt(var + eps) × weight + bias

RMSNorm (the Llama/MiniMind era):

rms = sqrt(mean(x²) + eps)
x_norm = x / rms × weight

4.2 A Detailed Comparison

| Property | LayerNorm | RMSNorm | |------|-----------|---------| | Step 1 | compute the mean | none | | Step 2 | subtract the mean (centering) | none | | Step 3 | compute the variance | compute the root mean square | | Step 4 | divide by the standard deviation | divide by the RMS | | Parameters | weight + bias | weight only | | Compute | 2 passes over the data | 1 pass | | Speed | baseline (1x) | 7.7x faster | | Effect | very good | comparable or better | | Used by | BERT, GPT-2 | Llama, MiniMind |

4.3 A Speed-Comparison Experiment

Timing 1,000 forward passes, here are the measured results on an NVIDIA A100:

LayerNorm time: 0.0234s
RMSNorm time: 0.0030s
Speedup: 7.80x  ← nearly 8x faster!

4.4 Why Can We Skip Subtracting the Mean?

The key question: LayerNorm subtracts the mean and RMSNorm doesn't — so why does it still work?

The theoretical explanation:

The statistical properties of deep networks:
- After many layers of transformation, the mean of the activations is usually close to 0
- This is especially true in networks with residual connections
- Controlling only the variance/RMS is enough for stable training
Empirical validation (the Llama paper):
- Measuring the mean of each layer's output in a 100-layer network
- The means ranged over [-0.0234, 0.0187], very close to 0
The compute-efficiency trade-off:
- The benefit of subtracting the mean: a more symmetric distribution
- The cost of subtracting the mean: extra computation
- In deep networks, the benefit < the cost

4.5 Comparing the Actual Results

Experimental results from Meta's Llama paper:

| Configuration | LayerNorm | RMSNorm | Difference | |---------|-----------|---------|------| | 7B model PPL | 12.34 | 12.31 | -0.24% ✅ | | Training speed | 100% | 112% | +12% ✅ | | Memory usage | 100% | 98% | -2% ✅ |

Conclusion: comparable results, faster speed!

5. Where RMSNorm Sits in the Transformer

5.1 A Common Misconception

❌ Wrong: "A Transformer has an RMSNorm layer."

✅ Right: "A Transformer Block has RMSNorm components inside it."

5.2 The Structure of a Transformer Block

class MiniMindBlock(nn.Module):
    def __init__(self, config):
        super().__init__()
        # 1st RMSNorm: before Attention
        self.input_layernorm = RMSNorm(config.hidden_size)

        # Attention
        self.self_attn = Attention(config)

        # 2nd RMSNorm: before FeedForward
        self.post_attention_layernorm = RMSNorm(config.hidden_size)

        # FeedForward
        self.mlp = FeedForward(config)

    def forward(self, x):
        # ========== Part 1: Attention ==========
        residual = x
        x = self.input_layernorm(x)        # ← RMSNorm #1
        x = self.self_attn(x)
        x = residual + x                    # residual connection

        # ========== Part 2: FeedForward ==========
        residual = x
        x = self.post_attention_layernorm(x)  # ← RMSNorm #2
        x = self.mlp(x)
        x = residual + x                    # residual connection

        return x

Data-flow diagram:

input x
  ↓
  ├─────┐ (save residual)
  ↓     │
RMSNorm #1  ← normalize
  ↓
Attention  ← attention mechanism
  ↓
  └─────┘ (add residual)
  ↓
  ├─────┐ (save residual)
  ↓     │
RMSNorm #2  ← normalize
  ↓
FeedForward  ← feed-forward network
  ↓
  └─────┘ (add residual)
  ↓
output

5.3 Counting Them in a Full Transformer

Taking MiniMind as an example:

MiniMindModel
├─ embed_tokens (token embeddings)
├─ layers: 8 MiniMindBlocks
│   ├─ Block #1
│   │   ├─ input_layernorm (RMSNorm)      ← #1
│   │   ├─ self_attn
│   │   ├─ post_attention_layernorm (RMSNorm)  ← #2
│   │   └─ mlp
│   ├─ Block #2
│   │   ├─ input_layernorm (RMSNorm)      ← #3
│   │   └─ ... (same as above)
│   └─ ... (Blocks #3-8, two RMSNorms each)
└─ norm (final RMSNorm)                    ← #17

The count:

Each Block: 2 RMSNorms
8 Blocks: 8 × 2 = 16 RMSNorms
Before the final output: 1 RMSNorm
Total: 17 RMSNorms

5.4 Why Place It Before Attention/FeedForward?

This comes down to the Pre-Norm vs Post-Norm design choice.

Post-Norm (the original Transformer, 2017):

# normalization comes after the sublayer
x = x + Attention(x)
x = Norm(x)
x = x + FeedForward(x)
x = Norm(x)

Pre-Norm (modern Transformers, Llama/MiniMind):

# normalization comes before the sublayer
x = x + Attention(Norm(x))
x = x + FeedForward(Norm(x))

The advantages of Pre-Norm:

| Property | Post-Norm | Pre-Norm | |------|-----------|----------| | Training stability | hard for deep networks | more stable ✅ | | Gradient propagation | can be interrupted by Norm | cleaner residual path ✅ | | Learning rate | needs warmup | can use a larger learning rate ✅ | | Best suited for | shallow networks (< 12 layers) | deep networks (> 12 layers) ✅ |

Modern LLMs all use Pre-Norm (GPT-3, Llama, MiniMind, Mistral...).

6. Hands-On Experiments and References

6.1 Running the Example Code

The complete learning materials are open source, so you can run and verify them yourself:

# Clone the code
git clone https://github.com/joyehuang/minimind-notes
cd minimind-notes/learning_materials

# Experiment 1: observe vanishing gradients
python why_normalization.py

# Experiment 2: a demonstration of how RMSNorm works
python rmsnorm_explained.py

# Experiment 3: LayerNorm vs RMSNorm comparison
python normalization_comparison.py

6.2 References

Papers:

Root Mean Square Layer Normalization — the original RMSNorm paper
Llama 2 Technical Report — includes practical experience with RMSNorm

Code:

MiniMind source: github.com/jingyaogong/minimind
RMSNorm implementation: model/model_minimind.py:95-105

Other articles in this series:

7. Summary

7.1 Key Takeaways

✅ Vanishing gradients aren't magic: there's a clear mathematical principle behind them, and you can verify it with code
✅ What RMSNorm does: it stabilizes the numerical scale and preserves the vector's direction, without losing information
✅ Why it's faster than LayerNorm: it skips the mean-subtraction step and finishes in a single pass
✅ Where it sits in the Transformer: two inside each Block, not as a standalone layer
✅ The Pre-Norm design: the standard choice for modern deep Transformers

7.2 One Sentence to Remember

"Normalization is the water-pressure stabilizer of deep networks, and RMSNorm is the more efficient version."

7.3 Key Code Locations (MiniMind)

RMSNorm implementation: model/model_minimind.py:95-105
Used in the Block: model/model_minimind.py:359-380
Learning example code: learning_materials/why_normalization.py

Author: joye Published: 2025-12-16 Last updated: 2025-12-16 Series: MiniMind learning notes (1/4)

If you found this helpful, feel free to:

⭐ Star the original project MiniMind
⭐ Star my learning notes minimind-notes
💬 Leave a comment with your own learning insights
🔗 Share it with others studying LLMs

Frontend Intern Interviews at Chinese Startups: A Prep Guide

Thu, 23 Oct 2025 16:00:00 GMT

Background

As a second-year student at the University of Melbourne, I spent late 2025 looking for a frontend internship in Shanghai (React stack) for the November–March break. After about a week of back-to-back interviews, I ended up with roughly 10 offers. Drawing on that firsthand experience, this post summarizes the main technical topics that come up in frontend internship interviews at smaller Chinese companies, along with how to prepare for them. I'll also share some practical tips for staying sharp and performing well during a stretch of high-frequency interviewing.

Application Data

The numbers

Positions contacted: 210 (including both cold applications and HR outreach, for the main one-week push only)
Resumes exchanged: 51
Interview conversion rate: ~15%
Offers: ~10
Primary channel: BOSS Zhipin

What the data tells me

Looking at the conversion rate, resume screening for frontend internships at smaller companies is relatively lenient: about 1 in 6 conversations made it to a technical interview, and the final offer rate hit 70%. In other words, as long as you interview well, you're very likely to land an offer.

Breakdown of Technical Interview Topics

Based on every technical interview I went through (smaller companies usually run a single round, with the occasional second round or lead interview), it's clear they care more about fundamentals and practical framework usage. Below I only keep the "what gets asked" points; the "how to prepare" part comes later, to avoid repetition.

React (high frequency)

Hooks: common Hooks and their use cases, useEffect dependencies and the closure/render pitfalls
Component communication and state: parent-child (props), cross-level (Context), global (lightweight state libraries, e.g. the basics of Zustand/Redux)
Performance optimization: controlling re-renders, memo/useMemo/useCallback, the gist of virtual lists
New features: how React 18/19 affect concurrency, forms, and server-side capabilities

JavaScript (high frequency)

ES6+: destructuring/spread, modules, the differences between arrow functions and regular functions (this, arguments, can't be used as constructors), var vs let/const (scope, hoisting, the temporal dead zone)
Async: Promise chains, async/await, error boundaries and unified handling
Coding questions: debounce/throttle, array deduplication, and (at the conceptual level) deep copy

TypeScript (medium frequency)

Common types, interface vs type, basic generics, frequently used utility types

Build Tools and Frameworks (medium frequency)

Next.js: why choose it, SSR/SSG scenarios, and the SEO differences
Build tools: how Vite and Webpack work and their performance differences

CSS Layout (high frequency)

Types of responsive layout:
- Media queries: breakpoint-driven; the upside is fine-grained control, the downside is the maintenance cost of breakpoints; good for B2C pages with clearly defined device breakpoints
- Fluid layout (percentages + max/min): shrinks naturally with the container; simple to implement, but elements can become unbalanced at extreme widths; good for information-oriented content pages
- Flexbox: distributes along the main axis/cross axis; strong for one-dimensional layouts, limited for two-dimensional arrangements; good at the component level and for linear arrangements
- CSS Grid: a two-dimensional grid; very expressive, but with a steeper learning curve; good for complex panels/dashboards
- Modern responsiveness (clamp/container queries): adapts based on container/font size; closer to a component-based approach, though you'll need to verify browser support; good for design systems and component libraries
- Combined strategy: mobile-first, content-driven breakpoints
The classic three-column layout (Holy Grail / Twin-Wing): the underlying principles and differences, plus the trade-offs between Flex and Grid implementations

Networking and Browsers (low frequency)

HTTP status codes and how redirects work
Cross-origin issues (CORS/proxies) and how to debug using the DevTools Network tab

Git (low frequency)

Branching strategy, git rebase, git fetch

Other (role-specific)

Deployment: the typical frontend deployment flow and basic troubleshooting
AI/LLM (specialized roles): RAG, long-context quality assurance, API response structures
Forms: ways to inject/prefill data into a form library

Where to Focus Your Prep

Based on the "what gets asked" above, here's an action checklist for "how to prepare efficiently," keeping repetition to a minimum:

Core stack (80% of your effort)

The React ecosystem:
- Go through the common Hooks and practice them with small demos; get a solid grasp of useEffect dependencies and pitfalls
- Get comfortable with props/Context and one lightweight state library (I'd suggest Zustand)
- Do a focused performance exercise: track down redundant re-renders, apply memo/useMemo/useCallback, and build a basic virtual list
CSS layout: build a responsive page once using Flex and media queries
JavaScript fundamentals:
- Shore up ES6+ (modules, destructuring/spread, this behavior)
- The async trio: Promise chains, async/await, error-handling patterns
- Three coding questions: debounce, throttle, array deduplication (optional: the approach to deep copy)

Supporting knowledge (20% of your effort)

TypeScript: basic types, interface vs type, one generics example, common utility types
Computer networking (just the basics is fine):
- The four-layer TCP/IP model; what happens from typing a URL to the page rendering
- Common status codes; TCP's three-way handshake / four-way teardown; TCP vs UDP; cross-origin issues (CORS/proxies)
- Recommended: Xiaolin Coding - Illustrated Networking (lots of diagrams, which makes it easier to understand and remember)
Build tools/Git: understand the differences between Vite and Webpack; day-to-day branch management and the basics of rebase

Resume Tips

Choosing a tool

I recommend Reactive Resume:

Open source and free, with data export
Professional templates and clean typography
Supports Markdown and custom styling

Content principles

Skills section

Group by proficiency (proficient, comfortable, familiar)
Only list technologies you've actually used, not ones you've merely read the docs for
Highlight the skills that match the role

Projects section

Two or three representative projects is plenty; highlight the stack you know well (React / Next.js / TypeScript, etc.).
I'd suggest a concise structure for each description:
- Overview: one sentence on what it does and where it sits (e.g. "a voice-interaction platform for AI-powered mock interviews").
- Technical highlights: focus on the features you built yourself or the problems you solved (e.g. "implemented the login/registration logic and database integration," "built a reusable form component").
- What you learned: things like "got the hang of the SSR rendering flow" or "understood how Zustand's state management works."
- Real over flashy: don't force performance metrics; focus on which key technologies you mastered and which problems you solved.
Ship it if you can: even deploying to Vercel / Netlify demonstrates completeness and hands-on ability.
Stack consistency: the frameworks and libraries mentioned in your projects should line up with the skills section — keep everything consistent.

The key principle

Every technology and project detail on your resume needs to be something you can explain in depth. Interviewers ask questions based on your resume, and listing things you're not familiar with is an easy way to get exposed.

Interview Strategy

Technical interviews

Fundamentals first: smaller companies weigh fundamentals over projects — solid JavaScript and React basics matter more than a complicated project
Structured delivery: when answering, lead with the conclusion, then fill in the details
Be honest: for things you don't know, "I'm not deeply familiar with this, but my understanding is..." beats winging it
Make the most of the Q&A: never waste the chance to ask questions — you can ask about the specifics of the internship, the team and the product, or where you could improve based on the interview

Communication tips

Stay active on BOSS Zhipin and reply to messages promptly
When cold-applying, briefly explain why you're a good fit
Send a thank-you note after the interview to express your interest

Review and practice

Interview enough that nerves fade: pack your interviews into a short window so you get into the groove quickly
Record and review (for your own use only): replay the questions and your answers, mark each as "good / okay / needs work," and patch the gaps accordingly
Turn it into a checklist: organize the frequent questions and common mistakes into flashcards and practice them with spaced repetition
Ship your projects if you can: put the live URLs on your resume and personal homepage — HR and interviewers will actually visit them, and it's a clear plus

Wrapping Up

The technical bar for frontend internships at smaller Chinese companies is fairly clear: solid JavaScript fundamentals + comfortable React usage + reasonable resume packaging. Compared to the big players, smaller companies care more about "can you get up to speed and do the work" than about algorithms and system design.

In terms of return on effort, I'd suggest spending 80% of your time on React and JavaScript fundamentals (the classic interview canon) and 20% on resume polishing and project prep.

I hope this rundown helps anyone out there looking for an internship.

References:

My First-Ever Pull Request

Tue, 01 Jul 2025 22:06:36 GMT

import { GithubCard } from 'astro-pure/advanced'

Preface

On June 27, 2025, around 7 PM Melbourne time, I opened the first pull request of my life — for the VMind project in the VisActor community. It would be a lie to say that moment wasn't exciting. After all, in my mind, open source had always been something only seriously skilled people could do. I'd tried to break into open source before, but those attempts clearly failed. Maybe my approach was wrong, maybe my goals weren't clear enough, or maybe it was just my tendency to give up halfway.

How I found this project

It was a lucky break, honestly. I discovered this open-source project through OSPP (and if the event hadn't been postponed, I probably wouldn't have applied at all). To be honest, I do have a bit of an aversion to high-difficulty tasks. At the time, I browsed every JavaScript project in this round of OSPP and noticed a few of the VisActor community's foundational projects. One of them was building a candlestick chart for VChart — I was really interested in it, so that same night I did some research and reached out to the mentor. The reply, however, made it clear that all VisActor projects would be judged on cumulative contributions made during the OSPP registration window. In other words, someone like me, hoping to "snag a leftover spot" a week after the deadline, basically had no chance of being accepted. Still, the mentor's email included a QR code for the VisActor Contributors Group on Feishu, and I joined right away. As a newcomer, I didn't dare say much at first — mostly I just scrolled through the past chat history (Feishu keeps message history) and quietly learned.

Picking an issue

I found the group's atmosphere incredibly welcoming. When someone wanted to claim an issue, they'd simply comment under the GitHub issue and give a heads-up in the Feishu group, and a core contributor or maintainer would respond. For someone like me, participating in open source for the first time, this was genuinely a great fit — it spared me a lot of the "nobody's responding" anxiety, and I could ask questions in the group anytime. I went through the issue trackers of all four open-source projects in the VisActor community and found that VMind currently had mostly beginner-friendly unit-test tasks, many of them tagged "good first issue." Through AI and online searches, I also confirmed that writing unit tests really is a solid entry point into open source (along with non-coding tasks like fixing documentation).

Getting started for real

I picked an issue and left a comment saying I wanted to claim it (later I confirmed it again in the Feishu group — everyone's busy, so I'd recommend just saying it in the group directly). From there it was the standard open-source contribution flow: fork the repo, clone it locally, set up the remote and upstream, then start studying the project code. Since this was about writing unit tests, I first looked at the test folder and quickly found where I needed to add my test (and discovered the existing tests for other chart types). What I wrote this time was the test file for getChartSpecWithContext_boxplot — essentially adding BoxPlot-type tests for VMind's getChartSpecWithContext function, to verify the data-field mapping and chart-spec logic when AI generates charts. At first my head really was spinning a bit (maybe I'm just too much of a noob), so I handed the issue to an AI and asked it to lay out the rough steps for me (plenty of small problems cropped up along the way, of course), along with the concepts I needed to grasp. For instance, this project uses Jest, so I had to go learn it (checking the official site, or a crash-course video on YouTube / Bilibili — a one-hour speedrun is plenty). What I think you absolutely must do is read the test code already written in the project and learn how others write it. Even if everyone uses Jest, different projects still differ a bit. And the process of understanding someone else's code deepens your understanding of the project itself. My first draft was actually modeled on the pie chart's test file — I then tweaked the data (which I found in the mockdata) and asked the AI to take a look at the problems. I'd specifically point out: I don't need the answer directly; I just need you to point out the problems and the approach — I'll write the code myself. I think this distinction matters a lot. AI can certainly handle simple test tasks, but if you let it, you won't learn a thing. If you let AI generate complete, ready-to-use code, very few people would bother studying the reasoning behind each line. But writing it yourself means hitting pitfalls and debugging, and that process is enormously valuable for improving your skills — in any field.

The PR gets merged

I posted in the Feishu group asking a contributor to review my work, and feedback came quickly: I'd written two pointless lines of code. After fixing that and pushing a new commit, my PR was successfully merged today (July 1, 2025)!

Takeaways

This experience taught me a lot. First, I learned how to get started on an issue, including how to locate the corresponding spot and function within a project. In my case, I needed to find where to add the test file, the definition of the getChartSpecWithContext function, the core code for the BoxPlot chart (which defines the fields that needed testing), and the mockdata (which could be used directly for testing). Once I'd found that code, I read and understood it, then extracted the parts I needed for the test. Second, I think imitation is a great friend of learning. Human learning often starts with imitation. My first draft was modeled on the pie chart's test — it had bugs (for instance, I used the pie spec but was testing a boxplot), but this "imitate and improve" process is important. Once you have a framework, asking an AI for help becomes more efficient too. I also ran into the kind of small problems common to "big projects," like Node.js version incompatibility. That's when you need nvm to install and switch between multiple versions. And here's something amazing: once you claim an issue in an open-source project, you feel a powerful sense of responsibility — you genuinely want to do the job well. So now I've gone and left a comment on another issue in this project, ready to keep contributing!

If you found this experience helpful, or you're thinking about giving open source a try yourself, consider following the VisActor community's projects or dropping by the group — maybe you'll find a "first time" of your own too.