Top 40+ câu hỏi phỏng vấn Data Engineer phổ biến

Theo báo cáo của Dice 2025, nhu cầu tuyển dụng Data Engineer tại Đông Nam Á tăng hơn 40 % mỗi năm, vượt xa Data Analyst và tiệm cận Software Engineer. Doanh nghiệp hiểu rằng mô hình AI/BI dù đắt tiền cũng sẽ vô nghĩa nếu nền móng dữ liệu bẩn, phân mảnh và khó mở rộng – và đó cũng chính là lúc Data Engineer trở thành “người hùng thầm lặng” của mọi tổ chức hướng dữ liệu. Vậy nếu bạn đang chuẩn bị cho buổi phỏng vấn Data Engineer sắp tới, sau đây là các nhóm câu hỏi phỏng vấn Data Engineer bạn cần chuẩn bị để có một buổi phỏng vấn tót hơn!

Thị trường Việt Nam bắt đầu khắt khe không kém Singapore hay Ấn Độ: ứng viên Data Engineer phải “vượt ải” HackerRank/LeetCode, bài SQL nâng cao, hệ thống thiết kế data warehouse trên bảng trắng, thậm chí live‑coding PySpark hoặc Airflow DAG. Chuẩn bị kỹ lưỡng không chỉ giúp bạn tự tin, mà còn thể hiện tư duy hệ thống – yếu tố nhà tuyển dụng đánh giá cao hơn bất kỳ chứng chỉ đám mây nào.

Dưới đây là tuyển chọn những câu hỏi phỏng vấn Data Engineer thường gặp, đi kèm gợi ý trả lời ngắn gọn và sát thực tế, giúp bạn tự tin thể hiện cả kiến thức lẫn tư duy hệ thống của mình qua 6 nhóm chủ đề – cũng là 6 cụm câu hỏi thường gặp nhất:

  • Nhóm 1: Tổng quan & Kiến thức nền tảng CSDL
  • Nhóm 2: Data Architecture & ETL/ELT
  • Nhóm 3: Big Data & Streaming
  • Nhóm 4: Cloud & Workflow Orchestration
  • Nhóm 5: Lập trình & Data Quality
  • Nhóm 6: Kinh nghiệm thực chiến & Kỹ năng coding

Câu hỏi phỏng vấn Data Engineer về Tổng quan & Kiến thức nền tảng CSDL

Đây là phần giúp bạn thể hiện kiến thức căn bản về vai trò của Data Engineer, mối quan hệ với các vị trí khác trong team dữ liệu, và kỹ năng xử lý dữ liệu truyền thống như SQL hay kiến trúc hệ thống. Nhà tuyển dụng thường nhìn vào nhóm này để đánh giá tư duy nền tảng và khả năng giao tiếp kỹ thuật của bạn.

Bạn hiểu Data Engineer đóng vai trò gì trong chuỗi giá trị dữ liệu của doanh nghiệp?

Data Engineer chịu trách nhiệm xây dựng và duy trì hệ thống xử lý dữ liệu, giúp chuyển đổi dữ liệu thô thành dữ liệu sạch, có cấu trúc để cung cấp cho Data Scientist, BI Analyst, hỗ trợ quyết định kinh doanh.

Bạn thường phối hợp với Data Scientist, BI Analyst, hay DevOps như thế nào trong một dự án dữ liệu?

  • Với Data Scientist: cung cấp dữ liệu đã được làm sạch, chuẩn hóa và tổ chức hợp lý để phân tích và huấn luyện mô hình.
  • Với BI Analyst: chuẩn bị dữ liệu tối ưu hóa cho các báo cáo, dashboard.
  • Với DevOps: đảm bảo triển khai pipeline dữ liệu tự động, hiệu quả, ổn định và bảo mật.

Khi được giao thiết kế một pipeline dữ liệu mới, quy trình bạn tiếp cận và phân tích yêu cầu ra sao?

  • Xác định rõ yêu cầu nghiệp vụ và mục tiêu cần đạt.
  • Thu thập thông tin nguồn dữ liệu (dạng dữ liệu, định dạng, khối lượng).
  • Chọn công cụ và kiến trúc phù hợp (batch hoặc streaming).
  • Thiết kế mô hình lưu trữ và xử lý (schema, partitioning, indexing).
  • Triển khai kiểm thử, đánh giá hiệu năng và bảo trì hệ thống.

Bạn có thể phân biệt ngắn gọn OLTP (Online Transaction Processing) và OLAP (Online Analytical Processing)?

  • OLTP (Online Transaction Processing) là hệ thống xử lý giao dịch trực tuyến, chuyên dùng để quản lý các giao dịch thường xuyên như thêm, sửa, xoá dữ liệu trong cơ sở dữ liệu – ví dụ như hệ thống ngân hàng hoặc bán hàng.
  • OLAP (Online Analytical Processing) là hệ thống xử lý phân tích trực tuyến, được thiết kế để hỗ trợ truy vấn phân tích phức tạp, giúp tổng hợp và phân tích dữ liệu lớn nhằm phục vụ việc ra quyết định – ví dụ như báo cáo kinh doanh, phân tích xu hướng.

Điểm khác biệt chính giữa hai khái niệm này là:

Tiêu chí OLTP OLAP
Mục đích Giao dịch nhanh, thời gian thực Phân tích dữ liệu lịch sử
Kiểu dữ liệu Chi tiết, ngắn hạn Tổng hợp, dài hạn
Truy vấn CRUD đơn giản Truy vấn phân tích phức tạp

Bạn tối ưu truy vấn SQL bằng cách nào (indexing, partitioning, explain plan, caching…)?

  • Sử dụng index hợp lý.
  • Chia partition theo thời gian hoặc category.
  • Dùng EXPLAIN PLAN để phân tích truy vấn.
  • Sử dụng cache cho các truy vấn thường xuyên.

Đọc thêm: Tổng hợp 90+ function trong SQL cần biết

Trong trường hợp nào bạn ưu tiên dùng NoSQL thay vì SQL?

  • Khi dữ liệu không có cấu trúc rõ ràng hoặc cấu trúc thay đổi thường xuyên.
  • Khi cần khả năng mở rộng theo chiều ngang (horizontal scalability).
  • Khi cần thời gian đáp ứng cực nhanh (real-time).

Đọc thêm: SQL vs NoSQL: Cách chọn hệ quản trị cơ sở dữ liệu phù hợp

Câu hỏi phỏng vấn Data Engineer về Data Architecture & ETL/ELT

Khi dữ liệu bắt đầu phức tạp, bài toán không chỉ là viết truy vấn nữa – mà là thiết kế hệ thống, chọn mô hình lưu trữ, quản lý chất lượng và dòng chảy dữ liệu (data pipeline). Nhóm câu hỏi này kiểm tra khả năng thiết kế hạ tầng dữ liệu linh hoạt, có thể mở rộng, đồng thời tối ưu hiệu quả vận hành và chi phí.

So sánh sự khác biệt giữa Data Warehouse và Data Lake. Khi nào nên cân nhắc mô hình “lakehouse”?

Data Warehouse lưu trữ dữ liệu có cấu trúc và được xử lý, tối ưu cho các tác vụ phân tích chuyên sâu và báo cáo kinh doanh. Data Lake là nơi lưu trữ dữ liệu thô, chưa qua xử lý, phù hợp với dữ liệu đa dạng và linh hoạt.

Tiêu chí Data Warehouse Data Lake Lakehouse
Mục đích Phân tích dữ liệu có cấu trúc Lưu trữ dữ liệu thô Kết hợp cả hai
Dữ liệu Có cấu trúc rõ ràng Không cấu trúc hoặc bán cấu trúc Cấu trúc và bán cấu trúc
Quy trình xử lý ETL (Extract-Transform-Load) ELT (Extract-Load-Transform) ELT, hỗ trợ xử lý nhanh
Hiệu suất truy vấn Nhanh Chậm hơn Nhanh tương đương Warehouse

Lakehouse nên được cân nhắc khi doanh nghiệp cần cả sự linh hoạt của Data Lake và khả năng phân tích nhanh, mạnh mẽ của Data Warehouse.

Bạn từng gặp những khó khăn gì khi duy trì chất lượng dữ liệu trong Data Warehouse hoặc Data Lake? Bạn đã xử lý thế nào?

Gợi ý một số khó khăn phổ biến và cách xử lý:

  • Sai lệch schema (schema drift), khi cấu trúc dữ liệu thay đổi không báo trước. Giải pháp là chặn thay đổi schema trực tiếp từ các team khác, khi thay đổi cần phải có sự phê duyệt của team data hoặc phải nhờ team data hỗ trợ.
  • Dữ liệu thiếu hoặc cập nhật trễ, gây sai lệch trong báo cáo. Trường hợp này tôi sẽ trao đổi với các phòng ban để nắm bắt vấn đề, xem nút thắt cổ chai nằm ở đâu.
  • Dữ liệu trùng lặp hoặc không nhất quán, làm giảm độ tin cậy của phân tích. Trường hợp này có rất nhiều nguyên nhân cần phải điều tra kỹ hơn.
  • Khó kiểm soát lineage và nguồn gốc dữ liệu khi tích hợp từ nhiều hệ thống. Trường hợp này cần xem log hoặc thiết kế một hệ thống ETL có thể truy nguồn, ai đang upload dữ liệu gì, đây thường là dự án dài và đôi khi cần phải nâng cấp hệ thống. 

Phân biệt Star Schema và Snowflake Schema; ưu và nhược điểm của mỗi mô hình?

Tiêu chí Star Schema Snowflake Schema
Cấu trúc Một bảng fact liên kết trực tiếp nhiều bảng dimension Bảng dimension phân cấp, chi tiết hơn
Truy vấn Truy vấn nhanh, dễ viết Truy vấn phức tạp hơn
Bảo trì Dễ bảo trì Khó bảo trì hơn do cấu trúc phức tạp
Lưu trữ Dữ liệu dư thừa nhiều Ít dư thừa hơn, tiết kiệm dung lượng

Star Schema phù hợp với các ứng dụng cần truy vấn nhanh, đơn giản. Snowflake Schema thích hợp khi cần giảm dư thừa dữ liệu và tổ chức dữ liệu chi tiết.

Slowly Changing Dimensions (SCD) là gì? Bạn đã khi nào sử dụng kết hợp Type 1 và Type 2?

SCD là kỹ thuật quản lý thay đổi dữ liệu theo thời gian trong Data Warehouse.

  • Type 1: Ghi đè dữ liệu cũ, không giữ lịch sử.
  • Type 2: Tạo bản ghi mới để giữ lịch sử thay đổi.

Kết hợp Type 1 và Type 2 khi vừa cần cập nhật ngay thông tin mới (ví dụ: địa chỉ hiện tại của khách hàng), vừa cần lưu trữ lịch sử thay đổi (ví dụ: lịch sử giá bán sản phẩm).

Khi nào bạn chọn sử dụng surrogate key thay vì natural key trong thiết kế bảng Dimension?

Natural key là khóa chính được lấy từ dữ liệu thực tế có ý nghĩa nghiệp vụ, ví dụ như mã số nhân viên, số CMND.

Surrogate key là khóa thay thế không mang ý nghĩa nghiệp vụ, thường là số nguyên tự động tăng, được dùng để định danh duy nhất cho từng bản ghi trong bảng.

Khi natural key không ổn định, có khả năng thay đổi hoặc để tối ưu hiệu năng join, surrogate key là số nguyên tự tăng sẽ hiệu quả hơn. Và đôi khi cần bảo mật thông tin (ẩn natural key nhạy cảm).

Sự khác biệt chính giữa ETL và ELT trong bối cảnh các Cloud Data Warehouse như BigQuery, Snowflake, Redshift?

Tiêu chí ETL (Extract-Transform-Load) ELT (Extract-Load-Transform)
Quy trình Dữ liệu được xử lý trước khi tải vào DW Dữ liệu tải vào DW trước, sau đó mới xử lý
Tính linh hoạt Thấp hơn, phải xác định trước schema Cao hơn, xử lý sau nên linh hoạt hơn
Hiệu năng Hiệu năng xử lý tại nguồn hạn chế Tận dụng khả năng xử lý mạnh của Cloud DW

ELT được ưa chuộng hơn khi sử dụng Cloud Data Warehouse do khả năng xử lý mạnh mẽ và linh hoạt trong phân tích dữ liệu sau khi tải vào.

Bạn có kinh nghiệm gì với các công cụ ETL/ELT (Airflow, Glue, dbt…)?

Dưới đây là một số trường hợp sử dụng phổ biến của mỗi công cụ:

  • Airflow: Áp dụng để orchestrate, quản lý và lên lịch trình workflow dữ liệu.
  • Glue: Dùng trong các tác vụ tự động hóa ETL, tận dụng hạ tầng serverless.
  • dbt: Dùng để quản lý và tái sử dụng mã SQL, hỗ trợ mô hình hóa dữ liệu hiệu quả.

Bạn hãy chọn lọc các trường hợp trên để trả lời câu hỏi này, dựa trên kinh nghiệm cá nhân đã sử dụng những công cụ nào, cho mục đích gì.

Bạn đã gặp vấn đề gì về độ trễ (latency) hoặc bất đồng bộ dữ liệu khi đồng bộ từ nhiều nguồn?

Vấn đề với độ trễ dữ liệu là khi dữ liệu từ các hệ thống nguồn không đồng bộ, khiến báo cáo không cập nhật kịp thời.

Giải pháp là: Áp dụng streaming pipeline, thiết lập đồng bộ gần real-time, sử dụng các công cụ như Kafka, Spark Streaming, hay Apache Flink để giảm thiểu độ trễ; xây dựng cơ chế cảnh báo tự động khi phát hiện dữ liệu bất thường hoặc đồng bộ chậm.

Câu hỏi phỏng vấn Data Engineer về Big Data & Streaming

Khi hệ thống xử lý hàng triệu record mỗi ngày hoặc dữ liệu đến theo thời gian thực, bạn cần hiểu rõ công nghệ như Hadoop, Spark, Kafka – không chỉ lý thuyết mà là ứng dụng thực tế. Các câu hỏi trong nhóm này giúp nhà tuyển dụng đánh giá bạn có khả năng làm việc với dữ liệu lớn, xử lý phân tán và kiến trúc streaming hay không.

Bạn có thể mô tả kiến trúc Hadoop (HDFS, YARN) và mục đích của từng thành phần cốt lõi?

  • HDFS (Hadoop Distributed File System): lưu trữ dữ liệu phân tán, chịu lỗi tốt, tối ưu hóa cho truy xuất batch với dữ liệu lớn.
  • YARN (Yet Another Resource Negotiator): quản lý tài nguyên, phân phối công việc tính toán giữa các node trong cluster, tối ưu hiệu suất và độ ổn định.

Khi làm việc với Spark, bạn quan tâm những gì để tối ưu partition, shuffle, và tránh bottlenecks?

  • Xác định số lượng partitions phù hợp dựa trên kích thước dữ liệu.
  • Giảm thiểu shuffle bằng cách tối ưu hóa việc sắp xếp, aggregate dữ liệu sớm nhất.
  • Sử dụng broadcast join khi một bảng nhỏ, giúp giảm lượng shuffle.
  • Monitoring Spark UI để xác định và xử lý nhanh các bottleneck.

Bạn từng sử dụng Spark Streaming hoặc Structured Streaming chưa? Chúng có ưu/nhược điểm gì?

  • Spark Streaming: Xử lý micro-batch, tích hợp dễ dàng với hệ sinh thái Spark, nhưng latency cao hơn real-time thực sự.
  • Structured Streaming: API dễ dùng hơn, hỗ trợ xử lý liên tục, tốt hơn về fault-tolerance và độ chính xác.
Tiêu chí Spark Streaming (DStream API) Structured Streaming (Dataset/DataFrame API)
Mô hình xử lý Micro‑batch cố định (thường ≥ 500 ms) Continuous micro‑batch (tự động, có chế độ continuous processing ≈ ~1 ms)
API RDD‑like, rời rạc, phải quản lý trạng thái thủ công Tương tự SQL/DataFrame; khai báo (declarative), quản lý trạng thái tự động
Latency Cao hơn real‑time (vài trăm ms → giây) Thấp hơn (< 100 ms với micro‑batch; vài ms với chế độ continuous)
Khả năng chịu lỗi Dựa vào lineage + checkpoint; khôi phục phức tạp khi trạng thái lớn Checkpoint + state store tối ưu; exact‑once mạnh hơn
Tính chính xác At‑least‑once mặc định; dễ trùng lặp nếu không cẩn thận Exactly‑once end‑to‑end (kể cả với sinks hỗ trợ)
Semantics thời gian Hạn chế; xử lý processing‑time là chủ yếu Hỗ trợ event‑time, watermark, window tuỳ biến
Tích hợp nguồn/đích Hệ sinh thái Spark (Kafka, Flume, HDFS, etc.) Kế thừa toàn bộ + thêm FileSink, JDBC, Delta Lake, Iceberg…
Back‑pressure Thủ công (spark.streaming.backpressure.enabled) Tự động điều chỉnh tốc độ và kích thước batch
Bảo trì & tương lai Đã đứng yên từ Spark 3.x; chỉ sửa lỗi Được ưu tiên phát triển; tính năng mới (Lakehouse, incremental ETL)
Khi nào nên dùng? Hệ cũ cần giữ nguyên; yêu cầu đơn giản, ít thay đổi Hầu hết use‑case mới: CDC, streaming ETL, real‑time analytics
  • Ưu điểm chung: dễ tích hợp, xử lý dữ liệu lớn hiệu quả.
  • Nhược điểm chung: độ trễ cao hơn các giải pháp streaming real-time khác (Flink, Kafka Streams).

Apache Kafka hoạt động theo mô hình pub-sub như thế nào? Giải thích Topic, Partition, Consumer Group một cách dễ hiểu.

Mình có thể dưa ra một ẩn dụ trong một thư viện sách và cách sắp xếp sách để diễn giải một cách dễ hình dung cách hoạt động của pub-sub trong Kafka. 

Pub-sub trong Kafka

  • Người gửi (Producer) “đẩy” thông điệp vào Kafka.
  • Người nhận (Consumer) tự kéo (pull) thông điệp về, chứ Kafka không chủ động “nhét” dữ liệu vào tay người nhận. Cách làm này giúp consumer đọc nhanh hay chậm tùy sức mà không làm nghẽn hệ thống.

Topic – kệ sách

  • Hãy hình dung Topic như một kệ sách gắn nhãn. Mọi cuốn sách (thông điệp) liên quan đến cùng chủ đề đều được xếp lên đúng kệ đó.
  • Bạn có thể có nhiều kệ khác nhau: “orders”, “logs”, “payments”…

Partition – ngăn kệ

  • Mỗi kệ (topic) lại được chia thành nhiều ngăn (partition).
  • Nhờ chia ngăn, bạn có thể đặt các ngăn ở nhiều thư viện (broker) khác nhau → Kafka mở rộng ngang hàng (scale-out) rất dễ.
  • Bên trong một partition, sách được sắp theo thứ tự thời gian – đọc lại luôn ra đúng trình tự gửi vào.

Consumer Group – nhóm độc giả

  • Một Consumer Group giống đội độc giả cùng đọc chung một kệ, nhưng chia nhau các ngăn.
  • Quy tắc: mỗi partition chỉ được một thành viên trong nhóm xử lý → không bị trùng lặp.
  • Nếu nhóm có ít người hơn số partition, một người có thể đọc nhiều ngăn; thêm người mới, Kafka tự cân bằng lại để tải được chia đều.

Phỏng vấn độc quyền với Senior Software Engineer tại Ninja Van: Kafka là gì? Những lợi ích tuyệt vời mà Kafka mang lại cho Dev

Exactly-Once Semantics trong Kafka được đảm bảo bằng cách nào?

Exactly‑once semantics là cam kết của hệ thống phân tán (ví dụ: message queue, stream processing) rằng mỗi thông điệp hay bản ghi sẽ được xử lý đúng một và chỉ một lần – không bị bỏ sót (at‑least‑once) và cũng không bị xử lý lặp (at‑most‑once) – kể cả khi xảy ra lỗi, retry hoặc khởi động lại.

Kafka sử dụng transactional API và offset management để đảm bảo mỗi message được xử lý đúng một lần duy nhất, tránh trùng lặp hoặc mất dữ liệu.

Bạn xử lý dữ liệu trễ (late data) hay dữ liệu đến không đúng thứ tự thời gian trong kiến trúc streaming ra sao?

  • Tìm hiểu nguyên nhân dữ liệu bị trễ: chỉ trễ trong hôm nay hay mỗi schedule đều trễ, trễ do batch xử lý lần này bị mắc kẹt hay mỗi schedule đều mắc kẹt, từ đó xác định bảng hoặc logic cụ thể dẫn đến việc đó. 
  • Áp dụng cơ chế watermarking để xác định khoảng thời gian dữ liệu có thể trễ.
  • Sử dụng windowing để nhóm dữ liệu theo khoảng thời gian hợp lý.
  • Kết hợp các chiến lược lưu trữ tạm thời (buffering) dữ liệu trễ và xử lý khi dữ liệu đến đủ hoặc đạt timeout nhất định.

Câu hỏi phỏng vấn Data Engineer về Cloud & Workflow Orchestration

Trong thời đại cloud-first, việc triển khai pipeline trên AWS, GCP, Azure không còn là “cộng thêm”, mà gần như là yêu cầu cơ bản. Nhà tuyển dụng sẽ hỏi bạn cách tối ưu chi phí cloud, bảo mật dữ liệu, và tự động hóa workflow bằng các công cụ như Airflow, Prefect. Đây cũng là nơi thể hiện bạn có tư duy hệ thống và DevOps mindset không.

Bạn đã triển khai data pipeline trên nền tảng Cloud (AWS, GCP, Azure) chưa? Chia sẻ một ví dụ cụ thể.

Dưới đây là ví dụ quy trình triển khai trên từng nền tảng, bạn hãy lựa chọn dựa theo kinh nghiệm cá nhân:

  • AWS: Dữ liệu raw được đẩy vào Amazon S3 ► AWS Lambda tự động kích hoạt AWS Glue Job (PySpark) để làm sạch & chuẩn hoá ► Ghi vào Amazon Redshift; Glue Catalog giữ metadata, CloudWatch theo dõi lỗi.
  • GCP: File CSV đến Cloud Storage ► Cloud Functions tạo thông điệp Pub/Sub ► Cloud Dataflow (Apache Beam) biến đổi & chuẩn hoá ► Nạp kết quả vào BigQuery, dùng Cloud Monitoring giám sát.
  • Azure: IoT/CSV đổ vào Azure Blob Storage ► Event Grid gọi Azure Data Factory pipeline, trong đó Mapping Data Flows làm ETL ► Lưu trữ phân tích trên Azure Synapse Analytics (SQL Pool); Azure Monitor cảnh báo lỗi.

Bạn làm gì để đảm bảo bảo mật và quyền truy cập (IAM) đối với dữ liệu bảo mật cao trên Cloud?

  • Xây dựng chính sách truy cập theo nguyên tắc ít quyền nhất (principle of least privilege).
  • Sử dụng Multi-factor Authentication (MFA) và kiểm soát truy cập bằng IAM roles.
  • Mã hóa dữ liệu lưu trữ (at rest) và dữ liệu truyền tải (in transit).
  • Thường xuyên audit và review quyền truy cập định kỳ.

Bạn có giải pháp hoặc kinh nghiệm gì trong việc kiểm soát chi phí xử lý dữ liệu lớn trên Cloud?

Đầu tiên bạn có thể chia sẻ nhận định của mình về tầm quan trọng của việc kiểm soát chi phí xử lý dữ liệu lớn trên Cloud như sau: 

Dữ liệu phình to nhanh, chỉ một cụm Spark quên tắt cũng “đốt” ngân sách trong vài giờ. Việc theo dõi sát chi phí không chỉ giúp dự án dữ liệu có ROI tích cực, mà còn giúp team Data nói chuyện dễ dàng với phòng Tài chính.

Sau đó, hãy đề xuất cách kiểm soát chi phí:

  • Đặt budget alert + dashboard (AWS Cost Explorer, GCP Billing, Azure Cost Management).
  • Right‑size & auto‑scale; dùng Spot/Preemptible VM cho batch, serverless cho workload dao động.
  • Bật lifecycle tiering (S3 IA → Glacier, GCS Coldline, Azure Archive) và dọn “zombie” resources định kỳ.
  • Partition/nén dữ liệu, tận dụng query cache; cam kết Reserved/Committed Use cho dịch vụ chạy 24/7.

Airflow DAG (Directed Acyclic Graph) hoạt động thế nào? Ưu thế của DAG so với việc chạy job thủ công là gì?

Cách hoạt động: Một DAG (Directed Acyclic Graph) trong Apache Airflow mô tả workflow dưới dạng các “nút” task cùng quan hệ phụ thuộc, để Scheduler tự động chạy, giám sát và khôi phục khi lỗi.

Ưu thế của DAG so với việc chạy job thủ công:

Tiêu chí Airflow DAG Chạy thủ công (cron/script)
Phụ thuộc & thứ tự Khai báo graph rõ ràng; ép chạy đúng thứ tự Logic cài tay; dễ chạy sai bước
Lập lịch & trigger schedule_interval, sensor sự kiện; sửa ngay trong code Cron cố định; thêm trigger phải tự viết
Giám sát Web UI, trạng thái màu, log tập trung Grep log từng máy; không có dashboard
Retry & khôi phục Retry tự động từng task; backfill chọn lọc Thường rerun toàn job, dễ trùng dữ liệu
Mở rộng Worker pool, scale hàng trăm task Parallel khó, dễ tranh chấp tài nguyên

Nếu một task trong Airflow thất bại, chiến lược retry và alert của bạn thường thế nào?

Bạn có thể mở đầu bằng nguyên nhân phổ biến khiến task Airflow thất bại:

  1. Network/API timeout hoặc vượt quota.
  2. Worker thiếu RAM/disk.
  3. Credential hoặc IAM hết hạn/thiếu quyền.
  4. Dữ liệu hoặc schema đổi bất ngờ.
  5. Bug trong code, version library lệch.

Sau đó, trả lời chiến lược retry & alert:

  • Cấu hình retries=3 với retry_delay=10 → 20 → 40 phút (exponential back‑off).
  • Dùng on_failure_callback: gửi Slack + email ngay lần lỗi đầu; hết retry vẫn lỗi thì escalate tới DevOps/PM.

Khác biệt chính giữa Airflow với Prefect hay Luigi là gì?

  • Airflow, Prefect và Luigi đều là workflow orchestrator mã nguồn mở, giúp khai báo, lập lịch và giám sát các pipeline ETL/batch. Chúng diễn tả quy trình dưới dạng đồ thị task-phụ thuộc, hỗ trợ retry, alert và logging, qua đó giảm thao tác thủ công.

Một số điểm khác biệt chính:

Tiêu chí Airflow Prefect Luigi
Giao diện Web UI mạnh mẽ, phổ biến Web UI hiện đại, dễ dùng UI đơn giản hơn
Kiến trúc DAG-based, scheduler trung tâm Task-based, distributed dễ hơn Task-based đơn giản
Mức độ linh hoạt Cao, hỗ trợ nhiều operator Rất cao, hỗ trợ state management tốt Ít hơn, đơn giản hơn
Độ phổ biến Rộng rãi, nhiều cộng đồng Đang tăng trưởng nhanh Ít phổ biến hơn

Câu hỏi phỏng vấn Data Engineer về Lập trình & Data Quality

Một Data Engineer giỏi không thể thiếu kỹ năng lập trình, đặc biệt là xử lý dữ liệu bằng Python, Scala, hoặc Java. Bạn cần chứng minh khả năng viết mã sạch, tối ưu hiệu năng và kiểm soát chất lượng dữ liệu từ đầu vào đến đầu ra. Các câu hỏi ở đây giúp bạn thể hiện khả năng coding thực chiến, cũng như hiểu biết về kiểm thử và bảo trì.

Bạn thường xử lý dữ liệu bằng Python (pandas, PySpark) hay Scala/Java? Lý do lựa chọn?

  • Python (pandas, PySpark): Dễ dùng, cộng đồng hỗ trợ lớn, thư viện phong phú, phù hợp với các tác vụ phân tích nhanh.
  • Scala/Java: Hiệu năng cao hơn, mạnh mẽ trong xử lý dữ liệu lớn, phù hợp với các pipeline dữ liệu lớn và phức tạp.

Khi dùng PySpark, bạn chú ý gì về lazy evaluation và cách giảm shuffle để cải thiện hiệu năng?

Lazy evaluation có lợi ích: Spark chỉ chạy khi gặp action, nên có thời gian tối ưu toàn bộ DAG. Nhưng hạn chế là:

  • Debug khó: lỗi xuất hiện muộn ở bước action, khó khoanh vùng.
  • Job dồn cục: nhiều transformation tích lũy → action cuối đòi RAM cao, dễ OOM.

Lí do phải giảm shuffle vì: Shuffle di chuyển dữ liệu qua mạng + ghi đĩa, tạo stage mới → chậm và tốn tài nguyên.

Hệ quả nếu lạm dụng:

  • Network I/O cao, spill sang disk, kéo dài GC.
  • Data skew làm vài executor chạy lâu, toàn job chờ, dễ timeout.

Chiến lược tối ưu hiệu năng có thể là:

  • Giữ nguyên partition key; broadcast join cho bảng nhỏ.
  • Tránh groupBy, distinct, join không cần thiết; ưu tiên mapPartitions/reduceByKey.
  • Dùng repartition() có chủ đích (đầu job), coalesce() thu gọn (cuối job).

Ở Scala/Java, bạn đã từng phải xử lý vấn đề GC (Garbage Collection) khi xử lý data lớn chưa?

Garbage Collection (GC) là cơ chế JVM tự động thu hồi vùng nhớ của các đối tượng không còn được tham chiếu.

GC là vấn đề với khối lượng dữ liệu lớn vì:

  • Stop‑the‑world pauses: GC tạm dừng toàn bộ threads, gây độ trễ, chậm stage Spark/Hadoop.
  • Nếu heap cấu hình sai → Full GC dài, Out‑Of‑Memory, task retry → tốn thời gian & chi phí.
  • Pauses làm mất kết nối driver–executor, job fail, dữ liệu phải xử lý lại.

Chiến lược xử lý GC khi chạy data pipeline Scala/Java:

  • Tối ưu JVM: -Xms/-Xmx phù hợp, chọn GC G1/ZGC, bật -XX:+UseStringDeduplication.
  • Theo dõi GC log: bật -Xlog:gc* (JDK >= 9) → phân tích bằng GCViewer; chỉnh NewRatio, G1HeapRegionSize dựa trên pattern.
  • Giảm đối tượng tạo mới: dùng primitive arrays, mapPartitions thay vì map, cache chọn lọc, tái sử dụng buffer.

Bạn đảm bảo chất lượng dữ liệu (Data Quality) như thế nào xuyên suốt pipeline?

  • Sử dụng validation rule, schema enforcement tại bước nhập liệu.
  • Kiểm tra tính toàn vẹn và nhất quán của dữ liệu thông qua các bước xử lý trung gian.
  • Định kỳ audit dữ liệu để phát hiện sớm các vấn đề.
  • Tích hợp tự động các cảnh báo khi dữ liệu không đạt chuẩn chất lượng.

Bạn có dùng công cụ nào cho data validation hay tự viết script?

Bạn có thể chia sẻ về 2 công cụ data validation là Great Expectations và Soda:

  • Great Expectations: hỗ trợ validation rules mạnh mẽ, dễ dàng tích hợp vào pipeline.
  • Soda: thân thiện, giao diện tốt, phù hợp cho người dùng không chuyên sâu kỹ thuật.

Nếu tự viết script, bạn có thể chia sẻ trường hợp sử dụng: khi cần linh hoạt, tùy chỉnh sâu hơn theo yêu cầu đặc biệt của dự án.

Câu hỏi phỏng vấn Data Engineer về Kinh nghiệm thực chiến & Kỹ năng coding

Lý thuyết tốt thôi chưa đủ – phần này là nơi bạn kể lại trải nghiệm thực tế của mình, những dự án bạn từng làm, cách bạn giải quyết vấn đề, và bài học bạn rút ra. Nhà tuyển dụng rất đánh giá cao các tình huống cụ thể, vì chúng phản ánh chân thực nhất năng lực và tư duy Data Engineering của bạn. Đây cũng là phần bạn có thể ghi điểm lớn nhất nếu chuẩn bị tốt.

Lưu ý: Ở phần này, tôi sẽ chia sẻ một ví dụ cho một dự án thực tế mà bạn có thể tham khảo, nhưng tốt nhất là bạn vẫn nên tự thực hành một dự án có code hoàn chỉnh để dễ trả lời khi nhà tuyển dụng hỏi chuyên sâu.

Bạn có thể chia sẻ một dự án điển hình bạn từng xây dựng pipeline từ ingest → transform → load → báo cáo?

Gợi ý cách trả lời:

  • Mở đầu bằng việc mô tả đầu vào của pipeline: nguồn dữ liệu đến từ đâu (API, log, file batch…)?
  • Nêu rõ kinh nghiệm ở từng giai đoạn: 
    • Bạn đã sử dụng công nghệ nào để ingest dữ liệu? (Kafka, Flink, API Gateway…)
    • Bạn đã xử lý (transform) dữ liệu ra sao? Có làm sạch, enrich, join nhiều nguồn không?
    • Dữ liệu cuối cùng được load vào đâu (Data Warehouse, Data Lake)?
  • Cuối cùng, dashboard/report được tạo như thế nào? Dùng công cụ gì?

Một câu trả lời tốt cần thể hiện:

  • Có khả năng trình bày end-to-end pipeline rõ ràng, có logic.
  • Sự hiểu biết về công nghệ và lý do lựa chọn công nghệ phù hợp.

Ví dụ dự án tham khảo: 

Phễu Thương mại điện tử Thời Gian Thực – hệ thống thu thập log click và đơn hàng tức thời, làm sạch-làm giàu trên Spark Streaming, ghi Delta Lake rồi trực quan hoá funnel & cohort ngay lập tức trên Tableau.

  • Nguồn: log click‑stream (Web & App) + REST API đơn hàng.
  • Ingest: Kafka Connect (Debezium cho MySQL, HTTP Source cho API), partition theo event_date.
  • Transform: Spark Structured Streaming trên Databricks — chuẩn hoá UTC, dedup, enrich với user‑profile, join click ↔ order.
  • Load: ghi Delta Lake trên S3 → Snowflake bằng Snowpipe.
  • Report: Tableau live‑query Snowflake hiển thị funnel & cohort.

Lý do chọn các công nghệ này:

Chọn Kafka + Kafka Connect, Spark Structured Streaming, Delta Lake, Snowflake / Snowpipe và Tableau vì tất cả đều có bản OSS hoặc gói free-trial – có thể spin-up Docker trên laptop 8 GB RAM để ingest log, xử lý bằng Spark local mode, lưu Delta file vào ổ đĩa, rồi dùng Snowflake free tier (5 GB) làm warehouse và Tableau Public để trực quan hóa.

Nhờ vậy mà người mới, hay dự án có kinh phí hạn chế vẫn dựng được pipeline mẫu cho portfolio, dễ học, dễ mở rộng, không tốn chi phí phần cứng nặng.

Cho ví dụ về việc bạn tối ưu pipeline thành công (giảm chi phí hoặc tăng tốc độ xử lý). Bạn đã làm gì?

Gợi ý trả lời:

  • Trình bày hiện trạng pipeline trước khi tối ưu.
  • Mô tả cụ thể thay đổi bạn thực hiện (chuyển batch → streaming, caching, indexing, parallelism…)
  • Kết quả đo lường cải thiện: latency giảm bao nhiêu phần trăm, chi phí hạ tầng giảm bao nhiêu?

Một câu trả lời tốt cần thể hiện:

  • Tư duy tối ưu hóa hiệu quả về mặt thời gian, chi phí.
  • Biết sử dụng metrics để chứng minh hiệu quả tối ưu.

Ví dụ dự án tham khảo: 

Giảm Chi Phí Batch → Streaming: chuyển pipeline xử lý 6 giờ/lần sang luồng streaming Parquet kèm cache Redis, giúp hạ latency xuống 35 phút và cắt 52 % chi phí EMR.

  • Trước: Spark batch 6 h / lần, lưu CSV; latency ~4 h, 12 EC2 r5.4x large.
  • Thay đổi: chuyển streaming, đổi CSV → Parquet, bật auto‑scaling, cache dimension nhỏ trên Redis.

Bạn đã bao giờ gặp tình huống dữ liệu bị thiếu/sai nhiều? Cách bạn nhận diện và xử lý ra sao?

Gợi ý trả lời:

  • Mô tả cụ thể tình huống (dữ liệu sai format, null bất thường, duplicate…)
  • Bạn phát hiện ra vấn đề bằng cách nào (alert, test, log)?
  • Cách bạn xử lý: rule làm sạch, kỹ thuật hồi phục, liên hệ team khác…

Một câu trả lời tốt cần thể hiện:

  • Kỹ năng phát hiện lỗi dữ liệu tự động hoặc bằng công cụ.
  • Quy trình xử lý và cải tiến pipeline để tránh lỗi lặp lại.

Ví dụ dự án tham khảo: Khôi phục cột giá, phát hiện đột biến null ở trường price qua Great Expectations, vá API, backfill Kafka ba ngày và bổ sung kiểm thử schema để ngừa lặp lại.

  • Sự cố: cột price thỉnh thoảng null vì upstream bỏ field khi = 0.
  • Phát hiện: Great Expectations rule “non‑null > 99.5 %” gửi alert Slack.
  • Xử lý: update API trả 0, backfill 3 ngày từ raw Kafka, thêm JSON Schema contract & unit test.

Với SQL, bạn thường gặp khó khăn nhất ở phần nào (window functions, CTE, pivot…)? Làm sao để vượt qua?

Gợi ý trả lời:

  • Xác định kỹ thuật SQL bạn từng gặp khó khăn.
  • Tìm và chia sẻ một ví dụ cụ thể bạn đã giải quyết thành công.
  • Bạn học từ đâu, áp dụng như thế nào để vượt qua vấn đề đó?

Một câu trả lời tốt cần thể hiện:

  • Có tư duy phản biện và học hỏi chủ động.
  • Biết áp dụng SQL nâng cao đúng ngữ cảnh.

Ví dụ mẫu trả lời phỏng vấn, hãy chỉnh sửa theo kinh nghiệm cá nhân:

  • Khó khăn của tôi nằm ở phần Window functions từng làm tôi xoay xở mãi. Khi cần lấy bản ghi mới nhất của mỗi user, tôi chuyển từ sub-query sang row_number() trong CTE, giảm thời gian từ 12s xuống 3s. Bài học rút ra là: Luôn thử trên data nhỏ, benchmark rồi ghi chú lại.
  • Tôi chưa gặp nhiều khó khăn, nhưng để làm tốt với Window functions, mỗi tối tôi học nửa tiếng khóa Advanced SQL, thực hành lag() và rank() trên báo cáo cũ rồi nhờ Senior review. Mục tiêu của tôi là hai tháng nữa đưa một truy vấn window vào production.

Bạn có tham gia giải bài thuật toán/cấu trúc dữ liệu (HackerRank, LeetCode) cho vị trí Data Engineer không? Bạn gặp dạng bài gì?

Gợi ý trả lời:

  • Kể tên platform và số lượng bài bạn đã làm.
  • Các chủ đề hay gặp: mảng, chuỗi, heap, hashmap, two pointers…
  • Bạn có chiến lược luyện tập như thế nào? Theo chủ đề, theo mức độ?

Một câu trả lời tốt cần thể hiện:

  • Có đầu tư nghiêm túc để rèn luyện kỹ năng coding.
  • Hiểu rõ mục tiêu của các vòng technical test.

Ví dụ mẫu trả lời phỏng vấn, hãy chỉnh sửa theo kinh nghiệm cá nhân:

  • Nếu có nhiều kinh nghiệm: Tôi giải khoảng 250 bài LeetCode, tập trung heap, hashmap và sliding-window; luyện ba tuần theo chủ đề, tuần cuối mock test 90 phút. Vòng coding ở công ty X hoàn thành trong 35 phút, đạt điểm tối đa.
  • Nếu chưa làm nhiều: Tôi đã làm 30 bài LeetCode; ưu tiên two-pointers và heap vì sát bài test Data Engineer. Đặt mục tiêu 10 bài/tuần và viết blog ngắn ghi lại cách giải để lên tay.

Bạn có dự án cá nhân nào (portfolio) về ETL, Streaming, hay Machine Learning Pipeline có thể chia sẻ không?

Gợi ý trả lời:

  • Mô tả ngắn gọn về bài toán, dữ liệu, công cụ sử dụng.
  • Pipeline gồm những bước nào? Xử lý batch hay streaming?
  • Link GitHub hoặc demo nếu có.

Một câu trả lời tốt cần thể hiện:

  • Có chủ động học qua dự án thực tế.
  • Khả năng trình bày rõ ràng, tự tin về sản phẩm của mình.

Một ví dụ về thực hành:

Trong dự án này, mục tiêu của tôi là cung cấp cho trader một chỉ báo “nhiệt độ cảm xúc thị trường” (bullish hay bearish) càng gần thời gian thực càng tốt, từ đó hỗ trợ họ ra quyết định giao dịch.

Mình xây hệ thống đo sentiment crypto gần realtime cho trader. Tweet chứa 50 từ khoá được hút từ Twitter Streaming API, giá khớp lệnh lấy qua Binance WebSocket, cả hai đẩy vào Kafka (6 partition) để chống nghẽn. Flink SQL làm sạch tweet, gọi BERT‑sentiment trong UDF, rồi join cửa sổ 30 s với dòng giá; kết quả stream ghi vào ClickHouse (partition theo phút, TTL 180 ngày). Airflow cuối ngày xuất Parquet lên S3 + chạy dbt cho phân tích offline. Grafana đọc ClickHouse hiển thị heat‑map cảm xúc chồng giá, bắn alert Telegram khi FUD > 0.7; Tableau dùng layer batch vẽ tương quan 7 ngày

Bạn đã từng làm việc với version control cho dữ liệu chưa? Bạn dùng công cụ gì để quản lý schema/data versioning?

Gợi ý trả lời:

  • Đã dùng Delta Lake, Apache Hudi hoặc các công cụ tương tự chưa?
  • Bạn quản lý version schema như thế nào khi có thay đổi?
  • Làm sao đảm bảo backward/forward compatibility?

Một câu trả lời tốt cần thể hiện:

  • Biết áp dụng các công cụ hiện đại để quản lý thay đổi dữ liệu.
  • Hiểu rõ tầm quan trọng của versioning trong môi trường production.

Ví dụ mẫu trả lời phỏng vấn, hãy chỉnh sửa theo kinh nghiệm cá nhân:

  • Nếu đã từng làm: Trong dự án marketing-analytics, tôi dùng Delta Lake + DBT. Mỗi thay đổi schema qua PR, CI kiểm tra breaking change; nhờ time-travel tôi từng rollback bảng fact về bản 01:00 12-04-2025 chỉ trong hai phút.
  • Trường hợp chưa làm nhiều: Tôi chỉ quản lý script migration trên Git. Tôi đang dựng lab Iceberg trên Docker để thử snapshot; quý tới đề xuất dùng Delta Lake cho bảng sự kiện, bắt đầu từ staging rồi mới lên production.

Bạn có kinh nghiệm làm việc với CI/CD cho pipeline dữ liệu không? Quy trình bạn xây dựng như thế nào?

Gợi ý trả lời:

  • Mô tả tool bạn sử dụng (GitHub Actions, GitLab CI, dbt Cloud…)
  • Pipeline build/test/deploy có bước nào?
  • Bạn validate dữ liệu hay test code như thế nào?

Một câu trả lời tốt cần thể hiện:

  • Có tư duy DevOps cho hệ thống dữ liệu.
  • Biết đảm bảo chất lượng khi release pipeline mới.

Khi viết script xử lý dữ liệu, bạn làm gì để đảm bảo khả năng mở rộng và bảo trì dễ dàng về sau?

Gợi ý trả lời:

  • Bạn có chia module, tách logic, viết function reusable không?
  • Bạn có logging, error handling không?
  • Có viết tài liệu/README kèm theo không?

Một câu trả lời tốt cần thể hiện:

  • Tuân thủ clean code và best practices.
  • Hướng đến sản phẩm dễ chuyển giao và mở rộng bởi người khác.

Đọc thêm: CI/CD là gì? Lợi ích và các nguyên tắc triển khai CI/CD vào quy trình phát triển phần mềm

Tổng kết

Chuẩn bị cho một buổi phỏng vấn Data Engineer không chỉ là học thuộc kiến thức hay nhớ các câu trả lời mẫu, mà là hành trình bạn xây dựng nền tảng tư duy hệ thống, logic và khả năng phản xạ trong những tình huống thực tế. Từ SQL cơ bản, cấu trúc dữ liệu, đến kiến trúc Big Data, Cloud và quy trình ETL phức tạp – mọi khía cạnh đều có thể là mảnh ghép tạo nên sự khác biệt trong buổi phỏng vấn.

Điều quan trọng nhất là: bạn không cần phải biết mọi thứ, nhưng phải thật sự hiểu những gì bạn đã làm và đã học. Hãy dành thời gian xây dựng một portfolio thật chất lượng, rèn luyện kỹ năng giải quyết vấn đề, và luôn cập nhật công nghệ mới. Dù bạn đang là sinh viên mới ra trường hay đã có kinh nghiệm, một thái độ học hỏi nghiêm túc và sự kiên trì sẽ luôn dẫn bạn đến đúng cơ hội.

Chúc bạn tìm thấy thật nhiều giá trị hữu ích trong bài viết này, và sớm chinh phục được công việc mơ ước trong lĩnh vực Data Engineering. Hãy tự tin, tích cực và đừng quên rằng – mọi kỹ sư giỏi đều từng bắt đầu từ những dòng dữ liệu đầu tiên.

Đọc thêm: Top 30+ câu hỏi phỏng vấn Data Analyst thường gặp