Software engineer interview questions, with the answers worked out.

Most software engineer interviews mix a coding problem with a design discussion. Here’s one of each, answered the way interviewers want to hear it.

Free question 1 (coding): Merge overlapping intervals

You’re given a list of meeting times as [start, end] pairs, for example [[1,3],[2,6],[8,10],[15,18]]. Merge every pair that overlaps and return the result. For this example, return [[1,6],[8,10],[15,18]].

Model answer

Start by saying the plan out loud: “If I sort by start time, any overlap has to be with the interval right before it. So I can sort once, then walk the list one time.”

def merge(intervals):
    if not intervals:
        return []
    intervals.sort(key=lambda pair: pair[0])
    merged = [list(intervals[0])]
    for start, end in intervals[1:]:
        last = merged[-1]
        if start <= last[1]:
            last[1] = max(last[1], end)
        else:
            merged.append([start, end])
    return merged

Walk-through: after sorting, [1,3] goes in. [2,6] starts at 2, which is at or before 3, so the last interval becomes [1,6]. [8,10] starts after 6, so it’s added. [15,18] starts after 10, so it’s added. Result: [[1,6],[8,10],[15,18]].

Complexity: O(n log n) time for the sort, then O(n) for the single pass. O(n) extra space for the output.

Edge cases to mention: an empty list; a single interval; intervals that only touch, like [1,4] and [4,5] (with start <= end they merge, so ask the interviewer if touching counts as overlapping); one interval inside another, like [1,10] and [2,3], which is why the code takes max() instead of the new end.

What interviewers listen for: you state the sorting idea before coding, you test with the example, and you raise the “touching” question yourself.

Free question 2 (system design): Design a URL shortener

Design a service like bit.ly. Users paste a long URL and get a short link. Anyone who opens the short link is sent to the long URL.

Model answer

1. Agree on scope first. Core features: create a short link, redirect, optional custom alias, optional expiry. Out of scope unless asked: user accounts and detailed analytics.

2. Estimate the load. Say 10 million new links a month and 100 reads for every write. That’s about 4 writes and 400 reads per second on average, so plan for spikes several times higher. Over 5 years that’s 600 million links. At roughly 500 bytes each, about 300 GB of data.

3. API.

• POST /links with the long URL, returns the short code
• GET /{code} returns a redirect to the long URL

4. Making the short code. Use a unique counter (or an ID service that hands out blocks of IDs to each server) and convert the number to base 62 (a to z, A to Z, 0 to 9). Seven characters give 62 to the power of 7, about 3.5 trillion codes, far more than needed. A counter never collides. Random codes also work but need a check for collisions.

5. Storage. A key-value table: code, long URL, created date, expiry. The workload is simple lookups by key, so a key-value or wide-column store fits. A relational database with an index on code also works at this size.

6. Make reads fast. Reads outnumber writes 100 to 1, so put a cache (for example Redis) in front of the database. Popular links stay in memory. Put the redirect service behind a load balancer and add servers as traffic grows.

7. Redirect type. A 301 (permanent) lets browsers cache the redirect, which cuts load. A 302 (temporary) sends every click back to you, which you need if you count clicks. Say which you’d pick and why.

8. Abuse and reliability. Rate-limit link creation, check long URLs against a malware list, and replicate the database so a single failure doesn’t break every link.

What interviewers listen for: you ask about scale before drawing boxes, you explain the trade-off on code generation, and you notice the read-heavy pattern and add caching.