Coding Interview Preparation

⚠️ COMMON INTERVIEW MISTAKE #4 - Bad-Mouthing a Previous Employer This comes up constantly in "why are you leaving your current role" - and it's one of the fastest ways to quietly lose an interviewer's trust, even if every word you say is true. Here's why: the interviewer isn't just evaluating your former company. They're predicting how you'll talk about THEIR company someday, if things go wrong. ❌ "My manager was incompetent and the whole team was toxic, honestly I couldn't wait to leave." ✅ "I've grown a lot in my current role, but I'm looking for a team with more opportunities to work on [specific thing] - that's actually what drew me to this opening." Notice the good version is still honest - you ARE leaving because something's missing - it's just framed around what you're moving toward, not what you're running from. If something was genuinely toxic or unethical, it's fine to be honest at a high level ("there were some communication issues on my team") - just don't turn it into a 5-minute complaint session. One sentence, then pivot forward. Have you ever had to bite your tongue about a former job in an interview? 😅

💰 SALARY NEGOTIATION #4 - Negotiating Equity, Not Just Salary Especially at startups, equity can be worth more than the base salary difference - but most candidates don't know what questions to ask. ✅ Questions to ask before accepting any equity offer: 1. "How many total shares are outstanding, fully diluted?" (Your number of shares means nothing without this - 10,000 shares out of 10 million is very different from 10,000 out of 100 million) 2. "What's the strike price, and what's the most recent 409A valuation?" (This tells you the real cost to exercise, and a rough sense of current value) 3. "What's the vesting schedule?" (Standard is 4 years with a 1-year cliff - meaning you get nothing if you leave before year one) 4. "Is there a post-termination exercise window longer than 90 days?" (Standard 90-day windows force ex-employees to either pay to exercise immediately or lose their vested equity - some companies now offer extended windows, which is a real, valuable perk to ask about) If a recruiter can't answer these clearly, that's itself useful information about the company's transparency. Bottom line: never treat "$X in equity" as a clean number to compare across offers without understanding the mechanics behind it. Has anyone here actually had equity turn into real money? Tell us about it 👀

🧠 EDUCATIONAL CS #4 - Trees, Graphs, and the Difference That Matters A tree is just a graph with two extra rules: no cycles, and exactly one path between any two nodes.

Tree:                Graph (with cycle):
    1                    1 --- 2
   / \                   |     |
  2   3                  4 --- 3

Why does this distinction matter in interviews? 🔹 In a tree, you never need to track visited nodes during traversal - since there are no cycles, you literally cannot revisit a node. 🔹 In a graph, you MUST track visited nodes, or you risk infinite loops.

python
# Graph DFS - visited set is NOT optional
def dfs(graph, node, visited=None):
    if visited is None:
        visited = set()
    if node in visited:
        return
    visited.add(node)
    for neighbor in graph[node]:
        dfs(graph, neighbor, visited)

Forgetting the visited set is one of the most common graph-traversal bugs in interviews - code that works perfectly on the example tree-like input, then infinite-loops the moment the interviewer adds one cycle to the test case (which they often do specifically to check this). Also worth knowing cold: BFS finds the SHORTEST path in an unweighted graph; DFS does not guarantee that. If a problem says "shortest," that's your signal to reach for BFS. Quick one: is a linked list technically a tree, a graph, both, or neither? 👇

🏗️ SYSTEM DESIGN MONDAY #5 - Let's Design TinyURL Time for our first full end-to-end design. Requirements: ✅ Given a long URL, generate a short one ✅ Given a short URL, redirect to the original ✅ High read traffic (redirects happen constantly), lower write traffic (new URLs created less often) Step 1 - the core challenge: how do we generate a short, unique code for each URL? Option A: Hash the URL (like MD5) and take the first 7 characters. Risk: collisions, requires checking uniqueness. Option B (better): use an auto-incrementing ID from the database, then convert it to base62 (a-z, A-Z, 0-9). ID 125 becomes something like "cb" - dramatically shorter, always unique by construction. Step 2 - the architecture:

[Client] → [Load Balancer] → [App Servers] → [Cache] → [Database]
                                                 (hot URLs cached
                                                  for fast redirects)

Step 3 - the schema:

urls
+--------+--------------------------+---------------------+
| id     | short_code | long_url    | created_at          |
+--------+------------+-------------+---------------------+
| 125    | cb         | example.com | 2024-01-01 10:00:00 |

Step 4 - the follow-ups interviewers actually ask: 🔹 "What if two servers generate the same ID at the same time?" → Use a centralized ID generator service, or database auto-increment, or a distributed ID scheme like Twitter's Snowflake. 🔹 "How do you handle a URL that goes viral overnight?" → This is exactly why we cache hot URLs - the cache absorbs the read spike so the database doesn't get hammered. 🔹 "Should short codes expire?" → Product decision, not purely technical - worth explicitly asking your interviewer this instead of assuming. The key skill being tested isn't "do you know TinyURL" - it's whether you can reason from requirements to architecture out loud, and handle the follow-up curveballs. If you were designing this, would you go with hash-based or counter-based short codes? 👇

🔍 GUESS THE OUTPUT #5 - full breakdown

python
print(bool("False"))
print(bool(""))
print(bool([False]))
print(bool(0.0))

Answers:

True
False
True
False

Breakdown: 1️⃣ "False" is a non-empty string - any non-empty string is truthy, REGARDLESS of its content. The string literally saying "False" doesn't matter. 2️⃣ "" is an empty string - falsy. 3️⃣ [False] is a list containing one element - and non-empty lists are always truthy, regardless of what's inside them. 4️⃣ 0.0 is falsy, just like 0. This one trips up even experienced developers because #1 and #3 look like they "should" be False at a glance, but Python's truthiness rules only care about emptiness/zero-ness of the container itself, never its contents. Which one did you get wrong, if any? Be honest 😄

📢 Advertising in this channel You can place an ad via Telega․io. It takes just a few minutes. Formats and current rates: View details

🔍 GUESS THE OUTPUT #5 Language: Python

python
print(bool("False"))
print(bool(""))
print(bool([False]))
print(bool(0.0))

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

📊 SQL SATURDAY #5 - Window Functions (The Interview Differentiator) If GROUP BY collapses rows, window functions let you calculate aggregates WITHOUT collapsing them - you keep every row, plus a calculated value alongside it. This is one of the clearest signals of SQL seniority in interviews.

sales
+----+------------+--------+
| id | department | amount |
+----+------------+--------+
| 1  | Eng        | 100    |
| 2  | Eng        | 200    |
| 3  | Sales      | 150    |
| 4  | Sales      | 300    |

Question: Show each sale alongside the total for its department, without collapsing rows.

sql
SELECT id, department, amount,
       SUM(amount) OVER (PARTITION BY department) AS dept_total
FROM sales;

+----+------------+--------+------------+
| id | department | amount | dept_total |
+----+------------+--------+------------+
| 1  | Eng        | 100    | 300        |
| 2  | Eng        | 200    | 300        |
| 3  | Sales      | 150    | 450        |
| 4  | Sales      | 300    | 450        |

PARTITION BY is like GROUP BY, but it doesn't collapse the rows - every row keeps its own identity while gaining group-level context. Another classic interview favorite - ranking within groups:

sql
SELECT id, department, amount,
       RANK() OVER (PARTITION BY department ORDER BY amount DESC) AS dept_rank
FROM sales;

⚠️ Interview trap: RANK() vs DENSE_RANK() vs ROW_NUMBER() - know the difference cold: 🔹 ROW_NUMBER() - always unique, 1,2,3,4, even with ties 🔹 RANK() - ties share a rank, but the NEXT rank skips (1,1,3,4) 🔹 DENSE_RANK() - ties share a rank, next rank does NOT skip (1,1,2,3) Interviewers love asking you to explain this exact difference, then predict output on a tied dataset. Which of the three ranking functions do you use most in your actual job? 👇

📄 RESUME ROAST #4 > "2020-2023: Software Engineer > 2023-2024: Senior Software Engineer > 2024-Present: Software Engineer II" Spot the issue before I explain 👇 . . . The roast: This looks like a demotion, and recruiters WILL notice and wonder about it - even if "Software Engineer II" is actually a level ABOVE "Senior Software Engineer" at your specific company (title inflation and naming varies wildly between companies). The resume doesn't explain that, so it just reads as a step backward, and most recruiters won't take the time to ask - they'll just quietly deprioritize the resume. ✅ The fix: add a one-line clarifying note, or better, standardize your titles to reflect actual seniority level consistently: > "2024-Present: Software Engineer II (Senior-equivalent level at [Company]'s leveling structure)" Or simply pick the title that most clearly communicates your actual seniority to an outside reader, even if it's not your exact internal title - as long as it's honest and defensible if asked about in an interview. Never assume the reader knows your company's internal quirks. Assume zero context and write for a stranger. Anyone else dealt with a confusing title change like this? 👇

🎯 CODING CHALLENGE #7 - Kth Largest Element in an Array Difficulty: Medium | Asked at: Facebook, Amazon, Google

Input: nums = [3,2,1,5,6,4], k = 2
Output: 5

💡 Hint: Sorting works but is O(n log n). Can you do better with a heap that only ever holds k elements? Solution (min-heap approach):

python
import heapq

def find_kth_largest(nums, k):
    heap = nums[:k]
    heapq.heapify(heap)

    for num in nums[k:]:
        if num > heap[0]:
            heapq.heapreplace(heap, num)

    return heap[0]

Complexity: O(n log k) time, O(k) space - much better than sorting when k is small relative to n. Common mistake: Using a max-heap of the FULL array (heapifying all n elements, then popping k times) - this works, but it's a weaker answer. Building a min-heap of just size k and comparing incoming elements against the smallest kept element is the optimization interviewers are hoping to see. Alternative: Quickselect gets this down to average O(n) time, though worst case O(n²) - a great follow-up to mention if you want to show extra depth. Do you know Quickselect, or is the heap approach your default here? 👇

🕵️ RECRUITER SECRETS #4 - What Actually Happens After Your Interview Ever wondered what happens the moment you leave that Zoom call? Here's the real process at most mid-to-large companies: 1️⃣ Each interviewer independently writes feedback and a rating (usually a scale like "Strong Hire / Hire / No Hire / Strong No Hire") before discussing with anyone else - this is intentional, to avoid groupthink. 2️⃣ These are compiled into a packet for a hiring committee or debrief meeting - often people who never even met you. 3️⃣ One "no hire" from a single round can sometimes be overridden by strong signal elsewhere, but a "strong no hire" is very difficult to recover from, even with great other rounds. 4️⃣ The single biggest factor in close calls: whether interviewers can point to specific examples in their notes, not vague impressions. This is why articulating your thinking clearly matters so much - a vague "good vibes" interview generates a vague, easily-overruled recommendation. Here's the actionable part: at the end of every round, briefly summarize what you just demonstrated. "Just to recap, I approached this with a hash map for O(1) lookups, handled the edge cases we discussed, and we walked through the complexity together." This gives the interviewer an easy, concrete sentence to write down - literally doing their job for them. Did this change how you think about what happens after you leave the interview? 👇

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

💬 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 👇

🗣️ 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)? 👇

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

🏗️ 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? 👇

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

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