Những người chán ngấy phỏng vấn kiểu LeetCode

• Sau khi rời Robinhood vào cuối tháng 11/2023 vì vấn đề sức khỏe và trải qua nhiều quy trình tuyển dụng, tác giả cảm thấy cách đánh giá kiểu LeetCode không phù hợp với công việc kỹ sư phần mềm thực tế
• Nhận thấy nhiều công ty lặp lại các kiểu phỏng vấn tương tự vì bắt chước phương pháp của các công ty công nghệ lớn như Google, Facebook/Meta và Amazon
• Phê phán rằng các kỹ sư thường nói không cần ghi nhớ những kiến thức có thể tra cứu, nhưng trong phỏng vấn lại hỏi như đố vui về những kiến thức có thể tra cứu mà khó nhớ ra ngay tại chỗ
• Tác giả từng trải qua cả thành công lẫn thất bại trong những buổi phỏng vấn như vậy, và cơ sở cho sự bất mãn này đến từ kinh nghiệm làm việc thực tế trước đây hơn là từ trải nghiệm thất bại
• Bổ sung rằng nếu có công ty đang tìm kỹ sư có kinh nghiệm AWS, Kubernetes, Ruby on Rails và không tổ chức những câu đố vô bổ, thì có thể liên hệ

---

Những điểm phỏng vấn kiểu LeetCode lệch khỏi công việc thực tế

• Sau khi rời Robinhood vào cuối tháng 11/2023 vì lý do sức khỏe, tác giả đã phỏng vấn với nhiều công ty
• Các quy trình tuyển dụng không đi đến kết quả vì nhiều lý do, nhưng bản thân các phỏng vấn kiểu LeetCode lặp đi lặp lại khiến tác giả mệt mỏi
• Tác giả cho rằng những buổi phỏng vấn này không phản ánh đầy đủ trách nhiệm của kỹ sư phần mềm trong thực tế
• Nhiều công ty dường như áp dụng cùng một cách đánh giá chỉ vì đó là phương pháp mà các công ty lớn như Google, Facebook/Meta và Amazon đang dùng

Xung đột giữa đánh giá kiểu đố vui và kinh nghiệm thực tế

• Có những kỹ sư thường nói rằng không cần ghi nhớ các kiến thức có thể dễ dàng tìm bằng Google
• Nhưng trong phỏng vấn, đôi khi họ lại hỏi những nội dung dù có thể tra cứu nhưng khó nhớ ra ngay tại chỗ, nên tác giả cảm thấy điều này mâu thuẫn
• Không có giải pháp rõ ràng cho vấn đề này, nhưng tác giả cho rằng bản thân vấn đề là rất rõ
• Tác giả đã trải qua cả thành công lẫn thất bại trong kiểu phỏng vấn này, và quan điểm này chịu ảnh hưởng từ kinh nghiệm chuyên môn trước đây nhiều hơn là từ tỷ lệ thất bại
• Nếu công ty nào cần một kỹ sư phần mềm có kinh nghiệm AWS, Kubernetes, Ruby on Rails và không tổ chức phỏng vấn kiểu đố vui, thì có thể liên hệ
• Tác giả gợi ý đọc thêm bài Re-imagining Technical Interviews: Valuing Experience Over Exam Skills

[GN⁺]

Ý kiến trên Hacker News

• Tôi hiểu sự bức bối, nhưng rốt cuộc kiểu phỏng vấn này cũng có mục đích. Dù không hoàn hảo, nó vẫn đủ dùng, và thường tạo ra nhiều âm tính giả hơn dương tính giả, nên xét từ phía công ty thì cũng hợp lý
  Chi phí để đánh rớt một người thông minh là thấp, nhưng nếu tuyển nhầm người thì phải mất vài tháng để xác minh, sa thải rồi tuyển lại, nên chi phí rất lớn. Tuy vậy, với ứng viên thì đây là một quá trình cực kỳ đau đớn, và ngay cả một kỹ sư phần mềm giỏi cũng có thể căng thẳng, bỏ sót, hoặc gặp ngày xui nên trượt vài lần. Phỏng vấn không phải là đánh giá cuối cùng về giá trị cuộc đời, mà chỉ là một công cụ thô kệch, nên cứ bỏ qua thôi

  • Ở các công ty tôi từng điều hành, vì vậy chúng tôi dùng các ví dụ trên bảng trắng đơn giản. Không để ý lỗi gõ, mà xem người đó suy nghĩ như thế nào
    Câu hỏi “gài bẫy” là ngu ngốc, nhưng vẫn cần xem ứng viên có nắm kiến thức cơ bản không, đồng thời cũng phải cho họ thấy công ty mình là nơi như thế nào. Ví dụ, hỏi “Tôi có được sửa đối số không?” hoặc nói “Tôi không nhớ strlen có tính byte 0 hay không nên tôi sẽ cộng thêm 1, bình thường tôi sẽ tra cứu” là tín hiệu tốt. Bài toán ở mức cơ bản nhưng không quá tầm thường như fizzbuzz, chẳng hạn atoi hoặc “xáo một bộ bài”. Một trong những người chúng tôi tuyển tốt nhất đã mắc một lỗi nền tảng, nhưng khi được hỏi liệu nó có chạy đúng như dự định không, anh ta nói “Tôi đúng là thằng ngu chết tiệt” rồi sửa ngay. Cách nói đó có thể không phù hợp trong phỏng vấn, nhưng chúng tôi xem đó là tín hiệu rất tích cực. Ngược lại, cũng có ứng viên khăng khăng cho rằng câu hỏi phân tích chuỗi để trả về số nguyên là bất công vì đã có hàm thư viện sẵn, trong khi thực tế một phần hệ thống của chúng tôi chạy trong môi trường nhúng không có thư viện
  • Dù có ra câu đố thì cũng nên cho mọi người được tìm kiếm. Kỹ sư phần mềm thực sự làm việc như vậy, không nên biến nó thành một bài thi
    Tôi mong đừng bắt chước kiểu ưu tiên kiểm tra trí nhớ như những bài thi kinh khủng ở trường phổ thông và đại học. Tôi rất khổ sở vì không thể nhớ ra ngay tại chỗ khi cần, và chắc chắn không chỉ mình tôi như vậy. Khi phỏng vấn lập trình viên Android, tôi đặt câu hỏi và quan sát cách họ suy nghĩ, chứ không kỳ vọng mọi câu trả lời đều chính xác. Sau khi xem họ có hiểu cơ bản về Android không, tôi cho họ làm một ứng dụng nhỏ ở nhà
  • Tôi đã thấy lập luận rằng “người thông minh bị đánh rớt còn kẻ ngốc được tuyển thì ít xảy ra”, nhưng tôi nghi ngờ liệu điều đó có thật sự đúng không. Đặc biệt nếu còn tin vào một quan niệm phổ biến khác trong tuyển dụng rằng “phần lớn ứng viên không đủ năng lực”
    Trong tuyển dụng, nơi cuối cùng vẫn phải lấp chỗ trống, âm tính giả càng tăng thì xác suất tuyển phải dương tính giả cũng tăng. Cực đoan mà nói, nếu trên Trái Đất chỉ có một người phù hợp với công việc đó mà bạn đánh rớt người ấy như một âm tính giả, thì lựa chọn còn lại chỉ là tuyển nhầm người
  • Kiểu phỏng vấn này cũng tạo ra nhiều dương tính giả. Chỉ là không phải “tuyển kẻ ngốc”, mà là tuyển người hoàn toàn không phù hợp với công việc thực tế nhưng giỏi LeetCode
    Vấn đề không phải là thiếu trí thông minh, mà là có người giải bài thuật toán giỏi nhưng không phải kỹ sư phần mềm, hoặc thiếu năng lực mà vị trí đó yêu cầu. Tôi đang làm trong một đội tuyển rất nhiều người bằng kiểu phỏng vấn đố mẹo; ai cũng thông minh, nhưng họ không phải kỹ sư phần mềm, và sự khác biệt đó lộ ra rất rõ
  • Các bài LeetCode khó chọn ra người đã luyện tập lặp đi lặp lại, chứ không phải người biết suy nghĩ. Nhiều bài trong số đó, khi lần đầu được giải vài chục năm trước, đủ tầm để viết thành bài báo khoa học, và ngay cả người rất thông minh cũng khó tự suy ra kết quả tương tự từ đầu trong vài chục phút
    Nếu ai đó giải được, khả năng cao hơn nhiều là họ đã gặp đúng hoặc gần đúng bài đó trong lúc luyện tập, chứ không phải thật sự tự suy ra lời giải tối ưu mới

• Có lần tôi từng có một buổi phỏng vấn khá ưng ý, ở một ngân hàng. Họ đưa cho tôi đoạn mã bẩn được viết vội, nhưng không phải cố tình làm rối, rồi bảo hãy refactor tốt nhất có thể
  Người phỏng vấn ngồi cạnh và trò chuyện trong suốt quá trình, gần như là pair programming do ứng viên dẫn dắt. Sau các buổi phỏng vấn LeetCode thì cảm giác rất mới mẻ. Tất nhiên, ngân hàng đó biết chính xác công nghệ họ dùng và ít cần đo khả năng học công nghệ mới, nên cách này mới khả thi. Với họ, điều quan trọng hơn là liệu tôi có tạo được mã dễ bảo trì không, đặt tên có đúng không, và giao tiếp với đồng nghiệp ra sao

  • Phỏng vấn LeetCode cũng đâu đo được khả năng học công nghệ mới của ứng viên, phải không
  • Tôi cũng thường dùng kiểu phỏng vấn này. Ban đầu là nội dung rất cơ bản, và vì công việc của tôi chủ yếu liên quan đến cơ sở dữ liệu, phần tiếp theo thường chuyển sang code review
    Điều thú vị là có những người gần như thất bại ở câu hỏi cơ bản, nhưng đến phần code review lại làm tốt đến mức bộc lộ chuyên môn sâu. Phỏng vấn là công cụ khá tệ để thể hiện năng lực làm việc của một người, nhưng nếu họ có thể nhìn vấn đề cả rộng lẫn hẹp và cũng viết code đủ tốt, thì nhìn chung tôi xem đó là thành công

• Phỏng vấn kiểu LeetCode có lẽ phục vụ hai chức năng. Thứ nhất, nó là một cách kìm hãm tiền lương và khả năng nhảy việc của kỹ sư phần mềm. Muốn chuyển việc thì phải học một, hai tháng, vậy ai có thể dễ dàng chuyển được
  Nếu xui xẻo gặp một người phỏng vấn đã chuẩn bị rất kỹ rồi ném cho bạn một quả bom cỡ LeetCode hard, thì trong vòng 1 năm bạn cũng khó mà ứng tuyển lại vào công ty đó. Thứ hai, nó trở thành công cụ che lấp thiên kiến trong quy trình bằng cách tuyên bố rằng đã đưa cho mọi người một mục tiêu tương tự và rõ ràng. Nếu cùng trường, cùng giới tính, cùng chủng tộc, thì dù đưa cùng một bài, họ vẫn có thể gợi ý, bỏ qua lỗi cú pháp, và dù không đưa ra được cách tiếp cận tối ưu vẫn có thể đánh giá tuyển dụng rất cao vì “giao tiếp”. Còn nếu không thích ai đó thì chỉ cần ném một bài khó rồi im lặng suốt buổi phỏng vấn. Với công ty thì đó là nhiễu có thể chấp nhận được, nhưng với cá nhân thì là mất cơ hội nhận mức đãi ngộ hàng trăm nghìn đô la. Tôi đã phỏng vấn ở FAANG và cũng từng làm người phỏng vấn; tôi đã thấy những người được tuyển với tiêu chuẩn thấp, đồng thời cũng thấy các kỹ sư xuất sắc mất cơ hội vì những câu hỏi phi lý như quadtree hay lý thuyết số

  • Quy trình nào cũng có thể bị cố ý vận hành bất công, nhưng tôi cho rằng nếu có bài kiểm tra chuẩn hóa thì quy trình lại công bằng hơn nhiều
    Nếu giả định có người phỏng vấn công bằng, cách này cho cả những ứng viên không có tên tuổi nổi tiếng trên CV cơ hội thể hiện năng lực. Một số cơ hội tôi có được, dù không có bằng khoa học máy tính, chắc chắn sẽ không bao giờ tồn tại nếu không có phỏng vấn bảng trắng. Thật khó hình dung có cách nào ngăn người phỏng vấn cố tình đảo ngược quy trình để tuyển bạn mình
  • Vấn đề được mô tả ở đây không phải là bản thân LeetCode, mà là độ lệch giữa các buổi phỏng vấn và thiên kiến tuyển dụng. Nó xuất hiện trong mọi hình thức phỏng vấn
    Nhiều công ty có ngân hàng câu hỏi được thiết kế công bằng và ít nhiều liên quan đến vấn đề thực tế. Các công ty tôi từng phỏng vấn nhìn chung cũng vậy, và dù không phải nguyên xi bài LeetCode, rốt cuộc đó vẫn là bài code tách biệt nên tôi xem là kiểu LeetCode. Phỏng vấn ở những công ty vận hành tốt cách này khá ổn. Công ty và người phỏng vấn tốt không chỉ nhìn vào đoạn code cuối cùng, và cũng chấm điểm tuyển dụng theo thang để giảm kiểu quyết định nhị phân
  • Vấn đề không phải là bản thân hình thức phỏng vấn code đơn giản 30–50 phút và cấu trúc dữ liệu · thuật toán, mà là độ khó ngày càng tăng
    Thực tế chỉ riêng fizzbuzz cũng đã lọc được 75%. Nhiều người không viết được code khi bị áp lực, và cũng có người cố trụ bằng cách sao chép · dán. Những người này không phải hoàn toàn không làm được việc gì, nhưng họ chậm, đưa ra các abstraction kỳ quặc, và ngốn nhiều thời gian trước khi có được kết quả dùng được. Và vì với họ cũng là chuyện hàng trăm nghìn đô la, họ sẽ phản bác y như vậy
  • Cách này cũng rất tốt để lọc những người có hạn chế về thời gian như con cái, chăm sóc cha mẹ già, vấn đề sức khỏe
    Từ phía công ty thì hợp lý. Vì họ muốn nhân viên không bị phân tâm và có thể làm thêm giờ
  • Nếu muốn mức đãi ngộ cao nhất thì phải chơi trò chơi đó. Nghề nào cũng vậy; chẳng lẽ mọi người nghĩ luật sư muốn vào các hãng luật hàng đầu thì dễ hơn sao
    Có nhiều phê bình xác đáng về thực tiễn tuyển dụng công nghệ ngày nay, nhưng lời than phiền rằng “không thể trở nên cực kỳ giàu có nếu không bán linh hồn” thì không thuyết phục lắm

• Khi sàng lọc kỹ sư phần mềm, điều quan trọng không phải là kiến thức mà là năng lực giải quyết vấn đề và khả năng xây dựng mô hình tinh thần của vấn đề
  Nếu ứng viên chưa từng thấy bài đó trước đây và người phỏng vấn hiểu mình cần quan sát điều gì, phỏng vấn bảng trắng là một cách tốt để đánh giá năng lực này. Nhưng giống như định luật Goodhart, khi thước đo trở thành mục tiêu thì nó không còn là chỉ báo tốt nữa. Những người yếu về giải quyết vấn đề hoặc năng lực mô hình hóa cũng muốn công việc phần mềm lương cao nên cày LeetCode; theo thời gian, khi những người đó trở thành người phỏng vấn, họ tiến hành phỏng vấn như một bài kiểm tra trí nhớ, đúng như cách họ từng trải qua. Dù vậy, xét các ràng buộc của công ty, nhu cầu giảm lãng phí thời gian của ứng viên và duy trì phiếu đánh giá nhất quán mà HR thích, tôi vẫn chưa thấy phương pháp phỏng vấn nào tốt hơn được đề xuất, và có lẽ nó sẽ tiếp tục được dùng trong một thời gian

  • Cách tốt hơn thì khá dễ tiếp cận. Hãy yêu cầu ứng viên xây một thứ quen thuộc như máy tính bỏ túi hay lịch, hoặc đưa cho họ một cụm code rồi yêu cầu sửa hoặc tìm bug
    Nó gần với việc làm phần mềm hơn. LeetCode quá xa công việc thực tế, và kết quả cũng có tương quan quá yếu với mức độ phù hợp thực tế
  • Cũng có thể kết luận rằng điểm LeetCode càng cao thì càng là chỉ báo tốt về người sẽ bị LLM thay thế
  • Người ta nói “hạng A tuyển hạng B, hạng B tuyển hạng C”, và rốt cuộc để ngăn chuyện đó, họ lại nhét thêm LeetCode vào quy trình phỏng vấn
  • Tại sao công ty lại thật sự quan tâm đến vấn đề này và cố làm quy trình tuyển dụng bớt đối kháng hơn? Vẫn có rất nhiều ứng viên sẵn sàng vượt qua bất kỳ bài kiểm tra nào được đưa ra
    Đó là cái xô bị rò, nhưng công ty hài lòng với hiện trạng, còn lập trình viên thì tiếp tục cày LeetCode. Có vẻ nó sẽ không sớm thay đổi, nhưng may là khi tìm việc mới, tôi ở trong tình thế có thể từ chối kiểu phỏng vấn này

• Một người bạn của tôi từng đột nhiên ngừng nói rồi đứng dậy bỏ đi giữa buổi phỏng vấn kỹ thuật. Người của công ty đuổi theo và nói “Sao vậy, anh đang làm tốt mà!”, nhưng anh ấy bảo mình đã trở nên quá chán nản và không còn hứng thú nữa
  Với đa số người, đây hẳn là một nghề thú vị, nên chuyện đó thật buồn

  • Tôi cũng từng làm điều tương tự. Đó là một công ty game nổi tiếng về phúc lợi nhưng cũng nổi tiếng với lịch sản xuất điên rồ, và ban đầu tôi thật sự muốn vào đó
    Nhưng đến khoảng giữa buổi phỏng vấn thì họ đưa bảng trắng ra, đồng nghiệp bước vào và yêu cầu tôi dùng bút triển khai những thứ cơ bản; càng về sau họ càng đối kháng và thô lỗ, đến mức tôi cảm thấy như một dạng bắt nạt được nghi thức hóa. Có vẻ như họ đang kiểm tra xem tôi có thể chịu đựng sự sỉ nhục và thù địch trong khi tạo ra một kết quả kỹ thuật vụn vặt hay không. Cuối cùng tôi dừng buổi phỏng vấn và nói: “Tôi đã thấy cách các anh làm việc, nên tôi quyết định không muốn làm việc ở đây. Cảm ơn vì cơ hội và xin lỗi vì đã làm mất thời gian của cả hai bên”, rồi bước ra. CEO đuổi theo tôi ra tận bãi đỗ xe để hỏi vì sao lại thành ra như vậy, và dường như ông ấy thật sự sốc trước việc ứng viên cũng có thể đưa ra quyết định ngay trong buổi phỏng vấn. Mọi người quên rằng phỏng vấn việc làm là hai chiều. Sau ngày hôm đó, tôi nhận ra mình có quyền xem xét mọi khía cạnh của công ty nơi mình có thể làm việc, và nếu thấy điều tiêu cực trong quy trình thì không cần thỏa hiệp. Ngày hôm sau, tôi gặp những người ở công ty đối thủ mà đến nay vẫn là bạn tốt và đồng nghiệp tốt, nên đó là quyết định đúng. Nghề này thú vị, nhưng nếu niềm vui đó bị thu hoạch và khai thác như ở nông trại thì chẳng khác gì các hình thức nô dịch khác
  • Tôi cũng từng làm chuyện tương tự trong một buổi phỏng vấn qua Zoom. Tôi nhận được một bài LeetCode hard khó và hoàn toàn bí, còn người phỏng vấn cũng không có vẻ muốn giúp
    Khi tôi nói “Có vẻ hôm nay không phải ngày của tôi, và tôi muốn dừng buổi phỏng vấn”, từ lúc đó họ khá cố gắng giữ tôi ở lại cho hết thời gian còn lại. Tôi nghĩ nếu ứng viên muốn rời đi thì nên để họ đi

• Đến tận 5 năm sau, tôi vẫn từ chối kiểu phỏng vấn này và không muốn trải qua quy trình đó lần nào nữa. Tôi đã bị quấy rối và chế giễu bởi những người đối xử với con người như một trò đá đạp kéo dài một giờ, và tôi không muốn dây dưa thêm nữa
  Vì có nhiều buổi phỏng vấn LeetCode không báo trước, tôi đã ghi rõ trên hồ sơ LinkedIn [1] và GitHub [2] của mình những gì được chấp nhận và không được chấp nhận. “Tôi có chính sách cá nhân phản đối mọi hình thức live coding hoặc bài kiểm tra coding online trong lúc phỏng vấn, và tôi không thích cũng không tham gia lập trình thi đấu. Thay vào đó, tôi sẵn sàng làm bài tập coding offline có mục tiêu và thời hạn hợp lý, cũng như tham gia thảo luận kỹ thuật sâu về kiến trúc và thiết kế phần mềm cùng các công nghệ liên quan.”
  [1] https://www.linkedin.com/in/mtodor
  [2] https://github.com/mihaitodor

  • Những người đang tìm developer cũng có thể cùng nhau tạo ra thứ gì đó giống như điều khoản sử dụng. Việc đó có thể buộc HR phải nắm rõ và suy nghĩ lại cách làm của họ
  • Tôi thích cách tiếp cận này. Bạn có thể chia sẻ thực tế nó hiệu quả đến đâu không
    Tuy nhiên, có nhiều ý kiến cho rằng gian lận trong phỏng vấn dạng bài tập mang về đang tràn lan, nên tôi lo số nhà tuyển dụng muốn dùng hình thức này sẽ giảm mạnh

• Thử đóng vai luật sư của quỷ thì LeetCode được dùng trong tuyển dụng cá nhân đóng góp trung bình để sàng lọc một hoặc cả hai điều. Có chăm chỉ không, tức là có phải người học nhiều bài, học thuộc lời giải và lặp lại không. Hoặc có thông minh không, tức là người dù không luyện LeetCode vẫn nắm nền tảng và có thể tổng hợp kiến thức cũ để trả lời câu hỏi mới không
  Nếu không có thông tin gì khác, tôi cho rằng người không vượt qua được bài LeetCode nhiều khả năng không thuộc nhóm nào trong hai nhóm đó. Với vai trò cần coding, tôi nghĩ ít nhất họ phải giải được một bài LeetCode mức dễ đến trung bình, dù cần một chút gợi ý từ người phỏng vấn. Thực tế, các công ty càng tuyển vị trí senior hơn hoặc vai trò càng chuyên biệt thì càng giảm trọng số năng lực LeetCode. Còn có rất nhiều phần như sửa bug, thiết kế hệ thống, phỏng vấn hành vi, bài tập, câu hỏi kiến thức lặt vặt, câu hỏi đặc thù theo nền tảng; ở tuyển dụng trên mức junior, LeetCode không phải là tất cả. Nó không phải công cụ thần kỳ để chọn ra kỹ sư giỏi nhất, mà chỉ là một tín hiệu nữa cho hội đồng tuyển dụng sử dụng

  • Đây là kỹ năng mà sinh viên đại học 4 năm học vào khoảng 19 tuổi, rồi gần như không dùng trong 50 năm sau khi thực sự xây dựng thứ gì đó
    Nó không đánh giá được năng lực kỹ thuật để đẩy việc đến cùng trong phạm vi ngân sách. Nhìn tích cực thì chỉ là thứ bên lề; nhìn tiêu cực thì là chỉ báo thay thế cho phân biệt tuổi tác, ưu ái những người gần 19 tuổi hơn. Có lẽ vì vậy mà ngành này chật vật đến thế trong việc tạo ra phần mềm chất lượng tốt. Cách tốt hơn là đưa ra một tình huống lỗi như build bị hỏng hoặc code bị crash rồi yêu cầu sửa. Nếu ứng viên có thể khám phá hệ thống, chẩn đoán lỗi, tìm nguyên nhân, đề xuất patch, và khớp với phong cách code/chú thích, đó mới là người thực sự cần. Có thể có branch và issue tracker, cuộc thảo luận về bug đã diễn ra, hoặc trong comment có file patch phải áp dụng thủ công. Patch có thể có bug mới, hoặc là mồi nhử đụng vào một vấn đề tương tự nhưng không liên quan. Có thể đó là hồi quy của một bug đã đóng nhưng không có unit test; hoặc có test nhưng ứng viên phải tự tìm ra, hay bản thân test đã cũ và đầy lỗi. Đây mới là công việc thật. Sau khi kết thúc, nói “unit test bị hỏng” và nói “tôi không hiểu cách chạy đúng nên bỏ qua” là khác biệt lớn về thái độ, và người chơi theo đội là vế sau
  • Phần lớn ứng viên đã có việc làm. Nếu là người thật sự làm việc chăm chỉ, việc họ còn dư dả năng lượng để giải LeetCode bên cạnh công việc chính lại hiếm hơn
    Vì vậy, ngược lại, bạn cũng có thể nhận được một ứng viên không đạt thành tích xuất sắc ở vai trò hiện tại nhưng dùng năng lượng dư thừa để cày LeetCode
  • Bài LeetCode, theo định nghĩa, không thể gần với vấn đề thực tế. Vì nó bị tách khỏi ngữ cảnh
    Chỉ cần làm dự án vài tuần, người thông minh có thể có được những insight thực sự cần thiết. Những câu đố bất ngờ mà LeetCode đưa ra giống ô chữ trên tạp chí ngày xưa hơn
  • Nghĩ rằng có thể tự nghĩ ra thuật toán Dijkstra trong phỏng vấn chỉ từ nguyên lý là một sự kiêu ngạo khủng khiếp
    Lý do duy nhất bạn làm được là vì trước đó bạn đã học nó
  • Nói rằng lên senior thì trọng số LeetCode giảm, vậy khi nào điều đó bắt đầu? Tôi đã có hơn 8 năm kinh nghiệm mà vẫn mệt mỏi vì bị yêu cầu nghĩ ra lời giải bingo NxM trong 30 phút
    Nếu là năm 2022, tôi sẽ đồng ý rằng LeetCode không phải công cụ để chọn kỹ sư giỏi nhất, nhưng đến 2024 thì dù trả lời đúng cũng bị loại nhiều hơn vì không đủ nhanh hoặc không giải được nếu không có gợi ý. Tôi không phải thiên tài LeetCode, còn quá nhiều thứ phải học, và tỷ trọng LeetCode trong phỏng vấn khoảng 20%, nhưng tôi không cảm thấy nó tệ hơn nhiều so với 2 năm trước. Chỉ là kỳ vọng của các công ty đã vọt lên trời, và có xu hướng muốn mua vai trò hơn 15 năm kinh nghiệm bằng mức lương của người 5 năm kinh nghiệm

• Một điểm thú vị ít được nhắc đến về phỏng vấn kiểu LeetCode là nó giống một dạng nghi thức nhập môn trí tuệ
  Việc nghi thức gia nhập càng khắc nghiệt thì mức độ cam kết của những người vào được nhóm càng tăng mạnh là điều đã được chứng minh nhiều lần

  • Vấn đề là kẻ thua thì không vượt qua bài kiểm tra, còn người thắng thì vượt qua
    Khi một công ty tư bản tuyển lập trình viên, giữa “những người thông minh và giống nhau, tin vào đáp án đúng” và “một nhóm người có kỹ năng được trộn ngẫu nhiên”, cái nào tốt hơn? Nếu bạn trả lời là vế sau thì bạn là người duy tâm, và ý kiến đó thực tế không quan trọng. Tự nhiên sẽ thay thế bạn bằng người thông minh hơn và thực tế hơn

• Trong vài buổi phỏng vấn gần đây, chúng tôi cho ứng viên xem mã mẫu và yêu cầu họ review. Trong mẫu đó, mỗi dòng đều có ít nhất một bug hoặc vấn đề
  Tiếp theo là bài toán mô hình hóa, thường làm trên whiteboard. Cũng có bài tập đơn giản kiểu fizzbuzz để xem một junior có thật sự đảm nhận được vai trò junior không, đồng thời dùng làm điểm khởi đầu để trò chuyện về các chủ đề như độ phức tạp thời gian chạy hay bố trí bộ nhớ. Tùy theo cách ứng viên thực hiện mà buổi phỏng vấn diễn ra rất tương tác; mục đích là lọc ra những người “giả” đã bằng cách nào đó vượt qua vòng screening, và phần nào cảm nhận được độ phù hợp văn hóa

  • Tôi thích đưa cho ứng viên các unit test đang bị lỗi, rồi để họ sửa trong vòng 1 giờ bằng công cụ của họ, trong môi trường thoải mái như ở nhà
    Tôi tạo các vấn đề lộn xộn như kiểm tra múi giờ hoặc số điện thoại, và dùng tài liệu Wikipedia làm đặc tả. Khi xong thì hỏi về lời giải và review code. Senior giỏi nhất thì đơn giản là dùng thư viện. Ứng viên tốt thì tự làm nhưng có thể giải thích các đánh đổi. Junior thì chỉ làm cho test pass rồi dừng lại
  • Thứ tôi hay dùng là cái này
    https://github.com/emilybache/GildedRose-Refactoring-Kata
    Tôi để ứng viên làm bằng ngôn ngữ họ thích, và nó là một bộ lọc rất hiệu quả

• Tôi từng phỏng vấn một ứng viên lập trình viên trông có vẻ biết rất nhiều lý thuyết, nhưng đến lúc bảo viết code thì thất bại thảm hại. Không triển khai nổi cả fizzbuzz, và một lập trình viên Java Senior còn không import được HashMap nếu không tra cứu
  Nó giống toán học. Với 562 * 1041 thì dùng máy tính là đúng, nhưng nếu phải lôi máy tính ra để biết 3 * 7 thì người ta sẽ nghi ngờ bạn có phải chuyên gia không. Nhiều công ty lạm dụng phỏng vấn kiểu LeetCode, nhưng một buổi live coding interview thể hiện thao tác mảng, điều khiển luồng và sử dụng cấu trúc dữ liệu cơ bản sẽ cho thấy ứng viên có “trí nhớ cơ bắp” chỉ có được từ kinh nghiệm hay không. Nếu để vượt qua mà phải học thuật toán duyệt đồ thị thì có lẽ bài đó quá kiểu LeetCode

  • Kiểm tra xem có thuộc tên package của HashMap hay không là bài test lập trình Java ngu ngốc nhất mà tôi từng nghe
  • Không import được HashMap tự nó là một tiêu chí buồn cười. Một sinh viên vừa xem ví dụ HashMap trong Java có khi lại nhớ được import
    Nhưng trong chương trình cần nhiều yếu tố nhỏ nhặt như vậy, và trong thế giới quan đó thì tất cả đều phải thuộc lòng. Với 562 * 1041, người ta kỳ vọng bạn biết nguyên lý tính, tức là biết cách làm. Có thể tính sai, nhưng không được sai ý tưởng của phép nhân dài. Trong bối cảnh đó, quên một mục trong bảng cửu chương như 3 * 7 cũng không sao. Lập trình viên là người tổ chức việc tính toán, chứ không phải người trực tiếp tính; việc đó là của máy tính. Tôi đồng ý rằng với thuật toán duyệt đồ thị, chỉ cần biết tìm lời giải ở đâu, không nhất thiết phải nắm sẵn mọi lời giải trong tay
  • Eclipse tự import cho tôi mà tôi thậm chí không cần nhìn. IntelliJ cũng vậy
    Trong tình huống nào mà những người này phải tự import? Không có IDE à
  • Có phải người không biết HashMap nằm trong namespace nào thì cũng giống người không làm được 3 * 7 không
    Tôi không rõ đây có phải là châm biếm định kiến của người phỏng vấn không