Mở đầu — vì sao bài này quan trọng
Nếu bạn từng ngồi vào ghế người phỏng vấn kỹ thuật lần đầu, khả năng cao bạn đã lặp lại đúng những gì người ta từng làm với mình: quăng một bài toán khó, ngồi im, và âm thầm chấm điểm xem ứng viên có "ra" đáp án tối ưu hay không. Đây là cái bẫy phổ biến nhất của coding round, và nó khiến vòng phỏng vấn kỹ thuật trở thành một trò chơi may rủi hơn là một công cụ đánh giá đáng tin.
Với vai trò tech lead, coding round là nơi bạn đưa ra một trong những quyết định tốn kém nhất của tổ chức: có nên đưa một con người vào đội hay không. Một quyết định sai — cả false positive (nhận nhầm người yếu) lẫn false negative (loại nhầm người giỏi) — đều đắt. False positive tốn hàng tháng lương, thời gian coaching, và đôi khi phải xử lý PIP về sau. False negative âm thầm hơn nhưng nguy hiểm không kém: bạn để tuột mất người mà đối thủ sẽ vui vẻ nhận.
Bài học này tập trung hẹp vào một thứ: làm sao thiết kế và vận hành một coding round có chất lượng — nghĩa là round đo đúng thứ cần đo, công bằng, và cho ra tín hiệu (signal) rõ ràng để đưa ra quyết định hire/no-hire. Chúng ta không bàn về pipeline tuyển dụng tổng thể (Bài 8), không bàn về system design (Bài 10) hay behavioral (Bài 11). Chỉ riêng coding round, và chỉ riêng chất lượng của nó.
Khái niệm cốt lõi
Mục tiêu thật sự của coding round
Mục tiêu của coding round KHÔNG phải để "bí" ứng viên hay chứng minh bạn thông minh hơn họ. Mục tiêu là quan sát cách một kỹ sư làm việc trong điều kiện gần với công việc thật nhất có thể. Cụ thể, bạn muốn thu tín hiệu về bốn năng lực:
- Cách tiếp cận vấn đề: Ứng viên có clarify (làm rõ) yêu cầu trước khi lao vào code không? Họ có hỏi về input, edge case, ràng buộc không? Người giỏi hiếm khi code ngay dòng đầu tiên — họ dừng lại để hiểu bài toán.
- Khả năng chuyển ý tưởng thành code chạy được: Không phải viết code hoàn hảo, mà là biến một hướng giải thành cấu trúc rõ ràng, chạy được, và tự kiểm tra được.
- Giao tiếp kỹ thuật: Họ có nói ra suy nghĩ (think out loud) không? Khi bạn gợi ý, họ tiếp thu hay phòng thủ? Đây là tín hiệu về việc làm cùng họ sẽ như thế nào.
- Xử lý khi bí: Ai cũng sẽ bí ở đâu đó. Điều quan trọng là họ debug ra sao, có bình tĩnh chia nhỏ vấn đề không, có biết đánh đổi (trade-off) khi hết thời gian không.
Signal vs Noise
Một khái niệm nền tảng trong phỏng vấn là phân biệt signal (tín hiệu thật về năng lực) và noise (nhiễu do hoàn cảnh). Một bài toán quá khó, quá lạ, hoặc phụ thuộc vào một "mẹo" mà bạn hoặc biết hoặc không sẽ tạo ra rất nhiều noise: bạn chấm điểm may mắn chứ không chấm năng lực. Bài toán tốt là bài mà một kỹ sư có năng lực phù hợp sẽ giải được với chất lượng khác nhau tùy trình độ — nghĩa là nó phân tầng (differentiate) được ứng viên, không phải chặn cứng.
Rubric — xương sống của một round công bằng
Rubric là bảng tiêu chí chấm điểm được định nghĩa trước. Không có rubric, mỗi interviewer chấm theo cảm tính, và feedback của họ hầu như vô dụng khi cả nhóm ngồi lại debrief. Một rubric tốt tách các trục đánh giá: Problem Solving, Coding, Communication, Testing/Verification — mỗi trục có mô tả mức độ (ví dụ: Strong / Meets / Below). Ứng viên được chấm trên từng trục, không phải một con điểm mù mờ "cảm thấy ổn".
Coding round không phải bài kiểm tra thuật toán
Đây là điểm nhiều tech lead Việt Nam hiểu sai. Bạn không tuyển người để đi thi ACM. Trừ khi công việc thật sự đòi hỏi thuật toán nặng (ví dụ đội làm search engine, hệ thống matching của Grab, hay pricing engine), một bài coding sát công việc — kiểu parse một file log, viết một rate limiter đơn giản, xử lý một cấu trúc dữ liệu quen thuộc — sẽ cho signal tốt hơn nhiều so với một bài dynamic programming hóc búa.
Tình huống thực tế
Tình huống 1 — Startup fintech ở TP.HCM và bài toán "mẹo"
Một startup fintech khoảng 40 người ở quận 1 gặp vấn đề: pass rate coding round của họ chỉ khoảng 8%, và trong sáu tháng họ chỉ tuyển được 2 backend engineer dù đã phỏng vấn hơn 60 người. Khi tech lead ngồi xem lại, anh phát hiện bài coding chuẩn của đội là một biến thể của bài "median of two sorted arrays" — một bài nổi tiếng khó, đòi hỏi một insight rất cụ thể về binary search mà nếu không biết trước thì gần như không nghĩ ra trong 40 phút.
Kết quả: đội đang lọc ra những người tình cờ đã luyện đúng bài đó trên LeetCode, chứ không phải những người viết backend tốt. Anh đổi bài sang một bài sát công việc: "cho một luồng giao dịch, viết hàm phát hiện các giao dịch trùng lặp trong cửa sổ 5 phút". Bài này có nhiều tầng: giải ngây thơ O(n²) vẫn chạy được, giải tốt dùng hash map và sliding window, và có vô số edge case thật (giao dịch cùng lúc, timezone, tiền âm). Pass rate lên 24%, và quan trọng hơn, ba người được nhận trong quý sau đều được đánh giá "trên kỳ vọng" sau 90 ngày.
Bài học: Bài toán phụ thuộc "mẹo" tạo noise cực lớn. Hãy chọn bài phân tầng được ứng viên và có liên hệ với công việc thật.
Tình huống 2 — Grab và chuẩn hóa rubric giữa các interviewer
Ở một tổ chức lớn kiểu Grab hay Shopee, vấn đề không phải bài toán mà là tính nhất quán giữa hàng chục interviewer. Giả sử hai kỹ sư cùng phỏng vấn một bài, một người là "hard grader" luôn cho "no hire" trừ khi ứng viên viết code hoàn hảo, người kia là "easy grader" gật đầu với bất kỳ ai thân thiện. Cùng một ứng viên có thể pass hay fail chỉ tùy vào việc bốc trúng ai — đây là bất công và là noise thuần túy.
Cách một đội xử lý: họ xây rubric bốn trục với mô tả hành vi cụ thể cho từng mức. Ví dụ trục Communication: mức "Strong" nghĩa là "chủ động nêu giả định, giải thích trade-off mà không cần hỏi"; mức "Below" nghĩa là "im lặng code, chỉ nói khi được hỏi trực tiếp". Sau mỗi phỏng vấn, interviewer bắt buộc nộp feedback trong 24 giờ, kèm code ứng viên viết và ví dụ cụ thể cho từng đánh giá. Trong debrief, họ phát hiện độ lệch giữa các grader giảm rõ rệt vì mọi người đang tranh luận trên bằng chứng ("ở phút 20 ứng viên tự phát hiện bug off-by-one") thay vì cảm giác ("mình thấy bạn này ổn ổn").
Bài học: Rubric chi tiết cộng feedback dựa trên bằng chứng biến phỏng vấn từ trò cảm tính thành quy trình có thể tin cậy được.
Tình huống 3 — Interviewer "phá" ứng viên và cái giá phải trả
Một công ty product ở Hà Nội có một senior engineer nổi tiếng "khó". Anh xem phỏng vấn như đấu trí, thường xuyên ngắt lời, chê bai lựa chọn của ứng viên ngay giữa chừng, và cố tình không cho hint để "xem ứng viên tự bơi". Về mặt số liệu, các round của anh có pass rate 5%, thấp nhất công ty. Ban đầu quản lý tưởng anh là "người giữ chuẩn". Nhưng khi họ khảo sát trải nghiệm ứng viên (candidate experience), điểm của anh thấp thảm hại, và họ phát hiện nhiều ứng viên giỏi đã rút lui khỏi quy trình sau round của anh, kể cả một số người sau đó gia nhập đối thủ.
Đội làm một thử nghiệm: cho anh phỏng vấn cặp (shadow) cùng một interviewer giàu kinh nghiệm, người sẵn sàng đưa hint đúng lúc và giữ không khí hợp tác. Cùng nhóm ứng viên đó khi được phỏng vấn theo phong cách hợp tác lại thể hiện tốt hơn hẳn, và một vài người trước đó bị đánh giá "no hire" hóa ra rất mạnh khi được unblock đúng chỗ. Hóa ra anh không đo năng lực — anh đo khả năng chịu đựng áp lực từ chính anh.
Bài học: Interviewer là một phần của phép đo. Một interviewer đối kháng tạo ra false negative hàng loạt và làm hỏng thương hiệu tuyển dụng. Phỏng vấn giỏi là hợp tác, không phải trấn áp.
Hướng dẫn từng bước
Dưới đây là quy trình thiết kế và vận hành một coding round chất lượng, từ chuẩn bị đến sau phỏng vấn.
Bước 1 — Xác định năng lực cần đo trước khi chọn bài. Ngồi lại với đội và trả lời: vị trí này thực sự cần gì? Backend nặng về data modeling? Frontend nặng về xử lý state? Đừng chọn bài trước rồi mới hợp lý hóa. Viết ra 3-4 năng lực ưu tiên, đó là kim chỉ nam cho mọi thứ sau này.
Bước 2 — Chọn bài toán có nhiều tầng và calibrate nội bộ. Chọn một bài mà ứng viên yếu vẫn giải được phần cơ bản, còn ứng viên mạnh sẽ đi xa hơn (tối ưu, edge case, testing). Trước khi dùng thật, cho 2-3 kỹ sư trong đội tự giải bài đó có bấm giờ. Nếu chính người của bạn không giải xong trong thời gian dự kiến, bài quá khó.
Bước 3 — Chuẩn bị kịch bản hint theo tầng. Viết sẵn: nếu ứng viên bí ở đây thì gợi ý gì. Hint có tầng giúp bạn unblock mà không "cho không" đáp án, và giúp mọi interviewer đối xử công bằng như nhau. Một ứng viên cần hint vẫn có thể được đánh giá cao nếu sau hint họ triển khai xuất sắc.
Bước 4 — Mở đầu bằng việc tạo tâm lý an toàn. Dành 2-3 phút giới thiệu bạn là ai, format round ra sao, và nói rõ: "Cứ nghĩ ra tiếng, cứ hỏi, không sao cả khi chưa hoàn hảo." Một ứng viên căng thẳng sẽ cho signal sai. Nhiệm vụ của bạn là gỡ căng thẳng, không phải tạo thêm.
Bước 5 — Quan sát quá trình, không chỉ kết quả. Khi ứng viên code, chú ý: họ có clarify trước không? Có tự chạy thử ví dụ không? Có tự phát hiện bug không? Ghi chép cụ thể theo thời gian ("phút 15: tự nhận ra thiếu edge case rỗng"). Những ghi chú này là vàng khi debrief.
Bước 6 — Chấm theo rubric ngay sau round, dựa trên bằng chứng. Nộp feedback trong 24 giờ khi trí nhớ còn tươi. Với mỗi trục, viết đánh giá kèm ví dụ cụ thể từ phiên phỏng vấn. Tránh viết "cảm thấy ổn"; hãy viết "giải quyết vấn đề tốt: tự đề xuất dùng hash map và giải thích được vì sao O(n)".
Bước 7 — Debrief dựa trên dữ liệu, không dựa trên chức danh. Trong buổi debrief, mỗi interviewer trình bày bằng chứng. Người senior nhất KHÔNG nên nói trước để tránh anchoring (mọi người bị neo theo ý kiến của họ). Quyết định hire dựa trên tín hiệu tổng hợp, không dựa trên ai nói to nhất.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng bài quá khó hoặc phụ thuộc mẹo. Đây là lỗi số một, đã thấy ở tình huống fintech. Bạn tưởng mình đang giữ chuẩn cao, thực ra bạn đang tuyển người luyện LeetCode chăm chỉ. Mẹo: hỏi bản thân "một senior giỏi trong đội mình có chắc giải được bài này trong 40 phút mà không cần biết trước không?" Nếu không chắc, đổi bài.
Lỗi 2 — Chấm nhị phân "đúng/sai đáp án tối ưu". Nhiều interviewer chỉ quan tâm ứng viên có ra được lời giải tối ưu hay không. Điều này bỏ qua toàn bộ tín hiệu về quá trình. Mẹo: một ứng viên đưa ra giải pháp O(n²) nhưng phân tích được trade-off, tự nhận biết nó chưa tối ưu và biết hướng cải thiện thường mạnh hơn người bốc trúng lời giải tối ưu mà không hiểu vì sao.
Lỗi 3 — Không cho hint, để ứng viên "tự bơi". Như tình huống ở Hà Nội, điều này tạo false negative. Mẹo: coi hint là một phần thiết kế. Điều bạn đo là ứng viên tận dụng hint tốt đến đâu, không phải họ có cần hint hay không.
Lỗi 4 — Đánh giá theo "culture fit" mơ hồ. Nói "bạn này không hợp" mà không có bằng chứng thường là ngụy trang cho thiên kiến (bias). Mẹo: mọi đánh giá phải gắn với hành vi quan sát được trong round, không gắn với việc ứng viên có giống bạn hay không.
Lỗi 5 — Quên rằng ứng viên cũng đang phỏng vấn bạn. Đặc biệt với người giỏi trong thị trường cạnh tranh như Việt Nam hiện nay, trải nghiệm phỏng vấn tệ khiến họ rút lui. Mẹo: dành 5 phút cuối cho ứng viên hỏi, và trả lời thật lòng. Đây vừa là phép lịch sự vừa là công cụ bán (sell) vị trí.
Mẹo chung — chuẩn hóa môi trường. Cho ứng viên chọn ngôn ngữ họ thoải mái nhất, dùng công cụ collaborative editor quen thuộc, và cho phép tra cứu cú pháp cơ bản như khi làm việc thật. Bạn không đo trí nhớ cú pháp, bạn đo tư duy giải quyết vấn đề.
Bài tập thực hành
- Thiết kế một bài coding có ba tầng. Chọn một bài toán sát công việc đội bạn (ví dụ: xử lý log, dedup dữ liệu, một cache đơn giản). Viết ra rõ ràng: đâu là lời giải mức "cơ bản chấp nhận được", mức "tốt", và mức "xuất sắc". Nếu không tách được ba tầng, bài của bạn chưa phân tầng được ứng viên.
- Viết rubric bốn trục. Cho bài ở trên, viết mô tả hành vi cụ thể cho từng mức (Strong / Meets / Below) trên bốn trục: Problem Solving, Coding, Communication, Verification. Đưa cho một đồng nghiệp đọc và hỏi họ có chấm ra kết quả giống bạn với cùng một tình huống giả định không.
- Soạn kịch bản hint theo tầng. Liệt kê 3 điểm ứng viên hay bị bí trong bài của bạn, và với mỗi điểm viết một hint "nhẹ" và một hint "rõ hơn". Mục tiêu: giúp mọi interviewer unblock công bằng như nhau.
- Tự audit round gần nhất của bạn. Nhìn lại ba ứng viên bạn phỏng vấn gần đây. Với mỗi người, bạn có thể chỉ ra bằng chứng cụ thể cho đánh giá của mình không? Nếu chỉ nhớ được "cảm giác", đó là dấu hiệu bạn đang chấm bằng noise.
Tóm tắt
Coding round chất lượng không phải là round khó nhất, mà là round đo đúng thứ cần đo và cho tín hiệu đáng tin để quyết định tuyển dụng. Bốn điều cốt lõi cần nhớ: (1) Mục tiêu là quan sát cách tiếp cận, khả năng viết code chạy được, giao tiếp, và xử lý khi bí — không phải để "bí" ứng viên. (2) Chọn bài phân tầng, sát công việc, tránh bài phụ thuộc "mẹo" vì chúng tạo noise. (3) Chuẩn hóa bằng rubric chi tiết, hint theo tầng, và feedback dựa trên bằng chứng để giảm sự bất công giữa các interviewer. (4) Interviewer là một phần của phép đo — hợp tác và tạo tâm lý an toàn cho ra signal tốt hơn nhiều so với đối kháng, đồng thời bảo vệ thương hiệu tuyển dụng của bạn. Một round tốt vừa giúp bạn không nhận nhầm, không bỏ sót, vừa khiến người giỏi muốn về với đội bạn.