Why this matters: every LLD candidate has heard of SOLID, and interviewers know it. That's precisely why saying "I'll follow SOLID principles here" earns exactly nothing. Principles in an LLD round are not a vocabulary test — they're graded the way a driving examiner grades mirror checks: by watching whether you actually do it, at the moment it matters.

The grading direction

Here's the mechanism to internalize: the interviewer never asks "can you name the SOLID principles?" They watch your design decisions and map them back to principles afterward. The scoring runs from evidence to principle, not the other way around.

Which means the same principle can score at three levels:

• Recited: "I'll apply single responsibility." (Nothing. Anyone can say this.)
• Demonstrated: the pricing logic ends up in one class, and adding a discount later touches only that class. (Solid credit, even if you never name it.)
• Demonstrated and named at the decision: "I'm pulling pricing out of the ticket — it changes for business reasons the ticket doesn't care about, so it's a separate responsibility." (Full credit: the behavior plus the reasoning, attached to a concrete choice.)

The third form is the target. Not principle-first, and not silent — the principle arrives as the justification for a decision the interviewer just watched you make.

One refactor, several principles

Definitions don't stick; decisions do. Here's a single before/after — a report generator, deliberately not from this course's problem set — that demonstrates most of what interviewers look for.

The "before" that candidates write under time pressure:

class ReportGenerator:
    generate(data):
        rows = query_database(data.source)     # fetches
        html = build_html_table(rows)          # formats
        write_file("report.html", html)        # delivers
        send_email(MANAGERS, "report ready")   # notifies

Four verbs, one class. It works, and it's a trap: every change request lands here. New output format? Edit this class. Deliver to S3 instead of disk? Edit this class. Different recipients? Same class. Four reasons to change share one body, so every change risks every behavior.

The "after" — same behavior, seams at the change points:

class ReportGenerator:
    generate(source, formatter, delivery):
        rows = source.fetch()
        doc  = formatter.render(rows)      # HtmlFormatter | CsvFormatter
        delivery.publish(doc)              # FileDelivery  | S3Delivery

# notification is not the generator's job at all:
delivery.on_published -> notifier

Now narrate the mapping the way you would in the round:

• Fetching, formatting, and delivering change for different reasons on different schedules — separating them is single responsibility, stated as the reason for the split, not as a slogan.
• A new output format is now a new Formatter, not an edit to working code — that's open/closed, demonstrated by where the next change lands.
• ReportGenerator holds its collaborators as passed-in parts rather than being subclassed into HtmlEmailReportGenerator, CsvS3ReportGenerator, and the rest of that combinatorial family — composition over inheritance, justified by the explosion it avoids.
• Notification moved out entirely because the generator knew too much: who managers are, when to email them. Reducing what it knows about the world is coupling reduced — and each piece now does one whole thing, which is cohesion raised.

One refactor, four principles, every one of them attached to a visible decision. That's what "knowing SOLID" looks like from the interviewer's chair.

Patterns: same rule, sharper edge

Design patterns get the same treatment, with less mercy. Pattern name-dropping earns nothing — a pattern only counts when it arrives with a justification. "I'll use the strategy pattern here" is a noise; "the eviction policy is the part that varies, so it goes behind an interface I can swap — which is just the strategy pattern" is signal. The difference isn't the vocabulary, it's the direction: the problem summoned the pattern, not the reverse.

Interviewers are openly suspicious of pattern-first design, because they've watched it produce factories for classes with one implementation and visitors where a loop would do. If you name a pattern, be ready for the follow-up — "why that one, here?" — and make sure the answer talks about the problem, not the pattern.