Trải nghiệm bị loại ở vòng phỏng vấn bài tập về nhà của Kagi Search

 (bloggeroo.dev)
4 điểm bởi GN⁺ 2025-05-16 | 1 bình luận | Chia sẻ qua WhatsApp
  • Nhấn mạnh sự kém hiệu quả của take-home assignment trong phỏng vấn lập trình viên và vấn đề lãng phí thời gian của ứng viên
  • Trong quá trình ứng tuyển vào Kagi Search, tác giả đã gặp yêu cầu bài tập quá rộng và mơ hồ
  • Với kế hoạch triển khai cụ thể đã đề xuất, tác giả trải nghiệm sự thiếu phản hồi rõ ràng từ quản lý và cách giao tiếp kém hiệu quả
  • Sau khi dốc nhiều công sức để phát triển dự án rồi nộp, tác giả cảm thấy bất hợp lý khi bị loại mà không có lý do rõ ràng và tiêu chí còn bị thay đổi
  • Chia sẻ các phương án thay thế cho quy trình tuyển dụng tốt hơn (ví dụ: review code theo thời gian thực) và nêu vấn đề về việc yêu cầu quá mức ở các vòng phỏng vấn dạng bài tập

Lời mở đầu

  • Take-home assignment là hình thức đánh giá trong phỏng vấn lập trình viên phần mềm, trong đó ứng viên được giao một bài toán và phải hiện thực nó bằng code rồi nộp lại
  • Bài viết này muốn chỉ ra tính bất hợp lý và vấn đề lãng phí thời gian của ứng viên thông qua bài tập thực tế và trải nghiệm khi ứng tuyển vào Kagi Search, một công ty mà tác giả từng cho là có danh tiếng tốt

Ứng tuyển vào Kagi Search

  • Tác giả đã nộp hồ sơ cho vị trí lập trình viên backend tại Kagi Search
  • Yêu cầu của vai trò này như sau
    • Kinh nghiệm xây dựng hệ thống backend
    • Khả năng sử dụng ngôn ngữ Go
    • Kinh nghiệm mở rộng và bảo trì các hệ thống backend quy mô lớn
    • Khả năng phối hợp với các thành viên trong nhóm như SRE
    • Hiểu biết về công nghệ container như Docker

Hướng dẫn bài tập phỏng vấn và yêu cầu

  • Sau khi qua vòng hồ sơ, tác giả đã nhận được email hướng dẫn về take-home assignment
  • Chủ đề bài tập: "triển khai một ứng dụng email client lấy cảm hứng từ terminal ở mức tối thiểu"
    • Có thể chọn dạng terminal hoặc web app
    • Chức năng cơ bản để xem/gửi email
    • Tự do chọn backend email giả lập hoặc thực tế (IMAP/POP, v.v.)
    • Chỉ bắt buộc xử lý tin nhắn plaintext, không cần rich text
    • Nộp dự án: repository GitHub, bản triển khai, kèm tài liệu hướng dẫn cài đặt
  • Thiếu hướng dẫn rõ ràng và quy mô dự án khá lớn
  • Dù vậy, vì danh tiếng của công ty nên tác giả vẫn quyết định làm bài

Giao tiếp với quản lý

  • Khi hỏi về phạm vi bài tập rõ ràng và các tính năng bổ sung, tác giả chỉ nhận được câu trả lời mơ hồ kiểu “thêm gì là tùy ứng viên”
  • Trước khi đầu tư thời gian và công sức vào bài tập, tác giả đã chia sẻ kế hoạch triển khai cụ thể (Proposal) và yêu cầu phản hồi, nhưng cuối cùng vẫn phải tiếp tục mà không có góp ý đáng kể

Đề xuất và kế hoạch cho bài tập

  • Kế hoạch triển khai:
    • Web app dựa trên Go
    • Triển khai qua AWS ECS Fargate và áp dụng SSL
    • Tích hợp dịch vụ gửi email Postmark
    • Bổ sung chức năng đăng nhập/xác thực
    • Gửi/nhận email và hiển thị trên UI
  • Cơ sở lựa chọn công nghệ:
    • Sử dụng nhiều công nghệ liên quan trực tiếp đến vai trò backend
    • Xây dựng hệ thống thực tế thông qua công cụ Infrastructure-as-Code
    • Không chỉ dừng ở tích hợp API đơn giản mà hướng tới tính năng gần với một dịch vụ thực tế
  • Các thành phần triển khai chính:
    • Pocketbase (backend/DB), TEMPL (template), Pulumi (IaC), Postmark (dịch vụ email)
    • Triển khai phân trang, đăng nhập, v.v.
    • Stretch Goal: độ ổn định như sao lưu và khôi phục dữ liệu
  • Kết luận: tác giả đã đưa ra giải thích và căn cứ khá đầy đủ từ trước, nên kỳ vọng sẽ nhận được sự xem xét và phản hồi rõ ràng

Phản hồi của quản lý và vấn đề giao tiếp

  • Chỉ nhận được một câu trả lời ngắn kiểu “đề xuất thú vị” mà không có xem xét cụ thể
  • Hoàn toàn không có phản hồi về mức độ phù hợp của đề xuất hay yêu cầu cải thiện
  • Từ góc nhìn của ứng viên, điều này tạo cảm giác thiếu tôn trọng với thời gian đầu tư và công sức bỏ ra

Thực hiện dự án bài tập

  • Tác giả đã triển khai toàn bộ các yêu cầu và nội dung đã đề xuất, dành trọn một tuần làm việc toàn thời gian
  • Tác giả cũng đã nộp video demo dự án, repository GitHub và cả tài liệu chi tiết

Thông báo bị loại và phản hồi sau đó

  • Sau khi nhận email từ chối tự động, tác giả yêu cầu phản hồi và nhận được câu trả lời như sau:
    • “Có bài nộp của ứng viên mạnh hơn”, “cạnh tranh tuyển dụng rất khốc liệt”
  • Vấn đề được chỉ ra
    1. Nếu ưa chuộng giải pháp đơn giản thì lẽ ra có thể nói ngay từ đầu
    2. Nếu đề xuất chưa tốt, họ cũng hoàn toàn có thể phản hồi ở thời điểm đó
    3. Ngay cả sau khi từ chối, tin tuyển dụng vẫn còn được đăng, nên tác giả cho rằng đây không chỉ là cạnh tranh đơn thuần mà còn là yêu cầu tiêu tốn thời gian quá mức
    4. Sau khi nhận bài nộp, yêu cầu còn bị nâng cao hơn nữa, khiến giải pháp đã nộp vô tình trở thành thứ làm tăng tiêu chuẩn đánh giá

Kết luận và vấn đề được đặt ra

  • Cách làm như vậy là bất hợp lý với nhiều người tìm việc, thậm chí có thể đi kèm rủi ro ảnh hưởng trực tiếp đến sinh kế
  • Nhấn mạnh sự cần thiết phải từ chối hoặc lên tiếng trước các yêu cầu bài tập không lương quá mức
  • Cho rằng vẫn có quy trình tuyển dụng tốt hơn như review code theo thời gian thực để thay thế các bài tập dạng dự án
    • Có thể đánh giá năng lực giải quyết vấn đề thực tế qua review code bất đồng bộ/đồng bộ
    • Chỉ ra khoảng cách giữa các bài toán kiểu Leetcode và yêu cầu công việc thực tế
  • Kêu gọi cải thiện văn hóa bào mòn ứng viên và đánh giá thiếu công bằng

Đề xuất cho một quy trình tuyển dụng tốt hơn

  • Đưa ra các phương án thay thế như review code theo thời gian thực để đánh giá năng lực lập trình viên một cách có ý nghĩa hơn
  • Nhấn mạnh sự cần thiết phải chuyển từ kiểu giải thuật đố vui có bấm giờ sang cách đánh giá tập trung hơn vào năng lực thực tế và khả năng giải quyết vấn đề

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-05-16
Ý kiến trên Hacker News
  • Chia sẻ ý kiến một cách thẳng thắn từ góc nhìn người tuyển dụng. Cá nhân tôi không thích bài tập take-home. Những bài như vậy làm lãng phí thời gian của tất cả mọi người. Nếu là vòng cuối cùng của tuyển dụng thì còn có thể hiểu được, nhưng dùng để sàng lọc ứng viên thì rất kém hiệu quả.
    1. Có quá nhiều câu hỏi được gửi đến. Việc dùng khả năng phán đoán để giải quyết trong sự mơ hồ vốn là một phần của bài tập. Với các điều kiện đã cho, chỉ cần đầu tư một hai ngày để làm một dự án local đơn giản là đủ.
    2. Việc viết và chia sẻ proposal là quá mức. Có vẻ ứng viên muốn thể hiện sự kỹ lưỡng, nhưng từ phía công ty điều này có thể bị xem là kém hiệu quả và tốn thời gian.
    3. Kết quả hoàn thiện thì có chạy được, nhưng đã dồn quá nhiều công sức vào hạ tầng và phần hoàn thiện cuối. Khi bị loại thì rốt cuộc trở thành lãng phí thời gian.
    4. Hình như có yêu cầu về một email client lấy cảm hứng từ terminal, nhưng tôi không thấy được định hướng đó trong sản phẩm.
      Tôi công nhận năng lực và nhiệt huyết với công việc của ứng viên. Chỉ muốn góp ý từ một góc nhìn hơi khác.
    • Tôi có cảm giác thái độ của tác giả blog hơi khó chịu. Chỉ đọc bài thôi cũng thấy đây là kiểu người khó làm việc cùng, khó tự chủ động ra quyết định và cần guideline rõ ràng. Hợp với tập đoàn lớn hơn là startup.
      "Phát triển một email client lấy cảm hứng từ terminal để alpha test với khách hàng" là một yêu cầu hợp lý với kỹ sư ở startup giai đoạn đầu. Dù có thêm thông số kỹ thuật, phần lớn vẫn phụ thuộc vào phán đoán của kỹ sư. Ứng viên này muốn sự chắc chắn quá mức.
      Việc tò mò trước xem Kagi sẽ phản hồi thế nào sau khi hoàn thành bài tập không phải là tín hiệu tốt. Đây không phải tình huống họ có thể đưa ra câu trả lời chắc chắn. Có lẽ họ đang đánh giá hàng trăm, hàng nghìn hồ sơ.
    • Tác giả đã làm việc tốt, nhưng đã thất bại ở điều kiện ngầm là "đừng cố gắng quá mức".
      Nếu không cần phải làm rõ yêu cầu, thì khác gì bảo ứng viên "đoán một số từ 1 đến 10" rồi loại những người chọn sai.
      Tôi không đồng ý với việc loại chỉ vì ứng viên đầu tư công sức cho bài tập và hoàn thiện nó tốt.
      Những bài tập mơ hồ như vậy thực chất chỉ là một cách khác để sàng lọc "cultural fit".
    • Theo tôi, cách ứng viên xác thực ý tưởng của mình khá giống với cách làm kỹ thuật ngày nay. Một đội ngũ lành mạnh sẽ mô tả bản thiết kế tính năng bằng tiếng Anh, xin phê duyệt rồi mới triển khai.
      Văn hóa "code trước, feedback sau" là trải nghiệm gây hại nhất cho sự nghiệp của tôi. Ứng viên này đã theo các thực hành phần mềm hiện đại. (Tôi là người phụ trách tuyển dụng tại một công ty có hơn 1000 kỹ sư.)
    • Từ góc nhìn nhà tuyển dụng, bài take-home tôi thấy phù hợp là loại có thể hoàn thành trong 30 phút, tiêu chí chấm điểm rõ ràng, có nhiều cách tiếp cận và phải cân nhắc trade-off.
      Trong đợt tìm việc trước, tôi cũng từng bị loại vì một bài take-home quá rộng mà không biết phần nào mới là tiêu chí đánh giá. Sau trải nghiệm đó tôi có ác cảm rất lớn với dạng bài này.
    • Tôi nghĩ lý do bị loại là vì proposal đã trở nên quá đồ sộ. Trong hướng dẫn không hề yêu cầu proposal, và nếu nộp quá chi tiết thì lại có thể bị diễn giải là "thiếu khả năng tự chủ động thúc đẩy công việc". Đến mức này thì chất lượng code cũng không còn ý nghĩa nữa.
      Tôi nghĩ phía công ty nên dừng bài tập ngay ở thời điểm đó thay vì để ứng viên tiếp tục lãng phí thời gian.
    • Thật đáng tiếc khi ngành này hiện thiếu khả năng nắm bắt yêu cầu đến mức phải dùng năng lực đọc ý nghĩ để sàng lọc lập trình viên.
    • Việc ứng viên không giữ đúng deadline cũng là vấn đề. Nếu chậm mà không giải thích lý do đặc biệt thì coi như đã bị loại. Mục tiêu của bài tập là thiết kế một lời giải phù hợp trong thời hạn.
    • Về nhận xét số 4 liên quan đến terminal, trong bản đầy đủ mà tác giả chia sẻ có phần giải thích điều đó.
    • Những cuộc tranh luận như thế này, nhìn từ kết quả rồi thì lúc nào cũng dễ nói. Dù dùng chiến lược ngược lại (không xác nhận yêu cầu, chỉ đáp ứng tối thiểu) thì cũng có thể ra đúng kết quả này. Trong tình huống như vậy sẽ luôn có người nói theo chiều ngược lại rằng "đáng lẽ phải chủ động làm rõ yêu cầu hơn".
  • Sau khi xem code và video demo, ấn tượng của tôi là đã mất khá nhiều thời gian chỉ để làm một web app hai trang trong một tuần.
    Ngay cả các chức năng email cơ bản nhất (như mở thư) cũng không có; dù ứng tuyển vị trí backend engineer nhưng thực tế lại dùng sản phẩm bên ngoài như postmark và turso; đồng thời còn thiếu các chức năng cơ bản như định dạng plain text, chế độ xem, folder.
    Có các tính năng phụ như trang quản trị, đăng nhập, nhưng lại thiếu cả cấu trúc dữ liệu tối thiểu như map header email.
    Có thể là một kỹ sư giỏi, nhưng tôi cho rằng không phù hợp với vị trí này.
    Tôi cũng thấy proposal cho bài take-home là điều quá bất thường.
    Đọc lại tin tuyển dụng ban đầu thì thấy có ghi rõ "email client tối giản lấy cảm hứng từ terminal" cùng các tham chiếu như aerc, mutt, himalaya. Đây rõ ràng là thất bại trong việc diễn giải yêu cầu.
    • Khi nghe nói "thất bại trong việc diễn giải yêu cầu", tôi muốn biết rốt cuộc đã không đáp ứng yêu cầu nào.
      Yêu cầu là một email client dạng terminal hoặc web app, có các chức năng cơ bản, và tôi nghĩ điều đó đã được đáp ứng.
      Phần lấy cảm hứng từ công cụ terminal vốn mang tính chủ quan. Nếu là vị trí backend thì tôi còn nghĩ việc quá chú ý đến UI có thể là không hiệu quả.
    • Việc ứng viên đã bỏ thời gian vào mà chỉ nhận được một email từ chối thì thật đáng buồn.
      Nếu ít nhất có feedback thì còn giúp ích cho sự phát triển, nhưng ngay cả điều đó nhiều khi cũng khó trong thực tế.
      Vì thế tôi ngày càng hoài nghi về bài tập take-home. Cả ứng viên lẫn nhà tuyển dụng đều cần tôn trọng thời gian của nhau.
    • Có câu hướng dẫn: "Email client can either be in the terminal (i.e. a TUI) or a web app".
  • Việc đánh giá bằng take-home là có ý nghĩa, nhưng nhất thiết phải có giới hạn thời gian.
    Chỉ cần 2~3 giờ là đủ để đánh giá ứng viên. Nếu có time limit thì ứng viên cũng có thể đưa ra giải pháp phù hợp trong khung đó, đồng thời mong muốn của công ty cũng sẽ rõ ràng hơn.
    Ngoài ra công ty cần nói rõ là họ chấp nhận "bất kỳ đáp án nào" hay là "mong muốn đáp án tốt nhất".
    Ý đồ của take-home có thể là vượt qua bài test, mức độ hoàn thành nhiệm vụ hay chất lượng code, nên ứng viên dễ bị bối rối.
    • Từ góc độ người làm tuyển dụng, tôi nghĩ bài tập của Kagi quá đồ sộ và thiếu tôn trọng thời gian của ứng viên.
      Thậm chí còn có nguy cơ loại nhầm những người đang bận rộn, không có nhiều thời gian.
      Công ty chúng tôi chỉ ra một bài toán ETL đơn giản và đặt giới hạn 4 giờ.
      Chúng tôi cũng thiết kế để dù không làm xong hết vẫn không sao, và ở vòng follow-up sẽ có thời gian review code cùng đặt câu hỏi.
      Năng lực thực sự có thể được đánh giá ở buổi follow-up này.
    • Ứng viên có thể đầu tư nhiều hơn rất nhiều so với thời gian thực tế được yêu cầu, nên tôi băn khoăn nhà tuyển dụng làm sao biết được điều đó.
      Khác với bài tập tại chỗ có cùng đơn vị thời gian công bằng, take-home có thể gây bất lợi do mỗi người phân bổ thời gian khác nhau.
      Thà vậy làm một buổi coding tại chỗ 1 giờ còn hơn. Ứng viên và người phỏng vấn cùng đầu tư một lượng thời gian như nhau thì mới tôn trọng giá trị thời gian của nhau.
    • Tôi nghĩ live review tốt hơn nhiều so với live coding. Nếu phải live coding, tôi cho rằng tốt hơn là để tôi làm việc một mình 45 phút trên laptop của mình rồi quay lại review từ xa.
  • Đúng là phản hồi của công ty không thân thiện và cũng không hữu ích, nhưng trong yêu cầu đã ghi rất rõ là 'lấy cảm hứng từ terminal'.
    Trong video demo chỉ thấy một web app thông thường. Họ đã nói rõ là hãy lấy cảm hứng từ các email client terminal hiện có như aerc, mutt, himalaya.
    Tôi tự hỏi liệu mình có bỏ sót điều gì không.
    • Sẽ tốt hơn nếu email từ chối giải thích rõ lý do, nhưng ngay từ đầu bài tập đã trực tiếp yêu cầu tham chiếu đến các terminal client đó.
      Vì UX đặc trưng của terminal client vẫn là lĩnh vực chưa có "đáp án đúng", nên rất có thể họ đã lấy chính điểm đó làm tiêu chí đánh giá.
    • Xét việc ứng viên thiên về ngôn ngữ Go, thì làm một CLI chưa đến 20 dòng, nên việc dồn sức vào phát triển web GUI khiến tôi thấy khó hiểu.
    • Có hướng dẫn: "Email client can either be in the terminal (i.e. a TUI) or a web app".
  • Gần đây tôi cũng có trải nghiệm tương tự trong một cuộc phỏng vấn. Tôi đã nộp một dự án bài tập rất tốt nhưng không có bất kỳ cuộc trao đổi nào về dự án mà chỉ nhận thông báo bị loại ngay.
    Tôi tin rằng nếu đã yêu cầu bài tập thì nhất định phải có một buổi follow-up.
    Tôi vốn đã dùng Kagi bản trả phí, nhưng sau chuyện này đang cân nhắc xóa tài khoản.
    Nếu họ còn không có thời gian để trò chuyện với ứng viên, thì ngay từ đầu không nên yêu cầu bài tập.
    • Bài tập take-home không chỉ đòi hỏi nhiều công sức từ ứng viên mà cả người phỏng vấn đánh giá cũng phải bỏ ra đáng kể.
      Sau khi đã review, tôi nghĩ ứng viên có quyền được nhận feedback.
      Nhưng thực tế là khi phải chọn chỉ một người giữa hàng chục ứng viên xuất sắc, thì việc trượt không đồng nghĩa với "năng lực kém".
      Về mặt pháp lý, câu trả lời chính thức cho việc 'tại sao chọn A mà loại B?' trong thực tế thường chỉ còn là soi mói lỗi.
    • Sẽ tốt hơn nếu công ty công khai tiêu chí đánh giá rõ ràng, hoặc ít nhất đưa feedback. Tôi cho rằng việc lãng phí thời gian mà không có phản hồi khi thất bại là không thể chấp nhận được.
      Nhiều công ty xử lý điểm này rất tốt.
    • Tôi nghi ngờ liệu đó có thật sự là một "giải pháp xuất sắc" không. Có vẻ họ đã hoàn toàn bỏ qua yêu cầu về một email client tối giản lấy cảm hứng từ terminal cùng các tham chiếu liên quan.
      Nếu hiểu sai yêu cầu đến mức lớn như vậy thì rất có thể cuộc trao đổi đã bị lược bỏ luôn.
  • Trường hợp này là ví dụ điển hình của việc đọc sai ý đồ ẩn trong phần mô tả bài tập.
    Công ty muốn một người có thể tự chủ và tự đặt mục tiêu cho mình.
    Sự mơ hồ nhằm xem ứng viên có thể khám phá câu trả lời theo nhiều hướng và tự tháo gỡ vấn đề hay không.
    • Bài tập đó dành cho người có thể đưa ra một lời giải càng đơn giản, khéo léo mà vẫn chạy được càng tốt.
      Vì có những người không hợp với công ty thiên về prototype như vậy, nên có ứng viên chỉ cần suy nghĩ 10 phút rồi làm ra được mức tối đa trong 60 phút.
    • Với một dự án R&D mà chỉ nhấn mạnh "tối giản", thì không rõ đó là prototype hay sản phẩm cho người dùng, có cần chú ý UX hay không, v.v. Yêu cầu mơ hồ như vậy rốt cuộc chỉ là trò đoán xem người chấm coi trọng điều gì.
    • Với những bài tập kiểu "hãy tự diễn giải", người không làm rõ yêu cầu hay không đặt thêm câu hỏi có thể bị loại.
      Nhưng với lập trình viên, khả năng đặt câu hỏi như vậy là một phẩm chất rất quan trọng. Vì thế càng kỳ vọng vào cách tuyển dụng này thì càng dễ thất vọng.
    • Tôi nghĩ "misreading the subtext" là thứ đã được viết ngay trong yêu cầu rồi.
    • Trong giáo dục, đổ lỗi rằng học sinh "không hiểu" là một kết luận quá dễ dãi.
      Vấn đề thực ra là ở phần giải thích mơ hồ.
      Một giáo viên giỏi sẽ giúp càng nhiều người hiểu càng tốt. Nếu có nhiều học sinh bối rối thì lỗi thuộc về người ra đề.
      Sinh viên đại học đâu nên phải giải công án như thiền sư.
  • Vì chính người viết bài đã đăng lên đây, tôi muốn giải thích thêm bối cảnh dựa trên kinh nghiệm từng làm ở Kagi.
    Trước đây Vlad trực tiếp đánh giá ứng viên và bài tập cũng theo kiểu này.
    Khi công ty phát triển hơn, có vẻ giờ những người khác đang đánh giá.
    Vlad có xu hướng kiểu HN và muốn làm việc với những ứng viên mà anh ấy thấy là "cool".
    Ví dụ, nếu viết dài dòng một tài liệu thiết kế rồi nói "tôi sẽ dùng Galactor và dự án đã flop-ready" thì sẽ cho hiệu ứng hoàn toàn ngược lại.
    Với yêu cầu "lấy cảm hứng từ terminal", họ có xu hướng kỳ vọng cả các chi tiết như phím tắt bàn phím và những yếu tố thực sự có ở ứng dụng terminal.
    Tiêu chí như vậy có phải là một bộ lọc tốt hay không thì còn tranh cãi, nhưng nếu hiểu bối cảnh đó và có năng lực để vượt qua, bài tập sẽ trông khá dễ.
    Tôi mong Kagi truyền đạt bối cảnh này tốt hơn. Thật đáng tiếc khi thời gian đã bị lãng phí, nhưng hy vọng bạn sẽ tìm được công ty hợp tính hơn.
    • Nhiều công ty tìm người có lối suy nghĩ giống mình.
      Một đội ngũ thiếu đa dạng có thể khiến mọi người cùng đâm đầu vào một bức tường rồi trì trệ.
      Tôi nghĩ hiện tượng này đặc biệt phổ biến ở startup, và cũng liên quan đến lý do 9/10 startup thất bại.
    • Điều khiến tôi thấy có vấn đề là Vlad đang lãng phí thời gian của quá nhiều người chỉ để tìm "người cool".
      Tôi cho rằng bài tập chấm điểm mà không có tiêu chí rõ ràng là không công bằng.
      Rốt cuộc nó chẳng khác gì một bài tập ngầm yêu cầu "hãy đoán đáp án trong đầu tôi".
      Nó tạo ấn tượng là thiếu sự quan tâm đến con người.
    • Tôi có thắc mắc rằng: "Mình thật sự phải biết trước những điều này sao?"
      Nếu là văn hóa như vậy thì chẳng lẽ ai cũng phải điều tra ngầm để biết trước hay sao.
      Sẽ tốt hơn nếu cả những ứng viên "không cool" như tôi cũng nhận được tín hiệu rõ ràng để nhanh chóng tìm công ty khác.
  • Sau khi trực tiếp review code, tôi thấy ngay từ file đầu tiên đã có các comment như thể chỉ sao chép code mẫu mà không có mục đích, mô tả không khớp và những cách diễn đạt cho thấy sự thiếu chú ý.
    Chỉ riêng những chi tiết nhỏ đó cũng đủ khiến tôi ngừng review.
    • Tôi đã deploy ứng dụng lên domain của mình và không thấy vấn đề gì về hiệu năng. Các phần mang tính backend như auth và infra cũng được làm tốt. Nhưng tôi không đồng ý với nhận xét rằng lẽ ra phải chú ý hơn đến comment trong code.
    • Vấn đề cốt lõi ở trường hợp này không phải là việc bị loại, mà là cách tuyển dụng không có guideline rõ ràng, lại còn không cung cấp cả feedback, hoàn toàn thiếu tôn trọng thời gian của ứng viên.
  • Tôi cũng từng có trải nghiệm tương tự với DuckDuckGo, nhưng ở mọi vòng ứng tuyển đều nhận được một khoản bồi dưỡng nhỏ.
    Từ proposal thiết kế đơn giản đến bài tập triển khai, mọi thứ đều được tiến hành với giới hạn thời gian rõ ràng.
    Cuối cùng tôi vẫn không đỗ và cũng không được cho biết lý do cụ thể.
    Có vẻ là vì số lượng ứng viên quá nhiều, nhưng trải nghiệm đó vẫn để lại ảnh hưởng cảm xúc rất lâu. Tôi đồng cảm với tâm trạng của OP.
  • Nói từ góc nhìn người phỏng vấn kỹ thuật: cả leetcode lẫn take-home đều tốn nhiều thời gian mà lượng thông tin lại ít.
    Nhưng nếu là người tuyển dụng, có lẽ tôi cũng sẽ loại tác giả bài viết.
    Startup cần người làm việc nhanh và thực dụng.
    Tôi từng có đồng nghiệp cũ hay đi hỏi ý kiến xung quanh rồi tự cắm đầu làm một mình suốt nhiều ngày, đến lúc xong thì yêu cầu đã đổi mất, và điều đó không tốt cho bất kỳ ai.