Resume and Project Packaging: STAR, README, Architecture Diagrams, a Demo Video, an English Resume

Pick one bullet per repository, and find the number first

Fix the names first and use the same set in every later artifact, rather than "my agent project" one moment and "week one's homework" the next: agent-service (W1's output, a containerizable single-agent service), mini-koda (W2's output, a distributed execution platform with a gateway and a worker pool), and mini-multi-agent (W3's output, a multi-role orchestration service).

Pick each repository's strongest bullet and fit the pattern. Take mini-koda's, whose numbers are the prettiest of the three:

Under the constraint of one machine running three worker replicas via docker compose,
in order to keep one user's messages strictly ordered, I changed the shard key from
message length to a hash of the user id and gave every shard a lease with holder
validation; shard utilization rose from 1 of 256 occupied to all 256, and the largest
bucket fell from 2,000 messages to 19 (ideal 8); after a holder froze, another replica
took over in about 2.8 seconds, and one user's message sequence numbers were still a
strict 1 through 6 across the handover.
(Measured locally on one machine in offline mock mode, with 2,000 simulated users and
256 shards.)

One sentence holds three numbers, each from a real measurement: the shard distribution printed by self-check 1, the 2.8 seconds from check 4's trace, and whether the sequence scrambled from check 4's comparison output. Why is this bullet useful? Because it naturally invites three follow-ups — why hash the user id, why the lease needs holder validation, and where 2.8 seconds came from — and you can answer all three, so on your resume you laid a road you know well for the interviewer.

mini-multi-agent's picks the parallel-state-write trap:

Under the constraint of several subagents writing one graph state in parallel, in order
to eliminate duplicate records in the workspace, I changed the workspace channel's
reducer from append to update-by-id; the records left by 3 subtasks fell from 6
(including 3 duplicate ids, where a lookup by id returned the stale pending version) to
3, with 0 duplicates and every status done.
(Measured locally on one machine in offline mock mode, on the same graph with only the
reducer swapped for an A/B comparison.)

That clause about the same graph with only the reducer swapped is this bullet's soul. Somebody who can present a controlled experiment is not at the same level, to an interviewer, as somebody who reports one final figure: the former shows you know what your one change actually produced, and the latter only proves your program eventually ran.

After writing all three, subtract: if the three repositories demonstrate the same capability (all of them saying "I can use Docker") then you effectively have one bullet. The ideal split has one on protocols and streaming (agent-service), one on distribution and state (mini-koda), and one on orchestration and cost (mini-multi-agent), so the coverage spreads and whichever direction the interviewer enters from, you have material.

A README is written for somebody who leaves after three minutes

The resume lured them to GitHub, and what decides the outcome next is the repository's front page. There is a brutal reality here: whoever reads your README has a three-minute budget and does not intend to clone and run it. So a README is not documentation, it is a second product page.

Seven fixed sections in this order, and fill in any that are missing:

# mini-koda
 
One-line positioning: an agent execution platform separating a gateway from a worker
pool, decoupled by a message bus, guaranteeing one user's messages stay strictly ordered.
 
## Architecture
(a Mermaid diagram, see the next section)
 
## Quick start
(running within three commands)
 
## Key design decisions
1. Why shard by hashing the user id - and what was given up
2. Why the lease needs holder validation - and what was given up
3. Why the heartbeat does not feed the readiness probe - and what was given up
 
## Known limitations
## Directory guide
## License

Three of those sections are most easily written badly, so each gets a note.

Quick start's hard requirement is three commands. Not three paragraphs of explanation, three copy-pasteable lines. More than three means your project has unhandled implicit dependencies (create a database by hand, edit configuration by hand, request a key first). The criterion is equally hard: find a machine that has never run this project, or at least a freshly created empty directory, and type your own instructions out. Your own machine always works, because the environment variables, the node version, and the image cache are already there — this course's most common "it works on mine."

Every key design decision must include what was given up. That section is the most valuable part of the whole README, because it is the only content that cannot be copied from a template. "Used Redis Streams as the message bus" is a feature list; "used Redis Streams rather than Kafka, giving up cross-datacentre replication and unlimited replay in exchange for starting on one machine with one container to operate" is a decision. An interviewer will pick one of those three and open on it, so you effectively set three questions and prepared your own answers.

Known limitations is a bonus rather than a liability. Many people dare not write it for fear of exposing weakness. The opposite holds: volunteering "verified only on one machine so far, with no cross-datacentre work; vector search in offline mock mode is a full scan with no index" conveys two things — you know where your boundary is, and you will not oversell a demo as production. And it has a practical benefit: saying it first makes it hard for an interviewer to use it against you, and at most they ask which you would fix first for production, which you can answer.

One diagram answers one question

Use Mermaid for architecture diagrams, never screenshots. The reasons are practical: Mermaid renders natively on GitHub so the reader need not open an image; its source is text, so changing a node is a one-line diff rather than reopening a drawing tool, exporting, and replacing a file; and you edit it in passing while writing the README, whereas the screenshot approach requiring a tool switch will eventually go stale.

What to draw and what not has one criterion: leave only where the data flows and where the boundaries are, and delete everything else. No class diagrams, no dependency version numbers, and not every middleware on the board. Keep nodes under eight, and beyond that split into two — one overview and one drawing only the part you intend to go deep on.

mini-koda's looks like this:

flowchart LR
  C[Client] -->|POST /chat| G[Gateway]
  G -->|persist runs| DB[(Postgres)]
  G -->|publish sharded by user| BUS[[Redis Streams]]
  BUS --> W1[Worker replica 1]
  BUS --> W2[Worker replica 2]
  BUS --> W3[Worker replica 3]
  W1 -->|state and messages| DB
  W1 -->|SSE back| C

Eight nodes and three shapes: rectangles are services, the cylinder is storage, the double box is the bus. If somebody looking at it can say within five seconds that requests enter at the gateway, work happens in three workers, and state lives in Postgres, the diagram succeeded.

The counterexample puts Nginx, log collection, monitoring, and the config service on it and labels every edge with a protocol and a version. That kind of diagram looks maximally informative and conveys the least, because the reader cannot find the main line. One diagram answers one question, and yours answers "a message's lifecycle," so anything unrelated to that lifecycle stays off.

The check is cheap: send the diagram alone to a friend who does backend work and has never built an agent, and ask where requests enter, where work happens, and where state lives. If they can say it, it passes; if they cannot, there are too many nodes or the naming is jargon. On naming: use generic words like "Gateway" and "Worker replica" rather than internal abbreviations only you understand.

A three-to-five-minute demo video

Many people skip the video on the grounds that nobody watches it. The opposite holds: among a pile of text-only resumes, a working demo link is a strong differentiator, because it proves what text cannot — this thing genuinely runs, and you can talk about it.

Four fixed sections totaling three to five minutes:

• The first 30 seconds: what it is and what problem it solves. The one-line positioning is enough; do not open with the rise of large models.
• The middle 90 seconds: run the happy path. Actually type commands and actually show output, not static screenshots.
• The next 90 seconds: talk through the hardest design decision in your view. This is the film's most important part, and pick the one where you can say what was given up — the same material as the README's fourth section.
• The last 30 seconds: known limitations and next steps.

Do not read the README aloud. That is the most common mistake and the most wasteful: the README already put what needed saying into text a reader consumes in two minutes, and spending five reading it aloud burns your one chance to let somebody see how you think. A video's value is the part not in the text — where you pause, how you explain a trade-off, how you react when your own program errors.

A few practical details that save time. Get the happy path working before recording; do not expect one take, and the third is usually smooth. Enlarge the terminal font until it is legible on a phone, because plenty of people open your link while commuting. Do not cut out the waiting: if a step genuinely takes 8 seconds, wait and say "this is waiting on the model," because a hard cut makes people wonder what you hid. Re-record a section when you misspeak, because re-recording is far cheaper than editing.

In passing: recording that video is a rehearsal for tomorrow. On the first take you will discover you were 40 seconds in without having said what the project does — a flaw you can re-record in a video and cannot in an interview.

An English resume is not a translation of the Chinese one

If you are applying abroad, the English resume gets rewritten rather than run through a translator. The differences split into format and wording.

Five hard format requirements: one page (no exceptions under five years of experience); reverse chronological (most recent first); every bullet starting with a verb; every bullet carrying a quantified result; and the tech stack on its own line rather than scattered through project descriptions for the reader to hunt.

Take the verb-first rule especially seriously. An English technical resume's default sentence pattern leads with a verb: Built, Designed, Implemented, Reduced, Cut, Shipped, Instrumented, Migrated. Three openings to avoid are Responsible for (which describes a job description rather than your contribution), Helped with (which reads as assisting from the sidelines), and Familiar with (which belongs in the skills section, not in experience). Compare:

weak:   Responsible for the development of a multi-agent orchestration service.
strong: Cut duplicate task records from 6 to 3 (zero duplicate ids) in a
        multi-agent orchestration graph by switching the workspace reducer from
        append to upsert-by-id. Measured locally in mock mode, same graph,
        reducer swapped for an A/B comparison.

What matters most in the differences is what must not appear: an English resume carries no photo, no age or date of birth, no gender, no marital status, and no national-id or household-registration information, nor expected salary. That is not a style preference — in the United States, Canada, the United Kingdom and elsewhere, recruiters avoiding employment-discrimination exposure are actually put in a difficult position by a resume carrying a photo and an age. Of the personal-information fields customary on a Chinese resume, the English version keeps only name, city, email, phone, and GitHub and LinkedIn links.

How to label projects echoes the integrity line above: on an English resume the three repositories are Personal project or Course project, in a block separate from Work experience. On tense, finished projects take the past tense and ongoing ones the present, without mixing them in one bullet.

Finally, write units and currency in full: p95 latency 320 ms, not "latency 320"; cost as $0.0006 per turn, not "0.0006 a turn." Interviewers abroad are sensitive to dimensions, and a number without a unit gives them no way to judge whether it is good.

Once written, one effective self-check: delete every adjective from the English resume and see whether what remains still reads. If it does, you wrote facts; if it stops making sense, adjectives were holding it up.

Source Reading

Hands-On Lab

Today's lab has no code and produces four Markdown files. starter/ holds four templates with blanks marked TODO in block quotes; solution/ holds a worked example filled in with this course's three projects. Every number in the worked example must be replaced with one you measured yourself — those numbers came from specific conditions, your completion of the blanks and your machine differ, and copying them makes them fake. When stuck, go back to that day's lab self-check output; X and Y are basically printed there.

1. Open the self-check output from D7, D14, and D19, pick one number per project showing a before-and-after difference for agent-service, mini-koda, and mini-multi-agent, fill them into star-bullets.md, and add measurement conditions to each.
2. Following readme-template.md, write a README for each repository with all seven sections, and for each of the three key design decisions state what was given up.
3. Draw a Mermaid architecture diagram for each README with at most 8 nodes, and push to GitHub to confirm it really renders.
4. Record a three-to-five-minute demo video in the structure of 30 seconds of positioning, 90 of happy path, 90 on the hardest design decision, and 30 of known limitations, putting the link on the resume and above the fold in the README.
5. Fill in resume-cn.md first and then write resume-en.md, then read every bullet yourself (or have somebody do it) and strike anything exaggerated, unable to survive follow-ups, or missing measurement conditions.

Interview Questions

Today's four questions are in the bank below, all behavioural, weighted toward how to organize an answer rather than what the model answer is — the same experience told in a different order sounds like a different level. Expand a question and read the analysis before the key points: these four analyses give the timing and order of an answer, and practicing against them beats memorizing points. Each is tagged for the China-domestic or overseas market so you can prioritize by where you are applying.

Checklist and Tomorrow

• Turn at least 3 project experiences into resume bullets using the STAR method
• Round out each of three repos with a README that includes an architecture diagram
• Produce an English resume ready to submit directly
• For every number in the three STAR bullets, say which day, which self-check, and under what measurement conditions
• Every key design decision in all three READMEs states what was given up
• All 5 acceptance criteria of the lab pass
• Answer at least 3 of the 4 interview questions without looking at the key points

Tomorrow (D28) runs one complete mock interview each in the China-domestic and overseas processes. Everything built today — the resume, the READMEs, the diagrams, the demo video — is static: you can revise it repeatedly, delete and rewrite, and have somebody review it. An interview is dynamic, happens once, and the other side interrupts whenever they like. Those two are not the same order of difficulty: a well-written resume plus somebody who starts circling 30 seconds into their self-introduction halves the effect of all that preparation. So the order must be write first and speak second — assemble the content today and practice delivering it tomorrow.