🐛 SPOT THE BUG #1
Language: Python

python
def get_average(scores):
    total = 0
    for score in scores:
        total += score
    return total / len(scores)

print(get_average([]))

What breaks here? Try to spot it before reading on 👇

.
.
.

The bug: ZeroDivisionError when scores is empty. It's an easy edge case to forget under interview pressure, but interviewers plant empty-input tests specifically to see if you check for them.

Fixed version:

python
def get_average(scores):
    if not scores:
        return 0  # or raise a meaningful exception, depending on requirements
    return sum(scores) / len(scores)

💡 Takeaway: Before you write a single line of code in an interview, say out loud: "What happens with an empty input? A single element? Negative numbers?" It shows structured thinking, and it catches bugs like this before they exist.

Common File Types Explained

🗣️ BEHAVIORAL INTERVIEW #1 - "Tell Me About Yourself"

This question kills more interviews than any coding question ever will. Not because it's hard - because people ramble.

❌ What NOT to do: Recite your entire resume chronologically starting from university.

✅ What actually works - the "Present, Past, Future" formula:

1️⃣ Present: What you do right now, in one sentence.
2️⃣ Past: How you got here - the 1-2 experiences most relevant to THIS role.
3️⃣ Future: Why you're excited about this specific opportunity.

Example:
"Right now I'm a backend engineer at a fintech startup, focused on building payment infrastructure that processes millions of transactions daily. Before that, I spent three years at [Company] scaling their API from handling thousands to millions of requests, which is actually what got me excited about distributed systems. I'm looking at this role because you're solving similar scaling challenges, but at a size and complexity I haven't tackled yet."

Under 60 seconds. Relevant. Forward-looking.

Try writing your own "Present, Past, Future" answer in the comments - I'll give feedback on a few 👇

⚠️ COMMON INTERVIEW MISTAKE #1 - Jumping Straight Into Code

The single most common thing that turns a "strong hire" into a "no hire": candidates hear the problem and immediately start typing.

Here's what that signals to the interviewer: you don't clarify requirements, you don't think about edge cases, and you might do the same thing on a real production ticket.

✅ What strong candidates do instead:

1. Repeat the problem back in your own words
2. Ask clarifying questions ("Can the array contain duplicates? Negative numbers? Is it sorted?")
3. State your approach out loud BEFORE writing code
4. Mention the time/space complexity of your plan
5. THEN code

This adds maybe 90 seconds. It makes you look like someone who's shipped real software, not someone doing a LeetCode speedrun.

Have you ever jumped into code too fast and regretted it? Tell us the story 😅

🎯 CODING CHALLENGE #2 - Valid Parentheses
Difficulty: Easy | Asked at: Microsoft, Meta, Bloomberg

Given a string containing just (, ), {, }, [, ], determine if the input is valid. Brackets must close in the correct order.

Input: "{[()]}"  → true
Input: "{[(])}"  → false
Input: "((("     → false

💡 Hint: What data structure naturally handles "last opened, first closed"?

Solution:

python
def is_valid(s):
    stack = []
    pairs = {')': '(', ']': '[', '}': '{'}
    for char in s:
        if char in pairs.values():
            stack.append(char)
        elif char in pairs:
            if not stack or stack.pop() != pairs[char]:
                return False
        else:
            return False
    return not stack

Complexity: O(n) time, O(n) space (worst case, all opening brackets).

Common mistake: Forgetting to check if the stack is empty at the very end. "(((" never fails inside the loop - you only catch it because the stack still has unclosed brackets when you finish.

Stacks show up constantly in interviews. Where else have you seen one used? 👇

📄 RESUME ROAST #1

Here's a real-style resume bullet. Before I roast it, tell me what's wrong:

> "Responsible for developing and maintaining web applications using React and Node.js, worked closely with team members to deliver features on time."

What's the problem? Take a guess before scrolling 👇

.
.
.

The roast:
❌ "Responsible for" - passive, says nothing about impact
❌ No numbers. How many applications? How many users? What team size?
❌ "Delivered features on time" - that's the baseline expectation of the job, not an achievement

Rewritten:
> "Built and shipped 4 customer-facing features in React/Node.js used by 50K+ monthly active users; reduced average page load time by 35% through code-splitting and lazy loading."

Same job, same skills - completely different impression. Specifics + numbers = credibility.

Got a resume bullet you're not sure about? Drop it below and I'll roast it (kindly) 🔥

🔍 GUESS THE OUTPUT #2 - full breakdown

python
def add_item(item, items=[]):
    items.append(item)
    return items

print(add_item(1))
print(add_item(2))
print(add_item(3))

Answer:

[1]
[1, 2]
[1, 2, 3]

Surprised? Mutable default arguments in Python are created once, when the function is defined - not each time it's called. So that same list keeps getting reused and mutated across calls.

The fix:

python
def add_item(item, items=None):
    if items is None:
        items = []
    items.append(item)
    return items

This exact bug has caused real production incidents. It's also a favorite "gotcha" question at Python-heavy companies.

Did you know about this one, or did it just break your brain a little? 😄

🔥 Binary Search Coding Problems (Must for Interviews) 🔍💻

These are high-frequency interview problems based on Binary Search. Focus on logic + pattern recognition.

🧠 1️⃣ Basic Binary Search (Find Element Index)

Problem:
Given a sorted array, find the index of a target element.

Approach:

• Compare with middle
• Go left or right
• Repeat until found

👉 This is the foundation of all binary search problems.

🧠 2️⃣ First Occurrence of Element

Problem:
Find the first position of a target in a sorted array with duplicates.

Example:
Array:, Target = 2 → Output: index 1[1][2][3]

Insight:
👉 Don’t stop at first match
👉 Continue searching on the left side

🧠 3️⃣ Last Occurrence of Element

Problem:
Find the last position of a target.

Example:
Array: → Output: index 3[1][2][3]

Insight:
👉 Move towards the right side after finding match

🧠 4️⃣ Count Occurrences

Problem:
Count how many times a number appears.

Approach:
👉 count = last_index - first_index + 1

🧠 5️⃣ Search in Rotated Sorted Array

Problem:
Array is rotated:
Find target efficiently.[4][5][6][7][0][1][2]

Insight:
👉 One half is always sorted
👉 Decide which side to search

🧠 6️⃣ Find Minimum in Rotated Sorted Array

Problem:
Find smallest element in rotated array.

Example:
→ Output: 1[4][5][6][1][2][3]

Insight:
👉 Compare middle with rightmost element

🧠 7️⃣ Square Root using Binary Search

Problem:
Find integer square root of a number.

Example:
√25 → 5

Insight:
👉 Use binary search on range 1 to n

🧠 8️⃣ Peak Element Problem

Problem:
Find an element greater than its neighbors.

Insight:
👉 If mid < next → go right
👉 Else → go left

⚡️ Common Pattern

Binary search is not just for searching. It is used when:
• Data is sorted
• You need optimal solution (log n)
• You can eliminate half of search space

⚠️ Common Mistakes

❌ Wrong mid calculation
❌ Infinite loops
❌ Not updating bounds correctly
❌ Ignoring edge cases

💰 SALARY NEGOTIATION #1 - The Script You Need

Most engineers leave $10K-$30K on the table because they accept the first offer out of fear the company will rescind it.

They almost never do. Here's a script that works:

When you get the offer:
"Thank you so much, I'm really excited about this. Could I have a couple of days to review everything?"

(Always ask for time. Never negotiate on the spot.)

When you come back to negotiate:
"I'm really excited about this role and the team. Based on my research and the scope of responsibilities we discussed, I was expecting something closer to $X. Is there flexibility on the base salary or the signing bonus?"

Key principles:
✅ Always express enthusiasm first - negotiation isn't confrontation
✅ Anchor with a specific number, not a vague "more"
✅ Ask about total comp flexibility (base, bonus, equity, sign-on) - not just base salary
✅ Never lie about competing offers, but you CAN say "I'm evaluating a few opportunities"

The worst that happens? They say no, and you're exactly where you started. The best case? Thousands of extra dollars a year, for one polite conversation.

Have you ever negotiated an offer? How did it go? 👇

📊 SQL SATURDAY #2 - JOINs Without the Confusion

Two tables this week:

customers                    orders
+----+---------+            +----+-------------+--------+
| id | name    |            | id | customer_id | amount |
+----+---------+            +----+-------------+--------+
| 1  | Alice   |            | 1  | 1           | 250    |
| 2  | Bob     |            | 2  | 1           | 100    |
| 3  | Charlie |            | 3  | 2           | 75     |
+----+---------+            +----+-------------+--------+

Notice Charlie has no orders.

INNER JOIN - only rows that match in both tables:

sql
SELECT c.name, o.amount
FROM customers c
INNER JOIN orders o ON c.id = o.customer_id;

Charlie won't appear - he has no matching order.

LEFT JOIN - all rows from the left table, matched or not:

sql
SELECT c.name, o.amount
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id;

Charlie appears with amount = NULL.

⚠️ Interview trap: "Find customers with zero orders."

sql
SELECT c.name
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.id IS NULL;

People often try WHERE o.amount = 0 here - wrong, that finds orders worth $0, not customers with no orders at all. Filtering on IS NULL after a LEFT JOIN is the pattern to remember.

Which JOIN type trips you up the most? RIGHT and FULL OUTER are coming in a few weeks 👀

🧠 EDUCATIONAL CS #2 - Why Hash Tables Are Basically Magic

You use hash tables constantly (Python dicts, JS objects, Java HashMaps) - but do you know why they're O(1)?

Here's the core idea:

1️⃣ You have a hash function that takes a key and turns it into a number (an index).
2️⃣ That index points directly to a slot ("bucket") in an array.
3️⃣ To look up a value, you hash the key again, jump straight to that slot - no searching required.

key "apple" → hash("apple") → index 7 → array[7] = value

That's why lookup, insert, and delete are all O(1) on average.

Why "on average" and not always? Because two different keys can hash to the same index - a collision. When that happens, most implementations chain multiple entries in the same bucket (a small linked list) or probe for the next open slot.

If your hash function is bad and everything collides into one bucket, your "O(1)" hash table quietly degrades into an O(n) linked list. This is exactly why interviewers sometimes ask: "what happens if all your keys hash to the same value?"

Now you know the answer. 😉

What's a bug you've hit because of hash collisions or bad hashing? 👇

💬 DISCUSSION - What's Your Interview Horror Story?

We've all got one. The question that made your brain completely blank. The moment you realized you'd been debugging the wrong function for 10 minutes. The interviewer who just... stared at you in silence.

Drop your worst interview moment below. No judgment - half the people reading this have a story just as bad (including me).

Bonus points if it has a happy ending. 😄

To effectively learn SQL for a Data Analyst role, follow these steps:

1. Start with a basic course:
Begin by taking a basic course on YouTube to familiarize yourself with SQL syntax and terminologies. I recommend the "Learn Complete SQL" playlist from the "techTFQ" YouTube channel.

2. Practice syntax and commands:
As you learn new terminologies from the course, practice their syntax on the "w3schools" website. This site provides clear examples of SQL syntax, commands, and functions.

3. Solve practice questions:
After completing the initial steps, start solving easy-level SQL practice questions on platforms like "Hackerrank," "Leetcode," "Datalemur," and "Stratascratch." If you get stuck, use the discussion forums on these platforms or ask ChatGPT for help. You can paste the problem into ChatGPT and use a prompt like:
- "Explain the step-by-step solution to the above problem as I am new to SQL, also explain the solution as per the order of execution of SQL."

4. Gradually increase difficulty:
Gradually move on to more difficult practice questions. If you encounter new SQL concepts, watch YouTube videos on those topics or ask ChatGPT for explanations.

5. Consistent practice:
The most crucial aspect of learning SQL is consistent practice. Regular practice will help you build and solidify your skills.

By following these steps and maintaining regular practice, you'll be well on your way to mastering SQL for a Data Analyst role.

🏗️ SYSTEM DESIGN MONDAY #2 - Caching 101

Last week: client → server → database. Now let's fix the bottleneck.

Say your database gets hit with the same query a thousand times a second - like fetching a popular product page. Hitting disk every time is wasteful.

Enter the cache: a fast, in-memory layer that sits between your server and database.

[Client] → [Server] → [Cache] → [Database]
                          ↑
                   (checked first)

Flow:
1️⃣ Server checks cache first
2️⃣ Cache hit → return immediately (fast!)
3️⃣ Cache miss → query database, store result in cache, return it

Popular tools: Redis, Memcached.

Two concepts you MUST be able to explain in an interview:

🔹 Cache eviction (LRU) - cache has limited memory, so when it's full, Least Recently Used items get kicked out to make room for new ones.

🔹 Cache invalidation - the hardest part. If the underlying data changes, how does the cache know to update? (Famous quote: "There are only two hard things in computer science: cache invalidation and naming things.")

Common strategies: TTL (time-to-live expiry), write-through (update cache and DB together), or explicit invalidation on writes.

Next System Design Monday: what happens when ONE server can't handle the traffic anymore - load balancing.

What would you cache first in a system like Instagram? 👇

🐛 SPOT THE BUG #2
Language: Java

java
public class Counter {
    private int count;

    public void increment() {
        count++;
    }

    public int getCount() {
        return count;
    }
}

// Used across 10 threads simultaneously calling increment()

What breaks under concurrent access? 👇

.
.
.

The bug: count++ is NOT atomic. It's actually three operations: read, increment, write. Two threads can read the same value, both increment it, and both write back the same result - losing an update. With 10 threads hammering this, your final count will almost always be less than expected.

Fixed version:

java
public class Counter {
    private AtomicInteger count = new AtomicInteger(0);

    public void increment() {
        count.incrementAndGet();
    }

    public int getCount() {
        return count.get();
    }
}

Alternative fix: mark increment() as synchronized, though that's slower under high contention than AtomicInteger.

This is one of the most common concurrency bugs in real production systems, not just interviews. Ever debugged something like this in the wild? 👇

🎯 CODING CHALLENGE #3 - Reverse a Linked List
Difficulty: Easy-Medium | Asked at: Amazon, Apple, Adobe

Reverse a singly linked list, iteratively.

Input:  1 → 2 → 3 → 4 → None
Output: 4 → 3 → 2 → 1 → None

💡 Hint: You need to track three pointers as you walk the list: the previous node, the current node, and the next node - because once you flip a pointer, you lose the way forward unless you saved it first.

Solution:

python
class ListNode:
    def __init__(self, val=0, next=None):
        self.val = val
        self.next = next

def reverse_list(head):
    prev = None
    curr = head
    while curr:
        next_node = curr.next
        curr.next = prev
        prev = curr
        curr = next_node
    return prev

Complexity: O(n) time, O(1) space - this is the detail that separates a strong answer from an average one. A recursive solution is O(n) time but O(n) space due to the call stack - know both, and be ready to explain the tradeoff.

Common mistake: Forgetting to save curr.next before overwriting it, which permanently disconnects the rest of the list.

Iterative or recursive - which do you reach for first, and why? 👇

🗣️ BEHAVIORAL INTERVIEW #2 - "Tell Me About a Time You Failed"

This question isn't a trap to expose your weaknesses. It's testing whether you're self-aware and whether you actually learn from mistakes.

❌ What kills this answer:
- "I don't really have failures, I'm pretty thorough" (nobody believes this, and it reads as low self-awareness)
- Choosing a failure that was actually someone else's fault
- Never getting to what you learned

✅ The STAR-based structure that works:

Situation: Brief context.
Task: What you were responsible for.
Action: What YOU did (own it, don't blame the team).
Result: What happened, AND what you changed afterward.

Example:
"I once shipped a database migration without adequately testing it against production-scale data. It caused a 20-minute outage during peak hours. I immediately rolled it back, then led the postmortem. The real failure wasn't the bug - it was that we didn't have a staging environment that mirrored production data volume. I pushed for building one, and we haven't had a similar incident since."

Notice: real mistake, real ownership, real systemic fix. That's what "failure" questions are actually testing.

What's a failure you'd feel comfortable sharing in an interview? (Only share what you're comfortable with, of course) 👇

🕵️ RECRUITER SECRETS #2 - The "Culture Fit" Question Nobody Explains

When a recruiter says "we're assessing culture fit," most candidates hear "do they like me personally." That's not quite it.

What they're actually assessing:
✅ Do you ask questions, or do you passively wait to be told what to do?
✅ How do you talk about former teammates and managers? (Bad-mouthing a previous employer is a massive red flag - even if they were genuinely bad)
✅ Do you show curiosity about the company's actual problems, or just want "a job"?
✅ Can you disagree with someone respectfully, or do you either fold immediately or get defensive?

Here's the secret: culture fit interviews are often scored on specific behavioral traits the company has defined internally (ownership, collaboration, communication) - not vibes. Prepare a story for each of these, not just "tell me about yourself."

One tip that works surprisingly well: ask your interviewer "what does someone who's thriving on this team actually do day-to-day?" It shows genuine interest and gives you real signal about whether you'd enjoy the role.

What's the strangest "culture fit" question you've ever been asked? 👇

⚠️ COMMON INTERVIEW MISTAKE #2 - Going Silent While Coding

Interviewers aren't just grading your final code. They're grading how you think.

If you go completely silent for 5 minutes while typing, the interviewer has zero signal about your thought process - and silence under pressure often reads as "stuck" even when you're not.

✅ What to do instead - narrate as you go:

"I'm going to start by handling the edge case where the array is empty."
"I'm using a dictionary here so I get O(1) lookups instead of scanning the array again."
"Let me trace through this with the example to make sure it's correct before I move on."

This isn't about talking nonstop - brief, purposeful narration. It turns a silent black box into a conversation, and it gives the interviewer chances to nudge you in the right direction if you're drifting off track (which they usually WANT to do - most interviewers are rooting for you).

Do you naturally talk while coding, or does it feel forced? Genuinely curious 👇

🎯 CODING CHALLENGE #4 - Merge Intervals
Difficulty: Medium | Asked at: Meta, Google, LinkedIn

Given a list of intervals, merge all overlapping ones.

Input:  [[1,3],[2,6],[8,10],[15,18]]
Output: [[1,6],[8,10],[15,18]]

💡 Hint: Overlaps are much easier to spot once the intervals are sorted by start time.

Solution:

python
def merge(intervals):
    intervals.sort(key=lambda x: x[0])
    merged = [intervals[0]]

    for start, end in intervals[1:]:
        last_end = merged[-1][1]
        if start <= last_end:
            merged[-1][1] = max(last_end, end)
        else:
            merged.append([start, end])

    return merged

Complexity: O(n log n) - dominated by the sort. The merge pass itself is O(n).

Common mistake: Forgetting max(last_end, end) and just assuming end is always bigger. Consider [[1,10],[2,3]] - the second interval is fully contained in the first, so if you don't take the max, you'd shrink your merged interval incorrectly.

This pattern (sort, then single pass comparing to the last processed item) shows up in a TON of interval problems. Recognize it and you'll fly through similar questions.

What's your go-to strategy when you see "intervals" in a problem? 👇

📊 SQL SATURDAY #3 - GROUP BY and Aggregates

orders
+----+-------------+--------+------------+
| id | customer_id | amount | order_date |
+----+-------------+--------+------------+
| 1  | 1           | 250    | 2024-01-05 |
| 2  | 1           | 100    | 2024-02-14 |
| 3  | 2           | 75     | 2024-01-20 |
| 4  | 3           | 500    | 2024-03-01 |
| 5  | 2           | 200    | 2024-03-15 |

Question: Find the total spend per customer, only for customers who spent more than $150 total.

sql
SELECT customer_id, SUM(amount) AS total_spent
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 150;

⚠️ The classic trap: using WHERE instead of HAVING here.

sql
-- WRONG:
SELECT customer_id, SUM(amount) AS total_spent
FROM orders
WHERE SUM(amount) > 150   -- ❌ ERROR
GROUP BY customer_id;

WHERE filters rows before grouping happens - it has no idea what SUM(amount) even means yet, since that's calculated during grouping. HAVING filters after the aggregation, which is exactly what you need for conditions on aggregate functions.

Simple rule to remember: WHERE filters rows, HAVING filters groups.

What SQL clause order still confuses you sometimes? (No shame - even senior engineers mix this up under pressure) 👇