Grokking is back!

Grokking đã trở lại - cùng bàn chuyện tech, chuyện đời, và chuyện hiểu sâu hơn

Oct 16, 2025

Chào bạn,

Grokking Newsletter đã trở lại, sau một khoảng thời gian tạm lắng để suy ngẫm và tìm kiếm định hướng nội dung mới. Trong các số newsletter sắp tới của Grokking, bạn sẽ thấy cấu trúc nội dung thay đổi nhiều. Nội dung của newsletter sẽ không phân mục quá rõ ràng hoặc chỉ có bài viết hay như trước đây, mà sẽ mang tính chất chia sẻ góc nhìn, thảo luận nhiều hơn.

Chúng tôi mong đây không chỉ là newsletter, mà là một cuộc trò chuyện - nơi bạn tìm thấy cảm hứng và những góc nhìn riêng cho hành trình của mình. Các bạn có nhu cầu thảo luận, hoặc muốn đóng góp ý kiến của mình đến bạn đọc Grokking Newsletter, có thể gửi nội dung đến cho bọn mình nhé.

Bàn chuyện System Design thời AI: Khi “biết tuốt” không bằng “hiểu sâu”

Dạo này lướt mạng, thấy các bạn khoe xài Copilot, ChatGPT generate code phà phà, thậm chí còn hỏi nó “design cho tao một cái hệ thống giống Twitter”. Nó trả lời vanh vách, nhìn có vẻ ngon lành. Nhưng đây chính là cái bẫy nguy hiểm nhất.

Theo quan sát của bọn mình, AI đang dần thay thế các task entry-level. Một bạn junior giờ có thể dùng AI để fix bug, viết unit test, hay viết một đoạn code CRUD đơn giản nhanh gấp mấy lần trước đây. Nhưng việc “design một hệ thống” lại là chuyện hoàn toàn khác.

Cái hệ thống mà AI “vẽ” ra cho bạn, bạn có thật sự hiểu các trade-offs đằng sau không? Vì sao chỗ này lại dùng message queue thay vì gọi API trực tiếp? Vì sao lại chọn Cassandra chứ không phải PostgreSQL? Khi bị hỏi vặn lại, liệu có im lặng rồi sấp mặt như mấy em sinh viên chạy model mà không biết vì sao không dùng XGBoost không?

Trước đây, để học về hệ thống lớn, các bạn phải cày cuốc, đọc cả chục cái paper, mò mẫm code của các bậc tiền bối. Giờ AI nó tóm tắt lại cho bạn trong 3 nốt nhạc. Nhưng sự tiện lợi này lại lấy đi cái cốt lõi: quá trình tư duy và đào sâu để hiểu tận gốc rễ vấn đề. AI nâng productivity của người có kinh nghiệm lên rất nhanh, nhưng nó cũng có thể tạo ra một thế hệ kỹ sư “học mẹo”, chỉ biết “xài” mà không “hiểu”.

Vậy các bạn trẻ (và cả không trẻ nhưng skillset vẫn entry-level) cần làm gì? Câu trả lời muôn thuở: quay về với kiến thức nền tảng. Phải hiểu “domain knowledge” của ngành mình thật chắc.

Một vài bài viết và paper ví dụ minh họa cho việc hiểu và đọc sâu:

Một bài rất đáng đọc đến từ Uber: “Building Reliable Reprocessing for Critical Datasets at Scale”
- Vì sao phải đọc? Hãy tưởng tượng chỉ một bug nhỏ cũng có thể khiến hàng terabyte dữ liệu bị tính sai - ảnh hưởng đến thanh toán cho tài xế, hay thậm chí cả báo cáo tài chính. Trong bài viết này, Uber chia sẻ cách họ xây dựng một hệ thống “sửa sai” tự động và đủ tin cậy để vận hành ở quy mô khổng lồ - mà không làm sập cả công ty. Đọc để thấy họ phải đánh đổi những gì, và vì sao đôi khi, những giải pháp có sẵn lại không thể “vá” được vấn đề thật sự.
Từ thực tế của Netflix: “Scaling Time Series Data Storage at Netflix“
- Vì sao phải đọc? Ai cũng biết Netflix có hệ thống observability kinh khủng để theo dõi sức khỏe hệ thống. Bài viết này đào sâu vào một góc nhỏ nhưng cực kỳ quan trọng: họ đã lưu trữ và xử lý dữ liệu dạng chuỗi thời gian (time series) như thế nào ở quy mô hàng petabyte. Nó là một case study thực tế về việc “build vs. buy” (tự xây hay mua), những giới hạn của các giải pháp hiện có và cách họ tự xây một hệ thống tên là Atlas Telemetry Platform để giải quyết bài toán của riêng mình. Đây là minh chứng cho việc ở quy mô lớn, không có giải pháp “một kích cỡ cho tất cả”.
Kinh điển về Trade-offs: “CAP Theorem: Two Decades Later” của Eric Brewer
- Vì sao phải đọc? Hầu hết các hệ thống phân tán đều phải đánh đổi giữa Consistency, Availability, và Partition Tolerance. Bài viết này, từ chính cha đẻ của định lý CAP, sẽ cho bạn thấy định lý này không phải là “chọn 2 trong 3” một cách cứng nhắc, mà là một chuỗi các trade-offs tinh vi hơn nhiều. Hiểu được nó, bạn sẽ có cái nhìn thực tế hơn khi thiết kế hệ thống.
Kinh điển về NoSQL: “Amazon’s Dynamo: A Highly Available Key-value Store”
- Vì sao phải đọc? Cái paper này là nền móng cho cả một thế hệ database NoSQL sau này, bao gồm cả DynamoDB của AWS. Đọc nó để hiểu về eventual consistency, sharding, a “gossip” protocol... Đây là kiến thức nền tảng giúp bạn không bị ngợp khi làm việc với các hệ thống cloud-native hiện đại.

Hay nói cách khác, để thích nghi với thời đại AI này, các bạn cần làm gì?

Đừng để AI làm thay bạn trong việc suy nghĩ. Hãy coi nó là một trợ lý siêu nhanh để xử mấy việc tay chân - còn phần quan trọng nhất: tư duy về kiến trúc, đánh đổi, và quyết định thiết kế - vẫn là việc của bạn.
Đầu tư vào nền tảng. Những khái niệm cốt lõi như định lý CAP, các kiểu dữ liệu, hay thuật toán đồng thuận không bao giờ lỗi thời. Công nghệ thay đổi, nhưng nguyên lý thì ở đó.
Học từ thực tế. Đọc engineering blog của các công ty lớn - ví dụ những case study như Uber hay Netflix - để thấy họ đã vấp ngã thế nào và làm sao đứng dậy. Những bài học đó giá trị hơn mọi “hack” ngắn hạn.
Luôn hỏi “Tại sao?”. Đừng chấp nhận một giải pháp chỉ vì AI gợi ý hay vì nó đang là trend. Đào sâu đủ để hiểu rõ cái giá phải trả (trade-offs) - trước khi bạn bấm deploy.

Thị trường lao động sẽ ngày càng khắc nghiệt. Những kỹ năng mà bạn có thể học trong 3 phút trên mạng sẽ nhanh chóng bị thay thế. Chỉ có kiến thức nền tảng và khả năng tư duy sâu mới giúp bạn đứng vững. Đừng để mình trở thành một kỹ sư “entry-level” dù đã đi làm nhiều năm.

P/S: bài viết này được tạo ra với sự hỗ trợ của AI, bạn nghĩ AI đóng góp cho bài viết trên bao nhiêu phần trăm? :)

Phỏng vấn thời AI

(chia sẻ bởi bạn đọc n^4)

Chủ đề có nên cho phép ứng viên sử dụng AI trong quá trình phỏng vấn hay không là một câu hỏi thường được đặt ra trong thời gian gần đây. Vừa rồi, trong quá trình phỏng vấn, bản thân mình cũng đã thử đổi cách tiếp cận một tí, cho phép ứng viên có thể dùng AI thoải mái trong quá trình phỏng vấn, đặc biệt là coding interview, xem kết quả như thế nào.

Dĩ nhiên, đề bài đặt ra cũng thay đổi một tí. Thay vì đặt ra một đề bài đóng, yêu cầu ứng viên hiện thực hóa một thuật toán hoặc một component cụ thể, mình đặt ra đề bài là yêu cầu ứng viên xây dựng một chương trình nhằm giúp minh họa/giả lập một vấn đề gì đó. Và ứng viên có thể toàn quyền sử dụng AI, lựa chọn công nghệ, hình thức triển khai, …

So sánh giữa hai ứng viên có cách tiếp cận khác nhau.

Ứng viên A cũng có đặt ra 1-2 câu hỏi để làm rõ chương trình, nhưng sau đó sẽ dùng ngay đề bài để prompt “Hãy xây dựng chương trình để minh họa xxx / yyy”, … Sau khi AI viết ra chương trình, bạn chạy thử rồi bắt đầu đọc code xem AI implement như thế nào. Tuy nhiên, code AI viết ra lại hơi phức tạp và bạn hoàn toàn không giải thích được xem thuật toán hoạt động như thế nào. Dĩ nhiên, việc thời gian bị giới hạn cùng áp lực phỏng vấn cũng là một nhân tố làm cho bạn không trả lời được. Tuy nhiên, cách tiếp cận này rõ ràng không phù hợp trong một buổi phỏng vấn coding.

Ứng viên B có cách tiếp cận khác. Bạn sẽ phân tích coi là nên minh họa vấn đề/thuật toán này thế nào, bạn sẽ hỏi có cần UI hay không, nên scope down thành vài trường hợp cụ thể hơn, … Sau đó, bạn bắt đầu phân tích về cấu trúc dữ liệu cần thiết để minh họa thuật toán này, tiếp theo là bạn bắt đầu mô tả cách tiếp cận. Cuối cùng, bạn sử dụng AI để yêu cầu implement thuật toán để giải quyết đề bài. Đối với ứng viên này, thuật toán chạy ra vẫn không hoàn toàn đúng, nhưng bạn có thể giải thích và debug xem từng bước thuật toán hoạt động như thế nào.

Nhìn chung, dựa vào trải nghiệm cá nhân thì phỏng vấn có hay không có AI vẫn không thay đổi quá nhiều như mình nghĩ ban đầu. Việc ứng viên có kiến thức nền tảng hoặc kỹ năng tốt vẫn sẽ được biểu hiện rõ. Nên thay vì cấm dùng AI khi phỏng vấn, thì việc cho phép và khuyến khích dùng có khi lại làm cho quá trình phỏng vấn được tốt hơn.

Có lẽ điều tuyệt nhất khi làm kỹ sư không phải là viết ra dòng code hoàn hảo, mà là hiểu vì sao mình viết như thế.

Cảm ơn bạn đã đọc đến đây - mong rằng Grokking sẽ luôn là nơi bạn tìm thấy chút cảm hứng giữa những ngày đầy deadline và release.