Assessment · Entry diagnostic

Where should you start?

Twelve scenarios, two for each of the six judgments this course is built on. They are not a test of what you have read; each one is a decision you would make in a review. At the end you get a starting phase and a lesson number, and an honest account of how little twelve questions can prove.

Time: 25–35 minNo preparation Jump to your route

How the routing works, and what it cannot tell you

The six skills are ordered by the phase that teaches them. You are routed to the earliest skill where you did not get both questions right, and the recommendation is that skill’s home lesson.

That rule is deliberately strict, and worth arguing with. One wrong answer out of two is weak evidence — it could be a misread question. We treat it as “not yet consistent” anyway, because the two errors have very different prices: re-reading a phase you already knew costs a few hours and reinforces it, while skipping a phase you did not know costs you every later lesson that assumes it. When the evidence is thin, the cheaper mistake wins.

Three honest limits:

• Multiple choice measures recognition, not design. Picking the leaking method out of four is a much smaller act than noticing it in a repository nobody flagged. This diagnostic can tell you where to start reading; it cannot tell you what you can build.
• Later skills are not tested until earlier ones pass. If you route to Phase I, that says nothing about your architecture-driver judgment — it was measured, but the route stops at the first gap by design.
• The real diagnostic is written, not clicked. The open-response tasks in each phase assessment, scored against the rubric, are where judgment shows. Twelve buttons are the cheap first pass.

1 · Find a structural problem

Home: Phase I · Core Designer. Two questions.

A sign-up handler, three months after it was first written.

def register_user(email: str, plan: str, db: Database) -> str:
    if "@" not in email:
        raise ValueError("that is not an email address")
    user_id = db.insert_user(email, plan)
    price = 0 if plan == "free" else 1900
    StripeClient().create_subscription(user_id, price)
    SmtpMailer().send_welcome(email)
    logger.info("registered %s on %s", user_id, plan)
    return user_id

A reporting class from an internal tool.

class ReportBuilder:
    def build(self, rows, fmt, mailer, s3, logger):
        body = self._render(rows, fmt)
        s3.put("reports/latest." + fmt, body)
        mailer.send("ops@example.com", body)
        logger.info("report built")
        return body

2 · Protect a domain invariant

Home: Phase I · Core Designer. Two questions.

A subscription model and the only place its seat cap is checked.

class Subscription:
    def __init__(self, plan: str, seats: int) -> None:
        self.plan = plan
        self.seats = seats


def add_seats(sub: Subscription, extra: int) -> None:
    if sub.plan == "free" and sub.seats + extra > 3:
        raise ValueError("the free plan is capped at three seats")
    sub.seats += extra

Same subscription model.

3 · Identify a leaking boundary

Home: Phase II · System Designer. Two questions.

A repository port, as it appears in the domain package.

from typing import Protocol


class OrderRepository(Protocol):
    def find(self, order_id: str) -> Order: ...
    def save(self, order: Order) -> None: ...
    def query(self, sql: str) -> list[dict]: ...

A module inside the domain package.

# domain/pricing.py
import stripe


def charge_for(order: Order, customer: stripe.Customer) -> stripe.PaymentIntent:
    cents = order.total().cents
    return stripe.PaymentIntent.create(amount=cents, customer=customer.id)

4 · Compare an architectural trade-off

Home: Phase III · Master Designer. Two questions.

A checkout writes an order, then calls a fraud-scoring vendor. The vendor’s published p95 is 900 ms and its contracted monthly availability is 99.5%. Checkout’s own driver says 400 ms at p95 and 99.95% availability.

A shop shows a stock count on the product page and reserves stock at checkout. Both read from one replicated store.

5 · Turn a vague requirement into a quality-attribute scenario

Home: Phase IV · Initiative Lead. Two questions.

The brief says: “the returns portal must be fast and reliable.”

A draft driver reads: “If the carrier API is down, the system stays available.”

6 · Replan an initiative after evidence changes

Home: Phase IV · Initiative Lead. Two questions.

Three weeks before the pilot, research shows customers cannot tell which items are eligible; drop-off at the eligibility step is 38%. The plan assumed the policy was self-explanatory.

An accepted ADR chose a synchronous carrier call, assuming a 400 ms p95. Measurement in the sandbox puts the carrier’s p95 at 2.4 s.

Your route

Answer the twelve questions above and your route appears here.

What to do with this

Working through the code lab alongside the lessons is what turns the recognition this page measured into something you can do on a codebase. Retake this diagnostic’s harder twin, the exit diagnostic, at the end.