← 회사 목록

Companies

LinkedIn

LinkedIn Data Engineer Interview Questions & Process (2026) — docs/LinkedIn Data Engineer Interview Questions & Process (2026).pdf

Overview

LinkedIn의 Data Engineer 채용 프로세스는 리크루터 콜부터 오퍼까지 업계 데이터 기준 약 33일 정도가 걸리는 것으로 알려져 있으며, Amazon·Stripe보다는 길고 Google과는 비슷한 수준이라는 것이 필자의 관찰이다. 6~8라운드로 구성되어 업계에서 가장 긴 축에 속하는 온사이트가 특징이며, 그중 DSA(자료구조·알고리즘) 라운드와 확률·A/B 테스트를 다루는 통계 라운드는 다른 회사의 표준 DE 인터뷰에는 잘 없는 구성이라 방심한 지원자를 자주 걸러낸다. LinkedIn은 Kafka, Samza, Apache Pinot을 자체 개발한 인프라 원조 회사라, 시스템 설계 라운드에서는 이 기술 스택에 대한 깊은 이해를 기대한다.

Timeline

# 단계 형식 소요 시간 평가 항목
1 Recruiter Screen Phone call 30 min Role fit, comp expectations, basic background
2 Technical Phone Screen Video call 60 min SQL + coding fundamentals
3 Onsite Loop 6~8 rounds, 45 min each (하루 또는 이틀에 분산) 1~2일 SQL, DSA, Coding, Data Modeling, System Design, Statistics, Behavioral, (선택) HM
4 Team Matching 복수의 콜(HM 2~4명) 1~2주 Hiring manager 콜, 팀 적합성 대화
5 Offer & Negotiation 비동기 + 콜 3~5 영업일 오퍼, 협상, 결정

Rounds

1 SQL 공유 에디터에서 라이브 SQL, 인터뷰어가 스키마를 주고 2~3문항 질문 — 스키마는 거의 항상 커넥션, 채용 공고, 메시지, 피드 이벤트 등 프로페셔널 네트워크 데이터

Focus Areas

윈도우 함수와 랭킹 — 그룹별 top-N, 사용자별 최신 레코드, 누적합그래프 인접(graph-adjacent) SQL — "커넥션 그래프에서 2홉 떨어진 사람 찾기" 같은 LinkedIn 특유 유형퍼널 분석 — 노출→클릭→지원→면접→채용 등 다단계 이벤트 시퀀싱A/B 테스트 지표 계산 — 처리군 vs 대조군, lift, 세그먼트별 차이피드 참여, 채용 지원 퍼널, 커넥션 그래프 분석, 메시징 활동 등이 주요 테마

Sample Question

(user_id, connected_user_id) 형태의 직접 커넥션을 나타내는 connections 테이블이 있다. 각 사용자에 대해, 본인의 직접 커넥션을 제외한 고유한 2차(friends-of-friends) 커넥션 수를 구하는 쿼리를 작성하라.

Solution Approach

connections 테이블을 자기 자신과 셀프 조인해 2차 관계 쌍으로 확장한 뒤, 기존 직접 커넥션을 안티 조인으로 제외하고, COUNT(DISTINCT)로 그룹핑하는 방식이 깔끔한 답이다. 재귀 CTE로 접근하는 지원자는 고정 깊이(2홉) 순회에는 과도한 방식이라 대개 시간이 부족해진다.

이렇게 말하면 좋다

"connections 테이블을 셀프 조인해서 2차 쌍으로 확장한 다음, 기존 직접 커넥션을 안티 조인으로 제외하고, 사용자별로 distinct count를 세겠습니다"처럼 코드를 쓰기 전에 구조를 먼저 말로 설명한다.

피해야 할 답변

"코드에서 그래프로 모델링하겠습니다" — LinkedIn이 보고 싶은 것은 SQL 안에서 그래프 쿼리를 해낼 수 있는지이며, 그 자체가 이 질문의 핵심이다.

Common Mistakes

  • 2차 확장 시 자기 자신으로 돌아오는 경로(A→B→A)를 제외하지 않는다 — 이는 유효한 2차 커넥션이 아니다
  • 필요한 곳에 COUNT(DISTINCT)를 쓰지 않아 경로 중복 문제가 생긴다
  • 커넥션이 (A,B)와 (B,A) 양방향으로 저장되는지 단방향인지 방향성 논의를 생략한다 — 반드시 확인 질문을 던져야 한다
2 DSA (Data Structures and Algorithms) 공유 에디터에서 라이브 코딩, 보통 LeetCode-medium 1문항, Python 선호(Java도 허용)

Focus Areas

배열과 해시맵 — 가장 흔한 카테고리문자열 — 팰린드롬 체크, 서브스트링 문제, 슬라이딩 윈도우투 포인터 — 정렬된 배열 문제, in-place 연산트리와 그래프 — BFS, DFS, 레벨 순회 (빈도는 낮지만 실제로 나옴)가끔: 힙, 인터벌, 동적 계획법(DE 치고는 드묾)

Sample Question

정수 리스트와 목표 합(target sum)이 주어질 때, 합이 target이 되는 모든 고유한 숫자 쌍을 반환하라. 리스트에는 중복값이 있을 수 있다. 각 쌍은 한 번만, 오름차순으로 정렬해 반환하라.

Solution Approach

Two Sum의 LeetCode-medium 변형이다. 해시셋으로 이미 본 값을 추적하고 결과셋으로 쌍의 중복을 제거하는 방식(또는 정렬 + 투 포인터)이 깔끔한 접근이다. 브루트포스 O(n²) 중첩 루프로 접근하는 지원자는 정확성 기준은 통과하지만 최적화 점수에서 감점된다.

이렇게 말하면 좋다

문제를 자신의 말로 재진술하고, 예시를 손으로 따라가보고, 브루트포스 접근과 복잡도를 먼저 말한 뒤, 최적화 방안을 제안하고 왜 동작하는지 설명한 다음, 코드를 작성하며 계속 설명하고, 마지막에 예시로 테스트한 뒤 엣지 케이스를 검토한다.

피해야 할 답변

"이거 외운 문제예요" — 설령 외웠더라도 모르는 척하는 편이 낫다. 인터뷰어는 추론 과정을 보고 싶어 하며, 암기한 패턴 매칭은 얕은 인상을 준다.

Common Mistakes

  • 코딩 중 침묵한다 — 사실상 자동 탈락 신호이므로 계속 말로 설명해야 한다
  • 마지막에 코드를 테스트하지 않는다 — 예시를 머릿속으로라도 다시 실행해봐야 한다
  • 엣지 케이스를 놓친다 — 빈 리스트, 원소 1개, 전부 중복, 음수 등
  • 조급하게 최적화부터 시도한다 — 먼저 동작하는 해를 만들고 그다음 최적화해야 한다
3 Coding in Python or Java 라이브 코딩, DSA 라운드보다 DE 색채가 강함 — 순수 알고리즘이 아니라 실전 데이터 처리

Focus Areas

데이터 변환 — 지저분한 이벤트 로그를 재구성해 깨끗한 레코드로 만들기엣지 케이스가 있는 파일 파싱 — 깨진 행이 있는 CSV, 중첩 구조가 있는 JSON상태 유지 집계 — 이벤트 스트림을 처리하며 엔티티별 현재 상태 반환가끔 Spark 패턴(PySpark 또는 Spark Scala)

Sample Question

user_id, event_type(impression, click, share, like, hide), content_id, timestamp를 가진 피드 이벤트 스트림이 있다. 각 사용자에 대해, 별도의 룩업 테이블에 있는 콘텐츠 소스 카테고리별 클릭률(클릭/노출)을 계산하는 함수를 작성하라.

Solution Approach

스트림과 참조 데이터를 조인하고, 비율 지표를 정확히 계산하며, 노출은 있지만 클릭이 없는 사용자를 처리(CTR=0, undefined 아님)하고, 룩업 테이블의 엣지 케이스(카테고리 누락)까지 다루는 것이 핵심이다. LinkedIn은 이 라운드에서 클린하고 가독성 높은 코드를 중시하며, 영리한 한 줄 코드보다 작은 헬퍼 함수 여러 개로 나누고 설명적인 변수명을 쓰는 지원자가 더 좋은 평가를 받는다.

이렇게 말하면 좋다

각 헬퍼 함수에 docstring을 붙이며 4~5개의 작은 함수로 구조화하는 방식이 하나의 40줄짜리 블록보다 더 좋은 인상을 준다는 것을 인지하고 그렇게 코딩한다.

Common Mistakes

  • 노출은 있지만 클릭이 없는 사용자의 CTR을 0이 아니라 undefined/에러로 처리한다
  • 룩업 테이블에 카테고리가 없는 경우를 처리하지 않는다
  • 하나의 큰 함수로 몰아 써서 가독성과 테스트 용이성을 떨어뜨린다
4 Data Modeling 화이트보드(또는 가상 화이트보드) — LinkedIn 특유의 유스케이스에 대한 데이터 모델을 설계

Focus Areas

프로페셔널 네트워크 플랫폼을 위한 차원 모델링커넥션 그래프 데이터 모델 — 네트워크를 효율적으로 저장·쿼리하는 방법채용 마켓플레이스 모델 — 공고, 지원, 리크루터 활동피드 이벤트 모델 — 노출, 참여, 콘텐츠 메타데이터멤버 프로필을 위한 Slowly Changing Dimension — 직함, 회사, 지역이 시간에 따라 변함

Sample Question

"LinkedIn 피드를 구동하는 데이터 모델을 설계하라. 멤버는 게시물을 보고, 좋아요, 댓글, 공유를 한다. 실시간 참여 카운트와 히스토리컬 분석을 모두 지원해야 한다." / "'People You May Know(PYMK)'의 데이터 모델을 설계하라. 무엇을 저장하고, 어떻게 갱신하며, LinkedIn 규모에서 어떻게 서빙하는가?" / "리크루터 분석(누가 내 공고를 봤는지)과 지원자 분석(어디에 지원했고 응답 시간은 어땠는지)을 모두 지원하는 채용 마켓플레이스 데이터 모델을 설계하라."

Solution Approach

커넥션 그래프 저장(adjacency list vs adjacency matrix vs edge table, LinkedIn 규모인 9억+ 멤버 기준 트레이드오프), 멤버 프로필 변경을 위한 SCD Type 2, 원본 진실은 raw 이벤트로 두고 분석 성능을 위해 일/주 단위로 집계하는 활동/이벤트 grain, 이 데이터에 대한 스타 스키마 vs 스노우플레이크 선택 등을 다룰 줄 알아야 한다.

이렇게 말하면 좋다

"이 모델이 어떤 질문에 답해야 하나요?"로 쿼리부터 시작한 뒤, "이 팩트 테이블의 한 행은 한 멤버가 하나의 콘텐츠에 대해 발생시킨 하나의 피드 노출을 의미합니다"처럼 grain을 명확히 진술한다.

피해야 할 답변

"그냥 그래프 데이터베이스를 쓰겠습니다" — LinkedIn은 SQL과 Kafka 중심의 자체 그래프 시스템을 쓰는 회사이므로, 이런 배경 인지 없이 Neo4j를 언급하면 스택을 조사하지 않았다는 신호로 읽힌다.

Common Mistakes

  • 쿼리 요구사항을 먼저 확인하지 않고 바로 테이블 설계로 들어간다
  • grain을 명시적으로 진술하지 않는다
  • LinkedIn의 실제 스택(SQL + Kafka + 자체 그래프 시스템)을 인지하지 못한 채 범용 그래프 DB를 기본값으로 제안한다
5 System Design 화이트보드 — LinkedIn 규모의 문제를 위한 데이터 파이프라인을 설계

Focus Areas

9억+ 멤버, 하루 수십억 피드 이벤트 규모에서의 설계 능력LinkedIn의 데이터 스택(Kafka, Samza, Pinot, Spark, HDFS)에 대한 이해스트리밍 + 배치 하이브리드 설계장애 처리, 스키마 진화, 데이터 품질

Sample Question

"LinkedIn 뉴스 피드를 구동하는 데이터 파이프라인을 설계하라. 실시간 랭킹, 하루 수십억 노출." / "People You May Know를 위한 데이터 인프라를 설계하라. 9억 멤버에 대한 friend-of-friend 추천을 계산하라." / "채용 추천을 구동하는 시스템을 설계하라. 멤버 활동의 실시간 신호와 배치로 계산된 프로필 피처를 함께 사용한다."

Solution Approach

요구사항 수집(기능/비기능, 볼륨, 지연, 소비 주체, 5~7분) → 어림 추정(9억 멤버, DAU, 멤버당 하루 평균 이벤트 수로 숫자에 근거를 두기, 3~5분) → 상위 아키텍처(수집→스트리밍/배치→저장→서빙, LinkedIn 네이티브 서비스명을 명시, 10~15분) → 심화(장애 처리, 스키마 진화, 지연 도착 데이터, 백필, 15~20분) → 트레이드오프(예: "수십억 행 테이블에 서브초 쿼리가 필요해 실시간 서빙 레이어로 Pinot을 선택했다. 분 단위 지연이면 충분하다면 Druid나 Spark 기반 웨어하우스로도 충분했을 것이다", 5분) 순서로 진행한다. 핵심 LinkedIn 네이티브 기술: Apache Kafka(LinkedIn이 만든 기술 — 파티셔닝, 컨슈머 그룹, exactly-once 시맨틱스, 스키마 레지스트리를 깊이 알아야 함), Apache Samza(LinkedIn이 만든 스트림 프로세서, 내부적으로 많이 쓰임 — 아는 지원자가 드물어 언급하면 신뢰도가 크게 오름), Apache Pinot(LinkedIn이 만든 실시간 OLAP 데이터베이스, 피드/리크루터 분석과 실시간 대시보드를 구동, 수십억 행 테이블에서 100ms 이내 저지연 집계 쿼리에 특화), Espresso(LinkedIn의 자체 NoSQL 스토어 — 내부 구조까지는 몰라도 존재를 아는 것만으로 조사했다는 신호), Spark(배치 워크호스, 일별 연산 레이어), HDFS(히스토리컬 데이터 레이크).

이렇게 말하면 좋다

"피드 이벤트를 Kafka로 emit하고, Samza로 실시간 보강(enrichment)을 수행하고, 서브초 피드 분석 쿼리를 위해 Pinot에 집계를 기록하고, 백필을 위해 HDFS 위에서 매일 Spark 잡을 돌리겠습니다"처럼 LinkedIn 네이티브 스택을 구체적으로 조합해 답한다.

피해야 할 답변

"Snowflake를 쓰겠습니다" — LinkedIn은 Snowflake를 쓰지 않고 자체 스택을 운영한다. 이 배경을 인지하지 못한 채 Snowflake를 언급하면 조사 부족 신호로 읽힌다.

Common Mistakes

  • LinkedIn 네이티브 기술(Kafka, Samza, Pinot)을 몰라 범용적인 대안(Snowflake, 일반 메시지 큐 등)만 언급한다
  • 장애 모드, 스키마 진화, 지연 도착 데이터 등 운영 관점을 깊이 다루지 않는다
  • 숫자에 근거하지 않고(9억 멤버, DAU 등) 막연하게 설계한다
6 Statistics / Quantitative 대화형 — 인터뷰어가 통계 문제 2~3개를 던지고 추론 과정을 파고듦, 코딩 없음, 가끔 어림 계산

Focus Areas

확률 기초 — 조건부 확률, 베이즈 정리분포 — 정규/이항/포아송을 언제 적용하고 왜 중요한지A/B 테스트 — 귀무가설, p-value, 신뢰구간, 통계적 유의성표본 크기 — 표본이 작으면 왜 결과 신뢰도가 낮아지는지, 필요한 표본 크기를 어떻게 계산하는지실전 추론 — "5% lift와 p-value 0.08인 기능을 출시하겠는가?" 같은 판단 문제

Sample Question

"피드 랭킹에 대한 A/B 테스트를 진행했다. 처리군은 CTR에서 3% lift를 보였고 p-value는 0.04다. 대조군은 10만 명, 처리군도 10만 명이다. 출시해야 하는가? 결정 전에 어떤 추가 질문을 던지겠는가?" / "베이즈 정리를 실제 예시로 설명하라. 계정의 5%를 플래그하는 사기 탐지 시스템이 있고, 플래그된 계정의 95%가 실제로 사기라고 하자. 사기 기본 발생률(base rate)이 1%일 때, 플래그된 계정이 실제로 사기일 확률은?" / "p-value와 신뢰구간의 차이는 무엇인가? 언제 하나를 다른 것보다 선호해 보고하겠는가?"

Solution Approach

"먼저 문제를 세팅하겠습니다. 두 가설이 있습니다..."처럼 소리 내어 추론 과정을 설명하는 것이 핵심이다. 통계 라운드는 정답 자체만큼이나 사고의 명료함을 평가한다.

이렇게 말하면 좋다

가설 설정부터 소리 내어 말하며 단계적으로 풀어나간다.

피해야 할 답변

"그냥 A/B 테스트 툴이 주는 결과를 신뢰하겠습니다" — LinkedIn은 대시보드를 소비하는 것이 아니라 수학 자체를 이해하는지를 보고 싶어 한다.

Common Mistakes

  • p-value를 "귀무가설이 참일 확률"로 착각한다(실제로는 P(데이터 | 귀무가설이 참)이다)
  • 출시 결정을 내리기 전에 표본 크기와 효과 크기를 확인하지 않는다
  • 동시에 여러 실험이 진행되는 시나리오에서 다중 비교 보정을 놓친다
  • 통계적 유의성과 실질적 유의성(practical significance)을 같은 것으로 취급한다
7 Behavioral / Culture 대화형 — LinkedIn의 가치(TICHER)를 중심으로 한 행동 질문

Focus Areas

Transformation — 의미 있는 변화를 주도했는가Integrity — 압박 속에서 올바른 선택을 했는가Collaboration — 팀을 넘나들며 협업했는가Humor — 지나치게 진지하지 않고 가벼움과 따뜻함이 있는가Results — 결과가 숫자로 뒷받침되는가

Sample Question

"팀이 데이터를 다루는 방식에 변화를 주도했던 경험을 말해달라." / "업무에서 integrity 트레이드오프에 직면했던 경험을 말해달라." / "경쟁하는 우선순위를 조율해야 했던 크로스펑셔널 프로젝트 경험을 말해달라." / "결과가 예상과 크게 달랐던 프로젝트 경험을 말해달라."

Solution Approach

필자가 강조하는 바로는, 제네릭한 STAR식 답변은 LinkedIn에서 통과하지 못하고 "기준은 넘지만 눈에 띄지 않는다"는 평가로 탈락한다. LinkedIn은 차별화된 스토리를 원하며, 각 스토리는 TICHER 가치 중 최소 하나 이상을 명확히 건드려야 한다.

이렇게 말하면 좋다

"각기 80%의 로직이 중복된 파이프라인 4개가 있었습니다. 한 분기 만에 이를 대체하는 공유 라이브러리를 만들었고, 유지보수 표면을 약 70% 줄였으며 더 이상 같은 조인 순서 문제로 새벽 2시에 호출받지 않게 됐습니다"처럼 구체적이고 정량화된 스토리로 Transformation과 Results를 동시에 짚으며 약간의 유머·따뜻함을 곁들인다.

피해야 할 답변

"저는 팀 플레이어입니다" 같은 일반적인 클리셰는 실패한다 — 구체적인 스토리 없이는 소용없다.

Common Mistakes

  • 제네릭한 STAR 답변에 그쳐 눈에 띄지 않는다
  • 결과를 숫자 없이 말한다 — "X를 개선했다"는 숫자가 없으면 결과로 인정받지 못한다
  • TICHER 다섯 가치 중 어느 것도 명확히 건드리지 못하는 밋밋한 스토리를 고른다
8 Hiring Manager / Cross-Functional (일부 루프에만 포함) 대화형, 행동 라운드와 유사 — LinkedIn DE 루프의 약 절반 정도에 이 추가 라운드가 포함되는 것으로 보인다는 것이 필자의 관찰

Focus Areas

커리어 목표팀에서 무엇을 찾고 있는지어떻게 협업하는지

Solution Approach

이 라운드는 팀 매칭으로 이어지므로 인터뷰이자 동시에 파트너 대화로 취급해야 한다 — 지원자도 상대 팀을 평가하는 자리이기도 하다.

Culture — TICHER (Transformation, Integrity, Collaboration, Humor, Results)

전용 행동 라운드 하나에 집중되지만, 필자의 관찰로는 다른 라운드에서도 은연중에 함께 평가되는 경향이 있다.

Transformation(의미 있는 변화를 주도했는가 — 단순 딜리버리가 아니라 임팩트 스토리), Integrity(쉬운 선택지가 있었음에도 올바른 선택을 했는가 — 압박 속 어려운 결정 스토리), Collaboration(팀을 넘나들며 일했는가 — 크로스펑셔널 파트너십 스토리), Humor(스토리라기보다 태도에 가까움 — 지나치게 진지하지 않고 가벼움과 따뜻함이 대화에 묻어나는지), Results(결과가 중요함 — 노력이 아니라 정량화된 성과)의 다섯 축으로 구성된다.

Prep Strategy

Key Takeaways