Career Readiness

Three READMEs rewritten to the same six-part structure, on the three repositories you would actually send to a hiring manager.

1. Line one is the pitch. What it does and who it is for, under 20 words, above everything else. Not "a project I built to learn React".
2. Show it working. A screenshot, a GIF, or a pasted terminal session with real output, inside the first screen of the page.
3. Five commands to running. Clone, install, configure, seed, run — copy-pasteable, with the exact language and tool versions you tested. Then run them yourself in a fresh clone on a clean machine and fix everything that breaks.
4. One decision, defended. A short section naming a real trade-off — the database, the framework, the schema shape — with the alternative you rejected and why.
5. State the limits. What it does not do, what breaks at scale, what you would fix first. This reads as judgement, not weakness.
6. Test the pitch on an outsider. Sixty seconds, someone outside your field, then ask what the project does. Rewrite line one until they get it right.

Scope guard: no badges that do not report a real status, no roadmap section, no architecture diagram for 400 lines of code.

One page where every bullet names a specific action, a measurable result, and something a reference could confirm.

1. Rewrite every bullet to one shape. Action, method or tool, result with a number, timeframe. "Cut nightly report generation from 40 minutes to 90 seconds by replacing per-row queries with a single aggregate" — not "improved database performance".
2. Find the numbers. Users, latency, revenue, hours saved, defects, team size, uptime. Where no metric exists, use scale: records processed, requests served, people trained.
3. Apply the two-minute test. Could you withstand two minutes of questioning on this line? If not, cut it — that is precisely the line you will be asked about.
4. Cut to one page. Remove the objective, the skills list that repeats the bullets, and anything before your three most recent roles unless it is the strongest thing on the page.
5. Run the six-second test. Hand it to three people for six seconds each, then ask what you do and what you are best at. Fix the layout until all three answer correctly.
6. Make one targeted version. Take a real posting and reorder and reword — without inventing anything — so the top third of the page answers its top three requirements.

Scope guard: one page, one column, no photo, no skill bars, no rating yourself four out of five at anything. Export as PDF and open it on a phone before sending.

An 800-word write-up of one real bug, structured as an investigation rather than a conclusion, published somewhere with a URL you can send.

1. Open on the symptom. What was observed, by whom, how often, and what it cost. The reader should not know the cause any earlier than you did.
2. Show the wrong hypothesis. What you believed first, why it was reasonable, and the evidence that killed it. This is the part interviewers are listening for.
3. Name the technique that worked. Bisection, a profiler, a packet capture, structured logging, a minimal reproduction — say exactly what narrowed the search space and by how much.
4. Show the root cause in code. The smallest snippet or config that demonstrates it, with the fix as a diff.
5. Close the class, not the instance. The test, type, lint rule, alert or invariant you added so this whole category of bug cannot recur silently.
6. Rehearse it aloud. Time yourself telling the story in two minutes without notes. That is the interview answer; the post is its written form.

Scope guard: one bug, 800 words, real code. Sanitise anything confidential — rename services, redact data — but never fictionalise the technical detail.

Five timed mock interviews, spoken aloud and recorded, each followed by a written review. The log is the deliverable — practising without reviewing is how people solve fifty problems and interview no better.

1. Fix the format. 45 minutes, a problem you have not seen, talking throughout, screen and audio recorded. Silence in your own recording is data.
2. Cover five different shapes. One data structures problem, one system design, one code-reading or debugging exercise, one deep dive on a project from your resume, and one full loop simulation. Draw problems from a fixed list such as NeetCode 150 so you cannot quietly pick easy ones.
3. Score against a rubric immediately. Clarifying questions asked, approach stated before coding, complexity named, tests considered, communication maintained under pressure. One to five on each, straight after the session.
4. Watch the recording. Note the timestamp where you froze, where you rambled past 60 seconds, and where you started coding before stating the approach.
5. Write one correction per session. A single specific behaviour: "state the brute force and its complexity before optimising" — never "communicate better".
6. Prove the trend. Plot the five rubric scores. If a line is not moving, the correction attached to it was too vague to act on.

Scope guard: five reviewed sessions beat fifty silent problems. Do not start the next one until the correction from the last is written down.

Six STAR stories, written down and timed at two minutes spoken, covering the six themes every behavioural loop draws from.

1. Cover the six. Conflict with a colleague, a failure you caused, leading without authority, working under ambiguity, influencing a decision that was not yours, and a technical trade-off you argued for.
2. Hold the ratio. Situation and Task in 20 seconds, Action for 80, Result in 20. Most people invert this and burn 90 seconds on context.
3. Put a number in the Result. What changed, by how much, and how you knew — including the part that was still unresolved when you left.
4. Make the failure a real one. Something that cost time, money or trust, with what you changed afterwards. Interviewers can hear when a failure has been sanded into a strength.
5. Time each one aloud. Read it, then tell it without the page. Anything over 2:15 gets cut, and the cut comes out of the Situation.
6. Prepare the follow-ups. For each story, write the two questions that come next — "what would you do differently", "how did the other person see it" — and answer each in a line.

Scope guard: six flexible stories, not twenty rehearsed scripts. Never invent one; a story you did not live collapses on the second follow-up.

A written, ranked set of criteria and walk-away conditions, produced before any offer exists — because the only reliable defence against a persuasive room is a decision made outside it.

1. Rank, do not list. Force a strict order across learning rate, compensation, stability, the person you would report to, domain, location and autonomy. An unordered list is not a decision tool.
2. Turn each criterion into a question you can ask. "Learning" becomes "who reviews my work, and how often". "Stability" becomes "what is the runway and when was the last raise". Vague criteria produce vague interviews.
3. Set the number. Your minimum acceptable total compensation, benchmarked on levels.fyi or the local equivalent for that role, level and city — fixed before anyone asks what you are looking for.
4. Write three walk-aways. Conditions under which you decline regardless of money, stated concretely: no code review, a two-hour commute, a manager who cannot describe what success looks like at 90 days.
5. Score a role you already know. Your current or last one. If the framework rates it in a way you disagree with, the weights are wrong — fix them now rather than mid-negotiation.
6. Draft the three sentences. Exact wording for asking for more, for asking for time to decide, and for declining well. Rehearsed sentences beat improvised ones under pressure.

Scope guard: one page, written before you enter a process. Revisit it after an offer only in writing, recording the reason for every change.