LinkedIn interview questions and process

He'd done four hundred LeetCode problems and could recite the Big-O of a segment tree in his sleep. Then the LinkedIn interviewer said: "Design People You May Know." He drew a feed. Timeline, ranking, cache — the Instagram-shaped design he'd rehearsed twenty times. The interviewer waited, then asked the question that actually mattered: "Where's the graph?" There wasn't one. He'd prepared for a content company and walked into a relationship company.

LinkedIn interview questions cluster around one fact that's easy to memorize and hard to internalize: LinkedIn's core product isn't a feed, it's a graph — 1+ billion members connected by edges that mean something (colleague, classmate, "second-degree connection who could get you into that Series C startup"). The coding rounds lean on trees and graphs more than most FAANG-adjacent loops. The system design round is rarely "scale a generic web app" — it's "rank a feed," "expand a connection graph," or "fan out a notification" at graph scale. And the culture round isn't generic HR filler; it's scored against six principles LinkedIn has published and repeated for over a decade. This guide covers all three, plus what's genuinely different by role, with the hedges in place where the exact structure varies by team and year — because it does, and pretending otherwise would be the same mistake as designing a feed for a graph problem.

The LinkedIn interview process, round by round

Candidates on Glassdoor, Blind and 1point3acres describe a broadly consistent shape, though the exact round count and order vary by team, level and year — treat the following as commonly reported, not guaranteed:

• Recruiter screen (~15–30 min). Background, motivation, comp expectations, and which team/pod you're being considered for.
• Technical phone screen (45 min, sometimes two). One live coding problem on a shared editor, occasionally paired with a short design or behavioral component.
• Virtual onsite loop (4–6 interviews, 45–60 min each). Typically: two coding rounds, one to two system design rounds for mid-level and above, and one values/culture round often called the "host" round internally by candidates who've been through it.
• Team matching / hiring committee. Like most large companies, the final call often runs through a committee that didn't sit in your room — your interviewers write up feedback, not a verdict.

For a shorter walkthrough of the same loop with fewer worked examples, see our LinkedIn interview preparation guide. This post goes deeper on the actual questions and answers, especially the graph-flavored system design round.

LinkedIn coding interview questions

In the phone screen and each onsite coding round, candidates typically get one or two problems in 40–45 minutes, at LeetCode medium difficulty with occasional hards for senior roles. What's specific to LinkedIn: candidates and prep sites consistently report a heavier lean toward trees and graphs than the general FAANG mix — a direct reflection of the product being a social graph. Expect array/string/hashmap fundamentals too, but don't skip graph traversal prep the way you might for a more feed-centric company.

Commonly reported topic areas:

• Graphs and trees — BFS/DFS, shortest path, topological sort, lowest common ancestor, number of islands/connected components. These map directly to "how many people are within two connections of me" style reasoning.
• Arrays, strings, hashmaps — two-pointer, sliding window, interval merging.
• Heaps and recursion — top-K problems, merge-style questions.
• Clear narration is graded, not optional. Every write-up of a LinkedIn loop mentions the same thing: interviewers ask you to talk through your approach before and while you code, not just present a finished solution.

A worked example that shows why the graph lean matters — "find everyone within two connections of a given member":

from collections import deque

def within_two_connections(graph, start):
    # graph: dict[member_id] -> set(connected member_ids)
    visited = {start: 0}
    queue = deque([start])
    result = []

    while queue:
        member = queue.popleft()
        depth = visited[member]
        if depth == 2:
            continue  # don't expand past the second degree
        for neighbor in graph[member]:
            if neighbor not in visited:
                visited[neighbor] = depth + 1
                queue.append(neighbor)
                result.append(neighbor)

    return result

The interview follow-up almost always probes the parts that matter at LinkedIn's actual scale: what happens when a member has 30,000 connections (LinkedIn caps first-degree connections around 30,000 for exactly this reason), how you'd bound the BFS so a highly-connected member doesn't blow up the traversal, and how you'd cache second-degree results since they change slowly for most members.

LinkedIn system design interview questions — the graph-shaped round

This is where LinkedIn's loop diverges most from a generic "design a scalable web service" prompt. Candidates report design questions drawn directly from LinkedIn's own product surface: the feed, the connection graph, and notifications. Treat every number below as a commonly-used prep assumption, not a disclosed internal figure — LinkedIn hasn't published its actual infrastructure numbers, and any guide (including this one) that states them as fact is guessing.

"Design LinkedIn's feed" — ranking, not just fan-out

A generic feed-design answer (Twitter/Instagram-shaped: fan-out on write vs. fan-out on read, a timeline service, a cache) gets you halfway. What separates a strong answer here is treating ranking as the hard part, because LinkedIn's feed is professional and low-frequency compared to a consumer social feed — most members don't post daily, so pure recency ranking produces a stale, boring feed fast.

• Requirements first. Clarify read/write ratio (commonly assumed to be extremely read-heavy, on the order of 100:1), latency target (a p95 feed-load target under 300ms is a reasonable assumption to state out loud), and whether you're ranking posts, articles, job postings, or all three.
• Fan-out strategy. Fan-out-on-write for typical members; fan-out-on-read (or a hybrid) for high-follower accounts — the same "celebrity problem" every feed system hits, worth naming explicitly rather than treating as a surprise.
• Ranking signals. Recency, affinity (how close the connection is — first-degree colleague beats second-degree stranger), engagement prediction, and content type diversity so the feed isn't five job posts in a row. This is the part interviewers are actually listening for — can you reason about why a professional feed ranks differently from a consumer one.
• Data model. A post table, an edge/connection table, and a precomputed or on-demand ranking service that reads both.

"Design People You May Know" — the connection-recommendation graph

This is the question that catches candidates who only prepped feed-shaped systems, because it's a graph problem end to end, not a content problem.

• Signal sources. Mutual connections (the obvious one), shared company/school history, profile views, imported contacts, and search co-occurrence. A strong answer names more than one signal and says how you'd weight them.
• The graph traversal problem. Computing "mutual connections" naively for every pair of members doesn't scale — this is where a candidate who's fluent in graph algorithms (see the coding section above) has a real advantage, because the interviewer is testing the same intuition twice: can you bound a traversal over a graph where some nodes have tens of thousands of edges.
• Offline batch vs. online. Full recomputation of recommendation candidates is typically framed as a batch job (nightly or near-real-time) with a fast online re-ranking layer on top for freshness — a distinction interviewers listen for explicitly.
• Feedback loop and quality. How do you know the recommendations are good? Click-through and "connected within N days" are reasonable proxy metrics to propose.

"Design a notification system" — fan-out with preference and priority

• Event sources. Connection requests, post likes/comments, job matches, InMail — each with different urgency and different opt-out rules.
• Fan-out at write time, since notifications need to reach potentially many subscribers per event, with a preferences table so members can mute categories without disabling notifications entirely.
• Delivery channels. In-app, email digest, push — with a dedup/batching layer so one busy thread doesn't turn into fifty separate emails, a genuinely common follow-up in write-ups of this round.
• Guarantees. At-least-once delivery with idempotent handling on the client is the standard honest answer; claiming exactly-once without qualification is a tell that you haven't actually built a notification system.

LinkedIn behavioral and values questions

LinkedIn has publicly described its operating principles for over a decade, and candidates consistently report the culture/values round mapping to them. As with any public company messaging, the exact wording can shift between refreshes of the culture deck, so treat the phrasing below as directionally accurate rather than a verbatim quote you should recite back:

• Members first. Everything is weighed against what's good for the member, not just the metric. Expect: "tell me about a time you pushed back on a feature because it was good for the business but bad for the user."
• Relationships matter. LinkedIn is, structurally, in the relationship business — and this extends to how they expect you to treat colleagues. Expect: "tell me about a disagreement with a teammate and how you resolved it," graded partly on whether the relationship survived intact.
• Be open, honest and constructive. Expect direct questions about giving and receiving difficult feedback — "tell me about feedback you gave that was hard to deliver," with the interviewer listening for whether it was actually constructive or just blunt.
• Demand excellence. Expect a question about raising your own bar or someone else's — "tell me about a time 'good enough' wasn't good enough for you."
• Take intelligent risks. Not "tell me about a risk" generically — the follow-up almost always probes how you bounded the risk. What made it intelligent rather than reckless.
• Act like an owner. Expect "tell me about something outside your job description you picked up anyway," scored on whether you actually followed through, not just noticed the gap.

The honest preparation advice: don't memorize six answers mapped one-to-one to six values. Prepare four or five real stories from your own work, then be ready to explain which value each one demonstrates and why — because interviewers rotate which values they probe, and a story that only fits one box reads as rehearsed.

How the loop differs by role

• Software engineer (product/backend/frontend). The loop described above, in full — coding, graph-shaped system design, values.
• Data engineer. Expect the coding round to lean more heavily on SQL and data-modeling problems alongside DSA, and the system design round to shift toward pipelines, batch vs. stream processing, and schema evolution at scale. Worth knowing as real, verifiable context: LinkedIn built and open-sourced Apache Kafka in 2011, and Kafka-shaped questions — partitioning, consumer groups, exactly-once semantics, replay — show up disproportionately often in data-engineering-track interviews at LinkedIn, for the obvious reason that it's their own infrastructure.
• Infrastructure / platform engineer. More emphasis on distributed systems fundamentals — consistency models, replication, capacity planning — and less on product-specific ranking logic. The values round is reportedly unchanged across tracks.

Our system design interviews guide covers the general framework these role-specific loops all sit on top of, and the frontend system design interview questions guide is the right companion if you're interviewing for a LinkedIn frontend role specifically.

LeetCode dumps, GeeksforGeeks threads, and where they fall short

Search "linkedin interview questions" and most of what comes back is a list of question titles with no explanation of why LinkedIn asks them, or a GeeksforGeeks-style thread of one-line "I was asked X" reports with no worked answer. LeetCode itself is genuinely useful for the coding round — grind graphs and trees specifically, not the general problem set — but it will not rehearse the two rounds that actually decide the offer: explaining why your feed-ranking design accounts for LinkedIn being low-frequency-post, and telling a values story that survives a follow-up question you didn't script for.

A friend's WhatsApp PDF of "questions I got asked" has the same problem: it's a transcript, not a rehearsal. And prompting ChatGPT to "ask me LinkedIn interview questions" gets you a list, not a real follow-up — it won't push back on a hand-wavy answer to "where's the graph in your design" the way an actual interviewer will. Greenroom runs the values round and the system design round out loud, with Ari asking the same kind of follow-up a real LinkedIn interviewer would — "you said 'affinity,' define it" — because the real interview rarely stops at your first sentence. The honest tradeoff: Ari won't run your code or check a Kafka config for you, so pair spoken practice with real DSA reps.

How to prepare for the LinkedIn interview

• Weeks 1–2. DSA with a deliberate lean toward trees and graphs — BFS/DFS, shortest path, topological sort, LCA — on top of the standard array/string/hashmap set.
• Week 3. Design the feed, People You May Know, and a notification system out loud, from scratch, twice each. The second pass should be faster and should name the graph-shaped part of the problem within the first two minutes.
• Week 4. Write down four or five real work stories, then map each one to more than one of LinkedIn's six operating principles, out loud, until the mapping stops sounding rehearsed.
• Final days. A full mock loop — one coding round, one system design round, one values round — back to back, the way the real onsite will feel.

For the DSA-heavy weeks, our DSA coding interview preparation guide and recursion and backtracking questions cover the graph-adjacent categories LinkedIn leans on. For your own GitHub projects coming up in the values round, talking about your GitHub projects in interviews is worth a read, and your actual LinkedIn profile matters more once you're the one being searched — see LinkedIn profile tips for software engineers.

Frequently asked questions

What is the LinkedIn interview process for software engineers?

Candidates commonly report a recruiter screen, one or two technical phone screens with live coding, and a virtual onsite loop of four to six interviews covering two coding rounds, one or two system design rounds for mid-level and above, and a values/culture round. The exact count and order vary by team, level and year, and the final decision typically runs through a hiring committee rather than a single interviewer's call.

What coding questions does LinkedIn ask?

LinkedIn's coding rounds are LeetCode medium-difficulty with occasional hards for senior candidates, drawn from arrays, strings and hashmaps, heaps and recursion, and — more heavily than most companies — trees and graphs, reflecting the product's social-graph structure. Expect BFS/DFS, shortest path, topological sort, lowest common ancestor and connected-components style problems, with narrating your approach out loud graded as part of the round.

What system design questions does LinkedIn ask?

Commonly reported prompts are drawn directly from LinkedIn's own product: design the feed (where ranking, not just fan-out, is the hard part, since LinkedIn's feed is lower-frequency-post than a consumer social feed), design "People You May Know" (a connection-graph recommendation problem, not a content problem), and design a notification system (fan-out with per-category preferences and delivery guarantees). Strong answers reach for graph-shaped reasoning rather than retrofitting a generic feed-system template.

What are LinkedIn's core values and how do they show up in interviews?

LinkedIn has publicly described operating principles including Members First, Relationships Matter, Be Open Honest and Constructive, Demand Excellence, Take Intelligent Risks, and Act Like an Owner — exact wording can shift between refreshes of the company's culture messaging. Candidates report a dedicated values round that maps behavioral questions to these principles, such as a time you pushed back on a feature for the member's benefit, or a disagreement with a teammate you resolved without damaging the relationship.

How many rounds are in a LinkedIn interview?

Most candidates report five to seven total touchpoints: a recruiter screen, one or two technical phone screens, and a four-to-six-interview virtual onsite loop covering coding, system design and values. This varies by team, level and year, so treat any specific count — including this one — as commonly reported rather than guaranteed.

How is the LinkedIn interview different for data engineers versus software engineers?

Data engineering candidates report a stronger SQL and data-modeling component in the coding round and a system design round that shifts toward pipelines, batch versus stream processing, and schema evolution rather than product-feature ranking. LinkedIn built and open-sourced Apache Kafka, and Kafka-shaped questions — partitioning, consumer groups, replay — show up disproportionately in the data-engineering track. The values round is reportedly consistent across tracks.