Top 15 Câu Hỏi Phỏng Vấn Data Engineer & Gợi Ý Trả Lời Chuẩn 2026

Sự thật ít ai nói thẳng: phần lớn ứng viên trượt phỏng vấn Data Engineer không phải vì không biết kỹ thuật — mà vì biết mà không giải thích được. Họ dùng Spark hàng ngày nhưng không trả lời được “tại sao Spark nhanh hơn MapReduce?”. Họ viết ETL thành thục nhưng lúng túng khi bị hỏi “nếu pipeline fail lúc 3 giờ sáng, anh/chị xử lý như thế nào?”. Bài viết này không chỉ liệt kê câu hỏi — nó phân tích tại sao câu hỏi đó được hỏi và trả lời như thế nào để gây ấn tượng với interviewer.

Dù bạn đang chuẩn bị cho vòng phỏng vấn đầu tiên hay đang target vị trí senior tại công ty lớn, bài viết này tổng hợp đầy đủ 15 câu hỏi phỏng vấn Data Engineer thường gặp nhất — phân loại theo từng vòng, kèm gợi ý trả lời thực chiến và những sai lầm cần tránh.

1. Cấu Trúc Một Quy Trình Phỏng Vấn Data Engineer Thường Gồm Mấy Vòng?

Trước khi đi vào từng câu hỏi, cần hiểu bức tranh tổng thể của quy trình tuyển dụng để biết chuẩn bị đúng thứ cho đúng vòng.

Tham khảo thêm quy trình tuyển dụng Data Engineer đầy đủ 3–4 vòng để hiểu sâu hơn từng giai đoạn và cách chuẩn bị chiến lược.

2. Câu Hỏi Phỏng Vấn Hành Vi (Behavioral) — Vòng HR Và Culture Fit

Câu hỏi hành vi đánh giá cách bạn hành động trong các tình huống thực tế trong quá khứ — dựa trên nguyên tắc “hành vi trong quá khứ là dự đoán tốt nhất cho hành vi tương lai”. Dùng format STAR (Situation – Task – Action – Result) để trả lời mọi câu hỏi behavioral.

Câu 1: “Điều gì khiến bạn là ứng viên phù hợp nhất cho vị trí Data Engineer này?”

Tại sao câu này được hỏi: Interviewer muốn biết bạn có hiểu rõ yêu cầu công việc không, và bạn có thể kết nối kỹ năng của mình với nhu cầu cụ thể của họ không.

Sai lầm phổ biến: Nêu danh sách kỹ năng chung chung (“em biết Python, SQL, AWS…”) mà không kết nối với bối cảnh cụ thể của công ty.

Gợi ý trả lời: Nghiên cứu kỹ JD và website công ty trước. Xác định 2–3 điểm cụ thể trong yêu cầu tuyển dụng mà bạn có kinh nghiệm thực chiến, sau đó dẫn chứng bằng kết quả cụ thể. Ví dụ: “Trong JD, anh/chị đề cập đến việc xây dựng streaming pipeline xử lý real-time data — đây đúng là công việc chính của em tại [công ty cũ], nơi em xây hệ thống Kafka + Flink xử lý 2 triệu event/giờ với độ trễ dưới 500ms.”

Câu 2: “Trách nhiệm hàng ngày của bạn ở công việc trước là gì?”

Tại sao câu này được hỏi: Đánh giá độ phức tạp thực tế của công việc bạn đã làm — và quan trọng hơn, bạn có thể mô tả công việc kỹ thuật một cách rõ ràng và có cấu trúc không.

Gợi ý trả lời: Đừng liệt kê flat. Hãy chia theo nhóm: hạ tầng (pipeline, warehouse), chất lượng dữ liệu, và cộng tác (với Data Scientist, Analyst, Engineering). Đề cập đến quy mô cụ thể (bao nhiêu pipeline, data volume, team size) — con số giúp câu trả lời thuyết phục hơn nhiều. Nếu bạn là người mới chưa có kinh nghiệm đi làm, hãy nói về project cá nhân và thực tập — xem những gì intern Data Engineer thực sự làm để chuẩn bị.

Câu 3: “Thách thức lớn nhất bạn gặp phải khi làm Data Engineer là gì và bạn xử lý thế nào?”

Tại sao câu này được hỏi: Đánh giá khả năng problem-solving, khả năng chịu áp lực và mức độ tự nhận thức về điểm yếu của bản thân.

Gợi ý trả lời: Chọn một thách thức thực sự có độ phức tạp kỹ thuật — không phải “em hay quên deadline” hay “em quá cầu toàn”. Ví dụ tốt: xử lý data quality issue ảnh hưởng đến model production, tối ưu pipeline bị timeout khi data volume tăng đột biến, hay migrate data warehouse mà không downtime. Kết thúc bằng bài học rút ra — interviewer muốn thấy bạn phát triển từ thách thức đó.

Câu 4: “Bạn có thể mô tả một dự án bạn phải cộng tác với team khác không? Cách bạn xử lý khi có conflict?”

Tại sao câu này được hỏi: Data Engineer làm việc với Data Scientist, Data Analyst, Backend Engineer, và Business stakeholder cùng lúc. Khả năng giao tiếp và xử lý conflict là yêu cầu thực tế, không chỉ là “nice to have”.

Gợi ý trả lời: Dùng STAR. Mô tả rõ: bạn và team nào, mục tiêu dự án là gì, conflict phát sinh ở đâu (thường gặp nhất: yêu cầu data format khác nhau, timeline không đồng bộ, hoặc technical approach bất đồng), bạn xử lý thế nào và kết quả ra sao. Tránh đổ lỗi cho người khác — focus vào cách bạn đóng góp vào giải pháp.

Câu 5: “Bạn cập nhật kiến thức và theo dõi xu hướng công nghệ Data Engineering như thế nào?”

Tại sao câu này được hỏi: Lĩnh vực Data Engineering thay đổi rất nhanh (Apache Iceberg, DuckDB, dbt, Polars đều là công nghệ chưa phổ biến 3–5 năm trước). Interviewer muốn biết bạn có thực sự tự học liên tục hay không.

Gợi ý trả lời thuyết phục: Không nên liệt kê chung chung như “em đọc blog và tham gia community”. Hãy cụ thể: đặt tên newsletter bạn subscribe (Data Engineering Weekly, Airbyte Blog, dbt blog…), Discord hoặc Slack community bạn tham gia, paper gần đây bạn đọc, hoặc technology mới bạn vừa thử nghiệm. Thêm một câu hỏi ngược lại: “Anh/chị có thể chia sẻ team đang theo dõi công nghệ mới nào không?” — đây vừa thể hiện sự tò mò, vừa giúp bạn hiểu culture công ty.

3. Câu Hỏi Kỹ Thuật Cơ Bản — Data Modeling, ETL Và Orchestration

Câu 6: “Giải thích sự khác biệt giữa Star Schema, Snowflake Schema và Data Vault?”

Tại sao câu này được hỏi: Data modeling là kỹ năng core của Data Engineer — quyết định pipeline nhanh hay chậm, data warehouse dễ mở rộng hay không.

Trả lời đủ sâu:

Star Schema có một fact table trung tâm kết nối trực tiếp với các dimension table (không normalize). Ưu điểm: query đơn giản, ít JOIN, phù hợp cho analytical workload cần tốc độ. Nhược điểm: data dư thừa do denormalization.

Snowflake Schema là mở rộng của Star Schema — dimension table được normalize thêm thành các sub-dimension. Ưu điểm: ít data dư thừa hơn, dễ maintain khi dimension thay đổi. Nhược điểm: query phức tạp hơn do nhiều JOIN hơn.

Data Vault là phương pháp modeling linh hoạt hơn, chia thành Hub (business keys), Link (relationships) và Satellite (descriptive attributes). Phù hợp cho enterprise data warehouse cần audit trail và khả năng thêm nguồn dữ liệu mới mà không phá vỡ cấu trúc hiện tại.

Gây ấn tượng thêm: “Trong thực tế, em thường dùng Star Schema cho data mart phục vụ BI tools như Power BI hoặc Tableau vì query performance tốt hơn. Data Vault phù hợp hơn khi data warehouse cần integrate nhiều source system và history tracking quan trọng — ví dụ trong banking.”

Câu 7: “ETL và ELT khác nhau như thế nào? Khi nào bạn chọn cái nào?”

Trả lời cốt lõi: ETL (Extract–Transform–Load) transform dữ liệu trước khi load vào destination — phù hợp khi destination không có compute power đủ mạnh (on-premise database) hoặc khi cần giảm storage cost. ELT load raw data trước, transform sau bên trong destination — phù hợp với cloud data warehouse hiện đại (BigQuery, Snowflake, Redshift) có compute power lớn và storage rẻ.

Gây ấn tượng thêm: Nhắc đến dbt — “Với ELT stack hiện đại, em thường dùng dbt để manage transformation layer — có version control, test tự động, và documentation tích hợp. Điều này giúp transformation trở nên reproducible và dễ maintain hơn nhiều so với viết stored procedure thuần.”

Câu 8: “Bạn sử dụng công cụ ETL nào? Tại sao chọn tool đó thay vì tool khác?”

Đừng chỉ liệt kê tên tool — interviewer muốn thấy bạn hiểu trade-off và có khả năng chọn đúng tool cho đúng bài toán.

Câu 9: “Data Orchestration là gì? Tại sao cần orchestration thay vì chỉ dùng cron job?”

Trả lời cốt lõi: Data orchestration là quá trình quản lý và tự động hóa toàn bộ luồng data pipeline — bao gồm scheduling, dependency management, error handling, retry logic và monitoring. Cron job chỉ chạy task theo lịch — không xử lý được dependency (task B phải chờ task A xong), không có retry tự động khi fail, không có visibility vào trạng thái từng step và không alert khi có vấn đề.

Gây ấn tượng thêm: “Trong production, một pipeline đơn giản tưởng như chỉ cần cron job thực ra cần ít nhất: idempotency (chạy lại an toàn), backfill (chạy lại cho ngày cũ khi data source fail), và alerting khi SLA bị vi phạm. Đó là lý do tại sao ngay cả team nhỏ cũng nên dùng Airflow hoặc Prefect thay vì cron.”

4. Câu Hỏi Kỹ Thuật Nâng Cao — System Design Và Kiến Trúc

Câu 10: “Batch Processing và Stream Processing khác nhau như thế nào? Khi nào dùng Lambda Architecture?”

Trả lời cốt lõi: Batch processing xử lý dữ liệu theo lô tại một thời điểm cố định (hourly, daily) — throughput cao, latency cao. Phù hợp cho: báo cáo cuối ngày, data warehouse update, ML training. Stream processing xử lý từng event ngay khi nó phát sinh — latency thấp (millisecond đến giây), phù hợp cho: fraud detection, real-time recommendation, monitoring hệ thống.

Lambda Architecture kết hợp cả hai: speed layer (streaming, low latency) + batch layer (high accuracy) + serving layer (merge kết quả). Dùng khi cần vừa real-time vừa accurate — nhưng phức tạp để maintain vì phải giữ hai codebase song song. Xu hướng hiện nay là Kappa Architecture — dùng streaming cho tất cả, đơn giản hơn.

Câu 11: “Bạn đảm bảo data quality trong pipeline như thế nào?”

Tại sao câu này quan trọng: Đây là câu hỏi phân biệt Data Engineer “junior” với “senior” rõ rệt nhất. Người mới thường chỉ nghĩ đến việc data chạy được — người giỏi nghĩ đến việc data đúng.

Gợi ý trả lời toàn diện: Trả lời theo 4 tầng: (1) Schema validation — kiểm tra đúng kiểu dữ liệu và cấu trúc ngay tại ingestion; (2) Business logic tests — kiểm tra các rule nghiệp vụ (ví dụ: revenue không thể âm, user_id không được null trong bảng orders); (3) Statistical monitoring — phát hiện khi phân phối dữ liệu thay đổi bất thường (data drift); (4) Freshness check — đảm bảo dữ liệu được cập nhật đúng SLA. Nhắc đến tool cụ thể: Great Expectations, dbt tests (not_null, unique, accepted_values), hoặc Monte Carlo cho data observability.

Câu 12: “Giải thích CAP Theorem và nó ảnh hưởng đến quyết định chọn database như thế nào?”

Trả lời cốt lõi: CAP Theorem phát biểu rằng một distributed system không thể đồng thời đảm bảo cả ba: Consistency (mọi node đọc được data mới nhất), Availability (mọi request đều nhận được response) và Partition Tolerance (hệ thống vẫn hoạt động khi có network partition). Vì Partition Tolerance là yêu cầu bắt buộc trong distributed system thực tế, lựa chọn thực sự là giữa CP (ưu tiên consistency, chấp nhận downtime khi partition) và AP (ưu tiên availability, chấp nhận data có thể stale).

Ứng dụng thực tế: “Em chọn PostgreSQL (CP) cho dữ liệu tài chính vì consistency quan trọng hơn — không thể có hai node đọc được số dư khác nhau. Em chọn Cassandra (AP) cho activity log hoặc sensor data vì availability quan trọng hơn — không sao nếu đọc được data cũ hơn một chút, miễn là hệ thống không down.”

5. Câu Hỏi SQL Thực Chiến — Thường Xuất Hiện Trong Technical Test

SQL test là vòng loại phổ biến nhất. Dưới đây là ba dạng câu hỏi SQL điển hình trong phỏng vấn Data Engineer:

Câu 13: “Viết query tìm top 3 sản phẩm bán chạy nhất mỗi tháng trong năm ngoái”

Tại sao câu này được hỏi: Đánh giá khả năng dùng Window Function — kỹ năng SQL nâng cao nhất thường được test.

Hướng tiếp cận đúng:

WITH monthly_sales AS (
  SELECT 
    DATE_TRUNC('month', order_date) AS month,
    product_id,
    SUM(quantity) AS total_sold
  FROM orders
  WHERE order_date >= DATE_TRUNC('year', CURRENT_DATE - INTERVAL '1 year')
    AND order_date < DATE_TRUNC('year', CURRENT_DATE)
  GROUP BY 1, 2
),
ranked AS (
  SELECT *,
    RANK() OVER (PARTITION BY month ORDER BY total_sold DESC) AS rank
  FROM monthly_sales
)
SELECT month, product_id, total_sold
FROM ranked
WHERE rank <= 3
ORDER BY month, rank;

Điểm gây ấn tượng khi giải thích: Chủ động nêu lên edge case — “Em dùng RANK() thay vì ROW_NUMBER() để xử lý trường hợp tie — nếu sản phẩm thứ 3 và 4 có cùng số lượng bán, RANK() sẽ trả về cả hai. Nếu business yêu cầu đúng 3 kết quả, em sẽ dùng ROW_NUMBER() hoặc hỏi lại yêu cầu.”

Câu 14: “Làm thế nào để detect và xử lý duplicate records trong một bảng lớn?”

Đây là câu hỏi thực chiến: Không phải chỉ biết cú pháp mà cần có tư duy data quality.

Hướng tiếp cận: Trước tiên xác định “duplicate theo nghĩa gì” — exact duplicate (mọi column giống nhau) hay business duplicate (cùng user_id nhưng khác timestamp). Với exact duplicate, dùng ROW_NUMBER() với PARTITION BY tất cả các column để giữ lại một row. Với business duplicate, cần xác định column nào là “source of truth” (thường là created_at mới nhất hoặc updated_at mới nhất). Đề xuất thêm: “Phòng ngừa tốt hơn xử lý — em sẽ đặt UNIQUE constraint phù hợp hoặc dùng INSERT … ON CONFLICT trong Postgres thay vì để duplicate xảy ra rồi mới clean.”

Câu 15: “Bạn sẽ thiết kế schema như thế nào cho hệ thống tracking user behavior của một e-commerce?”

Tại sao câu này được hỏi: Đánh giá tư duy data modeling trong bối cảnh business thực tế — không có một đáp án duy nhất, interviewer muốn xem quá trình suy nghĩ của bạn.

Cách trả lời theo framework: Bắt đầu bằng câu hỏi làm rõ yêu cầu: “Schema này dùng cho OLTP (operational) hay OLAP (analytical)? Cần hỗ trợ query real-time hay batch? Cần lưu history của attribute thay đổi không?” — điều này thể hiện tư duy system design thực chiến. Sau đó đề xuất schema cụ thể với giải thích trade-off: “Cho OLAP, em sẽ dùng Star Schema với fact_events làm fact table, dim_user, dim_product, dim_session làm dimension. Nếu cần history tracking cho user attribute (vd: địa chỉ thay đổi), em sẽ dùng Slowly Changing Dimension Type 2.”

6. Những Sai Lầm Phổ Biến Nhất Trong Phỏng Vấn Data Engineer

7. Câu Hỏi Bạn Nên Hỏi Ngược Lại Nhà Tuyển Dụng

Hỏi ngược lại không chỉ giúp bạn đánh giá công ty — nó còn cho thấy sự nghiêm túc và tư duy chuyên nghiệp của bạn. Dưới đây là những câu hỏi thể hiện đúng mindset của một Data Engineer:

8. FAQ — Câu Hỏi Thường Gặp Khi Chuẩn Bị Phỏng Vấn Data Engineer

Tổng Kết: Phỏng Vấn Data Engineer Là Kỹ Năng Có Thể Luyện Được

15 câu hỏi phỏng vấn Data Engineer trong bài này không phải danh sách để học thuộc — chúng là framework để bạn hiểu interviewer muốn thấy gì ở mỗi vòng. Vòng HR muốn thấy bạn giao tiếp rõ ràng và có motivation thực sự. Vòng technical muốn thấy bạn hiểu sâu, không chỉ biết dùng tool. Vòng final muốn thấy bạn là người đồng đội tốt và có tư duy phát triển.

Chuẩn bị tốt nhất không phải là đọc câu hỏi và thuộc đáp án — mà là build thêm một project thực tế, thực hành giải thích to quá trình suy nghĩ, và mock interview với người đang làm trong ngành. Ba thứ đó có giá trị hơn đọc 100 bài tổng hợp câu hỏi cộng lại.

Nếu bạn muốn có nền tảng kỹ thuật đủ vững để tự tin trả lời mọi câu hỏi kỹ thuật trong danh sách này, khóa học Data Engineer tại Cole bao gồm toàn bộ kiến thức từ SQL, Python, ETL pipeline đến AWS và data warehouse — được dạy bởi người đang làm thực tế trong ngành.

Tìm hiểu thêm:

Khóa học Data Engineer tại Cole – Chuẩn bị đầy đủ kỹ năng để pass mọi vòng phỏng vấn

Quy Trình Tuyển Dụng Data Engineer – Chi Tiết 3–4 Vòng Cần Chuẩn Bị

Thực Tập Data Engineer Cần Những Kiến Thức Gì?

Công Việc Của Data Engineer Là Gì? Phân Tích Chi Tiết

ETL Pipeline Là Gì? Quy Trình Xử Lý Dữ Liệu Hiệu Quả

Lộ Trình Data Engineer Roadmap 2026 – 7 Phương Pháp Chuẩn

Khóa Học SQL thực chiến tại Cole – Nền tảng không thể thiếu để pass SQL test