Building a Portfolio & Passing Technical Interviews (Cloud/DevOps/AI Roles)

You started this course at “what is a program.” You can now write Python that holds up in production: typed, tested, packaged, containerised, deployed. You have built an ML service and designed a scalable system. The skill is real.

None of that gets you hired by itself. A hiring manager cannot see your skill — they can only see the evidence of it, filtered through a resume, a GitHub page, and four or five interview rounds designed to find reasons to say no. This final lesson is about the evidence: how to build a portfolio that proves what you can do, and how to walk the interview gauntlet without dropping off at the two places strong candidates silently fail.

There is no code to run here. Instead there are artifacts — a README template, a repo layout, resume bullets, behavioural answers, a prep plan — that you will copy, fill in with your own work, and use this month. Interviewing is a skill like any other in this course. It is learnable, it is drillable, and by the end of this lesson you will have the kit to start.

---

Why this matters: proof beats claims

Here is the asymmetry that governs everything. A resume says “experienced with CI/CD and infrastructure automation.” A GitHub repo says here is a tool I built that provisions infrastructure, here is the test suite, here is the green CI badge, here is it running in a two-line demo. One is a claim. The other is proof. Every hiring decision is a bet under uncertainty, and proof lowers the perceived risk of betting on you.

This matters most for exactly the people reading a Zero-to-Hero course: career changers, self-taught engineers, new graduates, anyone without a big-name employer on the resume to borrow credibility from. You cannot say “trust me, I did this at Google.” You can say “here is the thing, run it yourself.” A portfolio is how someone with no pedigree out-competes someone with a mediocre one.

That last row is the whole point. A portfolio shifts the competition from where have you worked to what can you build — and that is the field you can win on.

---

The portfolio that gets you hired

What makes a project impressive

Not all projects generate signal. A hiring manager skimming your GitHub for ninety seconds is asking one question: does this person build real things the way we build real things here? A todo app built by following a tutorial answers “no” — not because todo apps are bad, but because it demonstrates you can follow instructions, which is not the skill being hired for.

The projects that generate signal share five properties. Miss them and the project is noise; hit them and a single repo can carry an entire application.

Those five map directly onto lessons you have already done in this course. Tested + CI is the testing lessons and the CI/CD Integration lesson made visible on your GitHub. Documented and runnable are the packaging lesson’s README, entry points, and pip install story. Your portfolio is not new work — it is your course work, finished to a standard a stranger can trust.

The single sharpest distinction a reviewer draws is tutorial-clone versus portfolio-grade, and it is worth making explicit because it is the difference between a project that helps you and one that quietly hurts you:

If you can explain why you made each decision, it is yours. If you can only explain what the code does, it is the tutorial’s. Interviewers probe exactly this seam.

Quality over quantity: three strong beats ten toy

The instinct is to pad the profile — ten repos looks busier than three. It reads worse. Ten shallow projects say “I start things and abandon them at the tutorial’s end.” Three finished, deployed, documented projects say “I ship.” A reviewer’s time is finite; they will judge you on your best repo and your worst pinned repo, and rarely on the count.

Pin three. Make each one finishable and finished. Archive or unpin the rest — a graveyard of half-built repos is worse than an empty profile, because it shows a pattern of not-finishing, which is the exact fear a hiring manager has about a junior hire.

Project ideas mapped to the role

The best portfolio project sits at the intersection of a real problem, the role you want, and the skills this course gave you. Below are concrete, non-generic ideas per track — each one ties back to a lesson you have already done, so it is buildable, not aspirational. Pick the row that matches the job title on the posting.

Two rules for choosing. First, pick the role’s core competency, not a side skill — a Cloud role wants to see you touch cloud APIs, not a beautiful React frontend. Second, pick a problem you actually understand, because the interview will drill into your decisions and you cannot fake having cared. The cost reporter above is the example project we will document, test, and turn into a system-design answer for the rest of this lesson.

---

Making a project shine

You have a good project. Now make it legible — because an unread project generates zero signal, and the reader gives you ninety seconds to earn the next ten minutes.

The README is the highest-ROI thing you will write

Nothing else in your portfolio has a better effort-to-payoff ratio than a good README. It is the first thing a reviewer sees, it renders on GitHub and on PyPI, and for most visitors it is the only documentation they read. A brilliant project with a one-line README loses to a decent project with a great one, because the reviewer never learns the first one is brilliant.

A README has exactly one job: answer, in order, the questions a stranger actually has — and answer the first one above the fold, before they scroll.

The commonest README failure is not being too short — it is opening with a wall of badges and an architecture essay while never once showing the tool run. The load-bearing element is the demo: a GIF of the CLI printing output, or a screenshot of the running app. A demo is a demonstration; an example without output is just another claim.

Here is a complete, reusable README template. Copy it, delete the guidance in brackets, fill it with your project. It is the same skeleton the cost reporter uses in the lab.

# project-name

[![CI](https://github.com/you/project/actions/workflows/ci.yml/badge.svg)](…)
[![PyPI](https://img.shields.io/pypi/v/project.svg)](…)
[![License: MIT](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)

**[One sentence: what it does and who it's for. Bold. Above the fold.]**

[2–3 sentences: the problem this solves and why the obvious alternative is
annoying. Honest about scope — say what it does NOT do.]

![demo](https://raw.githubusercontent.com/you/project/main/docs/demo.gif)

## Quickstart

​```bash
pip install project
project do-the-thing --flag value
​```

​```text
[The REAL output of that command. This block sells the tool.]
​```

## Why [project]

- **[Benefit 1]** — [one line]
- **[Benefit 2]** — [one line]
- **[Benefit 3]** — [one line]

## Installation

[pip / pipx / docker. Note any credentials or prerequisites — and where they're
read from, so nobody has to guess.]

## Architecture

[A 4–6 line ASCII sketch or one diagram. Show the data flow, not every class.]

## Design decisions

| Decision | Why | Trade-off |
|---|---|---|
| [what you chose] | [the reason] | [what it costs] |

## Development

​```bash
git clone … && cd project
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
pytest && ruff check . && mypy src
​```

## License

MIT — see [LICENSE](LICENSE).

The ## Design decisions table is the part that separates a portfolio README from a normal one. It pre-answers the interview question “why did you build it this way?” in writing — which both impresses the reader and rehearses you for the conversation.

Clean git history

A reviewer who is genuinely interested will read your commits. What they find tells them how you will behave on their team — because on their team, the commit log is how humans understand each other’s changes. A history of fix, fix2, asdf, final fix says you will make their git blame useless. A history of clear, scoped, imperative-mood messages says you are a considerate collaborator.

You do not need to rewrite years of history. Start clean on the project you are about to pin, use Conventional Commits style (type(scope): summary), and never commit a secret — a leaked key in history is permanent even after you “remove” it, and a reviewer who spots one will assume you will leak theirs too.

Tests, CI, and the green badge

A CI badge in your README is a claim you can back up with one click: this code is tested, and the tests pass right now, on a clean machine that isn’t mine. It is the single most efficient trust signal a repo can carry, because it refutes “works on my machine” before the thought forms.

This is your CI/CD Integration lesson made visible. A .github/workflows/ci.yml that runs ruff, mypy, and pytest across a couple of Python versions turns your test suite into a badge, and the badge into a reason to trust you. The lab builds exactly this file.

A live demo, and a short writeup

“Deployed” beats “runnable” beats “here’s the source.” The further right you land, the more real the project feels — and real is the entire currency.

A live URL for a web project, or an asciinema/GIF for a CLI, converts a skeptic in one click. And a short writeup — “why I built X, what was hard, what I’d do differently” — is disproportionately powerful: it demonstrates communication, it is linkable from your resume, and it seeds the exact stories you will tell in the behavioural round. It need not be long. Five hundred honest words about one real difficulty beat a polished essay that never admits anything was hard.

---

Your GitHub profile and online presence

The individual repos are the substance; the profile is the storefront. A reviewer lands on github.com/you before they land on any single repo, and the first screen decides whether they keep reading.

A word on the contribution graph, because it induces real anxiety. Green squares are a weak signal, and hiring managers know it. A sparse graph with three excellent pinned projects beats a solid-green graph of trivial commits. Do not manufacture activity — reviewers can tell, and a graph of obviously padded commits is a negative signal about your judgement. Contribute to open source because it makes you better and gives you real PRs to point at (the OSS contribution lesson covers how to find a first issue and land it), not to colour in a calendar.

The profile README is the highest-leverage and most-skipped element. It is a README.md in a repo named exactly after your username, and GitHub renders it at the top of your profile. Three short paragraphs — what you do, what you are proud of (link the pinned repos), how to reach you — turns a blank page into an introduction.

The resume: quantify or it didn’t happen

Your resume gets six to eight seconds on the first pass. In that window, the reader is scanning bullets for impact, and impact means numbers. A bullet without a number is a job description; a bullet with a number is an accomplishment. The transformation is mechanical: action verb + what you built + a measured result.

Do not have a number handy? Estimate honestly and say so — “reduced manual work by roughly a day a week” is fine and far stronger than “responsible for automation.” The number does not need three-decimal precision; it needs to communicate scale. And crucially, every number on your resume is an invitation to a question — “how did you measure that 45 to 6?” — so put nothing there you cannot walk through. A quantified bullet you can explain is your best friend in the room; one you can’t is a trap you set for yourself.

For projects with no employer behind them, the same rule holds: “Built X that does Y, handling Z requests/records, with N% test coverage.” Scale, coverage, adoption, time saved — pick the honest metric and lead with it.

LinkedIn and the STAR method

LinkedIn is where recruiters find you, so it is a discovery tool, not a second resume. A few things move the needle; most do not.

The single most valuable interview-prep concept, though, is not a platform — it is a format. STAR structures a behavioural answer so it lands in ninety seconds instead of rambling for five minutes. Every strong behavioural answer has four parts:

The mistake candidates make is living in S and T — setting up context forever and never getting to what they did. The Action is the answer; the Result is the proof. We will write two full STAR answers in the lab.

---

The interview gauntlet

An interview process is not one event — it is a pipeline of filters, each testing a different thing, each able to reject you independently. Knowing the shape of the pipeline is half the battle, because it lets you prepare the right thing for the right stage instead of over-indexing on the coding round and getting blindsided by the behavioural one.

Read this pipeline left to right. Your portfolio and presence get you into it; the rounds are the filters; the two red badges mark where strong candidates drop off for reasons that have nothing to do with ability — a demo-less repo that never earns a callback, and an unprepared behavioural round that sinks a great engineer at the final stage. The last round forks by role.

The six badges are the lessons of the whole pipeline: a weak README silently kills a strong project (1); quantified bullets beat claimed ones (2); the coding round rewards patterns narrated out loud (3); system design tests judgement, not a single right answer (4); skipping behavioural prep fails strong engineers at the last hurdle (5); and the final round forks by the role you actually want (6).

The stages, and what each one is really testing

You can be strong on four of these and get rejected on the fifth. The rejections that sting most are the avoidable ones: a brilliant coder who never prepared a single behavioural story, or a great communicator who did zero DSA drilling. Prepare across the whole pipeline, weighted toward your weak stages.

Round 1: the recruiter screen

Fifteen to thirty minutes, usually non-technical, and its real purpose is to filter out the obviously-unfit before an engineer’s time is spent. It feels casual; it is a gate. Three things sink candidates here: not being able to say what they want, fumbling the compensation question, and being unable to summarise their own background crisply.

Do your compensation homework before this call — know the market rate for the role and location, and have a range ready. “I’m looking in the X to Y range, and I’m flexible depending on the whole package” keeps you in the game without lowballing yourself.

Round 2: the coding round

An engineer, a shared editor, one or two problems, forty-five minutes. This is the round with the most preparation material in the world, and the one candidates most misunderstand. It is not testing whether you can memorise algorithms — it is testing data-structure fluency and, above all, whether you can think out loud while solving a problem with someone watching. A silent candidate who reaches the answer often scores below one who narrates a slightly messier path, because the job is collaborative and the interviewer is auditioning your collaboration.

The efficient way to prepare is not to grind hundreds of random problems — it is to learn the ~15 recurring patterns (two pointers, sliding window, BFS/DFS, hashing, binary search, dynamic programming, and so on), because almost every problem is a dressed-up instance of one. The dedicated lesson, Coding Interviews: DSA & LeetCode Patterns, is the drill plan for this round; treat it as the syllabus and this section as the framing. In the room: restate the problem, state a brute force, improve it out loud, code the improved version, then test it against an edge case before you claim you’re done.

Round 3: the system design round

For mid and senior roles this round often matters more than the coding one, and it terrifies people because there is no single right answer — which is precisely the point. It tests judgement: can you take a vague, under-specified problem, impose structure on it, and reason about trade-offs like an engineer who has felt the consequences of bad ones? Silence and hand-waving both fail; a candidate who thinks aloud through a framework passes even with an imperfect design.

Use a framework so you never freeze. The System Design for Scalable Services lesson goes deep; here is the skeleton to walk every time:

Let me walk one, cloud-flavoured, tied to the portfolio project: “Design a service that ingests billing data from thousands of cloud accounts and serves cost dashboards.”

Clarify. How many accounts — thousands, so tens of thousands of daily pulls, not millions. How fresh must data be — cost data tolerates hours of staleness, which is a huge simplifying gift. Read or write heavy — write-heavy on ingest (scheduled pulls), read-light on dashboards. Estimate. Say 5,000 accounts, three clouds, hourly pulls: ~360k pull-jobs a day, each returning maybe thousands of line items — low-hundreds of GB a month of raw billing data. Comfortable for a single managed database with good partitioning. API and data model. The normalised LineItem from the cost reporter is the core entity; an internal ingest path writes them, a public query API (/cost?month=&group_by=) reads aggregates. Components:

Scale and bottlenecks. The real constraint is not our compute — it is the providers’ API rate limits, so the queue plus exponential backoff plus idempotent writes (re-pulling a month must not double-count) is the load-bearing design choice. Trade-offs. Eventual consistency on cost data (dashboards may lag reality by an hour — explicitly fine), precomputed aggregates (fast reads, staler numbers, more storage), and a single region to start (simpler, and cost dashboards are not latency-critical).

The interviewer will almost always push on scale: what breaks at 10x — 50,000 accounts? This is not a trap, it is an invitation to reason, and the honest answer names the first thing to break, not every possible thing. Here, ingest is embarrassingly parallel — 10x the accounts is 10x the workers, cheap — so the pressure lands on two places: the providers’ rate limits (which don’t scale with your worker count, so you shard pulls across accounts and spread them over the hour rather than firing at midnight) and the query-time aggregations (which you’d move from on-read to precomputed rollups, trading storage and freshness for read latency). The move that scores points is saying “I’d measure ingest lag and p95 query latency, and I’d only add the rollup layer once the numbers showed on-read aggregation hurting” — you are demonstrating that you scale in response to evidence, not by reflexively gold-plating. Reflexive over-engineering reads as junior; scaling the actual bottleneck reads as someone who has run something in production.

Notice how the project you built became the system you designed — that is the payoff of building something real: your portfolio is your system-design prep.

Round 4: the behavioural round

Here is the round that fails more strong engineers than any technical one, because they walk in thinking it doesn’t need preparation. It does. It is testing the things that determine whether you are pleasant and safe to work with for years: ownership, collaboration, how you behave under conflict, and — the one people fumble most — whether you can talk about a failure without either blaming everyone else or falling apart.

The preparation is concrete: bank six STAR stories before you need them, chosen so they cover the grid above. You do not need a story per question — one good story about a hard project can answer “conflict,” “ambiguity,” and “proud moment” depending on which facet you emphasise. Here is the map, with one-line sketches so you can see how a single real experience gets angled:

Two rules make behavioural answers land. Be specific — a real story with names, numbers, and a concrete action beats a general philosophy every time. And be honest about the failure story — interviewers are not looking for someone who never fails; they are looking for someone who fails well: owns it, fixes it, and changes something so it doesn’t recur. A candidate who claims never to have failed is either lying or has never owned anything hard, and both are worse than a good failure story.

Round 5: the role-specific technical round

The final technical round goes deep in the stack you would actually work in — and this is where the pipeline forks. Prepare the branch you are interviewing for; depth in your lane beats shallow coverage of both lanes.

For Cloud and DevOps roles specifically, expect a scenario / troubleshooting round — a broken system you must debug live, out loud. This rewards exactly the calm, hypothesis-driven debugging the course’s debugging and Linux lessons built: reproduce, isolate, check the obvious (logs, permissions, connectivity), form a hypothesis, test it. Narrate the whole thing; they are hiring your process, not just your answer. For AI/ML, expect probing on why a model is good — evaluation metrics, overfitting, data leakage, and how you’d monitor it in production — because the industry is full of people who can call .fit() and far fewer who can tell whether the result is trustworthy.

To make the troubleshooting round concrete: say they hand you a crash-looping Kubernetes pod. The wrong move is to guess (“maybe restart it?”); the right move is to narrate a funnel, out loud, from cheapest check to most expensive. “First I’d look at what’s actually happening — kubectl get pod for the status and restart count, then kubectl describe pod for the events, because that tells me if it’s the scheduler, the image pull, or the container itself. If it’s CrashLoopBackOff, the container is starting and dying, so I’d read kubectl logs --previous to see why the last run exited. Common causes I’d check in order: a missing env var or secret, a failed readiness probe, an OOMKill from too low a memory limit, or a dependency it can’t reach. I’d form one hypothesis from the logs and test just that — if it’s OOMKilled I’d check the limits against actual usage before touching anything else.” That answer wins not because it reaches the fix but because it shows a method: observe before you act, cheap checks before expensive ones, one hypothesis at a time. That is the exact posture the debugging and Linux lessons drilled, and it is what separates an engineer who gets paged at 3 a.m. and fixes it calmly from one who thrashes.

---

The take-home assignment

Some companies replace or supplement the coding round with a take-home: a small project you build on your own time. It is a gift and a trap. A gift because it plays to your strength — building real things without whiteboard pressure — and a trap because there is no natural stopping point, so people either under-deliver or spectacularly over-engineer.

The take-home is where everything in this lesson converges: a scoped, tested, documented, well-committed project is exactly the portfolio-grade artifact you already know how to build. The winning move is restraint — do precisely what’s asked, to a high standard, and put your judgement in the trade-offs note rather than in unrequested features. Over-engineering is not impressive; it signals someone who cannot tell what matters, which is the opposite of senior.

---

Negotiation and evaluating an offer

You got the offer. Two things left, both brief and both worth doing professionally.

Negotiate — almost always, and always kindly. The first number is rarely the best number, and a polite, well-reasoned ask is expected, not offensive. The leverage you have is another offer, a strong interview performance, and the cost to them of restarting the search. The mechanics: be warm, be specific, anchor on the whole package, and never bluff an offer you don’t have.

Evaluate the offer as a whole, not just the base salary — and watch for the signals that a job will be worse than the number suggests. Compensation is several components, and a headline base can hide a weak total or a bad environment.

And the red flags — the things that predict a bad experience regardless of pay:

None of these is automatically disqualifying, but each one is a question to ask before you sign. An offer is the one moment you have maximum leverage and maximum information; use it.

---

The honest meta: it’s a numbers game and a skill

Two truths to carry out of this course. First: rejection is normal, and it is not a verdict on your worth. Strong engineers get rejected constantly — for fit, for timing, for a better-matched candidate, for reasons that have nothing to do with ability and that you will never be told. Applying to a handful of dream jobs and stopping when they say no is the single most common self-inflicted wound. It is a numbers game: more applications, more interviews, more reps, and the odds compound in your favour.

But not every application is an equal rep, and this is the lever most job-seekers ignore: a referral is worth ten cold applications. A resume dropped into a company’s portal competes with hundreds in an automated filter; the same resume forwarded by an employee lands on a hiring manager’s desk with a human vouching for it, and the callback rate is not close. You do not need to already know people at the company. You need to become findable and reachable: publish the project writeups, be active where engineers in your target field are (a relevant community, conference talks, open-source issues on tools you use), and — the uncomfortable but effective move — message people directly. A short, specific note to someone doing the job you want (“I built X in this space, I saw you work on Y at Z, would you be open to a fifteen-minute chat?”) converts far better than its awkwardness suggests, because most people genuinely like helping and almost nobody asks well. Rank your channels by yield, not by comfort: warm referral, then a recruiter who sought you out, then a targeted application to a specific team, and only then the cold portal firehose. The portfolio you built is what makes every one of those channels work — it is the thing you point the referral, the recruiter, and the stranger at.

One more free rep most people skip: follow up. A short, genuine thank-you note after an onsite — one specific thing you enjoyed discussing, one line reaffirming your interest — costs two minutes and occasionally tips a close decision. And when you are rejected, ask the recruiter for feedback; some will give it, and a single concrete note (“they wanted more system-design depth”) is worth more than another ten blind applications because it tells you exactly which rep to drill next.

Second: interviewing is a skill separate from engineering, and it is learnable. Nobody is born good at whiteboard coding or STAR stories. You get better the way you got better at Python in this course — deliberate practice, feedback, iteration. Every interview, even a rejection, is a rep that makes the next one easier. Do mock interviews. Keep a brag-doc — a running file where you log wins, metrics, and hard problems solved as they happen, because you will never remember them under pressure six months later, and it is the raw material for both your resume bullets and your STAR stories.

Keep it current, and interview prep stops being a panicked archaeology of your own past and becomes a five-minute review of a document you already wrote.

And now the send-off. You began this course not knowing what a program was. You learned variables and loops, then functions and objects, then the standard library, testing, and packaging; you touched concurrency and performance; you built web services, data pipelines, and a machine-learning system end to end; you learned to design systems that scale and algorithms that pass interviews. That arc — from “what is programming” to “here is a system I designed and shipped” — is the entire distance from beginner to hireable, and you have walked it. What remains is not more knowledge. It is reps: build the three projects, write the READMEs, apply widely, interview often, get rejected, adjust, and keep going. The skill is real, the evidence is buildable, and the process is learnable. Go get the job.

---

Hands-on lab: build your launch kit

No new syntax here — you are going to assemble the concrete artifacts that get you hired. By the end you will have a portfolio-project scaffold, a complete README, two STAR answers, three resume bullets, and a four-week plan. Work in a scratch directory; everything is copy-usable into your real projects.

Step 1 — scaffold a portfolio-grade repo

Create the layout every strong Python project shares — src/ layout, tests beside it, CI, a license, and the docs that make it legible. This is the exact structure from the packaging lesson, now stocked as a portfolio artifact.

mkdir -p cloudcost/{src/cloudcost,tests,.github/workflows}
cd cloudcost

Populate it so it looks like this (the cost reporter from the project-ideas table):

cloudcost/
├── .github/
│   └── workflows/
│       └── ci.yml          # ruff + mypy + pytest on 3.11–3.13
├── src/
│   └── cloudcost/
│       ├── __init__.py     # __version__ lives here
│       ├── core.py         # pure cost model — no network, fully testable
│       ├── providers.py    # adapters: vendor API -> LineItem
│       └── cli.py          # thin shell: argparse/typer + exit codes
├── tests/
│   ├── __init__.py
│   ├── test_core.py        # tests the pure logic, no cloud account
│   └── test_providers.py   # tests adapters against recorded fixtures
├── .gitignore              # .venv/ dist/ __pycache__/ .env
├── CHANGELOG.md            # Keep a Changelog format
├── LICENSE                 # MIT — without it, legally unusable
├── README.md              # the storefront (Step 2)
└── pyproject.toml          # name, deps, scripts, tool config

The load-bearing choices, all of which an interviewer will recognise: src/ layout so tests import the installed package, not the source dir sitting in your CWD (the packaging lesson demonstrates the bug this prevents); core.py split from providers.py and cli.py so the logic is pure and testable without a cloud account or a terminal; tests/ beside src/, not inside it, so tests exercise the install and don’t ship in the wheel. That separation is not ceremony — it is what lets test_core.py run in CI on a machine with no AWS credentials.

The CI file is what earns the green badge in your README:

# .github/workflows/ci.yml
name: CI
on:
  push: { branches: [main] }
  pull_request:
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.11", "3.12", "3.13"]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "${{ matrix.python-version }}", cache: pip }
      - run: pip install -e ".[dev]"
      - run: ruff check .
      - run: mypy src
      - run: pytest

With the package installed via pip install -e ".[dev]", the pure-logic tests run with no cloud account:

pytest -q

........                                                                 [100%]
8 passed in 0.01s

What just happened: eight tests — the cost totals, the grouping, the forecast, the AWS adapter — passed against the pure core, exactly as they will in CI. That green run is the thing your README badge points at, and the reason a reviewer believes the code runs.

Step 2 — fill in the README template

Take the template from earlier and fill it for this project. Here is the real, complete result — the storefront a reviewer sees first. Note the shape: problem in the first bold line, a demo reference, a Quickstart with output, and a design-decisions table that pre-answers the interview.

# cloudcost

[![CI](…/ci.yml/badge.svg)](…) [![PyPI](…)](…) [![License: MIT](…)](LICENSE)

**One command to see this month's spend across AWS, Azure and GCP — grouped,
totalled, and forecast — without opening three billing consoles.**

FinOps dashboards are per-cloud, slow, and hard to diff. `cloudcost` pulls each
provider's native cost API into one normalised report you can run in CI, drop in
a Slack alert, or eyeball before standup.

![demo](https://raw.githubusercontent.com/you/cloudcost/main/docs/demo.gif)

## Quickstart

​```bash
pip install cloudcost
cloudcost report --month 2026-07 --group service
​```

​```text
        Cloud spend — 2026-07
┏━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┓
┃ Service           ┃ Cost (USD) ┃
┡━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━┩
│ AmazonEC2         │     120.00 │
│ VirtualMachines   │      50.00 │
│ AmazonS3          │      30.00 │
│ TOTAL             │     200.00 │
└───────────────────┴────────────┘
​```

## Design decisions

| Decision | Why | Trade-off |
|---|---|---|
| Pure core, thin adapters | Test logic without a cloud account | Boilerplate per provider |
| Linear forecast, not ML | Honest "on track?" glance, zero training | Misses spiky spend |
| Read-only creds only | Nothing to leak; safe in CI | Cannot remediate, only report |

## Development

​```bash
git clone … && cd cloudcost
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
pytest && ruff check . && mypy src
​```

## License

MIT — see [LICENSE](LICENSE).

What just happened: in under a screen, a stranger learns what it is, sees it run, can install it, understands why it’s built this way, and can develop on it. That design-decisions table is doing double duty — it impresses the reader and rehearses you for “why did you build it this way?”

Step 3 — write two STAR answers and three resume bullets

Here is your sample scenario — adapt it to something real from your own life; the structure is what transfers.

Scenario. You inherited a nightly deployment that failed about 30% of the time, blocking the team every morning. You diagnosed a race condition in the Terraform apply — two jobs grabbing the same state — added state locking and a bounded retry, and cut failures to near zero while deploy time dropped from 45 to 6 minutes.

STAR answer — “Tell me about a failure or a difficult problem you owned.”

(Situation) When I joined the platform team, our nightly deploy was failing roughly one night in three, and every failure blocked the whole team’s morning until someone manually re-ran it. (Task) I took ownership of making it reliable, because the interruptions were costing the team real time daily. (Action) I started by adding structured logging around the deploy so the failures stopped being a black box, and the logs showed two scheduled jobs occasionally hitting the same Terraform state at once — a race condition. I introduced remote state locking so only one apply could run at a time, added a bounded retry with backoff for the transient cloud-API errors underneath, and wrote a short postmortem so the team understood the fix. (Result) Nightly failures dropped from about 30% to effectively zero over the next month, and as a side effect of parallelising the independent steps, deploy time fell from 45 minutes to 6. The morning interruptions stopped entirely.*

Notice the proportions: one sentence of Situation, one of Task, the bulk in Action (what you specifically did), and a Result with two numbers. That is the shape.

STAR answer — “Tell me about a disagreement with a colleague.”

(Situation) A teammate wanted to ship the deploy fix without adding tests, arguing we were under time pressure and the change was “obviously correct.” (Task) As the person who’d own the deploy going forward, I wanted a safety net, but I didn’t want to just block them or turn it into a standoff. (Action) I proposed a compromise: rather than full coverage, we’d add a fast CI check for the one behaviour that had actually bitten us — the state-lock path — and I offered to pair on writing that first test so it wasn’t extra work landing on them. I framed it as protecting both of us from a 2 a.m. page, not as a process demand. (Result) We shipped with the one targeted test, they were fine with it once it was quick and paired, and that exact test later caught a regression before it reached production. It also set a norm — every deploy change since gets a small test — without anyone having to mandate it.*

That answer screens green on conflict (found a compromise, didn’t villainise), ownership (owned the deploy), and collaboration (paired, shared the load).

Three resume bullets from the same scenario — action verb, what, measured result:

• Cut nightly deployment failures from ~30% to near-zero by diagnosing a
  Terraform state race and adding remote state locking with bounded retries.

• Reduced deploy time 45 min → 6 min by parallelising independent pipeline
  steps, unblocking the team's morning workflow.

• Introduced structured deploy logging and a postmortem practice that turned
  opaque failures into a fix and a lasting per-change test norm.

What just happened: one real experience became two behavioural answers and three resume bullets — because they draw on the same well. This is exactly why the brag-doc matters: capture the experience once, angle it many ways.

Step 4 — a four-week interview-prep plan

A realistic plan for someone with the skills (you have them) who needs to convert. Adjust the pace to your calendar, but keep the shape — portfolio first (it feeds everything else), then breadth across the pipeline, weighted toward your weak rounds.

What just happened: you turned “prepare for interviews” — an anxiety — into a schedule with deliverables. Portfolio in week one because it feeds your resume, your GitHub, your system-design answers, and your behavioural stories. Then breadth across the pipeline. Then reps, forever, until an offer lands.

---

Common mistakes and troubleshooting

The career failure modes, and the fix for each. Most rejections trace to one of these — and all of them are avoidable.

Three of these deserve a closer look because they are the ones that sink otherwise-strong candidates.

The tutorial clone that generates negative signal. A project you followed step-by-step is worse than no project, because it invites the question you cannot answer: “why did you structure it this way?” If the honest answer is “the tutorial did,” the interviewer has learned you cannot make design decisions. The fix is not to avoid learning from tutorials — it is to diverge: take the concept, apply it to a different, real problem, make your own choices, and be ready to defend them. The moment a project’s decisions are yours, it becomes an asset.

Skipping behavioural prep — the strong-engineer killer. This is the most painful failure mode in the whole lesson because it fells the most capable people. A brilliant engineer who has never once rehearsed “tell me about a conflict” will ramble, sound evasive on the failure question, and get rejected at the final round by a hiring manager who could not, in the moment, picture working with them for two years. The technical rounds got you there; the behavioural round is a separate skill, and it is easy to prepare — six stories, practised aloud, and you are ahead of half the candidates who assumed it didn’t count.

Applying to only dream jobs. Interviewing is a numbers game and, separately, a skill that improves with reps. Sending five applications to your five favourite companies and stopping when they say no is doubly self-defeating: your odds on any single application are low regardless of ability, and you walked into those five interviews with zero recent practice. Apply widely, including to roles you are lukewarm about — the “practice” interviews sharpen you for the ones you want, and offers create leverage. Volume is not desperation; it is strategy.

---

Cheat-sheet

Two checklists to bookmark: one for the portfolio, one for the interview loop.

Portfolio checklist — per project:

Interview-prep checklist — before you apply:

---

Interview and exam questions

Q: A portfolio or a certification — which gets me hired faster? A: A portfolio, for most Cloud/DevOps/AI roles. A certification proves you can pass an exam; a portfolio proves you can build the thing the exam is about. Certs help you clear a keyword filter (some cloud roles list them), but in the interview, “here is a tool I built and deployed” beats “I passed a multiple-choice test” every time. If you have limited hours, spend them on one deployed project before a second cert.

Q: I have no professional experience. What do I put on my resume? A: Your projects, framed exactly like jobs — with quantified bullets. “Built X that handles Y, with N% test coverage, deployed at [link].” A strong project section plus a clean, defensible GitHub is how career-changers and new grads out-compete people with unremarkable jobs. The portfolio is your experience until you have the other kind.

Q: How many LeetCode problems do I need to grind? A: The number is the wrong target. Aim to be fluent in the ~15 recurring patterns rather than to hit a problem count — most problems are a disguised instance of one. Fifty problems done deliberately (solve, then study the optimal, then re-solve) beat three hundred rushed. The dedicated DSA & LeetCode lesson is the pattern syllabus.

Q: How do I answer “what’s your greatest weakness” without a cliché? A: Name a real, non-fatal weakness and — this is the whole point — what you do about it. “I used to under-communicate on long tasks; now I post a short daily status so nobody has to ask.” Avoid the humblebrag (“I work too hard”) — interviewers have heard it a thousand times and it reads as evasive. Self-awareness plus a corrective action is the signal they want.

Q: Give me a good answer to “tell me about yourself.” A: Sixty to ninety seconds, three beats: what you do now / your strongest proof point / why this role. “I’m a Python developer focused on cloud automation — most recently I built a multi-cloud cost reporter that surfaced about $4k a month of waste, which is the kind of infrastructure-tooling work I want to do more of, and it’s why this platform role caught my eye.” Concrete, forward-looking, and it hands them a thread to pull.

Q: I keep getting rejected after the final round. What’s going wrong? A: If the technical rounds pass but the final doesn’t, it is almost always behavioural. Record yourself answering “tell me about a conflict” and “tell me about a failure.” If you ramble, blame others, or blank — that’s it. Bank six STAR stories, practise them aloud, and the final-round pass rate changes. Also ask the recruiter for feedback; some will tell you.

Q: Should I disclose I’m self-taught / a career changer? A: Don’t hide it, don’t lead with an apology. Lead with proof — your projects — and the “self-taught” part becomes a strength (initiative, drive) rather than a gap. Nobody who can point at three deployed projects gets rejected for lacking a CS degree; they get rejected for not having the projects.

Q: How do I handle “why are you leaving your current job?” A: Forward-looking, never bitter — even if you’re leaving something bad. “I’ve learned a lot but I’ve plateaued on the infrastructure side, and I want a role where that’s the core work” is true, professional, and doesn’t badmouth anyone. Bitterness about a current employer is the fastest way to make an interviewer imagine you badmouthing them later.

Q: Behavioural — “tell me about a time you had to make a decision without all the information.” A: (STAR) “We got a vague mandate to ‘reduce cloud spend’ with no data on where it was going. Rather than guess, I spent a day building a small reporter to pull actual per-service costs, which showed most of the waste was idle non-prod resources. I prioritised shutting those down first because it was the biggest, safest win, and deferred the riskier rightsizing. That surfaced about $4k a month immediately, and gave us the data to make the harder calls deliberately instead of guessing.” — Ambiguity handled by reducing the ambiguity before acting, then prioritising by impact.

Q: The take-home says “3–4 hours” but I could do so much more. Should I? A: No. Do exactly what’s asked, to a high standard — README, tests, CI, clean commits — and put your ambition in a short “what I’d do next with more time” note. Over-delivering signals poor prioritisation, which is a senior-level red flag. Respecting the scope is the signal of judgement they’re testing for.

Q: How much should I negotiate as a junior with one offer? A: Always negotiate, always kindly, and expect a smaller delta than a senior would get. A polite “I’m excited to join — is there flexibility on the base?” costs nothing and often yields something. If there’s no room on base, trade across the package (sign-on, start date, PTO). The worst case is they say no and you accept the original — you don’t lose an offer by asking respectfully.

Q: My GitHub contribution graph is mostly empty. Is that disqualifying? A: No. Green squares are a weak signal and hiring managers know it. Three excellent pinned projects beat a solid-green wall of trivial commits. Do not fake activity — padded daily commits are a negative signal about judgement. Put your energy into finishing and documenting real projects; that’s what a reviewer actually reads.

---

Key takeaways

• Proof beats claims. A deployed, documented, tested project is evidence a hiring manager can inspect; a resume line is a claim they must take on faith. Your portfolio is how skill without pedigree wins.
• Three strong projects beat ten toy ones. Reviewers judge you on your best pinned repo and your worst — quality and finish, not count. Pin three you can defend for an hour each; archive the graveyard.
• The README is the highest-ROI thing you’ll write. Problem, demo, Quickstart-with-output, and a design-decisions table — above the fold. An unread project generates zero signal, and the reader gives you ninety seconds.
• Quantify everything. Every resume bullet is action verb + what you built + a measured result, and every number is a question you must be able to answer. A bullet without a number is a job description.
• The interview is a pipeline of independent filters. Recruiter screen, coding, system design, behavioural, role-specific — you can be strong on four and rejected on the fifth. Prepare across all of them, weighted toward your weak rounds.
• The two silent drop-offs are a demo-less README and unprepared behavioural answers. Both fell strong candidates; both are easy to fix. Bank six STAR stories before you need them.
• It’s a numbers game and a learnable skill. Rejection is normal and not a verdict. Apply widely, keep a brag-doc, do mock interviews, and treat every interview as a rep that improves the next.
• You’ve walked the whole distance. From “what is a program” to designing systems and shipping ML — the arc of this course is the arc from beginner to hireable. What’s left isn’t more knowledge; it’s reps. Build the projects, write the READMEs, apply, interview, adjust, and go get the job.