Backend Lead

PO ưu tiên theo giá trị mang lại so với chi phí và rủi ro, gắn với mục tiêu sản phẩm.

• Mục tiêu sản phẩm/công ty trong giai đoạn này: tăng người dùng mới, giữ chân, doanh thu, hay giảm chi phí vận hành.
• Dữ liệu: số liệu sử dụng, phản hồi người dùng, ticket hỗ trợ, kết quả phỏng vấn người dùng.
• Effort và rủi ro do team ước lượng; phụ thuộc kỹ thuật; nợ kỹ thuật cần trả.
• Ràng buộc bắt buộc: quy định pháp lý, cam kết hợp đồng, hạn chót của đối tác.
• Framework hỗ trợ: RICE, MoSCoW, Kano, value/effort.

Người phỏng vấn muốn nghe: ví dụ một lần bạn từ chối hoặc hoãn một yêu cầu từ sếp/khách lớn nhờ dữ liệu, và cách bạn giải thích để họ đồng ý.

Tận dụng giờ làm trùng nhau cho việc cần trao đổi trực tiếp, phần còn lại làm bất đồng bộ có tài liệu.

• Thống nhất lịch họp cố định trong khung giờ trùng (daily hoặc vài buổi mỗi tuần), có agenda và biên bản.
• Câu hỏi gom lại, viết rõ ràng kèm ngữ cảnh và phương án đề xuất, để khách trả lời được ngay trong một lần.
• Báo cáo định kỳ: đã làm, sẽ làm, rủi ro, quyết định cần khách đưa ra.
• Demo cuối sprint để khách thấy sản phẩm thật; ghi hình nếu khách không tham gia được.
• Lưu ý khác biệt văn hoá: một số khách cần nói thẳng, một số cần trang trọng; chủ động báo tin xấu sớm.

Hay sai: để team chờ câu trả lời của khách cả ngày mà không có việc dự phòng.

Quản lý rủi ro là xác định sớm, đánh giá, có kế hoạch ứng phó và theo dõi liên tục.

• Lập danh sách rủi ro (risk register) ngay từ đầu: nhân sự, công nghệ mới, phụ thuộc bên thứ ba, yêu cầu chưa rõ, hạ tầng.
• Đánh giá khả năng xảy ra và mức ảnh hưởng, ưu tiên rủi ro cao.
• Chọn cách ứng phó: tránh, giảm thiểu, chuyển giao, chấp nhận; mỗi rủi ro có người chịu trách nhiệm theo dõi.
• Xem lại trong các buổi họp định kỳ, cập nhật khi tình hình thay đổi.

Ví dụ theo STAR: "API của đối tác chưa sẵn sàng (S), em cần giữ tiến độ tích hợp (T). Em đề xuất team làm mock theo tài liệu API, đồng thời hẹn mốc kiểm tra với đối tác hàng tuần (A). Khi API thật có, phần tích hợp chỉ mất vài ngày điều chỉnh (R)."

Goroutine leak là goroutine bị chặn mãi mãi và không bao giờ kết thúc, giữ theo bộ nhớ và tài nguyên nó tham chiếu. Số goroutine tăng dần theo thời gian là dấu hiệu rõ nhất.

Nguyên nhân hay gặp:

• Gửi vào channel mà bên nhận đã bỏ đi (ví dụ đã trả về vì timeout).
• Nhận từ channel không bao giờ được gửi hoặc đóng.
• Vòng lặp chạy nền không kiểm tra ctx.Done().
• HTTP response không đóng Body.

ch := make(chan Result, 1) // buffer 1: goroutine gửi xong vẫn thoát được
go func() { ch <- slowCall() }()
select {
case r := <-ch: return r, nil
case <-ctx.Done(): return Result{}, ctx.Err()
}

Phát hiện: theo dõi runtime.NumGoroutine(), xem profile goroutine qua net/http/pprof, dùng thư viện goleak trong test.

Người phỏng vấn muốn nghe: mỗi goroutine bạn tạo phải có câu trả lời rõ ràng cho câu hỏi "nó kết thúc khi nào?".

Từ Go 1.18, hàm và kiểu có thể nhận type parameter với ràng buộc (constraint):

func Map[T, U any](in []T, f func(T) U) []U {
    out := make([]U, 0, len(in))
    for _, v := range in {
        out = append(out, f(v))
    }
    return out
}

• Constraint có thể là any, comparable, cmp.Ordered, hoặc interface tự định nghĩa chứa tập kiểu (~int | ~float64).
• Thư viện chuẩn đã có các package generic như slices và maps.

Khi nào dùng:

• Generics: cấu trúc dữ liệu và hàm tiện ích làm việc giống hệt nhau với nhiều kiểu (cache, set, hàm lọc, phân trang).
• Interface: khi cần hành vi khác nhau cho từng kiểu (lưu vào DB hay vào file, nhiều cổng thanh toán).

Hay sai: generic hoá mọi thứ ngay từ đầu. Code Go chuộng đơn giản; hãy viết cụ thể trước, khi có hai ba chỗ lặp lại thật sự thì mới trích generic.

Cache giảm độ trễ và tải cho DB, đổi lại phải chấp nhận dữ liệu có thể cũ trong một khoảng thời gian.

• Cache-aside (phổ biến nhất): đọc cache, miss thì đọc DB rồi ghi vào cache kèm TTL. Khi cập nhật thì ghi DB rồi xoá key cache.
• Write-through: ghi qua cache rồi cache ghi xuống DB, dữ liệu cache luôn mới nhưng ghi chậm hơn.
• Write-behind: ghi cache trước, đẩy xuống DB sau; nhanh nhưng có thể mất dữ liệu.

Các vấn đề cần xử lý:

• Cache stampede: key nóng hết hạn, hàng nghìn request cùng đánh vào DB. Giải pháp: lock hoặc single-flight, làm mới sớm, thêm độ lệch ngẫu nhiên cho TTL.
• Cache penetration: truy vấn key không tồn tại liên tục. Giải pháp: cache cả kết quả rỗng, dùng bloom filter.

Hay sai: cập nhật cache thay vì xoá, dễ ghi đè giá trị cũ khi hai request chạy song song.

Đầu tiên là minh bạch: báo sớm, kèm nguyên nhân và phương án, không chỉ báo tin xấu.

• Đánh giá lại thực trạng: còn bao nhiêu việc, velocity thực tế, đường găng (critical path).
• Đưa các phương án với đánh đổi rõ ràng: cắt bớt phạm vi cho đợt đầu, dời mốc, bổ sung nguồn lực (lưu ý người mới cần thời gian làm quen), song song hoá một số việc.
• Đề xuất một phương án bạn khuyến nghị và lý do.
• Sau khi chốt: kế hoạch mới, mốc kiểm tra gần hơn, báo cáo thường xuyên hơn để lấy lại niềm tin.
• Tìm nguyên nhân gốc để không lặp lại.

Người phỏng vấn muốn nghe: bạn không giấu, không đổ lỗi cho team hay khách, và biết rằng thêm người vào dự án đang trễ thường không giúp kịp ngay.

Không chỉ "đúng hạn, đúng ngân sách", mà còn giá trị mang lại và sức khoẻ của team.

• Dự án: tiến độ theo mốc, chi phí so với ngân sách, phạm vi bàn giao, chất lượng (bug sau release, số lần hotfix), mức hài lòng của khách hàng.
• Sản phẩm: chỉ số gắn với mục tiêu như người dùng hoạt động, tỷ lệ chuyển đổi, tỷ lệ giữ chân, doanh thu, chi phí vận hành giảm.
• Team: tốc độ ổn định, ít OT kéo dài, tỷ lệ nghỉ việc thấp, retrospective có cải tiến thật.

Ví dụ: "Dự án trước bàn giao trễ hai tuần so với kế hoạch ban đầu nhưng khách đã đồng ý từ sớm vì đổi phạm vi; sau go-live ít lỗi nghiêm trọng và khách ký tiếp giai đoạn 2. Em coi đó là thành công."

Hay sai: chỉ nói về output (số tính năng) mà không nói outcome.

Phát hiện sớm, nói thật sớm, và chọn phương án cùng team và PO.

• Tìm nguyên nhân: estimate sai, phát sinh việc ngoài kế hoạch, bị block bởi bên khác, có người nghỉ.
• Gỡ block trước: liên hệ team khác, khách hàng, xin môi trường, quyết định nhanh các điểm chờ.
• Cùng PO thương lượng phạm vi: giữ những gì quan trọng nhất cho sprint goal, đẩy phần còn lại sang sprint sau.
• Thông báo cho stakeholder kèm kế hoạch mới, không đợi tới ngày review.
• Retrospective: tìm nguyên nhân gốc để điều chỉnh planning lần sau.

Hay sai: bắt team OT để kịp mà không đổi gì về phạm vi. Làm một lần có thể được, nhưng lặp lại thì chất lượng giảm và người giỏi sẽ nghỉ.

Trả lời thật nhưng hướng về phía trước: nói điều bạn đang tìm kiếm, không kể xấu nơi cũ.

Lý do chấp nhận được: muốn thử thách mới, muốn làm sản phẩm, dự án kết thúc, công ty tái cấu trúc, thu nhập chưa tương xứng (nói khéo).

Câu mẫu: "Em đã làm 2 năm ở dự án outsourcing, học được nhiều về quy trình và làm việc với khách nước ngoài. Giờ em muốn gắn bó lâu dài với một sản phẩm để thấy được tác động của những gì mình làm, và vị trí bên mình đúng hướng đó."

Hay sai: chê sếp, chê đồng nghiệp, kể chuyện drama. Người phỏng vấn sẽ nghĩ bạn cũng sẽ nói về công ty họ như vậy. Nếu nhảy việc nhiều, chuẩn bị lời giải thích cho từng lần.