Mục lục
Có một bình luận mình đọc được, đại ý thế này:
"Mấy bài LeetCode/giải thuật lúc phỏng vấn ấy, có khi chỉ là thử thách ma mới thôi. Chứ vào làm thực tế, mấy ai ngồi mài não giải đệ quy tối ưu đâu, toàn dùng thư viện có sẵn không à?"
Và mình muốn nói thẳng: người này đúng. Chính vì họ đúng nên kết luận của họ mới nguy hiểm.
Đây không phải kiểu "đúng một nửa" cho vui. Đây là loại nửa-đúng dẫn thẳng tới những website tải chậm, sập khi có khách thật, và ngốn tiền hosting gấp mấy chục lần cần thiết. Để mình chỉ ra cái bẫy nằm ở đâu.
Phần đúng: không, không ai ngồi viết lại quicksort
Bắt đầu bằng sự thành thật, vì mình từng nghĩ y hệt.
Nhiều năm trước mình cũng coi mấy bài đảo cây nhị phân, giải đệ quy tối ưu là trò diễn. Đi làm thực tế, bạn import một thư viện, gọi hàm sort có sẵn, dùng ORM để truy vấn database. Bạn không code lại thuật toán sắp xếp, không tự tay dựng cây đỏ-đen. Điều đó đúng 100% với đại đa số công việc web, app, CRUD hằng ngày.
Và còn hơn thế: bản thân cái nghi lễ LeetCode-phỏng-vấn cũng thật sự có vấn đề. Đây là chỗ mình đứng về phía người bình luận.
Nghiên cứu của interviewing.io trên khoảng 700 ứng viên cho thấy rating LeetCode và điểm thi contest gần như không tương quan gì với hiệu suất phỏng vấn thật. Số bài đã giải chỉ tương quan 0.27 — yếu. Nói cách khác, cày điểm contest chẳng chứng minh bạn là kỹ sư giỏi.
Kinh điển hơn: Max Howell, tác giả Homebrew — phần mềm mà theo chính lời anh, "90% kỹ sư của Google đang dùng" — bị Google từ chối vì không đảo được cây nhị phân trên bảng. Dòng tweet của anh trở thành bằng chứng số một trong cả một làn sóng phản đối kiểu phỏng vấn whiteboard.
Và có một nghiên cứu ít người biết mà mình thấy đắt giá nhất: Behroozi và cộng sự tại NC State cho 48 ứng viên giải cùng một bài. Nhóm bị người phỏng vấn ngồi nhìn thất bại 61.5%, trong khi nhóm giải riêng tư chỉ thất bại 36.3%. Tức là cái bảng trắng phần lớn đang đo mức độ chịu áp lực khi bị soi, chứ không phải năng lực kỹ thuật.
Nếu bài viết dừng ở đây, mình đã đồng ý hoàn toàn với người bình luận. Nhưng đây mới là chỗ họ trượt.
Cái bẫy: họ nhầm giữa bài toán được test và năng lực được test
Người bình luận rút ra kết luận: vì công việc chỉ xài thư viện, nên tư duy giải thuật là vô dụng.
Đây là một cú đánh tráo. Phỏng vấn thuật toán — khi làm đúng — không kỳ vọng bạn viết đệ quy tối ưu ở chỗ làm. Nó dùng bài toán làm proxy để đo ba thứ:
- Phân rã vấn đề — chia một bài lớn mơ hồ thành các bước nhỏ giải được.
- Hiểu độ phức tạp và đánh đổi — biết cái này nhanh, cái kia tốn bộ nhớ, và tại sao.
- Debug dưới áp lực và diễn giải được suy nghĩ của mình.
Chú ý cái số 2. Đây chính là mắt xích mà "chỉ cần xài thư viện" chặt đứt sai chỗ.
"Xài thư viện có sẵn" không loại bỏ nhu cầu tư duy giải thuật. Nó chỉ dời nhu cầu đó sang một chỗ khác — chỗ đắt tiền hơn nhiều nếu bạn không nhìn thấy.
Chính vì bạn không tự viết thuật toán, bạn càng phải biết:
- Nên dùng cấu trúc dữ liệu nào — một
Sethay một mảng? Sai lựa chọn này biến một vòng kiểm tra từ O(n) thành O(n²). - Tại sao trang danh sách sản phẩm của bạn nhanh lúc test nhưng chậm rề khi lên production?
- Tại sao thiếu một cái index database làm câu truy vấn chậm gấp trăm lần?
Bạn không viết thuật toán. Bạn chọn và debug thuật toán mà người khác viết. Và để chọn đúng, bạn cần đúng thứ tư duy mà bài LeetCode đang cố đo — chỉ là đo vụng về.
Người biết viết thuật toán và người chỉ biết ghép thư viện trông giống hệt nhau — cho tới khi có 5.000 bản ghi thật và lượng truy cập thật. Lúc đó khoảng cách giữa họ là tiền của bạn.
"Bug ẩn danh" đắt nhất mà mình từng gặp: N+1 query
Cho bạn một ví dụ cực kỳ đời thường, không cần biết code cũng hiểu.
Có một lỗi kinh điển tên là N+1 query. Nó xảy ra khi code của bạn chạy một câu truy vấn để lấy danh sách (ví dụ 20 sản phẩm), rồi lại chạy thêm một câu riêng cho từng sản phẩm để lấy dữ liệu liên quan. 20 sản phẩm thành 21 câu truy vấn. 5.000 sản phẩm thành 5.001 câu.
Cái độc của nó, như tài liệu kỹ thuật mô tả, là: trên máy dev với 5 bản ghi, nó chạy êm ru, không ai thấy gì. Lên production với 5.000 bản ghi, nó biến một trang tải 100ms thành 10 giây — và trên hạ tầng cloud tính tiền theo mili-giây CPU, nó có thể khiến hóa đơn hosting đắt gấp 50 lần.
Ai gây ra lỗi này? Thường là người "chỉ biết xài ORM có sẵn" mà không hiểu mỗi lần gọi hàm đó thực ra bắn ra bao nhiêu câu truy vấn. Thư viện có sẵn hết. Nhưng không có tư duy độ phức tạp, thư viện trở thành khẩu súng tự bắn vào chân.
Con số về hậu quả không hề trừu tượng. Một phân tích chi phí sự cố production cho thấy chỉ 22 phút suy giảm hệ thống thanh toán ở một công ty doanh thu 15 triệu USD/tháng đã ngốn hết 25.592 USD. Loại bug này gần như luôn bắt nguồn từ việc ai đó không nhìn thấy chi phí ẩn sau một dòng code trông vô hại.
Và với chủ website, đây không phải chuyện của riêng dev
Bạn không code? Không sao. Đây là lý do bạn vẫn nên quan tâm.
Cái "10 giây" ở trên không phải chi tiết kỹ thuật — nó là doanh thu bị bốc hơi. Số liệu 2025 rất rõ ràng:
- 53% người dùng di động bỏ đi nếu trang tải quá 3 giây (nguồn).
- Tỷ lệ chuyển đổi giảm trung bình ~4.42% cho mỗi giây tải thêm trong khoảng 0–5 giây.
- Trang tải trong 1 giây có tỷ lệ chuyển đổi gấp 3 lần trang tải 5 giây.
Đọc lại vụ N+1: một quyết định "xài thư viện mà không hiểu độ phức tạp" biến 100ms thành 10 giây. Ghép với số liệu trên, bạn thấy nó nghĩa là gì cho túi tiền chưa? Website của bạn có thể chạy hoàn hảo lúc demo và chảy máu doanh thu khi có khách thật. Sự khác biệt nằm ở tư duy của người dựng ra nó — thứ vô hình cho tới lúc quá muộn.
Đây chính là công việc mà đội tối ưu SEO & hiệu suất của bọn mình làm mỗi ngày: không phải viết lại thuật toán, mà là nhìn ra chỗ nào tư duy độ phức tạp đã bị bỏ qua và sửa nó.
Nghịch lý: AI khiến tư duy này quan trọng hơn, không phải ít đi
Đây là phần phản trực giác nhất, và là lý do cả cuộc tranh luận này đang bị đảo ngược.
Lập luận phổ biến: "AI viết code hộ rồi, thư viện có sẵn hết rồi, thời nay ai còn cần hiểu giải thuật." Nghe rất hợp lý. Nó sai.
Khảo sát Stack Overflow 2025 trên hơn 49.000 lập trình viên cho thấy:
- 84% đã hoặc đang dùng công cụ AI — tăng từ 76% năm trước.
- Nhưng 46% không tin vào độ chính xác của output AI — tăng vọt từ 31% năm 2024.
- Và đây là con số quan trọng nhất: 66% nói họ tốn nhiều thời gian hơn để sửa loại code AI "gần đúng mà chưa đúng".
Bạn thấy chuyện gì đang xảy ra chưa? AI đã làm hộ phần dễ — phần ghép thư viện, viết code mẫu. Cái phần mà người bình luận nghĩ là "toàn bộ công việc" thì máy làm được rồi.
Cái còn lại cho con người là phần khó nhất và đắt nhất: phán đoán xem đoạn code "gần đúng" kia sẽ gãy ở đâu, chậm ở đâu, nổ bộ nhớ ở đâu khi lên production. Và phán đoán đó chính là tư duy độ phức tạp — thứ mà bài LeetCode, dù vụng về, đang cố đo.
Nói cách khác: AI càng giỏi ghép thư viện, giá trị của người hiểu khi nào thư viện gãy càng cao. Người chỉ biết copy code AI mà không thẩm định được nó chính là người sắp tạo ra một quả bom N+1 hẹn giờ.
Vậy làm gì với điều này? Một khung nhìn thực dụng
Bỏ qua chuyện cày 500 bài LeetCode — nghiên cứu ở trên cho thấy khoảng 500 bài là điểm dừng tối ưu, và cày hơn nữa gần như vô ích. Cái đáng đầu tư là tư duy, không phải số bài.
Nếu bạn là người thuê một đội làm web (không code): đừng hỏi "bạn biết những framework nào". Ai cũng liệt kê được. Hãy hỏi những câu lộ ra tư duy độ phức tạp:
- "Khi dữ liệu tăng từ 100 lên 100.000 bản ghi, trang nào của tôi sẽ chậm trước, và các bạn xử lý thế nào?"
- "Các bạn kiểm tra hiệu suất trên dữ liệu thật hay chỉ trên dữ liệu demo?"
- "Nếu dùng AI để viết code, các bạn thẩm định nó ra sao trước khi đưa lên production?"
Người "chỉ biết ghép" sẽ ậm ừ. Người có tư duy sẽ trả lời được ngay, bằng ví dụ cụ thể.
Nếu bạn là dev: đừng cày thuật toán để khoe. Hãy học đủ để đọc được chi phí ẩn của một dòng code. Hiểu Big-O đủ để biết vòng lặp lồng nào sẽ nổ. Biết vì sao truy vấn của mình chậm. Đó là 20% kiến thức giải thuật tạo ra 80% giá trị thực tế — và nó không nằm ở việc đảo cây nhị phân trên bảng.
Chốt lại
Người bình luận đúng ở chỗ: hiếm khi bạn tự tay viết thuật toán, và nghi lễ LeetCode-phỏng-vấn thì thật sự bị lạm dụng. Nếu chỉ dừng ở đó, mình gật đầu.
Nhưng kết luận "nên vô dụng, chỉ để hành ma mới" thì sai — và sai theo kiểu tốn tiền. Kỹ năng được test (nhìn ra độ phức tạp, chọn đúng công cụ, biết khi nào nó gãy) vẫn chuyển giao được ngay cả khi bài toán cụ thể thì không. Nó chỉ dời từ "viết thuật toán" sang "chọn và thẩm định thuật toán" — và trong thời đại AI viết code hộ, đó lại là kỹ năng đắt giá nhất còn lại cho con người.
Một website nhanh, mở rộng được và không đốt tiền hosting không đến từ việc biết nhiều thư viện. Nó đến từ việc hiểu cái giá ẩn sau mỗi dòng code — dù dòng đó do bạn, do thư viện, hay do AI viết ra.
Nếu website của bạn đang chạy chậm dần khi lớn lên, hoặc bạn nghi ngờ nó chứa vài quả bom hẹn giờ kiểu N+1, nói chuyện với bọn mình. Đó đúng là loại "độ phức tạp ẩn" mà bọn mình đi tìm.
Nguồn:
- How well do LeetCode ratings predict interview performance? — interviewing.io
- Does Stress Impact Technical Interview Performance? — Behroozi et al., NC State (FSE 2020)
- Max Howell / Homebrew — tweet gốc
- What is the N+1 Query Problem — PlanetScale
- How to Calculate the Real Cost of a Production Incident — Medium
- Website Load Time Statistics 2025 — Envisage Digital
- Stack Overflow Developer Survey — AI
