⚠️ 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) 👇

📄 RESUME ROAST #2

Real-style bullet incoming:

> "Familiar with Python, Java, C++, JavaScript, React, Angular, Vue, Node.js, Docker, Kubernetes, AWS, Azure, GCP, MongoDB, PostgreSQL, Redis, Kafka, GraphQL"

What's wrong here? 👇

.
.
.

The roast:
This is the "keyword salad" resume. It signals one of two things to an experienced hiring manager: either you're exaggerating your depth in most of these, or you genuinely have surface-level exposure to 20 tools and mastery of none.

Recruiters and hiring managers both find this to be a red flag, not a strength.

✅ Better approach: List 4-6 technologies you can genuinely go deep on in an interview, and organize by proficiency if you must list more:

> "Core: Python, PostgreSQL, AWS (EC2, S3, Lambda)
> Familiar: Docker, Kafka, GraphQL"

Anything on your resume, you should be able to talk about for 10 minutes without panicking. If you can't, it doesn't belong in your top skills section.

Be honest - is there something on your resume right now you'd struggle to explain in depth? 😅

🏗️ SYSTEM DESIGN MONDAY #3 - Load Balancing & Horizontal Scaling

One server is now overwhelmed. Two options: make it bigger (vertical scaling) or add more of them (horizontal scaling). Horizontal scaling is what most large systems actually do - there's a ceiling on how big one machine can get, but no real ceiling on how many machines you can add.

                     ┌─────────┐
              ┌─────▶│ Server 1│
              │      └─────────┘
[Client] → [Load Balancer] 
              │      ┌─────────┐
              ├─────▶│ Server 2│
              │      └─────────┘
              │      ┌─────────┐
              └─────▶│ Server 3│
                     └─────────┘

The load balancer sits in front of your servers and distributes incoming requests, usually via:
🔹 Round robin - requests go to servers in rotating order
🔹 Least connections - send to whichever server currently has the fewest active requests
🔹 IP hash - same client always routed to the same server (useful for session data)

Here's the important follow-up question interviewers ask: "if a user's session data is stored in Server 2's memory, what happens if the load balancer routes their next request to Server 3?"

That's the concept of statelessness - well-designed servers shouldn't hold session data locally at all. Instead, store session state in a shared cache (like Redis) or a database, so ANY server can handle ANY request. This is a foundational principle behind horizontally scalable systems.

Why do you think "statelessness" matters so much in distributed systems? 👇

💰 SALARY NEGOTIATION #2 - Handling "What's Your Current Salary?"

This question puts a lot of candidates on the spot - and in many US states, it's actually illegal for employers to ask. But it still comes up, especially in phone screens or in regions where it's legal.

The problem with answering directly: it anchors your new offer to your old salary, especially if you were underpaid before.

✅ A script that redirects gracefully:

"I'd rather focus on the value I can bring to this role and what's a fair market rate for it, rather than my previous compensation, which honestly reflected a different set of circumstances. Based on my research, I'm looking at a range of $X to $Y for this role - does that align with your budget?"

If they push:
"I understand you're trying to gauge fit - I'm confident that whatever we agree on will be fair market rate for the role and my experience level. What's the budgeted range for this position?"

Turning the question back on THEM to share the range first is a classic, effective negotiation tactic - whoever names a number first gives up information.

Have you ever been asked this? How did you handle it? 👇

🧠 EDUCATIONAL CS #3 - Recursion Without the Headache

Recursion clicks once you stop thinking about "the whole problem" and start thinking about these two things:

1️⃣ Base case - the simplest version of the problem you can answer directly, no further recursion needed.
2️⃣ Recursive case - how to break the problem into a smaller version of itself, plus some work.

python
def factorial(n):
    if n == 0:          # base case
        return 1
    return n * factorial(n - 1)   # recursive case

Here's the trick most people miss: you don't need to mentally trace the ENTIRE call stack to trust recursion works. You just need to trust that factorial(n-1) correctly returns (n-1)!, because you already proved the base case works, and each recursive call is just one step closer to it. This is called "trusting the recursion."

⚠️ Common failure mode: forgetting the base case, or having a recursive case that doesn't actually move toward it - both cause infinite recursion and a stack overflow.

Also worth knowing for interviews: every recursive solution can be rewritten iteratively (usually with an explicit stack), and interviewers sometimes ask you to do exactly that, to test whether you understand what recursion is doing under the hood rather than treating it as magic.

What's the recursion problem that finally made it click for you? 👇

🐛 SPOT THE BUG #3
Language: Python

python
def binary_search(arr, target):
    left, right = 0, len(arr)
    while left < right:
        mid = (left + right) // 2
        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            left = mid
        else:
            right = mid
    return -1

Subtle one. Spot it before scrolling 👇

.
.
.

The bug: Infinite loop risk. When arr[mid] < target, the code sets left = mid instead of left = mid + 1. If mid ends up equal to left again on the next iteration (which happens when the search space shrinks to 2 elements), the loop never makes progress.

Fixed version:

python
def binary_search(arr, target):
    left, right = 0, len(arr)
    while left < right:
        mid = (left + right) // 2
        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            left = mid + 1
        else:
            right = mid
    return -1

This is exactly why binary search is famously easy to get "almost right" but subtly wrong. Off-by-one errors here are so common that some engineers recommend writing out the invariant explicitly ("left is always a possible answer, right is always excluded") before coding it.

Do you write binary search from memory, or always double-check the boundaries? 👇

💰 SALARY NEGOTIATION #3 - Comparing Multiple Offers

Having multiple offers is the single strongest negotiation position you can be in - but a surprising number of people mishandle it by staying quiet about it.

✅ The script, once you have a competing offer:

"I wanted to be transparent with you - I've received another offer at $X with [notable perk, e.g., more equity / remote flexibility]. I'm genuinely more excited about this role because of [specific, real reason - team, mission, growth path]. Is there room to close the gap?"

Why this works:
✅ Transparency builds trust rather than looking like a bluff
✅ Naming a specific, genuine reason you prefer them makes it clear you're not just auctioning yourself off
✅ Companies would rather match a number than lose a candidate they already invested interview time in

⚠️ Never fabricate a competing offer. Recruiters talk to each other more than you'd think, especially in tight-knit industries, and getting caught destroys your credibility permanently.

If you don't have a competing offer, you can still negotiate - just anchor on market research (levels.fyi, Glassdoor, Blind) instead of a competing number.

Ever used a competing offer to negotiate? Did it work? 👇

🎯 CODING CHALLENGE #5 - Longest Substring Without Repeating Characters
Difficulty: Medium | Asked at: Amazon, Meta, Bloomberg

Input:  "abcabcbb"
Output: 3   ("abc")

Input:  "bbbbb"
Output: 1   ("b")

💡 Hint: This screams sliding window. Keep expanding a window to the right, and when you hit a repeat, shrink from the left until the repeat is gone.

Solution:

python
def length_of_longest_substring(s):
    seen = {}
    left = 0
    max_len = 0

    for right, char in enumerate(s):
        if char in seen and seen[char] >= left:
            left = seen[char] + 1
        seen[char] = right
        max_len = max(max_len, right - left + 1)

    return max_len

Complexity: O(n) time - each character is visited by right once, and left only ever moves forward. O(min(n, alphabet size)) space for the hash map.

Common mistake: Resetting left to seen[char] + 1 even when the previous occurrence of char is OUTSIDE the current window (i.e., seen[char] < left). Without the seen[char] >= left check, you can accidentally move left backwards, which breaks the algorithm.

Sliding window is one of the highest-ROI patterns to master - it solves a huge chunk of "substring" and "subarray" problems. Comfortable with it, or still building intuition? 👇

📄 RESUME ROAST #3

> "Team player with excellent communication skills, hard worker, fast learner, detail-oriented, passionate about technology."

Before I roast this - what's actually wrong with it? 👇

.
.
.

The roast:
Every single word here is an unverifiable adjective. "Team player" and "hard worker" mean nothing to a hiring manager because literally every resume claims them, and there's zero evidence attached.

This section is functionally invisible - recruiters' eyes skip right past it, and it takes up valuable space that could hold something specific.

✅ The fix: show, don't tell. Instead of claiming "excellent communication skills," demonstrate it:

> "Presented quarterly architecture reviews to both engineering and non-technical stakeholders, translating complex system tradeoffs into business impact."

That single sentence proves communication skills far more convincingly than the adjective ever could - and it does it without ever using the word "communication."

Go check your resume right now. Do you have any pure adjective-lists like this? Be honest 😅

📊 SQL SATURDAY #4 - Subqueries and CTEs

Time to clean up messy nested queries. Same orders table as before.

The old, hard-to-read way (nested subquery):

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

The cleaner way, using a CTE (Common Table Expression):

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

Same result, dramatically more readable - especially once you start chaining multiple CTEs together:

sql
WITH customer_totals AS (
    SELECT customer_id, SUM(amount) AS total_spent
    FROM orders
    GROUP BY customer_id
),
big_spenders AS (
    SELECT customer_id
    FROM customer_totals
    WHERE total_spent > 150
)
SELECT c.name
FROM customers c
JOIN big_spenders b ON c.id = b.customer_id;

💡 Why interviewers love CTE questions: they reveal whether you can decompose a complex problem into logical, named steps - the same skill you need for clean production SQL, not just passing a test.

⚠️ Performance note: CTEs aren't automatically materialized/cached in every database engine - in some (like older Postgres versions), a CTE could be re-run each time it's referenced. Worth knowing your specific database's behavior before assuming CTEs are always a free readability win.

Do you default to CTEs or subqueries in your day-to-day work? 👇

🕵️ RECRUITER SECRETS #3 - Why "We'll Get Back to You" Sometimes Means Nothing

Uncomfortable truth: sometimes a recruiter genuinely doesn't know when they'll get back to you, and "we'll follow up soon" is a real answer, not a brush-off - internal hiring processes are often slower and messier than candidates assume.

But here's what you SHOULD do instead of just waiting anxiously:

✅ Ask directly at the end of every interview: "What does the timeline look like from here, and who should I follow up with?" This isn't pushy - it's expected, and it makes you look organized.

✅ If you haven't heard back by the timeline they gave you, it's completely appropriate to send ONE polite follow-up: "Hi [Name], just checking in on the status of my application for [Role] - happy to provide anything else that's useful. Thanks!"

✅ If you have a competing offer with a deadline, tell your recruiter immediately. Companies move surprisingly fast when there's real time pressure - this is one of the few legitimate ways to speed up a slow process.

What you should NOT do: message the hiring manager on LinkedIn every 2 days, or email multiple people at the company hoping someone responds faster. It reads as impatience, not enthusiasm.

Have you ever had to nudge a stalled interview process? What did you say? 👇

⚠️ COMMON INTERVIEW MISTAKE #3 - Not Testing Your Own Code

You finish coding, say "I think that's it," and stop. The interviewer asks "are you sure this works?" - and you just... shrug.

This is one of the most avoidable point losses in the entire interview.

✅ What to do instead: Before declaring you're done, manually trace through your code with the example input(s) given. Actually walk through it line by line, tracking variable values as you go - out loud.

"Let's trace through with nums = [2,7,11,15], target = 9. i=0, num=2, complement=7, not in seen yet, so seen={2:0}. i=1, num=7, complement=2, IS in seen at index 0 - so we return [0,1]. That matches the expected output."

This catches real bugs before the interviewer has to point them out (which is a much worse look), and it demonstrates the exact skill you'd use before merging a real pull request.

Bonus: always test at least one edge case too (empty input, single element, all duplicates) - don't just re-test the example they gave you.

Do you naturally trace through your code, or does it feel like an extra step you skip under time pressure? 👇

hiring-without-whiteboards

A list of companies (or teams) that don't have a broken hiring process. The companies and teams listed here use interview techniques and questions that resemble day-to-day work.

Creator: poteto
Stars ⭐️: 51,200
Forked by: 3,903

Github Repo:
https://github.com/poteto/hiring-without-whiteboards

➖➖➖➖➖➖➖➖➖➖➖➖➖➖
Join @github_repositories_bds for more cool repositories. This channel belongs to @bigdataspecialist group

🏗️ SYSTEM DESIGN MONDAY #4 - Databases at Scale: Sharding & Replication

Your single database is now the bottleneck - too much data, too many writes, too many reads. Two techniques solve two different problems:

Replication (solves READ scaling):

                  ┌──▶ [Read Replica 1]
[Primary DB] ─────┼──▶ [Read Replica 2]
 (writes)         └──▶ [Read Replica 3]

All writes go to the primary. Reads get spread across replicas, which stay in sync via replication. Great when you have way more reads than writes (true for most apps).

⚠️ Watch for replication lag - replicas can be milliseconds to seconds behind the primary. If a user posts a comment and immediately refreshes, they might not see it yet if they're routed to a lagging replica. This is a classic system design follow-up question.

Sharding (solves WRITE scaling and storage limits):

[Shard 1: users A-H]   [Shard 2: users I-P]   [Shard 3: users Q-Z]

Split your data across multiple databases, each holding a subset. Now write load AND storage is distributed, not just reads.

The hard part interviewers dig into: how do you pick a shard key? Pick badly (like splitting alphabetically by name) and you get "hot shards" - massively uneven load, since names aren't evenly distributed. A better key is often something like user_id % number_of_shards, or a hash of the ID, to spread load evenly.

The other hard part: cross-shard queries (like "find all users who did X across every shard") become expensive, since you often need to query every shard and merge results.

If you were sharding a system like Instagram by user_id, what's one query that would suddenly become painful? 👇

🎯 CODING CHALLENGE #6 - Binary Tree Level Order Traversal
Difficulty: Medium | Asked at: Amazon, Microsoft, LinkedIn

Given a binary tree, return its values level by level (BFS).

        3
       / \
      9   20
         /  \
        15   7

Output: [[3], [9, 20], [15, 7]]

💡 Hint: BFS naturally processes a tree level by level using a queue. The trick is tracking how many nodes belong to the CURRENT level before you start adding next-level nodes to the same queue.

Solution:

python
from collections import deque

def level_order(root):
    if not root:
        return []

    result = []
    queue = deque([root])

    while queue:
        level_size = len(queue)
        current_level = []

        for _ in range(level_size):
            node = queue.popleft()
            current_level.append(node.val)
            if node.left:
                queue.append(node.left)
            if node.right:
                queue.append(node.right)

        result.append(current_level)

    return result

Complexity: O(n) time and space - every node is visited and queued exactly once.

Common mistake: Forgetting to snapshot level_size = len(queue) BEFORE the inner loop starts. If you check len(queue) inside the loop, it changes as you enqueue children, and your levels get mixed together.

BFS with a queue vs. DFS with recursion - do you know when to reach for each? That's often the actual follow-up question here 👇

🗣️ BEHAVIORAL INTERVIEW #3 - "Tell Me About a Conflict With a Coworker"

This one tests emotional maturity more than anything technical.

❌ Instant red flags:
- Making the other person sound irrational or incompetent
- A story where you were 100% right and they were 100% wrong (real conflicts are rarely that clean)
- No resolution - just "it eventually blew over"

✅ What works: pick a genuine disagreement about approach (not a personality clash), show you understood their perspective, and show how you reached resolution through communication, not just "waiting it out."

Example:
"A teammate and I disagreed on whether to refactor a legacy module before adding a new feature, or ship the feature first and refactor later. I initially pushed hard for refactoring first because I was worried about tech debt. Instead of just repeating my position, I asked him to walk me through his reasoning, and it turned out he had context I didn't - a hard deadline from a client commitment I wasn't aware of. We agreed on a middle path: ship the feature with a couple of safety tests around the risky area, and scheduled the refactor for the following sprint. It taught me to ask 'what am I missing?' before digging into a position."

Notice: real disagreement, real listening, real compromise, real lesson. That's the formula.

What's a work disagreement you'd feel comfortable sharing (with names/details changed, of course)? 👇

💬 POLL / DISCUSSION - Which Interview Round Scares You Most?

React with the emoji that matches your answer:

1️⃣ Coding round
2️⃣ System design round
3️⃣ Behavioral round
4️⃣ Take-home assignment
5️⃣ "Culture fit" round with a random exec

Comment WHY below - the reasons are usually more interesting than the answer itself 👇

🐛 SPOT THE BUG #4
Language: JavaScript (React)

javascript
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser(userId).then(data => setUser(data));
  });

  return <div>{user?.name}</div>;
}

What's the bug? 👇

.
.
.

The bug: Missing dependency array in useEffect. Without [userId] (or even []), this effect runs after EVERY render - and since setUser triggers a re-render, and that re-render triggers the effect again, you get either an infinite fetch loop or, at minimum, wildly wasteful re-fetching.

Fixed version:

javascript
useEffect(() => {
  fetchUser(userId).then(data => setUser(data));
}, [userId]);   // only re-run when userId changes

⚠️ Bonus bug hiding here too: if userId changes quickly (user navigates between profiles fast), an OLDER fetch can resolve AFTER a newer one, overwriting fresh data with stale data ("race condition"). The fix is usually a cleanup function that ignores outdated responses:

javascript
useEffect(() => {
  let ignore = false;
  fetchUser(userId).then(data => {
    if (!ignore) setUser(data);
  });
  return () => { ignore = true; };
}, [userId]);

React hooks bugs are EXTREMELY common in frontend interviews right now. Have you been bitten by a missing dependency array before? 👇