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ảng | Mục tiêu | Cách luyện |
|---|---|---|
| SQL | Viết query đúng grain, đúng logic, tối ưu vừa đủ | Window function, dedup, sessionization, cohort |
| Coding | Python sạch, xử lý file/API, edge cases | Bài nhỏ về parsing, grouping, streaming file |
| Data system design | Thiết kế pipeline end-to-end | Batch, 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 groupSELECT * 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:
- Làm rõ yêu cầu: batch hay realtime, độ trễ, volume, độ chính xác, người dùng downstream.
- Nguồn dữ liệu: API, database, event, file, CDC.
- Ingestion: queue, object storage, raw zone, schema registry nếu cần.
- Processing: batch/stream, transformation, data quality.
- Storage: warehouse/lakehouse/OLAP serving.
- Observability: freshness, volume, error rate, lineage, alert.
- Failure mode: retry, backfill, late data, duplicate, rollback.
- 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ự:
- Xác định tác động: bảng nào sai, dashboard nào trễ, ai bị ảnh hưởng.
- Khoanh vùng thời gian: bắt đầu từ run nào, source nào đổi.
- Kiểm tra triệu chứng: freshness, volume, schema, error rate, cost spike.
- Mitigate trước: tạm dừng downstream, rollback model, rerun partition nhỏ, dùng snapshot cũ nếu cần.
- Tìm nguyên nhân: code change, source change, infra, credential, data skew.
- 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ấn | Concept nội bộ cần đọc |
|---|---|
| SQL | SQL Transformation, Grain, Slowly Changing Dimension |
| Coding dữ liệu | Idempotency, Deduplication, Data Quality |
| System design | Data Pipeline, Data Warehouse, Lakehouse, Apache Kafka |
| Troubleshooting | Data Observability, Alerting Incident Response, Root Cause Analysis |
Kế hoạch ôn 4 tuần
| Tuần | Trọng tâm | Sản phẩm |
|---|---|---|
| 1 | SQL | 25 bài SQL, ghi lại pattern hay sai |
| 2 | Python | 5 bài file/API/log processing có test |
| 3 | System design | 3 thiết kế pipeline dạng document 1-2 trang |
| 4 | Troubleshooting | 5 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
- PostgreSQL SQL Tutorial - PostgreSQL Global Development Group.
- The Python Tutorial - Python Software Foundation.
- Apache Spark Documentation - Apache Software Foundation.
- Apache Kafka Documentation - Apache Software Foundation.
- Monitoring Distributed Systems - Google SRE.
- DORA metrics - DORA.
Bình luận & Thảo luận