Lời kêu gọi chấm dứt các thử thách lập trình phi thực tế
(blackentropy.bearblog.dev)- Một số bài tập lập trình phi thực tế trong phỏng vấn kỹ thuật tạo ra tình huống áp lực khác với công việc thực tế và không đo lường đúng năng lực làm việc thực tiễn của lập trình viên
- Các bài tập đơn độc, áp lực cao không phản ánh môi trường làm việc có cộng tác và hỗ trợ, và dễ biến thành việc debug codebase cũ mà không có tài liệu hay sự trợ giúp từ đội nhóm
- Ngay cả “bài tập 4 giờ” mà doanh nghiệp nói đến cũng có thể kéo dài thành 8–10 giờ hoặc hơn nếu tính cả việc tìm hiểu công ty, xem xét yêu cầu vị trí và trau chuốt sản phẩm bàn giao
- Bài tập dùng stack công nghệ không liên quan đến vai trò có thể được biện minh là đánh giá khả năng thích nghi, nhưng cách yêu cầu một lập trình viên Ruby debug PHP có thể lệch khỏi mức độ phù hợp thực tế
- Tuyển dụng nên tập trung vào công nghệ liên quan, giải quyết vấn đề, cộng tác và tiềm năng phát triển thay vì các bài tập áp lực cao tùy ý; bài tập quá mức có thể làm ứng viên giỏi kiệt sức và rời bỏ quy trình
Bài tập phỏng vấn lệch với công việc thực tế
- Một số cuộc phỏng vấn kỹ thuật yêu cầu lập trình viên hoàn thành các bài như debug PHP legacy hoặc xây dựng một ứng dụng mini trong vài giờ
- Những bài tập làm một mình như vậy khác với cách làm việc thực tế
- Trong công việc, thông thường có thể cộng tác với đội nhóm và nhận được hỗ trợ cần thiết
- Tình huống một mình debug thật nhanh một codebase cũ mà không có tài liệu hay sự trợ giúp từ đội nhóm không phù hợp với môi trường phát triển thông thường
- Doanh nghiệp xem đây là đánh giá “năng lực giải quyết vấn đề”, nhưng nếu bài tập không gắn với yêu cầu thực tế của vai trò thì khó thấy được mức độ phù hợp của ứng viên trong công việc
Chi phí thời gian ẩn và gánh nặng cho ứng viên
- Thời gian khuyến nghị của bài tập lập trình không phản ánh đầy đủ thời gian ứng viên thực sự bỏ ra
- Trước khi làm bài, họ phải tìm hiểu công ty và kiểm tra yêu cầu công việc
- Cũng cần thời gian để trau chuốt dự án nhằm tạo ra sản phẩm nộp ở trạng thái tốt
- Một bài tập “4 giờ” có thể kéo dài thành 8 giờ, 10 giờ hoặc hơn
- Với những lập trình viên phải cân bằng công việc và cuộc sống, điều này có thể tạo cảm giác như đang làm việc không lương cho một công việc mà họ còn chưa nhận được
Điểm lệch trong đánh giá khả năng thích nghi
- Bài tập dùng stack công nghệ không liên quan đôi khi được biện minh là để đánh giá “khả năng thích nghi”
- Cách yêu cầu một lập trình viên Ruby debug PHP có thể là tiêu chí không phù hợp để đánh giá giá trị của ứng viên, bất kể khả năng thích nghi có quan trọng đến đâu
- Chỉ dựa vào khả năng xử lý nhanh các bài tập mơ hồ và không liên quan thì khó đánh giá liệu ứng viên có phù hợp với vai trò thực tế hay không
- Một số bài tập có thể tạo cảm giác giống cách doanh nghiệp phô diễn tiêu chuẩn “tinh hoa” hơn là đánh giá mức độ phù hợp của ứng viên
- Nếu mọi đợt tuyển dụng đều dựng lên rào cản kiểu “top 1%”, cả những ứng viên lành nghề có thể làm tốt công việc thực tế cũng có thể rời bỏ quy trình vì các tình huống nhân tạo và áp lực cao
Bài tập tuyển dụng nên đánh giá điều gì
- Quy trình tuyển dụng nên được thiết kế xoay quanh kỹ năng cụ thể cần cho vai trò
- Nên tránh các bài tập kiểu bootcamp lập trình không liên quan đến yêu cầu công việc thực tế
- Nên tập trung vào giải quyết vấn đề, cộng tác và tiềm năng phát triển trong lĩnh vực liên quan
- Khả năng thích nghi nên được đánh giá như năng lực học hỏi dài hạn, chứ không phải tốc độ xử lý một bài tập tùy ý
1 bình luận
Các ý kiến trên Hacker News
Lần cuối bạn phải debug một codebase cũ không có tài liệu cũng không có đội ngũ hỗ trợ là khi nào? Với tôi thì lúc nào cũng vậy. Đó là một codebase C++ 300.000–400.000 dòng, và “legacy” nghĩa là hoàn toàn không có test, tài liệu thì gần như không có; tôi là lập trình viên duy nhất ở một công ty nhỏ, vừa phải tiếp tục phục vụ hàng chục nghìn người dùng vừa sửa lỗi và thêm tính năng.
Một ví dụ gần đây: có một bản vá cho tính năng cốt lõi bị bỏ đó hơn một năm, tác giả ban đầu thì không còn ở đó nữa, và tôi phải hoặc viết lại code từ đầu, hoặc hồi sinh bản vá đó để khớp với master.
Khả năng nhảy vào một dự án và dẫn dắt mọi người tới mục tiêu rõ ràng là kỹ năng cần có ở lập trình viên senior, và tôi đồng ý với kết luận rằng nên kiểm tra năng lực giải quyết vấn đề. Tuy nhiên, nội dung phỏng vấn kỹ thuật nên thay đổi theo vai trò; không cần bắt một lập trình viên web junior giải thuật đồ thị trên bảng trắng, nhưng một lập trình viên senior hay kiến trúc sư cho sản phẩm mạng xã hội thì phải hiểu sâu.
Tuần trước tôi cũng debug code Go từ năm 2020 không có chú thích hay tài liệu, cũng là phần cốt lõi của hệ thống, và trông như do người điên viết ra. Rất đau khổ.
Tôi cho rằng sự sẵn sàng đào xuống dưới để giải quyết vấn đề ở đúng tầng là một trong những kỹ năng mềm lớn phân biệt kỹ sư senior. Thay vì né bằng cách vá hậu kỳ trong code của mình cho các bug hoặc tính năng thiếu ở tầng thấp, nếu sửa ở đúng tầng thì toàn bộ hệ thống sẽ vững hơn trước các thay đổi lên xuống trong stack và những trường hợp sử dụng tương lai không lường trước.
Ngược lại, nếu không làm theo cách này, sau khi các kỹ sư senior rời đi hoặc bị thay bằng junior, codebase sẽ bắt đầu mục ruỗng. Ví dụ, nếu với mỗi trường hợp biên khi parse input lại gắn thêm một regex kiểm tra ngây thơ phía trước một parser đáng sợ và mờ mịt, thay vì sửa chính ngữ pháp của parser, thì codebase đang tiến hóa thành một đống bùn.
Tất nhiên, nếu sửa ở đúng tầng, công ty thường phải duy trì một nhánh hotfix dài hạn, riêng tư và nhỏ cho phần mềm hệ sinh thái mà stack đang dùng. Upstream thường không xem vấn đề đó là vấn đề nên không nhận patch, vì vậy bạn phải tự giữ lấy.
Nói nửa đùa thì nếu có thể xác thực trên hồ sơ GitHub và đếm số lần một kỹ sư đã tạo hoặc duy trì những nhánh hotfix riêng tư dài hạn như vậy, có khi còn đo seniority của họ đơn giản hơn nhiều so với coding test.
Cứ tỏ ra rằng nó vô dụng trong thực tế thì chẳng giúp được gì. Thực tế thì bừa bộn, tài liệu thường không có hoặc không đáng tin, và người hay đội đã viết code gốc có thể đã không còn nữa.
Có một giai thoại nhỏ. Vợ/chồng của một người bạn đã nghỉ việc hồi đầu năm nay rồi dành 4–6 tuần chuẩn bị phỏng vấn cho từng công ty Big Tech. Kiểu như Meta 4–6 tuần, Stripe 4–6 tuần; trong thời gian đó thỉnh thoảng cũng phỏng vấn ngẫu nhiên để luyện tập và tạo trí nhớ cơ bắp, tìm hiểu các dạng bài có thể xuất hiện ở từng công ty, rồi giải LeetCode vài tiếng mỗi ngày.
Kết quả là mọi chuyện diễn ra tốt đẹp và người đó nhận offer L6/staff của MAANG. Nhưng tuần này nói chuyện thì họ bảo rằng dù còn chưa bắt đầu vai trò mới, phần lớn chi tiết từng luyện đã quên mất rồi. Họ nói phần chuẩn bị thiết kế hệ thống là khó nhất vì trước đó không có kinh nghiệm thiết kế hệ thống, nhưng giờ đã trở thành staff eng ở MAANG. Qua một dự án nhỏ từng làm cùng, ngoài đời họ là một kỹ sư giỏi, nhưng không phải kiểu xuất sắc ngoại lệ.
Thật sự kỳ lạ, và có vẻ giải thích được khá nhiều về các chu kỳ bùng nổ và suy thoái trong tuyển dụng. Xem các video chuẩn bị phỏng vấn thiết kế hệ thống thì gần như giống một kịch bản. Vào phỏng vấn chỉ cần làm theo kịch bản, còn việc đã từng thực sự thiết kế một hệ thống tương tự hoặc phức tạp hơn hay chưa dường như không quan trọng. Mục đích của phỏng vấn thiết kế hệ thống rốt cuộc có vẻ là “có biết kịch bản không”.
Xem liên tiếp hai video này ở tốc độ 2x sẽ thấy ngạc nhiên vì chúng được thực hiện giống kịch bản đến mức nào: https://www.youtube.com/watch?v=4_qu1F9BXow, https://www.youtube.com/watch?v=_K-eupuDVEc
Cả bố mẹ tôi đều làm trong ngành công nghệ ở Santa Cruz những năm 1980–1990, thời đó nguồn ứng viên không lớn nên đây là một công cụ mang tính bao dung để tìm những người có thể phát triển thành lập trình viên. Ngành hiện nay đã tiếp nhận thông lệ đó nhưng lại biến nó thành thứ loại trừ theo hướng hoàn toàn ngược lại.
Một trong những người tôi từng tuyển là nhà vật lý, hoàn toàn không biết thuật ngữ chuyên môn và đã rất hoảng khi lần đầu thấy bài toán whiteboard. Khi tôi dẫn họ đến điểm họ thấy thoải mái, họ bắt đầu kể về các công cụ đã tự làm để hỗ trợ công việc vật lý, và rất ngạc nhiên khi tôi nói những công cụ họ làm mà không có kiến thức lập trình đó chính là phần mềm. Không chỉ thật sự là phần mềm, chúng còn cực kỳ ấn tượng; bài toán whiteboard khi ấy là công cụ để bộc lộ tiềm năng.
Tôi hiểu các công ty lớn muốn những “widget” có thể cắm vào dùng ngay thay vì con người, nhưng điều buồn cười là họ đang dùng một thứ vốn được tạo ra cho mục đích hoàn toàn ngược lại. Đôi khi tôi còn thấy may vì mình đã đủ già để không còn hy vọng vào được những công ty hào nhoáng dùng các code challenge kiểu này.
Lập luận là: bất kể bạn học đại học nào, đã học lớp gì, từng có lợi thế hay bất lợi nào, nếu bạn có những phẩm chất cần thiết cho vai trò thì đây là những nội dung có thể học trong vài tháng. Công nghệ đã được chuẩn hóa rất cao nên quy trình cũng trở nên khá khách quan.
Họ không kỳ vọng bạn sẽ dùng đúng kỹ năng cụ thể đó trong công việc thực tế. Thay vào đó, bạn chứng minh rằng mình có thể học loại kỹ năng như vậy và thực hiện ở mức cao trong bối cảnh phỏng vấn nhiều áp lực. Lập luận là đây là tín hiệu tốt cho việc liệu sau này bạn có thể học các kỹ năng cần cho dự án được giao và thực hiện dưới áp lực deadline lớn hay không.
Tôi không bênh vực hệ thống này, nhưng rõ ràng có một logic phía sau nó.
Họ nói là đã quên, nhưng nếu đã giành được vị trí đó thì có lẽ họ từng giải được các bài LeetCode độ khó trung bình. Khó có thể nói là quên hết; rất có khả năng họ vẫn giải được các bài dễ mà phần lớn mọi người không thể làm ngay tại chỗ. Họ cũng có lẽ vẫn biết độ phức tạp của các tác vụ backend thiết yếu như tìm kiếm, sắp xếp, mảng và tra cứu hash, duyệt cây và đồ thị.
Và tài năng diễn xuất có thể còn phổ biến trong dân số hơn tài năng lập trình.
Gần đây tôi đã điều hành quy trình phỏng vấn cho một vị trí kỹ sư tương đối senior ở một startup nhỏ. Tôi tin rằng mỗi người sẽ phù hợp hơn với những kiểu phỏng vấn khác nhau, nên đã cho tất cả ứng viên các lựa chọn
Vì đã thấy rất nhiều sự phẫn nộ với bài kiểm tra dạng bài tập về nhà, tôi tưởng ba lựa chọn sẽ được phân bổ khá đều, nhưng đáng ngạc nhiên là khoảng 90–95% ứng viên chọn bài kiểm tra dạng bài tập về nhà. Nếu là ứng viên thì đó cũng là cách tôi thích hơn, nên đây là dữ liệu thú vị; và việc đa số thích cách đó làm tôi rất ngạc nhiên
Phỏng vấn trực tiếp cũng khiến công ty phải trả chi phí đáng kể, nên có thể xem là khả năng thời gian của tôi bị lãng phí thấp hơn. Tính bất đối xứng trong quá trình tìm việc vốn đã lớn, và bài tập về nhà còn đẩy nhanh xu hướng đó
Trước đây một người bạn không làm kỹ thuật đến giờ vẫn không hài lòng với tôi vì tôi không hoàn thành một bài tập; yêu cầu cốt lõi rõ ràng là tầm thường, nhưng chỉ dẫn đủ mơ hồ để tôi có thể đốt vài giờ chỉ để phán đoán liệu nộp như vậy đã đủ tốt chưa. Hơn nữa họ kỳ vọng một bộ kỹ năng hẹp; tuy không khó, nhưng tôi cũng không muốn học chỉ vì một cơ hội có thể giúp một công ty đang than “không tìm được nhân tài kỹ thuật”
Tôi nghĩ mình sẽ thích lựa chọn 1 và 2 hơn lựa chọn 3. Vì người phỏng vấn cần hiểu bài toán tôi đang giải thì mới đánh giá tốt hơn cách tiếp cận của tôi
Nếu làm ở nhà rồi nộp sau, người phỏng vấn có thể so sánh lời giải của tôi với lời giải của họ hoặc những lời giải khác, từ đó nắm rõ hơn phong cách code của tôi trên cùng một đề bài
Nếu làm pair programming cùng nhau, họ có thể thấy quá trình suy nghĩ của tôi, và tôi cũng giải thích tốt hơn vì sao chọn một idiom cụ thể
Code cũ gần như không có ngữ cảnh. Nó chỉ là code được viết cho một dự án khác. Ở giai đoạn đầu, gửi kèm résumé để xác nhận rằng tôi thực sự có thể viết code thì hữu ích, nhưng ở các giai đoạn sau nó chỉ ấn tượng khi có một app chạy được và tôi có thể dẫn họ qua phần code của một tính năng cụ thể. Nhưng có bao nhiêu người thật sự có sẵn phần mềm đang chạy? Thường thì chỉ có code chạy tạm nhờ vài mẹo vặt
Tôi thích lựa chọn 1 hơn lựa chọn 2. Vì khả năng mắc lỗi sẽ giảm. Thay vì chấp nhận rủi ro làm hỏng trong 2 giờ tại chỗ vì áp lực và định luật Murphy, rõ ràng tôi thà dành thêm 2 giờ ở nhà và có thời gian thoải mái tra cứu những thứ mình chưa biết
Tôi cũng từng ở phía đánh giá bài kiểm tra dạng bài tập về nhà, nên biết để gây ấn tượng sâu với ai đó bằng cách đó khó đến mức nào
Lần gần nhất tôi phỏng vấn code thực sự, tôi có thể chọn bất kỳ ngôn ngữ lập trình nào và cũng được chọn 1 trong 3 bài để giải. Tôi khá thích điều đó và cũng nhận được offer. Trong một buổi phỏng vấn có giới hạn thời gian, việc được chọn Python thay vì C++ gần như cảm giác như cheat vậy
Càng thấy nhiều lời phàn nàn trên mạng về phỏng vấn code, tôi càng tin chắc rằng phỏng vấn code là cách tốt nhất tuyệt đối để sàng lọc ứng viên cho vị trí phát triển phần mềm. Trong toàn ngành có quá nhiều người chỉ giỏi nói, kẻ giả mạo, người chuyên đặt lịch họp, và quá ít người xắn tay áo nhảy vào code để thật sự hoàn thành việc
Vấn đề này càng lên cấp cao càng nghiêm trọng hơn. Cứ thoải mái phàn nàn, nhưng không có chuyện đương nhiên được trao một công việc FAANG nhàn nhã 500.000 USD/năm. Nếu không muốn ôn lại lập trình cơ bản và viết vài vòng lặp for, công ty sẽ đơn giản chuyển sang người sẵn sàng làm việc đó
Nếu phỏng vấn thật sự kiểm tra khả năng xắn tay áo nhảy vào code, tôi không hiểu vì sao khi mới vào, tôi lại phải giải thích quá nhiều về thực hành software engineering và debug cho những người đã ở đó lâu hơn
Nếu từng làm việc thật sự ở công ty lớn, bạn sẽ biết 90% công việc thật được làm bởi không quá 5% số người. Nếu phỏng vấn hoạt động đúng, tỷ lệ này lẽ ra phải tốt hơn nhiều
Có Cracking the Coding Interview, Elements of Programming Interviews in Java/Python/các ngôn ngữ khác, LeetCode cùng các trang thuê bao premium trả phí, rồi cả bootcamp phỏng vấn thử. Giờ chuyện này gần với việc gaming hệ thống hơn là năng lực thực sự
Thật đáng ngạc nhiên là hoàn toàn không có bất hòa nhận thức nào giữa tiền đề rằng phỏng vấn code là cách tuyển dụng tiêu chuẩn và thực tế rằng kết quả lại tệ như vậy
Nếu bài toán là thứ như token hóa LLM, làm sao có thể cấm dùng LLM trong các bài “ML-LeetCode”?
Nếu ứng viên là chuyên gia code thành thạo bằng Cursor và Claude, giải được trong 10 phút với 3 prompt và sửa 2 lỗi dễ phát hiện, lại còn có bài báo cấp NeurIPS và code open source, thì tôi đã lọc ra một kẻ lừa đảo giả mạo hay đã loại mất một ứng viên hàng đầu?
Tôi không thấy các bài kiểu LeetCode có ý nghĩa với người làm việc liên quan đến LLM. Dù thích hay không, trong tương lai ngày càng nhiều công việc FAANG+ nhàn nhã 500.000 USD/năm sẽ liên quan đến LLM
Việc bắt một lập trình viên Ruby debug PHP để kiểm tra tính linh hoạt nghe như một bài test ổn. Một lập trình viên giỏi, đặc biệt là senior developer, phải làm được những việc như vậy. Tự phân loại mình chỉ là “lập trình viên Ruby” là một cái bẫy sự nghiệp
Có lúc phải debug một DSL cũ đặc thù của vendor, hoặc code dùng framework và tiêu chuẩn quá cũ đến mức gần như đã thành một ngôn ngữ khác
Cũng có việc thêm hỗ trợ cho tính năng được backport hoặc vá lỗ hổng bảo mật cho client cũ và stack legacy. Ở công ty lớn, từng có lúc chúng tôi phải chịu trách nhiệm phần code escrow của một đối tác nhỏ hơn rất nhiều
Thiết lập môi trường để có thể debug đúng cách thường là phần việc lớn hơn cả sửa lỗi thực tế. Dù vậy, đây vẫn là bài test tốt cho cấp senior trở lên
Khi người phỏng vấn nói “hãy đảo ngược mảng này”, tôi trả lời “Nếu là Python thì tôi sẽ dùng array.reverse() hoặc reversed(array), và trong JS chắc cũng có một trong hai cái đó, có lẽ là method .reverse”. Người phỏng vấn nói “đoán hay đấy”
Thật lòng là tôi thấy vui, bước ra với cảm giác đã học được vài thứ, và phía bên kia cũng thấy được cách tôi suy luận trước một vấn đề mới
Tôi đã nhiều lần debug codebase cũ không có tài liệu cũng không có đội ngũ hỗ trợ. Thực sự có những hệ thống mà người tạo ra nó không còn ai ở lại, còn tài liệu thì không có hoặc không thể tìm thấy. Vì vậy ví dụ này không hay lắm. Khả năng debug chương trình, lần theo luồng request và xem chuyện gì đang xảy ra là một kỹ năng tốt
Tuy nhiên điểm thực sự tệ của ví dụ này là nó nhốt lập trình viên vào một ô chuồng bồ câu theo công nghệ cụ thể. Nếu có một ứng dụng PHP legacy, bạn sẽ lọc mất những lập trình viên Java, Python, Ruby, Go có năng lực debug đó nhưng không biết PHP nên sẽ chậm hơn. Dù chỉ cần vài tháng trực tiếp đụng PHP, họ có thể còn là lập trình viên mạnh hơn
Tôi đồng ý rằng “bài tập 4 giờ” rất dễ kéo dài thành 8 giờ, 10 giờ hoặc hơn để tạo ra kết quả tốt. Thời gian nêu ra rất dễ bị lợi dụng, nên người có nhiều thời gian hơn có thể trông như ứng viên tốt hơn
Hỏi lần cuối tôi debug một codebase cũ không có tài liệu cũng không có đội ngũ hỗ trợ là khi nào ư? Ngày nào trong tuần này cũng vậy
Nếu nói về tài liệu, code được cập nhật lần cuối vào tháng 6, còn tài liệu được cập nhật lần cuối vào tháng 1/2022
Nếu nói về đội ngũ, một nửa số người không bị sa thải hai năm trước đều đã rời sang nơi tốt hơn. Tất nhiên vẫn có một đội sở hữu dự án này, nhưng họ cũng sở hữu thêm ba dự án khác, và trong một năm qua đóng góp cho dự án này chỉ khoảng hơn chục dòng, trong đó 11 dòng là cập nhật dependency
Những câu như “giống như bắt lập trình viên Ruby debug PHP”, “nếu công việc cần công nghệ cụ thể thì hãy test công nghệ đó” nghe như lời của người trượt coding challenge
Nói nghiêm túc thì các công ty hiếm khi áp dụng thông lệ tuyển dụng chỉ cho vui. Thường đó là cách tốt nhất mà trí tuệ tập thể của họ nghĩ ra. Bảo bỏ nó đi mà không cố hiểu vấn đề họ đang muốn giải quyết là gì, cũng không đưa ra phương án thay thế, thì không hiệu quả
Tôi nghĩ trong phát triển phần mềm, chúng ta quá hay phát minh lại bánh xe thay vì mượn thông lệ từ các nghề khác. Hãy xem kỹ sư xây dựng trải qua quy trình tuyển dụng nào để nhận mức lương bằng một nửa lập trình viên phần mềm, rồi thử tích hợp điều đó vào thông lệ của chúng ta. Khi đó tất cả sẽ trở thành những người lính vui vẻ
Tôi nghĩ khả năng họ từng tự suy ngẫm xem thực sự muốn đạt được điều gì là rất thấp. Chỉ là thấy người khác làm thì làm theo, và tin rằng đâu đó có ai đó đã thiết kế quy trình này với chủ đích
Tuyển dụng kỹ thuật đã lạc lối đến mức cảm giác như nó đã ổn định ở một nơi cùng lắm chỉ giống cực đại cục bộ
Tôi đã có trải nghiệm rất tệ ở một công ty hoàn toàn không làm coding test. Chỉ có 2–3 vòng phỏng vấn là hết
Vấn đề lộ ra khi tôi bắt đầu làm việc cùng đội data engineering. Phần lớn stack dựa trên Hadoop, Kubernetes, Ruby, Python và nhiều công nghệ khác, đồng thời cần hiểu biết cơ bản về cloud computing
Nhưng kinh nghiệm làm việc và nền tảng của mọi người quá khác nhau, nên thay vì làm việc mà tôi được tuyển vào, tôi thường phải lấp chỗ trống cho người khác. Một số đồng nghiệp không làm được cả các việc cơ bản như đóng gói Python CLI bằng Docker hay kiểm tra job Hadoop, nên tôi phải làm nhiều công việc keo dính để bù vào
Cuối cùng tôi rời đi. Không phải vì tôi nghĩ mình đặc biệt, mà vì tôi chán việc dùng 80% thời gian để hỗ trợ những người được tuyển vào cùng cấp hoặc cấp cao hơn. Tôi thừa nhận thông lệ tuyển dụng của công ty đó rất tệ, nhưng dưới hình thức nào đó vẫn cần có bài kiểm tra kỹ thuật cơ bản
Một câu hỏi quan trọng nữa là bạn có phải giải thích lặp đi lặp lại cùng một nội dung cho cùng một người không. Không biết thì có thể chấp nhận, nhưng không chịu học thì khó chấp nhận
Điểm thú vị của bài kiểm tra dạng bài tập là dù có nói “chỉ dùng X giờ” thì vẫn tồn tại moral hazard khiến ứng viên bị thúc đẩy dành nhiều thời gian hơn. Nếu công ty hỏi, cũng sẽ có động cơ để nói dối về thời gian thực sự đã bỏ ra
Tôi đã nhiều lần nhấn mạnh việc hoàn thành trong thời gian khuyến nghị, giải quyết bài toán ở mức phù hợp rồi nộp bài, nhưng trong buổi phỏng vấn tiếp theo lại bị trách: “Sao không triển khai X?”
Liên quan đến chuyện này, các bài kiểm tra dạng bài tập quá mở là bài tập tệ. Vì chúng có lợi cho những người có nhiều thời gian rảnh hơn để làm thật kỹ. Xin gửi lời chào đến bài kiểm tra dạng bài tập data science yêu cầu sản phẩm cuối cùng là slide thuyết trình PowerPoint