The setup

The job was simple: every hour, find users whose trial expired in the last hour and send them a reminder email. The code looked like this:

async function sendTrialReminders() {
  const users = await db.users.findMany({
    where: { trialEndsAt: { lte: new Date() }, reminderSent: false },
  });
  for (const user of users) {
    await sendEmail(user, "Your trial has ended");
    await db.users.update({
      where: { id: user.id },
      data: { reminderSent: true },
    });
  }
}

Find users who need a reminder, send it, mark it sent. Read, act, mark. What could go wrong?

The two lines that matter

The bug lives in the gap between these two lines:

const users = await db.users.findMany({ ... reminderSent: false });

and

await db.users.update({ ... data: { reminderSent: true } });

Between finding a user and marking them, time passes. Sending an email takes a second or two. With fifty users, the loop takes a couple of minutes. And cron, meanwhile, does exactly what cron does: it runs the job again on schedule, whether the previous run finished or not. On Tuesday the email service was slow. The first run took longer than usual. The second run started while the first was still working through its list. The second run queried the same reminderSent: false rows — because the first run had not marked them yet — and sent the same emails again. That is a race condition: two runs of the same job, both reading the same unmarked rows, both acting on them. No error anywhere. Both runs completed successfully. The users got two emails.

Why I assumed it could not happen

I had assumed, without ever checking, that cron jobs do not overlap. That assumption felt safe because it usually is: a job that takes two minutes, scheduled hourly, never overlaps. Until the day it takes sixty-five minutes, or the email service slows down, or the database stalls, and suddenly the schedule and the runtime collide. "Usually finishes in time" is not a guarantee. It is a hope, and hopes do not hold under load.

The fix

The fix has two parts, and you want both. 1. Claim the work before you do it. Mark the rows as claimed in the same step that finds them, atomically, so a second run cannot see them:

const claimed = await db.users.updateMany({
  where: { trialEndsAt: { lte: new Date() }, reminderSent: false },
  data: { reminderSent: true },
});
// then fetch the claimed rows and send the emails

updateMany is a single atomic operation in the database. Two runs cannot both claim the same row. The second run finds nothing to do and exits quietly. The marking happens before the slow work, not after it. Note the trade-off: if the email send fails after claiming, the user is marked as reminded without receiving anything. For a reminder email, that is acceptable — the user can be re-targeted by a separate retry pass. For a payment or a critical notification, you want a three-state flag instead: pending, sent, failed, with a retry job that picks up failed rows. The principle is the same: the state change that prevents a duplicate must happen atomically, before the slow work. 2. Lock the job itself. Even with atomic claiming, add a lock so two runs cannot execute at the same time. The simplest version is a lock row in the database with an expiry: the job writes "running, locked until X" at the start, and refuses to start if a live lock exists. If a run crashes, the lock expires and the next run proceeds. Libraries exist for this in every ecosystem, and most of them are a dozen lines. Use one.

The check that finds this bug before users do

Look at every scheduled job you run and ask two questions:

1. If this job runs twice at the same time, what happens? If the answer is "duplicate work", it needs an atomic claim or a lock.
2. If this job runs longer than its schedule interval, does the scheduler start a second copy? For cron, the answer is yes, always. For most job queues, the answer depends on configuration — check yours. The bug cost me a handful of duplicate emails and an apology. It could have cost duplicate charges, duplicate database writes, duplicate anything. The fix was one atomic update and a lock — less code than the apology email I had to write.

What the bug is

TLS certificate validation is the check that answers one question: is the server I am talking to actually the server it claims to be? When your Node app connects to an API over HTTPS, it checks the server's certificate against a list of trusted authorities and against the hostname it expected. If the certificate does not match, the connection is refused. CVE-2026-105483 is a flaw in that validation logic in Node.js 24.x and 26.x. In the affected versions, certain malformed or mismatched certificates could pass validation when they should have failed. The practical consequence is that an attacker who can sit between your app and the server it talks to — a compromised network, a hostile Wi-Fi access point, a DNS trick — could present a certificate that is not valid for that hostname and still have the connection accepted. That is a serious failure, because certificate validation is the one thing standing between "encrypted connection to the right server" and "encrypted connection to whoever is listening."

Who is affected

The affected lines are Node.js 24.x and 26.x. If you run either of those in production, you are in scope. Other lines are not affected by this specific vulnerability, which is worth stating plainly: this is not a "Node is broken" story. It is a bug in two release lines, with a fix in the patched releases. What makes it worse than a typical dependency bug is where it sits. This is not a package you can update with npm update. It is the runtime itself. Every HTTPS request your app makes, and every TLS connection your server accepts, goes through this code.

How to tell if you're affected

Run one command on every machine and container that runs your app:

node --version

If the output starts with v24. or v26., check the exact patch version against the fixed releases in the Node.js security advisory. Anything below the fixed version in those lines needs the upgrade. If you run v20. or v22. or anything else, this CVE does not apply to you — but check anyway, because the next one might. Then check the places version numbers hide:

• Docker images. Your Dockerfile probably says node:24-alpine or similar. That tag moves, but the image you built last month does not. Rebuild the image after the base image updates, and check the version inside the running container, not the tag on the outside.
• CI runners and deployment targets. The Node version in your CI config and the one on your server are often different. Check both. A patched CI and an unpatched server is still an unpatched server.
• Bundled runtimes. Electron apps, serverless layers, and tools that ship their own Node can carry an affected version without it appearing in your package.json. If a tool bundles Node, check the tool's release notes.

The fix

Upgrade Node to a patched release in the 24.x or 26.x line. There is no configuration workaround worth relying on — certificate validation is not something to patch around with a flag. The upgrade is the fix. After upgrading, verify rather than assume. Run node --version on the deployed machine and confirm the number changed. Then run your TLS-dependent test suite — the tests that hit real HTTPS endpoints — and confirm they still pass. A runtime upgrade that silently changes TLS behaviour is exactly the kind of change that deserves a test run, not a shrug.

The habit this should build

Most teams pin their dependencies carefully and let the runtime float. The runtime is the biggest dependency you have, and it changes the least often, which is why it gets the least attention. Put the Node version in the same place you put your dependency checks: a scheduled check, a pinned version in your Dockerfile, and a habit of reading the Node.js security advisories the way you read your package audit output. CVE-2026-105483 will be a footnote in a month. The habit of knowing exactly which runtime version is running in production will keep paying off long after the CVE is forgotten.

Why a new JSON package at all

The old encoding/json is one of Go's oldest packages, and it shows. It was designed before generics, before the community settled on how JSON should behave at the edges, and it carries two decades of backwards-compatibility promises. The result is a package that works fine for the common case and surprises you at the edges: numbers that lose precision, struct tags that silently do nothing when misspelled, error messages that tell you something failed but not where. json/v2 is a fresh start under the encoding/json/v2 import path. It keeps the shape you know — Marshal, Unmarshal, struct tags — and fixes the sharp edges. The old package is not going away. The new one is the future, and it is designed so the two can coexist while you migrate piece by piece.

What changed

Numbers keep their precision. The old package decodes every JSON number into a float64 by default, which quietly mangles large integers — a 64-bit ID like 9007199254740993 comes back as 9007199254740992. The new package preserves integer precision by default. If your service passes IDs or money amounts through JSON, this alone is worth the migration. Struct tags are validated. In the old package, a typo in a struct tag — json:"usernmae" — fails silently. The field just never matches, and you find out in production when a field is mysteriously empty. The new package reports unknown or malformed tag options as errors. A typo becomes a compile-time-style failure instead of a silent data loss bug. Errors say where. The old package's errors are famously vague: "invalid character 'x' looking for beginning of value". The new package's errors include the position in the input and the path to the value that failed — which field, nested how deep. Debugging a bad payload goes from reading the whole document to reading one line. Streaming and options are cleaner. The new API separates the common operations from the configuration. Instead of a bag of methods on Encoder and Decoder, options are explicit values you pass in, which makes it easier to see what a given call actually does. The jsontext sub-package exposes the low-level token stream for the cases where you need it — building a JSON linter, say, or transforming a document without decoding it fully.

What breaks

This is a new package, not a drop-in replacement, and the migration has real edges:

• Import path changes. You import encoding/json/v2 instead of encoding/json. Both can live in the same program, which is good for gradual migration and confusing for exactly one afternoon.
• Default behaviours differ. The number-precision change is a fix, but it is also a behaviour change: code that relied on float64 rounding will see different values. The stricter tag validation will surface typos you have been shipping for years — which is the point, but it means the first build after migrating may fail in places you did not expect.
• Some old escape hatches are gone. A few of the old package's quirks that people worked around — custom MarshalJSON patterns that depended on specific error text, for instance — will not behave identically. Read the migration notes before porting a hot path.

Should you migrate now

For a new service: yes, start with json/v2. The defaults are better, the errors are better, and you avoid building on the package the language itself is moving away from. For an existing service: migrate the edges first. Start with the code that handles money, IDs, or untrusted input — the places where silent number mangling and silent tag typos cost real money. Leave the happy-path CRUD endpoints on the old package until you have a reason to touch them. The two packages coexist, so there is no big-bang rewrite and no deadline. One caution: json/v2 is new, and new means the ecosystem around it — linters, code generators, libraries that wrap encoding/json — is still catching up. If a library you depend on does its own JSON handling through the old package, mixing the two in the same request path can produce subtle inconsistencies. Check your dependencies before you migrate their inputs.

The takeaway

Go's JSON story for years was "it works, mostly, except when it quietly doesn't." The new package closes the quiet failure modes: numbers stay exact, typos get caught, errors point at the problem. It is not exciting. It is the kind of change that prevents a 2am incident six months from now, which is the best kind of change a standard library can ship.

What MCP actually is

Strip away the branding and MCP is a client-server protocol with three ideas:

• Tools: functions the AI can call. "Search my notes", "read this file", "add a task".
• Resources: data the AI can read. Your notes, your docs, your database rows.
• Prompts: reusable templates. "Summarise today's notes" as a saved starting point. The AI client (Claude Desktop, an IDE, whatever you use) connects to your server, asks what tools it has, and calls them when the conversation needs them. Your server is just a program that answers those calls. That is the whole protocol. Everything else is packaging.

The server I built

My notes live in a folder of Markdown files. I wanted the AI to search them and read them, so I never have to paste a note into a chat window again. The server exposes two tools: search_notes and read_note. I used the TypeScript SDK. The skeleton is this:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
const server = new McpServer({ name: "notes", version: "1.0.0" });
server.tool(
  "search_notes",
  "Search Markdown notes by keyword and return matching filenames",
  { query: z.string() },
  async ({ query }) => {
    const matches = searchFiles(NOTES_DIR, query);
    return { content: [{ type: "text", text: matches.join("\n") }] };
  }
);

That is most of it. A tool is a name, a description, a schema for its inputs (written with Zod), and a handler function that returns text. The description matters more than people think: the AI reads it to decide when to call the tool, so write it the way you would explain the tool to a colleague. The transport is stdio — the server reads JSON-RPC messages from stdin and writes replies to stdout. No HTTP, no port, no deployment. The client launches the server as a subprocess. That sounds primitive, and it is, and that is why it works everywhere.

The part that surprised me

Two things surprised me. First, how little code the protocol needs. My whole server is under 150 lines, and most of that is the file-search logic, not MCP. The protocol gets out of the way. The SDK handles the handshake, the tool listing, the schema validation. You write the function; MCP delivers the call. Second, how much the description shapes behaviour. My first description for search_notes was "Search notes". The AI called it for everything, including questions that had nothing to do with my notes. I changed it to "Search the user's personal Markdown notes by keyword — use only when the question is about something the user has written down before" and the false calls stopped. The description is the API documentation and the usage policy in one sentence. Write it carefully.

The read tool, and one safety rule

server.tool(
  "read_note",
  "Read one Markdown note by filename and return its full text",
  { filename: z.string() },
  async ({ filename }) => {
    const safe = path.basename(filename);
    const text = await fs.readFile(path.join(NOTES_DIR, safe), "utf-8");
    return { content: [{ type: "text", text }] };
  }
);

Notice the path.basename call. The AI supplies the filename, and the AI can be tricked — by a poisoned note, by a pasted message — into asking for ../../secrets.txt. Stripping the path down to a bare filename is one line, and it is the difference between a tool and a hole. Every MCP tool that touches the filesystem needs this. Do not skip it because your server is "just for personal use". Personal-use tools are the ones that end up connected to everything.

Wiring it up

The client configuration is a JSON file pointing at the server command:

{
  "mcpServers": {
    "notes": {
      "command": "node",
      "args": ["/path/to/notes-server.js"]
    }
  }
}

Restart the client, and the two tools appear. Ask "what did I write about commit messages last month" and the AI calls search_notes, then read_note, then answers from your own words. It feels like magic the first time. It is not magic. It is a function call with a good description.

When to build one, and when not to

Build an MCP server when you have data or tools the AI keeps asking you to paste in by hand: notes, a local database, a CLI you run ten times a day. If the same paste happens three times, a tool is cheaper than the pasting. Do not build one for things the client already does well. Web search, general knowledge, code generation — the model has those. MCP is for your stuff: your files, your systems, your data. That is where it earns its keep. An hour, 150 lines, two tools. My notes are now searchable by conversation, and I finally understand the protocol, because I built the smallest possible version of it instead of reading about the biggest.

The symptom

The test was simple:

test("formats a timestamp as HH:MM", () => {
  const result = formatTime(new Date("2026-11-07T09:30:00"));
  expect(result).toBe("09:30");
});

On CI it failed with Expected "09:30", received "09:29" or sometimes "09:31". Off by a minute, in either direction. Locally, never. The test had no randomness, no network, no database. Just a date and a string.

The first wrong theory

My first guess was timezones. CI runners often run in UTC while my laptop runs in local time, and date bugs love that gap. I checked: the runner's timezone was UTC, mine was +06:00, and the test used a fixed date string. But the expected value "09:30" was written against the local reading of that date, so in UTC the test should have failed every time, not one time in five. Wrong theory, but it taught me something: intermittent failures that depend on the clock are almost always about the clock.

Reproducing it

The trick with a flaky test is to stop asking "why does it fail" and start asking "what is different between the runs that pass and the runs that fail." I added one line to the CI job: print the current time at the start of the test run. The pattern jumped out immediately. Every failing run started within a few seconds of a minute boundary. Every passing run started mid-minute. The test was not flaky. It was a race against the clock, and the clock was winning about one run in five — exactly as often as a test run happens to straddle a minute change. Here is the mechanism. My formatTime helper did this:

function formatTime(date) {
  const now = new Date();
  // ... some logic that compared `date` against `now`
  // and rounded to the nearest minute
}

The function read the current time internally, and the test compared its output against a fixed expectation. If the test started at 09:30:58 and the function ran at 09:31:01, the rounding tipped over the boundary and the answer changed. Locally my runs were fast and I never straddled a boundary. On CI, the runner was slower, the test suite was bigger, and the boundary got crossed regularly.

The fix

Two changes, both small: 1. Inject the clock. The helper now takes the current time as a parameter with a default, instead of reading it internally:

function formatTime(date, now = new Date()) {
  // ... same logic, but `now` is passed in
}

The test passes a fixed now. The function is deterministic. The same input always gives the same output, on every machine, at every second. 2. Freeze time in the test. For tests that genuinely need "now", use a fake timer. In Jest that is jest.useFakeTimers().setSystemTime(new Date("2026-11-07T09:30:00")). In Vitest, vi.useFakeTimers() and vi.setSystemTime(...). The test controls the clock, so the clock can never surprise it.

The habits that prevent the next one

Treat any use of new Date(), Date.now(), Math.random(), or setTimeout inside tested code as a smell. Not always a bug — sometimes you genuinely need the current time. But every one of those calls is a hidden input your test does not control, and hidden inputs are where flakiness lives. Inject them or freeze them. When a test is flaky, log the environment, not the test. I wasted an hour re-reading the test. The answer was in the runner: the start time of the run. Flaky tests are usually deterministic functions of something you are not looking at — the clock, the order tests run in, leftover state from a previous test. Log the context first, read the test second. The test has been green on CI for three weeks now, across dozens of runs. Not because I made it more robust. Because I made it deterministic, and deterministic things do not flake.

The example

Two tables. Customers, and orders.

Customers:

| id | name | | 1 | Aisha | | 2 | Ben | | 3 | Cara |

Orders:

| order_id | customer_id | item | | 101 | 1 | Laptop | | 102 | 1 | Mouse | | 103 | 2 | Keyboard |

Aisha ordered twice. Ben ordered once. Cara ordered nothing. Every join below starts from these two tables. The only question is: which rows survive?

1. INNER JOIN: only the matches

SELECT name, item FROM customers
INNER JOIN orders ON customers.id = orders.customer_id;

Result:

| name | item | | Aisha | Laptop | | Aisha | Mouse | | Ben | Keyboard |

Cara is gone. She has no order, so she has no match, so she does not appear. This is the join most people want most of the time, and it is also the one that quietly drops people.

Picture two circles overlapping. INNER JOIN is only the overlap. Use it when you only care about customers who actually ordered. Do not use it for a report called "all customers", because it will silently leave Cara out.

2. LEFT JOIN: everyone on the left, matches where they exist

SELECT name, item FROM customers
LEFT JOIN orders ON customers.id = orders.customer_id;

Result:

| name | item | | Aisha | Laptop | | Aisha | Mouse | | Ben | Keyboard | | Cara | (empty) |

Cara is back, with an empty space where the item would be. LEFT JOIN keeps every row from the left table, customers, and adds the matching order where one exists. Where there is no match, you get an empty value instead of losing the row.

This is the join you want when the question is "show me all customers, and their orders if they have any". It is also how you find customers who never ordered. Add WHERE orders.order_id IS NULL and you get only Cara.

3. RIGHT JOIN: the mirror image

SELECT name, item FROM customers
RIGHT JOIN orders ON customers.id = orders.customer_id;

Result:

| name | item | | Aisha | Laptop | | Aisha | Mouse | | Ben | Keyboard |

Same result as INNER JOIN here, because every order has a matching customer. RIGHT JOIN keeps every row from the right table, orders, and adds the customer where one exists. In practice I almost never write it. If I want the orders side kept whole, I swap the tables and write a LEFT JOIN instead. Learn what it means so you can read it, then write LEFT JOINs in your own code.

4. FULL JOIN: everyone from both sides

SELECT name, item FROM customers
FULL JOIN orders ON customers.id = orders.customer_id;

Result:

| name | item | | Aisha | Laptop | | Aisha | Mouse | | Ben | Keyboard | | Cara | (empty) |

Again the same as LEFT JOIN here, because there are no orphan orders. FULL JOIN keeps every row from both tables. A customer with no order shows up with an empty item. An order with no customer would show up with an empty name. You will use it less than the others, but when two tables have messy data, it shows you the whole mess at once, including rows that match nothing.

The one mistake that still catches people

Here it is. People write a LEFT JOIN, then add a filter on the right table in the WHERE clause, and wonder why Cara disappeared again.

SELECT name, item FROM customers
LEFT JOIN orders ON customers.id = orders.customer_id
WHERE item = 'Laptop';

Cara has no item. The WHERE clause checks her empty item against 'Laptop', it fails, and she is gone. Your LEFT JOIN just turned into an INNER JOIN, and nothing warned you.

If you need to filter the right table, put the filter in the ON clause, not the WHERE clause.

SELECT name, item FROM customers
LEFT JOIN orders ON customers.id = orders.customer_id AND item = 'Laptop';

Now Cara stays, with an empty item, and Aisha shows only her laptop. The join keeps its promise.

I check for this mistake in every query I write now. It makes reports quietly wrong instead of loudly wrong. Loudly wrong is fine. You notice it. Quietly wrong ships to a manager.

How to remember them

Do not memorise the definitions. Memorise the question each join answers. INNER JOIN: who has both? LEFT JOIN: who is on the left, and what did they do? RIGHT JOIN: the same, from the other side. FULL JOIN: who is anywhere at all?

Run the example above on your own machine, with these exact tables. Change one row. Delete Ben's order. Add a customer with no orders. Watch the results change. Ten minutes with real rows beats an hour of reading definitions.

She typed "junior data analyst" into search. A wall of names came back. Mine was there, somewhere in the middle, and my headline read "Data Analyst at XYZ Corp". She scrolled straight past it. Not because my experience was weak. Because my headline told her nothing she did not already know from the job title filter.

That is the failure. Most headlines are just a job title repeated back. Recruiters search by skills, tools, and problems solved. A headline that only says your current title gives search nothing to grab onto, and gives a human reader no reason to click.

Here is the fix, in ten minutes. Set a timer. It really does take ten minutes, and most of that is deciding which words to keep.

Minute 0 to 2: Pick your three search terms

Open five job posts you actually want. Not dream jobs. Jobs you would take tomorrow. Write down the words that repeat across them.

For a data analyst, those words are usually SQL, dashboards, and Excel or Python. For a designer, Figma, user research, and mobile apps. For a junior developer, React, APIs, and testing.

Pick three. These are the words a recruiter types. If your headline does not contain them, you are invisible in that search, no matter how good your experience section is.

Minute 2 to 6: Rewrite it with this shape

Role plus what you do plus proof. Keep it under 200 characters so it does not cut off on mobile.

Here are three before and after versions, from real profiles I rewrote for friends.

1. The junior data analyst

Before: "Data Analyst at XYZ Corp" After: "Data Analyst | SQL + Python dashboards that cut weekly reporting from 6 hours to 40 minutes"

The second version has the search terms, the tool, and a number. A recruiter can picture the work in one line. The number is the part that makes someone click. It does not need to be huge. Forty minutes saved a week is real work.

2. The fresh graduate looking for a marketing role

Before: "Marketing Graduate | Seeking Opportunities" After: "Marketing Graduate | Ran a student society Instagram from 400 to 3,200 followers in 5 months"

"Seeking opportunities" is the worst phrase on LinkedIn. Every graduate is seeking opportunities. The rewrite replaces it with the one thing this person actually did, with numbers. Recruiters hire evidence, not availability.

3. The career changer moving into UX

Before: "Aspiring UX Designer" After: "UX Designer | Ex-teacher turning classroom research into clear, tested app flows"

"Aspiring" tells a recruiter you have not done the work yet. The rewrite owns the past career instead of apologising for it. Teaching is user research with harder users. Say that.

Minute 6 to 8: Delete the filler

Read your new headline out loud. Cut any word that does not earn its place. Cut "passionate", "results-driven", "detail-oriented", and "hardworking". Nobody has ever been hired because their headline said "hardworking". Those words take up space that a skill or a number could use.

If you have a certification that employers actually search for, keep it. "AWS Certified" earns its place. "Lifelong learner" does not.

Minute 8 to 10: Check it the way a recruiter does

Search LinkedIn for your own three terms. Look at the first ten profiles. Does yours now read like one of the useful ones, or does it still blend in?

Then check it on your phone. LinkedIn cuts headlines off after about 120 characters on a small screen. Put the role and the strongest skill first, the proof second. If the number gets cut off, move it earlier.

What changed for me

I rewrote mine on a Tuesday night. By Friday I had three profile views from recruiters, and one message asking if I was open to a contract role. That had never happened before. My experience did not change in those three days. Only the headline did.

I am not saying a headline gets you a job. It gets you seen, and seen is the step before everything else. A recruiter cannot shortlist a profile she scrolls past.

Ten minutes. Three search terms. One number. Do it tonight, before you send the next application, because the next application lands better when the person who opens your profile can see in one line why you are worth a reply.

The rebuild kept three projects and deleted most of the rest. The replies came after the deletions, not the additions. Here's what I learned about how portfolios actually get read.

How hiring eyes actually move

Nobody reads a junior developer's portfolio like a book. They scan it like a menu in a restaurant they're not sure about. Roughly: land on the page, look for projects, click the first live demo, spend under a minute inside it, check whether the code is viewable, then decide whether your name goes on the maybe pile.

That scan order tells you where the weight sits. The demo and the README carry the whole verdict. Everything else is decoration, and some of it is worse than decoration because it eats the seconds the scan would have spent on your projects.

Caption: A GitHub profile — for most junior roles, this page gets more scrutiny than the portfolio site itself, and the pinned projects do the talking.

What to cut, starting with the section I deleted

Skill bars. The section I deleted entirely. "JavaScript: 85%" raises one question — 85% of what? — and answers none. Worse, it invites the reader to grade you against a scale you invented. A project that uses JavaScript proves more about your JavaScript than any percentage. Cut the bars, the pie charts, and the star ratings. If a skill matters for the role, it should be visible inside a project.

The generic intro. "I am a passionate developer who loves building scalable solutions" could sit on ten thousand portfolios unchanged, which makes it invisible. Replace it with one specific line: what you build, and one true thing about it. "I build small web tools; my last one converts bank CSVs into clean spreadsheets" gives a stranger something to ask you about.

Tutorial clones with no twist. A to-do app, a weather app, and a Netflix-looking homepage tell a reviewer you've completed tutorials, which they already assumed. A clone earns its place only if you changed it in a way that was your idea: the weather app that texts you when rain would hit your commute route is a project; the weather app from the video is homework.

Anything empty or borrowed. A testimonials section with quotes from nobody real, a blog tab with one post from eight months ago, a services list for work you've never been hired to do. Empty sections don't look ambitious. They look abandoned.

The 3-project structure that replaced it

Three projects, presented the same way each time:

1. The most complete one first. Not the newest — the one with a live demo, a real problem, and code you'd defend in an interview.
2. Each project gets four things: one line on the problem, a live link, a screenshot or short recording, and a README that names what you personally did. "Built the checkout flow and the retry logic for failed payments" beats "we built an amazing app" every time. Reviewers know teams exist; they want your slice of it.
3. One project should be slightly odd. The boring clone proves you can follow. The odd one (the tool you built for your uncle's shop, the bot that tracks your bus route) proves you can start. Interviewers ask about the odd one.

Before and after, as a list

Before: Hero with buzzword intro · Skills with bars (14 skills) · About page · 9 projects, no live demos on 6 · Testimonials · Blog (1 post) · Services · Contact form

After: One-line intro naming what I build · 3 projects, each with live demo + README · Short about paragraph at the bottom · Email address, plain text, on the first screen

The page got shorter and the replies got longer. That's the trade.

The uncomfortable summary

Deleting the skills section worked because it was the loudest claim on the page with the least evidence behind it. Your portfolio doesn't need more sections; it needs every section to survive one question: "can I check that?" Live demo, readable code, a README in your own words. If a section can't be checked, it reads as filler, and filler makes the real work look smaller. Cut first, polish second.

Caption: Microsoft Excel — the five formulas below cover most of the copy-paste work in a typical reporting sheet.

1. XLOOKUP — replaces hunting through a second tab by eye

The chore: you have orders in one tab and a price list in another, and you're scrolling back and forth typing prices in by hand. Or worse, using VLOOKUP and praying nobody inserts a column.

=XLOOKUP(A2, Products!$A:$A, Products!$B:$B, "not listed")

Read it left to right: take the product code in A2, find it in the Products tab's column A, bring back the price from column B, and if it's missing, write "not listed" instead of an error. That fourth argument is the whole ballgame — the lookup handles its own failure.

Google Sheets: XLOOKUP exists there too, same shape. Older sheets files may still use VLOOKUP; XLOOKUP reads left to right in plain order and doesn't break when columns move.

2. SUMIFS — replaces filter, select, read the status bar, unfilter, repeat

The chore: "How much did the Dhaka office spend on travel in March?" You filter three times, squint at the total in the status bar, write it on a sticky note, then do it again for every office.

=SUMIFS(Spend!$C:$C, Spend!$A:$A, "Dhaka", Spend!$B:$B, "Travel")

Translation: add up column C, but only rows where column A says Dhaka and column B says Travel. Change the two words and the next answer takes four seconds. Build a small grid of offices down one side and categories across the top, point the formula at the grid cells instead of typed words, and you've built the report you used to assemble monthly.

Google Sheets: SUMIFS works identically.

3. TEXTSPLIT — replaces the Text to Columns wizard, every single import

The chore: a system exports names as "Rahim Uddin, Dhaka, 0171..." in one cell and you need three cells. You select, open the wizard, click through, and repeat next week when the export lands again.

=TEXTSPLIT(A2, ", ")

One formula splits the cell at every comma-space and spills the parts across the row. Next week's export? Paste it under the old one, copy the formula down, done. The chore is now ten seconds old instead of ten minutes.

Google Sheets: no TEXTSPLIT; use =SPLIT(A2, ", "), which does the same job with a slightly older name. Going the other way, TEXTJOIN (available in both) glues cells back together with a separator of your choice.

4. UNIQUE — replaces copy tab, Remove Duplicates, hope you pasted the right range

The chore: you need the clean list of customers, departments, or product codes with each appearing once, for a dropdown or a summary. The manual route copies data to a scratch tab and runs Remove Duplicates, and it's stale the moment the source changes.

=UNIQUE(A2:A500)

The list rebuilds itself whenever the source data changes. Pair it with SORT and it even tidies up after itself: =SORT(UNIQUE(A2:A500)). Feed a dropdown from it and the dropdown stays current forever, which is more than can be said for any list you've ever pasted.

Google Sheets: UNIQUE and SORT both exist with the same names.

5. IFERROR around a lookup — replaces scanning for #N/A by eye

The chore: a column of lookups with a handful of angry #N/A errors scattered through it, and you're scrolling to find each one before sending the file to someone senior.

=IFERROR(XLOOKUP(A2, Products!$A:$A, Products!$B:$B), "check code")

IFERROR runs the formula inside it and, if that formula throws an error, shows your message instead. The file now reads cleanly, and the problems announce themselves in words ("check code") instead of error codes. One warning from experience: don't wrap formulas in IFERROR while you're still building them. It hides real mistakes too, and you'll debug a silent blank cell for twenty minutes. Add it last, as the coat of paint.

Google Sheets: IFERROR works the same way.

The hour, accounted for

Ten minutes of manual lookups, fifteen of filter-and-squint totals, ten on splitting imported text, ten on duplicate lists, ten on error hunting. That's most people's spreadsheet Friday. None of these five formulas is advanced; each is one line. The trick was never learning them, it was noticing that the chore you repeat weekly is a formula wearing a disguise.

Quick spec check, because these numbers shape every verdict below. ChatGPT's free plan runs its smaller GPT-5.6 Luna model with a 27K-token context window and 3 file uploads a day. Claude's free plan gives you its Sonnet model with a 200K-token context window and Artifacts, metered in rolling five-hour sessions (roughly 15–40 messages per session depending on length). Gemini's free plan runs its fast Flash models with a 32K-token context window, Canvas included, and the big 1M window is paid-only. Those three rows explain most of what happened.

Task 1: Explain an error message

The prompt: a real TypeError stack trace from a small Node script, pasted with the offending function.

All three found the actual cause. Nobody hallucinated a fix for a different bug, which was not guaranteed a couple of years ago. The difference was in the shape of the explanation.

Caption: ChatGPT — fastest route from error message to a plain-English cause.

ChatGPT answered shortest: the cause, the line, the corrected line. If you're mid-debugging and annoyed, that's the tone you want. Claude explained the same cause but added why the value became undefined two calls earlier, which is the part that stops the bug coming back next week. Gemini matched ChatGPT on speed and added a short list of related mistakes, decent, slightly more than I asked for.

Verdict: a tie you split by mood. Fast fix, ChatGPT. Understanding that prevents a repeat, Claude.

Task 2: Write a small function with edge cases

The prompt: a function that applies a percentage discount to a list of prices, handling an empty list, negative prices, and non-numeric junk in the input.

Caption: Claude — Artifacts let you see and run small front-end code without leaving the chat.

All three wrote working code and handled the empty list. Claude and ChatGPT both rejected negative prices explicitly; Gemini clamped them to zero, which is a defensible choice it didn't flag as a choice. Small thing, but silent decisions in code are how bugs get tenure.

The real split here is the workspace. When the task is a small self-contained widget (a converter, a form validator), Claude's Artifacts and Gemini's Canvas both render it next to the chat so you can poke it immediately. ChatGPT has Canvas too, but on free the tighter upload and session limits make longer back-and-forth sessions bump into walls sooner.

Verdict: Claude, by a nose, because the edge-case reasoning was spelled out instead of buried in the code.

Task 3: Refactor a messy file

The prompt: one ugly 400-line utility file, pasted whole, asked to split it into named functions without changing behaviour.

This is where the spec sheet stopped being trivia. The file ran to roughly 30K tokens with the prompt attached. That is over ChatGPT free's 27K window and right at the edge of Gemini free's 32K, so both quietly worked from a truncated file and produced refactors that dropped a helper function near the end. Quietly is the problem. Neither threw up a big warning; the output just looked complete.

Caption: Gemini — Canvas and Deep Research are free, but the free context window is the tight ceiling for whole-file work.

Claude's 200K window swallowed the file without blinking, and the refactor kept every function. This isn't a brains contest; it's a bucket-size contest. On paid plans the picture changes (Gemini Pro's 1M window is the biggest bucket here, ChatGPT Plus raises its limits too), but on free, whole-file work has one home.

Verdict: Claude, and it isn't close on the free tier.

Pick by situation

My honest summary after the three tasks: for day-to-day coding questions, the gap between these tools is smaller than the gap between their free-plan limits. Pick the one whose ceiling you won't hit. For most people doing most coding, that means ChatGPT for volume, Claude for anything long or worth understanding properly, and Gemini when the work starts with research. Then stop switching tools and go finish the project; that part, sadly, none of them do for you.

That token is a promise. Everything else in this article is just the token system with code attached.

The token, in code

A promise is an object that stands in for a result that doesn't exist yet. It starts pending (you're holding the token, waiting). It ends in exactly one of two states:

• Fulfilled — your number is called. You collect the food. This is .then().
• Rejected — the kitchen failed. Someone tells you why. This is .catch().

const order = getFoodToken(); // returns a Promise

order
  .then(meal => eat(meal))                          // token called: collect your food
  .catch(problem => orderSomethingElse(problem));   // kitchen ran out: do this instead

fetch() hands you a token. The menu hasn't downloaded yet, but you already have the object, and you can attach instructions for both endings right now:

fetch("https://example.com/menu")
  .then(response => response.json())
  .then(menu => showMenu(menu))
  .catch(err => showError("Menu failed to load"));

Read it as a sentence: fetch the menu, then read it, then show it. If anything in that chain fails, the catch at the bottom handles it. One catch covers the whole chain, the same way one announcement covers everyone holding a token from that kitchen.

async/await is the same kitchen, better seating

async and await don't replace promises. They let you write the token flow as if you had a waiter:

async function loadMenu() {
  try {
    const response = await fetch("https://example.com/menu");
    const menu = await response.json();
    showMenu(menu);
  } catch (err) {
    showError("Menu failed to load");
  }
}

await means: pause here until this token is called, then hand me the food. The try/catch is your .then() and .catch() wearing different clothes. Underneath, it is the same promise. Use whichever reads better in the code you're writing; most people find await easier once a function has three or four steps.

The 3 mistakes that cause most promise bugs

1. Forgetting to return inside .then(). This one bites everyone.

// broken: the next .then receives undefined
fetch(url)
  .then(response => { response.json(); })
  .then(data => console.log(data)); // undefined

// fixed: return the next token
fetch(url)
  .then(response => response.json())
  .then(data => console.log(data));

Why: each .then() passes its return value to the next one. response.json() itself returns a promise, and if you don't return it, the chain doesn't wait for it. It's like collecting your token number but never handing it to the person at the next counter. The food exists; nobody brings it to you.

2. Mixing callbacks into a promise chain. You'll meet older functions that want a callback instead of returning a promise. Don't thread them through a chain. Wrap them once, at the edge:

const wait = ms => new Promise(resolve => setTimeout(resolve, ms));

await wait(1000); // a clean token, no callback nesting

One wrapper, written once, and the rest of your code stays flat and readable.

3. Skipping .catch(). A rejected promise with no catch doesn't stop your program politely. It produces an unhandled rejection, which usually means the user stares at a spinner forever and you get a confusing console warning hours later. In token terms: the kitchen called out that your order failed, and nobody at your table was listening. Every chain gets a catch, or every async function gets a try/catch. No exceptions, even for code you're "sure" won't fail. Kitchens run out of things.

The 10-line cheat summary

1. A promise is a token for a result that isn't ready yet.
2. Pending means you're still holding the token.
3. Fulfilled means the food arrived: .then() runs.
4. Rejected means the kitchen failed: .catch() runs.
5. fetch() returns a promise, not data.
6. Return values inside .then(), or the next step gets undefined.
7. Returning a promise inside .then() makes the chain wait for it.
8. await pauses an async function until the token is called.
9. try/catch around awaits is .then()/.catch() in a calmer format.
10. No catch means silent failure. Always attach one.

Keep the token picture in your head for a week and promises stop being a topic you revise and start being a thing you just read. The syntax was never the hard part. The waiting was.

That software is an ATS, an applicant tracking system, and the good news is that it is not judging your career. It is doing three much dumber jobs, and all three can be fixed in about 15 minutes.

What an ATS actually does

Strip away the marketing and an ATS does this:

1. Parse. It converts your file into plain text and tries to sort it into boxes: name, contact details, job titles, employers, dates, education, skills. If it cannot find the boxes, parts of your history simply vanish.
2. Match. It compares the text it extracted against the job description, looking for the skills, tools and titles the employer asked for.
3. Rank. It scores and sorts the pile, so a recruiter works from the top down. Many resumes are never opened by a person at all.

That is it. No taste, no judgement, no sense that your startup job title meant three roles at once. If the parser drops your experience because it was hiding inside a text box, the ranker cannot reward what it never saw.

The 6 formatting mistakes that break parsing

1. Tables and multi-column layouts. The classic two-column resume with a tidy sidebar is the single biggest offender. Many parsers read straight across the page, so your sidebar skills get stitched into the middle of your job descriptions and the whole thing turns into soup.

2. Headers and footers. Plenty of systems skip headers and footers entirely. If your name, email and phone number live in the header, the system may process your entire application without your contact details.

3. Icons, skill bars and graphics. That neat row of icons and the little bars showing "Excel: 4 out of 5" contain no readable text. The parser sees blank space where your skills were supposed to be.

4. Decorative fonts. A display font can break character extraction, turning clean text into garbled output. Stick to standard fonts the way you would stick to a standard file name.

5. The wrong file type. Unless the posting says otherwise, send a .docx or a text-based PDF. A PDF exported from a design tool as one big image is, to the parser, a photograph of a resume. It reads almost nothing from it.

6. Keyword-stuffed walls. Swinging to the other extreme does not work either. A hidden block of repeated keywords in white text or a dense skills paragraph copied wholesale from the posting reads as spam to modern systems, and a human who spots it will bin the application on principle. Keywords belong inside real bullet points about work you actually did.

The 15-minute fix

You need your resume file and one real job description you want to apply for. Timer optional but encouraged.

Minutes 0–3: Flatten the layout. Switch to a single column, newest job first. Move your name, email, phone and location out of the header and into the top of the document body. Delete skill bars, icons and text boxes.

Minutes 3–8: Fix the skeleton. Use plain headings a parser recognises: Summary (optional), Experience, Skills, Education. Under Experience, every role gets the same pattern: job title, company, dates on their own line. Use standard bullet points, the round kind, not custom glyphs.

Minutes 8–12: Borrow the job's own words, honestly. Read the job description and list its required skills and tools. Go through that list and, wherever you genuinely have the skill, make sure your resume uses the employer's exact term for it. If they wrote "data analysis" and you wrote "number crunching", theirs wins. Do not add anything you cannot talk about in an interview. This step is translation, not fiction.

Minutes 12–15: Save and test. Save as .docx (or a text-based PDF if the posting asks for PDF) with a plain file name like Firstname-Lastname-Resume.docx. Then run the free checks below and fix whatever they flag about unreadable sections before you send anything.

Check your own resume, free

Two tools will show you roughly what the robot sees:

• Jobscan lets you paste your resume against a job description and gives you a match rate with the missing keywords listed. The free account includes 5 scans a month, which is plenty if you save them for jobs you seriously want.

Jobscan: your resume scored against a real job description, missing keywords shown.

• Resume Worded gives you a free score out of 100 with a partial report, and re-uploads are free, so you can fix and re-check. The full line-by-line report is a paid Pro feature, but the free score plus its headline feedback already catches most formatting and weak-bullet problems.

Resume Worded: a free score out of 100, with recruiter-style feedback on your bullets.

Neither tool is the employer's actual system, so treat the scores as a smoke test, not a verdict. If both can read your resume cleanly, the real thing almost certainly can too.

One last thing: the 30 words a recruiter actually reads

Pass the robot and you meet the human, who is also fast. Recruiters skim a resume in seconds, and the honest version of the famous statistic is that only a small slice of the page gets real attention on the first pass: your last job title, your last employer, your dates, and the first bullet or two under that role. Call it roughly 30 words deciding whether the rest gets read.

So put your strongest, most measurable result in the first bullet of your most recent job. "Answered support tickets" survives parsing and dies on the skim. "Cut average ticket response time from 9 hours to 2" survives both.

And none of this means your resume has to be ugly. Clean, well-spaced, single-column resumes look professional to humans and readable to software at the same time. The robot is not asking you to be boring. It is asking you to be legible. Fifteen minutes, and you are.

A beginner does not need to buy anything to learn Python well. What a beginner needs is the right free resources, used in the right order, with most of the time spent writing code. Here are the six that, together, cover the paid shelf. Every screenshot below is the actual starting page of that resource, as a learner would see it — no mockups.

1. The official Python tutorial and docs (docs.python.org)

What it is: The tutorial and reference documentation written and maintained by the Python project itself.

The official Python tutorial — the reference every other resource on this list quietly assumes you will end up reading.

Format: Web documentation: a guided tutorial, then a full reference for the language and standard library.

Time cost: The tutorial takes roughly 10 to 15 hours if you type the examples as you go. The docs themselves are not something you finish; you keep them open in a tab for years.

Best at: Being right. If a blog post, a video, and the docs disagree, the docs win. Nothing covers the standard library as completely.

Honest limit: It assumes you already think a little like a programmer, so true first-timers can find it dense and dry, with almost no exercises or coaching. Use it as your reference and fact-checker, not as your only teacher.

2. Harvard CS50P (edX audit / cs50.harvard.edu)

What it is: Harvard's Introduction to Programming with Python, taught by David Malan's CS50 team. Free to audit on edX, and the lectures and problem sets are also free on Harvard's own site. Only the optional verified certificate costs money.

The CS50P course page — ten weeks of lectures and problem sets, free to audit; only the optional certificate costs anything.

Format: Video lectures (10 weekly units), problem sets with automatic checking, and a final project.

Time cost: Harvard suggests 3 to 9 hours a week for 10 weeks — 40 to 90 hours in total for most self-learners.

Best at: Teaching quality and problem sets. The lectures explain ideas clearly, and the problems make you write real programs from week one: functions, file input and output, regular expressions, unit tests, and a first taste of classes near the end.

Honest limit: It stays in the terminal from start to finish. No web frameworks, no pandas, no apps with windows and buttons. If web development is your goal, CS50P is a strong first step, not the whole road.

3. Python for Everybody — PY4E (py4e.com)

What it is: Dr. Charles Severance's course from the University of Michigan: a free textbook, video lectures, and auto-graded assignments, all openly licensed and free on py4e.com (also on Coursera, edX, and freeCodeCamp).

Python for Everybody at py4e.com — the book, the lectures, and the graded assignments, free on one page.

Format: Book chapters matched with short videos and auto-graded assignments in the browser.

Time cost: Around 40 to 60 hours at your own pace, if you do the assignments properly instead of skimming.

Best at: Absolute beginners, especially people without a maths or engineering background. The pace is gentle, the examples use real data early (files, web pages, databases), and the tone never makes you feel stupid.

Honest limit: The gentle pace cuts both ways: if you already know another language, the first half feels slow. It also stops before advanced topics such as decorators, generators in depth, or type hints.

4. Automate the Boring Stuff with Python (automatetheboringstuff.com)

What it is: Al Sweigart's best-selling beginner book, published free to read online in full under a Creative Commons licence. The print copy is the same book people pay for.

Automate the Boring Stuff online — the complete book, chapter by chapter, free to read.

Format: A complete book online, 24 chapters in the current edition, with practice questions and a small project at the end of most chapters.

Time cost: Roughly 40 to 60 hours if you do the projects — most readers finish in four to six weeks of part-time study.

Best at: Making Python useful fast. After the basics, it goes straight at real tasks: renaming and organising files, working with Excel sheets and PDFs, pulling data from web pages. This is the resource that turns "I am learning Python" into "Python saved me an afternoon."

Honest limit: It teaches practical scripting, not computer science. Testing, program design, and object-oriented thinking get light coverage, and a few examples depend on websites that change over time.

5. freeCodeCamp — Scientific Computing with Python

What it is: freeCodeCamp's Python certification path: a browser-based curriculum where you learn by building projects step by step, plus free full-length Python courses on YouTube. freeCodeCamp is a nonprofit; the courses carry no ads and no paywall.

freeCodeCamp's curriculum page — Python Certification sits in the same list as the web tracks, and signing in to save progress is free.

Format: Interactive lessons in the browser, nothing to install, ending in a set of required projects for the certificate.

Time cost: Plan on a few months part-time. freeCodeCamp estimates its certifications at around 300 hours, though many learners finish the core material faster.

Best at: People who stall on video courses. You type code from the first lesson, feedback is immediate, and there is nothing to install — handy if your computer is old or shared.

Honest limit: The explanations are thinner than CS50P or PY4E. Follow the steps passively and you can finish lessons without fully understanding them — pause, experiment, and break things on purpose to get the full value.

6. Exercism — the Python track

What it is: A practice platform with a large set of Python exercises, automatic test feedback, and optional code review from human volunteer mentors. All of it, mentoring included, is free; Exercism is funded by donations.

The Exercism Python track — small exercises with tests to pass, and an optional human mentor at the end of them.

Format: Small exercises, each with tests your code must pass, in the browser or in your own editor.

Time cost: This one never really ends, which is the point. Budget two or three exercises a week, 20 to 60 minutes each, alongside your main course.

Best at: Turning "I understood the lesson" into "I can write this myself." Solving small problems, reading other people's solutions afterwards, and getting a mentor's comments is the closest free equivalent of a classroom.

Honest limit: It is practice, not teaching. Exercism assumes you can look concepts up yourself, and mentor replies can take a while because the mentors are volunteers.

Use them in this order

1. Pick one main course and finish it. PY4E if you want the gentlest start, CS50P if you want harder problem sets, freeCodeCamp if you only learn by typing. One. Not all three at once.
2. Keep the official docs open from day one. Every time a course mentions a function or a module, spend two minutes reading its docs page. This habit pays off for years.
3. From week three, add Exercism. Three exercises a week, every week, while the main course continues.
4. After the main course, work through Automate the Boring Stuff's project chapters, skipping the basics you already know.
5. Finish with a test you did not take. If you started with PY4E, do a few CS50P problem sets cold; if you started with CS50P, do freeCodeCamp's final projects. Unfamiliar formats show you what you actually retained.

When does paying for a book make sense?

Honestly? Sometimes. You are never paying for secret knowledge — everything above is the same Python. You are paying for one voice, one sequence, everything edited to fit together, readable on paper or offline, with no tab-hopping between six sites. If that convenience keeps you studying, it is money reasonably spent. If money is tight, it is not a barrier: the free shelf above is not the cheap substitute. Used properly, it is the real thing.

The catch: the hour has to be spent the right way. Here is the split that works, and the plan that follows from it.

How to spend the hour

15 minutes: learn one small thing. One concept. Not a chapter, not a playlist — one idea, like "what a dictionary is" or "how a while loop exits."

45 minutes: write code that uses it. Type programs by hand. Break them on purpose. Fix them. The learning happens in the fixing, not in the watching.

If you reverse this ratio — 45 minutes of video, 15 minutes of code — you will feel like you are learning and retain almost nothing. This is the single most common reason beginners quit: they confuse recognition ("I've seen this before") with ability ("I can write this myself").

One more rule: keep a mistakes notebook. Every bug that costs you more than five minutes goes in it, with one line about what was wrong. Review it every Sunday. Your notebook becomes a map of your own weak spots, which no course can give you.

The 12-week plan

Weeks 1–2 — The basics, as programs Variables, numbers, strings, input and output, if/else. Write tiny programs daily: a temperature converter, a tip calculator, a number-guessing game, a program that counts the vowels in your name. By the end of week 2 you should have written about 15 small programs. Small is fine. Finished is what matters.

Weeks 3–4 — Data and loops Lists, dictionaries, for loops, while loops. Programs: a shopping list that adds and removes items, a word-frequency counter for a paragraph of text, a contact book stored in a dictionary. This is where most people stall, because loops feel abstract. They stop feeling abstract after the tenth program, not before.

Weeks 5–6 — Functions, files, and errors Break your programs into functions. Read and write text files. Learn try/except by deliberately feeding your programs bad input. Project for week 6: a personal expense tracker that saves entries to a file and prints a weekly total. It will be ugly. Ship it anyway.

Weeks 7–8 — Object-oriented basics Classes, objects, methods — only as much as you need to model simple things: a BankAccount class, a Student class with grades. Do not spend a month here. Two weeks is enough for the fundamentals; depth comes later, when a real project demands it.

Weeks 9–10 — The standard library and a real project Work with dates, random, os, and JSON. Then build one complete project start to finish: a quiz app, a file organizer that sorts your downloads folder, a simple web scraper for a page you actually read. One finished project teaches more than five half-finished ones.

Weeks 11–12 — Write from memory Now change the exercise. Take programs you wrote in weeks 1–6, close them, and write them again from memory. Where you get stuck is exactly what you never learned — go back and fix only that. Finish the twelve weeks by re-writing your week 6 expense tracker from scratch. Compare the two versions. The difference is your progress, made visible.

What to honestly expect at the end

After twelve weeks of this you will not be a Python expert, and anyone who promises that in 84 hours is selling something. What you will have:

• The fundamentals, genuinely in your fingers, not just in your notes
• About 50–60 programs you wrote yourself
• Two finished projects
• The ability to sit down and write a small program without a tutorial open

That is a real foundation. From there, interviews, bigger projects, or a second language all become much easier — because the hard part was never the syntax. It was learning how to learn it. One hour a day, spent writing code, is how that happens.

So when I put together Python Interview Prep, I built it around writing: 140 complete programs in five rounds (warm-ups, logic classics, core Python, OOP, job-level problems) and 100 interview questions. Every program is printed with the real output it produces — each one was actually run, so what you see is what your screen will show.

Here are three programs from the book, exactly as they appear in it.

Program 24 — Print the Fibonacci Sequence With a Loop

What the interviewer is testing: Loop control and updating two variables in step. The simultaneous assignment a, b = b, a + b is the line they are listening for.

count = 10
a = 0
b = 1
print("Fibonacci sequence:")
for i in range(count):
    print(a, end=" ")
    a, b = b, a + b
print()

Output:

Fibonacci sequence:
0 1 1 2 3 5 8 13 21 34

Program 26 — Check Whether a Number Is an Armstrong Number

What the interviewer is testing: Turning a number into digits, and raising each digit to the right power. The classic trap is using power 3 for every number — the power is the number of digits.

number = 153
digits = str(number)
power = len(digits)
total = 0
for ch in digits:
    total = total + int(ch) ** power
print("Number:", number)
if total == number:
    print(number, "is an Armstrong number.")
else:
    print(number, "is not an Armstrong number.")

Output:

Number: 153
153 is an Armstrong number.

Program 60 — FizzBuzz

What the interviewer is testing: Whether you check the combined case first. If you test % 3 before % 15, FizzBuzz never prints — that ordering mistake is the whole point of the question.

for number in range(1, 21):
    if number % 15 == 0:
        print("FizzBuzz")
    elif number % 3 == 0:
        print("Fizz")
    elif number % 5 == 0:
        print("Buzz")
    else:
        print(number)

Output:

1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
11
Fizz
13
14
FizzBuzz
16
17
Fizz
19
Buzz

Read 25 programs free

The first 25 programs plus 10 of the Part B questions are free to read online, no email needed: aheadkit.me/free-chapter/python-interview-prep

The full book (135 pages, $7.99, one payment) adds rounds 2–5 — comprehensions, decorators, generators, OOP, threads, async, and the algorithm problems that decide offers — plus all 100 questions and a 7-day practice plan for when the interview is already booked: Python Interview Prep on AheadKit

If you have never written Python at all, this book will be too much, too fast — it assumes variables, loops and functions. Start with a beginner book first, then come back and sharpen up.

Good luck in the interview. Practise by writing, and the blank editor stops being the scary part.