🏗️ SYSTEM DESIGN MONDAY #6 - Let's Design Instagram (Feed + Media at Scale)

Bigger system this week. Core requirements:

✅ Users post photos/videos
✅ Users follow other users
✅ Users see a feed of posts from people they follow
✅ Massive read traffic - feeds are viewed constantly, posts created far less often

The hardest question in this whole design: how do you GENERATE the feed?

🔹 Option A - Pull model (fan-out on read): When a user opens their feed, query posts from everyone they follow, merge, and sort by time.

[User requests feed] → [Query posts from all 500 people they follow] → [Merge + sort] → [Return]

Simple, but SLOW for users following many accounts - that query fans out wide every single time they open the app.

🔹 Option B - Push model (fan-out on write): When someone posts, immediately push that post into the precomputed feed of every follower.

[User posts] → [Push post into feed_cache for each of their 10K followers]

Feed reads become instant (just read your precomputed feed) - but this completely breaks down for celebrities with 50 million followers, since one post would mean 50 million writes.

✅ The real answer (hybrid): Push model for regular users, pull model for accounts above a follower threshold (celebrities). Merge the two at read time. This exact hybrid approach is used by real large-scale social platforms, and mentioning it shows you understand that there's rarely one clean solution at true scale - just the least-bad tradeoff for each case.

Media storage: Photos/videos themselves don't belong in your database - they go in object storage (like S3), with only the URL/reference stored in the database. A CDN (Content Delivery Network) then caches that media geographically close to users, so someone in Tokyo isn't fetching an image from a US-based server every time.

[App Server] → stores reference → [Database]
[App Server] → stores actual file → [Object Storage] → cached globally by → [CDN]

Which feed generation approach would you have guessed first, before reading the hybrid answer? 👇

🔍 GUESS THE OUTPUT #6
Language: Python

python
def outer():
    x = 10
    def inner():
        print(x)
        x += 1
    inner()

outer()

Lock in your answer, then vote on the quiz below 👇

🔍 GUESS THE OUTPUT #6 - full breakdown

python
def outer():
    x = 10
    def inner():
        print(x)
        x += 1
    inner()

outer()

Answer: UnboundLocalError: local variable 'x' referenced before assignment

This one surprises a lot of people - it does NOT print 10. Here's why: because inner() assigns to x (x += 1), Python treats x as a LOCAL variable throughout the entire function the moment it sees any assignment to it, even before that line executes. So the print(x) line is trying to read a local x that hasn't been assigned yet.

Fixed version:

python
def outer():
    x = 10
    def inner():
        nonlocal x
        print(x)
        x += 1
    inner()

The nonlocal keyword tells Python "this x refers to the enclosing function's variable, not a new local one."

This is a genuinely tricky one - Python decides variable scope at compile time based on whether a name is assigned anywhere in the function, not based on execution order. Great interview question for testing real understanding of closures vs. just pattern-matching syntax.

⚠️ COMMON INTERVIEW MISTAKE #5 - Not Asking ANY Questions at the End

"Do you have any questions for me?" is not a courtesy formality - interviewers actively judge your answer to this, and "no, I think you covered everything" is a genuinely weak close to an interview.

Why it matters: it's your best remaining signal-generating opportunity, AND it shows genuine engagement rather than someone just trying to get through the process.

✅ Strong questions to have ready (tailor to who you're talking to):

To an engineer: "What's the most painful part of the codebase right now, and is there a plan to address it?"

To a manager: "How do you measure success for someone in this role after 6 months?"

To anyone: "What's something about working here that surprised you, in either a good or bad way?"

❌ Avoid questions Google can already answer (basic company facts, publicly available info) - it signals you didn't do basic homework.

❌ Avoid ONLY asking about perks/benefits/PTO in the first interview - save that for later rounds or the recruiter; asking it too early to your potential future teammates can look like priorities are misplaced.

Save at least 2-3 genuinely good questions for every interview. It's one of the highest-leverage, lowest-effort improvements you can make.

What's the best question you've ever asked (or been asked) at the end of an interview? 👇

🎯 CODING CHALLENGE #10 - Word Ladder (BFS Shortest Path)
Difficulty: Hard | Asked at: Google, Amazon, LinkedIn

Given beginWord, endWord, and a word list, find the length of the shortest transformation sequence, changing one letter at a time, where each intermediate word must exist in the word list.

Input: beginWord = "hit", endWord = "cog"
wordList = ["hot","dot","dog","lot","log","cog"]
Output: 5   ("hit" -> "hot" -> "dot" -> "dog" -> "cog")

💡 Hint: "Shortest transformation" is your biggest clue - this is shortest path in an unweighted graph, which means BFS, not DFS.

Solution:

python
from collections import deque

def ladder_length(begin_word, end_word, word_list):
    word_set = set(word_list)
    if end_word not in word_set:
        return 0

    queue = deque([(begin_word, 1)])
    visited = {begin_word}

    while queue:
        word, steps = queue.popleft()
        if word == end_word:
            return steps

        for i in range(len(word)):
            for c in 'abcdefghijklmnopqrstuvwxyz':
                next_word = word[:i] + c + word[i+1:]
                if next_word in word_set and next_word not in visited:
                    visited.add(next_word)
                    queue.append((next_word, steps + 1))

    return 0

Complexity: O(M² × N) time, where M is word length and N is the word list size - for each word, we try M positions × 26 letters, each generating an M-length string.

Common mistake: Reaching for DFS because it "feels" more natural for pathfinding - DFS can find A path, but has no guarantee it finds the SHORTEST one without exploring everything. The moment you see "shortest" or "minimum steps" in unweighted graph problems, that's your signal: BFS.

This is one of those problems where recognizing the underlying pattern (shortest path = BFS) matters far more than clever tricks - the "graph" here isn't even given to you explicitly, you have to realize that words are nodes and one-letter-difference is an edge.

Did you recognize this as a graph problem right away, or did it take a second to see it? 👇

📚How I’d Prepare for an IT Interview Before I Even Applied

If you're applying for technical roles, don't prepare for interviews and certifications as two completely separate things.
Use them together.

1️⃣ Start with the role

🔹 roadmap.sh
Pick your path and identify the technologies you actually need.
Data Engineer, DevOps, Cloud, Cybersecurity, Backend, etc.

2️⃣ Find the questions you'll actually face

🔹 IT Interview Questions
It has role-specific collections across Cloud, Data/BI, Cybersecurity, Software/DevOps and many more.

Don't memorize the answers. Use the questions to find what you don't understand.

3️⃣ Go deeper on weak areas
Some of the best free technical material isn't packaged as "interview prep."

🔹 MIT Missing Semester
🔹 Google SRE Books
🔹 Full Stack Deep Learning
🔹 DataTalksClub

These are the kind of resources worth keeping long after the interview.

4️⃣ If the role requires cloud, prepare for the certification side too

This is where certification material becomes useful even if you aren't planning to take the exam.

🔹 Free training & study materials

This is a platform to learn different materials including AWS, Microsoft, CompTIA and other cloud/IT certification resources.

And always keep the official documentation nearby:
AWS
Azure
Google Cloud

5️⃣ If You Need actual certification practice
🔹 Exam practice

Use this specifically when you're preparing for a certification. I wouldn't use it as an interview-question substitute.

For official practice, also check:
🔹 AWS Skill Builder
🔹 Microsoft Learn

6️⃣ The final test
Close everything. Pick 10 questions. Answer them out loud.

Then take one architecture problem and explain:
requirements → architecture → trade-offs → failure scenarios → scaling → cost

If you can't explain your answer without looking something up, you've found what to study next.

Don't collect resources. Build a preparation loop:
Learn → practice → identify gaps → study → explain → repeat.

That's what actually gets you interview-ready.

🗣️ BEHAVIORAL INTERVIEW #5 - "Tell Me About a Time You Disagreed With a Decision"

Similar to the conflict question, but this one specifically probes: can you push back on authority respectfully, and can you also let go gracefully if you don't get your way?

✅ The structure that works:

1. What was the decision, and why did you disagree?
2. How did you raise your concern (privately? with data? at the right time?)
3. What was the outcome - did they change course, or did you disagree and commit?
4. How did you handle it either way?

Example:
"My manager decided to launch a feature without A/B testing it first, to hit a deadline. I disagreed, so I put together a quick doc showing the risk based on a similar past launch that had gone poorly without testing. He read it, but ultimately decided the deadline pressure from a client commitment outweighed the risk. I made sure my concerns were documented, then fully committed to making the launch as smooth as possible - added extra monitoring and a fast rollback plan just in case. It ended up working out fine, but even if it hadn't, I'd rather have raised the concern clearly once than either stayed silent or kept relitigating it after the decision was made."

This shows: you can think critically and push back, you use evidence rather than just opinion, and - critically - you know how to "disagree and commit" once a decision is made, which is a trait senior leaders explicitly look for.

Have you ever disagreed with a decision and had to commit to it anyway? How'd that feel? 👇

🧠 EDUCATIONAL CS #5 - Concurrency: Race Conditions vs. Deadlocks

Two concurrency terms that get confused constantly - here's the clean distinction.

🔹 Race condition: the outcome depends on unpredictable TIMING of operations. We saw this back in Spot the Bug #2 - two threads incrementing a shared counter, and depending on exact timing, updates get lost.

🔹 Deadlock: two or more threads are permanently stuck, each waiting for a resource the other one holds, forever.

Thread A: holds Lock 1, waiting for Lock 2
Thread B: holds Lock 2, waiting for Lock 1
→ Neither can ever proceed. Frozen forever.

The classic fix for deadlocks: always acquire locks in a consistent, agreed-upon order across your entire codebase. If EVERY thread always locks Resource 1 before Resource 2 (never the reverse), the circular waiting pattern above becomes structurally impossible.

Why this matters in interviews: system design and backend interviews increasingly probe concurrency understanding, even outside dedicated "concurrency" questions - e.g., "what happens if two requests try to update the same row at the same time?" is really asking about race conditions, often expecting you to mention database-level solutions like row locking or optimistic concurrency control (checking a version number before committing a write).

Race condition or deadlock - which one is scarier to debug in your experience, and why? 👇

📄 RESUME ROAST #6 - Bonus Round: The Objective Statement

> "Objective: To obtain a challenging position in a dynamic company where I can utilize my skills and grow professionally while contributing to organizational success."

This one's almost a meme at this point. What's wrong? 👇

.
.
.

The roast: This sentence could be copy-pasted onto literally any resume, for literally any job, in any industry, and nobody would notice. It says absolutely nothing specific about you, and it wastes prime real estate - the very TOP of your resume, the part guaranteed to get read.

Objective statements are largely considered outdated in software engineering resumes. Recruiters already know your objective is "get this job" - you don't need to state it.

✅ Replace it with a brief, specific summary (optional, and only if it adds real value):

> "Backend engineer with 4 years building high-throughput payment systems in Python and Go; specialized in reducing latency at scale."

This tells a recruiter, in one line, exactly what box to file you in and why they should keep reading - which is the entire job of the first line of your resume.

If your resume still has an "Objective" section, that might be worth revisiting today. Does yours? 👇

📊 SQL TUESDAY #7 (BONUS) - NULLs: The Silent Query Killer

NULL doesn't behave like a normal value, and it quietly breaks queries that "look" correct. This trips up even experienced engineers.

customers
+----+---------+---------+
| id | name    | phone   |
+----+---------+---------+
| 1  | Alice   | 555-1234|
| 2  | Bob     | NULL    |
| 3  | Charlie | NULL    |

⚠️ Trap #1: WHERE phone = NULL returns ZERO rows - always. NULL means "unknown," and "is unknown equal to unknown?" is itself unknown, not true. You must use IS NULL:

sql
SELECT * FROM customers WHERE phone IS NULL;  -- ✅ correct

⚠️ Trap #2: COUNT(phone) vs COUNT(*) give different results. COUNT(*) counts all rows; COUNT(column) only counts non-NULL values in that column.

sql
SELECT COUNT(*) FROM customers;        -- 3
SELECT COUNT(phone) FROM customers;    -- 1

⚠️ Trap #3: NULL values are often silently EXCLUDED from aggregate calculations in ways people don't expect:

sql
SELECT AVG(phone_call_count) FROM customers;
-- NULLs are ignored entirely, NOT treated as 0.
-- If you wanted them treated as 0, use:
SELECT AVG(COALESCE(phone_call_count, 0)) FROM customers;

COALESCE(value, default) returns the first non-NULL argument - extremely useful for handling missing data gracefully instead of letting it silently skew your results.

Has a NULL-related bug ever quietly thrown off a real report at your job? 👇

💬 MOTIVATIONAL / DISCUSSION - The Uncomfortable Truth About Rejections

Here's something senior engineers rarely say out loud: almost everyone gets rejected by companies they were genuinely qualified for. Not because they were bad candidates - because interviewing has enormous variance. A different interviewer, a slightly different question, a slightly off day, and the same person gets a completely different outcome.

This isn't meant to lower the bar - it's meant to correct a mental model that causes real damage: treating every single rejection as objective proof you're "not good enough."

The engineers who eventually land great offers aren't the ones who never get rejected. They're the ones who treat each rejection as one data point, extract whatever's actually learnable from it (was there a real skill gap, or was it just variance?), and keep going.

If you're in the middle of a job search right now and it's been rough - you're not alone, and it's not necessarily a reflection of your actual ability.

What's one thing that's kept you going during a tough job search? Let's hear it 👇

🎯 CODING CHALLENGE #11 (BONUS) - Number of Islands
Difficulty: Medium | Asked at: Amazon, Google, Meta

Given a 2D grid of '1' (land) and '0' (water), count the number of islands (connected groups of land, horizontally/vertically).

Input:
11000
11000
00100
00011

Output: 3

💡 Hint: This is graph traversal on an implicit grid graph - each land cell is a node, adjacent land cells are connected edges. DFS or BFS, "sinking" each island as you find it so you don't count it twice.

Solution:

python
def num_islands(grid):
    if not grid:
        return 0

    rows, cols = len(grid), len(grid[0])
    count = 0

    def sink(r, c):
        if r < 0 or r >= rows or c < 0 or c >= cols or grid[r][c] != '1':
            return
        grid[r][c] = '0'  # mark as visited by sinking it
        sink(r+1, c)
        sink(r-1, c)
        sink(r, c+1)
        sink(r, c-1)

    for r in range(rows):
        for c in range(cols):
            if grid[r][c] == '1':
                count += 1
                sink(r, c)

    return count

Complexity: O(rows × cols) time - every cell is visited a constant number of times. Space is O(rows × cols) worst case for the recursion stack, if the entire grid is one giant island.

Common mistake: Modifying the grid in place without realizing that mutates the input the caller passed in - perfectly fine for most interview settings, but worth mentioning out loud: "I'm mutating the grid directly to track visited cells - if we need to preserve the original input, I'd use a separate visited set instead."

This exact pattern - grid + DFS/BFS + "sinking"/marking visited - solves a huge family of "connected regions" problems. Worth having memorized cold.

Would you use DFS or BFS here, and does it actually matter for this particular problem? 👇

🏗 SYSTEM DESIGN FRIDAY #7 (BONUS) - Message Queues & Asynchronous Processing

Not everything needs an instant response. Sending a confirmation email, processing an uploaded video, generating a report - these can happen "in the background" instead of forcing the user to wait.

[Client] → [App Server] → [Message Queue] → [Worker Service] → [Database/Storage]
              (responds "got it!"                  (processes asynchronously,
               immediately)                          at its own pace)

Flow: instead of doing slow work directly in the request, the app server drops a "job" onto a queue (like RabbitMQ, Kafka, or SQS) and immediately responds to the user. Separate worker processes pull jobs off the queue and do the actual heavy lifting, independent of the original request's timeline.

Why this matters at scale:
✅ The user gets a fast response instead of waiting on slow work
✅ If a worker crashes mid-job, the message can be safely retried instead of being lost
✅ Workers can be scaled independently from your main app servers - heavy video processing doesn't need to compete for resources with fast web requests

⚠️ The follow-up interviewers ask: "What if the same job gets processed twice?" This is the concept of idempotency - designing your job handlers so processing the same message multiple times produces the same end result as processing it once (e.g., "set status to complete" rather than "increment counter by one," which would double-count on a retry).

Real example: when you upload a video to a platform like YouTube, encoding it into multiple resolutions happens exactly this way - asynchronously, off a queue, while you're immediately told "upload successful, processing now."

Where in a system you've worked on could background processing via a queue have improved things? 👇

⚠️ COMMON INTERVIEW MISTAKE #6 (BONUS) - Memorizing Solutions Instead of Understanding Patterns

Grinding 300 LeetCode problems by memorizing each specific solution is a losing strategy - the moment an interviewer changes ONE constraint, memorized solutions fall apart, because there was never any real understanding underneath them.

✅ The better strategy: learn the ~15 underlying PATTERNS (sliding window, two pointers, BFS/DFS, dynamic programming, backtracking, heaps, intervals, topological sort, and a few others), and practice recognizing which pattern a NEW, unfamiliar problem maps to.

A genuinely strong signal in interviews: when given a twist on a problem you've never seen ("now the array is sorted" or "now you need the top K instead of just one"), you can reason your way to the adjusted solution live, instead of freezing because it doesn't match anything memorized.

Quick self-test: could you solve a completely novel problem using the sliding window pattern right now, without looking anything up? If not, that's a sign to focus on the underlying technique, not another 20 random problems.

Which pattern do you feel weakest on right now? Let's crowdsource some practice problems for it in the comments 👇

🗣️ BEHAVIORAL INTERVIEW #6 (BONUS) - "Where Do You See Yourself in 5 Years?"

This question isn't really about predicting the future - nobody expects a precise 5-year roadmap. It's testing: are your goals compatible with what THIS role/company can actually offer you?

❌ Answers that raise flags:
- "I want to be a manager" (fine, but say it thoughtfully if the role is individual-contributor track, and be ready to discuss it)
- "I'm not sure, just going with the flow" (reads as a lack of direction or ambition)
- An answer wildly misaligned with the role (e.g., "I want to move into a completely different field" for a specialized technical role)

✅ A strong structure:
"In 5 years, I'd like to have deepened my expertise in [relevant technical area], and ideally be mentoring more junior engineers or leading technical design for larger projects. I'm drawn to this role specifically because [company/team] gives me a path toward that, given [specific reason tied to their team structure or challenges]."

This shows ambition, some self-awareness about growth direction, and - critically - that you've actually thought about whether THIS specific opportunity fits that direction, rather than giving a generic answer that could apply anywhere.

What did you actually say the last time you got this question? Be honest, even if it wasn't your best answer 😄

💬 CLOSING DISCUSSION - What Are You Working Toward Right Now?

We've covered a lot of ground together - coding patterns, SQL, system design, behavioral prep, salary scripts, and enough resume roasts to make anyone paranoid about their bullet points (in a good way).

Here's the truth: none of this matters unless you actually put it into practice. Reading about the sliding window pattern doesn't make you fast at recognizing it - solving 5 problems with it does. Reading a negotiation script doesn't make it feel natural - saying it out loud once, even just to yourself, does.

So tell us: what's your current goal? A specific company? A level up? Your first engineering job? A career switch into tech?

Drop it below. This channel is more useful as a community than as a broadcast - let's actually help each other get there. 🚀

🎯 CODING CHALLENGE #12 - Group Anagrams
Difficulty: Medium | Asked at: Amazon, Meta, Uber

Given an array of strings, group the anagrams together.

Input: ["eat","tea","tan","ate","nat","bat"]
Output: [["eat","tea","ate"],["tan","nat"],["bat"]]

💡 Hint: Two words are anagrams if and only if their sorted characters are identical. That sorted string makes a perfect hash key.

Solution:

python
from collections import defaultdict

def group_anagrams(strs):
    groups = defaultdict(list)
    for s in strs:
        key = ''.join(sorted(s))
        groups[key].append(s)
    return list(groups.values())

Complexity: O(n · k log k) time, where n is the number of strings and k is the max string length - sorting each string dominates. Space O(n · k).

Common mistake: Trying to compare every pair of strings directly (O(n²) comparisons) instead of using a canonical key to bucket them in one pass. Any time you see "group things that share a property," ask: "what's the key I can compute once per item?"

Bonus optimization: instead of sorting (O(k log k)), you can build a character-count tuple as the key in O(k) time - faster for long strings. Worth mentioning if you want to show extra depth.

Sorted-string-as-key or character-count-as-key - which would you reach for first? 👇

🐛 SPOT THE BUG #6
Language: Python

python
class BankAccount:
    def __init__(self, balance):
        self.balance = balance

    def withdraw(self, amount):
        if amount <= self.balance:
            self.balance -= amount
            return True
        return False

# Two threads calling withdraw(100) at nearly the same time
# on an account with balance = 100

What breaks here under concurrent access? 👇

.
.
.

The bug: Classic check-then-act race condition (a cousin of the counter bug from Spot the Bug #2, but with real money on the line). Thread A checks 100 <= 100 → true. Before it subtracts, Thread B also checks 100 <= 100 → true. Now BOTH threads proceed to withdraw, and the balance goes to -100 - the check and the action weren't atomic together.

Fixed version (using a lock):

python
import threading

class BankAccount:
    def __init__(self, balance):
        self.balance = balance
        self.lock = threading.Lock()

    def withdraw(self, amount):
        with self.lock:
            if amount <= self.balance:
                self.balance -= amount
                return True
            return False

The lock ensures the check-and-subtract happens as one atomic unit - no other thread can interleave in the middle.

💡 This exact pattern (check-then-act on shared state) is one of the most common sources of real financial bugs in production systems, not just interview trivia. Any time you see "if condition, then modify shared state," ask: "can two threads see the same 'before' state at once?"

Have you seen a check-then-act bug in real code before? 👇