- Phỏng vấn live coding trên thực tế đo phản ứng căng thẳng tốt hơn là năng lực lập trình của kỹ sư
- Theo các nghiên cứu khoa học, trong môi trường bị theo dõi theo thời gian thực sẽ xuất hiện suy giảm năng lực nhận thức và biến động hiệu suất nghiêm trọng
- Đặc biệt, với ứng viên nữ, đã ghi nhận hiện tượng tất cả đều trượt trong môi trường công khai nhưng đều đậu trong môi trường riêng tư
- Phần lớn doanh nghiệp không thực sự yêu cầu khả năng thích nghi với căng thẳng nhưng lại đánh giá nhầm điều đó thông qua bài kiểm tra coding
- Thi thử, phơi nhiễm dần, cùng một số dưỡng chất hỗ trợ có thể giúp giảm căng thẳng
Trải nghiệm cá nhân với phỏng vấn live coding
- Một số người thích phỏng vấn live coding, nhưng tác giả thì không
- Trong quá trình ứng tuyển vào Toptal, tác giả thất bại ở bài kiểm tra live coding nhưng khi tự giải lại một mình thì nhanh chóng tìm ra lời giải
- Trải nghiệm này khiến tác giả nhận ra rằng dưới áp lực bị giám sát theo thời gian thực, sự căng thẳng khiến bản thân không thể hiện được đúng năng lực vốn có
Bộ não phản ứng với căng thẳng
- Trong tình huống rủi ro cao, áp lực thời gian, hạch hạnh nhân của não được kích hoạt và mức cortisol tăng lên
- Điều này làm suy giảm chức năng của vỏ não trước trán, nơi phụ trách suy luận phức tạp và trí nhớ
- Trí nhớ làm việc là thước đo quan trọng nhất để đánh giá khả năng giải quyết vấn đề mới, và nó giảm mạnh trong tình huống coding thời gian thực
- Ngay cả khi chỉ có lo âu hiệu suất ở mức nhẹ, việc suy nghĩ rõ ràng cũng gần như trở nên bất khả thi
- Việc tập trung trở nên khó khăn, không thể đồng thời nhớ nhiều bước, và bản thân có cảm giác như mình là “một người kém hơn rất nhiều so với thường ngày”
Kết quả nghiên cứu mang tính quyết định
- Một bài báo do nhóm nghiên cứu của Microsoft thực hiện đã so sánh việc giải cùng một bài toán coding trong môi trường riêng tư và môi trường công khai
- Ở môi trường riêng tư, người tham gia làm bài một mình trong phòng; còn ở môi trường công khai, họ phải giải trước mặt giám sát viên và nói ra quá trình suy nghĩ
- Kết quả cho thấy trong môi trường bị quan sát, thành tích giảm còn một nửa, đồng thời độ chênh lệch thành tích cũng tăng mạnh
- Khác với ứng viên nam, tất cả ứng viên nữ trong môi trường công khai đều không đạt, trong khi ở môi trường riêng tư thì tất cả đều vượt qua
- Môi trường live coding đóng vai trò như một bộ lọc loại trừ đã được chứng minh bằng khoa học, khiến những kỹ sư có năng lực bị loại
Thực tế về hiệu suất dưới áp lực
- Live coding rốt cuộc chỉ là một thước đo thay thế cho hiệu suất trong tình huống căng thẳng
- Một số công ty thực sự muốn tuyển người làm tốt trong môi trường áp lực, nhưng đa số công ty không nêu rõ điều đó trong mô tả ứng tuyển
- Xét rằng phần lớn công việc thực tế không có nhiều áp lực thời gian thực, việc loại một kỹ sư giỏi chỉ vì mắc lỗi trong live coding là không phù hợp
- Sẽ hợp lý hơn nếu xem live coding là công cụ đo mức hormone căng thẳng hơn là năng lực lập trình
Cách giảm căng thẳng
- Vì live coding là điều phổ biến trong ngành, nên cần rèn luyện khả năng thích nghi với căng thẳng
- Có thể giúp não quen với áp lực bằng cách luyện tập lặp đi lặp lại trong môi trường giống thực tế (Pramp, Interviewing.io, bài thi thử của LeetCode, v.v.)
- Việc đặt hẹn giờ, tự ghi hình, hoặc nhờ bạn bè quan sát để dần tăng áp lực là cách luyện tập hiệu quả
- Ngoài ra, cũng có thể thử bổ sung các dưỡng chất như L-tyrosine (bổ sung chất dẫn truyền thần kinh khi căng thẳng) và L-theanine (giúp thư giãn và cải thiện tập trung)
- Trước buổi phỏng vấn thật, nhất định phải kiểm tra trước trong lúc thi thử xem phương pháp nào phù hợp với bản thân
Kết luận
- Việc yếu ở live coding là một đặc điểm phổ biến của con người, chứ không phải thiếu tố chất để trở thành kỹ sư
1 bình luận
Ý kiến trên Hacker News
Tôi không định khái quát hóa từ trường hợp của mình, nhưng muốn chia sẻ trải nghiệm cá nhân. Hiện tôi là một indie developer tự kinh doanh khá thành công. Một trong những lý do chính khiến tôi không từ bỏ con đường phát triển indie ngay cả trong giai đoạn khó khăn là vì trên thực tế tôi đã rơi vào tình trạng gần như không thể được tuyển dụng. Tôi là người trung niên trong ngành công nghệ, nơi nạn phân biệt tuổi tác rất nặng nề, không có bằng computer science, và bị đầu óc trống rỗng khi bước vào các buổi phỏng vấn live coding. Tôi muốn nhấn mạnh rằng không phải mọi loại căng thẳng đều giống nhau. Lính cứu hỏa có thể lao vào tòa nhà đang cháy, nhưng lại sợ hãi khi phải thuyết trình trước người lạ. Tôi cũng vậy: tôi chịu được áp lực công việc thường ngày, nhưng việc bị người khác đứng sau lưng quan sát rồi quyết định tương lai tài chính của mình là áp lực đến mức khó mà tiêu hóa nổi. Sau khi phỏng vấn xong thì tôi thường lại giải được bài ngay. Có thể người phỏng vấn sẽ nghĩ tôi là kẻ lừa đảo, nhưng gần 20 năm kinh nghiệm là bằng chứng phản bác. Nhiều người dường như coi "false negative" như chuyện ngẫu nhiên, nhưng cũng có những người như tôi luôn luôn bị loại. Tôi luôn trượt ở các kiểu phỏng vấn dạng audition, vì tôi không phải kiểu người biểu diễn trên sân khấu.
Tôi rất đồng cảm với chuyện bị đánh giá trong lúc có người khác đứng nhìn. Tôi đang ở đầu tuổi 60. Hồi 20–30 tuổi tôi phỏng vấn cũng tạm ổn, nhưng càng về sau tôi càng thấy bản thân các buổi phỏng vấn trở nên đối đầu hơn. Ngày xưa có cảm giác họ muốn tìm cách tuyển mình, còn bây giờ lại giống như họ đang tìm lý do để không tuyển. Điều đó có thể là do phân biệt tuổi tác, nhưng tôi cũng nghĩ bầu không khí chung của ngành đã thay đổi. Trong 15 năm gần đây, trải nghiệm phỏng vấn ngày càng khó chịu hơn, và tôi thậm chí từng hoảng loạn ngay trong buổi phỏng vấn. Dù vậy tôi vẫn xoay xở để được nhận việc, và cũng từng làm hợp đồng không cần phỏng vấn nhờ hồ sơ tham chiếu. Startup cuối cùng tôi làm việc bị cạn tiền vào cuối năm 2022, và tôi quyết định nghỉ hẳn. Tôi thực sự rất thích công việc, cũng làm với công nghệ mới nhất, nhưng lý do lớn nhất là tôi không còn chịu nổi chuyện phỏng vấn nữa.
Tôi nghĩ chính cấu trúc này mới là vấn đề. Các buổi phỏng vấn code gần đây dường như được thiết kế để kiểm tra xem người trẻ có từng làm bài tập cấu trúc dữ liệu trong CS hay chưa. Có thể điều đó từng có ý nghĩa ở những nơi tuyển số lượng lớn như FAANG trong thập niên 2010, nhưng với công ty vừa và nhỏ thì tập trung vào tình huống công việc thực tế như đọc code hoặc thảo luận edge case sẽ tốt hơn nhiều. Tôi đã làm startup hơn 20 năm mà vẫn không qua nổi các bài test kiểu này. Tôi cũng từ chối việc học vẹt để vượt qua. Nếu đó là nơi không hợp với mình thì có lẽ không vào được cũng đúng thôi. Tôi từng làm CTO, từng launch công ty nhiều lần, quản lý team cũng tốt, thế mà lần này vẫn bị đối xử như fresher. Trước đây tôi từng bị loại chỉ vì không thể viết LRU cache nhanh và gọn, trong khi tôi nghi ngờ startup ngày nay cần thứ đó đến mức nào. Tôi cũng chưa dùng đến nó gần đây. Chỉ vì không giải được ngay những bài kiểu này mà trông như một kẻ bất tài, nhưng tôi không hiểu việc kiểm tra thứ hiếm khi dùng trong thực tế thì có ý nghĩa gì. Nó giống như tuyển kiến trúc sư dựa trên kỹ năng dùng thước trượt vậy. Kiểu tuyển dụng này cuối cùng chỉ sinh ra codebase phức tạp, trong khi điều thực sự cần thiết phải là đạt được mục tiêu kinh doanh chứ không phải tăng độ phức tạp. Tôi muốn làm việc với những đồng nghiệp biết chia nhỏ vấn đề và giữ cho logic cùng cấu trúc luôn đơn giản. Việc dùng leetcode để chọn người thông minh đúng là có vài lợi điểm, nhưng người liên tục giải quyết vấn đề thực tế một cách hiệu quả mới tốt hơn.
Tôi đã từng trải qua tình huống này từ phía người tuyển dụng. Tôi phỏng vấn qua điện thoại một sinh viên đã tham gia dự án khá lâu, nhưng có vẻ vì đủ loại áp lực và rào cản ngôn ngữ nên bạn ấy không thể hiện đúng năng lực. Tôi sẵn sàng đổi hình thức, nhưng ứng viên tự nói rằng không muốn thử nữa. Nhưng nếu chuyển sang phỏng vấn code bất đồng bộ thì cuối cùng lại chỉ đang kiểm tra xem họ có dùng LLM hay không. Rốt cuộc, nếu phải chọn giữa việc loại những người bị đơ trong phỏng vấn và loại những kẻ lừa đảo hoàn toàn không có năng lực, thì tôi thấy lọc nhầm nhóm đầu vẫn là lựa chọn tốt hơn.
Tôi thấy kiểu lệch pha tính cách này rất nhiều trong công ty. Nhiều lập trình viên là người hướng nội, còn phía tuyển dụng lại thường hướng ngoại. Nếu không quản lý tốt khác biệt này thì sẽ dẫn tới việc tài năng hướng nội bị loại trừ hoặc không được thấu hiểu. Môi trường open seat cũng là vấn đề tương tự. Manager có thể thích cộng tác, nhưng với người hướng nội thì đó là môi trường cực kỳ khó chịu.
Tôi tò mò không biết điều gì đã giúp bạn bắt đầu thành công với indie development. Tôi cũng gần 40 tuổi và đã coi lập trình như sở thích từ lâu, nhưng từ năm ngoái mới quyết định theo đuổi nghiêm túc như nghề nghiệp. Tôi có nhiều dự án public trên GitHub, cũng có khá nhiều thành công ở lĩnh vực khác, và kỹ năng giao tiếp cũng không tệ. Nhưng tôi đang gặp khó với live coding. Tôi muốn biết bạn nghĩ gì về con đường independent contribution để thể hiện năng lực thực sự. Nếu thật sự có kỹ năng thì tôi muốn được trả tiền cho điều đó.
Tuần này tôi phỏng vấn một ứng viên Data Engineering. Tôi đưa ra 4 câu SQL rất cơ bản, và người đó đọc to đề rồi ngay lập tức đưa ra đáp án với cú pháp chính xác. Câu cuối tăng độ khó lên một chút thì bị mắc. Tôi bảo "hãy kiểm tra kết quả đi" nhưng người đó không hiểu và trở nên phòng thủ. Tôi bảo "hãy dump bảng ra" thì cũng hoàn toàn không hiểu, chỉ viện cớ. Cuối cùng trong câu SQL mà họ paste vào có [redacted].ai trong output. Có lẽ các câu trước họ dùng AI để giải, và đến câu cuối thì lộ ra. Nếu không có mấy bài kỹ thuật này thì tôi đã không phát hiện được hành vi gian lận.
Công cụ gian lận phỏng vấn bằng AI đang lan rất mạnh trong giới trẻ. Có trường hợp lộ ngay, nhưng ứng viên nhiều kinh nghiệm thì lại biết cách che bằng việc dùng AI xen với các khoảng trống kiểu "tôi không nghe thấy". Trong nhóm manager của tôi, đây là chủ đề tuyển dụng được bàn nhiều nhất gần đây. Những công ty có đủ nguồn lực thì tổ chức vòng cuối trực tiếp onsite. Có người trông rất ổn qua màn hình từ xa nhưng khi gặp trực tiếp lại không trả lời nổi câu hỏi cơ bản, và cuối cùng bị loại. Đúng là tốn thời gian và tiền bạc, nhưng vẫn tốt hơn chi phí của một tuyển dụng sai. Việc dùng AI không chỉ lan trong technical interview mà còn ở resume, behavioral question, thậm chí cả câu trả lời S.T.A.R. do ChatGPT tạo. Việc kiểm tra reference đáng tin cậy giờ quan trọng hơn bao giờ hết. Tôi đã nhiều lần gặp trường hợp nội dung công việc mà sếp cũ mô tả hoàn toàn khác với thứ ghi trong resume. Nếu ngay từ đầu họ thành thật rằng chưa có kinh nghiệm trực tiếp với domain của chúng tôi thì có khi vẫn được tuyển, nhưng khi mức độ nói dối cao như vậy thì không thể có chút tin cậy nào.
Gần đây khi phỏng vấn ứng viên, khoảng 50% dùng live GenAI theo thời gian thực. Tới giờ thì vẫn rất dễ nhận ra ai đang dùng AI. Trong hội thoại tự nhiên là lộ ngay. Trớ trêu thay, ứng viên cuối cùng cũng luôn lặp lại đề bài rồi chờ 10–15 giây. Điều đó cho thấy bản thân kiểu bài test này không phải giải pháp cho vấn đề gốc. Ngược lại, nó tạo ra vấn đề mới và khiến những ứng viên xuất sắc bị loại.
"Nếu dùng AI không phải là gian lận mà là thử trước đúng những gì họ sẽ làm trong công việc thực tế thì sao?" Nếu nhìn như vậy, buổi phỏng vấn đó thực ra là một ví dụ rất hiệu quả, quy mô nhỏ về <i>diễn giải yêu cầu</i>. Cuối cùng, tôi nghĩ hướng tích cực hơn là cho phép dùng tự do các công cụ sẽ sử dụng trong công việc, đồng thời kiểm tra mức độ hiểu thật sự về công việc và ngôn ngữ trong bối cảnh đó. Chỉ cần rời khỏi Leetcode thôi là chưa đủ; phải tìm cách tốt hơn.
Mọi thứ cuối cùng đều là "còn tùy". Live coding interview cũng vậy. Với ứng viên thì đó không phải trải nghiệm tốt nhất, nhưng ở quy mô lớn như Meta hay Google, nó giảm false positive tốt hơn các cách khác. Tuy nhiên, interviewer thường không được đào tạo đầy đủ và bài toán lại quá kiểu đánh đố, nên nếu không luyện LeetCode nhiều hoặc không phải người học thuật / mới ra trường thì rất khó. Tôi đã làm trong lĩnh vực assessment 6 năm và trực tiếp thấy đủ loại quy trình tuyển dụng từ Fortune 10 đến startup. Tôi khuyến nghị đánh giá sát với công việc thực tế, và giờ không còn thích cách gọi "công việc thực tế" cho những thứ gần như lao động không công nữa. Assessment nên là công cụ giúp công ty đủ yên tâm để đưa ra mức lương cao. Với sự xuất hiện của AI, ngay cả bài take-home ngắn cũng khó giữ công bằng. Vì thế một số công ty lại quay về phụ thuộc vào các cách cực đoan như onsite interview và giám sát thời gian thực. Giải pháp hoàn hảo theo tôi là tạo điều kiện để mọi ứng viên đều có thể thể hiện tốt nhất trong cùng một khoảng thời gian, môi trường và bộ công cụ. Tôi luôn suy nghĩ về vấn đề này nhưng vẫn chưa tìm ra câu trả lời.
Người ta cứ nói "ở tầm Meta, Google thì nó hoạt động tốt", nhưng thực ra chẳng có dữ liệu. Tôi từng làm cùng những lập trình viên hạng F xuất thân từ Facebook và Google. Trên thực tế, chính các big tech này cũng sa thải 3–5% nhân sự, và đó là bằng chứng rằng phỏng vấn không hề chặn false positive hiệu quả như người ta tưởng. Với lượng thời gian mà interviewer bỏ ra, tỷ lệ lỗi 3% là quá cao. Về cơ bản nó cũng chẳng khác mấy so với thời "Fizzbuzz" trước đây.
Thay vì bảo thợ xây xây một bức tường để xem tay nghề, ta chỉ yêu cầu xác nhận chứng chỉ rồi tuyển luôn. Nhiều nghề đang làm vậy. Nếu năng lực không hợp thì tuyển xong cho nghỉ. Không nhất thiết phải bắt người ta đi qua quy trình phỏng vấn doanh nghiệp đầy sỉ nhục như thế.
Những kỹ sư giỏi nhất mà tôi từng thấy thường lại hay rơi vào false negative. Họ căng thẳng trong live coding interview nên không thể hiện được đúng khả năng. Tôi không nghĩ có thể khẳng định chắc nịch rằng loại phỏng vấn này "hoạt động tốt".
Sau khi nói "còn tùy" mà lại chốt rằng "live coding interview hiệu quả" thì nghe mâu thuẫn. Theo chiều ngược lại, tôi cũng có thể nói "còn tùy, nhưng live coding interview không hiệu quả". Về logic thì chẳng khác gì.
leet-code khá hữu ích để loại những người thực sự không có khả năng giải quyết vấn đề. Giải pháp tốt nhất là tạo môi trường nơi ứng viên có thể thể hiện tối đa với bộ công cụ và môi trường quen thuộc của mình. Nhưng trên thực tế, tôi nghĩ có lẽ công bằng nhất vẫn là giải leetcode offline trên whiteboard theo kiểu pair programming cùng interviewer. Đó thực sự là một môi trường thoải mái.
Tôi nghĩ cả hai cách giải thích đều có thể đúng cùng lúc. Quả thật có những lập trình viên "senior" nhưng không làm được việc, và live coding giúp lọc họ ra. Nhưng cũng có nhiều lý do khác khiến một người thất bại trong phỏng vấn.
Cũng có nhiều người làm live coding tốt nhưng lại thiếu kinh nghiệm thiết kế hệ thống quy mô lớn. Những người này thường đưa vào codebase technical debt, anti-pattern, sự thiếu nhất quán, và làm mọi thứ tệ hơn. Đó mới thực sự là kiểu cần tránh. Công ty thì tin rằng senior hiện có sẽ kiểm soát người mới, nhưng công ty nào cũng bảo "codebase của chúng tôi là rác", nên biện pháp đó dường như cũng chẳng hiệu quả.
Nếu cho họ ngồi một mình trong phòng để code, bạn sẽ không bỏ lỡ những nhân tài giỏi nhưng chỉ không thể hiện tốt trong môi trường bất thường.
Live coding gần đây đã vượt xa một bài kiểm tra code đơn thuần; giờ phải ghi nhớ nhiều thuật toán và trong 30 phút phải ghép hai ba thuật toán với nhau để giải bài. Vì toàn bộ thời gian dùng để giải câu đố, nên lại chẳng còn thời gian để thể hiện năng lực code thật sự.
Trong 20 năm đi làm, tôi chưa từng thực sự phải làm việc với kiểu "senior không có năng lực" như vậy. Chỉ cần nhìn resume và nói chuyện 15 phút là đã đủ loại rồi. Ngược lại, tôi thấy nhiều người qua được whiteboard interview nhưng lại làm giảm năng suất cả team hơn nhiều.
Tôi không hiểu tại sao môi trường vừa có thời hạn ngắn vừa phải đứng trước whiteboard để nghĩ và giải thích cùng lúc lại là điều bắt buộc. Nếu mục tiêu là lọc những người không làm được việc thật, thì chẳng cần phải đi xa đến vậy.
Theo tôi, cách duy nhất để xác minh đúng năng lực làm một công việc là cho họ làm chính công việc đó. Dù có phương pháp đánh giá thay thế nào đi nữa, nếu có thể cho họ làm việc thực tế thì chẳng có lý do gì dùng cách khác. Nếu bản thân công việc của công ty quá phức tạp đến mức không thể cắt ra thành phần để dùng trong phỏng vấn, thì có lẽ công ty đang làm những thứ phức tạp không cần thiết. Ví dụ, nếu cần kiểm tra xem ai đó có thể nâng 10 kg hay không, thì cứ bảo họ nâng một kiện hàng 10 kg. Thế nhưng ta lại bày ra kiểu kiểm tra kỳ quặc như "để đánh giá sức mạnh, hãy cởi quần rồi dùng mông nhấc một cái xô 1 kg". Cuối cùng, chỉ cần xem đúng các kỹ năng cần cho công việc thực tế. Ví dụ, nếu là đầu bếp thì cho nấu trong bếp thật; nếu là nhân viên hỗ trợ thì xem cách họ giao tiếp trong tình huống mô phỏng. Với vòng phone screen cũng có thể cho xem màn hình trực tiếp.
Có ý kiến phản biện rằng "nếu bắt làm việc thật trong phỏng vấn thì chẳng phải sẽ phát sinh vấn đề gian lận hoặc bóc lột lao động sao?". Nếu công ty thực sự tận dụng kết quả của bài làm phỏng vấn thì có thể phát sinh vấn đề pháp lý.
Cũng có đề xuất thuê trực tiếp theo ngày, theo tuần hoặc theo tháng rồi nếu hợp thì nhận chính thức. Tuy nhiên, cách này không hợp với hệ thống employer healthcare kiểu Mỹ.
Từ phía công ty, lý do là tốn quá nhiều thời gian. Vì thế họ dùng các proxy thiên về false negative hơn là false positive.
Tôi muốn biết bạn nghĩ sao về lo ngại rằng giao việc thật trong phỏng vấn có thể bị xem là yêu cầu "lao động miễn phí".
Cần rất nhiều thời gian để thích nghi với một tổ chức mới, nên dùng công việc thực tế để test có thể còn kém hiệu quả hơn. Tôi thấy live coding assessment tốt hơn để đo khả năng giao tiếp, giải quyết vấn đề và năng lực code thuần.
Từ sau khi có con, khả năng làm bài coding interview của tôi giảm hẳn. Trước đây tôi chưa từng như vậy, nhưng giờ cảm giác có quá nhiều thứ đặt cược vào mỗi buổi phỏng vấn. Nghĩ đến bảo hiểm y tế, khoản vay, nghỉ hưu... là áp lực tăng vọt. Việc bị đứng hình hoàn toàn trong lúc phỏng vấn rồi chỉ sau khi kết thúc mới nghĩ ra lời giải thật sự rất đau đớn. Càng dành nhiều thời gian luyện tập thì tôi lại càng kém đi. Vì có người phải nuôi nên càng luyện càng thấy tội lỗi. Hiệu quả học cũng thấp, mà còn co cụm hơn. Làm ở big tech khiến tôi nhận ra rằng kiểu phỏng vấn này được đưa vào với tinh thần rất "bình đẳng, mọi người đều được test như nhau", nhưng thực tế lại hoàn toàn không phản ánh được những thay đổi hay bất cân bằng trong hoàn cảnh sống của mỗi người. Ngay cả đồng nghiệp chịu áp lực tốt thì vài năm sau cũng có thể khác. Nó khởi đầu với mục tiêu loại bỏ thiên kiến, nhưng tôi nghĩ phương pháp phải thay đổi.
Bạn không hề đơn độc với cảm giác đó. Càng lớn tuổi tốc độ học càng chậm, thời gian rảnh lại ít đi, nên hiệu quả luyện leetcode giảm rõ rệt. Tôi bực mình vì cuối cùng những người chỉ đơn giản là có nhiều thời gian hơn lại được thưởng nhiều hơn.
Tôi khuyên nên thử thiền, hít thở, L-Theanine, beta blocker... như các cách giảm căng thẳng. Nên theo dõi nhịp tim và huyết áp bằng smartwatch. Những cách này thực sự giúp cắt vòng xoáy căng thẳng.
Đây là một môi trường áp lực cường độ rất cao, khác về chất so với stress trong công việc thực tế. Chia sẻ kinh nghiệm phỏng vấn ở Google của tôi: tôi là người đã tạo ra search engine địa phương đầu tiên ở Hà Lan, vậy mà ở Google, một interviewer đội mũ cao bồi bắt tôi dùng bút lông viết code binary search lên whiteboard. Bình thường tôi không viết tay, chỉ dùng bàn phím, và họ cũng chẳng hề muốn nhìn vào kinh nghiệm xây search index mà tôi từng thiết kế. Có lẽ Google muốn kiểu tư duy "cao bồi" chăng.
Tôi cũng từng bị recruiter của Google thuyết phục đi phỏng vấn, nhưng interviewer quá tệ nên sau đó dù Google có đề nghị gì tôi cũng từ chối hết, kể cả khi tôi đã bỏ qua technical interview. Hầu hết câu hỏi đều kiểu "gài bẫy" hoặc hỏi về cấu trúc UNIX rất cũ, không liên quan đến thực tế (ví dụ như inode). Hoàn toàn không liên quan đến vai trò đó. Các công ty nhất định phải có quy trình theo dõi câu hỏi phỏng vấn, lấy phản hồi và đào tạo interviewer. Vẫn còn quá nhiều nơi để interviewer tự do hỏi theo sở thích cá nhân.
Cấu trúc này thực ra hoạt động đúng như ý định của nó. Những công ty như vậy muốn những người có thể chịu đựng bất kỳ sự nhục mạ nào từ công ty. Hai bên không fit với nhau thì như vậy là cả hai đều thành công.
Nếu bạn cảm thấy bị xúc phạm chỉ vì bị yêu cầu làm binary search thì có lẽ cái tôi của bạn hơi lớn quá.
Nếu trước mắt là mức lương 250 nghìn USD mỗi năm cùng thêm stock option của Google, thì tôi sẵn sàng chịu một ngày "bị xúc phạm".
Tôi xem live coding screening là một "cuộc trò chuyện về code". Tôi nói rõ với ứng viên rằng mục đích của buổi phỏng vấn là xem liệu hai bên có giao tiếp tốt với nhau hay không. Chỉ giỏi kỹ thuật thôi là chưa đủ; còn phải cộng tác được. Ví dụ, nếu trong lúc trao đổi mà hiểu nhầm nên triển khai sai, hoặc dù code rất tốt nhưng không thể trò chuyện kỹ thuật, thì đó là vấn đề. Vì vậy các câu hỏi kiểu Fizzbuzz quan trọng không phải chỉ để test kỹ năng đơn thuần mà còn để kiểm tra khả năng "thảo luận kỹ thuật".
Đúng vậy. Bản chất của live coding interview không phải là "có giải được bài hay không", mà là "có thể giải thích sẽ giải như thế nào hay không". Trọng tâm là một chút nền tảng kỹ thuật cùng khả năng giao tiếp. Một phần lớn công việc thực tế là giải thích cho manager không chuyên kỹ thuật, nên có thể xem đây là bài kiểm tra điều đó.
Tôi thích cách này. Tôi có thể giải FizzBuzz bằng ít nhất 3 ngôn ngữ, theo 4 cách khác nhau, và tự tin giải thích cả 12 cách đó.
Tôi cũng nhận ra vấn đề này và đồng ý rằng hiện chưa có lựa chọn thay thế thật sự tốt. Trong sự nghiệp của mình tôi đã nhiều lần gặp những người thật sự "nói năng và hành xử như kỹ sư nhưng thực ra không code được". Tôi cũng từng hối hận nhiều lần vì bỏ qua việc kiểm tra coding skill trong phỏng vấn. Tôi cũng ước các lập trình viên trẻ hiểu rằng nhiều vòng trong quy trình tuyển dụng thực ra đang tạo lợi thế hơn cho ứng viên lớn tuổi. Tôi biết trong ngành có rất nhiều kỹ sư không có khả năng code thật nhưng vẫn qua được chỉ nhờ lớp vỏ "chuyên gia" vô nghĩa. Thực tế, tuyển ai đó mà chưa từng một lần xem họ code thì chẳng khác nào tuyển guitarist cho một ban nhạc chỉ dựa vào resume, trò chuyện và reference. Một "chuyên gia guitar" chưa từng thực sự chơi guitar vẫn có thể được nhận. Vẫn có những người vượt qua theo cách đó mà không cần bằng cấp gì đặc biệt. Nếu trong phỏng vấn bạn chỉ suy đoán mà không có bằng chứng trực tiếp, thì cuối cùng thiên kiến và định kiến sẽ không thể tránh khỏi.
Đáp lại ý "có vấn đề nhưng không có giải pháp khác", thì cũng có hệ thống dựa trên chứng chỉ như bác sĩ và luật sư. Người ta không yêu cầu bác sĩ biểu diễn thử trước khi mổ, dù mức độ rủi ro còn cao hơn. Thực ra chỉ những vị trí thấp hơn mới bị kiểm tra gắt gao, còn manager hay chức vụ cao, nơi tác động thực tế còn lớn hơn, lại qua cửa dễ hơn nhiều.
Tôi nghĩ bắt viết pseudocode trên whiteboard sẽ tốt hơn. Nó giảm áp lực cú pháp và cho thấy rõ hơn logic giải quyết vấn đề. Đồng thời nó cũng hợp với cách cộng tác của tôi hơn, vì tôi thường cùng trao đổi ý tưởng trên whiteboard.
Hiện tượng “stress tách biệt với năng lực” cứ lặp đi lặp lại. Bài báo của Microsoft cũng rất tệ. Hầu hết lời khuyên chỉ kiểu "cứ cày LeetCode đi", nhưng lại bỏ qua stress (cortisol). Tôi đang luyện bằng cách tự làm quen với chính môi trường stress đó. Bạn bè không thể ép mình tập đủ nặng, còn thuê coach thì tính theo giờ quá đắt. Vì vậy dạo này tôi đang làm side project tên là Tough Tongue AI. Nó là một live code editor trả lời bằng giọng nói, có đặt câu hỏi thời gian thực, gây nhiễu và phản hồi ngay lập tức. Nhờ kiểu luyện này, cảm giác "có người đang nhìn mình" dần trở nên quen hơn. Nếu live coding interview còn tiếp diễn, thì ta cần cách luyện không chỉ thuật toán mà cả phản ứng sinh lý với stress.