Phỏng Vấn Data Engineer & AI/ML Engineer: Các Câu Hỏi Kỹ Thuật Quan Trọng Nhất - Pipeline Của Bạn Có 'Sạch' Không?
Mục lục bài viết
Tags: data engineer, ai ml engineer, phỏng vấn kỹ thuật, pipeline, sql
Gần đây, một anh chàng data engineer có 4 năm kinh nghiệm - khoe CV đầy Kafka, Spark, Snowflake - đổ rồi ở vòng system design. Lý do: khi được hỏi "Pipeline của bạn gặp lỗi ở 3 giờ sáng, bạn debug thế nào?" - anh trả lời bằng một đoạn generic về logging. Không có checkpoint strategy. Không có backfill plan. Không có idempotency design.
Kết quả: reject.
Pipeline không "sạch" - đó là lý do phỏng vấn viên đánh trượt anh ta. Và đây là loại câu hỏi đang được hỏi ngày càng nhiều trong các vòng phỏng vấn Data Engineer và AI/ML Engineer 2026.
Bài viết này tổng hợp các câu hỏi kỹ thuật quan trọng nhất ở cả hai track, kèm theo đó là cách tiếp cận để bạn không rơi vào bẫy tương tự.
1. Data Engineer: Thiết Kế Pipeline Có Idempotent Không?
Idempotent là từ xuất hiện trong hầu hết các vòng phỏng vấn Data Engineer năm 2026. Nhưng câu hỏi thực sự không phải là "bạn có biết idempotent là gì" - mà là "bạn đã thiết kế pipeline nào theo cách đó".
Câu hỏi thực tế được hỏi nhiều nhất:
"Walk me through cách bạn build một pipeline pull data từ paginated REST API, handle rate limit, và land data vào warehouse - sao cho rerun không tạo duplicate."
Câu trả lời được đánh giá cao:
- Lưu pagination state bên ngoài (external offset) để restart không mất progress
- Exponential backoff with jitter khi gặp HTTP 429
- Ghi vào staging table với deterministic hash key trên source record - không append đơn thuần
- Merge vào production table bằng hash để dedup - an toàn khi rerun
- Transaction semantics: nếu merge fail, không có record nào được insert
Sai lầm phổ biến: nhảy thẳng vào requests.get code mà không đề cập idempotency. Đó là flag đỏ lớn cho interviewers - vì nó cho thấy ứng viên chưa từng bị paged lúc 3am vì pipeline chạy hai lần và nhân ba revenue dashboard.
Câu hỏi mở rộng thường gặp:
- "Schema của upstream API thay đổi từ string sang object. Pipeline bắt đầu fail. Bạn xử lý thế nào trong 1 giờ đầu?"
- "Backfill cần reprocess 9 tháng data mà không break dashboard. Strategy của bạn là gì?"
2. Data Engineer: SQL Ở Production Scale - Không Phải Toy Table
👉 Luyện tập câu hỏi SQL production scale phỏng vấn Data Engineer tại X Interview!
SQL là nền tảng nhưng câu hỏi phỏng vấn Data Engineer 2026 không còn ở mức "viết JOIN đi". Họ hỏi sâu hơn nhiều.
Những pattern được kiểm tra:
- Window functions: phân vùng theo thứ tự, frame clause, tích lũy (cumulative sum), lag/lead - và đặc biệt là hiểu khi nào dùng
RANK()vsDENSE_RANK()vsROW_NUMBER()khi có tie. - Anti-join: tìm records không tồn tại trong table khác, ví dụ users chưa có order nào.
- Deduplication logic: xử lý duplicate trên composite key với nhiều cách - ROW_NUMBER, GROUP BY, DISTINCT ON - và biết performance khác nhau ra sao trên 10TB data.
- Slowly Changing Dimensions (SCD): Type 2 implementation - cách xử lý khi một dimension record thay đổi và bạn cần lưu lịch sử.
Câu hỏi production thực tế:
`
Viết SQL query để tìm top 3 sản phẩm theo doanh thu trong mỗi region 30 ngày gần nhất.
`
Follow-up: "Hai sản phẩm cùng doanh thu thì sao?" → Dùng DENSE_RANK() thay vì ROW_NUMBER().
Follow-up: "Query chạy trên 10TB thì optimize thế nào?" → Partition theo region + date, clustering key trên product_id, cover index.
3. Data Engineer: Spark Internals - Shuffle, Skew, và Memory
👉 Thực hành câu hỏi Spark và Big Data với X Interview!
Nếu công ty đang dùng Databricks, Snowflake, hoặc bất kỳ lakehouse nào ở quy mô petabyte - họ sẽ hỏi về Spark. Và không phải ở mức DataFrame syntax.
Câu hỏi hard nhất:
"Điều gì gây shuffle trong Spark? Tại sao nó đắt? Làm sao mitigate?"
Shuffle xảy ra khi data cần tái phân bố qua các executor - ví dụ sau groupBy, join, distinct, repartition. Mỗi shuffle là I/O disk, network serialization, và tăng latency đáng kể.
Các chiến lược mitigate được interviewers đánh giá:
- Broadcast join cho small table:
broadcast(smallDf)- tránh shuffle hoàn toàn - Pre-partition data trên join key trước khi join
- Dùng
reduceByKeythay vìgroupByKey-reduceByKeycombine locally trước, giảm shuffle volume - Tăng
spark.sql.shuffle.partitionscho dataset lớn - Xử lý data skew: split skewed partition, salting technique
Câu hỏi tiếp theo thường là:
- "Cache() và persist() khác nhau thế nào?" →
persist()cho phép chọn storage level,cache()mặc định MEMORY_ONLY - "Spark job fail với OOM. Bạn debug thế nào?" → Đọc executor logs, kiểm tra spill-to-disk, partition size distribution, garbage collection overhead
4. Batch vs Streaming: Chiến Khung Quyết Định, Không Phải Tool Preference
Đây là fork đầu tiên trong hầu hết pipeline architecture interview. Ứng viên nhảy thẳng vào Kafka = automatic fail.
Framework đúng:
Bước 1: Hỏi về latency requirement thực sự
- 500ms → true streaming (Flink)
- 5 phút → micro-batch (Spark Structured Streaming)
- 15 phút trở lên → scheduled batch (Airflow + dbt)
Bước 2: Cost heuristic
- Daily batch job: ~20 phút runtime, ~$5/ngày
- Always-on streaming: ~$500/ngày + dedicated on-call
- Ratio: 100x cost cho real-time. Business value có justify được không?
Bước 3: Reprocessing story
- Kappa architecture sweet spot: 30-90 ngày retention
- Ngoài 90 ngày: batch reprocessing rẻ hơn replay streaming
Câu hỏi cụ thể:
"Khi nào nên dùng Lambda architecture? Khi nào dùng Kappa? Ưu nhược điểm?"
- Lambda: song song batch + speed layer, operational nightmare vì hai codebase cùng logic, dễ diverge
- Kappa: replay qua Kafka, đơn giản nhưng replay petabyte data có thể chậm và đắt hơn batch
Lambda vs Kappa không phải câu hỏi đúng/sai - nó là câu hỏi về decision framework. Interviewers muốn thấy bạn hỏi trước, không phải đưa ra architecture preference.
5. AI/ML Engineer: ML System Design - Từ Problem Formulation Đến Monitoring
👉 Ôn luyện câu hỏi ML System Design phỏng vấn AI/ML Engineer tại X Interview!
ML system design interview là vòng mà nhiều researcher giỏi fail vì approach như research problem thay vì engineering problem.
Framework 6 bước đúng:
- Clarify Problem: ML formulation (classification? ranking? regression?), proxy metric, business metric
- Data: Training data sources, labeling strategy, feature engineering, data pipeline
- Modeling: Model selection, loss function, training infrastructure
- Evaluation: Offline metrics (AUC, NDCG), online metrics (A/B test)
- Serving & Inference: Latency budget, batch vs real-time, serving infrastructure
- Monitoring & Retraining: Model drift detection, retraining triggers, MLOps
Câu hỏi phổ biến nhất 2026:
"Design một fraud detection system với latency < 50ms, handle 50,000 transactions/giây, minimize false positives."
Điểm quan trọng cần đề cập:
- Class imbalance: fraud rate < 0.1%. Naive model đạt 99.9% accuracy nhưng zero utility
- Feature store: không thể compute mọi feature inline ở 50ms. Cần pre-compute và cache
- Two-tier ranking: lightweight model filter trước, complex model only on top candidates
- Latency breakdown: feature fetch 1-5ms, model inference 10-30ms, network 10-20ms
- Monitoring: track false positive rate, false negative rate, prediction score distribution
Câu hỏi drift detection:
"Model precision drop overnight từ 91% xuống 76%. Bạn debug trong 1 giờ đầu như thế nào?"
Answer framework:
- Tách "model broken" vs "data different" vs "label collection process changed"
- Kiểm tra monitoring có sẵn trước - không đánh giá từ đầu
- Monitor prediction distribution bằng PSI (Population Stability Index) hoặc KL divergence
6. AI/ML Engineer: Feature Store và Training-Serving Skew
👉 Luyện tập câu hỏi Feature Store và Training-Serving Skew tại X Interview!
Feature store là nơi nhiều ML system fail trong production - và cũng là nơi interviewers đào sâu nhất.
Tại sao feature store quan trọng:
Không có feature store: model train trên feature definition A nhưng serve predictions dùng feature definition B hơi khác → silent performance degradation.
Điều cần cover:
- Offline vs online feature parity: training và serving phải dùng same feature logic - một codebase duy nhất
- Point-in-time joins: đảm bảo training không leak future data
- Feature versioning: khi schema thay đổi, old model vẫn có thể reproduce được
- CDC patterns: change data capture từ source → push vào cả offline (warehouse) và online (Redis/DynamoDB) feature stores
Câu hỏi về MLOps và versioning:
- "How do you version a model?" → Weights, training code, training data, feature extraction code, environment
- "Rollback plan cho model ngày mai ship?" → Blue-green, shadow deploy, canary - không phải "retrain"
Monitoring checklist thực tế:
- Feature availability < 95%
- Input distribution drift (PSI > 0.1)
- Prediction distribution shift
- Latency P95 exceed 100ms
- Ground truth arrival lag
7. Case Study: Câu Chuyện Từ Một Pipeline Thất Bại
Một team data engineer tại startup e-commerce thiết kế pipeline ingest 2 triệu events/ngày vào BigQuery. Mọi thứ hoạt động smooth ở môi trường dev.
3 tháng sau, dashboard báo sai. Revenue report lệch 18%. Investigation kéo dài 2 tuần.
Root cause:
- Pipeline landing raw events vào BigQuery, sau đó dbt transform
- Transform dùng
MERGEstatement vớiupdated_atlà dedup key - Nhưng một job phía upstream viết lại
updated_atcho tất cả historical records khi reprocess MERGEinterpret sai - không merge mà overwrite toàn bộ
Lesson:
- Pipeline không idempotent: rerun không produce same result
- Không có data lineage → không biết dashboard đọc từ đâu
- Missing data quality check: không ai verify revenue total sau mỗi run
Interviewers hỏi về failure scenarios vì đó là cách tốt nhất để đánh giá production experience thực sự. Candidate nào chỉ describe happy path = chưa từng vận hành hệ thống thực.
8. Tổng Hợp Câu Hỏi Ôn Tập Quan Trọng
Dưới đây là tổng hợp những câu hỏi kỹ thuật được hỏi nhiều nhất trong các vòng Data Engineer và AI/ML Engineer 2026:
Data Engineer:
- Thiết kế idempotent pipeline từ paginated API → warehouse
- Schema upstream API thay đổi - pipeline fail. Xử lý 1 giờ đầu?
- Backfill 9 tháng data không break dashboard
- Spark shuffle: tại sao đắt, cách mitigate
- Batch vs streaming decision framework - không phải tool preference
- Lambda vs Kappa: khi nào dùng, ưu nhược điểm
- CDC patterns và watermark-based incremental processing
- Data quality check: implement ở đâu, check gì
AI/ML Engineer:
- Design fraud detection với 50ms latency, 50K TPS
- Feature store: offline + online parity, point-in-time joins
- Training-serving skew: cách phát hiện và xử lý
- Model drift detection: PSI, KL divergence, monitoring checklist
- Rollback plan cho ML model in production
- A/B testing framework cho ML model
- Retraining triggers: time-based vs performance-based
- ML system design: recommendation system end-to-end
Tài liệu tham khảo
- Apache Spark Documentation
- Amazon Redshift Documentation
- TensorFlow Guide
- Hugging Face Documentation
Kết Bài
Câu hỏi phỏng vấn Data Engineer và AI/ML Engineer năm 2026 đã thay đổi đáng kể so với 3-4 năm trước. Không còn là "bạn biết Kafka không?" hay "viết SQL JOIN đi". Các vòng technical giờ tập trung vào:
- Production judgment: bạn đã vận hành hệ thống thực, không chỉ build demo
- Trade-off reasoning: batch vs streaming, cost vs latency, simple vs flexible
- Failure thinking: bạn thiết kế cho failure case, không phải happy path
- Operational depth: debugging instinct, backfill strategy, rollback plan
Pipeline "sạch" không phải là không có bug - mà là hệ thống mà khi fail, bạn biết chính xác đang có vấn đề gì, đang ở đâu, và cách fix trong thời gian ngắn nhất.
Đó cũng chính là lý do interviewers hỏi những câu hỏi kiểu này.
Bạn có thể đọc thêm: Bộ Câu Hỏi Phỏng Vấn DevOps & Cloud Engineer 2026 Kèm Trả Lời Mẫu - cùng chuyên mục kỹ thuật, giúp bạn ôn tập thêm các câu hỏi về system failure và operational scenarios.
👉 Luyện tập trả lời câu hỏi tại x-interview.com/mypage/questions