TL;DR

GPT doesn’t see letters; it sees tokens (subword chunks). “strawberry” becomes [”straw”, “berry”], which is why counting R’s is hard. This single design choice explains mysterious behaviours, API costs, and why your prompts sometimes get truncated. Understanding tokens is now as fundamental as understanding databases for anyone building with LLMs.

You type:

“How many R’s are in strawberry?”

Early versions of ChatGPT would often reply:

“There are two R’s in strawberry.”

Wrong. There are three.

Modern models like GPT-5 usually get this right. But they’re getting it right despite how they read text, not because of it.

When you type “strawberry,” the model does not see s-t-r-a-w-b-e-r-r-y. It sees two tokens, something like:

To count the R’s, the model has to work around its own representation. It needs to reason about spelling even though the architecture never promised it could see characters at all.

That single design choice, how text is chopped up into tokens, explains a lot of behaviour that feels mysterious:

• Why letter counting, reversing strings, and simple ciphers are surprisingly hard

• Why API costs spike with certain kinds of content

• Why does your prompt sometimes get silently truncated, and instructions vanish

If you’re building production systems on top of LLMs, tokenization is not an academic detail. It’s the first place bugs and costs start to show up.

💡 All the code you see here (and a lot more) is in the MiniGPT repo with Colab notebooks you can run yourself.

Why Understanding This Matters Right Now

Three years ago, knowing how to call an API was enough. Today, understanding how LLMs work is becoming as fundamental as understanding databases or networking.

Here’s why this specific topic tokenization is worth your time.

1. You’re Already Building With LLMs

If you’re:

• Integrating ChatGPT in your product

• Using GitHub Copilot

• Indexing documents with embeddings

...you’re already making architectural decisions around tokens, context windows, and costs.

One line of code that ignores token limits can:

• Truncate your prompt in production

• Drop the most important part of a document

• Double your bill without changing a single word of UI copy

2. The Abstraction Is Leaking

The nice mental model of “I send text, I get text back” holds until:

• The model hallucinates after a small prompt change

• A long prompt quietly stops following your last instruction

• A user pastes some code, and your token counts explode

At that point, “vibes-based” prompt engineering stops working. The people who understand tokens, attention, and probabilities are the ones who can actually debug and improve the system.

3. The Market Has Moved

“LLM experience” on a job description rarely means “can call the OpenAI API.”

It usually means:

• Can reason about context limits

• Can estimate and control token costs

• Can design systems that combine LLMs with traditional components

You don’t need to become a research scientist. But you do need to know what’s really happening when you send a text to a model.

4. It’s Much Less Scary Than It Looks

You already know the ingredients:

• Strings

• Arrays

• Integers

• Some probability

We’re just going to put those pieces together in a way that explains what GPT is doing behind the scenes.

By the end of this series, when the next major model ships, you won’t just read the marketing page. You’ll look for:

• What tokenizer does it use

• How large is the context window really in practice

• Where the failure modes are going to show up

The Core Insight: Tokens, Not Letters

Here’s what you think happens when you send a text to GPT:

“strawberry”
  ↓
[’s’, ‘t’, ‘r’, ‘a’, ‘w’, ‘b’, ‘e’, ‘r’, ‘r’, ‘y’]

Here’s what actually happens:

“strawberry”
  ↓ [Tokenizer]
[”straw”, “berry”]
  ↓ [Token IDs]
[496, 15717]

GPT never sees letters. It only sees integers. Every model call is “take this sequence of integers and predict the next integer.”

That one detail explains a lot:

• Letter counting is not “free” like it is for humans

• String reversal is hard without an explicit character-level tool

• Small whitespace or punctuation changes can alter the meaning the model perceives

What Is Tokenization?

Tokenization is the step that turns text into something a neural network can work with.

Conceptually:

Your sentence
    ↓
Tokenizer
    ↓
[Tokens]
    ↓
[Token IDs]
    ↓
Embeddings and transformer layers

Example:

Everything that looks “smart” later is built on top of this representation.

Why Not Just Use Characters?

The obvious question is: why not just give the model one token per character and be done with it?

Character-Level

“Hello world”
→ [”H”, “e”, “l”, “l”, “o”, “ “, “w”, “o”, “r”, “l”, “d”]
→ 11 tokens

Pros:

• Simple

• Fixed vocabulary (roughly 256-byte values)

• Never out-of-vocabulary

Cons:

• 5-10× more tokens for the same text

• Smaller effective context window

• The model has to learn everything from scratch at the character layer

Word-Level

“Hello world”
→ [”Hello”, “world”]
→ 2 tokens

Pros:

• Intuitive

• Each token has a clear meaning

Cons:

• Vocabulary explodes into the millions

• Fails on new words, typos, usernames, weird formatting

Subword-Level (What GPT Uses)

Subword tokenization aims for a balance:

• Common words become single tokens

• Rare words are split into smaller pieces

• Everything can still be represented

“ChatGPT”          → [”Chat”, “GPT”]
“unbelievableness” → [”un”, “believ”, “able”, “ness”]
“strawberry”       → [”straw”, “berry”]

This choice is what makes models like GPT feasible in the first place.

How Byte Pair Encoding (BPE) Works

Modern GPT-style models use a variant of Byte Pair Encoding.

You don’t need to memorize the algorithm, but understanding the idea pays off.

The Training Idea, In Plain Language

1. Start with individual bytes as your basic tokens

2. Look at a huge corpus of text

3. Find the most frequent pair of tokens that occur together

4. Merge that pair into a new token

5. Repeat until you have the desired vocabulary size

Widespread patterns become tokens:

• “the”

• “ing”

• “ion”

• “ ChatGPT”

Rare patterns stay as combinations of existing tokens or bytes.

Why This Is Powerful

BPE discovers structure without any linguistic rules. It will naturally learn:

• Suffixes like “ing”, “ness”, “tion”

• Prefixes like “un”, “re”

• Common code patterns like def , import , return

From the model’s point of view, tokens are just IDs. But the tokenizer has arranged things so that frequent, meaningful chunks have their own IDs.

A Tiny Longest-Match Tokenizer

To make this concrete, here’s a tiny “toy” tokenizer that behaves a bit like a BPE tokenizer at runtime.

We won’t train anything here. We just assume a tiny vocab that already contains some subwords:

def simple_tokenizer(text, vocab):
    “”“Greedy longest-match tokenizer.”“”
    tokens = []
    i = 0

    while i < len(text):
        matched = False

        # Try longest possible substring first
        for length in range(len(text) - i, 0, -1):
            piece = text[i:i + length]
            if piece in vocab:
                tokens.append(vocab[piece])
                i += length
                matched = True
                break

        if not matched:
            # Unknown token
            tokens.append(vocab.get(”<UNK>”, 0))
            i += 1

    return tokens


# Our tiny vocabulary
vocab = {
    “Hello”: 101,
    “ world”: 102,
    “!”: 103,
    “straw”: 201,
    “berry”: 202,
    “<UNK>”: 0,
}

print(simple_tokenizer(”Hello world!”, vocab))
# Output: [101, 102, 103]

print(simple_tokenizer(”strawberry”, vocab))
# Output: [201, 202]

The important part is the strategy: always take the longest matching piece. Real GPT tokenizers follow the same greedy idea, just with a much larger and more complex vocabulary.

The actual BPE training and a fuller tokenizer implementation live in the repo. You don’t need all of that in your head to benefit from understanding what it’s doing.

Real Tokenization With tiktoken

Now, let’s look at how OpenAI’s tokenizer, tiktoken, sees the same text.

import tiktoken

encoder = tiktoken.get_encoding(”gpt2”)  # close enough for examples

# Simple sentence
text = “Hello world!”
tokens = encoder.encode(text)

print(tokens)
# Output: [15496, 995, 0]

print([encoder.decode([t]) for t in tokens])
# Output: [’Hello’, ‘ world’, ‘!’]

# The strawberry example
text = “strawberry”
tokens = encoder.encode(text)

print(tokens)
# Output: [41449, 19772]

print([encoder.decode([t]) for t in tokens])
# Output: [’straw’, ‘berry’]

Key observations:

• “Hello world!” is 3 tokens, not 12

• “strawberry” is 2 tokens, even though it has 10 characters

• “straw” and “berry” are meaningful chunks that the tokenizer discovered

Spaces Matter More Than You Think

One of the surprising details in GPT tokenizers is how they handle spaces.

text1 = “hello”
text2 = “ hello”

tokens1 = encoder.encode(text1)
tokens2 = encoder.encode(text2)

print(tokens1, [encoder.decode([t]) for t in tokens1])
print(tokens2, [encoder.decode([t]) for t in tokens2])

Typical output looks like:

[31373] [’hello’]
[23748] [’ hello’]

So:

• “hello” is one token

• “ hello” (with a leading space) is also one token

• But they are different tokens

The tokenizer encodes the space into the token itself. That’s why models usually generate “ world” as one token instead of “ “ followed by “world”.

This Has Implications

• Adding or removing spaces changes the token sequence

• Slightly different prompts can have different costs and behaviour, even if they look the same at a glance

• When you’re debugging strange behaviour, whitespace can be part of the story

Gotchas That Actually Bite You

Once you know how tokens work, you start to see a few failure modes over and over.

1. Token Counts Are Not Intuitive

This kind of thing is common:

examples = [
    “cat”,
    “cats”,
    “ChatGPT”,
    “GPT-4”,
]

for text in examples:
    tokens = encoder.encode(text)
    print(f”{text!r}: {len(tokens)} token(s)”)

You might get:

‘cat’: 1 token
‘cats’: 1 token
‘ChatGPT’: 2 tokens      # [’Chat’, ‘GPT’]
‘GPT-4’: 3 tokens        # [’G’, ‘PT’, ‘-4’]

So a short string like “GPT-4” can be more expensive than it looks, especially when you’re dealing with a lot of IDs, symbols, or emojis.

Why “GPT-4” becomes 3 tokens: The tokenizer sees ‘G’ as rare enough to be separate, ‘PT’ as a common chunk (from words like “ception”), and ‘-4’ as a number with punctuation. This is why brand names and technical identifiers often tokenize unexpectedly.

2. Token Limits Are Hard Limits

Models have a fixed context size, expressed in tokens, not characters or words.

For example, if a model has an 8,192-token limit:

• You cannot send 8,193 tokens

• Anything beyond the limit is effectively invisible to the model

• In many APIs, the excess text is silently truncated from the end

That’s how you get bugs like:

• “The model ignored the last instruction”

• “The summary stops mid-sentence”

• “Some sections of the document were not considered”

The text is not being ignored on purpose. It simply never made it into the context window.

3. Word-Count Heuristics Lie To You

Rough mental rules like:

• “1 token ≈ 4 characters”

• “1 token ≈ 0.75 words”

...are fine for back-of-the-envelope estimates, but they’re not accurate enough for anything serious.

The only reliable approach if you care about correctness or cost is:

tokens = encoder.encode(text)
actual_count = len(tokens)

This is especially true for:

• Code

• Mixed-language content

• Emoji-heavy text

• Anything with a lot of punctuation or math

Token Efficiency Across Text Types

Different kinds of text “compress” differently into tokens.

In practice, you’ll see patterns like:

Content Type Typical Chars/Token Plain English prose 4-5, Code 2-3, Math notation, emoji, rare symbols 1-2

The Practical Point

• A 1,000-character essay might be ~230 tokens

• A 1,000-character code snippet might be ~400 tokens

If your product sends a lot of code to an LLM, your token bill will not look like your character count.

A Small Helper To Inspect Tokenization

Here’s a short helper that you can drop into your own code to understand how a string is being tokenized.

import tiktoken

encoder = tiktoken.get_encoding(”gpt2”)

def analyze(text: str) -> None:
    “”“Analyze how text is tokenized.”“”
    tokens = encoder.encode(text)
    pieces = [encoder.decode([t]) for t in tokens]

    print(f”Text: {text!r}”)
    print(f”Characters: {len(text)}”)
    print(f”Tokens: {len(tokens)}”)
    if tokens:
        print(f”Chars per token: {len(text) / len(tokens):.2f}”)
    print(”\nToken breakdown:”)
    for i, (tid, piece) in enumerate(zip(tokens, pieces)):
        # Make whitespace visible
        visible = (
            piece
            .replace(” “, “␣”)
            .replace(”\n”, “↵”)
        )
        print(f”  {i:2d}. id={tid:5d} piece={visible!r}”)

# Try it out
analyze(”Hello world!”)
print()
analyze(”strawberry”)

Output example:

Text: ‘Hello world!’
Characters: 12
Tokens: 3
Chars per token: 4.00

Token breakdown:
   0. id=15496 piece=’Hello’
   1. id=  995 piece=’␣world’
   2. id=    0 piece=’!’

Use it to try:

• Your name

• Your product name

• A typical user prompt

• A code snippet from your app

You’ll very quickly build intuition for what’s cheap, what’s expensive, and where surprising splits happen.

All of this is built out more fully in the notebook, including nicer formatting and comparison helpers.

The Bigger Picture

Tokenization is only the first step in the pipeline, but it sets the ground rules for everything that follows.

It:

• Defines what the model can see at once

• Shapes how meaning is represented

• Controls how much you pay

• Introduces quiet failure modes if you ignore it

Once text is tokenized, the model throws away the original character boundaries. From that point on, it’s all vectors and matrices.

Understanding this step makes the next step much easier to follow.

In Part 2 we’ll take those token IDs and turn them into embeddings: high-dimensional vectors that capture meaning in a way that allows the model to reason. That’s where analogies like king - man + woman ≈ queen come from. We’ll build the embedding layer ourselves so you can see that this is not magic either.

What To Do With This As A Builder

If you’re building with LLMs today, you can start applying this immediately:

1. Log token counts for your prompts and responses

2. Add checks that truncate or summarize text before you hit model limits

3. Run your own product prompts through a tokenization helper and look for surprises

4. Refine prompt templates to reduce tokens without losing meaning

You don’t need to obsess over every token, but you do need to know when tokens start to dominate your costs and your failure modes.

Repo: github.com/naresh-sharma/mini-gpt
Colab: Tokenization notebook
Discussion: GitHub Discussions

This is Part 1 of the MiniGPT series.

→ Series introduction

Most developers use LLMs every day, but few understand how they actually work.
When prompts break or models hallucinate, we treat it like magic failing instead of software misbehaving.
This series changes that.

MiniGPT is a hands-on guide to understanding language models by building one from scratch—small enough to grasp fully, real enough to work.

What You’ll Build

By the end of this series, you’ll build a working MiniGPT that can:

• Process text and generate human-like responses

• Understand context across multiple sentences

• Learn patterns from training data

• Predict the next word with surprising accuracy

More importantly, you’ll understand:

• Why LLMs sometimes “hallucinate”

• Why prompt engineering works (and when it doesn’t)

• How to debug LLM behaviour in production

• The real constraints and tradeoffs of these systems

Who This Is For

This series is for you if:

✅ You’re a developer who uses LLMs (ChatGPT API, Copilot, etc.)
✅ You want to understand how they actually work
✅ You’re comfortable with Python and basic math (matrix multiplication, probability)
✅ You learn best by building, not just reading

This series is NOT for you if:

❌ You want a quick “10 ChatGPT prompts” listicle
❌ You’re looking for cutting-edge research papers
❌ You want to use OpenAI’s API without understanding the internals

The Approach: Learn by Building

Each post follows the same structure:

1. A real problem - Why does GPT behave this way?

2. The concept - Clear explanation with visuals

3. Build it - Working code you can run and modify

4. Real-world implications - How this affects production systems

No hand-waving. If we use a concept, we implement it.
No prerequisites beyond Python. I’ll explain the math as we go.
No fluff. Every section moves you toward understanding.

The Roadmap

Part 1: Tokenization (This Week)

Why GPT can’t count letters in “strawberry”

• How text becomes numbers

• Build a simple tokenizer

• Why token limits break your prompts

Part 2: Embeddings

How “king - man + woman = queen” actually works

• Turning tokens into vectors

• Semantic similarity

• Building an embedding layer

Part 3: Attention Is All You Need

The mechanism that changed everything

• Self-attention from scratch

• Why transformers replaced LSTMs

• Implementing multi-head attention

Part 4: The Transformer Architecture

Putting all the pieces together

• Encoder-decoder structure

• Positional encoding

• Building a mini transformer

Part 5: Training and Generation

Making it actually work

• Training on real text

• Sampling strategies

• Why temperature matters

Part 6: Fine-tuning and Prompt Engineering

Making it useful

• Transfer learning

• Prompt design

• Production deployment patterns

What You’ll Need

• Python 3.8+ (we’ll use PyTorch, but I’ll explain every line)

• Basic linear algebra (don’t worry, I’ll review as we go)

• 30-45 minutes per week (reading + coding exercises)

• Curiosity (most important)

All code is available on GitHub with Colab notebooks you can run in your browser. No GPU required.

What Makes This Different

There are plenty of transformer tutorials out there. Here’s what makes this one different:

1. Production-focused
Every concept connects to real problems you’ll face building LLM apps. Not just “here’s how attention works,” but “here’s why your context window fills up faster than expected.”

2. Complete implementation
We build everything from scratch. No mysterious library calls. When we use PyTorch, you’ll understand what it’s doing under the hood.

3. Progressive complexity
Each part builds on the last. By Part 3, you’ll be reading transformer papers and actually understanding them.

4. Debuggable intuition
The goal isn’t memorization, it’s developing intuition. When something breaks, you’ll know where to look and why.

The Philosophy

Understanding > Completion

I’d rather you deeply understand Parts 1-3 than skim through all 6. Each part is designed to give you a mental model you can build on.

Build > Read

Every concept includes working code. Type it out. Break it. Fix it. That’s where understanding happens.

Why > How

We don’t just implement—we explain the tradeoffs. Why BPE instead of character-level? Why self-attention instead of RNNs? Understanding the “why” makes you a better engineer.

Join Me

Part 1 drops in 3 days: “How GPT Reads Your Words (And Why It Can’t Count Letters)”

We’ll start with the most fundamental question: How does GPT actually “read” your text?

Spoiler: It doesn’t see letters at all.

Want to follow along?

• ⭐ Star the repo on GitHub to get notified

• 💻 Clone the code to code along

• 💬 Join the discussions to ask questions

• 🔗 Connect on LinkedIn for updates

The best way to learn is to build. Let’s build together.

The reason is simple. Models don't read your mind. They only see the context you give them.

Why Prompts Alone Don't Cut It

Picture a developer asking: "Review this pull request."

The AI might comment on variable names or reformat a line, but it misses bigger issues like performance, security, or consistency with the team's style guide.

Now compare that to: "You are reviewing a pull request for our backend service. Apply our Python style guide, flag any security risks with user input, and check if the changes follow the existing logging pattern. Use short comments with examples of fixes."

The second request works because the developer supplied context: coding standards, priorities, and the style of feedback they expect. That context turns the AI into a helpful teammate instead of a noisy lint tool.

What Context Really Means

Context is the background you wrap around your prompt. It can be examples, rules, documents, or even the audience you're targeting. Without it, AI fills in the gaps with guesses. With it, you guide the output toward something useful.

Think about how a marketing team works. If you ask an AI, "Write ad copy for our new headphones," you'll get generic text. But if you load it with brand voice guidelines, customer personas, and past campaigns that performed well, you give it a frame to work inside. Now the output isn't just text. It's on-brand campaign material.

What the Research Shows

This isn't just opinion. Studies back it up.

A 2025 benchmark on software engineering prompts found that structured prompts with examples and constraints improved accuracy by 10 to 15 percentage points compared to vague requests.

"Prompting in the Wild" (2024) analyzed thousands of real prompts in open-source codebases. Most edits weren't clever rewrites. They were context fixes: adding missing constraints, clarifying output formats, or specifying the audience.

In short, people don't get better results by writing prettier prompts. They get them by engineering a better context.

Trade-Offs You Can't Ignore

Context is powerful, but it isn't free.

Cost: More tokens mean higher API bills.

Speed: Longer prompts increase response time.

Confusion: Irrelevant or contradictory context makes answers worse, not better.

A practical guideline: keep context at no more than half your output budget. If you expect 800 tokens of output, aim for 300 to 400 tokens of context. Summarize where possible. Use bullet points instead of long paragraphs.

Common Mistakes That Kill Results

Here are traps I see people fall into:

Dumping raw documents: Pasting a 10-page manual instead of a 200-word summary.

Mixing tones: Asking for formal and casual output in the same prompt.

Stale context: Forgetting to update rules or data, so the model follows outdated instructions.

Over-constraining creativity: Loading creative tasks with so many rules, the output becomes robotic.

Context that fights itself: Saying "be concise" then asking for "detailed explanations with examples."

Avoid these, and you'll save yourself a lot of frustration.

How to Debug Bad Context

Don't expect to nail it on the first try. Context design is messy. Here's how to make it work:

Start with your basic context: purpose, audience, constraints, and examples.

Run the same prompt on three to five different inputs.

When it fails, ask why. Did it ignore your constraints? Was the tone wrong? Did it add unnecessary fluff?

Here's what a real debugging session looks like:

Try 1: "Write a product description for wireless earbuds." Result: Generic, boring copy.

Try 2: "Write a 50-word product description for wireless earbuds targeting fitness enthusiasts." Result: Better, but sounds like every other fitness ad.

Try 3: "Write a 50-word product description for wireless earbuds targeting runners who hate when their music cuts out mid-workout. Focus on reliability, not features." Result: Now you have something that speaks to real pain points.

Each revision added context that mattered. That's how you get from "interesting" to "ready to use."

Beyond Technical Skills

Context engineering isn't just about writing better prompts. The best practitioners understand psychology, domain expertise, and system design.

Psychology matters because you need to know how people process information. A legal brief and a social media post need completely different context structures.

Domain expertise matters because the context that works for code reviews won't work for medical diagnoses. Each field has its own standards, risks, and success metrics.

System design matters because context flows through workflows. You need to think about how context gets updated, who maintains it, and what happens when requirements change.

The strongest context engineers I know aren't just technical. They're translators between different worlds.

Different Industries, Different Needs

Context isn't one-size-fits-all. The stakes and details vary:

Legal: Precision and citations are non-negotiable. Context needs to include references to statutes or contracts. One wrong interpretation could cost millions.

Medical: Patient history and safety disclaimers must be front and center. Output without them isn't just bad. It's dangerous.

Creative work: Style guides, character notes, and pacing matter more than strict rules. Too much structure kills the magic.

Customer service: Cultural context matters. A response that works for American directness might seem rude to customers who expect formal acknowledgment of hierarchy.

Think about what context actually matters in your field, and design for it.

The Collaboration Factor

Context design works best as a team sport. Engineers provide technical constraints. Domain experts supply business rules. End users reveal real-world edge cases that no one thought about.

I watched a team spend weeks perfecting prompts for a customer service bot. The context looked perfect on paper. Then real customers started using it, and everything broke. Turns out, angry customers don't follow the polite scripts the team had imagined.

The fix wasn't better prompts. It was a better context that accounted for emotional states, incomplete information, and the chaos of real human communication.

Making It Stick

If you want to get good at context engineering, practice on problems that matter to you. Don't just optimize toy examples. Pick a real workflow where AI could help, then iterate on the context until it actually works.

Track what breaks and why. Build a personal library of context patterns that work in your domain. Share what you learn with your team.

Most importantly, remember that a perfect context doesn't exist. Good context evolves with your needs, your users, and your understanding of the problem.

The goal isn't to write the perfect prompt once. It's to build systems that keep working as the world changes around them.

Prompts fade. Context endures.

I've been there. We've all been there.

With 150k tech jobs cut in 2024 and another 22k gone by mid-2025, choosing your next move feels less like career planning and more like navigating a minefield. But here's the thing—both paths can work. The trick is figuring out which one works for you at the moment.

Let me walk you through what I've learned after talking to dozens of engineers, PMs, and designers who've made this jump in both directions.

The Money Talk (Because Let's Be Real)

Nobody likes to admit it, but most of us check the salary first. And honestly? The gap is real.

At Big Tech, you're looking at median SWE salaries around $184k nationally, with Google hitting $301k. Meanwhile, startups typically pay 30-40% lower for comparable levels. Ouch.

But here's where it gets interesting—equity.

Those Google RSUs? They vest quarterly, and you can sell them immediately. It's basically salary with extra steps. Startup equity? That's your lottery ticket. You might own 0.5-2% of something that could 10x, but realistically, about 90% of options expire worthless or get diluted into oblivion.

I know someone who turned down a $400k Google offer for a Series A startup. Three years later, that startup got acquired, and his equity payout bought him a house in Palo Alto. I also know someone who did the same thing and ended up with options worth approximately $0.

Bottom line: Treat RSUs like salary. Treat startup equity like a lottery ticket you can afford to lose.

Growth Curve & Skill Depth

This is where things get nuanced, and honestly, where most people get it wrong.

At Big Tech, you're going deep. Really deep. You'll have formal design reviews, polished infrastructure, and domain specialists who've seen every edge case. If you want to understand how to squeeze latency from billion-request services, this is your playground.

At startups? It's "whatever ships by Friday." Last week you were designing the database schema, this week you're answering support tickets, next week you're in the room when they're pitching Series B investors.

My friend put it perfectly: "At the 20-person startup, I went from backend engineer to acting CTO in 8 months because our technical lead quit. Terrifying? Yes. But I learned more about system architecture, hiring, and business strategy in that year than I did in three years at Microsoft."

But here's what most people miss: "startup" covers everything from 3 founders in a garage to 500-person companies preparing for IPO. The experience varies wildly:

Pre-Seed/Seed (2-15 people): You're basically a founding team member. Expect to wear 6 different hats and have massive influence on product direction. The equity upside is highest, but so is the "will we survive the quarter?" anxiety.

Series A/B (15-100 people): Still scrappy, but with actual product-market fit signals. You'll have a defined role but flexible boundaries. The learning curve is steep but structured.

Series C+ (100+ people): These feel more like small Big Tech companies than startups. You'll have the scale challenges without the Big Tech compensation or stability.

Here's my rule: If you want to become the world's expert in ML infrastructure, lean Big Tech. If you want to understand how an entire business works—from code to customers to cash flow—lean early-stage startup.

The Brand Game (And Why It Still Matters)

Let's talk about something uncomfortable: prestige still opens doors.

A year at a FAANG company can 10x your recruiter response rates. It's a signal that cuts through resume noise and unlocks higher-level interviews everywhere else. It's not fair, but it's real.

Startups can build founder credibility, but that recognition is hit-or-miss outside entrepreneurial circles. Unless your startup becomes the next Airbnb, most people won't recognize the name.

The smart play? Collect one strong brand stamp and one strong narrative. Like "first infrastructure engineer who scaled Series B app to 10M MAU." Either alone is helpful; together, they compound.

The 2025 Reality Check

Here's what nobody wants to talk about: "stable" is relative in 2025.

Those Big Tech layoffs hit cloud giants and scrappy startups alike. Google, Meta, Amazon—they all cut thousands. But so did hundreds of startups when VC funding tightened.

The difference? Big Tech layoffs come with severance packages and LinkedIn sympathy. Startup layoffs come with "we ran out of money" and worthless equity.

But here's the twist—Big Tech alumni networks are incredibly strong for landing. Startup alumni networks open doors to founding opportunities. Both have value, just different kinds.

The Lifestyle Reality

Startups mean stress spikes that align with fundraising cliffs and production fires. You'll get pinged at weird hours, context-switch constantly, and sometimes wonder if you're building something people actually want.

But there's also this weird camaraderie. When you're 12 people trying to figure out product-market fit, everyone's in it together. You'll know everyone's name, their kids' names, and probably their coffee order.

Big Tech means meeting load and process drag that can kill momentum. But mature on-call rotations mean your weekends are actually yours. The benefits are luxe, the cafeteria food is free, and burnout risk is genuinely lower.

Pros/Cons at a glance:

Startup Life:

• ✅ Direct impact, fast decision-making, equity upside

• ❌ Long hours, resource constraints, survival risk

Big Tech Life:

• ✅ Great mentorship, work-life balance, predictable growth

• ❌ Bureaucracy, narrow ownership, golden handcuffs

Choose the adrenaline cocktail that sustains you, not the one that drains you.

Your 4-Question Decision Framework

When I'm helping friends think through these choices, I ask them to walk through these questions:

1. What's Your Runway? Could you live on just the cash portion for 2 years? If not, you're gambling rent money on options.

2. Where's Your Risk Tolerance? Mortgage? Visa applications? Kids? Your risk tolerance at 25 is different from 35. Be honest about what you can afford to lose.

3. What's Your Learning Plateau? Haven't fought a new problem in six months? Prioritize the environment that stretches you, even if it's scary.

4. What's Your 5-Year Vision? Write down the role, skills, and network you want by 2030. Which offer gets you there faster?

Questions That Cut Through the BS

Before you sign anything, ask these:

For startups: What's your current burn rate and runway? What happens to my equity if I leave before the next round? What's Plan B if fundraising fails?

For Big Tech: What has this team shipped in the last 12 months? Can you share promotion stories from people who've worked under my prospective manager?

Transparency is a health indicator. If they're evasive, that's your red flag—regardless of the brand name.

TL;DR

If you're optimizing for: immediate cash, visa sponsorship, or deep specialization → Big Tech is probably your move.

If you want: end-to-end ownership, broad skills, and outsized upside potential → Startup life might be calling.

Want the best of both? Do Big Tech for 2-4 years until your savings and network are solid, then make the startup jump.

The real truth: Both paths can lead to incredible careers. The "wrong" choice is staying somewhere that doesn't challenge you or align with where you want to be in five years.

Single Responsibility Principle (SRP)

One job per component—if it does two, it’s doing too much. SRP says a module or function should have only one reason to change. If you mix salary calculation with email notification, you’ll break both when either requirement shifts. By splitting into focused units, changes stay isolated and tests stay simple.

Why It Matters: Changes to one feature shouldn’t break unrelated ones.

# ❌ Violates SRP: mixes user role update and email logic  
def make_user_admin(user):  
    user.role = 'admin'  
    send_email(user.email, "You’re now an admin")  

# ✅ SRP-compliant: split responsibilities  
def set_admin(user):  
    user.role = 'admin'  

def notify_admin(email):  
    send_email(email, "You’re now an admin")  

Interview Script:

“Let’s split this into two modules—updating roles and sending emails. That way, changing the email service won’t break user management.”

Don't Repeat Yourself (DRY)

Stop the copy-paste—one place for each logic. DRY means each piece of knowledge lives in just one spot. If you find the same formula in five functions, one tweak becomes five potential bugs. Extract a helper, update once, ship safely.

Why It Matters: Duplicate code = duplicate bugs.

# ❌ Repeats area calculation  
print(f"Area: {width * height}")  
volume = (width * height) * depth  

# ✅ DRY: centralize logic  
def calculate_area(w, h):  
    return w * h  

print(f"Area: {calculate_area(width, height)}")  

Interview Script:

“I notice some repeated logic here – I'll refactor into a helper function to keep things DRY and maintainable.”

YAGNI (You Aren’t Gonna Need It)

No crystal ball—implement features only when needed. YAGNI warns against building for hypothetical futures. Over-engineering bloats code and slows you down. Solve today’s problem simply; you can evolve the design when new requirements arrive.

Why It Matters: Over-engineering kills agility.

# ❌ Premature discount feature (unused)  
def total(price, qty, discount=0):  
    return price * qty * (1 - discount)  

# ✅ YAGNI: keep it simple  
def total(price, qty):  
    return price * qty  

Interview Script:

“Let’s skip the discount logic for now—we can add it later if needed. YAGNI keeps our MVP lean.”

CAP Theorem Tradeoffs

Consistency or availability—in a partition, pick one. In distributed systems, you can only have two of Consistency, Availability, and Partition Tolerance. Partitions happen, so choose between consistency (fresh data) or availability (always up). A social feed tolerates slight staleness (AP); a payment system probably errs out until data syncs (CP).

Why It Matters: Distributed systems require brutal prioritization.

“Given this is a payment system, I’d prioritize Consistency. During a partition, we’ll error out instead of risking bad data.”

Design for Failure

Everything fails eventually—design like you know it. Murphy’s Law rules: servers crash, networks go down, disks corrupt. Build resilience with retries, fallbacks, and redundancy. If one zone goes dark, others pick up the slack; if a config file is missing, fall back to safe defaults.

Why It Matters: Resilient systems survive chaos.

# Handle missing configs gracefully  
try:  
    config = json.load(open('config.json'))  
except FileNotFoundError:  
    config = {"mode": "default"}  # Fail-safe default  

“If the database goes down, we’ll serve cached data and log the outage. No single point of failure.”

Final Thought

At the end of the day, these principles are guides, not hard laws. Great engineers (and interviewees) use judgment to decide when to apply each principle and when to bend it. It’s better to understand the trade-offs than to blindly chant “SOLID” or “DRY” at every turn. So remember: knowing the name is good, but knowing when and why to use it is the real cheat code.

In this article, I’ll share the 4-step framework I used to solve LeetCode problems. No memorization is required—just systematic thinking.

Step 1: Categorize the Problem

Goal: Identify the pattern in under 2 minutes by looking for key signals—input type, common keywords, and problem constraints.

1. Inspect the Input Type

• Arrays & Strings: Potential for sliding window, two pointers, prefix sums, or sorting strategies.

• Trees & Graphs: Look for DFS, BFS, topological sort, union-find (disjoint sets).

• Linked Lists: Often revolve around pointer manipulation (slow/fast pointers), reversing lists, or merging.

• Matrices/2D Grids: Typically DFS, BFS for “island” or “path” style problems, or dynamic programming for path optimizations.

2. Scan for Keywords

Certain words hint at certain algorithms or data structures. Use this quick-reference table to match keywords to likely patterns:

Example:

• “Longest substring without repeating characters” → Sliding Window

  • Reason: “substring” implies a contiguous portion of a string; O(n) time implies a single-pass approach with two pointers.

3. Consider Constraints (Time & Space)

• If the input size can be up to 10^5 or 10^6, an O(n^2) approach will be too slow; aim for O(n) or O(n log n).

• If space is limited (e.g., “constant extra space” or “in-place” requirement), solutions like in-place sorting or two-pointer swaps may be necessary.

• O(log n) time constraints often signal binary search or tree-based approaches.

Tip: The problem statement’s desired complexity (often hinted by constraints) narrows down possible algorithms. For instance, an O(n) or O(n log n) time requirement is a strong clue you shouldn’t be attempting an exhaustive backtracking or naive double loop.

Step 2: The 4-Step Framework

1. Break It Down

Rephrase the problem in plain English.

• Bad: “I need to find the longest substring.”

• Good: “Track unique characters in a window, expand until duplicates appear, then shrink from the left.”

Identify Edge Cases:

• Empty input? All duplicates? Case sensitivity?

2. Visualize

Sketch scenarios (even for non-visual problems):

• Arrays: Draw pointers, partitions.

• Trees: Sketch recursion paths.

• Graphs: Map nodes and edges.

Example for LeetCode 124: Binary Tree Max Path Sum:

Copy

     -10  
     /  \  
    9    20  
        /  \  
       15   7  

Visual Insight: The max path could be 15 → 20 → 7 (sum 42), ignoring the root.

3. Optimize

Time-Space Tradeoffs:

• Replace nested loops with hash maps (e.g., two-sum).

• Use recursion with memoization for overlapping subproblems (DP).

• Precompute values (prefix sums, frequency counts).

Red Flags:

• Brute-force solutions with O(n²) time.

• Recursion without memoization (stack overflow risk).

4. Code

Interview-Ready Code Checklist:

• Descriptive variable names (left_ptr, max_sum).

• Handle edge cases upfront.

• Add brief comments for complex logic.

Bad vs Good Code:

# Bad: Unclear variables  
def f(s):  
    d = {}  
    l = 0  
    ...  

# Good: Self-documenting  
def longest_unique_substring(s: str) -> int:  
    char_index_map = {}  
    left = 0  
    max_length = 0  
    ...  

Step 3: Avoid These 3 Deadly Traps

1. The “Code First, Think Later” Mistake

• Why It Fails: Jumping into code without planning leads to confusion, endless debugging, and missed edge cases.

• How to Fix It: Spend at least 10 minutes on problem analysis (Steps 1–3) before writing a single line of code. Outline your approach, consider edge cases, and confirm time/space constraints.

2. Overcomplicating Solutions

• Why It Fails: Using advanced data structures or algorithms when simpler ones suffice wastes time and increases bug risk.

• How to Fix It: Always ask, “What’s the simplest approach that meets the constraints?” Start with that and only optimize further if needed.

3. Ignoring Space Complexity

• Why It Fails: Focusing solely on time complexity can lead to memory bloat or stack overflow—problems you discover too late.

• How to Fix It: Calculate space complexity upfront. If recursion or extra data structures could get too large, switch to an iterative or more memory-efficient approach.

Case Study: LeetCode 239 – Sliding Window Maximum

Problem Statement
You are given an integer array nums and an integer k, representing the size of a sliding window. For each valid window position, return the maximum value within that window.

Step 1: Categorize the Problem

1. Identify the Input Type

   • Input is an array (nums) with the potential for repeated elements.

2. Look for Keywords

   • “Sliding Window,” “Maximum,” and “Size k.”

   • These keywords strongly hint at the Sliding Window pattern and the possibility of a deque (double-ended queue) solution to keep track of maximum elements.

3. Check Constraints

   • Typically, n can be large (e.g., up to 10^5).

   • A naive O(n*k) approach will be too slow for large n if k is also large.

   • This suggests we need an O(n) or O(n log n) approach.

Result: We’ve placed the problem into the Sliding Window category, where we keep track of the maximum using a deque or similar structure.

Step 2: Use the 4-Step Framework

Now that we’ve categorized it, let’s apply the framework in detail.

1. Break It Down

• Plain English Restatement
  “We slide a window of size k across the array. For every window position, find the maximum element.”

• Edge Cases

  • k = 1: Return the array as-is (every element is its own max).

  • k = len(nums): Only one window; the result is a single value—the max of the entire array.

  • Mixed or Negative Values: Ensure we handle them correctly (the max may be negative).

2. Visualize

To really see how this works, consider a concrete example:

nums = [1, 3, -1, -3, 5, 3, 6], k = 3

Window positions:
1) [1, 3, -1], -3, 5, 3, 6  -> max = 3
2) 1, [3, -1, -3], 5, 3, 6  -> max = 3
3) 1, 3, [-1, -3, 5], 3, 6  -> max = 5
4) 1, 3, -1, [-3, 5, 3], 6  -> max = 5
5) 1, 3, -1, -3, [5, 3, 6]  -> max = 6

• Naive Approach: For each window, scan k elements. This is O(n*k), which can be costly for large n.

• Key Insight: We can maintain a deque that stores indices of elements in descending order. The element at the front is always the window’s maximum.

3. Optimize

• Time Complexity Goals

  • A direct approach: O(n*k) – too slow for large n and k.

  • Optimized approach: O(n), by ensuring each index enters and leaves the deque at most once.

• Why a Deque?

  • We can push new elements (by index) at the back.

  • Pop from the back any elements smaller or equal to the new element (they’ll never be needed).

  • Pop from the front if the front index is out of the current window (i.e., front == i - k).

  • The front of the deque is always the index of the current window’s maximum element.

Result: Each element is processed in constant time, leading to a total of O(n).

4. Code

Below is an interview-ready Python solution. Note the inline comments that map back to our strategy:

from collections import deque
from typing import List

def max_sliding_window(nums: List[int], k: int) -> List[int]:
    # Handle trivial case
    if k == 1:
        return nums
    
    q = deque()  # will store indices of potential maxima
    result = []
    
    for i, num in enumerate(nums):
        # 1. Pop from the back while the current num is >= the element at q[-1]
        #    Those smaller elements can't be a future max
        while q and nums[q[-1]] <= num:
            q.pop()
        
        # 2. Push the current index onto the back
        q.append(i)
        
        # 3. If the front of the deque is out of the window, pop it
        if q[0] == i - k:
            q.popleft()
        
        # 4. Once we've processed at least k elements, the front of q is the max
        if i >= k - 1:
            result.append(nums[q[0]])
    
    return result

Mental Models from Top Engineers

1. The 20-Minute Rule

   • What It Is: Spend no more than 20 minutes stuck on a single approach. If you’re still spinning your wheels, seek a hint or switch tactics.

   • Why It Works: Timeboxing prevents you from wasting hours on a dead end and encourages you to explore alternative methods sooner.

2. Spaced Repetition

   • What It Is: Revisit problems and patterns weekly to consolidate learning (tools: Anki, LeetCode’s “Review” feature).

   • Why It Works: The human brain retains information more effectively when it’s reinforced at structured intervals rather than cramped.

3. Mock Interviews

   • What It Is: Practice out loud with friends or online platforms (e.g., Pramp, Interviewing.io).

   • Why It Works: Verbalizing solutions reveal gaps in your reasoning and help you simulate real interview pressure.

4. The Feynman Technique

   • What It Is: Teach or explain a problem in your own words as if you’re instructing a beginner.

   • Why It Works: Breaking down complex ideas into simple explanations clarifies your thought process and uncovers hidden assumptions.

5. “Post-Mortem” Analysis

   • What It Is: After solving each problem (or failing to), jot down what went well, where you struggled, and how you’d improve next time.

   • Why It Works: Reflection cements lessons learned and highlights recurring mistakes, so you don’t repeat them.

6. The Pareto Principle (80/20 Rule)

   • What It Is: Focus on the 20% of problem types or patterns (e.g., sliding window, DFS, DP) that appear 80% of the time in interviews.

   • Why It Works: Targeted practice on the most common patterns yields the biggest bang for your buck in a limited timeframe.

7. Rubber Duck Debugging

   • What It Is: Explain each line of your logic to an inanimate “listener” (like a rubber duck) or even just yourself.

   • Why It Works: Speaking out loud forces you to slow down and identify subtle errors or assumptions in your reasoning.

Your Action Plan

1. Learn Patterns, Not Problems: Focus on categories (e.g., sliding window, DFS).

2. Time Yourself: Solve easies in 10 minutes, mediums in 20, hards in 30.

3. Analyze Failures: For every wrong answer, write down why (e.g., missed edge case).

Final Tip: Embrace the Process, Not Just the Answer

LeetCode success isn’t about raw talent or memorizing a hundred solutions—it’s about using a consistent, repeatable framework. The next time you face a challenging problem:

1. Categorize the question type (arrays, graphs, DP, etc.).

2. Visualize the steps or data structures involved.

3. Optimize with an eye on time and space constraints.

4. Code cleanly, handling edge cases upfront.

By shifting from guesswork to structured problem-solving, you’ll tackle even the toughest interviews with confidence. More importantly, these skills carry over to real-world engineering, turning every coding challenge into a stepping stone for your growth.

Setting the Stage

Imagine this: every minute, TikTok users upload more than 16000+ videos, tap 11 million likes, and hammer out 5 million comments—while an AI feed seemingly knows your taste in music, your sense of humor, and your pet’s name better than you do.

This is the platform that turned short-form video into a global obsession. Love it or hate it, TikTok’s engineering is a marvel of modern system design.

Today, we’re cracking open the black box. Let’s dissect how TikTok handles:

✅ Petabyte-scale uploads
✅ Sub-50ms AI recommendations
✅ A global CDN built for speed

Grab your popcorn, because we’re about to see how the engineers at ByteDance keep the show rolling for over a billion users—without missing a single beat.

1. The 10-Second Time Bomb: TikTok’s Core Challenges

TikTok isn’t just another social media platform—it’s an endless, real-time content tsunami that devours bandwidth, compute power, and developer ingenuity. At its core, engineers must tackle:

Upload Avalanche

📹 Over 350 hours of video uploaded every minute (~5GB/hour for 4K).
⚡ A complex workflow ensures minimal friction for creators worldwide.

Scroll Apocalypse

📱 Over a billion daily video views demanding near-instant feed loading.

AI Mind-Reader

🧠 Recommending videos within 50 ms of app launch for maximum engagement.

These aren’t solved by magic. They’re solved by brutal system design optimizations, geo-distributed microservices, and borderline obsessive testing.

2. Handling the Upload Deluge: How TikTok Digests 350+ Hours of Video per Minute

Solution: Geo-Distributed Microservices

Chunk & Conquer

📦 Videos are split into 1–5 MB chunks via MPEG-DASH, allowing parallel processing across 200+ global Points of Presence (PoPs).
⚡ This parallelism ensures that even massive uploads are completed quickly.

Edge Encoding

🎞️ Real-time transcoding using GPUs at edge nodes, not just plain old FFmpeg scripts.
🔄 In most regions, 720p is prioritized for immediate availability, with full-resolution versions processed in the background. (Some bandwidth-constrained regions may start at 480p.)

Priority Tiers

📊 TikTok prioritizes high-profile uploaders, ensuring creators with high engagement (often monetized) get faster throughput.
🔁 ByteDance leans heavily on Pulsar (over Kafka) to orchestrate and buffer these upload pipelines, though some legacy systems still rely on Kafka.

Custom Storage Layers

🔥 “Hot” videos—recently uploaded or going viral—reside on NVMe SSDs for ~48 hours.
📂 After trending periods end, they’re shifted to ByteDance’s in-house “HDFS++” object store (because apparently, AWS S3 wasn’t enough).

💡 Pro Tip: TikTok actively monitors regional usage patterns to distribute heavy encoding tasks to off-peak hours—so your midnight upload may process faster than a prime-time post.

3. The “For You Page” AI: Hypnotizing You in 50 ms

If there’s a secret sauce that turned TikTok into a cultural phenomenon, it’s the For You Page (FYP). It’s an ensemble of AI models that are really good at predicting what you want to watch next.

Step 1: Real-Time Feature Extraction

🔍 Micro-Gesture Tracking: TikTok tracks swipe velocity (users dwell for ~2.1 seconds per video) and “scroll hysteresis” (how forcefully you stop scrolling).
🎭 Multi-Modal Fusion: Leveraging CLIP-like models to analyze video frames, text overlays, audio, and voice transcripts simultaneously.

Step 2: Model Training

🧠 Hybrid Learning: A mix of federated learning (on devices) + centralized training on 10,000+ A100 GPUs.
🔄 Real-Time Feedback Loop: Most user preference updates happen within 90 seconds, but some adapt in just seconds if engagement shifts sharply.

Step 3: Inference & Delivery

📡 Edge Caching: TikTok pre-computes three potential feed variants per user, caching them in local data centers—so videos load instantly.
⚡ Fallback Mechanism: If something fails, TikTok switches to geo-local trending videos, serving them 400 million times a day—without you noticing.

4. The CDN Illusion: How TikTok Delivers Videos at Warp Speed

TikTok’s secret? A globally distributed nervous system:

A. Edge Caching
🗂️ 8,000+ servers inside ISP hubs store the top 0.1% of viral videos (your cousin’s dance reel? Probably not here).

B. Adaptive Protocols
🚀 QUIC protocol (Google’s faster alternative to TCP) slashes buffering by 75%.

C. Codec Wars
🎥 H.266/VVC codecs save 50% bandwidth vs. AV1—critical for users on potato-tier networks.

💰 Money Shot: TikTok’s private CDN costs $1.3B/year, but ad revenue covers it 1.5x over.

5. Real-Time Chaos: Likes, Comments, and Digital Anarchy

7 million likes/second? Here’s how TikTok avoids meltdowns:

⚡ RedisCell: Atomic counters keep likes synced globally (no double-tap ghosts).
⚖️ CRDTs: Conflict-free data types resolve comment clashes in 11ms (faster than your Wi-Fi latency).
🚨 AI Moderation: 30+ models scan comments as you type, blocking spam before it’s posted.

🔥 Fail-Safe: If likes break, TikTok lies to you (“Liked!”) while frantically fixing things backend.

6. Disaster Mode: When Systems Implode

Case Study: 2023 LIVE Shopping Day Crash

📉 28 million concurrent viewers overwhelmed product link servers.

The Fix:

⚡ 22-second fallback UI using WebAssembly.
🔄 Traffic rerouted to Moscow PoP (lowest load).
🎤 Influencers prioritized to keep major creators online.

💥 Chaos Engineering: TikTok intentionally crashes a cluster daily to test real-time recovery. Average fix time? 9.7 seconds.

What’s Next? Your Call!

What should we break down next?

1️⃣ Netflix: Why Buffering is Basically Dead
2️⃣ Uber: The Real-Time Surge Pricing Engine
3️⃣ X/Twitter: 300K TPS Meltdown (and Recovery)

Reply with your pick—or just drop a note if you’re vibing with this style!

Until next week—keep scaling the impossible, one microservice at a time.

Heads up—I’m trying out something new this week with a slightly bolder, more conversational style. Let me know if you dig this new tone or if you prefer the old vibe!

The High-Stakes Game of System Design

System design interviews often come with:

• Ambiguous requirements that demand clarifying questions

• Time pressure (usually 45–60 minutes)

• Unclear best answers but a high bar for demonstrating structured thinking

Despite these challenges, system design interviews aren’t about perfection. They’re about showing how you approach and break down complex problems. By the end of this newsletter, you’ll know the core framework for tackling any system design prompt—and you’ll be one step closer to thinking like an architect under pressure.

My First System Design Interview (And the Lessons Learned)

I still remember my first attempt at a system design interview. The prompt? “Design a scalable, real-time messaging system like WhatsApp.”

I started confident, sketching a quick architecture with users, servers, and databases. But then came the deeper questions:

“How would you ensure real-time message delivery under heavy traffic?”
“What about fault tolerance and data durability?”
“How do you handle encryption and privacy?”

Suddenly, I realized just how intricate messaging at scale can be. I stumbled through suggestions—a pub-sub model, message queues—but missed key considerations like database sharding, caching, and encryption.

The big lesson? System design isn’t about cramming in every possible component; it’s about systematically asking the right questions, considering trade-offs, and justifying your decisions.

Why It Feels Like a Game

In a system design interview, you’re under the gun to:

1. Clarify vague requirements (the interviewer expects you to ask questions).

2. Manage your time (45 minutes goes fast).

3. Analyze trade-offs (strong vs. eventual consistency, monolith vs. microservices, SQL vs. NoSQL, etc.).

4. Communicate effectively (while thinking on your feet).

When you understand these “rules,” the interview transforms from an impossible task into a focused exercise in architectural thinking.

A Framework to Dominate Any System Design Interview

Whether you’re designing YouTube, a Chat App, or a Rate Limiter, you can follow this structured approach:

1. Clarify Requirements

• Ask specific questions to understand the scope.

• Examples:

  • “How many daily active users are we expecting?”

  • “Is strict ordering of messages crucial?”

  • “Are we prioritizing low latency, high availability, or strong consistency?”

2. Define Key Constraints

• Identify critical factors like throughput, latency requirements, fault tolerance, and data consistency.

• Example: “For a messaging system, real-time delivery is essential, but we may accept eventual consistency for read operations.”

3. Sketch a High-Level Architecture

• Draw out main components: load balancer, application servers, databases, caches.

• Example for a messaging app:

  • Load Balancer: Distributes traffic across multiple server instances.

  • Pub-Sub or Message Queue: Handles asynchronous message delivery.

  • Database: Stores messages, user data, metadata. Consider sharding or replication strategies.

4. Dive into Critical Components

• Pick 1–2 areas to detail (e.g., real-time messaging pipeline, database sharding strategy, or encryption).

• Show depth in explaining these choices.

5. Discuss Trade-Offs

• Compare potential solutions (e.g., SQL vs. NoSQL).

• Explain the pros and cons (e.g., “NoSQL offers flexibility and easier sharding, but SQL can provide stronger ACID guarantees.”)

6. Plan for Scaling

• Address future growth: “We’ll shard the database using consistent hashing and replicate to different regions for lower latency.”

• Mention tools or services that handle large-scale operations (e.g., Kafka, Redis, Cassandra).

7. Wrap Up

• Summarize your design and highlight key decisions.

• Ask for clarifications or indicate areas you could dive deeper into if time allows.

Popular Prompts & What They Test

1. Design a URL Shortener

   • Hashing, database design, read/write performance.

2. Design a Chat Application

   • Real-time messaging, fault tolerance, encryption.

3. Design YouTube

   • Video storage, CDN, streaming, recommendation engine basics.

4. Design an E-Commerce Platform

   • Inventory management, transaction handling, caching.

5. Design a Rate Limiter

   • Distributed counters, throttling, consistency.

How to Prepare

1. Study Core Concepts: CAP theorem, load balancing, caching strategies, database sharding, replication, consistency models.

2. Practice Frameworks: Keep refining a reusable approach for clarifying requirements, picking components, and scaling strategies.

3. Use Real-World Case Studies: Netflix and AWS blog posts often share how they handle billions of requests—gold mines for learning about distributed systems.

4. Mock Interviews: Platforms like Pramp or Interviewing.io help you practice communicating your ideas under time pressure.

5. Think Aloud: Get comfortable articulating your thoughts so your interviewer sees how you approach problems.

Bonus: Quick Cheat Sheet

1. Ask Questions (Users, Data, Traffic, Requirements)

2. Identify Key Constraints (Latency, Consistency, Availability)

3. Outline a High-Level Design (Load Balancer, App Servers, Database, Cache)

4. Deep Dive on 1–2 Components (Pub-Sub, DB Sharding, etc.)

5. Highlight Trade-Offs (SQL vs. NoSQL, Microservices vs. Monolith)

6. Scaling Strategy (Horizontal vs. Vertical Scaling)

7. Summarize and Clarify Next Steps

Conclusion: Think Like an Architect

System design interviews are a valuable exercise in tackling large-scale engineering problems under pressure. They’re not about constructing a perfect solution in 45 minutes—they’re about showcasing your structured thinking, trade-off analysis, and communication skills.

Master the framework, practice with real examples, and you’ll soon find these interviews aren’t an impossible game—they’re a playground for innovative thinking.

Happy designing!

REST APIs are the invisible workhorses of modern software, powering everything from your favourite mobile apps to massive cloud-based systems. They’re the bridges that connect disparate systems, enabling seamless data exchange. But when an API is poorly designed, it can frustrate developers, degrade user experiences, and stifle innovation.

That’s why thoughtful API design isn’t a luxury—it’s a necessity. A well-designed API doesn’t just work; it’s intuitive, reliable, and a delight to use. In this newsletter, we’ll break down actionable best practices to help you craft REST APIs that developers will love.

1. Master the Basics: HTTP Methods

HTTP methods are the backbone of REST APIs. When used correctly, they make your API intuitive and predictable. Let’s dive deeper into what makes each method essential.

GET: Retrieve Resources

• Use Case: Fetch data without making changes.

• Examples:

  • GET /users retrieves a list of users.

  • GET /users/123 fetches details about the user with ID 123.

• Best Practices:

  • Use query parameters for filtering, sorting, or pagination.
    Example: GET /users?status=active&page=2&limit=10.

  • Return appropriate status codes:

    • 200 OK for successful retrieval.

    • 404 Not Found if the resource doesn’t exist.

• Tip: Avoid using GET for operations that change the server state, as this can lead to unexpected side effects.

POST: Create Resources

• Use Case: Add a new resource to the system.

• Examples:

  • POST /users creates a new user with the provided payload.

{
  "name": "Jane Doe",
  "email": "jane.doe@example.com"
}

• Best Practices:

  • Return 201 Created on success.

  • Include the URI of the newly created resource in the Location header.

Location: /users/123

• Validate input to ensure only valid data is processed.

PUT and PATCH: Update Resources

• PUT: Replace the entire resource.

PUT /users/123
{
  "name": "John Doe",
  "email": "john.doe@example.com"
}

• PATCH: Partially update specific fields.

PATCH /users/123
{
  "email": "john.new@example.com"
}

• Best Practices:

  • Use 404 Not Found if the resource doesn’t exist.

  • Document which fields are required for PUT and optional for PATCH.

DELETE: Remove Resources

• Use Case: Permanently delete a resource.

• Example:
  DELETE /users/123 removes the user with ID 123.

• Best Practices:

  • Return 204 No Content on successful deletion.

  • Avoid destructive operations for resources in use; consider soft deletes where applicable.

2. Design Clear, Consistent URIs

URIs are the front door of your API. A well-designed URI structure makes your API easier to use and maintain.

Core Principles

1. Human-Readable:
   A URI should be self-explanatory:

   • ✅ /users (clear and concise).

   • ❌ /getAllUsers (exposes implementation details).

2. Use Plural Nouns for Collections:

   • ✅ /users (for a collection of users).

   • ❌ /userList (inconsistent naming).

3. Avoid Verb-Based URIs:
   Let the HTTP method dictate the operation:

   • ✅ POST /users (to create a user).

   • ❌ /createUser.

Advanced Design Patterns

• Hierarchical Relationships:
  Represent relationships between resources:

  • Example:
    GET /users/123/orders retrieves all orders for the user with ID 123.

• Filtering and Searching:
  Use query parameters for complex queries:

  • Example: GET /products?category=electronics&price_lt=1000.

3. Versioning Your API

APIs are living systems that evolve. Proper versioning ensures stability and backward compatibility.

Versioning Strategies

1. URI-Based Versioning:

   • Example:
     GET /api/v1/users (Version 1).
     GET /api/v2/users (Version 2 with new features).

2. Header-Based Versioning:

GET /users
Accept: application/vnd.example.v2+json

3. Semantic Versioning:

• Increment versions based on changes:

  • v1.0.0: Initial release.

  • v1.1.0: Backward-compatible updates.

  • v2.0.0: Breaking changes.

Best Practices

• Communicate deprecation timelines for older versions.

• Include migration guides for smooth transitions.

4. Thoughtful Error Handling

Errors are inevitable. The key is to provide clear, actionable feedback when they occur.

Best Practices

• Use Appropriate HTTP Status Codes:

  • 400 Bad Request: Invalid input.

  • 401 Unauthorized: Missing or invalid authentication.

  • 403 Forbidden: Access denied.

  • 404 Not Found: Resource doesn’t exist.

  • 500 Internal Server Error: Something went wrong on the server.

• Standardize Error Responses:

{
  "error": {
    "code": "INVALID_INPUT",
    "message": "The 'email' field is required.",
    "details": {
      "field": "email",
      "expected": "A valid email address"
    }
  }
}

• Avoid Leaking Sensitive Information:

  • ❌ "message": "Database connection failed at line 123."

  • ✅ "message": "An internal error occurred. Please try again later."

5. Securing Your API

APIs handle sensitive data, making security a top priority.

Best Practices

1. Authentication:

   • Use OAuth 2.0 for secure and flexible access control.

Authorization: Bearer <access_token>

1. Encryption:

   • Enforce HTTPS for all API traffic.

2. Rate Limiting:

   • Protect against abuse:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 50

6. Scale for Performance

Scalability ensures your API remains reliable under increasing load.

Techniques

• Caching:

  • Use Cache-Control and ETag headers to store frequently requested data.

• Pagination:

  • Limit large datasets:

GET /users?page=1&limit=10

• Asynchronous Processing:

  • Use background jobs for long-running tasks, returning 202 Accepted for immediate responses.

7. Document Everything

Great documentation drives adoption. Include:

• Detailed descriptions of endpoints, parameters, and responses.

• Real-world examples with tools like Swagger or Postman.

• Error codes and their meanings.

Closing Thoughts

Designing a great REST API isn’t just about functionality—it’s about creating a delightful developer experience. By following these best practices, you’ll build APIs that are not only reliable and secure but also intuitive and scalable.

What’s your biggest challenge in API design? Let’s discuss—I’d love to hear from you!

AI/ML Dominance

Artificial intelligence and machine learning transformed software development in 2024, evolving from helpful tools to essential parts of workflows.

• Example: GitHub Copilot introduced more advanced context-aware code suggestions, predicting developer needs based on project history. Amazon CodeWhisperer expanded compatibility, integrating seamlessly with IDEs like IntelliJ and VS Code. Tools like Tabnine added real-time code quality checks powered by AI, while Diffblue Cover enabled deeper coverage analysis for automated unit tests.

• Why It Matters: 2024 marked the year AI tools evolved beyond automation to become strategic collaborators, significantly improving code quality and team productivity.

Cloud Computing Evolution

The cloud ecosystem matured in 2024, emphasizing specialization and edge computing to create more robust and flexible cloud-native architectures.

• Example: AWS enhanced Lambda at the Edge, enabling real-time invocation with sub-10ms latency, making it ideal for IoT applications and low-latency use cases. Google Cloud boosted Vertex AI’s integration with BigQuery, reducing ML model training time by 40%. Kubernetes adoption surged, aided by OpenCost 2.0, which optimized resource allocation, cutting costs for enterprises by up to 20%.

• Why It Matters: These advancements make cutting-edge computing accessible to developers at every scale, unlocking new possibilities for innovation and efficiency.

The Rise of Low-Code/No-Code

Low-code and no-code platforms gained sophistication, enabling non-technical users to create advanced, production-ready solutions.

• Example: Bubble introduced AI-generated workflows that recommend automation based on user actions. Microsoft Power Apps unveiled advanced connectors to enterprise data lakes, enabling complex data manipulation without code. Startups used these platforms to launch MVPs with AI-integrated features in weeks rather than months.

• Why It Matters: 2024 saw low-code tools mature into platforms capable of handling enterprise-grade applications, levelling the playing field for innovation.

Focus on Developer Experience (DX)

The developer community prioritized DX in 2024, introducing tools and practices that minimized friction and maximizing productivity.

• Example: GitHub Codespaces enhanced live collaboration, allowing teams to work simultaneously on cloud-based IDEs. JetBrains Space integrated AI for task prioritization, reducing context-switching. ChatGPT plugins for DevOps automated troubleshooting, transforming incident response times.

• Why It Matters: Happy developers build better software, and investments in DX are increasingly viewed as essential for competitive advantage.

Security at the Forefront

2024 reinforced security as a cornerstone of software development, driven by increasing cyber threats and regulatory demands.

• Example: GitLab released a vulnerability prioritization tool that combines AI and real-world exploit likelihood. OWASP's 2024 updates introduced new guidelines for securing APIs, which gained rapid adoption. Snyk launched real-time security feedback during local development, identifying potential risks before code hits a repository.

• Why It Matters: Integrating security early in the lifecycle reduces vulnerabilities and builds user trust, a critical differentiator in today’s market.

Looking Ahead to 2025

• AI/ML Integration Deepens: Artificial Intelligence (AI) and Machine Learning (ML) are set to evolve from assistive tools to integral components of software development workflows. By 2025, AI-driven solutions will automate complex tasks such as debugging, refactoring, and managing technical debt, leading to more efficient and reliable codebases.

• Edge Computing Takes Center Stage: The proliferation of Internet of Things (IoT) devices and applications requiring real-time processing will drive the demand for edge computing solutions. Technologies like 5G will enable near-zero latency, making edge computing essential for applications in augmented reality (AR), virtual reality (VR), and autonomous systems.

• Quantum Computing on the Horizon: Quantum computing is advancing rapidly, with companies like IBM and Google making significant strides. By 2025, emerging Software Development Kits (SDKs) and cloud-based quantum services are expected to facilitate breakthroughs in optimization and security, offering unprecedented computational power for complex problem-solving.

• Sustainability Focus: As environmental concerns intensify, there will be a stronger emphasis on sustainable technology practices. Organizations are expected to invest in energy-efficient hardware, adopt cloud services powered by renewable energy, and implement green coding practices to minimize carbon footprints.

Happy New Year, fellow developers!

Here’s a step-by-step guide to getting it right from the start.

1. Define Clear Objectives and Scope

Before writing even a single line of code, clarify what you are building and why. Answer questions like:

• Who are your target users?

• What specific problem are you solving for them?

• What does the Minimum Viable Product (MVP) look like?

Without a clear direction, it’s easy to get lost in feature creep or spend time solving problems that don’t matter. For inspiration, browse platforms like r/SomebodyMakeThis, where users post real-world problems they’d like solved. This can spark ideas and give you insight into unmet needs.

2. Choose a Tech Stack That Fits

Your tech stack should align with your project’s goals, scalability needs, and your team’s expertise. Avoid chasing trends; instead, prioritize tools you’re comfortable with and that are proven in the domain. Here are a few examples:

• Web Applications: React (front-end), Node.js or Django (back-end), PostgreSQL (database).

• Mobile Apps: Flutter (cross-platform) or native development with Swift (iOS) and Kotlin (Android).

• Data-Intensive Projects: Python with frameworks like Flask or FastAPI and a NoSQL database such as MongoDB.

• Real-Time Systems: Use WebSockets with libraries like Socket.IO or frameworks like NestJS and Django Channels.

Starting with tools you know ensures you’re productive from the beginning, even if you switch or expand your stack later.

3. Set Up Version Control and Collaboration Tools

Using Git from the very start is non-negotiable. Set up a remote repository on platforms like GitHub, GitLab, or Bitbucket. A well-defined branching strategy—like Git Flow—keeps your codebase organized and simplifies collaboration.

Complement version control with tools that streamline teamwork:

• Code Reviews: Use pull requests to ensure high-quality code and collective ownership.

• Task Management: Platforms like Jira, Notion, or Trello help you stay on top of priorities and deadlines.

• CI/CD: Automate testing and deployments with tools like GitHub Actions, CircleCI, or Jenkins.

4. Establish a Scalable Codebase Structure

A well-organized codebase prevents chaos as your project grows. Here’s an example of a clean folder structure for a web application:

project/
  src/
    components/      # Reusable UI components
    pages/           # Page-level components
    services/        # API calls, business logic
    utils/           # Helper functions
    hooks/           # Custom React hooks 
    store/           # State management (e.g., Redux, Context API)
    assets/          # Images, fonts, icons
    styles/          # Global styles, CSS/SASS files
    tests/           # Unit and integration tests
  public/            # Static assets (images, fonts, etc.)
  config/            # Configuration files for build tools (Webpack etc)
  .env               # Environment variables (API keys, app config)
  README.md          # Project documentation
  package.json       # Dependency management, scripts
  tsconfig.json      # TypeScript configuration (if applicable)
  .gitignore         # Files and directories to ignore in version     control

Backend codebase Structure

project/
  src/
    controllers/      # Express or other framework controllers
    models/           # Database models
    routes/           # API endpoint routing
    services/         # Business logic and helpers
    middlewares/      # Custom middlewares
    config/           # Configuration files (e.g., database connections, JWT settings)
    tests/            # Unit and integration tests
  .env                # Sensitive keys, tokens
  .gitignore          # Ignore unnecessary files/folders
  app.js / server.js  # Main entry point for the application

Each folder has a single responsibility, making the codebase easier to navigate and extend. Modularization is key—group functionality logically so changes in one area don’t inadvertently break another.

5. Write a Comprehensive README and Contribution Guide

Your README is the project’s first impression. A good README should:

• Clearly describe the project’s purpose.

• Provide installation and setup instructions.

• List prerequisites (e.g., Node.js version).

• Explain how to run and test the project locally.

If you’re planning to make your project open source, add a CONTRIBUTING.md file to guide others on how to contribute effectively. Use examples from well-maintained repositories like React or Express for inspiration.

6. Automate Early and Often

Automation saves time and reduces human error. Here’s where to focus:

• Linting and Formatting: Use tools like ESLint or Prettier to enforce consistent code styles.

• Testing: Start with basic unit tests using Jest, Mocha, or PyTest. Expand to integration and end-to-end tests as your project grows.

• Deployment: Use containerization tools like Docker to ensure consistency across environments. Automate deployments with platforms like Vercel, Netlify, or AWS CodePipeline.

Setting up automation might feel like overkill early on, but it pays off as your project scales.

7. Prioritize Security From Day One

Security is often overlooked in the rush to get things working but is critical to prevent future vulnerabilities. Best practices include:

• Environment Variables: Store sensitive information (e.g., API keys) in .env files and never hardcode them.

• Authentication: Use secure methods like OAuth2 or JWT for user authentication.

• Dependencies: Regularly audit your dependencies using tools like Dependabot or Snyk.

Implement HTTPS for web applications from the start to protect data in transit.

8. Build for the Future, but Start Simple

It’s tempting to overengineer, but simplicity should guide your decisions early on. For example:

• Don’t implement a full microservices architecture for a small MVP.

• Use an off-the-shelf authentication service (e.g., Auth0) instead of rolling your own.

• Avoid pre-optimizing performance until it’s necessary.

Focus on delivering value quickly, then iterate and scale as needed. For instance, if your database queries slow down as usage grows, add indexing or caching layers like Redis. But start with a basic, functional system.

9. Stay Inspired and Keep Learning

Starting a project is just the beginning. To stay motivated, continuously seek out inspiration and opportunities to grow. Follow tech blogs, explore developer communities, or look for problem-solving forums where others share unique ideas. Participating in hackathons or asking yourself, “What’s something I wish existed?” can also spark new perspectives.

By staying curious and open to new ideas, you'll keep your momentum high and fuel your creativity throughout the project.

Starting a new project is like planting a seed. With the right foundation and care, it can grow into something impactful. By following these best practices, you can set yourself up for success and ensure your project is both enjoyable to work on and resilient to future challenges.

What ideas are you excited to bring to life? Let’s discuss in the comments!

1. Set the Right Tone

Code reviews are opportunities for collaboration, not criticism. Approach them with the intent to improve the code while fostering a positive relationship with the author. Here are some tips:

• Be Respectful: Use language that shows empathy and respect. For example, say, “Could we simplify this logic?” rather than, “This is unnecessarily complex.”

• Be Constructive: Frame your feedback as suggestions rather than directives. Phrases like “Have you considered...” or “Would it make sense to...” are more collaborative.

• Acknowledge Good Work: Call out parts of the code you find well-written, efficient, or particularly clever. This motivates the author and fosters goodwill.

2. Understand the Context

Before diving into the code, ensure you understand why the pull request (PR) exists and what it aims to achieve:

• Read the Description: Thoroughly review the PR title and description. Look for explanations about the change’s purpose and implementation.

• Review Linked Issues or Tickets: Check references to related tasks or issues to ensure you’re aligned with the project’s goals.

• Understand the Bigger Picture: Consider how the change fits into the overall system and whether it aligns with long-term architectural plans.

3. Evaluate Code Quality

Assessing the quality of the code is central to any review. Keep these criteria in mind:

a. Readability and Maintainability

• Is the code easy to understand?

• Are variable and function names descriptive?

• Is the logic straightforward and broken into digestible chunks?

b. Adherence to Standards

• Does the code follow team style guides and conventions?

• Are there unnecessary comments or overly complex structures that could be simplified?

c. Modular Design

• Is the code modular and reusable?

• Are functions or classes single-responsibility and well-encapsulated?

4. Test the Code

Verifying that the code works as expected is critical. This step goes beyond automated tests:

• Run the Branch Locally: If possible, pull the branch and test the functionality in a realistic environment.

• Check Edge Cases: Look for scenarios the author might not have considered. Does the code handle invalid inputs, errors, or unusual user behavior?

• Assess Performance: Test the code under conditions it’s likely to face in production. Are there bottlenecks or inefficiencies?

5. Focus on Key Areas

A good code review doesn’t nitpick minor issues while missing critical problems. Focus on:

• Logic Correctness: Verify that the code’s logic aligns with requirements and produces expected outcomes.

• Error Handling: Ensure the code gracefully handles errors and edge cases without exposing vulnerabilities.

• Security: Check for potential security risks, such as unchecked inputs or improper access controls.

6. Provide Clear and Actionable Feedback

The way you articulate your feedback can significantly impact the review’s effectiveness:

• Be Specific: Instead of saying, “This isn’t clear,” point to a specific line and explain why it’s unclear.

• Use Examples: Offer alternatives or suggestions. For instance, “Consider using a ternary operator here for simplicity.”

• Prioritize: Distinguish between critical issues that must be addressed before merging and optional improvements.

7. Use the Right Tools

Take advantage of tools that streamline the review process:

• Integrated Code Review Platforms: Tools like GitHub, GitLab, or Bitbucket provide in-line comments and change tracking.

• Linting and Formatting Tools: Ensure automated tools are in place to catch style and syntax issues, allowing you to focus on higher-level concerns.

• Testing Frameworks: Use automated tests to confirm functionality, leaving manual testing for edge cases and usability.

8. Know When to Approve or Reject

Not every PR will be perfect, but it’s important to know when it’s “good enough” to merge:

• Approve: If the code meets standards, aligns with project goals, and any major concerns have been addressed.

• Request Changes: When critical issues remain unresolved or the code introduces risks to the project.

• Add Comments: For minor suggestions that don’t block the merge.

Why Effective Code Reviews Matter

Effective code reviews:

• Improve Code Quality: They catch bugs, enforce standards, and ensure maintainability.

• Facilitate Knowledge Sharing: They expose team members to different parts of the codebase, fostering a shared understanding.

• Build Team Culture: Collaborative and respectful reviews strengthen trust and teamwork.

By following these principles, you can make your code reviews both productive and positive, ultimately leading to better outcomes for your projects and team.