Interview questions & answers for every role

Key points

• ✓ Read-heavy system: optimize the redirect path above all.
• ✓ Generate a short, unique key with base-62 over a global ID (or a hash + collision check).
• ✓ Store short_key → long_url in a fast key-value store; cache hot keys.
• ✓ Redirect with 301 (permanent, cacheable) or 302 (if you need click analytics).

High-level design

Request flow

1. Create: API gets a unique id from the ID service, base-62 encodes it to a short key, stores key → url, returns the short link.
2. Redirect: look up the key in cache; on a miss read the DB and populate the cache; return a redirect.
3. Analytics: push the click event to a queue so counting never slows the redirect.

Deep dives & trade-offs

• ✓ Scale reads with cache + read replicas; the store is a natural key-value partition.
• ✓ Custom aliases & collisions: reserve/verify on write; hashing needs a collision check, counters don't.
• ✓ Capacity: ~62^7 ≈ 3.5 trillion 7-char keys — plenty. Add TTL/expiry if links should die.

Key points

• ✓ The core decision is fan-out on write vs fan-out on read.
• ✓ Precomputing timelines makes reads fast but writes expensive for high-follower accounts (the "celebrity problem").
• ✓ Most large systems use a hybrid: push for normal users, pull for celebrities.

Two strategies

How to answer

1. State the read:write ratio and latency goal, then justify a hybrid model.
2. Push new posts into followers' cached timelines; for celebrities, merge their posts at read time.
3. Add a ranking service (recency + engagement), cursor pagination, and a cache (Redis) for timelines.
4. Discuss consistency (eventually consistent feeds are fine) and back-pressure on the fan-out workers.

Key points

• ✓ Pick an algorithm: token bucket (allows bursts), sliding-window (more precise), or fixed window (simplest, edge bursts).
• ✓ Key the limit by user / IP / API key; store counters in a shared Redis so it works across servers.
• ✓ Enforce at the API gateway; return 429 Too Many Requests with a Retry-After header.

Approach

1. Token bucket: each key has a bucket that refills at r tokens/sec up to capacity c; a request consumes one token, else it's rejected.
2. Make it atomic in Redis (INCR + EXPIRE, or a small Lua script) to avoid race conditions.
3. Return limit headers so clients can back off gracefully; add per-tier limits.

The exchange

Step by step

1. ClientHello: the client lists supported TLS versions/ciphers and a random value.
2. ServerHello + Certificate: the server picks a cipher and sends its certificate (containing its public key) plus key-exchange parameters.
3. Authenticate: the client verifies the certificate chain up to a trusted CA.
4. Key agreement: both sides derive the same symmetric session key (e.g., via ECDHE — gives forward secrecy).
5. Finished: they confirm, then all data is encrypted with fast symmetric crypto.

Good to mention

• ✓ Asymmetric crypto sets up the key; symmetric crypto does the bulk work (it's faster).
• ✓ TLS 1.3 cuts it to one round trip (and 0-RTT resumption).

The idea

• ✓ You can't have all three of Consistency, Availability, and Partition tolerance at once.
• ✓ Networks partition, so P is a given — the real choice is C vs A during a partition.
• ✓ CP: reject/timeout to stay consistent (ZooKeeper, HBase). AP: stay up, allow stale reads (Cassandra, DynamoDB).
• ✓ Modern stores expose tunable consistency, so it's a spectrum, not a binary.

The journey

1. DNS: resolve the domain to an IP (browser → OS → resolver, with caching along the way).
2. TCP: open a connection (3-way handshake); for HTTPS, do the TLS handshake.
3. HTTP request: send GET with headers/cookies — often to a CDN or load balancer first.
4. Response: the server returns HTML (status, caching headers, compression).
5. Render: parse HTML → DOM, CSS → CSSOM, run JS, fetch sub-resources, paint the page.

Nice add-ons

• ✓ Mention caches at every layer (DNS, browser, CDN) and keep-alive/HTTP-2 multiplexing.
• ✓ Note render-blocking CSS/JS and how the critical path affects perceived speed.

Approach (iterative)

1. Keep prev = null and curr = head.
2. Each step: remember next = curr.next, set curr.next = prev, then advance prev = curr, curr = next.
3. When curr is null, prev is the new head.

Complexity

• ✓ Time O(n), space O(1). The recursive version is O(n) time but O(n) stack space.

Approach

1. Pair a hash map (key → node) with a doubly linked list ordered most-recently-used → least.
2. get(key): if present, move its node to the front and return the value.
3. put(key, val): insert/update at the front; if over capacity, remove the tail (LRU) and its map entry.

Complexity

• ✓ Both operations are O(1). The doubly linked list gives O(1) removal from the middle.

Approach

1. Walk the array once, keeping a hash map of value → index.
2. For each x, check if target - x is already in the map — if so, return the two indices.
3. Otherwise store x and continue.

Complexity

• ✓ Time O(n), space O(n) — beats the O(n²) brute-force double loop.
• ✓ Clarify: is the array sorted (two-pointer works), and can an element be reused?

Structure it with STAR

1. Situation: one specific disagreement (approach, priorities, ownership).
2. Task: what you were responsible for.
3. Action: you listened first, found the shared goal, brought data, and communicated respectfully.
4. Result: the resolution, the outcome, and what you learned.

What interviewers look for

• ✓ Collaboration and empathy — you disagree with ideas, not people.
• ✓ Focus on outcomes over ego; a concrete, positive result.
• ✓ Avoid badmouthing; show what you changed.

How to answer

• ✓ Pick a real, meaningful failure you genuinely owned (not a humble-brag).
• ✓ Set brief context, state your role honestly, and name what went wrong.
• ✓ Spend most of the answer on what you changed and the measurable improvement after.
• ✓ Land on accountability and growth — no blaming teammates or circumstances.

Tie three things together

1. Something specific about the company/product you admire (reference recent work or values).
2. How the role fits your strengths and where you want to grow.
3. The impact you want to have there.

• ✓ Be concrete — avoid generic praise anyone could say.
• ✓ Show you did your homework on the team and mission.

The flow

Step by step

1. Project unlevered FCF for ~5 years: EBIT×(1−tax) + D&A − capex − Δ working capital.
2. Discount each year to today at WACC (blended cost of debt & equity).
3. Terminal value: Gordon growth FCF×(1+g)/(WACC−g) with g ≈ 2–3%, or an exit EBITDA multiple — then discount it back.
4. Enterprise value = sum of all PVs. Subtract net debt → equity value; divide by shares → value per share.

What they're testing

• ✓ Do you know FCF is unlevered and matched to WACC?
• ✓ Can you sanity-check TV (often 60–80% of value) and run sensitivities on WACC/g?

The links

In one breath

• ✓ Net income flows to the top of the cash-flow statement and into retained earnings (equity) on the balance sheet.
• ✓ The cash-flow statement (operating / investing / financing) turns accrual profit into the change in cash; ending cash lands on the balance sheet.
• ✓ Non-cash items (D&A) and working-capital changes are the bridge. The balance sheet must always balance.

The mechanics

1. Entry: a sponsor buys the company at an EBITDA multiple, funded mostly by debt plus a slice of equity (build a sources & uses table).
2. Operate: project cash flows; use free cash flow to pay down debt over ~5 years.
3. Exit: assume an exit EBITDA multiple → exit enterprise value; subtract remaining debt → exit equity value.
4. Returns: compare exit equity to the initial equity → IRR and MOIC.

Where returns come from

• ✓ Debt paydown (leverage + FCF), EBITDA growth, and multiple expansion.
• ✓ Good LBO targets: stable cash flows, low capex, strong margins, room to add leverage.

A clean structure

1. Recommendation first: "I'd go long/short X" with your price target and time horizon.
2. Thesis (2–3 points): why the market is mispricing it — growth, margins, or a misunderstood segment.
3. Catalyst: what makes it re-rate (earnings, product, regulation) and when.
4. Valuation: the multiple/DCF that gets you to the target vs. where it trades now.
5. Risks & what would change your mind.

• ✓ Have a variant view — say what you believe that consensus doesn't.
• ✓ Know 2–3 numbers cold (revenue growth, margins, multiple).

Break it into a profit tree

How to solve it

1. Clarify the goal, timeframe, and what "profit" means; ask for context (product, market).
2. Isolate revenue vs cost: is it falling price, volume/mix, or rising fixed/variable cost?
3. Benchmark the market — is it company-specific or an industry-wide trend?
4. Quantify the biggest driver, then recommend targeted actions and next steps.

• ✓ Keep the tree MECE (no overlaps, no gaps) and lead with a hypothesis.
• ✓ Think out loud and check in with the interviewer as you branch.

Top-down estimate

How to answer

1. State assumptions out loud: population → cars → miles/year → tank size → fill-ups/year.
2. Estimate what one station can serve: pumps × fills/day × 365 = annual throughput.
3. Divide total fill-ups by per-station throughput; round to a clean ~110–150k.
4. Sanity-check against a known anchor and note what would move the number.

• ✓ They grade structure and reasonable assumptions, not the exact figure.

Run the CIRCLES flow

Steps

1. Clarify the goal (engagement? growth? revenue?) and constraints.
2. Pick a user segment and list their real pain points.
3. Prioritize the biggest one by impact × reach vs effort.
4. Brainstorm 2–3 solutions, weigh trade-offs, pick one.
5. Define a success metric and how you'd validate it.

• ✓ Anchor on a user problem and the goal — don't jump straight to features.

Walk the funnel

Diagnostic flow

1. Real or artifact? Check logging/tracking bugs, a recent release, or seasonality first.
2. Segment the drop: platform, geography, new vs returning, channel — localize it.
3. Funnel: find which step (acquisition → activation → engagement → retention) is leaking.
4. Hypothesize & validate with data before proposing a fix.

• ✓ Say the magic first move out loud: "Is this a real drop or a measurement issue?"

Attack the AARRR funnel

Approach

1. Measure each stage and attack the weakest step first (biggest lift).
2. For signups specifically: sharpen acquisition (channels, message-market fit, CAC) and activation (cut friction).
3. Run controlled experiments; prioritize by expected lift × reach vs effort.
4. Watch retention so you're not filling a leaky bucket.

Steps

1. Hypothesis & metric: pick one primary success metric (plus guardrails) and the minimum effect worth detecting.
2. Randomize users into control/treatment; make sure assignment is stable and unbiased.
3. Sample size / duration: compute power (α, β, baseline, MDE) so you can actually detect the lift; run at least a full weekly cycle.
4. Analyze: compare with a significance test; check p-value/confidence interval and guardrails.
5. Decide: ship, iterate, or kill — and watch for novelty effects.

• ✓ Beware peeking (stopping early), multiple comparisons, and network/interference effects.

The trade-off

In words

• ✓ Overfitting: the model memorizes training noise — great train accuracy, poor test accuracy (high variance).
• ✓ Underfitting: too simple to capture the signal (high bias).
• ✓ The goal is the sweet spot that minimizes total generalization error.

How to fix overfitting

• ✓ More/better data, regularization (L1/L2, dropout), simpler models, early stopping, and cross-validation.

Four buckets, in this order

How to solve it

1. Repeat back and clarify the objective — is this a revenue target, a strategic hedge, or a defence against a competitor? The answer changes the bar.
2. Is the market attractive? Size it, get its growth rate, and check profit pools — a big market with no margin is a trap.
3. Can we win in it? Competitors, barriers, and specifically our right to win: brand, cost position, channel, or IP we already own.
4. Do the economics work? Incremental revenue at a realistic share, minus entry cost — then payback period and downside case.
5. Recommend and pick a mode: organic build, acquisition, or JV/partnership, with the trade-off in one line each.

• ✓ Answer attractive and can-we-win separately — "yes, but not by ourselves" is a real and often correct answer.
• ✓ Close top-down: recommendation first, then the two or three reasons, then risks and the next step.

What the PEI actually grades

McKinsey's Personal Experience Interview scores three dimensions — personal impact (influencing people who don't report to you), entrepreneurial drive (going beyond the brief), and inclusive leadership. BCG and Bain ask the same substance under different names. One story, told in depth, beats three told shallowly.

How to answer

1. Set a stake: who disagreed, what they stood to lose, and why it mattered that they came along.
2. Name their objection in their words — this is the single strongest signal that you actually listened rather than steamrollered.
3. Show the specific moves: the one-on-one before the meeting, the data you went and got, the concession you made.
4. Quantify the outcome and say what you'd do differently — reflection is scored, not decoration.

• ✓ Expect relentless follow-ups: "what exactly did you say?", "how did they react?", "what was the hardest moment?" Depth is the test.
• ✓ Use "I", not "we" — they are hiring you, not your team.

The shortcut, then the model

How to answer

1. All-cash shortcut: compare the acquirer's after-tax cost of debt to the target's earnings yield (net income ÷ purchase price). Cheaper funding than the earnings it buys → accretive.
2. All-stock shortcut: the higher-P/E company buying the lower-P/E company is accretive; the reverse is dilutive. Say it as a yield comparison, not a memorised rule.
3. Then build it: combined net income = A + B + after-tax synergies − after-tax interest on new debt − forgone interest on cash used.
4. New share count: A's shares + any shares issued at A's price. Divide, compare to standalone EPS, and state accretion as a percentage.

• ✓ Accretive is not the same as value-creating — a deal can add EPS and still destroy value if you overpaid. Say so; it's what separates a strong answer.
• ✓ Don't forget forgone interest on cash spent, and amortisation of any written-up intangibles.

Match the numerator to the denominator

Every multiple has one rule behind it: an enterprise value must sit on top of a pre-debt metric, and an equity value on top of a post-debt one. EBITDA and EBIT are paid to everyone who funded the business, so they pair with EV. Net income is what's left for shareholders alone, so it pairs with price.

Which one, when

• ✓ EV/EBITDA — comparing companies with different leverage, or a target you're about to re-leverage. It's capital-structure neutral, which is exactly why LBO and M&A work lives here.
• ✓ EV/EBIT — when depreciation differs a lot across the comp set, because EBIT respects the fact that capital intensity is a real cost.
• ✓ P/E — mature, similarly-levered businesses, and financials, where debt is raw material rather than financing.
• ✓ EV/Revenue — pre-profit companies, where any earnings multiple is meaningless or negative.

What they're testing

• ✓ That you know EBITDA is not cash flow: it ignores capex, working capital and taxes, which is precisely how a capital-intensive business looks cheap on it.
• ✓ That you'd never put EV over net income, or price over EBITDA — the mismatch is the classic trap.

The flow every SQL round rewards

The query

WITH ranked AS (SELECT user_id, amount, DENSE_RANK() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rnk FROM purchases) SELECT user_id, amount FROM ranked WHERE rnk = 2;

Say these out loud — they are the actual signal

• ✓ Which rank function, and why. DENSE_RANK treats two equal top purchases as one tier, so rank 2 is the genuine second-highest amount; ROW_NUMBER would return the duplicate top value instead. Pick deliberately and name the trade-off.
• ✓ Users with only one purchase disappear. That's usually right — but confirm it, and switch to a LEFT JOIN from the user table if the ask was "every user".
• ✓ Filter before you rank (refunds, test accounts, soft-deleted rows) — a window applied over dirty rows produces a clean-looking wrong answer.
• ✓ If windows are off the table, offer the correlated-subquery or self-join version so a legacy engine isn't a dead end.

The definition, said correctly

A p-value is the probability of seeing a result at least this extreme if the null hypothesis were true — that is, if the change did nothing at all. It is a statement about the data given no effect, never about the probability that your hypothesis is right.

The plain-English version

"If this button change truly made no difference, we'd see a lift this big or bigger about 3 times in 100 just from luck. We saw it. So luck is a strained explanation — but not an impossible one."

The three things interviewers listen for

• ✓ p = 0.03 is not "a 3% chance the change doesn't work." Getting this backwards is the single most common fail in a DS stats round.
• ✓ p > 0.05 is not proof of no effect — it's failure to detect one, which an underpowered test guarantees regardless of the truth.
• ✓ Lead with the confidence interval instead. "+0.5% to +11.5%" tells a stakeholder both the direction and how much they still don't know; a p-value alone tells them neither.

Where it goes wrong in practice

• ✓ Peeking: checking daily until it crosses 0.05 inflates the false-positive rate well past 5%. Fix the stopping date up front, or use a sequential test.
• ✓ Many metrics: twenty guardrails at α = 0.05 means one "significant" result by chance. Correct for it, or pre-declare one primary metric.