🎯 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? 👇

📊 SQL SATURDAY #8 (BONUS) - Optimization: Why Your Query Is Slow

You've learned the syntax. Now let's talk about WHY some queries crawl on large tables - a favorite senior-level SQL interview topic.

The #1 cause: missing indexes. Without an index, the database does a full table scan - checking every single row to find matches, like reading an entire book to find one sentence.

sql
-- Without an index on email, this scans ALL rows:
SELECT * FROM users WHERE email = 'alice@example.com';

-- Add an index:
CREATE INDEX idx_users_email ON users(email);
-- Now the database can jump almost directly to matching rows,
-- similar in spirit to binary search on a sorted structure.

⚠️ But indexes aren't free - they speed up reads, but slow down writes (every INSERT/UPDATE also has to update the index), and they take up disk space. This is exactly why you don't index every column "just in case" - it's a genuine tradeoff, and knowing that tradeoff is what separates a junior from a senior answer here.

Second common cause: functions on indexed columns.

sql
-- This CANNOT use an index on order_date efficiently:
SELECT * FROM orders WHERE YEAR(order_date) = 2024;

-- This CAN use the index:
SELECT * FROM orders WHERE order_date >= '2024-01-01' AND order_date < '2025-01-01';

Wrapping a column in a function usually forces the database to compute that function for EVERY row before it can compare - defeating the index. Rewriting the condition as a plain range comparison lets the index actually do its job.

*Third: SELECT * when you only need 2 columns* - pulling unnecessary data across the network and, if you have a covering index available, missing the chance for the database to answer entirely from the index without touching the full table row at all.

What's the slowest query you've ever had to debug and fix? 👇

🕵️ RECRUITER SECRETS #6 - Why Referrals Actually Work (and How to Get One)

An internal referral doesn't guarantee you the job - but it dramatically increases the odds your resume actually gets read by a human, instead of getting buried under hundreds of cold applications.

Here's what's actually happening behind the scenes: most companies have an internal referral bonus for employees, AND recruiters are often measured on how many hires come through referrals (it's a cheaper, faster, generally higher-quality channel than cold sourcing). That means employees and recruiters both have real incentive to help you.

✅ How to actually get a referral, without being awkward about it:

1. Don't message a stranger with "hey, can you refer me?" as your opening line - that's an easy no.
2. Find genuine common ground first (same school, same previous company, mutual connection) or engage with their content authentically.
3. Ask for a 15-minute chat about their experience at the company first - most people enjoy talking about their own job.
4. If the conversation goes well, THEN ask: "Would you be comfortable referring me for the [specific role]? Happy to send my resume and a short blurb to make it easy."

Making it easy for them (a ready-to-forward blurb, not just "here's my resume, good luck") massively increases the odds they follow through.

Have you ever gotten a referral from a cold outreach? What worked? 👇

ESSENTIAL ARRAY PATTERNS 📌
Every Developer Should Know

1. TWO POINTERS

Find pairs, remove duplicates, compare elements
from both ends, and optimize array traversals.

2. SLIDING WINDOW

Solve subarray and contiguous sequence problems
efficiently without repeatedly recalculating values.

3. PREFIX SUM

Answer range-sum and cumulative queries quickly
by reusing previously computed sums.

4. KADANE'S ALGORITHM

Find the maximum-sum subarray in O(n) time.

5. BINARY SEARCH

Whenever the search space is sorted or monotonic,
think O(log n) instead of scanning everything.

6. CYCLIC SORT

Useful for finding missing, duplicate, or misplaced
numbers when values belong to a known range.

7. MERGE INTERVALS

Handle overlapping, merging, and scheduling
interval problems efficiently.

8. MONOTONIC STACK

Solve next greater/smaller element problems and
many range-optimization problems in O(n).

9. HASH MAP / FREQUENCY COUNT

Count occurrences, detect duplicates, and perform
fast lookups using hashing.

10. SORTING + GREEDY

Sort the data first, then make locally optimal
decisions to reach the best overall result.

✅ THE GOAL

Don't memorize individual solutions. Learn to recognize the pattern behind the problem.
Pattern recognition
→ Faster approach
→ Better complexity
→ Stronger interview performance

⚠️ COMMON INTERVIEW MISTAKE #7 (BONUS) - Over-Engineering the Solution

The opposite failure mode from jumping into code too fast: spending 10 minutes designing an elaborate, "enterprise-grade" solution for a problem that just needed a simple loop.

This happens most often to engineers who've read a lot about design patterns and want to show off - but interviewers usually read it as poor judgment about scope, not seniority.

✅ What to do instead: match the complexity of your solution to the actual complexity of the problem. If the interviewer explicitly says "assume this only ever runs once, on a small input," you don't need to discuss caching, sharding, or abstract factory patterns.

A good gut-check question to ask yourself out loud: "Given the constraints we discussed, is this the SIMPLEST solution that meets them?" If you want to show deeper knowledge, mention the more complex approach briefly as a "if this needed to scale further, I'd consider X" - without actually implementing it unless asked.

Simplicity that solves the actual problem beats complexity that solves an imagined one. Every time.

Have you ever over-engineered something in an interview (or in real production code)? 😅

📂 API Design Roadmap
┃
┣ 📂 Foundations
┃ ┣ 📂 What is an API?
┃ ┣ 📂 HTTP & HTTPS Fundamentals
┃ ┣ 📂 Request & Response Lifecycle
┃ ┣ 📂 JSON & Data Formats
┃ ┗ 📂 API Design Principles
┃
┣ 📂 REST API Design
┃ ┣ 📂 REST Architecture
┃ ┣ 📂 Resources & Endpoints
┃ ┣ 📂 HTTP Methods (GET, POST, PUT, DELETE, PATCH)
┃ ┣ 📂 Status Codes
┃ ┗ 📂 REST Best Practices
┃
┣ 📂 API Documentation
┃ ┣ 📂 OpenAPI Specification
┃ ┣ 📂 Swagger UI
┃ ┣ 📂 API Reference Documentation
┃ ┣ 📂 Examples & SDKs
┃ ┗ 📂 Versioned Documentation
┃
┣ 📂 Authentication & Authorization
┃ ┣ 📂 API Keys
┃ ┣ 📂 JWT Authentication
┃ ┣ 📂 OAuth 2.0 & OpenID Connect
┃ ┣ 📂 Role-Based Access Control (RBAC)
┃ ┗ 📂 Token Management
┃
┣ 📂 API Security
┃ ┣ 📂 HTTPS & TLS
┃ ┣ 📂 CORS Configuration
┃ ┣ 📂 CSRF & XSS Protection
┃ ┣ 📂 Rate Limiting & Throttling
┃ ┗ 📂 Input Validation & Sanitization
┃
┣ 📂 Advanced API Architectures
┃ ┣ 📂 GraphQL
┃ ┣ 📂 gRPC
┃ ┣ 📂 WebSockets
┃ ┣ 📂 Server-Sent Events (SSE)
┃ ┗ 📂 Event-Driven APIs
┃
┣ 📂 API Performance
┃ ┣ 📂 Pagination
┃ ┣ 📂 Filtering & Sorting
┃ ┣ 📂 Caching Strategies
┃ ┣ 📂 Compression
┃ ┗ 📂 Performance Optimization
┃
┣ 📂 API Reliability
┃ ┣ 📂 Error Handling
┃ ┣ 📂 Retry Strategies
┃ ┣ 📂 Idempotency
┃ ┣ 📂 Circuit Breaker Pattern
┃ ┗ 📂 Health Checks
┃
┣ 📂 API Testing
┃ ┣ 📂 Unit Testing
┃ ┣ 📂 Integration Testing
┃ ┣ 📂 Postman & Insomnia
┃ ┣ 📂 Load Testing
┃ ┗ 📂 Contract Testing
┃
┣ 📂 API Deployment
┃ ┣ 📂 API Gateways
┃ ┣ 📂 Reverse Proxies
┃ ┣ 📂 Docker & Containers
┃ ┣ 📂 CI/CD Pipelines
┃ ┗ 📂 Cloud Deployment
┃
┣ 📂 Monitoring & Observability
┃ ┣ 📂 Logging
┃ ┣ 📂 Metrics Collection
┃ ┣ 📂 Distributed Tracing
┃ ┣ 📂 Prometheus & Grafana
┃ ┗ 📂 API Analytics
┃
┣ 📂 AI-Powered APIs
┃ ┣ 📂 OpenAI API Integration
┃ ┣ 📂 Function Calling
┃ ┣ 📂 Streaming Responses
┃ ┣ 📂 AI Agent APIs
┃ ┗ 📂 Cost & Token Optimization
┃
┣ 📂 Real-World Projects
┃ ┣ 📂 Authentication API
┃ ┣ 📂 E-commerce REST API
┃ ┣ 📂 Payment Gateway API
┃ ┣ 📂 AI Chat API
┃ ┗ 📂 Microservices API Platform
┃
┣ 📂 Practice & Growth
┃ ┣ 📂 Build Public APIs
┃ ┣ 📂 Contribute to API Projects
┃ ┣ 📂 Write API Documentation
┃ ┣ 📂 API Design Reviews
┃ ┗ 📂 Interview Preparation
┃
┗ 📂 Career & Monetization
┣ 📂 Backend Engineer Roles
┣ 📂 API Platform Engineer
┣ 📂 SaaS Development
┣ 📂 API Consulting & Freelancing
┗ 📂 Continuous Learning

👉 Follow this consistently for 2–4 months and you'll be able to design, build, secure, and scale production-ready APIs with confidence.

🧠 DSA Topics You Should Learn in Order

Confused about what to learn in DSA? Follow this order and build your concepts step by step 👨‍💻🔥

🟢 Foundation

1. Time & Space Complexity ⏱️
• Understand Big O notation
• Learn how to analyze your solutions

2. Arrays & Strings 📦
• Master traversal, searching and basic manipulation
• Practice two pointers and sliding window

3. Recursion & Backtracking 🔄
• Understand recursive thinking
• Solve subsets, permutations and combination problems

🟡 Core Data Structures

4. Linked Lists 🔗
• Learn singly and doubly linked lists
• Practice reversal and cycle problems

5. Stacks & Queues 📚
• Understand LIFO and FIFO
• Learn monotonic stack and deque patterns

6. Hashing #️⃣
• Use hash maps and hash sets effectively
• Solve frequency and lookup-based problems

🔴 Advanced

7. Trees & Graphs 🌳
• Learn traversals, BFS and DFS
• Move towards harder graph problems

8. Heaps & Priority Queues ⛰
• Understand heap operations
• Practice top-K and scheduling problems

9. Dynamic Programming 🧩
• Start with 1D and 2D DP
• Gradually move to more complex patterns

10. Greedy & Advanced Algorithms ⚡️
• Learn greedy strategies, binary search and important algorithmic patterns

💡 Don't rush into advanced topics. Strong fundamentals make DSA much easier.

💾 Save this roadmap and follow it step by step.

@Coding_interview_preparation

Sorting Algorithms Summary

🚫 5 Mistakes Beginners Make While Learning Coding

Learning to code is not just about writing more code. Avoiding these mistakes can save you months of frustration 👨‍💻⚡️

1. Learning Too Many Languages 🔄
• Jumping between Python, C++, Java and JavaScript
• Master one language before moving to another

2. Watching Tutorials Without Practicing 📺
• Tutorials feel productive, but passive learning isn't enough
• Write the code yourself and solve problems without copying

3. Trying to Learn Everything at Once 🧠
• DSA, Web Dev, AI, Cloud, Cybersecurity...
• Pick one direction and build a strong foundation first

4. Avoiding Projects 🛠
• Completing courses without building anything
• Projects help you turn concepts into real skills

5. Giving Up When You Get Stuck 😵‍💫
• Getting errors and not knowing the solution is normal
• Learn to debug, search documentation and understand the problem

💡 You don't need to know everything. You just need to keep improving.

📌 Save this if you're learning to code.