Viết bởi một gã từng maintain microservice thanh toán cho 5 triệu người dùng, từng bị lôi dậy lúc 3 giờ sáng vì hệ thống down – và từng chửi thề khi thấy code của chính mình 3 tháng trước.

1. 28Tech Không Phải Leetcode – Nó Là Chỗ Để Luyện Cách Nghĩ Production

Bạn nghĩ mấy bài như "Tìm dãy con tăng dài nhất", "Xử lý truy vấn mảng", "Sắp xếp theo điều kiện ABC" là học thuật? Xin lỗi. Backend dev ngày ngày phải xử lý query phức tạp gấp 10 lần, trong khi thời gian load phải < 1s, tài nguyên server bị throttled, và user thì không kiên nhẫn.

Cách bạn giải bài sẽ phản ánh cách bạn viết code xử lý business real-world:

Gộp logic chung vào một hàm => chào mừng tới ticket “Fix bug logic nhưng không ảnh hưởng phần còn lại”

Không test edge case => Production down, xong gọi bạn giữa đêm

Không có tư duy scale => Đến khi data tăng gấp 10 thì bạn không scale nổi, bị đá khỏi dự án

1. Tư Duy Thuật Toán Không Phải Để Làm HackerRank – Mà Để Sống Sót Trong Codebase 500k Dòng

Tôi từng làm trong hệ thống xử lý reward point, mỗi tháng chạy batch 20 triệu giao dịch, điều kiện logic dị vãi cả *:

“Nếu user nằm trong nhóm promotion A, nhưng chưa nhận quà B, và có chi tiêu từ 15/3 đến 25/4, loại trừ cuối tuần…”

Bạn không có tư duy set/map/hash logic thì code đó dài như sớ táo quân.

Dev dốt thuật toán không sống được lâu ở môi trường có traffic. Dev giỏi thuật toán nhưng thiếu discipline cũng là mối nguy hiểm tiềm tàng.

28Tech cho bạn luyện: Khả năng rút gọn logic Tối ưu truy vấn lồng Tránh lặp dữ liệu Phân tích giới hạn tài nguyên

1. Viết Code Không Phải Để AC – Mà Để Duy Trì Được Sau 6 Tháng Không Đụng Vào

Một bài giải đẹp là bài: Nhìn vào thấy rõ chia input / process / output Có chỗ dễ thêm test case giả lập Có thể đưa thẳng vào một class handler xử lý logic trong hệ thống

Viết code như sau là tự sát:

int main() { int n; cin >> n; vector a(n); for (int &x : a) cin >> x; // xử lý ... }

Viết kiểu production là:

struct SubarraySolver { vector input; void load_input() { int n; cin >> n; input.resize(n); for (int &x : input) cin >> x; }

int solve() {
    // business logic here
}

void run() {
    load_input();
    int res = solve();
    cout << res << '\n';
}

};

Tại sao?

Dễ gắn unit test bằng cách nạp input bằng tay

Dễ chuyển thành handler trong API

Dễ debug/log từng step

Scale từ 1 bài → 100 case tương tự trong hệ thống

1. 28Tech Là Mô Phỏng Môi Trường Bạn Sẽ Làm Việc Nếu Làm Backend

Bài nhiều test case → như production có nhiều case người dùng

Giới hạn thời gian/memory → như khi chạy job server giới hạn CPU

Submit qua stdin/stdout → như system batch chạy bằng shell + cronjob

Bắt format đúng → như contract system định nghĩa output JSON y chang

1. Lời Khuyên Từ Một Người Đã Nếm Đủ Bug Production

Mỗi bài bạn AC bằng brute force là một lần bạn học cách scale logic gọn hơn

Mỗi lần bạn WA do không đọc kỹ đề là một lần bạn học cách đọc spec khách hàng

Mỗi dòng code tách hàm đúng là một dòng bạn tiết kiệm cho người khác debug 2 tháng sau

Giải bài cũng là kỹ năng sống sót. Không phải để đậu phỏng vấn – mà để không bị chính mình 6 tháng trước nguyền rủa.