Làm sao để vượt qua phỏng vấn HackerRank?

Điểm số mà nhà tuyển dụng nhìn thấy không chỉ là đạt hay không đạt. Một bài đánh giá HackerRank báo cáo nhiều thứ cùng lúc, và biết cái nào thay đổi độc lập sẽ thay đổi cách bạn phân bổ thời gian.

• Số test case đã vượt qua. Mỗi bài toán chạy trên các test case mẫu có thể nhìn thấy và một bộ test case ẩn lớn hơn. Chính trong bộ ẩn đó tồn tại các đầu vào rỗng, phần tử đơn lẻ, trùng lặp và kích thước tối đa. Phần lớn điểm bị mất là do các trường hợp biên, không phải do thuật toán sai.
• Điểm một phần. Việc chấm điểm thường tính theo từng test case, vì vậy một giải pháp đúng nhưng chậm vẫn ghi được điểm thật. Một giải pháp hoàn hảo nhưng không được nộp thì không được điểm nào.
• Giới hạn thời gian và bộ nhớ. Ở những nơi bài toán đặt ra các giới hạn này, một giải pháp kém hiệu quả sẽ bị timeout ở các test case ẩn lớn dù vượt qua mọi test case mẫu.
• Báo cáo giám sát. Việc chuyển tab, mất focus, sự kiện dán, và ảnh chụp webcam ở nơi được bật, đều được đính kèm vào bài nộp của bạn để nhà tuyển dụng đọc.

Những gì các nền tảng tuyển dụng khác kiểm tra, theo từng giai đoạn, được tổng hợp tại trung tâm nền tảng tuyển dụng.

Bạn đã biết thuật toán rồi mà vẫn mất điểm lần trước, điều này khiến cảm giác như việc luyện tập đã lãng phí. Phần này đề cập đến khía cạnh thuộc về môi trường chứ không phải kỹ năng. Phần lớn số điểm có thể lấy lại nằm ở đây, và chi phí để lấy lại chúng rất thấp.

• Luyện tập trong trình soạn thảo của HackerRank. Đó không phải là IDE của bạn. Không có tính năng tự động hoàn thành mà bạn quen dựa vào, không có trình gỡ lỗi, và các phím tắt của bạn cũng biến mất. Hãy giải trọn vẹn vài bài toán trong đó trước khi bước vào thực chiến.
• Học cách đọc phần khung đầu vào. Một số bài toán trao cho bạn chữ ký hàm đã được phân tích sẵn, số khác buộc bạn tự đọc từ đầu vào chuẩn. Đọc sai phần khung là một cách phổ biến khiến bạn thất bại ở mọi test case dù logic hoàn toàn đúng.
• Chọn ngôn ngữ mà bạn gỡ lỗi nhanh nhất, chứ không phải ngôn ngữ trông ấn tượng nhất. Thước đo là vượt qua các bài test.
• Viết giải pháp brute force trước, nộp nó, rồi mới tối ưu. Chốt điểm một phần trước khi hết giờ là thói quen có giá trị cao nhất.
• Kiểm tra các trường hợp biên bằng tay: đầu vào rỗng, một phần tử, tất cả giống nhau, kích thước tối đa.

Hãy hình dung một kỹ sư backend đang chuẩn bị cho một buổi sàng lọc của đội ngũ nền tảng. Anh đã từng giải các bài toán nền tảng đó trước đây, nhưng lại dành phần đầu của bài test để vật lộn với phần khung phân tích đầu vào và chỉ nộp được một giải pháp thay vì ba. Kiến thức thuật toán của anh hoàn toàn không phải là điểm nghẽn.

CodePair là một trình soạn thảo được chia sẻ với một con người trong cuộc gọi, điều này biến nó thành một cuộc trò chuyện có kèm theo sản phẩm mã nguồn hơn là một bài test. Việc chấm điểm là đánh giá của con người, và sự im lặng gây ấn tượng xấu.

• Diễn giải lại bài toán và xác nhận các ràng buộc trước khi viết bất cứ điều gì.
• Nói hướng tiếp cận thành tiếng trước, bao gồm cả hướng bạn đã loại bỏ và lý do tại sao. Người phỏng vấn chấm điểm quá trình suy luận, và một hướng tiếp cận bị loại bỏ chính là bằng chứng cho điều đó.
• Vừa gõ vừa nói. Những khoảng im lặng kéo dài là lời phàn nàn phổ biến nhất mà người phỏng vấn nêu ra về vòng này.
• Thuật lại các test case của bạn. Chủ động đi qua một trường hợp biên mà không cần được nhắc nhở thể hiện sự cẩn trọng tương tự như điều mà các test ẩn đo lường trong vòng bất đồng bộ.
• Hỏi trước khi tối ưu hóa. Thường thì người phỏng vấn muốn phiên bản hoạt động được cùng một cuộc thảo luận về độ phức tạp, chứ không phải phiên bản tối ưu.

Luyện tập cách thuật lại đó thành tiếng chính là mục đích của chế độ phỏng vấn thử, vì thất bại ở đây mang tính lời nói chứ không phải thuật toán.

Thẳng thắn về điều này quan trọng hơn câu trả lời mang tính tiếp thị.

• Một bài đánh giá HackerRank có giám sát nằm ngoài phạm vi. Hệ thống giám sát ghi lại việc chuyển tab, mất focus, sự kiện dán, và khung hình webcam. Chia sẻ màn hình, ghi màn hình, môi trường có giám sát, và máy tính do công ty quản lý là những trường hợp mà không trợ lý nào phù hợp, và SubcueAI không tuyên bố ngược lại.
• Chuẩn bị là nơi nó phù hợp. Chạy các vòng mô phỏng trước, thành tiếng, xây dựng thói quen thuật lại mà vòng CodePair đánh giá.
• Các cuộc trò chuyện về hành vi và thiết kế hệ thống xung quanh vòng lập trình là những cuộc phỏng vấn bình thường trên phần mềm họp thông thường, và đó chính là bối cảnh mà SubcueAI được xây dựng để phục vụ.

Những gì nền tảng có thể và không thể thấy được trình bày chi tiết hơn tại trung tâm khả năng bị phát hiện.