Tại sao phỏng vấn kỹ thuật đang hỏng và cách sửa chúng

📖 Cấp độ: Master ⏱️ Thời gian đọc: ~12 phút 📰 Chủ đề: Tech Hiring / Programming

📰 Bài đọc (English)

There is a growing consensus among software engineers that the technical interview process, as currently practiced by much of the industry, is fundamentally broken. The assertion is not new — engineers have been complaining about whiteboard coding challenges for over a decade — but what has changed is the volume and caliber of voices calling for reform, and the emergence of credible alternatives.

The standard technical interview at most major technology companies follows a remarkably homogeneous pattern: candidates are presented with algorithmic puzzles — often involving data structures such as balanced trees, graphs, or dynamic programming — and asked to produce optimal solutions within thirty to forty-five minutes, typically while an interviewer observes. The format ostensibly measures problem-solving ability and coding fluency. In practice, it primarily measures one’s proficiency at a very specific genre of competitive programming that bears little resemblance to the daily work of building and maintaining software systems.

The empirical evidence against the current system is damning . A widely cited 2020 study from Microsoft Research found that performance on algorithmic interview questions had no statistically significant correlation with on-the-job performance. Separate research demonstrated that the same candidate, interviewed twice at the same company, could receive dramatically different outcomes — a level of variance that would be considered unacceptable in virtually any other evaluative context.

The system’s failures are not merely epistemological — they are deeply structural. Algorithmic interviews disproportionately disadvantage experienced engineers who have spent years building production systems but have not recently drilled LeetCode problems. They favor candidates with the leisure time and resources to engage in months of dedicated preparation — a prerequisite that correlates more strongly with socioeconomic privilege than with engineering talent. Had the industry designed a system specifically to perpetuate homogeneity in its workforce, it could scarcely have done better.

Several companies have begun pioneering alternative approaches. Take-home projects allow candidates to demonstrate their abilities in a more realistic setting, working with actual codebases over a period of days rather than minutes. Pair programming sessions, in which candidates collaborate with an interviewer on a real or representative problem, offer insight into how a person actually works — their communication style, their approach to ambiguity , their willingness to seek help.

Were the industry to adopt work-sample tests as the primary evaluation method, the improvement in predictive validity would be substantial. Industrial-organizational psychology has long established that the best predictor of future job performance is past performance on analogous tasks. A system design discussion reveals far more about a senior engineer’s capabilities than a binary tree traversal exercise ever could.

Not only must the evaluation methods change, but the entire rubric by which candidates are assessed needs overhauling . Current systems optimize for false-negative avoidance at the company level — it is considered acceptable to reject ten qualified candidates if doing so prevents one underperformer from being hired. This calculus made sense when top companies received far more qualified applicants than they could hire. In today’s fiercely competitive talent market, the cost of rejecting strong candidates has grown prohibitively high.

The path forward requires not just better tools but a fundamental shift in mindset : from interviews as gatekeeping rituals to interviews as collaborative explorations of mutual fit.

📚 Từ vựng chính

🇻🇳 Bản dịch tiếng Việt

Ngày càng có sự đồng thuận trong giới kỹ sư phần mềm rằng quy trình phỏng vấn kỹ thuật, như cách phần lớn ngành đang thực hiện, về cơ bản đã hỏng. Nhận định này không mới — các kỹ sư đã phàn nàn về thử thách code trên bảng trắng hơn một thập kỷ — nhưng điều đã thay đổi là số lượng và trình độ của những tiếng nói kêu gọi cải cách, cùng sự xuất hiện của các giải pháp thay thế đáng tin cậy.

Cuộc phỏng vấn kỹ thuật tiêu chuẩn tại hầu hết các công ty công nghệ lớn tuân theo một khuôn mẫu đồng nhất đáng kinh ngạc: ứng viên được đưa cho các bài toán thuật toán — thường liên quan đến cấu trúc dữ liệu như cây cân bằng, đồ thị, hoặc quy hoạch động — và được yêu cầu đưa ra lời giải tối ưu trong ba mươi đến bốn mươi lăm phút, thường trong khi người phỏng vấn quan sát. Định dạng này bề ngoài đo lường khả năng giải quyết vấn đề và sự lưu loát trong code. Trên thực tế, nó chủ yếu đo lường sự thành thạo ở một thể loại rất cụ thể của lập trình thi đấu, vốn ít giống với công việc hàng ngày của việc xây dựng và bảo trì hệ thống phần mềm.

Bằng chứng thực nghiệm chống lại hệ thống hiện tại rất nghiêm trọng. Một nghiên cứu năm 2020 được trích dẫn rộng rãi từ Microsoft Research cho thấy hiệu suất trên các câu hỏi phỏng vấn thuật toán không có tương quan có ý nghĩa thống kê với hiệu suất công việc thực tế. Nghiên cứu riêng biệt cho thấy cùng một ứng viên, phỏng vấn hai lần tại cùng công ty, có thể nhận kết quả khác biệt đáng kể — mức độ biến thiên sẽ bị coi là không thể chấp nhận trong hầu như bất kỳ bối cảnh đánh giá nào khác.

Những thất bại của hệ thống không chỉ thuộc về nhận thức luận — chúng mang tính cấu trúc sâu sắc. Phỏng vấn thuật toán gây bất lợi không tương xứng cho các kỹ sư có kinh nghiệm, những người đã dành nhiều năm xây dựng hệ thống production nhưng gần đây không luyện các bài LeetCode. Chúng thiên vị ứng viên có thời gian rảnh và nguồn lực để tham gia hàng tháng chuẩn bị chuyên dụng — một điều kiện tiên quyết tương quan mạnh hơn với đặc quyền kinh tế xã hội so với tài năng kỹ thuật. Nếu ngành công nghiệp thiết kế một hệ thống đặc biệt để duy trì sự đồng nhất trong lực lượng lao động, khó có thể làm tốt hơn thế.

Một số công ty đã bắt đầu tiên phong các phương pháp thay thế. Dự án mang về nhà cho phép ứng viên thể hiện khả năng trong bối cảnh thực tế hơn. Các buổi lập trình đôi, trong đó ứng viên cộng tác với người phỏng vấn trên một vấn đề thực tế hoặc mang tính đại diện, cho cái nhìn sâu sắc về cách một người thực sự làm việc.

Nếu ngành áp dụng bài kiểm tra mẫu công việc làm phương pháp đánh giá chính, sự cải thiện về tính dự đoán sẽ rất đáng kể. Tâm lý học tổ chức công nghiệp từ lâu đã xác lập rằng yếu tố dự đoán tốt nhất cho hiệu suất công việc tương lai là hiệu suất quá khứ trên các nhiệm vụ tương tự.

Không chỉ phương pháp đánh giá cần thay đổi, mà toàn bộ bảng tiêu chí đánh giá ứng viên cũng cần được đại tu. Hệ thống hiện tại tối ưu hóa việc tránh false-negative ở cấp công ty — việc từ chối mười ứng viên đủ năng lực được coi là chấp nhận được nếu ngăn được một người kém hiệu suất được tuyển. Con đường phía trước đòi hỏi không chỉ công cụ tốt hơn mà còn sự chuyển đổi căn bản trong tư duy: từ phỏng vấn như nghi thức gác cổng sang phỏng vấn như khám phá hợp tác về sự phù hợp lẫn nhau.

📝 Phân tích ngữ pháp

Câu 1: “Had the industry designed a system specifically to perpetuate homogeneity in its workforce, it could scarcely have done better.”

• Cấu trúc: Had + S + past participle…, S + could scarcely have + past participle
• Ngữ pháp: Câu điều kiện loại 3 đảo ngữ — diễn tả sự mỉa mai: kết quả thực tế tệ đến mức như thể cố tình
• Ví dụ tương tự: “Had the team tried to create the worst possible UX, they could scarcely have done better.”

Câu 2: “Were the industry to adopt work-sample tests as the primary evaluation method, the improvement in predictive validity would be substantial.”

• Cấu trúc: Were + S + to-infinitive…, S + would be + complement
• Ngữ pháp: Câu điều kiện loại 2 đảo ngữ (subjunctive) — gợi ý thay đổi nên thực hiện
• Ví dụ tương tự: “Were companies to measure actual coding productivity, the hiring landscape would transform.”

Câu 3: “Not only must the evaluation methods change, but the entire rubric… needs overhauling.”

• Cấu trúc: Not only + must + S + V…, but + S + V
• Ngữ pháp: Đảo ngữ nhấn mạnh với Not only…but — hai thay đổi song song, ý sau mở rộng phạm vi
• Ví dụ tương tự: “Not only must the code be refactored, but the entire architecture needs redesigning.”

Câu 4: “A level of variance that would be considered unacceptable in virtually any other evaluative context.”

• Cấu trúc: Noun phrase + that + would be + past participle + prepositional phrase
• Ngữ pháp: Mệnh đề quan hệ với “would” (conditional relative clause) — so sánh tiêu chuẩn giữa hai lĩnh vực
• Ví dụ tương tự: “A failure rate that would trigger an immediate recall in any other industry.”

Câu 5: “The format ostensibly measures problem-solving ability and coding fluency. In practice, it primarily measures one’s proficiency at a very specific genre of competitive programming.”

• Cấu trúc: S + adverb + V + O. In practice, S + adverb + V + O
• Ngữ pháp: Cấu trúc đối lập “ostensibly…in practice” — phơi bày khoảng cách giữa mục đích tuyên bố và thực tế
• Ví dụ tương tự: “The metric ostensibly tracks user satisfaction. In practice, it primarily reflects response time.”

✏️ Bài tập

Comprehension (Đọc hiểu)

1. What did the Microsoft Research study reveal about algorithmic interview questions?
2. How do algorithmic interviews create structural disadvantages for experienced engineers?
3. What alternative interview approaches does the article suggest?

Vocabulary (Từ vựng)

Điền từ thích hợp:

1. The two systems are ___ in their architecture, despite being built by different teams.
2. There is growing ___ that remote work is here to stay.
3. The study found no ___ correlation between test scores and actual performance.
4. Current hiring practices ___ existing biases rather than eliminating them.
5. A depth-first ___ of the graph revealed all connected components.