LinkedIn Software Engineer Interview Prep Guide

Focus most on phone-screen execution, Top K/heaps, randomized multiset design, and LinkedIn-style system design because your interview starts in 1 week and your category ratings are all 3/5 with no solved-question signal yet. Nothing is clearly rated 4–5, so the only brief-review areas are LRU/cache follow-ups and general language/web/database fundamentals that are not central in your selected LinkedIn screen/onsite outline. The LinkedIn-specific emphasis is search/ranking, job-style recommendation thinking, member graph design, feed/notification fanout, key-value storage, and distributed observability. With 1 week to the phone screen and 2 weeks to onsite, spend the first half on coding reps plus concise system-design drills, then shift heavily into onsite system design and behavioral stories.

Technical Screen — 45 min

Coding & Algorithms

Focus area — Your phone screen is in 1 week, so prioritize fast clarification, brute force, optimization, coding, tests, and complexity narration.

What's being tested

Phone-screen coding execution tests whether you can translate an ambiguous prompt into a correct algorithm, implement it cleanly, and validate it aloud. The core skill is recognizing common patterns—hashing, two pointers, sliding windows, stacks, trees, graphs, and sorting—while managing edge cases and complexity under time pressure.

Patterns & templates

• Clarify and constrain — define input size, duplicates, ordering, mutability, invalid inputs, and expected output before choosing an algorithm.

• Hash map/set lookup — use dict or set for membership, counts, and complements; typically O(n) time and O(n) space.

• Two pointers — exploit sorted input or opposite/fast-slow movement; target O(n) scans instead of nested O(n²) loops.

• Sliding window — maintain a valid contiguous range with left/right pointers; expand, contract, and update state incrementally in O(n).

• Stack templates — use a stack for matching delimiters, undo-like behavior, or monotonic next-greater-element scans; each item is pushed and popped once.

• BFS/DFS traversal — track a visited set, define the base case, and state O(V + E) time for graph traversal.

• Complexity and testing — state time/space complexity, then test empty input, one element, duplicates, boundaries, and adversarial ordering.

Common pitfalls

Pitfall: Coding immediately without confirming whether inputs are sorted, whether duplicates matter, or whether modifying the input is allowed.

Pitfall: Producing a correct-looking solution but missing off-by-one errors, empty collections, duplicate values, or disconnected graph components.

Pitfall: Overengineering with dynamic programming or custom classes when a linear scan, hash table, or standard library operation is sufficient.

Practice these

The practice cards below cover the canonical variants—solve all of them and time yourself.

Practice questions

• Top K And Heaps (Focus) — covered in depth under Other below.

Focus area — Technical screens often test this data-structure variant; prioritize O(1) swap-delete, duplicate bookkeeping, and random correctness.

What's being tested

This tests the array-plus-hash-map pattern for supporting duplicate values with expected O(1) insert, remove, and random selection. You must maintain index bookkeeping correctly so deleting an arbitrary occurrence does not break uniform sampling or leave stale references.

Patterns & templates

• Store every occurrence in a dynamic array; choose randomIndex = randomInt(0, len(items) - 1) for uniform O(1) sampling.

• Map each value to a set of indices; duplicates therefore remain distinct while insert and lookup stay expected O(1).

• Remove in O(1) by swapping the target with the final array element, updating both values’ index sets, then popping.

• For frequency-weighted sampling, sample array positions rather than distinct keys; a value appearing k times receives probability k / n.

• Use a stored index from the value’s index set; avoid scanning for an occurrence, which silently changes removal to O(n).

• Handle the swapped element carefully when removing the final element itself; update its index only after determining whether indices coincide.

• State complexity precisely: expected O(1) operations, O(n) space, with hash-table worst cases depending on collision behavior.

Common pitfalls

Pitfall: Sampling from distinct keys makes values equally likely instead of making each stored occurrence equally likely.

Pitfall: Removing from the array without deleting and relocating index metadata leaves stale indices and causes later operations to corrupt state.

Pitfall: Assuming deterministic O(1) hash-map performance; describe expected complexity and mention resizing or adversarial-collision considerations when relevant.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

• Trees, Graphs, And Recursive Traversal — covered in depth under Other below.

System Design

• LinkedIn Member Graph Service (Focus) — covered in depth under Onsite below.

Onsite — 54 min

Coding & Algorithms

• Top K And Heaps (Focus) — covered in depth under Other below.

• Trees, Graphs, And Recursive Traversal — covered in depth under Other below.

System Design

Focus area — LinkedIn products rely on member connections; practice graph modeling, privacy rules, fanout, caching, and low-latency relationship queries.

What's being tested

This topic tests whether you can design a highly available, low-latency service for storing and querying relationships among hundreds of millions of members. The interviewer is probing API boundaries, graph-oriented data modeling, partitioning, consistency, idempotent mutations, and failure handling—not graph theory alone. LinkedIn cares because connection, follow, blocking, and recommendation-adjacent features all depend on correct relationship state under heavy read and write load.

Core knowledge

• Relationship modeling should represent an edge as (sourceMemberId, targetMemberId, type, state, createdAt, version). Keep direction explicit: connections are logically symmetric, while follows, blocks, and pending invitations are directed or stateful.

• Separate edge types and lifecycle states: PENDING, ACCEPTED, REJECTED, WITHDRAWN, and BLOCKED. A connection request should not become visible as a connection until both sides’ authorization and state transition are recorded correctly.

• Design APIs around explicit commands and queries: POST /invitations, POST /connections/{id}/accept, DELETE /connections/{id}, GET /members/{id}/connections, and GET /members/{id}/relationship/{otherId}. Return stable error semantics and idempotency behavior.

• Use idempotency keys for invitation creation and retries. A request identified by (requesterId, recipientId, clientRequestId) should produce one logical mutation even when clients retry after timeouts.

• A relational store such as Postgres or a distributed wide-column store can support adjacency lists. Index both (sourceMemberId, type, state) and (targetMemberId, type, state); bidirectional lookup is essential for symmetric connections and inbound requests.

• Avoid naïve graph traversal in the request path. “Connections of connections” can explode to $O(d^k)$ candidates; prefer bounded breadth-first search, precomputed summaries, or a separate service when the product explicitly requires second-degree results.

• Partitioning should distribute by member ID while handling celebrity or highly connected accounts. Consistent hashing, virtual shards, request fan-out limits, and hot-key mitigation matter more than choosing a graph database by name.

• Choose consistency per operation. Relationship writes need strong or carefully controlled consistency for authorization-sensitive checks; list reads may tolerate eventual replicas. State that a read immediately after an accepted invitation may be temporarily stale if using asynchronous replication.

• Make multi-record updates safe. For a symmetric connection, either store one canonical edge and derive both directions, or write two adjacency records with a transaction/outbox protocol and repair jobs; document how partial failure is detected and healed.

• Caching can serve relationship checks and popular adjacency pages, but invalidation must follow successful writes. Use versioned cache entries or short TTLs, and never let stale cache data bypass block, privacy, or authorization checks.

• Pagination must be stable under concurrent mutations. Prefer cursor pagination using (createdAt, edgeId) rather than offsets; define ordering, duplicate prevention, deleted-edge behavior, and a maximum page size to prevent expensive scans.

• Protect the service with authentication, authorization, abuse controls, and privacy enforcement. A member may query only permitted relationship data, while blocks should hide or suppress edges consistently across reads, search-like APIs, and notifications.

Worked example

Design a LinkedIn Member Graph Service: I would first clarify supported relationship types, expected read/write QPS, latency targets, privacy rules, pagination requirements, and whether second-degree traversal is in scope. I would declare an initial assumption of hundreds of millions of members, mostly read-heavy traffic, and a requirement for idempotent invitation and acceptance operations. I would organize the design around four pillars: APIs and state transitions, adjacency-list storage and indexes, partitioning and cache strategy, and consistency plus failure recovery. I would model invitations and accepted connections separately or as explicit states, then define the invariant that an accepted connection is visible from both members’ perspectives. A key tradeoff is canonical single-edge storage versus duplicated directional records: canonical storage simplifies consistency, while duplicated records makes neighbor reads faster but requires transactional repair or an outbox. I would explain how cursor pagination, bounded fan-out, and hot-member protection keep reads predictable. I would close by saying that, with more time, I would quantify capacity, design reconciliation metrics, and walk through failover during a partially completed acceptance.

A second angle

A related framing is serving a member’s connection list at scale, where the primary constraint is predictable read latency rather than mutation correctness. The design would emphasize adjacency indexes, cursor pagination, replica routing, cache behavior, and protection against very high-degree members. The same graph model applies, but the tradeoff shifts toward denormalized read paths and bounded fan-out, provided privacy and block-state checks remain authoritative. I would also clarify whether the product needs a point-in-time snapshot or accepts changes appearing between pages.

Common pitfalls

Pitfall: Treating the graph as a generic graph-database problem and proposing unrestricted traversal for every request. Connection lists and relationship checks usually need indexed adjacency lookups; bounded traversal or offline computation is safer for multi-hop features.

Pitfall: Saying “eventual consistency is fine” without identifying which operations require stronger guarantees. A stale list may be acceptable briefly, but stale block or authorization state can expose private relationship data.

Pitfall: Describing storage and APIs without failure semantics. A strong answer explains retries, duplicate requests, partial writes, cache invalidation, reconciliation, and what the client observes when an operation times out after the server commits.

Connections

An interviewer may pivot to distributed transactions, outbox patterns, consistent hashing, or rate limiting. They may also ask how to design privacy enforcement, abuse prevention, or a notification pipeline without coupling those systems tightly to the graph’s write path.

Further reading

• Designing Data-Intensive Applications — strong coverage of replication, partitioning, consistency, and distributed failure modes.

• Amazon Dynamo: A Highly Available Key-value Store — foundational discussion of partitioning, quorum behavior, and availability tradeoffs.

• The Log: What every software engineer should know about real-time data's unifying abstraction — useful context for durable event-driven propagation and replay.

Practice questions

Focus area — This adds LinkedIn-specific system design practice around push versus pull fanout, ranking hooks, delivery guarantees, and freshness.

What's being tested

This topic tests whether you can design a distributed fanout system that propagates one member’s activity to many followers while meeting latency, availability, ordering, and correctness requirements. For LinkedIn, a single post, connection update, or job change may affect millions of feed readers and notification recipients, so naïvely writing directly to every follower does not scale. The interviewer is probing whether you can decompose the system, choose push versus pull deliberately, handle retries and duplicates, and explain behavior during celebrity posts, failures, and traffic spikes.

Core knowledge

• Fanout-on-write materializes a post into followers’ feed stores when it is created; reads are cheap and predictable, but writes can become enormous for highly followed members. Fanout-on-read stores the post once and merges followed authors’ posts at request time; writes are cheap, but reads require more work and have less stable latency.

• A practical design uses a hybrid fanout: push to ordinary followers, but keep very large accounts in a pull path. Define a threshold using measured follower counts and traffic, not a magic constant; a 10-million-follower author cannot synchronously generate 10 million feed mutations.

• Separate the activity log from materialized feed state. An append-only event in Kafka or a durable log is the source for asynchronous workers, while per-member feed entries live in a database such as Cassandra, RocksDB, or a sharded relational store.

• Treat every delivery operation as at-least-once unless the entire path has stronger guarantees. Consumers must be idempotent using an event ID, such as (actor_id, activity_id, recipient_id), with conditional writes or deduplication records; retries must not create duplicate feed cards or notifications.

• Use partitioning to distribute work by recipient or actor. Recipient partitioning balances feed updates and makes a member’s feed localized, while actor partitioning preserves event order but can create hot partitions for high-follower accounts; hot-key mitigation is essential.

• Model ordering explicitly. Store an event timestamp plus a monotonic sequence or log offset, then define whether the API guarantees global order, per-author order, or only best-effort recency. Clock timestamps alone are unsafe because machines can disagree and events can arrive late.

• Use backpressure and bounded queues between ingestion, fanout, and persistence. When consumers lag, preserve the durable source event, shed noncritical work such as low-priority notifications, and expose lag metrics rather than allowing unbounded memory growth.

• Design separate notification delivery from feed materialization. In-app notifications can be persisted and fetched, while email, push, and SMS need channel-specific workers, rate limits, provider retries, suppression rules, and deduplication; a failed email provider should not block feed writes.

• Make APIs and workers resilient to partial failure. A post-creation request should acknowledge after durable acceptance rather than waiting for every follower update; retry with exponential backoff and jitter, use dead-letter queues for poison events, and provide replay or repair tooling.

• Cache read-heavy feed pages with a clear invalidation strategy. Cursor-based pagination is safer than offset pagination under concurrent inserts; a cursor should encode a stable ordering key such as (created_at, activity_id), and the system must tolerate deleted or privacy-restricted entries.

• Account for membership and visibility changes during asynchronous processing. Before serving or materializing an entry, enforce blocks, unfollows, audience restrictions, and deleted-content tombstones; otherwise a delayed worker can expose content that was valid only when the event was created.

• Define operational targets using measurable SLOs, such as event acceptance latency, time-to-feed-visibility, notification delivery latency, duplicate rate, queue lag, and p99 read latency. Monitor by shard, region, actor size, and channel so a global average does not hide celebrity-induced failures.

Worked example

For the representative prompt “Design LinkedIn Feed and Notification Fanout”, I would first clarify whether the requirement is feed-only or also email and push notifications, the expected read and write rates, freshness goals, ordering guarantees, privacy constraints, and acceptable delay for asynchronous fanout. I would declare that post creation returns after the event is durably recorded, while feed visibility is eventually consistent within a stated target such as a few seconds. I would organize the answer around four pillars: durable activity ingestion, hybrid fanout, per-member feed storage and cursor reads, and independent notification pipelines. I would then describe an idempotent consumer using an activity ID, recipient ID, and conditional insert so retries cannot duplicate entries. The key tradeoff is push versus pull: push gives fast, cheap reads for normal accounts, while pull prevents a highly followed account from creating an unbounded write storm. I would explicitly discuss backpressure, partition hot spots, privacy checks, retries, and observability rather than claiming “exactly once” end to end. I would close by saying that, with more time, I would specify shard sizing, multi-region failover, repair jobs, and load-test scenarios for a celebrity post and a regional queue outage.

A second angle

A notification-focused variant has different constraints from a feed, even though both begin with an activity event. Notifications require per-channel preferences, aggregation such as “five people reacted,” provider-specific retries, and stronger deduplication so one action does not generate repeated alerts. The system should therefore use a notification policy and aggregation layer before channel delivery, rather than treating every follower as a direct push recipient. Feed materialization can tolerate seconds of delay, while mobile push may require fast delivery but must also respect rate limits and quiet hours.

Common pitfalls

Pitfall: Saying “fan out synchronously to all followers” ignores tail latency and makes one large account able to exhaust request threads, database connections, or queue capacity. Use durable asynchronous work and explain a hybrid strategy for high-degree actors.

Pitfall: Claiming exactly-once delivery because Kafka or a database is involved is too strong. Most practical systems provide at-least-once processing with idempotent writes, deduplication, and reconciliation.

Pitfall: Discussing only the happy-path architecture misses the Software Engineer depth interviewers expect. Explicitly cover retries, poison messages, hot partitions, privacy changes, deletion, lag monitoring, and how the system recovers after a worker or region failure.

Connections

An interviewer may pivot to consistent hashing, event-driven architecture, idempotency, cursor pagination, multi-region replication, or backpressure. They may also ask how feed ranking is layered on top of the candidate-generation and fanout system without making ranking correctness a prerequisite for durable delivery.

Further reading

• Designing Data-Intensive Applications — Martin Kleppmann’s treatment of logs, streams, partitioning, replication, and exactly-once misconceptions.

• The Log: What every software engineer should know about real-time data's unifying abstraction — LinkedIn’s foundational discussion of durable event logs.

• Kafka: a Distributed Messaging System for Log Processing — Background on partitioned, replicated commit-log design.

Practice questions

Focus area — LinkedIn onsite system design can lean storage-heavy; your system design rating is 3/5, so emphasize partitioning and consistency.

What's being tested

These designs test whether you can turn simple GET/PUT semantics into a reliable service under concurrency, node failures, increasing data volume, and latency requirements. The interviewer is probing your command of partitioning, replication, consistency, durability, and operational tradeoffs—not whether you can name a favorite database. LinkedIn cares because many backend systems depend on predictable low-latency reads, graceful degradation, and clear correctness guarantees when machines and networks fail.

Core knowledge

• A key-value store exposes operations such as GET, PUT, DELETE, and often conditional writes like CompareAndSet. Define maximum value size, key format, availability target, throughput, p99 latency, and whether missing keys, stale reads, or overwrites have explicit semantics.

• For a single process, a hash map provides expected $O(1)$ lookup, insertion, and deletion, with $O(n)$ space. Concurrent access requires a mutex, read-write lock, or sharded locks; never hold a global lock across slow disk I/O or callbacks.

• Partitioning distributes keys across nodes. Simple hash(key) mod N is easy but remaps roughly most keys when $N$ changes; consistent hashing or rendezvous hashing limits movement, while virtual nodes improve balance when machines have unequal capacity.

• Replicate each partition across distinct failure domains using a replication factor $R$, commonly three. A leader-based design routes writes through one replica; leaderless designs use quorum parameters $N$, $W$, and $R$, typically requiring $W+R>N$ for read-write overlap, but this alone does not guarantee conflict resolution.

• Consistency is a contract, not a binary feature. Strong linearizable reads and writes simplify clients but cost coordination; eventual consistency improves availability and latency. State whether reads may be stale, what ordering is guaranteed, and how concurrent writes resolve.

• For quorum reads, read from $R_r$ replicas and write to $R_w$ replicas. If $R_r+R_w>N$, at least one replica overlaps, but repair, hinted handoff, version vectors, timestamps, or deterministic last-write-wins rules are still needed to reconcile divergent values.

• Durability requires more than acknowledging a write in memory. A write-ahead log (WAL), append-only log, or replicated commit must reach stable storage before acknowledgement if acknowledged data cannot be lost after process or machine failure; define the fsync policy explicitly.

• Storage engines trade write and read behavior. An in-memory hash map is fast but volatile; an LSM tree writes sequentially to a memtable and immutable SSTables, then uses compaction. Compaction consumes I/O and can cause write amplification, while Bloom filters reduce unnecessary SSTable reads.

• A cache-aside layer can reduce backend load, but invalidation creates stale-data races. TTL metadata should use monotonic expiration handling, and expired entries should be removed lazily or by bounded background work; avoid allowing a cleanup thread to monopolize locks.

• Rebalancing must preserve availability and avoid copying an entire dataset at once. Move ranges or virtual-node ownership incrementally, throttle transfer bandwidth, dual-read or dual-write during cutover when necessary, and verify checksums before deleting the old copy.

• Failure handling should distinguish process crashes, disk failures, network partitions, slow nodes, and correlated zone outages. Use timeouts, bounded retries, exponential backoff with jitter, circuit breakers, hinted handoff, and idempotent request identifiers to prevent retry storms and duplicate effects.

• Operational correctness needs observability: request rate, error rate, saturation, p50/p99 latency, replication lag, rejected writes, compaction debt, disk usage, hot partitions, and repair backlog. A health check should not report a node healthy merely because its process is alive.

Worked example: Design a Distributed Key-Value Store for a Small Company's Internal Use

In the first 30 seconds, a strong candidate would clarify expected keys and values, read/write ratio, data size, latency target, durability requirements, acceptable staleness, regions, and whether this is a general-purpose database or an internal configuration service. They might assume tens of millions of keys, three availability zones, replication factor three, and a requirement that acknowledged writes survive a single-node failure. The answer can be organized around the API and semantics, partitioning and request routing, replication and consistency, durable storage, and failure recovery/operations. For a small company, they should compare a centralized leader with replicas, a decentralized ring, and a hybrid design rather than prematurely building a globally distributed system. A sensible initial choice is a partitioned leader-per-shard architecture with consistent hashing, synchronous replication within the region, and asynchronous cross-region replication if disaster recovery is required. The explicit tradeoff is simplicity versus availability: a centralized or leader-based model is easier to operate and reason about, while decentralized quorum writes reduce dependence on one leader but make conflict repair and debugging harder. They should explain how membership changes trigger throttled range movement and how reads behave while a replica is unavailable. If they had more time, they would detail schema/value limits, rolling upgrades, backup restore testing, and load tests for hot keys and compaction.

A second angle: Design an in-memory key-value store using maps

The in-memory version shifts attention from cluster topology to API behavior, concurrency, and the path from volatile memory toward durability. Start with a hash map for expected $O(1)$ operations, then discuss sharded locks or a concurrent map so unrelated keys do not block one another. TTLs introduce clock and cleanup concerns, while persistence introduces a WAL, snapshots, or both. The key framing question is whether the store is merely a process-local cache or must recover acknowledged writes after restart. If it must recover, the design needs explicit ordering between memory mutation, log append, flush, and acknowledgement.

Common pitfalls

Pitfall: Saying “use consistent hashing” without explaining replication, ownership, and rebalancing leaves the core availability problem unsolved. Describe virtual nodes, replica placement across zones, bounded data movement, and what happens while ownership changes.

Pitfall: Treating $W+R>N$ as a universal strong-consistency guarantee is analytically wrong. Quorums overlap, but stale replicas, concurrent writes, clock skew, and conflict resolution still require a defined protocol and read-repair or hinted handoff.

Pitfall: Listing Kafka, Raft, LSM trees, and multi-region replication without prioritizing requirements sounds like technology name-dropping. State assumptions first, choose the simplest architecture that meets them, then identify the next bottleneck or failure mode you would investigate.

Connections

The interviewer may pivot to Raft leader election, gossip-based membership, consistent hashing, WAL recovery, LSM-tree compaction, or cache invalidation. Be prepared to connect consistency choices to CAP behavior, backpressure, observability, and idempotent API design.

Further reading

• On Consistent Hashing: https://en.wikipedia.org/wiki/Consistent_hashing

• On Partitioning Strategies: https://en.wikipedia.org/wiki/Hash_table#Partitioning

• Introduction to Key-Value Stores: https://martinfowler.com/articles/rackspace-pg.html

• Read about the CAP theorem: https://en.wikipedia.org/wiki/CAP_theorem

• Overview of Operational Monitoring: https://www.datadoghq.com/blog/the-importance-of-operational-monitoring-and-observability/#monitoring-and-observability

Practice questions

Behavioral & Leadership

Focus area — With 7 years of experience, onsite behavioral answers must show ownership, ambiguity handling, impact, and clear technical trade-offs.

What's being tested

These conversations test technical ownership: whether you can take a software system from ambiguous requirements through design, implementation, operation, and improvement. They probe whether you can explain architecture clearly, make explicit tradeoffs, debug incidents, and communicate decisions to engineers and stakeholders without hiding uncertainty. LinkedIn cares because production systems are cross-team, long-lived, and user-facing; strong Software Engineers reduce operational risk while helping others make sound technical decisions.

Core knowledge

• Ownership means being accountable for the outcome, not personally implementing every task. State the problem, constraints, decision-maker, collaborators, risks, rollout plan, and measurable result; distinguish what you directly changed from what the team achieved.

• Use a STAR structure—situation, task, action, result—but make the action technically specific. Explain the system boundary, your contribution, alternatives considered, failure modes, and follow-up work instead of saying “we improved scalability.”

• For system decisions, compare latency, throughput, availability, consistency, operational complexity, and cost. For example, asynchronous work through `Kafka` improves request latency and resilience but introduces eventual consistency, retries, duplicate delivery, and harder user-visible status handling.

• Make reliability quantitative with an SLO and error budget. A 99.9% monthly availability target permits roughly 43.2 minutes of unavailability; if a release consumes the budget rapidly, pause feature work, investigate, and prioritize remediation.

• Describe incident management as a controlled loop: detect through `p99` latency or error-rate alerts, mitigate with rollback or feature flags, establish a timeline, identify the contributing factors, and track corrective actions. Separate customer impact from root cause and avoid blame.

• Explain idempotency whenever retries can repeat writes. An idempotency key stored with the operation result prevents duplicate effects; a timeout does not prove failure, so clients and workers must safely retry. Consider key expiration, concurrent requests, and partial failures.

• For backward compatibility, prefer additive API or schema changes: deploy readers before writers, support old and new fields during migration, and remove deprecated paths only after usage reaches zero. Explicitly address rolling deployments, old binaries, and rollback behavior.

• When debugging, narrow the search using observability: structured logs for request IDs, metrics for rates and percentiles, and distributed traces for cross-service timing. Correlate the first bad deployment or dependency change, then reproduce with the smallest realistic input.

• Discuss rollout safety using canaries, dark launches, feature flags, and automated rollback thresholds. A canary should compare error rate, saturation, latency, and correctness—not merely whether the process remains alive.

• Knowledge transfer is an engineering control, not just onboarding courtesy. Provide an architecture diagram, request and failure-flow walkthrough, local setup instructions, runbook, ownership boundaries, and a small scoped change; verify learning by having the teammate explain or modify the system.

• Handle disagreement with written decision records such as an ADR: state the context, requirements, options, decision, rejected alternatives, and revisit conditions. Escalate only when the disagreement affects safety, availability, compliance, or an agreed delivery constraint.

• Measure outcomes with engineering signals such as `p95`/`p99` latency, availability, deployment frequency, change-failure rate, recovery time, queue depth, and support incidents. Attribute results carefully: “`p99` fell from 900 ms to 350 ms after caching” is stronger than “performance improved.”

Worked example: Discuss Projects and Tradeoffs

For “Discuss Projects and Tradeoffs,” a strong candidate first asks which project, the scale and reliability requirements, their personal scope, and whether the interviewer wants architecture depth or leadership context. They might declare assumptions such as millions of daily requests, a 300 ms `p99` target, and an existing multi-service deployment, then organize the answer around problem and constraints, architecture, key tradeoffs, execution, and measurable outcome. They should describe the request path, storage choices, asynchronous boundaries, failure handling, observability, and rollout strategy rather than listing technologies. One explicit tradeoff could be choosing asynchronous event processing through `Kafka`: it reduces synchronous latency and isolates failures, but requires idempotent consumers, replay handling, and a strategy for eventual consistency. The candidate should explain one disagreement, how they used measurements or a prototype to resolve it, and how they kept partner teams informed. They should quantify the result with latency, availability, cost, or incident-rate changes and clarify which part they personally owned. A strong close is: “If I had more time, I would validate the assumptions under load, test regional failure, and document the migration and rollback plan.”

A second angle

For “Handle Issues and Onboard Teammates,” the same ownership principle is applied to operational ambiguity and team resilience rather than a single project narrative. Frame the issue by separating immediate mitigation from the longer-term fix, then explain how you communicated impact, assigned ownership, and recorded decisions. When onboarding, avoid giving an unstructured code tour; use a production request path, failure scenarios, runbook, and a small change to test understanding. The key constraint is safe delegation: give the teammate enough context to act independently while retaining review, monitoring, and rollback safeguards. Close with how the process reduced repeated questions, shortened incident response, or improved bus-factor risk.

Common pitfalls

Pitfall: Saying “we chose microservices for scalability” is an analytical non-answer. Name the actual bottleneck, compare a modular monolith or a single service, and explain why the selected boundary improved a measured constraint while adding deployment and debugging cost.

A communication mistake is presenting a polished success story that hides disagreement or failure. “Everyone agreed and the launch went smoothly” gives no evidence of leadership; instead, explain the competing concerns, how you made the decision legible, and what you changed after an unexpected result.

A depth mistake is naming `Kafka`, Kubernetes, or caching without explaining behavior under retries, overload, rollback, or dependency failure. The interviewer is not testing brand familiarity; be ready to trace one request, identify a failure mode, and state the mitigation and monitoring signal.

Connections

The interviewer may pivot to system design, distributed-systems failure modes, incident response, API and schema evolution, or observability. They may also ask how you prioritize reliability work when the error budget is limited or how you validate a design before committing implementation effort.

Further reading

• Site Reliability Engineering — Google’s treatment of SLOs, error budgets, incident response, and sustainable operations.

• Designing Data-Intensive Applications — practical analysis of consistency, replication, streaming, storage, and distributed-system tradeoffs.

• Accelerate — research-backed engineering delivery and reliability metrics, including deployment frequency and change-failure rate.

Practice questions

Other — 15 min

Coding & Algorithms

Focus area — High-frequency LinkedIn coding pattern and no solved-question signal, so drill heap, sort, and quickselect trade-offs.

What's being tested

These problems test top-k selection: choosing a bounded set of best candidates without fully sorting all input. You must recognize when to use a size-k heap, BST traversal, quickselect, or a heap-backed streaming design, then explain correctness, tie-breaking, and complexity.

Patterns & templates

• Size-k min-heap for k-th largest or top-k values: push each item, pop when size exceeds k; O(n log k) time and O(k) space.

• Size-k max-heap for k smallest or closest candidates; define the root as the worst retained item so replacement is constant-time.

• For k closest BST values, use inorder traversal’s sorted order with two pointers, predecessor/successor stacks, or a bounded heap; handle duplicates and target ties explicitly.

• Quickselect finds the k-th order statistic in average O(n) time and O(1) auxiliary space, but worst-case O(n²) requires randomized pivots or median-of-medians.

• For sorted output, separate selection from presentation: extract heap contents and sort them, adding O(k log k) after O(n log k) selection.

• State edge conditions before coding: k <= 0, k > n, empty input, duplicate values, non-integer targets, and whether “closest” means absolute distance.

• For k-pair generation, seed a min-heap with one candidate per row and advance the smallest pair’s row pointer; avoid inserting duplicate states.

Common pitfalls

Pitfall: Sorting everything for a top-k request works but misses the intended O(n log k) solution and wastes memory when k << n.

Pitfall: Using the wrong heap polarity or comparing only values can discard the better candidate when distances tie; encode the full ordering key.

Pitfall: Claiming quickselect is always linear; distinguish average-case O(n) from worst-case O(n²) and explain when deterministic behavior matters.

Practice these

The practice cards below cover the canonical variants—solve all of them and time yourself.

Practice questions

Common across rounds, but no specific weakness was flagged; maintain fluency in DFS, BFS, recursion, and topological ordering.

What's being tested

These problems test recursive traversal and iterative stack/queue equivalents across nested lists, trees, grids, and graphs. You must model relationships correctly, track depth or distance, avoid revisiting nodes, and choose DFS, BFS, or BST-specific traversal based on the required result.

Patterns & templates

• Nested-list depth aggregation — compute maximum depth first, then apply inverse-depth weights; use recursion or an explicit stack when nesting may exceed call-stack limits.

• DFS connected components — scan every grid cell, launch DFS on unvisited land, and mark during traversal; runs in O(rows × cols) time and O(rows × cols) space.

• BFS shortest path — for unweighted graphs, process nodes by levels with a queue; the first visit gives fewest edges, including distance 0 for identical endpoints.

• Visited-state design — mutate the grid, use a boolean matrix, or maintain a hash set; distinguish “seen” from “fully processed” for directed graphs.

• DAG distance computation — topologically order vertices, initialize source distance to 0, and relax outgoing edges; unreachable targets remain -1.

• Canonical island shapes — record coordinates relative to an anchor, then normalize or serialize each shape; translation-equivalent islands share one representation.

• BST closest values — exploit inorder sortedness with predecessor/successor stacks, or maintain a bounded heap; compare absolute differences and handle duplicates consistently.

Common pitfalls

Pitfall: Treating diagonal grid cells as adjacent when the contract specifies four-directional movement, or vice versa.

Pitfall: Using DFS for shortest unweighted distance without tracking levels; DFS finds a path, not necessarily the fewest edges.

Pitfall: Forgetting cycles, duplicate values, empty inputs, disconnected components, or recursion-depth limits in skewed trees and deeply nested lists.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions