Trải nghiệm của một lập trình viên bị loại ở vòng phỏng vấn dạng bài tập của Kagi Search
(bloggeroo.dev)- Trong quy trình tuyển dụng backend của Kagi Search, một lập trình viên đã dành khoảng một tuần làm toàn thời gian để triển khai một email client mang cảm giác terminal, nhưng sau khi nộp đã bị loại mà không có phỏng vấn tiếp theo
- Bài tập để mở nhiều lựa chọn như TUI hoặc web app, các chức năng cơ bản xem/gửi email, backend giả lập hoặc chọn IMAP/POP/JMAP, nên ứng viên phải tự đánh giá phạm vi triển khai và tiêu chí chấm
- Ứng viên đã gửi trước một kế hoạch chi tiết gồm Go web app, AWS ECS Fargate, SSL, Postmark, đăng nhập, Pulumi, Pocketbase, TEMPL, v.v., nhưng phía Kagi không cho biết tiêu chí cụ thể để đạt yêu cầu
- Phản hồi sau khi bị loại chỉ là có “những bài nộp đơn giản hơn và mạnh hơn”, đồng thời được thông báo rằng ở giai đoạn này họ thường không cung cấp phản hồi riêng
- Trải nghiệm này cho thấy phỏng vấn dạng bài tập không trả phí và các câu đố lập trình giới hạn thời gian có thể kiểm tra thời gian và hoàn cảnh sống của ứng viên nhiều hơn năng lực kỹ thuật thực tế
Ứng tuyển và nhận bài tập
- Ứng viên đã gửi CV cho vai trò backend tại Kagi Search, và phần tóm tắt vai trò bao gồm các năng lực sau
- Kinh nghiệm xây dựng hệ thống backend
- Thành thạo Go
- Hiểu biết về mở rộng và bảo trì hệ thống backend
- Khả năng cộng tác với SRE và thành viên trong nhóm
- Hiểu biết về công nghệ container hóa như Docker
- Sau đó, ứng viên nhận email từ Kagi yêu cầu hoàn thành Kagi Developer Assessment cho bước tiếp theo
- URL bài tập được gửi qua HackMD
- Nội dung email cho biết sau khi hoàn thành và liên hệ lại, họ sẽ xem xét; nếu đạt, ở vòng phỏng vấn tiếp theo sẽ thảo luận về cách tiếp cận và giải pháp
Yêu cầu bài tập và tiêu chí đánh giá mở
- Mục tiêu của bài tập là tạo một “email client tối thiểu mang cảm giác terminal”
- Điều kiện triển khai được để mở khá rộng
- Email client có thể triển khai dưới dạng terminal TUI hoặc web app
- Cần có chức năng cơ bản để xem và gửi email
- Có thể dùng backend giả lập (DB, in-memory, v.v.) hoặc backend thực tế IMAP/POP/JMAP
- Không cần xử lý rich text message, chỉ cần xử lý văn bản thuần
- Họ thông báo rằng đối tượng đánh giá không chỉ là năng lực lập trình, mà còn bao gồm khả năng xử lý sự mơ hồ và các vấn đề mở cần thiết cho các dự án R&D như Kagi Labs
- Điều kiện của sản phẩm bàn giao như sau
- Triển khai theo cách thể hiện năng lực của một lập trình viên
- Đưa dự án hoàn chỉnh lên repository GitHub và deploy ở đâu đó để có thể kiểm thử dễ dàng
- Viết cách thiết lập trong README
Trao đổi với nhân sự tuyển dụng
- Ứng viên cho rằng yêu cầu quá rộng nên đã gửi câu hỏi cho người phụ trách tuyển dụng
- Người phụ trách trả lời rằng có nhiều ứng viên; một số chỉ triển khai phần cơ bản, còn một số cung cấp thêm tính năng, tài liệu xuất sắc, giải thích quyết định, bản demo đã deploy và cả kế hoạch tương lai
- Khi được hỏi tính năng bổ sung nào được đánh giá cao, người phụ trách trả lời rằng “bản thân điều đó cũng là một phần của đánh giá” và họ muốn xem ứng viên nghĩ ra các tính năng bổ sung nào
- Ứng viên quyết định viết chi tiết kế hoạch triển khai cho toàn bộ sản phẩm bàn giao và gửi đi trước khi thực sự viết code
- Ứng viên kỳ vọng nếu đề xuất được chấp nhận, điều đó có thể đưa mình đến gần hơn với phỏng vấn qua điện thoại hoặc lời mời làm việc
- Sau khi nhìn kết quả, ứng viên kết luận rằng nỗ lực cố gắng đáp ứng điều kiện từ trước không có nhiều ý nghĩa với người phụ trách tuyển dụng
Phần triển khai mà ứng viên đề xuất
- Trọng tâm của đề xuất là email client dựa trên Go web app
- Deploy lên AWS
- Sử dụng ECS Fargate
- Áp dụng SSL/HTTPS
- Tích hợp với nhà cung cấp dịch vụ gửi email
- Xác thực qua màn hình đăng nhập
- Gửi email dựa trên form
- Hiển thị email nhận được trong UI
- Trong đề xuất, hạn nộp được đặt là EOD Chủ nhật ngày 30 tháng 3, và ghi rằng đây là lịch muộn hơn hai ngày làm việc so với mốc hai tuần kể từ email đầu tiên
- Các lựa chọn công nghệ như sau
- Backend Go: dùng Pocketbase và TEMPL
- Infrastructure as Code: dùng Pulumi, chọn TypeScript SDK
- Nhà cung cấp dịch vụ email: dùng Postmark
- UI: phân trang email gửi/nhận, màn hình đăng nhập, cung cấp 2 tài khoản dùng cho demo
- Lý do lựa chọn thiên về việc thể hiện phạm vi năng lực rộng phù hợp với vai trò và phạm vi đánh giá
- Dù là vai trò backend, việc thêm frontend web có thể thể hiện bề rộng công nghệ web
- Database có liên quan đến vai trò backend
- AWS và deploy bằng Infrastructure as Code liên quan đến thảo luận về IaC, Docker, networking và khả năng phục hồi
- Dịch vụ email như Postmark giúp giảm độ phức tạp của tích hợp IMAP/POP trong khi vẫn giữ chức năng
- Ứng viên hỏi “nếu hoàn thành thì có thể kỳ vọng phản ứng nào từ Kagi”, nhưng câu trả lời chỉ dừng ở mức “rất thú vị và mong chờ bài nộp”
Bài nộp và việc bị loại
- Ứng viên đã triển khai toàn bộ nội dung đã đề xuất và cho biết tổng công việc mất một tuần làm toàn thời gian
- Demo web application được đăng lên YouTube, còn code được công khai trên GitHub cùng tài liệu
- Sau khi nhận email loại tự động và yêu cầu phản hồi, phía Kagi trả lời như sau
- Ở giai đoạn này, họ thường không cung cấp phản hồi
- Có những bài nộp đơn giản hơn và mạnh hơn, nên họ quyết định tiếp tục với các ứng viên đó
- Mỗi vị trí nhận được nhiều sự quan tâm và hồ sơ ứng tuyển, nên quá trình lựa chọn rất cạnh tranh
- Họ đề nghị tiếp tục theo dõi các vị trí trong tương lai và ứng tuyển lại
Những câu hỏi còn lại sau khi bị loại
- Ứng viên cho rằng nếu họ muốn một “giải pháp đơn giản hơn” thì lẽ ra đã có thể nói khi ứng viên gửi đề xuất vào ngày 18 tháng 3
- Nếu giải pháp không phù hợp với vai trò, ứng viên cũng cho rằng có thể đánh giá điều đó ngay ở giai đoạn đề xuất ngày 18 tháng 3
- Ứng viên viết rằng tính đến ngày 13 tháng 5, một tháng rưỡi sau khi bị loại, tin tuyển dụng vẫn còn được đăng
- Ứng viên thừa nhận rằng công ty có thể tuyển nhiều vai trò bằng cùng một tin tuyển dụng
- Tuy nhiên, ứng viên cho rằng khó có thể xem đó là một “cuộc cạnh tranh mà vị trí chiến thắng đã có người lấp đầy”
- Trong hướng dẫn bài tập ban đầu, việc có demo đã deploy là điều tốt nhưng không bắt buộc; ứng viên viết rằng sau khi nộp, hướng dẫn đã được đổi thành yêu cầu deploy nghiêm ngặt
Đề xuất về cách tuyển chọn tốt hơn
- Ứng viên chỉ trích rằng bài tập không trả phí là gánh nặng lớn với người tìm việc, đặc biệt là những người đang thất nghiệp và khoản tiết kiệm đang giảm dần
- Ứng viên cũng có quan điểm tiêu cực về phỏng vấn kiểu LeetCode
- Trong một vai trò gần đây dựa trên Clojure, ứng viên đã giải bài “coin change”; trong 50 phút đã vượt qua khoảng một nửa test, nhưng không đủ thời gian để triển khai phần backtracking
- Ứng viên đề xuất review code trực tiếp như một phương án thay thế
- Có thể thực hiện theo cả hình thức bất đồng bộ hoặc đồng bộ
- Có thể trao đổi bằng lời về các vấn đề và chủ đề của một dự án phần mềm thực tế
- Có thể bộc lộ tốt hơn kiến thức của một software engineer giàu kinh nghiệm
- Ứng viên không hoàn toàn phản đối live coding, nhưng cho rằng khả năng giải knapsack trong 50 phút cách xa công việc kỹ thuật hằng ngày
- Ứng viên khuyên rằng nếu không ở trong tình thế tuyệt vọng, hãy từ chối những vai trò yêu cầu loại công việc không trả phí như vậy
1 bình luận
Các ý kiến trên Hacker News
Nhìn từ góc độ nhà tuyển dụng, tôi không thích vòng tuyển dụng dạng bài tập vì những lý do này. Nó lãng phí thời gian của tất cả mọi người; có thể ổn ở bước cuối ngay trước khi tuyển, nhưng không phù hợp để dùng làm bộ lọc
Dù vậy, năng lực và sự nghiêm túc rõ ràng là có; tôi chỉ thử đóng vai người phản biện từ một góc nhìn khác
Yêu cầu “hãy làm một email client phong cách terminal để có thể alpha test với 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, và các chi tiết chắc chắn phải để kỹ sư tự xử lý
Đặc biệt, yêu cầu “tôi muốn biết nếu làm đến khi hoàn chỉnh thì có thể kỳ vọng phản hồi gì từ Kagi” là không hay. Trong tình huống phải xem hàng trăm đến hàng nghìn bài nộp, không có cách nào đưa ra câu trả lời chắc chắn
Nếu việc cố làm rõ yêu cầu là hành vi không được mong muốn, thì khác gì bảo người ta chọn một số từ 1 đến 10 rồi loại những ai chọn sai
Bài kiểm tra dạng bài tập là để thể hiện năng lực, nhưng nếu không có hướng dẫn cụ thể thì làm sao đoán được nên thể hiện đến mức nào
Việc hoàn thiện chỉ xấu khi nó cản trở việc bàn giao; còn loại vì “trau chuốt quá” thì giống như loại ai đó vì họ làm việc quá tốt
Kiểu bài kiểm tra mơ hồ như vậy rốt cuộc trông giống một cách khác để loại người với lý do không phải phù hợp văn hóa
Những môi trường “làm trước, review sau” là những nơi độc hại nhất trong sự nghiệp của tôi; thật tệ nếu bỏ ra vài ngày xây một tính năng rồi mới biết đó không phải thứ họ muốn
Vì vậy, cách mô tả tính năng bằng văn bản và xin phê duyệt gần như là chuẩn ngành khi ra mắt dự án, và ứng viên này đã làm theo một thực hành phần mềm mà các tổ chức lành mạnh tuân thủ
Với tư cách quản lý tuyển dụng ở một công ty có hơn 1.000 kỹ sư, tôi cũng nhìn nhận như vậy
Tất nhiên, chỉ nên giao cho những ứng viên mà kết quả bài tập có thể là một phần quyết định việc đỗ hay trượt
Lần tìm việc gần nhất, tôi nhận một bài tập rất rộng kiểu này, dù đó là công việc mà tôi thừa năng lực, và bị loại vì không thể đoán được phần nào sẽ được chấm
Có lẽ sau này tôi khó có khả năng kiếm việc bằng cách không qua giới thiệu, nhưng tôi cũng trở nên rất ngại cả việc nhận lẫn giao những bài tập như vậy
Bài tập này nhằm xem khả năng đặt vài câu hỏi, ghi lại giả định, rồi tự tin lao vào xây dựng một thứ còn mơ hồ
Có lẽ sau email đó thì code đã không còn quan trọng nữa, và công ty lẽ ra nên dừng lại ở thời điểm đó để ứng viên không lãng phí thời gian triển khai bài tập
Khi xem code và video demo, suy nghĩ đầu tiên của tôi là “mất một tuần để làm một web app hai trang, mà còn thiếu cả những chức năng email cơ bản nhất như mở tin nhắn”
Nhìn yêu cầu thì người này ứng tuyển vị trí “Email Backend Engineer”, nhưng phần backend email thực tế lại dùng các sản phẩm bên thứ ba như Postmark và Turso
Thiếu các yếu tố cơ bản như định dạng email dạng văn bản thuần, xem email, thư mục, tối thiểu là hộp thư đến và thư đã gửi; trong khi lại có các chức năng tùy chọn như màn hình đăng nhập, trang admin và backend framework
Trong database backend thậm chí không có map header email
Có thể là một kỹ sư giỏi, nhưng có vẻ không phù hợp với vị trí cụ thể này; nếu là tôi thì cũng từ chối
Xem tin tuyển dụng gốc thì tiêu đề là “The project is to build a minimal, terminal-inspired email client”, và có nêu rõ hãy lấy cảm hứng từ các công cụ email terminal hiện có như aerc, mutt, himalaya
Đây là mức không đọc đúng yêu cầu, nên trông như không thể tuyển
Có vẻ cả hai đều đã được đáp ứng đủ
Việc lấy cảm hứng từ công cụ hiện có là chủ quan, và tôi không nghĩ dành thời gian cho giao diện người dùng trong bài tập cho vị trí backend là cách tốt nhất để thể hiện năng lực
Tôi hiểu rằng nếu nhà tuyển dụng phải xem xét hàng trăm người cho một vị trí được quan tâm thì điều đó không phải lúc nào cũng thực tế, nhưng chính vì vậy mà vòng tuyển dụng dạng bài tập không hay
Ứng viên có thể lãng phí vài giờ cuộc đời mà không thu được gì, nên cả hai bên cần tôn trọng thời gian của nhau
Tôi hiểu rằng phản hồi rất ngắn và không hữu ích, nhưng yêu cầu đã nói rõ là phải làm một ứng dụng email client lấy cảm hứng từ terminal
Nhìn vào video được chia sẻ https://www.youtube.com/watch?v=yY1sVXMkP_o thì nó trông giống một ứng dụng email web bình thường, không có điểm gì đặc biệt lấy cảm hứng từ terminal
Nếu họ muốn một trong hai, TUI thật sự hoặc web app, thì nhiều khả năng web app cũng phải mang phong cách terminal
Trong phần “Inspiration” của toàn bộ yêu cầu có ghi rõ là “hãy lấy cảm hứng từ các công cụ email terminal hiện có như aerc, mutt, himalaya”
Dù vậy, prompt đã nêu rõ các terminal client khác làm nguồn cảm hứng
Ngoài ra, yêu cầu về terminal client làm thay đổi đáng kể đối tượng đánh giá. UI email trên web là lĩnh vực đã được biết đến từ lâu, nhưng trải nghiệm người dùng của terminal client vẫn chưa phải là lĩnh vực đã được “giải quyết” hoàn toàn
Rất có thể trong bảng đánh giá, các quyết định thiết kế terminal client mà bài nộp của ứng viên hoàn toàn không đề cập chiếm tỷ trọng lớn
Đánh giá bằng bài tập có thể có giá trị trong quy trình phỏng vấn, nhưng nhất thiết phải có giới hạn thời gian. 2–3 giờ là đủ để thu được thông tin cần thiết; nhiều hơn thế gần như chỉ lọc ra những người mới vào nghề không có người phụ thuộc, sở thích hay trách nhiệm
Nếu giới hạn 3 giờ, trường hợp tệ nhất ứng viên chỉ mất 3 giờ, còn khả năng cao hơn là họ sẽ đưa ra một đề xuất hoặc lời giải hoàn toàn khác phù hợp với khoảng thời gian đó
Ứng viên cũng cần xác nhận xem họ “muốn câu trả lời nào cũng được, hay muốn câu trả lời tốt”
Có bài tập chỉ xem có vượt qua bộ test hay không và không quan tâm cách làm, nhưng có bài lại ưu tiên code tốt hơn dù chỉ đáp ứng 80% yêu cầu. Tôi đã thấy ứng viên phán đoán sai ở cả hai phía
Những bài như vậy có thể lọc ra những người có thể lãng phí nhiều thời gian cho dự án, còn những người bận rộn — tức những người có thể là đối tượng họ muốn — thì lại bỏ qua
Khi tuyển năng lực data engineering, tôi giao một bài ETL đơn giản. Lấy dữ liệu ra từ file ZIP, biến đổi rồi đưa vào một cơ sở dữ liệu bất kỳ
Tôi để lại vài điểm mơ hồ, và trong dataset thì cài các yếu tố ẩn như giá trị null ngoài dự kiến hoặc CSV sai định dạng để xem năng lực thực hiện
Giới hạn 4 giờ, nhưng tôi chưa đưa hướng dẫn khi thiếu thời gian; đó là một gợi ý hay
Trong cuộc gọi sau đó, chúng tôi cùng xem code và hỏi các câu như “nếu dataset không vừa trong bộ nhớ thì sao?” để hỏi hướng cải thiện, và chính điểm đó trở thành phần đánh giá kỹ thuật thực sự
Vì không có bảo đảm mọi ứng viên đều dùng cùng một lượng thời gian, chuyện này trở thành vấn đề game theory, và ứng viên nhìn chung sẽ thiệt theo cách nào đó
Trong nhiều trường hợp, đáp án đúng là bỏ thêm thời gian để tạo ra một lời giải rất trau chuốt, nhưng không quá trau chuốt, rồi giả vờ đã tuân thủ giới hạn thời gian
3 giờ cũng là khoảng thời gian rất dài với một ứng viên còn chưa biết liệu mình có được nói chuyện với người tiếp theo hay không
Trong một buổi phỏng vấn 1 giờ, có thể cho làm bài lập trình và bảo đảm ứng viên không phải lãng phí thêm thời gian
Nếu ứng viên muốn, cũng có thể cho họ gửi bản cải thiện sau đó; thường ở thời điểm ấy tôi đã đánh giá tốt năng lực của họ và có thể nói “nếu muốn thì làm, nhưng bạn đã qua rồi”
Giữ mức đầu tư thời gian của ứng viên và người phỏng vấn ngang nhau giúp tôi tôn trọng thời gian của ứng viên như cách tôi tôn trọng thời gian của mình
Nếu quản lý tuyển dụng không tôn trọng thời gian của ứng viên, có vẻ khả năng họ tôn trọng thời gian của nhân viên cũng thấp
Gần đây tôi phỏng vấn ở nhiều nơi và trải nghiệm rất giống chuyện này. Tôi đưa ra một lời giải xuất sắc cho bài tập, nhưng bị từ chối mà không có thảo luận nào về kết quả
Từ kinh nghiệm nhiều lần vận hành vòng take-home với tư cách nhà tuyển dụng, tôi tin rằng nếu đã yêu cầu ai đó làm bài ở nhà thì nhất định phải trao đổi về code
Nếu nhận bài take-home, tôi thực sự khuyên nên hỏi chắc có buổi trao đổi tiếp theo hay không bất kể kết quả đánh giá, và nếu họ không đồng ý thì đừng làm “bài tập về nhà”
Thành thật mà nói, trình độ của nhiều đội tuyển dụng khá thấp, nên việc triển khai một lời giải tốt đôi khi lại thành điểm trừ. Bạn có thể bị loại vì một lý do bực bội là đội tuyển dụng không đủ trình độ để đánh giá mức đó
Tôi là người dùng Kagi từ thời đầu, nhưng vì chuyện này mà đang cân nhắc hủy tài khoản. Nếu không có thời gian nói chuyện với ứng viên thì ngay từ đầu đừng bắt họ làm việc
Take-home đòi hỏi nỗ lực đáng kể không chỉ từ ứng viên mà cả người vận hành và đội tuyển dụng; nếu đã review dự án thì kỳ vọng có phản hồi hoặc trả lời khi được yêu cầu là hợp lý
Tuy nhiên cũng có thực tế. Nếu mỗi vị trí có 20 ứng viên xuất sắc, nhiều người có năng lực vẫn sẽ bị từ chối. Điều đó không có nghĩa là họ thiếu năng lực hay đã “thất bại”
Nếu về mặt pháp lý phải giải thích vì sao chọn A mà không chọn B, rất khó nói “cả hai đều xuất sắc nhưng chúng tôi chọn một người”, và cuối cùng dễ trượt sang kiểu bới ra cả những khuyết điểm không tồn tại
Trong văn hóa doanh nghiệp Mỹ, tôi thường thấy cách như vậy, và Kagi có trụ sở tại Palo Alto
Trượt bài tập thì không sao, nhưng lãng phí thời gian của ai đó mà không trả lại gì là điều khó chấp nhận
Có nhiều công ty xử lý việc này tốt, kể cả các startup nổi tiếng
Kết quả không giống “email client tối thiểu mang phong cách terminal” cho lắm, và có vẻ cũng hoàn toàn bỏ qua các công cụ được nêu làm nguồn cảm hứng
Nếu đã hiểu sai yêu cầu lớn đến mức này thì là tôi, tôi cũng sẽ không dành thời gian để thảo luận
Đây là một trường hợp điển hình của việc đọc sai bối cảnh ngầm. Công ty muốn một người có thể độc lập tự tạo ra công việc và mục tiêu của mình.
Sự mơ hồ của bài tập không phải để ứng viên gửi nhiều email hỏi vặn, mà là một tấm canvas trống để nhận một đề bài khá rộng, tự khám phá không gian vấn đề và cho thấy cách tạo ra kết quả.
Nó rất giống cảnh làm việc ở đại học, khi một sinh viên không hiểu bài tập nhận điểm ngoài dự đoán rồi phàn nàn.
Trong bối cảnh phỏng vấn, khi ai cũng muốn gây ấn tượng, không nhiều người dám hành xử “lười biếng”.
Với một công ty có cách tiếp cận tập trung vào ra mắt thử nghiệm nhanh và prototype, một số người thật sự không phù hợp, và điều đó không tốt cho tất cả.
Có lẽ sẽ có ứng viên dành 10 phút nghĩ xem trong 60 phút có thể làm gì, rồi tận dụng HTTP authentication và form để chạy một backend Go nhỏ, sau đó gửi kèm một email ngắn. Người như vậy có khả năng đã trông tốt hơn nhiều trong quá trình này.
Không thể biết đây là prototype làm xong rồi bỏ, hay thứ người dùng thật sẽ nhìn thấy, liệu trải nghiệm người dùng chưa hoàn chỉnh có bị chỉ trích không, hay họ chỉ muốn xem một thứ gì đó.
Cuối cùng nó trở thành bài luyện đoán gu của người review.
Ngược lại, cũng sẽ có người bị loại vì đã không tiếp tục thúc đẩy để làm rõ yêu cầu, mà đó lại là một phẩm chất quan trọng của kỹ sư.
Cuộc sống không công bằng, nhưng tôi kỳ vọng nhiều hơn ở hiring manager, và vì thế cứ tiếp tục thất vọng.
Cũng có thể sinh viên không biết đọc ý nghĩ người khác và hiểu nhầm vì đề bài được viết quá tệ.
Giáo viên giỏi là người giúp càng nhiều sinh viên hiểu càng tốt, còn giáo viên tồi thì ngược lại.
Dưới những giáo viên tốt nhất, tiêu chí chấm điểm đã minh bạch ngay từ đầu nên không cần nghi ngờ điểm số.
Nếu có nhiều sinh viên bối rối, mẫu số chung có thể là giáo viên.
Việc các nhà sư Phật giáo học bằng cách giải những câu đố công án khó hiểu không có nghĩa là cũng nên áp dụng cách đó với sinh viên đại học đang đóng học phí.
Có vẻ chính tác giả đã đăng bài, nên tôi sẽ giải thích bối cảnh của phản ứng họ nhận được. Tôi từng làm ở Kagi và đã trải qua một bài test dạng take-home tương tự.
Khi đó công ty còn rất nhỏ, Vlad trực tiếp xem xét ứng viên và dùng những dự án dạng bài tập như thế này. Bây giờ công ty đã lớn hơn nên có thể ông ấy không còn trực tiếp xem nữa, nhưng cốt lõi có vẻ vẫn tương tự.
Nếu nói chuyện với Vlad, bạn sẽ thấy ông ấy gần như là hình mẫu điển hình của một người bình luận trên Hacker News, và phỏng vấn gần giống một buổi kiểm tra cảm giác xem “người này có vẻ ổn không”.
Với ông ấy, viết một tài liệu thiết kế dài kiểu “sẽ dùng Galactor, làm cho florp-ready, rồi fleem” là trái ngược hoàn toàn với sự ngầu.
Nếu bài tập là “email client phong cách terminal”, thì một dự án gần như đạt điểm tuyệt đối có lẽ là thứ có phím tắt bàn phím cho mọi chức năng, và được mô tả trong một đoạn văn rằng việc vẽ một frame không vượt quá 2ms.
Có khả năng người phỏng vấn thấy ứng viên có lối suy nghĩ quá kiểu enterprise để làm việc ở Kagi.
Tất nhiên chuyện cách tuyển chọn này có tốt hay không là vấn đề khác. Vlad muốn người suy nghĩ giống mình, và kiểu phỏng vấn này có nhiều vấn đề đã được bàn luận và nghiên cứu từ lâu.
Tuy vậy, nếu hiểu điều đó và có đủ dư địa để chịu được quá trình như vậy, thì bài tập thật ra cũng có lý. Kagi lẽ ra có thể truyền đạt điểm này tốt hơn.
Thật tiếc là bạn đã bị lãng phí nhiều thời gian, nhưng hy vọng bạn tìm được nơi phù hợp hơn với cách làm việc của mình.
Để mang lại góc nhìn mới cho vấn đề, cần có sự đa dạng trong tư duy. Nếu mọi người đều nghĩ theo cùng một cách, khi một người bế tắc thì khả năng cao tất cả cũng bế tắc.
Đây có vẻ là vấn đề phổ biến ở startup, và cũng có thể là tín hiệu cho thấy vì sao 9 trên 10 startup thất bại.
Điều đó khác với việc kiểm tra năng lực. Ở đây, bạn phải đạt điểm cao trên một thước đo không được nói cho biết thì mới qua.
Nó không khác mấy với việc giao bài “cứ code gì đó đi, vì phải biết xử lý sự mơ hồ”, nhưng thật ra là bắt đoán đúng thứ tôi đang nghĩ trong đầu.
Đây là một cách rất thiếu quan tâm đến người khác, và cũng không gửi tín hiệu tốt về con người Vlad.
Chẳng lẽ để biết điều đó tôi phải lục mạng xã hội của người trong công ty?
Nếu cuối cùng tôi đã bộc lộ đủ rõ rằng mình không ngầu mà họ vẫn bảo “tiếp tục đi” chỉ để thỏa mãn sự tò mò, thì tôi mong họ cũng được đối xử đúng theo cách họ đối xử với người khác.
Cảm ơn vì đã giải thích, và tôi không có ác cảm. Chỉ là giá mà tôi đã thấy một bài như thế này sớm hơn.
Từ nay, có lẽ nên xếp các công việc có “take-home” vào nhóm việc dành cho đám trẻ ngầu. Khi đó, những kỹ sư nhàm chán nhưng giàu kinh nghiệm có thể gây áp lực để công ty thay đổi cách làm nếu họ thật sự muốn lao động của chúng tôi.
Nếu công ty không thay đổi, ta có thể suy luận kiểu công ty “cung cấp” vai trò đó là nơi như thế nào.
Tôi đã xem qua code để thử nghĩ nếu là reviewer thì sẽ nhìn thế nào.
Tôi có lẽ đã dừng lại ở đây trong file đầu tiên mở ra: https://github.com/Sleepful/mymail/blob/main/app/router/page...
Comment đầu tiên rất lạ vì không liên quan đến công việc, và trông như được sao chép từ ví dụ blog. Dù thế nào, việc để nguyên nó lại là thiếu cẩn thận.
Cách diễn đạt ở dòng thứ hai không nhất quán với dòng thứ ba.
Tôi có lẽ đã dừng review ở đây. Đó là thiếu chú ý đến chi tiết, và không cho thấy khả năng suy nghĩ rõ ràng.
Nhưng thứ nhận lại là một email từ chối trống rỗng.
Trong hoàn cảnh đó, tôi khó đồng ý với ý kiến rằng lẽ ra tôi nên dành thêm thời gian cho comment trong code.
Tôi muốn nói với tư cách một người phỏng vấn kỹ thuật. Tôi không thích LeetCode, cũng không thích bài tập mang về. Cả hai đều tốn nhiều thời gian mà thông tin thu được lại ít
Dù vậy, trong trường hợp này nhiều khả năng tôi cũng sẽ từ chối tác giả. Kagi Search là một startup, và những nơi như vậy thường tìm những người lạc quan thực dụng có thể di chuyển nhanh, đồng thời cân bằng được chiều sâu và chiều rộng
Trước đây tôi từng có một đồng nghiệp gom các đầu vào rồi tự nhốt mình vài ngày để tạo ra giải pháp, đến lúc quay lại thì yêu cầu đã thay đổi trong thời gian đó. Đó không phải là trải nghiệm vui vẻ với bất kỳ ai
Tôi thật sự ghét dạng tuyển dụng giao bài tập
Câu “Dự án này không chỉ kiểm tra khả năng lập trình mà còn kiểm tra khả năng xử lý sự mơ hồ và các vấn đề mở” nghe như thực ra có nghĩa là a) bài tập được thiết kế quá tệ nên họ còn không lập bảng tiêu chí đánh giá, hoặc b) môi trường làm việc hỗn loạn đến mức không có đặc tả hay yêu cầu nào được định nghĩa rõ ràng
Hơn nữa, các chỉ dẫn “hãy phô diễn kỹ thuật” và “hãy đưa ra một giải pháp thực dụng, có chức năng” mâu thuẫn với nhau. Một giải pháp đơn giản tốt thì không hào nhoáng
Việc có thể tạo HTTP request và làm một màn hình chỉnh sửa CRUD cơ bản gần như chẳng nói lên điều gì. Các công cụ AI cũng có thể tạo những thứ này rất nhanh với chất lượng khá ổn
Điều tôi muốn thấy là kỹ sư triển khai logic nghiệp vụ khó chịu như thế nào
Tôi muốn xem nó sẽ thành một triệu câu if lồng nhau kèm chú thích “có rồng ở đây”, hay họ tìm được pattern phù hợp để tạo ra mã có thể đọc và suy luận được
Điều này có giá trị hơn nhiều trong công việc thực tế, tín hiệu phỏng vấn cũng mạnh hơn, AI cũng khó làm đúng hơn, và tốn ít thời gian hơn
Việc tạo ra một giải pháp đơn giản tốt cũng có thể chính là cách thể hiện năng lực
Tôi xem đó là một phần lớn của vai trò kỹ sư phần mềm senior
Hình thức này có thể không phải cách tốt nhất để kiểm tra điều đó, nhưng “muốn xem bạn có xử lý được sự mơ hồ không” không có nghĩa là mọi việc đều mơ hồ
Nó có thể có nghĩa là mọi việc đều phải đi qua quá trình từ “yêu cầu mơ hồ” đến “đặc tả rõ ràng”