Recommended resources
The freely available resources this lesson will direct you to.
Hello. Last time, you built a way to distinguish an impressive result from evidence of an architectural decision: you need to know what you owned, why you chose an approach, how you evaluated it, and what you may disclose. Today, you will use that evidence map to choose prior projects worth developing into interview case studies. The aim is a shortlist, not polished stories yet. Allow about 40 minutes, including the resources and a brief private review of your candidates.
Choose a decision, not just a successful project
An architecture case study is a bounded account of a design problem. It lets an interviewer examine your judgment: the constraints you faced, the alternatives you considered, the decision you influenced, and what you learned from the result. A large initiative can supply several achievements but still make a poor case study if your decision-making role is unclear. Conversely, a smaller project can be valuable if you can explain a consequential trade-off precisely.
Use four gates when reviewing a candidate:
- Distinct problem: Can you name the engineering problem without relying on a product name or an internal document?
- Your decision: Can you distinguish what you designed or influenced from what the team collectively delivered?
- Defensible evaluation: Can you explain how the approach was assessed, including limitations or an alternative you rejected? A permitted metric helps, but an unverified metric does not.
- Usable disclosure boundary: Can you discuss enough of the problem and reasoning to make the account meaningful under your actual confidentiality obligations?
A candidate that fails the first two gates is probably an achievement or a leadership story rather than an architecture case study. A candidate that fails the fourth is not rescued by calling it “sanitized.” Set it aside for an interview case study unless an authorized review establishes a workable boundary.
The following review comes from design portfolios, but its distinction between listing tools and showing a senior practitioner’s reasoning applies well to architecture interviews.
UX Portfolio Review: Senior Product Designer's Project Under NDA
Watch “UX Portfolio Review: Senior Product Designer's Project Under NDA” from vaexperience for its treatment of abstracted work and explicit disclosure boundaries. Translate the portfolio advice to an engineering interview; do not assume a design-portfolio practice is automatically permitted for your systems.
In the disclosure explanation, notice how the reviewer wants the reader to understand what kind of account they are seeing. In the seniority review, focus on the request for contributions and reasoning rather than software-tool labels. Finish with the clearance advice: a generalized draft still warrants checking against the applicable restrictions through an authorized channel.
For your interviews, “I used Java, Playwright, and CI” identifies technologies. “I chose an execution boundary under competing runtime and diagnostic needs, then assessed whether it met those needs” could identify architectural judgment—but only if that describes what you actually did and can permissibly discuss.
Triage the projects already in view
Your experience suggests several candidates, not yet approved stories. The table separates their potential from the facts you would need to verify.
| Candidate project area | Why it may be worth an interview case study | What to verify before selecting it |
|---|---|---|
| Distributed test execution or regression-platform work | Strong fit for Principal SDET: scheduling, reliability, feedback time, and adoption can expose substantial design trade-offs. | Which bounded project produced the change; your decisions versus others’ work; comparable before-and-after evidence; what system characteristics may be discussed. |
| Java-to-Playwright modernization | Can demonstrate migration architecture and technical leadership without depending entirely on a performance metric. | Whether you set migration boundaries, compatibility or rollout criteria, and how you evaluated the chosen approach. A tool migration alone is not an architecture story. |
| AI-augmented quality engineering or retrieval-based impact analysis | Especially relevant to AI Quality Engineering Architect roles if it involved a defined decision, evaluation, and safeguards. | Whether the work was a proposal, prototype, pilot, or operating system; precisely what you owned; what quality evidence exists. Do not imply measured AI effectiveness from integration work alone. |
| Coverage growth or release-quality improvement | May show quality strategy and influence across teams. | Whether this represents a separate architectural decision or is an outcome of one of the projects above. If it is only an outcome, attach it to the appropriate case rather than creating a duplicate story. |
This is a provisional ranking, not an assumption that any internal design or figure is shareable. Start by investigating the execution-platform and modernization candidates: together they could demonstrate different forms of principal-level judgment. Investigate the AI candidate next, because its role relevance is high but its claims require particularly careful separation between using AI, designing an AI-enabled workflow, and validating its effectiveness.
Your training and mentoring work is important evidence of influence. Unless it involved a distinct technical design decision, it will usually serve better as a leadership interview story than as a standalone architecture case study. Likewise, “regression time fell” is an outcome, not a project title. Find the work and decision behind it before assigning that outcome to a case.
Avoid counting the same redesign three times under different labels. If a migration, execution-platform change, and coverage increase were parts of one initiative, either present one coherent case or separate them only where there were genuinely different problems and decisions.
Sanitize the account without inventing a new history
The useful move is to generalize the question while preserving the reasoning. A case might concern “reducing feedback time for a multi-team regression suite” rather than a named internal platform. You can then discuss permitted classes of constraints and the criteria by which you compared approaches. You must not replace restricted facts with plausible details that were never true.
“Write About UX Case Studies Without the Confidential Details” offers a concrete way to think about that distinction. Its design examples are not engineering templates; concentrate on how the author retains the method while removing project specifics.
Read Saara Kamppari-Miller’s article on Medium to see how a case study can retain its problem-solving method without displaying the underlying project or a blurred internal artifact.
Begin with the paragraph immediately before “Example Method Case Study,” starting “The first thing is to step back,” and continue through “Step 1: Up-level the Challenge, Omit the Project Details.” Read the reframing example; notice what remains understandable after the specific project is omitted. Then, under “Step 2: Create ‘Wireframe’ Thumbnails, Not Blurred Images,” start at “Now think about wireframes” and stop at the comparison question about a blurred document and a fresh wireframe. Read the visual comparison for the distinction between explaining structure and displaying a redacted original.
For an engineer, a fresh conceptual illustration might show the general responsibilities involved in coordinating test execution. It must not be a lightly renamed reconstruction of a protected topology. A blurred screenshot, copied configuration with names removed, or diagram recreated from an internal document can still disclose architecture. Build any shareable material independently and check the proposed description, diagram, and figures against the applicable rules before using them. Do not copy internal artifacts into personal notes or an external tool to prepare it.
Keep truth and permission as separate checks. “Generic” is not synonymous with “permitted”; “publicly visible product” does not make its internal implementation public. Conversely, a restriction on diagrams does not necessarily rule out a permitted verbal account of your role and decision criteria. Determine each boundary rather than guessing. An interviewer’s interest, or a promise to discuss something only privately, does not itself provide authorization.
Leave this lesson with a shortlist you can defend
For a quick private inventory, record each candidate using the same six fields:
| Field | What belongs in it |
|---|---|
| Project boundary | The specific initiative and engineering problem—not every accomplishment from a job. |
| My role | Decisions you made, decisions you influenced, and work owned by others. |
| Trade-off | At least one real competing concern or alternative you considered. |
| Evaluation | What was observed, how it was assessed, and what remains uncertain. |
| Disclosure status | Separately mark the problem description, design rationale, diagram, and metric as confirmed shareable, needing approval, or not for disclosure. |
| Interview fit | The capability this case would show for a Principal SDET or AI Quality Engineering Architect role. |
A useful selection is one primary platform case and one distinct secondary case, subject to verification and clearance. The AI-related work can become a third case if its decision, evaluation, and disclosure gates hold. If it cannot, do not stretch it into a production AI architecture claim; the independent portfolio project later in the course will give you an AI system you can demonstrate and discuss on its own terms.
At this stage, you do not need a full script. You need to know which projects survive scrutiny. For any candidate you retain, you should be able to state, in permitted terms, the problem, your decision, the alternative worth discussing, and the basis for assessing the outcome. If one of those is missing, mark it for verification rather than filling the gap with a convincing-sounding design.
Key takeaways
The best prior-work case studies are not necessarily the biggest projects or the ones with the strongest percentages. Choose bounded projects with attributable decisions, explainable trade-offs, defensible evaluation, and a confirmed disclosure boundary. Execution-platform work and modernization are promising places to look; AI-related work is promising only at the level its evidence supports. Keep achievements, leadership stories, and architecture cases distinct.
Next, you will define the independent AI quality-engineering portfolio project—an opportunity to produce inspectable architecture evidence that does not depend on access to confidential prior work.