Trong quá trình phỏng vấn backend engineer tại Spotify, ngoài các vòng phổ biến như coding, system design và behavior, ứng viên sẽ gặp một vòng rất đặc biệt – case study round. Đây là vòng phỏng vấn mô phỏng tình huống trực on-call thực tế, nơi kỹ sư phải xử lý sự cố hệ thống khi mọi thứ có thể “đổ vỡ” bất ngờ.

Để hiểu rõ hơn về vòng này và cách chuẩn bị, chúng tôi đã có buổi trò chuyện với anh Hiệp, backend engineer tại Spotify, gần 3 năm kinh nghiệm làm việc ở Đức. Anh cũng là giảng viên khóa DSA tại Infinity Pro.

Anh có thể chia sẻ tổng quan về vòng này được không ạ?

Ở Spotify, vòng này thường đến sau vòng coding đầu tiên. Final interview sẽ có bốn phần: coding, system design, behavior và case study. Ở case study, giả định là hệ thống của bạn vừa phát ra một cảnh báo. Bạn sẽ không có nhiều thông tin ban đầu, chỉ biết là có vấn đề xảy ra. Lúc này nhiệm vụ của bạn là tìm hiểu chuyện gì đang diễn ra, tại sao lại có alert, rồi đưa ra hướng khắc phục hợp lý. Nó giống hệt công việc thực tế: bạn không được báo sẵn nguyên nhân, mà phải điều tra từng bước, từ dữ liệu ban đầu đến khi thu hẹp được gốc rễ sự cố.

Nghe có vẻ khá áp lực. Vậy theo anh, kỹ năng cốt lõi cần có để vượt qua vòng này là gì?

Anh nghĩ kỹ năng quan trọng nhất là khả năng suy luận và tư duy logic. Khi gặp một alert, bạn không thể lao vào đoán mò, mà cần bình tĩnh đặt ra các giả thuyết, rồi từng bước kiểm chứng để loại trừ dần. Ví dụ, nếu CPU tăng đột ngột, thì có thể do traffic tăng, cũng có thể do memory leak, hoặc do một đoạn code mới được deploy gây ra vòng lặp vô hạn. Việc của bạn là kiểm chứng từng khả năng bằng cách xem metric, đọc log, query database… Cứ đi từng bước như vậy, bạn sẽ dần thu hẹp phạm vi và tiến gần đến nguyên nhân thật.

Ngoài kỹ thuật, một yếu tố quan trọng khác là giao tiếp. Trong buổi phỏng vấn, interviewer chỉ đóng vai trò như hệ thống – bạn hỏi gì thì họ trả lời đúng câu hỏi đó. Họ không chủ động gợi ý. Nếu bạn không diễn đạt rõ suy nghĩ của mình, thì có khi interviewer chẳng biết phải cung cấp dữ liệu gì cho bạn. Do đó, việc nghĩ thành lời và trình bày rành mạch quá trình suy luận là cực kỳ quan trọng.

Vậy vòng này thường kiểm tra dạng lỗi nào ạ? Logic hay kỹ thuật cụ thể?

Thực ra thì không có một bộ lỗi cố định. Có thể là service báo lỗi 500, latency tăng bất thường, CPU hay memory vượt ngưỡng, hoặc một service phụ thuộc bên ngoài không phản hồi. Điểm chung là: ban đầu bạn không có nhiều thông tin. Nó giống như một bác sĩ khi bệnh nhân chỉ nói “em thấy mệt” – bạn phải hỏi nhiều câu để khoanh vùng vấn đề. Ví dụ, bạn sẽ tự đặt ra những câu như: “Lỗi này xảy ra với tất cả user hay chỉ một nhóm?”, “Có deployment nào vừa diễn ra không?”, “Lỗi xuất hiện ở tất cả server hay chỉ một node?”. Chính chuỗi câu hỏi này mới giúp bạn tiến đến câu trả lời.

Nếu em muốn chuẩn bị trước cho vòng này thì nên bắt đầu từ đâu ạ?

Vòng này gần như không có cách học tủ đâu. Nó giống hệt công việc hằng ngày của một backend engineer. Điều bạn có thể làm là ôn lại những công cụ cơ bản: cách kết nối server, cách đọc log, cách query database, làm quen với các metric dashboard như Grafana hoặc Datadog. Nếu có thời gian, bạn có thể tự tạo một service nhỏ, cố tình gây ra lỗi, rồi thử xử lý. Nhưng quan trọng nhất vẫn là cách suy nghĩ: khi gặp vấn đề, bạn liệt kê các khả năng, kiểm chứng dần, chứ không kết luận vội vàng. Đó là điều interviewer muốn thấy.

Có quy trình nào chung chung áp dụng cho hầu hết các trường hợp không ạ?

Anh thường đi theo mạch thế này: đầu tiên đọc alert để xem nó liên quan đến CPU, memory hay error rate. Sau đó nhìn triệu chứng – ví dụ metric graph có gì bất thường, log có lỗi gì lạ, có deployment gần đây không. Tiếp theo là khoanh vùng xem sự cố xảy ra ở đâu: toàn bộ service hay chỉ một phần. Rồi mới thu thập dữ liệu chi tiết hơn, đặt ra giả thuyết và kiểm chứng. Nghe thì có vẻ như một checklist, nhưng thực tế mỗi tình huống lại khác. Quy trình chỉ là khung, quan trọng nhất vẫn là tư duy suy luận.

Thế ứng viên hay mắc lỗi gì trong vòng này?

Anh thấy có mấy lỗi phổ biến. Một là đào quá sâu vào một giả thuyết khi chưa có đủ dữ liệu, dẫn đến mất phương hướng. Hai là nhảy đến kết luận quá nhanh, chưa có bằng chứng rõ ràng đã khẳng định nguyên nhân. Ba là hỏi interviewer để xin xác nhận – kiểu như “Anh nghĩ có phải do DB không?” – thì đó là sai. Interviewer chỉ giả lập hệ thống, họ không đưa ý kiến cá nhân. Nếu bạn nghi ngờ database, bạn phải nói: “Em muốn chạy query này để kiểm tra latency.” Như vậy mới đúng cách.

Nếu muốn tham khảo tài liệu thì có nguồn nào hữu ích không ạ?

Không có tài liệu viết riêng cho vòng này. Nhưng anh gợi ý đọc cuốn Site Reliability Engineering của Google, sách miễn phí và rất nổi tiếng. Nó không nhắm tới phỏng vấn, nhưng nói nhiều về cách Google vận hành hệ thống lớn và xử lý sự cố. Ngoài ra, blog kỹ thuật của các công ty như Netflix hay Uber cũng hay chia sẻ post-mortem về sự cố thực tế, đọc vào bạn sẽ học được cách người ta phân tích và rút kinh nghiệm.

Lời khuyên cuối cùng của anh cho ứng viên tham gia vòng này là gì?

Hãy nhớ rằng interviewer không mong chờ bạn tìm ra nguyên nhân cuối cùng bằng mọi giá. Cái họ muốn thấy là cách bạn tiếp cận vấn đề. Vì thế, hãy giữ suy luận chặt chẽ, nói rõ từng bước bạn đang nghĩ gì, và đừng ngại thay đổi hướng khi phát hiện giả thuyết ban đầu sai. Nếu thể hiện được sự logic và khả năng truyền đạt, bạn đã tạo được ấn tượng tốt rồi.

Qua câu chuyện của anh Hiệp, có thể thấy vòng case study ở Spotify không phải là một “bài test kỹ thuật” thông thường, mà là cơ hội để ứng viên thể hiện bản lĩnh của một kỹ sư thực sự: biết phân tích, suy luận và giao tiếp rõ ràng trong tình huống áp lực. Và đôi khi, điều quan trọng không nằm ở chỗ bạn tìm ra “đúng bệnh”, mà là cách bạn chứng minh rằng mình có thể làm việc có phương pháp giữa một môi trường phức tạp và nhiều biến số.