Chuẩn Tuyển Dụng Kỹ Thuật Và Quy Trình Phỏng Vấn Của NTIOT, Giải Thích Cặn Kẽ

Chúng tôi thường xuyên được hỏi vì sao quy trình phỏng vấn của NTIOT mất nhiều thời gian hơn so với nhiều công ty outsourcing tương đương, và vì sao chúng tôi sẵn sàng mất ứng viên vào tay các đối thủ di chuyển nhanh hơn. Câu trả lời thành thật là khách hàng đang giao phó cho chúng tôi các hệ thống production và, trong một số dự án, cả dữ liệu bị quản lý chặt chẽ — và một quy trình nhanh được tối ưu để lấp đầy vị trí nhanh chóng là một quy trình khác hẳn so với một quy trình được tối ưu cho khả năng phán đoán mà loại công việc đó đòi hỏi. Chúng tôi xây dựng quy trình của mình xoay quanh mục tiêu thứ hai, và chúng tôi vẫn giữ nó ngay cả khi nó khiến chúng tôi mất ứng viên và cả sự kiên nhẫn nội bộ.

Chúng tôi đã ngừng kiểm tra kiến thức cú pháp từ nhiều năm trước

Ban đầu, các vòng sàng lọc kỹ thuật của chúng tôi trông giống hầu hết các công ty khác — câu hỏi thuật toán, kiến thức vụn vặt về ngôn ngữ, code trên bảng trắng dưới áp lực thời gian. Chúng tôi đã bỏ phần lớn những thứ đó sau khi nhận ra nó tương quan kém với hiệu suất công việc thực tế. Một người có thể đọc thuộc lòng độ phức tạp thời gian của năm thuật toán sắp xếp không nhất thiết là người sẽ đưa ra những đánh đổi kiến trúc tốt trên một hệ thống khách hàng thực với yêu cầu không đầy đủ và một deadline.

Thay vào đó, chúng tôi kiểm tra:

• Khả năng suy luận trong điều kiện mơ hồ. Chúng tôi đưa cho ứng viên một bài toán cố tình thiếu thông số và quan sát họ đặt câu hỏi gì trước khi viết bất kỳ dòng code nào. Những ứng viên bắt đầu code ngay lập tức, không làm rõ các phần mơ hồ, thường gặp khó khăn trong các dự án thực tế nơi yêu cầu thực sự không đầy đủ ngay từ đầu.
• Khả năng diễn đạt đánh đổi, không phải câu trả lời "đúng". Với các vòng system design, thường không có một đáp án đúng duy nhất — chúng tôi lắng nghe xem ứng viên có thể nêu tên đánh đổi họ đang chấp nhận và lý do hay không, chứ không phải liệu họ có đi đến cùng thiết kế mà người phỏng vấn của chúng tôi đã chọn hay không.
• Cách họ xử lý khi sai. Chúng tôi cố tình phản biện thiết kế của một ứng viên giữa buổi phỏng vấn, ngay cả khi câu trả lời ban đầu của họ hợp lý, cụ thể là để xem liệu họ có thể cập nhật quan điểm của mình với thông tin mới hay sẽ khăng khăng bảo vệ một cách phòng thủ. Các dự án khách hàng thường xuyên liên quan đến việc bị nói rằng "cái này không phù hợp với yêu cầu tuân thủ của chúng tôi", và cách ai đó phản ứng với điều đó trong một buổi phỏng vấn là một tín hiệu thực sự.

Quy trình có bốn giai đoạn, mỗi giai đoạn kiểm tra một điều khác nhau

1. Một bài tập take-home, giới hạn khoảng ba giờ, dựa trên một vấn đề thực tế (không bao giờ là của một khách hàng thực đang hoạt động) trong lĩnh vực thế mạnh mà ứng viên tự khai. Chúng tôi nói rõ rằng chúng tôi đang đánh giá đoạn code họ thực sự thoải mái khi đưa vào production, không phải một giải pháp một lần thông minh — khả năng đọc hiểu và độ bao phủ test được tính ngang với việc logic cốt lõi hoạt động đúng.
2. Một buổi review code trực tiếp, nơi ứng viên review một PR chúng tôi đã chuẩn bị chứa hỗn hợp code hợp lý và một vài vấn đề được cài cắm cố ý — một race condition, một trường hợp biên không được xử lý, một lỗ hổng bảo mật. Đây hóa ra là một trong những giai đoạn có tín hiệu cao nhất, vì review code tốt là một kỹ năng khác biệt với việc viết code, và đó chính xác là kỹ năng một thành viên chuyên trách cần khi làm việc bán độc lập trên codebase của khách hàng.
3. Một cuộc trò chuyện system design được điều chỉnh theo cấp độ vai trò — với ứng viên senior, đây có thể là thiết kế một pipeline dữ liệu đa vùng; với ứng viên mới vào nghề hơn, một thứ gì đó gọn hơn, như thiết kế một rate limiter. Việc điều chỉnh quy mô rất quan trọng: chúng tôi không kiểm tra mọi người theo cùng một chuẩn, chúng tôi kiểm tra xem tư duy thiết kế của họ có khớp với những gì vai trò thực sự đòi hỏi hay không.
4. Một cuộc trò chuyện về giá trị và phong cách làm việc, không phải một thủ tục hình thức — chúng tôi cố tình tìm hiểu cách ứng viên đã xử lý bất đồng với một quản lý hoặc khách hàng, và cách họ đã xử lý khi ở trong một đội trễ deadline. Năng lực kỹ thuật đi kèm thói quen hợp tác kém không trụ được trong các dự án khách hàng kéo dài nhiều tháng, nơi lòng tin chính là sản phẩm thực sự đang được giao.

Những gì chúng tôi cố tình không làm

Chúng tôi không làm các bài kiểm tra bất ngờ về những tính năng ngôn ngữ hiếm gặp, và chúng tôi không làm các câu hỏi "gài bẫy" mang tính đối đầu nhằm khiến ứng viên cảm thấy tệ dưới áp lực. Không cái nào dự đoán được hiệu suất thực tế, và cả hai đều chỉ chọn ra những người giỏi phỏng vấn chứ không phải giỏi công việc.

Vì sao chúng tôi sẵn sàng mất ứng viên vì điều này

Quy trình mất 2-3 tuần từ đầu đến cuối, lâu hơn quy trình một ngày của một số đối thủ. Chúng tôi từng có những ứng viên mạnh nhận lời mời nhanh hơn ở nơi khác vì lý do này. Đó là một chi phí được chấp nhận, không phải một sơ suất — giải pháp thay thế là tuyển nhanh hơn và phát hiện ra khoảng trống về khả năng phán đoán sáu tháng sau khi đã vào một dự án khách hàng, điều này tốn kém hơn nhiều cho tất cả mọi người, kể cả ứng viên cuối cùng rơi vào một vai trò không phù hợp với mình.

Chuẩn này thực sự bảo vệ điều gì

Các khách hàng đánh giá NTIOT như một đối tác outsourcing, trên thực tế, đang tin tưởng vào chuẩn tuyển dụng của chúng tôi như một thước đo đại diện cho chất lượng công việc họ sẽ nhận được, vì họ không thể tự mình phỏng vấn từng kỹ sư trong một đội chuyên trách. Giữ chuẩn đó nhất quán — cùng bốn giai đoạn, cùng sự nhấn mạnh vào khả năng phán đoán hơn là kiến thức vụn vặt, bất kể một vị trí cần được lấp đầy khẩn cấp đến đâu — chính là điều khiến "kỹ sư NTIOT" mang một ý nghĩa cụ thể và đáng tin cậy trên một đội ngũ đang phát triển, thay vì một nhãn hiệu thay đổi thất thường tùy vào việc ai đang phụ trách tuyển dụng quý đó.

Nếu bạn tò mò muốn biết điều này trông như thế nào từ phía ứng viên thay vì phía khách hàng, các vị trí kỹ thuật đang mở và các bài tập take-home gắn với chúng được liệt kê trên trang tuyển dụng của chúng tôi, cùng với một bảng phân tích chi tiết hơn về những gì mỗi giai đoạn đánh giá.