Lesson 19 · Senior platform judgment

Mock senior platform add-ons interview pack

A retrieval-first mock pack for turning the whole operational toolkit course into clear, interview-grade answers you can say under pressure.

Your win: run a realistic senior platform mock interview on yourself, score your answers honestly, and turn weak spots into a focused review plan.

In plain English Plain English: answer out loud before checking the answer points. Recognition is not recall.

Why this page matters more than a normal recap

A recap page is easy to read passively. A mock pack is not. This page only works if you treat it as active retrieval practice: answer first, then compare, then answer again more cleanly.

That is why this lesson exists. The goal is not to feel familiar with the material. The goal is to make your answers usable under pressure.

The format

This page works best if you treat it like a real interview. Answer first. Then check the points. Then answer again more cleanly.

The answer checklist A strong answer should usually include: (1) the mechanism, (2) the main trade-off or weakness, and (3) a repo-grounded consequence or example.

How to use the rounds well

Round 1 checks whether you can explain the platform’s shipping mechanics clearly. Round 2 checks whether you can defend the reliability layer honestly. Round 3 checks whether you can talk about runtime and review judgment like a senior engineer.

If a round feels weak, that is useful information. Do not skip it. That weakness is your study map.

Round 1 · Ship it

  1. Why is a forward-only migration model defensible here?
  2. Why is `gen-db-schema` part of the migration workflow?
  3. What makes a configured lint check different from an enforced guardrail?
  4. How does the secret-loading path actually work at runtime?
  5. Why is one-binary / many-subcommands useful?
  6. What is the operational difference between Skaffold and `./local/run.bash`?
Round 1 · Strong answer points
  1. Fix-forward. Standardize recovery around new corrective migrations because live rollback is not always clean.
  2. Schema feed. sqlc reads generated schema dumps, so migrations must regenerate the schema snapshot.
  3. Enforcement. A guardrail must truly run and block bad changes, not just exist in config or code.
  4. Secrets path. SOPS-backed files are decrypted in process at boot, and some DB-stored keys use a separate AES layer.
  5. One binary. Shared image/build path, runtime role selected by cobra subcommand plus config.
  6. Two local loops. Skaffold+kind+Helm is the k8s path; `run.bash` is the compose/hot-swap path.

Round 2 · Keep it correct

  1. Why does at-least-once delivery force idempotent consumers?
  2. Why is the idempotent marker timing so important?
  3. What is the difference between in-process retry and broker redelivery?
  4. Why is the outbox stronger than publish-after-commit?
  5. Why might a team still choose publish-after-commit?
  6. What is the strongest honest summary of the repo’s reliability model?
Round 2 · Strong answer points
  1. Duplicates. Brokers redeliver on doubt, so handlers must survive seeing the same message twice.
  2. Marker timing. Write only after success or non-retryable failure so retryable failures can truly rerun.
  3. Retry split. In-process retry happens inside the handler loop first; broker redelivery comes later if the message is still unacked/uncommitted.
  4. Outbox strength. It closes the dual-write gap by inserting the event in the same transaction as the state change.
  5. Publish-after-commit trade-off. It is cheaper and faster but accepts a crash gap mitigated by compensation or caller retry.
  6. Repo model. Mix of idempotency, retries, selective outbox, and deliberate compensation-based pragmatism.

Round 3 · Run the domain and review it

  1. Why is `QUEUED` not the same as “email delivered”?
  2. Why can swallowed push failures be intentional?
  3. What are the three runtime shapes in this platform?
  4. Why is a CronJob not the same thing as an in-process scheduler?
  5. How would you review whether a secrets design explanation is too shallow?
  6. How would you summarize this repo’s platform-add-ons philosophy honestly?
Round 3 · Strong answer points
  1. Email state machine. `QUEUED` means published to Kafka, not necessarily accepted or delivered to the end recipient.
  2. Push trade-off. Avoiding double-push can matter more than treating every failed token as retryable.
  3. Runtime shapes. In-gRPC-pod consumers, KEDA-scaled gjob consumer pod, and k8s CronJobs.
  4. Cron truth. Kubernetes provides the timer; the Go job runs once and exits.
  5. Secrets review. Ask where decryption happens, who can unwrap keys, and what the plaintext/compromise boundary is.
  6. Repo philosophy. Pragmatic platform engineering: use real tools, keep the story honest, and accept some consciously chosen imperfections instead of pretending every path is ideal.

Self-scoring rubric

ScoreMeaning
0I could not explain it without notes.
1I gave fragments, but the answer was incomplete or fuzzy.
2I explained the main idea, but missed the trade-off, weakness, or repo consequence.
3I gave a strong, clear answer with mechanism + trade-off/weakness + repo consequence.
Recovery map — where to go next Missed ship-it mechanics? Revisit Lessons 1–4. Missed reliability? Revisit Lessons 5–8. Missed delivery/runtime? Revisit Lessons 9–12. Missed senior judgment? Revisit Lessons 13–18.

Q1. The main rule of this mock pack is…

Retrieval first is what turns recognition into interview recall.
What are the three ingredients of a strong senior platform answer?
recall, then click to reveal
A clear mechanism, the important trade-off or weakness, and a repo-grounded consequence or example.
If you want, I can now run this as a live mock senior platform interview and grade you answer by answer. Ask me.

Sources. This pack synthesizes the whole course into retrieval practice.