Career Readiness

1. 01

   A portfolio somebody will actually read

   Beginner

   Three projects explained well beats twelve repositories with default READMEs. The explanation is the artefact.

   • Make a README Article makeareadme.com 30 min Free The minimum a reviewer needs: what it does, why it exists, how to run it, and what you would change. Most candidate repositories fail on all four.
   • GitHub — About READMEs and profiles Documentation GitHub 45 min Free Includes the profile README, which is the first thing a recruiter looking at your GitHub sees. Pinned repositories matter more than commit streaks.
   • Google — Technical Writing Courses Course Google 4h Free Two short courses. They will improve your READMEs, your commit messages and your interview answers at the same time.

   Build this

   Rewrite the READMEs on your three best repositories

   For each: the problem it solves, a screenshot or example output, how to run it in under five commands, one design decision you made and why, and what you would do differently.

   Then ask someone outside your field to read one and tell you what the project does. If they cannot, it is not finished.

   Done when: Three rewritten READMEs, each verified by a reader from outside your field.

2. 02

   A resume that survives the scan

   Beginner

   One page, evidence per line, and no adjective you cannot substantiate. It gets about six seconds of attention.

   • Tech Interview Handbook — Resume Documentation Tech Interview Handbook 2h Free Specific, current, and free. Follow the format rather than inventing one — originality in resume layout is a cost, not a signal.
   • GOV.UK — Writing for the web Documentation GOV.UK 1h Free Front-load the point, cut the qualifiers. Exactly the discipline a resume bullet needs.

   Build this

   One page, evidence on every line

   Rewrite your resume so that every bullet names an action and a result you can prove. Delete anything you could not defend for two minutes under questioning.

   Then hand it to someone for six seconds and ask what you do. That answer is what your resume actually says.

   Done when: A one-page resume where every claim is defensible, tested with a six-second read.

3. 03

   Technical communication

   Intermediate

   Explaining your work to someone who has neither your context nor your enthusiasm. This is most of what a technical interview measures.

   • Julia Evans — blog Article jvns.ca Julia Evans 4h Free A masterclass in explaining hard technical things simply without making them wrong. Read for the method as much as the content.
   • Write the Docs — Documentation Guide Documentation Write the Docs 3h Free Community-maintained and practical. The sections on structure and on writing for different audiences transfer straight to interviews.

   Build this

   Write up the hardest bug you have fixed

   Eight hundred words: the symptom, what you thought it was, how you were wrong, how you found the real cause, and what you changed so it could not recur.

   This doubles as a blog post and as a rehearsed answer to the most common question in every technical interview.

   Done when: A published write-up of one real debugging story.

4. 04

   Technical interviews

   Intermediate

   A separate skill from the job itself. Unfair, well documented, and entirely learnable.

   • Tech Interview Handbook Documentation Tech Interview Handbook 8h Free The best free end-to-end guide, including a study plan by available time. Follow the plan rather than grinding problems at random.
   • NeetCode — Practice roadmap Interactive NeetCode 15h Free A curated ordering of problems by pattern. Patterns are what transfer; individual solved problems mostly do not.
   • The System Design Primer Code repository GitHub Donne Martin 15h Free Comprehensive and free. Work the exercises with a diagram and a stated set of assumptions — that habit is what is being assessed.

   Build this

   Five mock interviews, logged

   Do five, out loud, timed, with another person or recorded. After each, write down where you froze, where you rambled, and what you would say instead.

   The log is the deliverable. Practising without reviewing is how people do fifty problems and get no better at interviewing.

   Done when: Five session logs with a specific correction identified after each.

5. 05

   Behavioural interviews

   Beginner

   The half most technical candidates neglect, and the half that decides between two people who both passed the coding round.

   • Tech Interview Handbook — Behavioral interview Documentation Tech Interview Handbook 2h Free The question categories and the STAR structure. Prepare six stories that can be recombined, not thirty rehearsed answers.
   • re:Work — Hiring guides Documentation Google 2h Free Written for interviewers, which is exactly why it is useful to a candidate: it tells you what they are instructed to look for.

   Build this

   Six stories, written and timed

   Write six STAR stories covering conflict, failure, leadership, ambiguity, influence and a technical trade-off. Each must fit in two minutes spoken.

   Include a real failure with what you changed afterwards. Interviewers can tell when the 'failure' has been sanded down into a strength.

   Done when: Six written stories, each timed at two minutes spoken.

6. 06

   Evaluating an opportunity

   Intermediate

   The final skill: reading an offer honestly, and knowing what to ask before you accept one.

   • Ten Rules for Negotiating a Job Offer Article haseebq.com Haseeb Qureshi 1h Free The most widely recommended piece on this, and it holds up. Read both parts before your first offer conversation, not during.
   • levels.fyi Dataset levels.fyi 45 min Free Self-reported and skewed toward large companies, so treat it as a range rather than a number. Still better than negotiating with no data at all.
   • Questions to ask your interviewer Code repository GitHub 45 min Free A community list of what to ask them. Asking about on-call, code review and how the last person in this role left tells you more than any careers page.

   Build this

   Your criteria, written before the offer arrives

   Write down what you are optimising for — learning, money, stability, the people, the domain — and the ranking, before you are in a room with someone persuasive.

   Add your walk-away conditions. Deciding this in advance is the only reliable defence against accepting a role for the wrong reason.

   Done when: A written, ranked set of criteria with explicit walk-away conditions.

Nothing matches that combination in this path yet.