Phỏng vấn FDE cộng điểm khi bạn nói to rằng đã đoán sai

Bạn đang ở vòng cuối. Người phỏng vấn đóng vai khách hàng và mở đầu bằng một câu than phiền mù mờ. Mười giây sau, trong đầu bạn đã có một giả thuyết. Điều được chấm không chỉ là giả thuyết đó đúng hay sai, mà còn là bạn có nói nó ra không, và năm phút sau bạn có dám nói rằng nó sai không.

Đây không phải tình huống hiếm. Hướng dẫn phỏng vấn của Aced mô tả các vòng cuối của Cognition là những buổi mô phỏng khách hàng trực tiếp, chẳng hạn một buổi pitch với lãnh đạo hay một cuộc gọi case study.

Techinterview.org giải thích rằng phỏng vấn FDE mô phỏng đúng sự mơ hồ của công việc với khách hàng, nên phần lớn thời gian là nói chuyện chứ không phải gõ code. Một trong những điều vòng này kiểm tra là bạn có suy luận thành tiếng được không khi tình huống vẫn còn chưa rõ.

Nếu bạn quen phỏng vấn kiểu LeetCode, nơi chỉ có đáp án cuối được tính, bạn sẽ mất điểm ở chỗ không ngờ. Aced viết thẳng: người phỏng vấn chấm cách bạn tiến tới lời giải, không chấm việc bạn có tới được một lời giải cụ thể hay không. Việc của bạn là làm cho người chấm nghe được con đường đó.

Vì sao đoán sai lại được cộng điểm?

Hãy nhìn vòng này như một buổi debug. Theo techinterview.org, phỏng vấn FDE thưởng cho vòng debug có hệ thống: tái hiện lỗi, đặt giả thuyết, khoanh vùng, rồi xác minh cách sửa.

Cuốn SRE của Google mô tả troubleshooting theo đúng nhịp đó: lặp lại việc đưa ra các nguyên nhân có thể rồi kiểm tra chúng, dùng phương pháp thực nghiệm để giữ lại hoặc loại bỏ từng giả thuyết.

Trong vòng lặp ấy, loại bỏ một giả thuyết cũng là một bước tiến, giống như đặt giả thuyết. Cuốn SRE còn cảnh báo chuyện bám vào những nguyên nhân từng gặp trong quá khứ. Trong phòng phỏng vấn, cách dễ nhất để chứng tỏ bạn không mắc bệnh đó là để người chấm nghe bạn tự gạt đi một ý mà lúc đầu bạn tin.

Đó là lý do Aced khuyên coi câu trả lời đầu tiên là bản nháp, sửa dần khi có thông tin mới, và nhấn mạnh rằng quay lại sửa quyết định cũ là tín hiệu tốt chứ không phải điểm yếu.

Techinterview.org kể rằng ở vòng decomposition kiểu Palantir, người phỏng vấn cố tình thêm một yêu cầu giữa chừng để xem thiết kế của bạn uốn được hay gãy. Vì thế, hãy chuẩn bị đón dữ kiện mới thay vì hy vọng nó không đến.

Một cuộc gọi mẫu, từng câu một

Thử hình dung đề bài sau. “Khách hàng” là trưởng vận hành của một công ty giao hàng và nói: “Dashboard báo tỷ lệ đơn trễ tăng gấp đôi từ thứ Hai. Cần biết ngay chuyện gì đang xảy ra.” Không có spec, không có schema, chỉ có một con số đáng lo.

Ứng viên yếu sẽ im lặng ba mươi giây rồi đề xuất viết lại pipeline. Ứng viên tốt sẽ nói giả thuyết thành tiếng và gắn nhãn đó là giả định, đúng như Aced khuyên:

“Trước hết, đây mới là một giả định thôi nhé. Có thể đơn không trễ hơn thật, mà là cách tính ‘trễ’ đã thay đổi, ví dụ một bản deploy làm lệch múi giờ. Nếu đúng vậy thì khách cuối sẽ không phàn nàn gì thêm. Cho hỏi: từ thứ Hai có ai thay đổi gì ở hệ thống báo cáo không?”

Khách hàng né: “Bên kỹ thuật làm gì thì không rõ. Nhưng tổng đài tuần này nhận nhiều cuộc gọi phàn nàn hơn hẳn.”

Khoảnh khắc này cho thấy rõ nhất cách bạn đi tới lời giải. Ứng viên tốt không lặng lẽ chuyển hướng mà nói rõ: “Vậy bỏ giả thuyết lỗi hiển thị. Nếu chỉ là cách tính sai thì khách cuối đâu có gọi lên tổng đài.”

Rồi nói tiếp: “Giờ nghiêng về khả năng đơn trễ thật. Có hai nhánh: một khu vực cụ thể bị chậm, hoặc toàn hệ thống chậm. Nên kiểm tra theo khu vực trước, vì nếu đúng thì phạm vi sửa nhỏ hơn nhiều.”

Câu cuối ứng với lời khuyên của techinterview.org: đến ngã rẽ thì nói vì sao chọn nhánh này.

Rồi người phỏng vấn tung yêu cầu mới: “Sếp cần báo cáo trước thứ Sáu.” Ứng viên tốt cập nhật kế hoạch thành tiếng: hôm nay khoanh vùng theo khu vực, xác nhận nguyên nhân với một mẫu đơn cụ thể, còn việc sửa tận gốc để sau khi đã có báo cáo.

Ghi bảng để người chấm theo kịp

Cuốn SRE khuyên ghi rõ đã có những ý gì, đã chạy phép thử nào và thấy kết quả gì. Trong phòng phỏng vấn, ghi chú đó giúp người chấm nhìn thấy và lần theo được từng bước suy luận của bạn. Bảng cho cuộc gọi trên trông như sau:

Giả thuyết	Phép thử	Kết quả
Cách tính “trễ” bị đổi, đơn không trễ thật	Hỏi có thay đổi hệ thống không, khách cuối có phàn nàn không	Bác bỏ: tổng đài nhận nhiều phàn nàn hơn
Đơn trễ thật ở một khu vực	Tách tỷ lệ trễ theo khu vực hoặc kho	Đang chờ dữ liệu
Toàn hệ thống chậm	Chỉ kiểm nếu giả thuyết thứ hai sai	Chưa thử

Dòng ghi “Bác bỏ” có giá trị không kém dòng đang chờ dữ liệu. Nó cho thấy bạn loại trừ dựa trên bằng chứng, chứ không dựa vào cảm giác.

Câu mẫu bốn vế và cách luyện nó

Mỗi giả thuyết bạn nói ra nên có đủ bốn vế: “Giả định là X, vì Y. Nếu X đúng, ta sẽ thấy Z. Để kiểm tra, cần hỏi hoặc xem W.” Vế Z quan trọng nhất. Thiếu nó, giả thuyết của bạn không bác bỏ được, và người chấm không biết bạn sẽ đổi ý vào lúc nào.

Khi bằng chứng ngược chiều, dùng câu bác bỏ ba vế: “Điều này loại X, vì nó mâu thuẫn với Z. Chuyển sang giả thuyết tiếp theo. Chọn nó trước vì…” Câu này ngắn, nhưng nó cho người chấm thấy bằng chứng, sự linh hoạt và lý do ưu tiên.

Techinterview.org gợi ý cách luyện cụ thể: chạy vòng decomposition thành tiếng với một người bạn đóng vai stakeholder lảng tránh, không chịu đưa spec rõ ràng. Hãy dặn người bạn đó cố tình đưa thông tin trái với giả thuyết đầu tiên của bạn, và tung thêm một yêu cầu ở phút thứ mười.

Những lỗi khiến ứng viên giỏi vẫn trượt

Lỗi phổ biến nhất là im lặng suy nghĩ. Aced gọi sự im lặng trong phỏng vấn decomposition là tín hiệu tiêu cực, vì người phỏng vấn không chấm được suy luận mà họ không nghe thấy. Bạn có thể nghĩ rất đúng, nhưng trên phiếu chấm nó vẫn trống.

Lỗi thứ hai là đổi hướng âm thầm: bạn bắt đầu nói về giả thuyết mới mà không tuyên bố đã bỏ giả thuyết cũ. Người nghe sẽ thấy bạn nhảy lung tung chứ không thấy bạn đang loại trừ. Lỗi thứ ba là xin lỗi khi sửa ý, như thể đó là thất bại, trong khi Aced coi việc quay lại quyết định cũ là điểm cộng.

Lỗi cuối cùng tinh vi hơn: bám vào một nguyên nhân quen thuộc, kiểu “lần trước cũng là do cache”, rồi tìm cách giải thích mọi dữ kiện mới cho khớp với nó. Đó chính là cái bẫy mà cuốn SRE cảnh báo.

Đưa kỹ năng này vào hồ sơ

Kỹ năng này không chỉ để qua phỏng vấn. Ở một khách hàng thật, spec cũng mù mờ như vậy, và việc bạn nói rõ đang loại trừ điều gì giúp cả phòng họp theo kịp bạn.

Khi viết CV hay chuẩn bị câu chuyện cho vòng behavioral, hãy kể một sự cố theo ba cột ở trên: bạn nghi gì đầu tiên, phép thử nào loại nó, và bằng chứng nào dẫn bạn tới nguyên nhân thật.

Một dòng CV kiểu “loại trừ lỗi hiển thị bằng dữ liệu tổng đài, khoanh vùng sự cố về một khu vực trong hai giờ” cho người đọc thấy cách bạn làm việc rõ hơn hẳn những chữ như “chủ động” hay “tư duy tốt”.

Lần tới, khi một giả thuyết vừa đổ trước mặt người phỏng vấn, đừng vội lấp nó đi. Nói rõ nó sai ở đâu và bạn đi tiếp hướng nào, vì chính con đường đó là thứ được chấm.