Bỏ qua

Chiến lược trả lời khi chưa hiểu sâu

🔴 Rất quan trọng · Lời khuyên


Tình huống thực tế

Rất nhiều bạn 1 năm kinh nghiệm đã dùng Spark/SQL hàng ngày, nhưng chủ yếu viết code theo pattern có sẵn, chưa thực sự hiểu sâu bên dưới. Đây là chuyện bình thường — quan trọng là cách bạn thể hiện.

❌ Không nên

Interviewer hỏi Trả lời sai
"Spark có thành phần nào?" "Dạ, có DataFrame, có RDD ạ." — Quá sơ sài
"Tune Spark job thế nào?" "Em tăng memory ạ." — Không có logic
"Broadcast join là gì?" "Em chưa biết ạ." — Mất điểm dù có thể đã dùng

✅ Nên làm

Công thức trả lời khi chưa chắc

  1. Nói những gì mình biết — Trình bày phần đã hiểu, dù chưa đầy đủ
  2. Kể case thực tế — "Trong dự án em đã gặp..." chứng tỏ kinh nghiệm thật
  3. Thành thật về giới hạn — "Phần này em chưa tìm hiểu sâu, nhưng em hiểu cơ bản là..."
  4. Thể hiện hướng tiếp cận — "Nếu gặp vấn đề này, em sẽ vào Spark UI check trước, rồi..."

Ví dụ trả lời tốt

Q: "Broadcast join là gì?"

"Theo em hiểu, khi join 2 bảng mà 1 bảng nhỏ, Spark sẽ copy bảng nhỏ đó lên tất cả executor thay vì shuffle bảng lớn. Như vậy tránh được việc di chuyển dữ liệu lớn qua mạng. Em đã dùng khi join bảng dim nhỏ với bảng fact lớn, thấy job nhanh hơn rõ rệt."

5 thứ nên hiểu rõ trước khi phỏng vấn

Dù chưa tune job bao giờ, nắm 5 điều này là đủ trả lời 80% câu hỏi Spark:

Chủ đề Cần hiểu
Spark UI Biết mở, đọc được stage nào lâu, shuffle bao nhiêu, task nào skew
Shuffle Là gì, tại sao chậm, cách giảm (broadcast join, filter sớm)
Partition Shuffle partition (memory) vs disk partition (partitionBy). Kiểm soát số file
Data skew 1 key quá nhiều data = 1 task chạy lâu. Giải pháp: salting, repartition
Broadcast vs Sort-merge Bảng nhỏ + lớn = broadcast. Bảng lớn + lớn = sort-merge

💡 Điểm mấu chốt

Interviewer 1 năm kinh nghiệm không kỳ vọng bạn là expert. Họ muốn thấy: 1. Bạn đã thực sự dùng, không phải chỉ đọc sách 2. Bạn có tư duy debug khi gặp vấn đề 3. Bạn biết giới hạn và sẵn sàng học

Comments