← 회사 목록

Companies

Microsoft

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

Overview

Microsoft의 Data Engineer 채용 프로세스는 리크루터 콜부터 오퍼까지 보통 4~8주가 걸리며, Google보다는 빠르고 Amazon과는 비슷한 속도라는 것이 필자의 관찰이다. 온사이트는 'AA(As-Appropriate) Loop'라 불리는데, 라운드 수를 미리 확정하지 않고 팀의 판단이 갈리면 라운드를 추가하는 유연한 구조다. 모든 시스템 설계 질문은 Azure 스택(ADF, Databricks, Synapse, Event Hubs, Fabric 등)을 전제로 하며, 문화 평가 축으로는 Satya Nadella가 강조한 'Growth Mindset'이 전 라운드에 걸쳐 반영된다.

Timeline

# 단계 형식 소요 시간 평가 항목
1 Recruiter Screen Phone call 30 min Role fit, level calibration, team context
2 Technical Phone Screen Video call, 종종 hiring manager가 직접 진행 60 min SQL + data concepts
3 The AA Loop 4~5 rounds, 45~60 min each 1 day SQL, Coding, System Design, Growth Mindset, HM
4 AA Add-On Rounds 선택적, 45 min each 당일 또는 48시간 내 콜백 루프 결과가 갈릴 때 추가 시그널 확보
5 Hire/No-Hire Decision Internal 3~7 영업일 Hiring manager + interviewer 싱크

Rounds

1 SQL and Data Analysis 공유 에디터에서 라이브 코딩, T-SQL이 선호되는 방언(PostgreSQL/MySQL과 미묘하지만 중요한 문법 차이가 있음)

Focus Areas

다중 조인 + 집계/필터링윈도우 함수(ROW_NUMBER, RANK, LAG, LEAD, SUM OVER)가독성을 위한 CTE — Microsoft 리뷰어는 영리한 한 줄 쿼리보다 계층화된 명확한 쿼리를 선호쿼리 최적화(인덱스, 파티션 프루닝, 통계)T-SQL 특유 문법(CROSS/OUTER APPLY, MERGE, 테이블 변수 vs 임시 테이블)영업/고객/제품 분석 등 엔터프라이즈 비즈니스 시나리오로 포장된 문제

Sample Question

order_id, customer_id, product_id, sale_amount, order_date 컬럼을 가진 sales 테이블이 있다. 2025년 기준 고객별 매출 상위 3개 제품을 찾고, 그 각 제품이 해당 고객 전체 매출에서 차지하는 비율(%)을 계산하라.

Solution Approach

고객 파티션 기준 ROW_NUMBER 또는 RANK로 top-N-per-group을 구한 뒤 rank 1~3으로 필터링하고, 윈도우 SUM으로 비율을 계산하는 전형적인 top-N + per-row percentage 문제다.

이렇게 말하면 좋다

"top 3라는 요구사항상 동점이 생기면 3개보다 많은 행이 나올 수 있어 RANK보다 ROW_NUMBER를 쓰겠습니다. 정확히 3개를 원하시나요, 동점도 포함해야 하나요?"처럼 코딩 전에 명확화 질문을 던진다.

피해야 할 답변

"저는 보통 이런 건 pandas로 처리합니다" — Microsoft는 프로덕션 SQL 작성 능력을 기대하며, pandas는 기본값이 아니라 대안일 뿐이다.

Common Mistakes

  • 질문에 Azure SQL이나 Synapse가 명시됐는데 PostgreSQL/MySQL 문법을 쓴다 — 차이는 사소하지만 인터뷰어는 알아챈다
  • 마지막에 최적화(인덱스, 파티션 컬럼, 쿼리 플랜)를 언급하지 않고 넘어간다
  • NULL 케이스(예: 매출이 없는 고객은 어떻게 되는지)를 확인하지 않는다
2 Coding in Python 라이브 Python 코딩, 종종 Azure Databricks나 Azure Function에서 어떻게 동작할지에 대한 논의가 함께 진행됨

Focus Areas

실전 DE Python — 파일 파싱, 딕셔너리 조작, 중첩 JSON 처리Databricks 위 PySpark 패턴 — DataFrame, groupby, join, broadcastADF 커스텀 액티비티 및 Azure Functions에 대한 인지에러 처리, 재시도, 멱등성(idempotency)

Sample Question

고객 거래 레코드가 담긴 일일 JSON 파일을 받는데, 각 레코드는 중첩된 'line_items' 배열을 가진다. customer_id, transaction_id, item_id, quantity, price를 가진 line-item 단위 평탄화(flat) 레코드를 생성하는 Python 함수를 작성하라. 손상된(malformed) 레코드는 전체 잡을 실패시키지 말고 로그를 남긴 뒤 건너뛰도록 처리하라.

Solution Approach

레코드를 순회하며 구조를 검증하고, 중첩 배열을 평탄화하며, 손상된 레코드는 위치와 함께 로깅한 뒤 처리를 계속 진행하는 방식으로 접근한다.

이렇게 말하면 좋다

"코드를 쓰기 전에 확인하고 싶은데, '건너뛴다'고 하셨을 때 건너뛴 레코드 수를 함수 반환값에 포함해야 하나요, 아니면 로그만 남기면 될까요? 프로덕션이라면 모니터링을 위한 카운트 메트릭을 남기겠습니다." — 운영 관점을 드러내는 질문이다.

피해야 할 답변

"입력을 그냥 신뢰하고 잘못된 데이터가 있으면 실패하게 두겠습니다" — 데이터가 실제로 깨끗하더라도 이 답변 자체가 감점 요인이다. Microsoft는 프로덕션 현실을 고려한 설계를 보고자 한다.

Common Mistakes

  • 데이터 볼륨이 크다는 맥락이 있는데도 PySpark 관점("프로덕션이라면 유사한 로직을 DataFrame API로 Databricks에서 PySpark 잡으로 짜겠다")을 언급하지 않는다
  • 평탄화 로직과 IO를 분리하지 않는다 — Microsoft 리뷰어는 테스트 가능한 함수를 중시한다
  • 재시도를 고려하지 않는다 — Azure Function 스타일 실행이라면 멱등성을 언급해야 한다
3 System Design with Azure 화이트보드(또는 가상 화이트보드) — Azure 서비스로 데이터 파이프라인/분석 플랫폼을 설계

Focus Areas

Azure 네이티브 용어로 사고하는지설계 전 명확화 질문을 던지는지파이프라인 각 레이어에 맞는 Azure 서비스를 아는지Microsoft Fabric(신규 통합 데이터 플랫폼)에 대한 최신 지식

Sample Question

"엔터프라이즈 텔레메트리 플랫폼을 위한 실시간 분석 파이프라인을 설계하라" / "Microsoft Teams 사용량 분석을 위한 데이터 인프라를 설계하라" / "5,000개 매장의 소매 POS 데이터를 수집해 시간 단위 재고 대시보드를 만드는 시스템을 설계하라"

Solution Approach

레이어별로 맞는 Azure 서비스를 매핑해 설명한다 — 스트림 수집은 Event Hubs, 배치 수집은 ADF, 스트림/배치 처리는 Databricks(가벼운 스트림 처리는 Stream Analytics), 원본 저장은 ADLS Gen2, 웨어하우스는 Synapse 또는 Fabric Warehouse, 오케스트레이션은 ADF/Databricks Workflows, 테이블 포맷은 기본적으로 Delta Lake를 쓴다. Microsoft Fabric(OneLake, Direct Lake mode, Fabric notebooks)을 언급하면 최신 지식이 있다는 신호로 특히 잘 받아들여진다는 것이 필자의 관찰이다.

이렇게 말하면 좋다

"데이터 볼륨은 얼마나 되나요? 지연 목표는? 그린필드 Azure 배포인가요, 아니면 기존 온프레미스 시스템과 통합하는 건가요?" — 특히 온프레미스 통합 여부를 묻는 질문은 Microsoft 고객군이 엔터프라이즈에 치우쳐 있어 좋은 반응을 얻는다는 것이 필자의 경험이다.

피해야 할 답변

"AWS라면 Kinesis를 쓰겠지만 여기서는 그에 대응하는 게 Event Hubs입니다"처럼 AWS 프레이밍을 먼저 내세우지 말 것. "파티션 모델 때문에 Event Hubs를 쓰겠습니다. 이전 팀에서 Kinesis를 써봤는데 설계 패턴은 비슷합니다"처럼 Azure 답변을 먼저 제시하고 타 클라우드 경험은 보조적으로 언급하는 편이 낫다.

Common Mistakes

  • "메시지 브로커를 쓰겠다" 같은 클라우드 중립적 답변 — Microsoft는 Azure DE를 채용한다
  • Microsoft Fabric을 모른다 — 직접 써본 적이 없어도 OneLake가 무엇이고 Direct Lake가 왜 중요한지는 알아야 한다
  • 비용 언급을 생략한다 — Synapse의 슬롯 스케일링, Databricks의 DBU 소비, Event Hubs의 throughput unit 등을 언급하지 않는다
4 Growth Mindset / Behavioral 순수 행동 인터뷰이지만 Microsoft 특유의 색채 — 인터뷰어가 3~5개의 스토리를 후속 질문과 함께 물어봄

Focus Areas

Growth Mindset — 실패를 솔직하고 구체적으로 이야기할 수 있는지학습 민첩성 — 새 기술을 빠르게 습득한 경험을 설명할 수 있는지고객 공감 — 본인의 데이터 작업이 최종 사용자에게 미치는 영향을 이해하는지협업 — Microsoft는 팀 지향적 문화가 강해 "혼자 해냈다" 스토리는 점수가 낮다

Sample Question

"실패했던 경험과 거기서 배운 것을 말해달라" / "문제를 해결하기 위해 새 기술을 빠르게 배워야 했던 경험을 설명하라" / "동료와 의견이 갈렸던 경험과 어떻게 처리했는지" / "데이터 엔지니어링 실무 트렌드를 어떻게 따라가는지" / "고객에게 잘못된 결과물을 전달했던 경험과 그때 무엇을 했는지"

Solution Approach

Microsoft는 모든 루프에서 이 실패 스토리 질문을 던진다. 잘 답하는 지원자는 명확한 실패, 명확한 교훈, 구체적인 행동 변화까지 이야기한다. 필자의 관찰로는 구조상 상황 설명(15%)-결정/행동(30%)-실패(20%, 구체적이고 가능하면 정량적으로)-교훈(20%, 일반론이 아니게)-변화(15%, 실제로 다르게 행동한 예시 포함) 비중이 효과적이다. "시간 관리로 어려움을 겪었다" 식의 모호한 답변은 진짜 실패 스토리가 아니라 사실상 자기자랑(humblebrag)으로 읽힌다는 것이 필자의 지적이다.

이렇게 말하면 좋다

실제로 있었던 구체적인 기술적 실패(잘못된 아키텍처 선택, 실제 사용자 문제를 해결하지 못한 파이프라인, 잘못된 데이터 품질 판단 등)를 방어적이지 않게 이야기한다.

피해야 할 답변

"딱히 실패 스토리가 없습니다. 운이 좋았던 편이에요" — Growth Mindset 라운드를 가장 빠르게 망치는 답변이다. Microsoft는 고정 마인드셋(fixed mindset)을 명시적으로 걸러내며, "실패한 적이 없다"는 모든 인터뷰어에게 고정 마인드셋 신호로 읽힌다.

Common Mistakes

  • 진짜 실패를 말하지 못한다 — "실패 스토리가 딱히 없다"는 사실상 확정적 탈락 신호
  • 학습 답변이 일반적이다 — "블로그를 많이 읽는다"보다 "Databricks Engineer 자격증 교재 3~7장을 공부하고 Delta Live Tables로 작은 프로젝트를 만들었다"처럼 구체적이어야 한다
  • 타인 탓을 한다 — PM이 요구사항을 잘못 정리했더라도 "요구사항 검토 단계에서 그 간극을 더 일찍 잡았어야 했다"는 식으로 본인 책임으로 프레이밍해야 Growth Mindset과 부합한다
  • 행동 변화의 구체적 사례가 없다 — 반성만 하고 실제로 다르게 행동한 예시가 없으면 스토리가 설득력을 얻지 못한다
5 Hiring Manager 기술과 문화가 섞인 라운드 — HM이 팀 적합성, 성장 궤적, 프로젝트 관심도를 평가

Focus Areas

왜 이 팀인가, 왜 이 프로젝트인가 — 구체적이고 사전 조사된 답변이 필요향후 2년간 어떤 방향으로 성장하고 싶은지PM, 사이언티스트, 다른 엔지니어와 어떻게 협업하는지팀이 실제로 다루는 주제에 대한 기술적 깊이

Sample Question

"왜 이 팀인가?" / "향후 2년간 어떤 방향으로 성장하고 싶은가?" / "PM, 사이언티스트, 다른 엔지니어와 어떻게 협업하는가?"

Solution Approach

"왜 이 팀인가"는 타협 불가능한 질문이다. Microsoft는 조직이 아니라 팀 단위로 채용하므로, "데이터 관련이라면 뭐든 열려 있다"는 답변은 이 팀에 실제로 관심이 없다는 신호로 읽혀 HM이 통과시키지 않을 수 있다. 이 라운드는 Google보다 Microsoft에서 더 비중 있게 다뤄지는데, HM이 채용 결정에 실질적인 발언권을 갖기 때문이라는 것이 필자의 설명이다.

이렇게 말하면 좋다

"팀의 최근 블로그 글을 찾아봤는데 온프레미스 SSIS에서 ADF와 Fabric으로 마이그레이션 중이시더군요. 이전 직장에서 비슷한 마이그레이션을 해봤고, 그 과정에서 나오는 스키마 진화 이슈에 특히 관심이 있습니다"처럼 구체적으로 답한다.

피해야 할 답변

"Microsoft는 훌륭한 회사고 여기서 일하고 싶습니다" — 일반적인 답변은 밋밋하게 받아들여진다.

Common Mistakes

  • "어디든 열려 있다"는 식으로 답해 이 팀에 대한 관심 부족을 드러낸다
  • "Microsoft에서 일하고 싶다"는 일반론에 그치고 특정 팀/프로젝트를 언급하지 않는다

Culture — Growth Mindset

필자의 관찰로는 전체 평가에서 약 25%를 차지하며, 전용 라운드(4번 라운드) 외에 다른 모든 라운드에도 스며들어 평가된다. 기술 라운드가 아무리 좋아도 이 신호가 약하면 탈락할 수 있다는 것이 필자의 강조점이다.

Satya Nadella의 표현으로는 "learn-it-all이 know-it-all을 이긴다"는 원칙이며, 인터뷰어는 세 가지를 평가한다: 실패에서 배우는가(문제가 생겼을 때 성찰하는가, 아니면 교훈 없이 그냥 넘어가는가), 새 기술에 호기심이 있는가(요청받지 않아도 새 도구를 시도하고 논문·블로그를 자발적으로 읽는가), 고객 공감이 있는가(본인이 만드는 데이터의 실제 사용자를 이해하고 그 니즈에 기반해 결정하는가).

Prep Strategy

Key Takeaways