Craft, Collaboration & Judgment

The question behind the questions

Scattered across a mid-level loop — in behavioral rounds, in coding follow-ups, in design probes — one question keeps resurfacing in different clothes: "how did you know it worked?" A junior can answer "it worked" and survive; a mid-level candidate is probed on the how and must answer with mechanism. This lesson covers the three signal families that question feeds: craft, collaboration, and judgment.

Craft: verification as a habit, not an event

Mid-level candidates are expected to talk fluently — with specifics from their own work — about four practices:

Testing strategy. Not "we had tests" but which tests and why: "The retry logic got property-based tests because the bug space was combinatorial — timing crossed with failure type. The API layer got contract tests since two other teams consumed it. I skipped UI-level tests for the internal dashboard; the maintenance cost wasn't worth it there." The signal is that test effort was allocated by risk, which is a decision, not a chore.

Code review. Both directions. What you look for when reviewing ("correctness first, then whether the change makes the next change harder — naming and structure last"), and how you receive review ("my rule is that a reviewer confused by my code has found a bug in the code, not in themselves").

Observability — the practice of instrumenting systems so you can tell what they are doing in production, via logs, metrics, and traces. The mid-level tell is shipping with verification built in: "Before the rollout I added two metrics — retry-success rate and duplicate-charge count. That's how I knew the fix worked: duplicates went to zero within a week, and I could show the graph." A candidate who can produce the graph, so to speak, for their own past claims stands out immediately — because the interviewer's follow-ups keep landing on solid ground.

Rollout discipline. Flags, staged percentages, watching dashboards during the ramp, a rollback plan stated before the deploy. "I rolled to 5%, watched error rates for two days, then ramped" is a sentence that quietly carries an entire maturity level.

In coding rounds, the same craft shows up live: tracing your own code before being asked, naming things well under time pressure, mentioning what you would test. The story and the live behavior should corroborate each other.

Collaboration: the emerging-mentor signal

The mid-level collaboration bar is emerging mentorship and team leverage — more than executing alongside others, less than setting multi-team direction (that is senior). Interviewers look for concrete examples of four behaviors:

1. Unblocking teammates. "A teammate lost two days to our flaky integration environment; I paired with him for an hour, found the port collision, then fixed the env setup script so it couldn't recur." Note the shape: helped the person and removed the class of problem.
2. Reviewing others' code substantively — being someone whose review teammates seek out, not just a rubber stamp in the rotation.
3. Improving team process. A CI speedup, a runbook, an onboarding doc, a meeting killed. Quantify: "cut CI from 25 minutes to 9, which the team hits about 40 times a day."
4. Influence across one team boundary. "I convinced the platform team to add an idempotency header to their gateway by bringing three concrete incidents it would have prevented" — influence with evidence, across a boundary, without authority.

Calibration matters in both directions. No mentorship examples at all reads junior. But claiming you "set technical direction for three teams" invites senior-level follow-ups you may not want; the honest mid-level frame — "I'm the person juniors on my team come to first, and I ran onboarding for our last two hires" — scores better than inflated scope, because it survives drilling.

Judgment: articulating the why

The final signal is the ability to explain why you chose an approach — demonstrating decision-making rather than execution. Interviewers probe this constantly: "why that database?", "why didn't you just use the existing service?", "would you make the same call again?" A mid-level answer has three parts: the options you saw, the reason you chose, and the honest retrospective.

"Build vs buy came up for our feature-flag system. I evaluated a vendor against building on our config service: the vendor was faster to adopt but per-seat pricing got ugly at our growth rate, and we needed flag evaluation inside a latency budget the vendor's SDK couldn't guarantee. I chose to build a thin version — two weeks — deliberately skipping the vendor's targeting features until someone actually asked for them. A year later: right call on latency and cost, but I underestimated maintenance; if I redid it, I'd still build, but I'd have assigned an owner from day one instead of letting it be everyone's side job."

The last clause is what separates the answer: "what I'd do differently" delivered unprompted and specific. Candidates who cannot name anything they would change read as either inexperienced or unreflective; either way, not yet trusted with the next ambiguous decision — and being trustable with ambiguous decisions is the entire level.

The new judgment question: your AI workflow

Since 2025–2026, one judgment probe has become standard for mid-level candidates: "how do you use AI tools in your work?" Day-one fluency with tools like Copilot, Cursor, or Claude is increasingly assumed as baseline, and the question is scored like any other judgment question — options, reasons, limits. A strong shape:

"I delegate boilerplate, test scaffolding, and first-draft comprehension of unfamiliar code. I keep design decisions and anything touching money or auth fully manual. Everything generated gets read and tested before it lands — I've caught enough plausible-but-wrong output to treat review as non-negotiable. Where it fails me: subtle concurrency and anything where our internal conventions differ from the public norm, so those I write myself."

What makes it strong is the same thing that makes every answer in this lesson strong: a deliberate division of labor, verification as a habit, and known limits stated plainly. The tools are new; the bar they are measured against — you run your own work, and you know how you know it works — is the same bar this whole module has been describing.