Ôn phỏng vấn Data Engineer & Data Analyst

Ôn phỏng vấn

Câu hỏi phỏng vấn Data Engineer & Data Analyst thường gặp (kèm gợi ý trả lời)

Câu hỏi phỏng vấn Data Engineer và Data Analyst: SQL, ETL/ELT, Spark, mô hình dữ liệu, chỉ số và dashboard, kèm gợi ý trả lời. Gồm 12 câu do Drama Công Ty biên soạn: đọc ý chính rồi tự trả lời bằng ví dụ từ dự án của bạn.

  1. 01Các loại JOIN trong SQL khác nhau thế nào? Khi nào kết quả JOIN bị nhân bản dòng?Junior

    Gợi ý trả lời

    INNER JOIN chỉ giữ dòng khớp ở cả hai bảng; LEFT JOIN giữ mọi dòng bảng trái, phía phải không khớp thì NULL; FULL OUTER JOIN giữ tất cả; CROSS JOIN ghép mọi cặp.

    Dòng bị nhân bản khi khoá join không duy nhất ở một phía (quan hệ một-nhiều hoặc nhiều-nhiều). Ví dụ join orders với payments khi một đơn có nhiều lần thanh toán, rồi SUM(order_amount) sẽ bị cộng trùng.

    • Kiểm tra độ duy nhất của khoá trước khi join.
    • Gộp (aggregate) bảng chi tiết trước rồi mới join.

    Hay sai: đặt điều kiện lọc bảng phải trong WHERE sau LEFT JOIN, vô tình biến nó thành INNER JOIN; nên đặt trong ON.

  2. 02WHERE khác HAVING thế nào? Thứ tự thực thi logic của một câu SELECT là gì?Junior

    Gợi ý trả lời

    WHERE lọc từng dòng trước khi gộp nhóm; HAVING lọc nhóm sau khi đã GROUP BY và tính hàm tổng hợp.

    Thứ tự logic: FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT.

    SELECT customer_id, COUNT(*) AS orders
FROM orders
WHERE created_at >= DATE '2026-01-01'
GROUP BY customer_id
HAVING COUNT(*) >= 3;

    Hay sai: dùng alias định nghĩa trong SELECT ngay ở WHERE (đa số hệ quản trị báo lỗi), hoặc lọc điều kiện dòng bằng HAVING làm truy vấn chậm hơn.

  3. 03Window function là gì? Viết truy vấn lấy đơn hàng gần nhất của mỗi khách hàng.Junior

    Gợi ý trả lời

    Window function tính toán trên một nhóm dòng liên quan mà không gộp mất dòng như GROUP BY. Hay dùng: ROW_NUMBER, RANK, LAG/LEAD, tổng luỹ kế SUM() OVER.

    SELECT *
FROM (
  SELECT o.*, ROW_NUMBER() OVER (
    PARTITION BY customer_id ORDER BY created_at DESC
  ) AS rn
  FROM orders o
) t
WHERE rn = 1;
    • ROW_NUMBER cho số duy nhất; RANK cho cùng hạng khi bằng nhau và nhảy số; DENSE_RANK không nhảy số.
    • LAG để so sánh với kỳ trước, ví dụ doanh thu tháng này so với tháng trước.

    Hay sai: ORDER BY không xác định duy nhất khiến kết quả thay đổi giữa các lần chạy.

  4. 04ETL khác ELT thế nào? Vì sao ELT phổ biến hơn với data warehouse hiện đại?Junior

    Gợi ý trả lời

    ETL biến đổi dữ liệu trước khi nạp vào kho; ELT nạp dữ liệu thô vào kho trước rồi biến đổi ngay trong kho bằng SQL.

    ELT phổ biến vì:

    • Warehouse/lakehouse trên cloud (BigQuery, Snowflake, Databricks) tính toán mạnh và co giãn.
    • Giữ được dữ liệu thô, khi đổi logic có thể chạy lại.
    • Biến đổi viết bằng SQL, quản lý bằng công cụ như dbt có version, test, tài liệu.

    ETL vẫn hợp khi phải loại bỏ dữ liệu nhạy cảm trước khi vào kho, hoặc nguồn quá lớn cần lọc bớt.

    Người phỏng vấn muốn nghe: tổ chức theo lớp (raw, staging, mart hoặc bronze, silver, gold).

  5. 05Star schema là gì? Phân biệt bảng fact và bảng dimension.

    Gợi ý trả lời

    Star schema là mô hình dữ liệu cho phân tích: một bảng fact ở giữa nối với nhiều bảng dimension xung quanh, giúp truy vấn đơn giản và nhanh.

    • Fact: ghi các sự kiện đo đếm được (đơn hàng, lượt xem), chứa số đo (số tiền, số lượng) và khoá ngoại tới dimension. Thường rất nhiều dòng.
    • Dimension: mô tả ngữ cảnh (khách hàng, sản phẩm, ngày, cửa hàng), ít dòng, nhiều cột thuộc tính.
    • Phải xác định rõ grain: mỗi dòng fact là gì (một đơn hay một dòng sản phẩm trong đơn).

    Hay sai: trộn nhiều grain trong một bảng fact, dẫn đến cộng trùng khi tổng hợp.

  6. 06Slowly Changing Dimension (SCD) là gì? So sánh SCD Type 1 và Type 2.

    Gợi ý trả lời

    SCD là cách xử lý khi thuộc tính của dimension thay đổi theo thời gian, ví dụ khách hàng chuyển thành phố hoặc đổi hạng thành viên.

    • Type 1: ghi đè giá trị cũ. Đơn giản nhưng mất lịch sử; báo cáo quá khứ hiển thị theo giá trị mới.
    • Type 2: thêm dòng mới cho mỗi thay đổi, kèm valid_from, valid_to, is_current và surrogate key. Giữ được lịch sử, fact trỏ đúng phiên bản tại thời điểm phát sinh.

    Chọn Type 2 khi nghiệp vụ cần phân tích theo trạng thái lúc xảy ra (doanh thu theo hạng khách hàng lúc mua).

    Hay sai: join fact với dimension Type 2 mà quên điều kiện thời gian hoặc is_current, làm nhân bản dòng.

  7. 07Một job Spark chạy rất chậm, vài task chạy mãi không xong. Bạn chẩn đoán và xử lý thế nào?

    Gợi ý trả lời

    Vài task chậm hơn hẳn phần còn lại thường là data skew: một khoá chiếm phần lớn dữ liệu, dồn vào một partition.

    Chẩn đoán qua Spark UI: xem stage chậm, so sánh thời gian và dung lượng shuffle giữa các task, có spill ra đĩa không.

    Cách xử lý:

    • Bật Adaptive Query Execution (mặc định bật ở Spark 3.2+) để tự tách partition bị lệch.
    • Broadcast bảng nhỏ khi join để tránh shuffle.
    • Thêm salt vào khoá nóng rồi gộp lại.
    • Lọc dữ liệu và chọn cột sớm, tránh collect() về driver.
    • Điều chỉnh số partition; xử lý vấn đề quá nhiều file nhỏ.

    Người phỏng vấn muốn nghe: đo bằng Spark UI trước, không tăng tài nguyên một cách mù quáng.

  8. 08Doanh thu hôm nay giảm 30% so với hôm qua. Bạn phân tích nguyên nhân thế nào?

    Gợi ý trả lời

    Trước tiên kiểm tra dữ liệu có đúng không, rồi mới phân tích nghiệp vụ.

    1. Dữ liệu: pipeline có chạy đủ không, dữ liệu đến trễ, có thay đổi tracking hay định nghĩa chỉ số không.
    2. So sánh hợp lý: cùng thứ trong tuần trước, có ngày lễ, khuyến mãi hôm qua không.
    3. Phân rã chỉ số: doanh thu = số người dùng × tỷ lệ chuyển đổi × giá trị đơn trung bình; xem thành phần nào giảm.
    4. Cắt lát: theo kênh, nền tảng, khu vực, sản phẩm, phiên bản app để khoanh vùng.
    5. Đối chiếu sự kiện: deploy mới, lỗi thanh toán, đối thủ, chiến dịch quảng cáo dừng.

    Người phỏng vấn muốn nghe: cách tiếp cận có cấu trúc và kết luận đi kèm đề xuất hành động.

  9. 09Bạn thiết kế pipeline dữ liệu thế nào để chạy lại an toàn (idempotent) và xử lý dữ liệu đến trễ?Senior

    Gợi ý trả lời

    Idempotent nghĩa là chạy lại cùng một khoảng dữ liệu bao nhiêu lần cũng cho kết quả giống nhau, không trùng, không mất.

    • Xử lý theo partition thời gian; ghi bằng ghi đè partition hoặc MERGE theo khoá, không INSERT nối thêm mù quáng.
    • Tham số hoá job theo ngày logic (ví dụ data_interval_start trong Airflow) thay vì dùng giờ hiện tại.
    • Dữ liệu đến trễ: lùi cửa sổ xử lý lại vài ngày gần nhất, hoặc dùng watermark với streaming.
    • Khử trùng lặp theo khoá sự kiện.
    • Hỗ trợ backfill có kiểm soát.

    Hay sai: dùng now() trong logic khiến chạy lại hôm khác ra kết quả khác.

  10. 10Bạn đảm bảo chất lượng dữ liệu (data quality) trong hệ thống thế nào?Senior

    Gợi ý trả lời

    Chất lượng dữ liệu cần được kiểm tra tự động ở từng lớp và có người chịu trách nhiệm, không chỉ phát hiện khi dashboard sai.

    • Test trong pipeline: not null, unique, giá trị hợp lệ, quan hệ khoá ngoại (dbt tests, Great Expectations).
    • Giám sát: độ tươi (dữ liệu có cập nhật đúng giờ), số dòng bất thường, phân phối giá trị thay đổi đột ngột.
    • Data contract với team nguồn: schema và ý nghĩa cột, thay đổi phải báo trước.
    • Lỗi nghiêm trọng thì dừng pipeline, không đẩy dữ liệu sai xuống báo cáo.
    • Lineage để biết lỗi ở nguồn ảnh hưởng tới bảng và dashboard nào.

    Người phỏng vấn muốn nghe: ví dụ cụ thể bạn từng phát hiện và xử lý một lỗi dữ liệu.

  11. 11Khi nào cần xử lý streaming thay vì batch? Thiết kế pipeline real-time cần lưu ý gì?Senior

    Gợi ý trả lời

    Chỉ chọn streaming khi nghiệp vụ thật sự cần độ trễ thấp (phát hiện gian lận, cảnh báo, cá nhân hoá tức thời); còn báo cáo theo giờ/ngày thì batch hoặc micro-batch rẻ và dễ vận hành hơn.

    Lưu ý khi làm streaming (Kafka, Flink, Spark Structured Streaming):

    • Ngữ nghĩa giao nhận: at-least-once phổ biến, cần sink idempotent để tránh trùng.
    • Event time và watermark để xử lý sự kiện đến trễ, sai thứ tự.
    • Quản lý state và checkpoint để khôi phục khi lỗi.
    • Thay đổi schema có kiểm soát (schema registry).
    • Giám sát consumer lag.

    Người phỏng vấn muốn nghe: cân nhắc chi phí vận hành, không chọn streaming chỉ vì "hiện đại".

  12. 12Sản phẩm chạy A/B test, nhóm B có tỷ lệ chuyển đổi cao hơn. Bạn kết luận thế nào cho đúng?Senior

    Gợi ý trả lời

    Không kết luận chỉ vì con số cao hơn; cần kiểm tra thiết kế thí nghiệm và ý nghĩa thống kê.

    • Chỉ số chính và cỡ mẫu phải được định trước; không nhìn kết quả liên tục rồi dừng khi thấy đẹp (peeking).
    • Kiểm tra sample ratio mismatch: tỷ lệ chia nhóm thực tế có khớp thiết kế không.
    • Xem khoảng tin cậy và p-value, không chỉ chênh lệch trung bình.
    • Chạy đủ chu kỳ (ít nhất trọn tuần) để tránh hiệu ứng ngày trong tuần, hiệu ứng mới lạ.
    • Kiểm tra chỉ số bảo vệ (guardrail): doanh thu, tỷ lệ huỷ, tốc độ trang.
    • Cẩn thận khi cắt quá nhiều phân khúc: dễ có kết quả "có ý nghĩa" do ngẫu nhiên.

    Người phỏng vấn muốn nghe: phân biệt ý nghĩa thống kê với ý nghĩa kinh doanh.

Gặp câu hỏi khác khi phỏng vấn? Kể lại ẩn danh để người sau ôn đúng trọng tâm, hoặc xem câu hỏi thật hay gặp ở nhiều công ty.