Drills 53 to 60: patterns, seasonality and the interview itself

Eight drills, ninety seconds each, out loud. This is the most heterogeneous batch: three are architecture-pattern questions, two are dependency and vendor arithmetic, and three are about the interview process itself.

What unites them is that each has a specific committed position available, and the failure mode in all eight is answering with a survey of considerations. "It depends on your situation" is the weakest possible answer to every one of these, and each has a defensible line you can take.

Drill 53. Explain the repository pattern, then argue against it here.

It presents a collection-like interface over persistence so the domain can ask for aggregates without knowing where they live. The important word is aggregate: one repository per aggregate root, not one per table, and that distinction is what separates it from a DAO. The value is that if the only way to load an Order is through the repository, an Order is always loaded whole and its invariants stay enforceable.

Against it here: my ORM already is one. SQLAlchemy's Session is a Unit of Work and its query interface is a repository, so wrapping it produces a forwarding layer we maintain forever.

And it leaks on exactly the properties that matter. The interface says find_by_customer, and it says nothing about whether that's five rows or five million, whether it's indexed, whether it N+1s, or whether it holds a lock. Those decide whether the system works, and the abstraction is silent on all of them, so the leaks show up as production incidents rather than compile errors.

It also obstructs the database we're paying for: window functions, CTEs, INSERT ON CONFLICT, FOR UPDATE SKIP LOCKED. Teams then add execute_raw_sql to the repository and the abstraction has formally surrendered.

So my test is whether there's an invariant that would be violated if code could load a partial version of the thing. Order with line items and a cancellation rule: yes, and I've seen an incident from exactly that. A reporting endpoint producing a screen: no, that's a query object. And in one codebase I'd usually have both, repositories on the write side and query objects on the read side.

Depth signal: naming what the abstraction is silent about, and giving a test rather than a preference.

Full treatment: The repository pattern.

Drill 54. "Is CQRS a good idea for us?" Walk the adoption ladder.

It's four different questions, because CQRS is a ladder and almost everyone asking is imagining the top rung and needs the bottom one.

Rung one is separate command and query handlers: hours, no infrastructure. Rung two adds separate read models against the same database: days. Rung three is a separate read store updated in the same transaction: weeks. Rung four makes projections asynchronous: months, and it permanently changes consistency.

In a case I worked, the team asked for CQRS with event sourcing after a conference talk. Splitting the handlers took an afternoon and moved p99 from 2.4 seconds to 310 milliseconds, because the real problem was lazy loading on the aggregate rather than anything architectural. A dedicated read DTO took it to 95. At that point the original complaint was gone, and what remained was a read replica for reporting and a search index, which are two different answers.

Rung four is a product decision rather than an engineering one. "Can a customer place an order and not see it in their order list for two seconds" is answered by whoever owns the customer experience, and deciding it myself because the architecture is more elegant is making a product change without authority.

And I'd separate event sourcing explicitly, because the conflation is why teams think this costs months. They're independent, and most teams asking for event sourcing want an audit trail, which an append-only audit table gives without making replay the system's recovery path.

Depth signal: measuring after each rung, and rung four as a product decision.

Full treatment: CQRS: the adoption ladder.

Drill 55. Our vendor offers 99.5 percent and we sell 99.9 percent. Options?

If that vendor is on the critical path, we cannot sell 99.9 percent. Their unavailability multiplies into ours, so our ceiling is at best their 99.5, and lower once our own dependencies are included. That's arithmetic, so the conversation should start there rather than with engineering effort.

Four options, in order of how much they buy.

Take the vendor off the critical path. Can we degrade when they're down? If the request succeeds without them, with reduced functionality, their availability stops multiplying into ours. This is almost always the highest-value option and it's usually a fallback plus a cache, so days rather than quarters.

Add a second vendor. Combined availability is one minus the product of unavailabilities, so two at 99.5 is theoretically 99.9975. That number is almost certainly wrong, because it assumes independence: if both depend on the same upstream, or we deploy the integration for both from the same pipeline, the correlated fraction dominates. At ten percent correlation, two 99.5s give about 99.95, not 99.9975.

Cache aggressively with stale-if-error, so a vendor outage serves last-known-good rather than failing. Whether that's acceptable depends entirely on what the data is.

Or renegotiate the SLA we sell, which is the honest option and sometimes the right one, and it's better raised now than discovered at the first breach.

The thing I'd do first regardless is compute the current ceiling across every critical dependency, because the finding is often that the SLO was never achievable and we've been treating a planning error as an execution problem.

Depth signal: the independence correction on the two-vendor option, and computing the ceiling before proposing work.

Full treatment: Composite SLOs and dependency math.

Drill 56. A question you genuinely cannot answer. Perform the sequence.

Four steps, and the first one fast.

"I don't know that one." Plainly, in three seconds, because hedging around a gap for thirty seconds is worse: it reads as an attempted bluff that failed, and the interviewer has watched me decide whether to try it.

Then what I do know that's adjacent, because almost nothing is genuinely disconnected. "I haven't used Cassandra, but I've worked with DynamoDB, and I'd expect the partition key considerations to be similar because both derive the key schema from access patterns rather than from entities."

Then reason toward an answer and label the reasoning as reasoning. "So my guess would be X, and here's why. I'd want to verify that." That label is what separates it from a bluff, and without it the same words are scored as a confident assertion.

Then how I'd find out, specifically. Not "I'd look it up" but which document and what experiment, because the verification instinct is part of what's being assessed.

And the reason to do it this way rather than bluff: bluffing is retroactive. It's detected in one follow-up, the question fails, everything before it gets re-examined as a possible bluff, everything after is heard sceptically, and the note says "confidently wrong". One bluff costs more than three admissions.

Depth signal: the labelling of reasoning, and the retroactive cost of bluffing.

Full treatment: Handling what you do not know.

Drill 57. Ninety seconds with the CTO at the end of the loop. What do you ask?

Three questions, not five, and ones I actually want answered.

"What's the thing you'd most want fixed in engineering that you haven't been able to fix yet?" That's the best one: hard to deflect, the answer is genuinely useful to me, and asking it signals I expect a real organisation with real constraints rather than a brochure. A leader who can't name one is either not close to engineering or is selling.

"What does a staff engineer here do that a senior one doesn't?" Direct, and their answer tells me whether the level is real or a title.

And a business-framed one: "where does the company need to be in eighteen months for this to have been the right bet?" That tells me whether the strategy is coherent, and whether it matches what the earlier interviewers said.

That last point is what I'm actually doing in that room. The consistency check across the loop is the most reliable organisational signal available anywhere in the process: if the CTO's account of priorities differs from what the hiring manager and the engineers told me, that gap appears nowhere else and it's free to observe.

And what I'd avoid: anything answerable from the careers page, anything about compensation, and having no questions at all, which reads as indifference and wastes the one round where I can actually learn something.

Depth signal: the consistency check as the real purpose, and knowing that three beats five.

Full treatment: Ninety seconds with the CTO and Reverse due diligence.

Drill 58. Rewrite one of your SCOR stories as STAR on the spot.

The mapping is mechanical, and I'd say it out loud before telling it, because it shows I know what's being scored.

Situation compresses to two sentences. The Complication becomes the Task, restated in first person as what I was responsible for, because STAR scores individual contribution as its own field and SCOR leaves it implicit. The Options move to the front of Action, one sentence per option with its cost, and I keep all of them, because that's where the decision-making shows and it's the part that disappears in a naive conversion. The Resolution splits: what I did goes in Action, what happened goes in Result.

Two things I add that SCOR left out. An explicit sentence about what was mine to decide. And converting "we" to "I" for the decisions while leaving "we" for the team's work, which isn't about credit, it's that the rubric has a field for individual contribution and leaving it empty scores as empty.

And what does not change: the numbers. Four thousand queries a second, 180 to 1,400 to 210 milliseconds, two days to find it. Those are the story, and an interviewer who's heard the SCOR version and hears different figures in the STAR version notices immediately.

Depth signal: keeping the Options section through the conversion, and the numbers staying identical.

Full treatment: SCOR, STAR and the scar-tissue story.

Drill 59. Three red flags from the reverse-diligence list, and the questions.

First: nobody can name a decision that was reversed. I'd ask "what's a technical decision the team made and then changed their mind about, and what changed it?" An organisation where nothing is ever reversed either doesn't revisit decisions or doesn't admit to it, and both mean I'd be arguing against sunk costs constantly.

Second: the on-call story is vague. I'd ask "how many pages did the person on call last week get, and what fraction were actionable?" A specific number means someone measures it. "It's not too bad" means nobody does, and an unmeasured on-call load is usually a bad one.

Third: engineering and leadership describe priorities differently. I'd ask the same question in several rounds, "what are the top two things the team is working on and why", and compare. A gap means the strategy isn't communicated internally, which is a much bigger problem than any individual technical choice, and it's the single most reliable signal available because it costs nothing to observe.

And a fourth if there's time: ask about the last incident. "What was the most recent significant incident and what came out of it?" An organisation with a real postmortem culture answers specifically and without defensiveness. One that gets uncomfortable is telling you how failure is treated, which is what you're actually asking.

Depth signal: the cross-round consistency check, and using the incident question as a proxy for blame culture.

Full treatment: Reverse due diligence.

Drill 60. A 30-second scar-tissue story that fits inside a caching answer.

"We learned that one the hard way. We had a fifteen-minute TTL on a popular-products query, and when it expired at peak roughly nine hundred requests hit the origin in the same second and took the database to a hundred percent CPU for about forty seconds. What fixed it was a lease, so one request regenerates and the rest serve the previous value. That's why I always ask what happens at expiry rather than what the hit rate is."

That's twenty-eight seconds. The shape is three sentences: what we did, what went wrong with a number, and the specific thing we do now. And it ends by returning to the technical point, which is what stops it being a digression.

The properties that make it work: it contains a number only someone who watched the graph would know, forty seconds at a hundred percent CPU, which is the difference between a memory and a description. It's a failure rather than a success, because a success embedded in a technical answer reads as self-promotion and a failure reads as experience. And it's short enough that the interviewer doesn't have to steer me back.

And I'd use three or four of these across a whole interview, not one per answer, because one per answer becomes a tic and starts sounding rehearsed, which undoes the entire benefit.

Depth signal: the three-sentence shape, and knowing the frequency limit.

Full treatment: SCOR, STAR and the scar-tissue story.

How to practise these

This batch is the most varied and the practice is correspondingly specific: for each one, write down the single sentence you would commit to, because the failure mode across all eight is surveying considerations instead of taking a position.

53  "My test is whether an invariant would be violated if
     code could load a partial version of the thing."
54  "Rung four is a product decision, not an engineering
     one."
55  "If that vendor is on the critical path, we cannot sell
     99.9 percent. That's arithmetic."
56  "One bluff costs more than three admissions."
57  "The consistency check across the loop is the most
     reliable signal available."
58  "The numbers don't change between tellings."
59  "A gap between what leadership and engineers say about
     priorities is bigger than any technical choice."
60  "Three sentences, one number, and return to the point."

Three tests for your own answer:

1. Did you commit to a line? Every one of these has a defensible position. "It depends" without naming the variables and a default is the weakest available answer.
2. For the technical ones, did you give a number? 2.4 seconds to 310 milliseconds. 99.5 times 99.5 with a ten percent correlated fraction giving 99.95 rather than 99.9975. Forty seconds at a hundred percent CPU.
3. For the interview ones, did you say what you would actually do rather than what one should do? "I'd ask the same question in three rounds and compare" is a practice. "It's important to evaluate culture" is not.

And the observation across the batch: three of these eight are about the interview itself, and they are scored exactly like the technical ones. A candidate who has thought carefully about how to evaluate an employer is demonstrating the same judgement they would apply to a vendor, an architecture or a hire, and interviewers read it that way.