Top 15 LinkedIn Coding Interview Problems: Patterns and What Each Teaches

Top 15 LinkedIn Coding Interview Problems cover

LinkedIn interviews tilt heavily toward graphs. Not a rumor. Not vibes. Consistent signal across hundreds of candidate reports from 2023 through 2026. Skip graphs and round two is going to be a rough introduction to that fact.

This guide covers the 15 LinkedIn coding interview problems reported most in the software engineer loop, what each one is actually testing, and how to read the pattern clusters before you sit down.

LinkedIn Coding Interview Problems at a Glance

#	Problem	LC #	Pattern	Difficulty
1	Number of Islands	200	Graph DFS/BFS	Medium
2	Course Schedule	207	Topological Sort	Medium
3	Word Ladder	127	Graph BFS	Hard
4	Nested List Weight Sum II	364	DFS / Recursion	Medium
5	LRU Cache	146	Design: Hash Map + DLL	Medium
6	Merge k Sorted Lists	23	Heap	Hard
7	Merge Intervals	56	Sort + Greedy	Medium
8	Can Place Flowers	605	Greedy / Arrays	Easy
9	Max Consecutive Ones III	1004	Sliding Window	Medium
10	Isomorphic Strings	205	Hash Map	Easy
11	Binary Tree Level Order Traversal	102	Tree BFS	Medium
12	Search in Rotated Sorted Array	33	Binary Search	Medium
13	Maximum Subarray	53	Kadane's DP	Medium
14	Max Stack	,	Design: Stack + Auxiliary	Hard
15	Two Sum	1	Hash Map	Easy

Difficulty split: roughly 20% Easy, 60% Medium, 20% Hard. The phone screen usually lands one Medium. The onsite escalates.

Why LinkedIn Loves Graphs

LinkedIn's product is a social and professional graph. Connection paths, recommendation feeds, degree-of-separation queries. They built the thing. The interview problems are not random: they reflect the domain engineers actually work in. Graph problems appear in nearly every onsite loop. Expect at least one BFS or DFS problem in the coding rounds, often two. Topological sort shows up often enough that skipping it is a real risk.

After graphs, the next clusters are design problems (LRU Cache, Max Stack), interval and greedy problems, and sliding window. Dynamic programming appears but less dominantly than at Google or Meta. See the top 15 Google coding interview problems and top 15 Amazon coding interview problems for contrast.

Graph Problems: Treat These as Mandatory

Number of Islands (LC 200)

The most frequently reported problem in LinkedIn's loop. A 2D grid of '1' and '0' characters. Count connected islands.

Every approach works: DFS with in-place mutation, BFS with a visited set, union-find. What LinkedIn interviewers actually probe is the follow-up: "what if the grid does not fit in memory?" A lot of candidates solve the base case cleanly, then go quiet. Weak signal, every time.

def numIslands(grid):
    count = 0
    for r in range(len(grid)):
        for c in range(len(grid[0])):
            if grid[r][c] == '1':
                dfs(grid, r, c)
                count += 1
    return count

def dfs(grid, r, c):
    if r < 0 or r >= len(grid) or c < 0 or c >= len(grid[0]) or grid[r][c] != '1':
        return
    grid[r][c] = '0'
    for dr, dc in [(0,1),(0,-1),(1,0),(-1,0)]:
        dfs(grid, r+dr, c+dc)

Course Schedule (LC 207)

Can you complete all n courses given prerequisite pairs? Cycle detection in a directed graph.

Two clean approaches: Kahn's algorithm (BFS-based, count processed nodes) or three-color DFS (white/gray/black). Pick one and own it completely. Kahn's is easier to trace out loud, which matters. If processed_count != n after BFS, there is a cycle.

Word Ladder (LC 127)

Shortest transformation from one word to another, changing one letter at a time, using a dictionary. BFS on an implicit graph. You never build it explicitly. For each word in the queue, enumerate neighbors by swapping each character position through the alphabet and checking the dictionary.

Ranked Hard, but the pattern is standard BFS once you see it as a graph problem. The interview is entirely about whether you make that translation at all. Most people don't, immediately. Bidirectional BFS is the optimal follow-up if the interviewer pushes.

LinkedIn-Specific Problems: Know These Cold

Nested List Weight Sum II (LC 364)

A list of integers and nested lists, with a twist on weighting. In the original version, depth multiplies the integer. In version II, the weight is inverted: shallow elements get heavier weight, not deeper ones.

LinkedIn interviewers have asked this in both phone screens and first onsite rounds through 2024 and 2025. It is not a trick. It just looks like one until you see the BFS pattern. The clean BFS approach accumulates a running flat_sum and adds it again at every level, building up the inverse-depth multiplier without needing to know max depth upfront:

def depthSumInverse(nestedList):
    flat_sum = 0
    weighted_sum = 0
    queue = nestedList[:]
    while queue:
        next_level = []
        for el in queue:
            if el.isInteger():
                flat_sum += el.getInteger()
            else:
                next_level.extend(el.getList())
        weighted_sum += flat_sum
        queue = next_level
    return weighted_sum

Each level adds flat_sum once more, so integers at depth 1 get counted max_depth times and integers at depth max_depth get counted once. Inverse weighting without ever computing max depth.

Isomorphic Strings (LC 205)

Two strings are isomorphic if characters in one can be replaced to produce the other via a one-to-one mapping. The trap: the mapping must be bijective. You need two hash maps, not one.

def isIsomorphic(s, t):
    s_to_t, t_to_s = {}, {}
    for cs, ct in zip(s, t):
        if s_to_t.get(cs, ct) != ct or t_to_s.get(ct, cs) != cs:
            return False
        s_to_t[cs] = ct
        t_to_s[ct] = cs
    return True

Candidates who only check one direction fail on cases like s = "ab", t = "aa". One map allows it; two maps catch the collision. An Easy problem that reliably filters candidates who assume Easy means trivial and skip the edge cases.

Design Problems: O(1) Is the Entire Point

LRU Cache (LC 146)

Get and put in O(1). Hash map pointing to nodes in a doubly linked list ordered by recency. Sentinel head and tail nodes eliminate edge cases in removal.

Most candidates know the concept exists. The interview catches candidates who cannot implement the doubly linked list cleanly under pressure. Practice the full implementation from scratch, including the pointer splice operations. Fumble the pointer splicing under 45 minutes and you will not recover.

Max Stack

Not a numbered LeetCode problem, but it shows up in LinkedIn onsite reports from 2025 and 2026. Push, pop, top, and getMax all in O(1). A monotonic auxiliary stack tracks the running maximum alongside the main stack.

The reported follow-up: "now support O(log n) delete-by-value." Lazy-deletion heap paired with a doubly linked list. If the interviewer asks, it signals a senior-level expectation.

Greedy Problems: Don't Overthink the Linear Ones

Merge Intervals (LC 56)

Sort by start time, then sweep. The merge condition is current_start <= last_end. The only bug candidates reliably introduce: writing last_end = current_end instead of last_end = max(last_end, current_end). A fully contained interval breaks the naive version.

Can Place Flowers (LC 605)

Place k flowers in an array without adjacent neighbors. Greedy: scan left to right and plant whenever the current cell and both neighbors are empty. It shows up in LinkedIn phone screens as a warmup. Its purpose is to test greedy correctness on a linear scan, not complexity analysis. Candidates who treat it like a graph problem burn time they cannot afford to burn.

Sliding Window: One Follow-Up You Need to Know

Max Consecutive Ones III (LC 1004)

Maximum subarray length with at most k zeros allowed (you can flip them). Variable-size sliding window: expand right, shrink left when the zero count in the window exceeds k.

LinkedIn has added a follow-up about circular arrays in recent reports. If the interviewer asks, duplicate the array and cap the window at length n. Review the sliding window algorithm if the variable-size variant is not automatic yet.

Trees and Binary Search: Foundations You Cannot Skip

Binary Tree Level Order Traversal (LC 102)

BFS with a level separator. Use len(queue) at the start of each level to know how many nodes belong to it before processing children.

Search in Rotated Sorted Array (LC 33)

Modified binary search on a rotated array. The invariant: one of the two halves at any midpoint is always cleanly sorted. Check which half is sorted, determine which half the target could fall in, and recurse on that side.

Maximum Subarray (LC 53)

Kadane's algorithm. Running sum resets to the current element when it drops below zero. Initialize to nums[0], not 0. All-negative inputs break the zero-initialized version. For the dynamic programming framework behind why this recurrence works: dp[i] = max(nums[i], dp[i-1] + nums[i]).

Two Sum (LC 1)

The warmup problem for almost every phone screen at every company, LinkedIn included. One pass, hash map, store the complement, check if current element is already stored. Get this done in five minutes and spend the rest on communication. If it takes fifteen, that is useful information about your current prep state.

How to Actually Prep These 15

The LinkedIn onsite has two to three coding rounds. Graph problems cluster across those rounds more than any other topic.

Start with graphs: BFS, DFS, cycle detection via topological sort. Then design problems (LRU Cache, Max Stack). Then round out with intervals, sliding window, and binary search. DP appears but not as a dominant theme. Two or three core patterns (Kadane's, basic knapsack) will cover what comes up.

Phone screen usually gives one Medium on arrays or strings plus a follow-up. The onsite escalates to graph problems with constraints, hard design problems, or Medium problems with twist follow-ups like the circular array variant.

If you want to practice how you actually sound explaining these problems, SpaceComplexity runs voice-based mock interviews scored across problem-solving, communication, and code quality. The rubric feedback tells you which dimension is costing you, not just whether you solved the problem.

The Short Version

Graph problems dominate. BFS, DFS, topological sort, and cycle detection are mandatory prep, not optional.
Nested List Weight Sum II and Isomorphic Strings are distinctly LinkedIn. Know both cold.
LRU Cache is the most commonly reported hard problem. Practice the full implementation, not just the concept.
Phone screens skew Easy-Medium. Onsites escalate to hard design problems and constrained graphs.
Two maps, not one, for any character bijection problem.
Kadane's always initializes to nums[0].
The circular array follow-up on sliding window is a real reported twist. Know how to adapt.