Hôm nay xe tôi phải đi sửa, hãy nói cho tôi biết cách tốt nhất để về nhà là gì

Có thể hơi kỳ quặc — song câu hỏi lại rất đơn giản. “Hôm nay xe tôi phải đi sửa. Hãy nói cho tôi biết cách tốt nhất để về nhà là gì.”

Để giải thích được tại sao tôi lại đi hỏi kiểu này trong một cuộc phỏng vấn thì — Trước đây, khi còn làm quản lý về IT, tôi thường phải tuyển dụng nhân viên cho những vị trí hỗ trợ IT, những người trưởng nhóm dự án cấp cao và quản trị viên hệ thống cũng như những vị trí bình thường hơn cho các phòng trợ giúp IT.

Trong ngành này, tôi đã học được một điều từ rất sớm ấy là dù vị trí có ở cấp độ nào đi chăng nữa thì, kinh nghiệm và kiến thức chuyên môn thường có xu hướng bị đánh giá cao quá mức. Khi mới làm quản lý, tôi hay mắc sai lầm vì thuê người chủ yếu dựa vào những yếu tố đó và dẫn tới những kết quả tệ hại. Tôi đã sớm học được rằng ngành IT này luôn thay đổi, bởi vậy ta cần phải vận động thì mới có thể trụ vững được — giữ được mong muốn cũng như động lực tiếp tục học hỏi và cập nhật những tri thức cũng như khả năng giải quyết vấn đề và tư duy chăm sóc khách hàng là những điều tối quan trọng, sau đó mới là kiến thức tốt. Từ đấy, tôi nhanh chóng thay đổi quy trình phỏng vấn theo hướng tập trung sâu vào kỹ năng giải quyết vấn đề cốt lõi của ứng viên.

Tôi sẽ thử hỏi họ những câu hỏi có vẻ rất bình thường — chẳng liên quan gì đến IT — đơn giản chỉ để xem xem quy trình họ dùng để giải quyết các vấn đề là gì. Tôi nhận thấy rằng khi hỏi về một chủ đề IT, ứng viên thường sẽ tìm câu trả lời nhờ vào kiến thức học thuật hoặc dựa vào các quy trình mà có người đã bảo họ làm theo. Nếu tôi đặt ra câu hỏi liên quản đến việc quản lý dự án IT, đa phần mọi người sẽ kể ra hàng loạt các cách quản lý sản phẩm để đánh giá vấn đề — có lẽ còn trích ra một vài phương pháp thông dụng như dùng các mô hình Waterfall, Agile, SCRUM, PMBOK — nhưng tôi muốn xem xem liệu có ai thực sự dùng cách ấy không. Kể cả khi đối với một việc đơn giản như về nhà kiểu gì.

Vì thế, khi hỏi nhiều loại câu hỏi khá kỳ lạ, ngẫu nhiên về các vấn đề thường ngày, họ sẽ phải thực sự tư duy, và họ phải thoát khỏi cái “chế độ kể chuyện” kia đồng thời khả năng và quy trình giải quyết vấn đề của họ sẽ xuất hiện. Điều này phản ánh được chính xác cách thức mà người đấy sẽ thực sự sử dụng trong công việc chứ không phải chỉ là để trả lời phỏng vấn.

Vì thế, ví dụ trên là một câu hỏi khá đơn giản không liên quan tới IT mà tôi sẽ đặt ra, và thật ngạc nhiên khi nó tiết lộ được cực kỳ nhiều điều về quy trình giải quyết vấn đề một cách tự nhiên và khả năng đánh giá vấn đề. Những câu hỏi tương tự như vầy khiến tôi không thể tuyển những người mới đầu có hồ sơ khá đẹp.

Sau khi tôi đưa chiếc laptop qua bàn cho họ — và mặt họ nghệt ra với cái vẻ “đây cũng là câu hỏi á"? — vài người đơn giản chỉ hỏi địa chỉ và đưa số của tôi cho một chiếc taxi.

Nếu có ai đó làm những điều tương tự như vầy trong các câu hỏi về cách giải quyết vấn đề, tôi chắc chắn sẽ không tuyển.

Vài người sẽ hỏi thêm một chút rằng tôi cần về nhà lúc mấy giờ — và rồi thắc mắc rằng tôi thích đi taxi hay phương tiện công cộng hơn và có lẽ là vài câu bình thường khác. Có thể được cộng thêm vài điểm đấy...

Sau nhiều câu như vầy, tôi sẽ bảo họ rằng mình cần lấy xe tại shop trước khi về nhà. Và họ hỏi địa chỉ shop. Tôi sẽ bảo họ rằng tôi còn phải đón cả vợ mình đang ở chỗ làm vào thời gian nhất định nữa. Và rồi rất nhiều các tình huống kỳ dị hay ho khác liên quan tới vấn đề mà tôi chưa bao giờ đề cập đến và họ cũng chẳng bao giờ hỏi.

Những ứng cử viên thực sự, thực sự tốt sau đấy trở thành những nhân viên IT xuất sắc ở mọi cấp bậc đều sẽ tự biết được cách đánh giá vấn đề và thu thập những thông tin cần thiết (mà không cần phải nhắc) để giải quyết chính xác ngay từ lần đầu. Tôi thấy khả năng này rất hiếm gặp cũng như cực kỳ quý giá, tới mức nếu có ai đó trả lời chính xác được những câu hỏi kiểu vầy ngay từ lần đầu thì — tôi sẽ tuyển họ ngay lập tức.

Ví dụ về một ứng viên (UV) tốt nhé:

UV: Ông cần về nhà vào lúc nào?
Tôi: Muộn nhất 6h tối

UV: Ông còn cần làm xong việc gì trên đường về không?
Tôi: Tôi cần lấy xe trước 5h và trước đó cần đón vợ tại chỗlàm trước 5:30

UV: Ông muốn lấy xe hay đón vợ trước?
Tôi: Lấy xe đi.

UV: Được rồi, địa chỉ shop lấy xe và chỗ làm vợ ông nào?
Tôi: Cung cấp địa chỉ.

UV: Ông thích đi phương tiện nào đến lấy xe? Taxi, bus hay tàu hỏa?

Tôi: Shop ô tô ngay cạnh bến tàu nên tôi nghĩ đi tàu tiện hơn, còn tiết kiệm tiền nữa.

UV: (Đánh máy vài phút) ….. Được rồi nè, tùy thuộc vào việc ông muốn lấy xe ở shop trong bao lâu - tôi khuyên ông đi chuyến tàu số 5 khởi hành từ ga Milton lúc 4:15 và xuống tại ga Wilson. Trừ đi thời gian di chuyển dự kiến ông còn khoảng 20 phút để lấy xe ở shop và nhiều thời gian để tới chỗ vợ lúc 5:30 và thời gian dự kiến có mặt ở nhà là 5:45.

Tôi: Tuyển luôn.

Chỉ cần hỏi vài câu tương tự như vầy bạn đã có thể đoán được khá rõ rằng người này đánh giá sự việc có tốt hay không — và quy trình họ sử dụng để giải quyết vấn đề ấy là gì. Họ có thể đưa ra một câu trả lời hời hợt nhất mà chẳng cần kiểm tra lại xem ấy có phải điều mà khách hàng thực sự mong muốn hay không. Họ có thể lao vào “phục vụ” nhu cầu của người khách ấy, kết nối những mẩu thông tin mà câu hỏi cung cấp và thấu hiểu được rằng cần đặt ra câu hỏi quan trọng nào để có thể đưa ra giải pháp tối ưu.

Về cơ bản thì, IT ở cấp bậc nào cũng là một ngành dịch vụ — và những yếu tố then chốt tôi kiếm tìm ở một người ấy là khả năng phục vụ, khả năng giải quyết vấn đề và mong muốn cũng như khả năng đáp ứng được nhu cầu của người khác chứ không đơn thuần là làm cho xong việc. Điều đó sẽ tạo nên một nhân viên tốt làm việc hiểu quả và có thể giải quyết được những vấn đề dù đã từng phải đối mặt với nó trước đó hoặc chỉ mới được cung cấp những chi tiết cần thiết mà thôi. Và đọc bài này, bạn có thể bảo — không phức tạp đến thế đâu, tôi sẽ trả lời được một cách chính xác mà. Từ kinh nghiệm của cá nhân tôi thì, việc thấu hiểu tầm quan trọng của những câu hỏi đi kèm để có thể hỏi được một cách chính xác nhằm đánh giá được vấn đề và có được sự kiên nhẫn để thực hiện chuyện đó nữa….. thường khá đơn giản song cũng rất hiếm có đấy.