Skip to main content

Module Quiz

Complete this quiz after finishing all concept and practice pages. Questions are scenario-based judgment calls. There are often several defensible answers; the task is to pick one and defend it.

Current Module Questions​

Question 1: Case Study Opener​

A peer shows you a draft case study whose first two paragraphs read: "This project was built using Python, FastAPI, Postgres, Redis, Docker, and GitHub Actions. The stack was chosen because it is modern and well-supported." Is this a good opening?

Answer: No. The opening tells the reader about tools, not about the problem or the outcome. A stronger opener is a one-line summary of the problem plus an outcome paragraph with at least one measured fact. Tools belong in an implementation highlight paragraph, if they are non-obvious, or not at all.

Question 2: Diagram Triage​

A case study has four diagrams: (a) a box-and-arrow architecture with no edge labels, (b) a sequence diagram for the ingestion retry path with labeled delivery semantics, (c) a tech-stack logo grid, (d) a failure-mode diagram showing what happens when Redis is lost. Which should stay, and which should go?

Answer: Keep (b) and (d) -- they carry semantics (delivery guarantees, failure boundaries) a paragraph cannot replace. Cut (c) entirely; it is decoration. Either delete (a) or add edge labels to make it load-bearing; an unlabeled architecture diagram is the weakest default in the pack.

Question 3: Tradeoff Section​

Your capstone has a Tradeoffs section that says: "We chose Postgres for its reliability. Redis was added for latency. Docker was chosen for portability." Does this section work?

Answer: No. These are not tradeoffs; they are choices without a cost. A tradeoff sentence names what you gave up. Rewrite as, for example: "Redis-backed dedupe adds operational complexity (two systems to reason about on-call) in exchange for sub-10ms read latency; at current traffic we would be fine with just Postgres, but the upgrade path is cheaper to add early than late."

Question 4: Portfolio Pin Strategy​

You have 12 repos: 2 strong capstone projects, 3 tutorial follow-alongs, 1 unfinished side project pinned for 14 months, 4 small utilities, 2 forks you never touched. Someone advises "pin all 12 so nothing is hidden." Correct or incorrect?

Answer: Incorrect. The average quality of pinned repos is read as your quality. Pin 3-5: the two capstone projects, possibly one utility if it is polished, and nothing else. Unfinished or tutorial work stays public but unpinned. The advice to pin everything confuses volume with signal.

Question 5: README Scope Disclosure​

A pinned repo claims in its README: "Fully production-ready distributed inventory system." In fact, it runs on one node, has no authn/authz, and has never been deployed beyond a local docker-compose. What is the risk?

Answer: The claim will collapse on the first five minutes of reviewer scrutiny and poison trust in everything else in the repo. Rewrite as specific, honest scope -- e.g., "Single-node reference implementation with idempotent ingestion; authn is out of scope; deployed locally only." Honesty is both ethically correct and strategically better; reviewers read specific limits as a signal of engineering judgment.

Question 6: Commit Message Audit​

A reviewer scans the last 20 commits on main. Ten read "fix", three read "wip", four read "updates", and three have meaningful sentence-form messages. What will they infer, and what is the fix?

Answer: They will infer careless practice regardless of code quality, because craft signals are how they calibrate the source reading. The fix is (a) writing meaningful commit messages going forward, and (b) using PR-level squashed merges so the history on main reads like a changelog. Do not rewrite published history solely for appearance; change the practice going forward and rely on PR titles to carry the narrative.

Question 7: Bio Voice Mismatch​

A candidate's GitHub bio says: "Distributed systems engineer specializing in large-scale backend architecture." Their pinned repos show three CRUD apps and one tutorial follow-along. What is the problem?

Answer: The bio and the evidence disagree. A senior reviewer will downgrade trust in both. The fix is to either (a) rewrite the bio to match the evidence ("Backend engineer currently digging into distributed systems; capstone is…") or (b) change the evidence by shipping one real distributed artifact before updating the bio. Pick (a) today and revisit after the next artifact ships.

Question 8: Blog Cadence​

You have not blogged in 18 months and feel guilty. You consider writing four posts in two weeks to catch up. Is this a good idea?

Answer: No. A burst of hurried posts tends to produce weak, tutorial-style content and signals catch-up behavior. Start with one post tied to a real piece of capstone work, using the four-part skeleton. Ship it. Put the next one on the calendar for the following quarter. Cadence compounds; guilt does not.

Question 9: Editing Test​

Read: "It's worth noting that in many cases, one of the key considerations that often comes up is the question of how best to handle idempotency across multiple diverse upstream data sources." (31 words). Rewrite it to under 15 words without losing information.

Answer: "Handling idempotency across multiple upstream feeds is the main design decision." (11 words). The original is 95% hedge and 5% content; the rewrite keeps the content.

Question 10: Specialization by Market​

Your strength grid shows you strongest in backend (4) and weak in ML/data engineering (1). A friend says "data is the hottest market, just pivot." You have four months to graduate. Best move?

Answer: Do not pivot specialization based on market alone with four months remaining. Pick the track with the best combined rubric score (likely backend here, with distributed or infra as the adjacent track). Add "learn enough data engineering to contribute on a mixed team" to the gap list with a concrete first step. Revisit the rubric at 12 months post-graduation; if the data market is still compelling and strength has grown, re-pick then.

Question 11: Rubric Tie​

Backend scores 11; distributed scores 12 (higher interest, equal market, slightly lower strength). You choose backend "to be safe." Is this defensible?

Answer: It is defensible if you can articulate why your strength evidence materially trumps the interest gap. If the real reason is risk aversion, the pick is fragile -- a year of backend work without matching interest tends to stall. A better move is usually to pick the interest-pulled track as a stretch with backend as the supporting adjacent, unless you have a specific job in hand that requires the safer pick.

Question 12: Feynman Failure Mode​

You write a Feynman explanation of database isolation levels. It defines serializable, repeatable read, read committed, and read uncommitted -- but never mentions a scenario where the choice matters. Is the packet ready to ship?

Answer: No. It is missing the concrete example, the tradeoff, and the failure mode -- three of the four required parts of a Feynman explanation. The explanation is a textbook excerpt, not a Feynman explanation. Add: one specific scenario where isolation matters (e.g., double-charging under read-committed), the tradeoff (throughput on hot rows), and the production failure mode (finance report drifts silently).

Question 13: Hostile Question​

In mock defense, the interviewer asks: "You chose Raft instead of Paxos. Isn't that just trend-chasing?" You freeze. What is the ideal-shape answer?

Answer: Restate ("you're asking whether my choice is principled or fashionable"), then give the reason ("Raft's explicit leader election and log-matching invariants were easier for me to reason about and verify with tests, which mattered because I'm the only one on-call"), acknowledge the alternative ("Paxos / Multi-Paxos is more general and would matter if I needed reconfiguration flexibility"), and name what would change your answer ("if I had a production system with dynamic cluster membership, I'd reconsider"). Structure defuses hostility; defensiveness inflames it.

Question 14: Gap List Audit​

Your gap list reads: "I want to learn more about AI, cloud, leadership, and databases." Is this a usable gap list?

Answer: No. Every entry is a topic area, not a specific gap. Usable entries are concrete ("I have never run a distributed DB in production"), track-relevant ("matters because my chosen track is distributed"), and have a first step ("run 3-node CockroachDB locally, cause a partition, observe, write 500 words"). Rewrite all four entries in that three-part form.

Question 15: What "Done" Looks Like​

Your portfolio has: case study, organized profile, pinned repos, bio, 12-month plan, gap list, Feynman packet. But you have not delivered a live defense. Is the module complete?

Answer: No. Writing is forgiving; speaking is not. The live defense is where the gaps light up, and the whole point of the module is to find and close those gaps before interviews begin. Schedule and run the 10-minute defense with a peer this week. Then, and only then, sign off on the module.

Interleaved Review Questions​

Prior Module Question 1 (S10 M04)​

Your capstone has a runbook. A reviewer asks: "has this runbook ever been executed?" If the answer is no, what should you do before graduation?

Answer: Execute it at least once in a non-trivial scenario -- a simulated database failover, a known bad deploy rollback, or a deliberately induced incident. An unused runbook is a hypothesis; an executed runbook is evidence.

Prior Module Question 2 (S8 M05)​

A design doc you wrote six months ago opens with three paragraphs of background before stating the proposal. Is that the right structure?

Answer: No. The proposal and its motivation should be in the first 150 words. Background belongs later, for readers who need it. Written-first culture optimizes for the reader's attention budget.

Prior Module Question 3 (S7 M05)​

An ADR you wrote states the decision but omits the "consequences" section. Is it usable?

Answer: Barely. The consequences section is the forcing function for honesty -- it is where tradeoffs become visible. Without it, the ADR is closer to a design note. Add consequences before relying on the ADR in a portfolio reading.

Prior Module Question 4 (S6 distributed systems)​

You claim "exactly-once delivery" in a case study. A senior engineer raises an eyebrow. Why?

Answer: Exactly-once delivery end-to-end is not achievable in general distributed systems; typical architectures offer at-least-once delivery with idempotent processing, which is functionally equivalent if the application is correct. Rephrase to reflect the actual guarantee.

Prior Module Question 5 (S4/S5 systems and databases)​

Your case study claims "ACID guarantees" but you used read-committed isolation. Is the claim fine?

Answer: The "I" in ACID (isolation) is a dial with several settings. "ACID guarantees" without naming the level is imprecise. State the actual level and what that gains you versus stronger or weaker settings.

Self-Assessment and Remediation​

Scoring Bands​

Mastery Level (13-15 + 4-5 prior correct):

  • Status: portfolio, decision, and defense artifacts are graduation-ready.
  • Action: schedule the mock defense if not yet done; ship the 12-month plan.

Proficient Level (10-12 + 3-4 prior correct):

  • Status: substantive but uneven.
  • Action: identify the questions you got wrong; revisit the specific concept page (e.g., Q2 -> Cluster 1 concept 03; Q9 -> Cluster 3 concept 09). Revise the corresponding portfolio artifact.

Developing Level (7-9 + 2-3 prior correct):

  • Status: structural gaps in portfolio thinking.
  • Action: rework the practice pages in order (01 -> 02 -> 03). Do not skip Practice 04. Re-take the quiz after a week.

Insufficient Level (< 7 + < 2 prior correct):

  • Status: the module has been skimmed, not worked.
  • Action: restart from the module index. Do each cluster's concepts sequentially. Produce the drill outputs, not just read the pages. Re-take after all four practice pages are complete with their Evidence Check boxes ticked.

Remediation Map (by missed area)​

  • Case study weakness (Qs 1-3) -> revisit Cluster 1, redo Practice 01.
  • Portfolio weakness (Qs 4-6) -> revisit Cluster 2, redo Practice 02.
  • Voice / editing weakness (Qs 7-9) -> revisit Cluster 3; edit an existing artifact to half its length.
  • Decision weakness (Qs 10-11) -> revisit Cluster 4, refill the rubric; have a peer challenge it.
  • Defense weakness (Qs 12-15) -> revisit Cluster 5, run Defense Katas 1 and 3.