Cách đây vài năm, tuyển dụng IT là việc nhẹ nhất trong tuần.
Bên kỹ thuật soạn cho bộ phận tuyển dụng một bộ barem gọn gàng — vài câu lý thuyết, vài câu tricky đã cài sẵn bẫy — đủ tính phân loại để chạy vài vòng đầu. Trả lời trôi chảy thì đi tiếp, không qua nổi thì tự loại. Chỉ tới vòng cuối mới cần một dev manager, hoặc một kỹ sư cứng, ngồi đánh giá cho thật.
Thời kỳ AI đến, và mọi ứng viên bỗng nhiên đều “biết”. Đó lại chính là lúc việc tuyển dụng trở nên khó nhất.
Cách cũ dựa vào một giả định đã không còn đúng
Bộ barem cũ chạy được nhờ một giả định ngầm: người trả lời đúng là người hiểu, còn người không hiểu thì trả lời sai — hoặc im lặng.
Giả định đó từng đúng. Để nói được về microservices, về idempotency hay về eventual consistency, bạn phải từng đọc, từng làm, từng vật lộn với nó. Kiến thức là bằng chứng của công sức.
Giờ thì không cần nữa. Một câu prompt là ra một câu trả lời đủ hay để qua vòng đầu — không phải vì ứng viên hiểu, mà vì AI viết hộ họ thứ nghe rất hiểu.
Nghe thì hoa mỹ, bên trong thì rời rạc
Những câu trả lời này nghe rất “nặng”: thuật ngữ kỹ thuật dày đặc, câu cú phức tạp, nhịp điệu như một bài giảng được soạn sẵn. Người phỏng vấn không chuyên rất dễ bị choáng.
Nhưng gỡ từng mảnh ra thì chúng chẳng dính vào nhau:
- Rời rạc. Mỗi thuật ngữ đứng đúng chỗ của nó, nhưng giữa chúng không có mạch lập luận. Câu sau đá thẳng vào câu trước mà ứng viên không hề nhận ra.
- Thiếu thực tế. Thuộc vanh vách ưu nhược điểm của hai kiến trúc, nhưng tới câu “vậy dự án của bạn nên chọn cái nào, vì sao” thì tắc. Hỏi “lần cuối bạn gặp chuyện này là khi nào” thì câu trả lời trôi đi chỗ khác.
- Máy móc. Một công thức chung dán cho mọi bài toán, không phân biệt được cái nào cần đánh đổi cẩn thận, cái nào chỉ cần làm cho xong.
Đó là kiến thức học vẹt. Nghe như chuyên gia, nhưng không có kinh nghiệm nào đứng sau.
Người phỏng vấn kẹt giữa hai thứ họ không thể kiểm chứng
Vấn đề không nằm ở ứng viên. Nằm ở chỗ người ngồi đối diện không có cách nào phân biệt.
Bộ barem cũ đơn giản vì nó giả định đáp án sai là thứ dễ thấy: nói sai khái niệm, thiếu thuật ngữ, trả lời lạc đề. Giờ thì đáp án đúng ở khắp nơi — và cái sai nằm sâu hơn, ở chỗ lập luận, chứ không ở chỗ dùng từ.
Mà phán đoán điều đó thì cần đúng thứ chuyên môn mà bộ phận tuyển dụng không có. Chiếu vào thang điểm thì ai cũng đạt. Ngồi phản biện cho ra nhẽ thì cần người hiểu nghề — và người đó thường đang bận, ở tận vòng cuối.
Kết quả: bộ lọc chạy ngược. Người giỏi và người học vẹt đi qua cùng một cửa, rồi tới vòng cuối — chỗ tốn kém nhất — mới bị tách ra.
Phải dời bộ lọc, không chỉ thêm câu hỏi
Thêm vài câu tricky nữa cũng vô ích. AI trả lời được cả câu tricky. Phải dời chỗ đặt bộ lọc.
Có một cách vừa đơn giản vừa hiệu quả: hỏi thẳng vào use case của từng đặc tính kỹ thuật. Đừng hỏi “idempotency là gì” — câu đó AI trả lời trong ba giây. Hỏi: “trong hệ thống của bạn, chỗ nào cần nó, và nếu bỏ nó đi thì chuyện gì xảy ra?”. Một định nghĩa thì sao chép được; một use case thật thì phải hiểu mới nghĩ ra. Chính chỗ này hé lộ mindset, sự sáng tạo và hiểu biết thực tế — thứ mà ngồi tra định nghĩa với AI không thể nắm được. Và hay ở chỗ: người hỏi không cần giỏi kỹ thuật, chỉ cần kiên quyết đòi một ví dụ cụ thể.
Vài hướng khác cũng nên dời theo:
- Chấm việc làm được, không chấm điều biết được. Một bài tập nhỏ, một đoạn code phải đọc, một lỗi phải sửa, một lựa chọn phải bảo vệ. Học vẹt không mô phỏng lại được quá trình làm.
- Đưa người có chuyên môn vào sớm hơn. Không còn là “vòng cuối của dev manager” nữa, mà là ngay vòng đầu — dù chỉ vài phút.
- Hỏi đuổi. Đừng dừng ở câu trả lời đúng. Hỏi “vì sao”, hỏi “nếu điều kiện đổi thì sao”, và ấn đúng vào chỗ mâu thuẫn để xem người ta xử lý thế nào.
- Hỏi kinh nghiệm cụ thể. Một lần hệ thống sập, một lần phải thuyết phục cả team chọn ngược lại. Người từng trải kể bằng chi tiết; người học vẹt kể bằng khái niệm.
- Để “tôi không biết” là một câu trả lời. Có khi tín hiệu rõ nhất không phải câu trả lời, mà là cách một người đối diện với thứ mình chưa từng gặp.
Còn một màn nữa: bài test
Bài test IT vốn xoay quanh syntax và giải thuật: viết được vòng lặp, nhớ được cách đảo mảng, giải được vài bài thuật toán. Và vì bài test thường làm trực tiếp, làm được tại chỗ gần như đồng nghĩa với có trình độ thật.
Thời kỳ AI lật ngược chỗ đó. Syntax và giải thuật không còn đáng để test nữa — vì nhận việc rồi, ai cũng có AI viết hộ phần đó. Giỏi hay dở, mấy việc này AI cân hết trong vài giây. Đem chúng ra làm đề là đang lọc một kỹ năng mà chính công việc sắp không cần đến.
Thứ còn đáng test là mấy việc AI làm thay không được:
- Đưa một kỹ thuật, yêu cầu use case. Cho ra một bối cảnh — message queue, cache, idempotency, event sourcing — rồi hỏi: trong hệ thống bạn từng đụng, chỗ nào cần nó, nó giải quyết đúng vấn đề gì, và bỏ nó đi thì hỏng ở đâu. AI trả lời được “nó là gì”; chỉ người đã va mới trả lời được “dùng khi nào, và vì sao không chọn cái khác”.
- Test tư duy phân loại và tư duy kiến trúc. Vibe code thì AI sinh code tràn lan — thêm hàm, thêm lớp, thêm một tầng trừu tượng ở khắp nơi. Người thiếu tư duy phân loại (cái gì thuộc về đâu, cái gì tách ra, cái gì gộp lại) và tư duy kiến trúc (ranh giới giữa các phần, luồng dữ liệu, chỗ nào dễ vỡ) sẽ để đống code đó thành rác — chạy được lúc đầu rồi mục dần. Nên giao một bài toán đủ lớn để phải chia nhỏ, rồi xem họ đặt ranh giới ở đâu và gom nhóm thế nào.
Và theo tôi nghĩ, cứ để ứng viên dùng AI — bản base, kèm một giới hạn thời gian. Người phụ thuộc AI sẽ sớm sa đà: nhận gợi ý này, sửa chỗ kia, rồi hết giờ mà chưa xong. Người thật sự hiểu việc thì dùng nó như một trợ thủ và vẫn kịp.
Ở đây không có mẹo nào. Chỉ có một điều khó chịu: khi ai cũng nói được, thứ duy nhất còn phân loại được ai là việc họ từng thật sự làm.
Nếu bạn đang phải tuyển IT trong thời kỳ AI và thấy bộ barem cũ bắt đầu trượt, nhắn cho chúng tôi một câu — chúng tôi cũng đang xoay xở với đúng bài toán này.
