11.4 Portfolio and cloud interviews

What this is and why it exists

The last thing this subject owes you is a way to be believed. An interviewer cannot see what you understand; they can only see what you show them and hear how you talk about it. This lesson is about making the two projects legible to a stranger, writing up one thing you actually handled, and answering cloud questions in a shape that makes your reasoning visible — including the two subjects where candidates most often sound hollow, cost and failure.

The vocabulary

• Portfolio — the small set of things you can show, with enough context to be understood without you.
• Architecture diagram — one picture showing the components, the boundaries and the direction of traffic.
• Write-up — a short account of something you did: the situation, what you found, what you changed, what happened.
• Structured answer — an answer with a visible shape rather than a list of everything you know.
• Trade-off — the thing you gave up to get the thing you chose; naming it is what makes an answer credible.
• Signal — evidence an interviewer can act on, as opposed to a description of your enthusiasm.

The mental model

A portfolio is not a list of technologies; it is two or three things a stranger can understand in five minutes. For this subject that means a public repository holding the infrastructure code for your three-tier project, an architecture diagram in the README, and honest documentation — what it is, how to deploy it, what it costs, how to remove it. The diagram does more work than any other artefact, because it lets somebody see in one glance that you understood public and private subnets, where traffic enters, and where the database sits. Keep the repository small and complete rather than large and half-finished; the reader is deciding whether you are careful, and a tidy small thing answers that better than an ambitious mess.

Then the write-up, and this is the piece most people are missing. Choose one thing you genuinely handled — an incident you diagnosed, or a cost you reduced — and write four short paragraphs: what the situation was, what you found and how you found it, what you changed, and what the result was including anything that surprised you. A page is enough. Its value is that it shows your reasoning rather than your conclusions, and reasoning is the thing being assessed. If you have not yet had an incident, make the material honestly: break your own project deliberately, diagnose it with the tools rather than by remembering what you broke, and write up that. Say plainly that it was an exercise — nobody minds, and an invented production war story is both quick to detect and the fastest way to lose a room.

Interview answers need a shape, and the same one works for nearly every cloud question. Say the answer in one sentence. Give the reason. Name the trade-off. Then say what would change your mind. That last part is what distinguishes somebody who has thought about a topic from somebody who has read about it — "I would use a managed database, because the operational load is the expensive part for a small team; I am giving up some tuning control and paying more per unit; I would reconsider if we had a database specialist and very steady load." Four sentences, and every one of them is a thing you actually learned in this subject.

The two subjects where candidates sound hollow are cost and failure, and both are fixable by specificity. On cost, do not say you are cost-conscious. Say what your project costs per month, which line is largest, and one thing you changed that reduced it — the static-site project exists partly so you have that number. On failure, do not say you learn from mistakes. Describe one, including the part where you were wrong: what you believed, what the evidence actually said, how long it took you to notice, and what you now do differently. Being able to describe your own error calmly is read as seniority, because it is the thing people who have run real systems have all had to learn how to do.

And two habits for the questions you cannot answer. Say so, immediately, and then say how you would find out — the documentation you would read, the metric you would look at, the smallest experiment that would settle it. And when a question is vague, ask what the constraints are before answering, because "it depends" is a weak answer while "it depends on whether this is steady load or bursty, and here is what I would do in each case" is a strong one.

What you should now be able to explain or do

Publish a repository a stranger can understand in five minutes, with a diagram and honest documentation. Write one page about an incident or a cost reduction you handled, showing reasoning rather than conclusions. Answer a cloud question in four parts, ending with what would change your mind. State your project's monthly cost, its largest line, and one change you made. Describe a mistake of your own, calmly and specifically. Handle a question you cannot answer without bluffing.

Check yourself