Bỏ qua nội dung

Interview Preparation (Chuẩn bị phỏng vấn Data Engineer)

Phỏng vấn Data Engineer thường không kiểm tra bạn thuộc bao nhiêu công cụ. Họ muốn biết bạn có hiểu dữ liệu, code có chắc không, thiết kế pipeline có thực tế không, và khi production hỏng bạn có xử lý bình tĩnh không.

Hãy ôn theo năng lực, không ôn theo câu hỏi mẹo.

Bốn mảng cần chuẩn bị

MảngMục tiêuCách luyện
SQLViết query đúng grain, đúng logic, tối ưu vừa đủWindow function, dedup, sessionization, cohort
CodingPython sạch, xử lý file/API, edge casesBài nhỏ về parsing, grouping, streaming file
Data system designThiết kế pipeline end-to-endBatch, streaming, CDC, warehouse, observability
Production troubleshootingĐiều tra lỗi có thứ tựLog, metrics, freshness, retry, rollback

1. SQL: vòng giữ cửa

SQL là phần dễ bị đánh giá nhất vì kết quả đúng/sai rõ. Hãy luyện:

  • Dedup theo row_number().
  • Running total, rolling window.
  • Top-N per group.
  • Funnel conversion.
  • Slowly changing dimension.
  • Reconciliation giữa hai nguồn.

Khi giải, nói rõ grain trước. Ví dụ: “Em sẽ tạo một dòng cho mỗi user mỗi ngày trước, sau đó mới aggregate theo tuần.” Câu đó cho thấy bạn hiểu dữ liệu, không chỉ biết cú pháp.

Hai pattern chiếm tỷ lệ ra đề cao nhất, nên viết được không cần nghĩ:

-- Pattern 1: Dedup giữ bản ghi mới nhất (xuất hiện ở ~50% vòng SQL)
SELECT * FROM (
SELECT *, ROW_NUMBER() OVER (
PARTITION BY user_id ORDER BY updated_at DESC) AS rn
FROM user_events
) t WHERE rn = 1;
-- Pattern 2: Top-N per group
SELECT * FROM (
SELECT *, DENSE_RANK() OVER (
PARTITION BY category ORDER BY revenue DESC) AS rk
FROM product_sales
) t WHERE rk <= 3;

Và chuẩn bị trả lời câu hỏi nối tiếp gần như chắc chắn sẽ đến: “vì sao dùng ROW_NUMBER mà không phải RANK/DENSE_RANK?” (ROW_NUMBER không bao giờ trùng số → dedup an toàn; RANK nhảy số khi hòa; DENSE_RANK không nhảy — chọn theo việc bạn muốn xử lý tie thế nào). Luyện đầy đủ theo bài SQL Interview Patterns.

Ôn trong site: SQL Transformation, Grain, Fact Table, Slowly Changing Dimension.

2. Python coding

Các bài coding Data Engineering thường gần với công việc hơn LeetCode thuần:

  • Parse log thành record có schema.
  • Đọc file lớn theo dòng, không load toàn bộ vào RAM.
  • Gom nhóm sự kiện theo key.
  • Retry API có backoff.
  • Validate record và tách bad rows.

Tiêu chí chấm thường gồm: code rõ, xử lý edge case, test được, không dùng memory vô tội vạ.

Ôn trong site: Data Extraction, Deduplication, Idempotency, Data Quality.

3. Data system design

Một đề phổ biến: “Thiết kế pipeline cho clickstream/e-commerce/payment/fraud detection.”

Khung trả lời:

  1. Làm rõ yêu cầu: batch hay realtime, độ trễ, volume, độ chính xác, người dùng downstream.
  2. Nguồn dữ liệu: API, database, event, file, CDC.
  3. Ingestion: queue, object storage, raw zone, schema registry nếu cần.
  4. Processing: batch/stream, transformation, data quality.
  5. Storage: warehouse/lakehouse/OLAP serving.
  6. Observability: freshness, volume, error rate, lineage, alert.
  7. Failure mode: retry, backfill, late data, duplicate, rollback.
  8. Security và cost: quyền truy cập, PII, retention, partitioning.

Ôn trong site: Data Pipeline, Lambda Architecture, Kappa Architecture, Change Data Capture, Data Warehouse, Lakehouse.

flowchart LR
    A["Sources"] --> B["Ingestion"]
    B --> C["Raw storage"]
    C --> D["Transform / Enrich"]
    D --> E["Warehouse / Lakehouse"]
    E --> F["BI / ML / Apps"]
    D --> G["Tests and observability"]

4. Production troubleshooting

Đừng trả lời sự cố bằng “em sẽ check log” rồi dừng lại. Hãy có thứ tự:

  1. Xác định tác động: bảng nào sai, dashboard nào trễ, ai bị ảnh hưởng.
  2. Khoanh vùng thời gian: bắt đầu từ run nào, source nào đổi.
  3. Kiểm tra triệu chứng: freshness, volume, schema, error rate, cost spike.
  4. Mitigate trước: tạm dừng downstream, rollback model, rerun partition nhỏ, dùng snapshot cũ nếu cần.
  5. Tìm nguyên nhân: code change, source change, infra, credential, data skew.
  6. Viết follow-up: test mới, alert mới, runbook mới.

Google SRE nhấn mạnh monitoring nên ưu tiên tín hiệu gắn với hành động và tác động người dùng, không chỉ gom thật nhiều metric: Monitoring Distributed Systems. Trong phỏng vấn, hãy thể hiện bạn biết bảo vệ thời gian của người trực on-call.

Ôn trong site: Alerting Incident Response, Data Observability, Freshness Monitoring, Root Cause Analysis, Schema Drift.

Checklist đọc concept

Vòng phỏng vấnConcept nội bộ cần đọc
SQLSQL Transformation, Grain, Slowly Changing Dimension
Coding dữ liệuIdempotency, Deduplication, Data Quality
System designData Pipeline, Data Warehouse, Lakehouse, Apache Kafka
TroubleshootingData Observability, Alerting Incident Response, Root Cause Analysis

Kế hoạch ôn 4 tuần

TuầnTrọng tâmSản phẩm
1SQL25 bài SQL, ghi lại pattern hay sai
2Python5 bài file/API/log processing có test
3System design3 thiết kế pipeline dạng document 1-2 trang
4Troubleshooting5 tình huống sự cố, luyện nói thành quy trình

Câu hỏi tự luyện

  • Dữ liệu clickstream đến muộn 30 phút, dashboard realtime xử lý thế nào?
  • Job Spark chạy chậm gấp 5 lần từ hôm qua, bạn điều tra gì trước?
  • Làm sao thiết kế incremental model không mất dữ liệu update?
  • Khi nào dùng Kafka, khi nào chỉ cần batch file?
  • Nếu business nói số doanh thu sai, bạn reconcile từ đâu?

References

Bình luận & Thảo luận