A Five-Episode Season: Batch Production, Portfolio Packaging, and a Short-Drama Pipeline Interview Deep Dive

Reviewing one real run: four numbers

A review that reports one total duration or one "it ran" is useless. A run must leave at least four numbers: elapsed time, spend, failure rate and human touches. Missing any one and the line is still a black box to everyone else.

Each answers a different question:

• Elapsed time answers "can we deliver on schedule," deciding whether you dare take a five-episodes-a-week job.
• Spend answers "can this be profitable." Per-episode cost times episode count is your cost floor.
• Failure rate answers "is it stable." Note the denominator is calls, not episodes — twenty calls in an episode with one failed retry is a 5% failure rate, not 20%. The lab injects no failures by default; add INJECT=taskfail and the failure column comes alive.
• Human touches answers "can this scale." That number is the most overlooked and the most important: if an episode needs three human interventions, how many episodes a week this line can produce depends on a person's time, not a machine's.

The season bill the lab prints looks like this:

-- Season bill --
   ep  title         elapsed   img  video s  tts chars  calls  fail  human  spend (est)
   E1  Found          1257ms    2       8      18     6     0     0  CNY 4.0563
   E2  Obituary       1270ms    2       8      22     6     0     0  CNY 4.0577
   E3  Father's watch 1171ms    2       8      24     7     1     0  CNY 4.0584
   E4  The same watch 1154ms    2       8      16     6     0     1  CNY 4.0556
   E5  Powered off    1144ms    2       8      13     6     0     0  CNY 4.0545
   total 5 episodes, 6.0s, 31 calls, 1 failure (failure rate 3.2%), 1 human touch
   spend (estimated) CNY 20.2825, CNY 4.0565 per episode

Two conventions must be stated, because they decide whether this bill is trustworthy.

First, failed calls go into the bill too. A failed retry consumed time and quota, even if it may not have been billed. Leave it out and your "calls per episode" comes out low, and capacity planning is wrong throughout — projecting concurrency against D9's rate-limit table with the wrong denominator will walk you straight into rate limiting in production.

Second, spend is still an estimate, and the three tiers are not equally trustworthy. Images at CNY 0.025 are officially listed; speech publishes only package pricing, so the per-character rate is derived; and video is the subtlest — the pay-as-you-go page lists per-second rates for several resolution tiers, while the video API used here is deducted officially as video credits, two non-interchangeable regimes, so the per-second constant in the code is a ledger demonstration value not attached to any specific model id (D12 covered this). Put those three sentences verbatim into the portfolio document so nobody mistakes it for a real invoice.

An observation in passing: CNY 20.28 for the season, of which video is still over ninety percent. In fourteen days, this line's cost structure has never changed. Which is the best footnote to D12's judgment — every engineering decision orbits calling the video API one fewer time, not because it is elegant but because that is what the arithmetic says.

function summarize(records) {
  const attempts = records.reduce((s, r) => s + r.attempts, 0)
  const failures = records.reduce((s, r) => s + r.failures, 0)
  const totalCny = Number(records.reduce((s, r) => s + r.estimatedCny, 0).toFixed(4))
  return {
    episodes: records.length,
    totalMs: records.reduce((s, r) => s + r.ms, 0),
    totalCny,
    perEpisodeCny: records.length ? Number((totalCny / records.length).toFixed(4)) : 0,
    // Denominator is calls, not episodes - the wrong one makes capacity planning optimistic
    failureRate: attempts ? Number((failures / attempts).toFixed(4)) : 0,
    // This number decides whether the line can scale: it is bound by human time, not machine time
    manualTouches: records.reduce((s, r) => s + r.manualTouches, 0),
  }
}

def summarize(records):
    attempts = sum(r["attempts"] for r in records)
    failures = sum(r["failures"] for r in records)
    total_cny = round(sum(r["estimated_cny"] for r in records), 4)
    n = len(records)
    return {
        "episodes": n,
        "total_ms": sum(r["ms"] for r in records),
        "total_cny": total_cny,
        "per_episode_cny": round(total_cny / n, 4) if n else 0,
        # Denominator is calls, not episodes - the wrong one makes planning optimistic
        "failure_rate": round(failures / attempts, 4) if attempts else 0,
        # This number decides whether the line can scale: bound by human time, not machine time
        "manual_touches": sum(r["manual_touches"] for r in records),
    }

Packaging the portfolio: three artifacts for three readers

Finishing the code is not finishing the portfolio. A project that is only a repository link reads to others as "ran a script," because nobody reads source code to understand your project.

A portfolio needs three artifacts, aimed at three completely different readers.

A demo reel, for people who give you three minutes. Hiring managers, recruiters and non-technical interviewers will not run your code. Thirty seconds showing "one sentence in, a season out" beats a thousand words of description. The lab takes each episode's first shot and stream-copies them into one clip — note there is no re-encoding here either; with identical encoding parameters, -c copy is enough, and a season plus a reel means six joins, each of which would otherwise recompress, slowly and lossily.

An architecture diagram, for the technical interviewer. The diagram's job is not to look good; it is to let the reader know within thirty seconds where to aim their questions. So it must show not only the flow but the horizontal infrastructure blocks — workflow engine, concurrency gate, budget breaker, review console — because those are what separate this project from "called a few APIs."

flowchart TD
  idea[one-sentence premise] --> script[script Agent: structured storyboard and auto review]
  world[(world bible: cast, style, hooks)] --> script
  script --> assets[character and set assets]
  assets --> frames[per-shot first frames]
  frames --> clips[shot videos: async task polling]
  script --> voice[dubbing and subtitles]
  clips --> compose[ffmpeg assembly: vertical cut]
  voice --> compose
  compose --> qc[QC and compliance]
  qc --> release[multi-platform release: render once package many]
  engine[workflow engine: idempotency and resume] --- clips
  gate[concurrency gate and quota] --- clips
  budget[cost routing and budget breaker] --- clips
  console[human-in-the-loop review console] --- qc
  release --> data[data feedback: retention mapped back to stages]
  data --> script

A written document, for people who will actually read. It must answer three questions up front: what this is, what one real run's numbers are, and how to run the code. The lab fills the season bill's numbers into that document automatically, so what you hand over is not a template but a report carrying real results.

Missing any one of the three costs you: with only a reel, a technical interviewer thinks you make videos; with only a diagram, non-technical readers understand nothing; with only a document, nobody has the patience to finish.

One more thing that is easy to overlook: all three must speak for themselves with you absent. The most common use of a portfolio is being forwarded — the hiring manager sends it to an engineering lead, who glances at the diagram and decides whether to book you. So the reel's first three seconds must say what this is, every block on the diagram needs a name rather than an abbreviation, and the document's first paragraph must give the scale and the numbers. Anything that needs you standing beside it saying "well, this part is actually..." breaks the forwarding chain.

How to tell it in an interview: three technical stories

The last section is about interviews. This project offers too much to tell, and interviews last tens of minutes, so converge on three stories first, each tellable in two minutes and each hitting a different class of question.

Story one: the whole engineering design orbits one judgment. Open with the number — video is over ninety percent of an episode's cost and is also the slowest and most failure-prone. Then hang idempotency keys, artifact caching, reference-image reuse, draft-tier routing and the budget breaker off it, showing they are all corollaries. This story tests whether you have systemic trade-off judgment, not whether you can use a library. Its force is that whichever component the interviewer asks about, you can bring the thread back to the same spine.

Story two: how to write an async task client that does not strangle itself. Submit, poll, collect, download — four steps, each of which can fail, and failures split into retryable and not. A state machine plus exponential backoff, plus timeout abandonment, plus classification by error code, plus billing rules like "failed and safety-blocked calls are not billed." This story tests density of engineering detail and is the easiest to be probed on — be ready for "how many retries," "how long a backoff," "how do you set the timeout."

Story three: which cell of the line the human occupies. Fully automatic produces a pile of films nobody watches; fully manual cannot keep up. The review console places the human between QC and release, and translates "change one line" into "which downstream nodes need recomputing." This story tests product sense, and most candidates cannot answer it — it proves you thought about who this system is for.

The three map to three classes of question: system trade-offs, engineering detail, product judgment. Two general rules while telling them: every story carries a concrete number (ninety percent, four steps, one cell), because numbers are where credibility comes from; and every story leaves a hook to be probed, steering the interviewer toward what you prepared best.

As for "what would you change if you did it again," honesty beats inventing a perfect plan. What genuinely deserves changing on this line is right there: the console's recomputation scope is currently computed per node dependency and the granularity could be finer; and the derived unit prices in the cost table should be replaced with measured values once real invoices arrive. Being able to state your solution's boundaries proves you built it better than the solution itself does.

Where this line can go next

Fourteen days are over, and the line has one natural next step: lift the judgments it uses repeatedly out of the code.

Your project now holds a body of material that is neither general code nor business data but experience: how to cut a storyboard, how to assemble a prompt, how to classify a failure, when to call a human. It is currently scattered across functions, comments and constant tables. Change genre or change vendor and most of that experience still holds, but you have to lay it out again in new code.

Distilling it into a reusable capability package is the natural next move — and that is what this platform's Agent Skills course is about: separating the work instructions from the code so the same experience can be loaded repeatedly across projects. If you plan to push this line toward a product, that is the right place to continue.

Source Reading

Hands-On Lab

Before starting, be clear on one thing: this lab's deliverable is not only code but that portfolio/README.md. The program fills in the numbers and builds the skeleton; the flesh of the three technical stories is yours to write — and that is this day's real deliverable.

1. Run the starter unmodified, and use the consistency check's failures and the bill's zeros to judge which logic is not implemented yet.
2. Change prompt assembly to read only from the record, re-run, and confirm "appearance verbatim from the record" and "style tokens on every shot" turn green.
3. Add the hook comparison, then deliberately change one episode's hook and confirm that item turns red on the spot.
4. Implement spend estimation and stream-copy joining, confirm the bill is no longer all zeros and the log shows no re-encoding, then run with INJECT=taskfail and confirm the failure column and rate move.
5. Open the generated portfolio/README.md, expand each of the three technical stories into a two-minute version, then answer the interview follow-up list to yourself and mark what you still cannot answer.

Interview Questions

Today's 3 questions are in the question bank below, focused on the engineering means of cross-episode consistency, how to structure the telling of a project, and this line's overall architecture trade-offs. Read the analysis before the key points — practicing the derivation beats memorizing them. The cn / global labels let you pick by target market.

Checklist and Tomorrow

• I can produce a five-episode season in one run, and explain how cross-episode consistency was kept
• I can package this project into portfolio material someone else can understand in three minutes
• I can handle follow-up questions clearly on this pipeline's architecture trade-offs, cost control, and failure handling
• I can name the four numbers a run must leave behind, and why the failure rate's denominator is calls
• I can tell all three technical stories in two minutes each, with a concrete number in every one
• All 5 lab acceptance criteria pass
• I can answer at least 2 of the 3 interview questions without looking at the key points

Course end, and what comes next. There is no day fifteen; the course ends here. Look back at day one's task graph: what you write now has idempotency, concurrency, review, QC, cost control, distribution and season-scale batching on top of it. Two things are worth doing next: run this line for real on a subject of your own and replace the portfolio's numbers with your own run's; and follow the section above on distilling this line's experience into a reusable capability package. Good luck with the shoot.