Viettel AI_Kỹ sư Phát triển phần mềm

Memory leak ở frontend thường do thứ gì đó vẫn giữ tham chiếu đến object đáng lẽ đã bỏ đi, nhất là trong SPA vì trang không bao giờ tải lại.

Nguyên nhân hay gặp:

• addEventListener trên window/document mà không gỡ khi component bị huỷ.
• setInterval, subscription (WebSocket, store) không huỷ.
• DOM đã bị gỡ khỏi trang nhưng vẫn được biến JS giữ lại (detached DOM).
• Cache hoặc mảng toàn cục chỉ tăng không giảm.

Cách điều tra với Chrome DevTools:

1. Tab Memory: chụp heap snapshot, thực hiện thao tác vài lần, chụp lại, so sánh phần tăng thêm.
2. Lọc "Detached" để tìm DOM bị giữ, xem chuỗi retainers để biết ai đang giữ.
3. Tab Performance bật Memory để xem heap có giảm sau GC không.

Người phỏng vấn muốn nghe: mỗi tài nguyên đăng ký đều có chỗ huỷ tương ứng (cleanup của effect, ngOnDestroy, onUnmounted, AbortController).

Ba chỉ số chính đo trải nghiệm thật của người dùng:

• LCP (Largest Contentful Paint): thời gian hiện phần tử lớn nhất. Cải thiện: tối ưu ảnh (định dạng hiện đại, đúng kích thước, ưu tiên tải ảnh hero), giảm thời gian phản hồi server, cache/CDN, render phía server.
• INP (Interaction to Next Paint, thay FID từ 2024): độ trễ khi tương tác. Cải thiện: chia nhỏ tác vụ JS dài, giảm JS chạy trên main thread, tránh render lại quá nhiều.
• CLS (Cumulative Layout Shift): độ xô lệch bố cục. Cải thiện: khai báo kích thước cho ảnh, video, quảng cáo; tránh chèn nội dung đẩy trang xuống; xử lý font.

Ngoài ra: code splitting và lazy load theo route, bỏ thư viện nặng không cần, nén và cache tài nguyên tĩnh.

Người phỏng vấn muốn nghe: bạn đo bằng dữ liệu người dùng thật (field data) lẫn Lighthouse, và biết điểm Lighthouse không phải là mục tiêu cuối.

• XSS: kẻ tấn công chèn script chạy trên trang của bạn. Phòng: framework tự escape khi render; tránh innerHTML, v-html, dangerouslySetInnerHTML với dữ liệu người dùng (nếu bắt buộc thì sanitize); cấu hình Content-Security-Policy.
• CSRF: trang lạ khiến trình duyệt gửi request kèm cookie của người dùng. Phòng: cookie SameSite=Lax hoặc Strict, CSRF token, kiểm tra Origin.
• CORS: là cơ chế trình duyệt nới lỏng same-origin policy, do server cấu hình. Nó không phải lớp bảo vệ API khỏi người gọi ngoài trình duyệt.

Lưu token:

• localStorage tiện nhưng script XSS nào cũng đọc được.
• Cookie HttpOnly + Secure + SameSite thì JS không đọc được, nhưng phải tính đến CSRF.

Người phỏng vấn muốn nghe: không có chỗ lưu nào an toàn tuyệt đối; chặn XSS mới là việc quan trọng nhất, vì có XSS thì mọi cách lưu đều bị lợi dụng.

SLI là chỉ số đo trải nghiệm người dùng (tỷ lệ request thành công, độ trễ p99); SLO là mục tiêu cho SLI đó trong một khoảng thời gian; error budget là phần được phép hỏng còn lại.

• Ví dụ: SLO 99.9% request thành công trong 30 ngày, nghĩa là budget 0.1% request lỗi.
• Alert theo burn rate: budget đang bị tiêu nhanh bất thường (đo trên cửa sổ ngắn và dài) thì báo, thay vì báo mỗi khi CPU cao.
• Hết budget: ưu tiên việc ổn định, chậm lại tính năng mới.

Hay sai: đặt alert trên nguyên nhân (CPU, RAM) thay vì triệu chứng người dùng thấy, dẫn đến báo động giả và mệt mỏi vì alert.

GitOps coi Git là nguồn sự thật cho trạng thái hệ thống; một agent trong cluster (Argo CD, Flux) liên tục kéo và đồng bộ, thay vì CI đẩy thẳng bằng kubectl.

• Tách repo code ứng dụng và repo cấu hình deploy; CI build image rồi mở PR cập nhật tag.
• Cấu hình dùng chung bằng Helm chart hoặc Kustomize, overlay riêng cho dev/staging/prod.
• Lên prod qua PR có review; rollback bằng git revert.
• Bật phát hiện drift và tự sửa lệch cấu hình.
• CI không cần giữ credential admin của cluster.

Người phỏng vấn muốn nghe: cân nhắc được đánh đổi, ví dụ secret vẫn cần giải pháp riêng và số lượng PR cập nhật tag có thể nhiều.

Agent cho LLM tự quyết định gọi tool theo nhiều bước, nên lỗi và rủi ro tăng theo số bước; cần giới hạn quyền và kiểm soát chặt.

• Tool rõ ràng: mô tả và schema tham số chặt, kiểm tra đầu vào bằng code trước khi thực thi.
• Quyền tối thiểu: tool chỉ đọc khi có thể; thao tác ghi, xoá, chuyển tiền cần người xác nhận.
• Prompt injection: nội dung lấy từ web, email, tài liệu là dữ liệu không tin cậy; không để nó điều khiển tool nhạy cảm.
• Giới hạn số bước, timeout, ngân sách token; xử lý lỗi tool và cho phép thử lại có kiểm soát.
• Log và tracing toàn bộ chuỗi hành động để audit.
• Đánh giá theo tỷ lệ hoàn thành tác vụ trên bộ kịch bản.

Người phỏng vấn muốn nghe: workflow cố định thường đủ; chỉ dùng agent tự do khi thật cần.

var có phạm vi hàm, còn let/const có phạm vi block ({}). const không cho gán lại biến, nhưng object hay array bên trong vẫn sửa được.

• Hoisting: khai báo được "kéo" lên đầu phạm vi. var được khởi tạo sẵn là undefined, nên dùng trước khi khai báo không báo lỗi.
• let/const cũng được hoist nhưng chưa khởi tạo. Truy cập trước dòng khai báo ném ReferenceError; khoảng đó gọi là temporal dead zone.
• Function declaration được hoist cả phần thân, nên gọi được trước khi định nghĩa.

console.log(a); // undefined
console.log(b); // ReferenceError
var a = 1;
let b = 2;

Người phỏng vấn muốn nghe: mặc định dùng const, cần gán lại mới dùng let, và gần như không dùng var trong code mới.

=== so sánh cả kiểu lẫn giá trị. == ép kiểu trước khi so, nên cho ra kết quả khó đoán: "0" == 0 là true, [] == false cũng true.

• Các giá trị falsy: false, 0, -0, 0n, "", null, undefined, NaN. Mọi thứ khác là truthy, kể cả [], {} và "0".
• NaN === NaN là false; dùng Number.isNaN(x).
• Ngoại lệ hay được chấp nhận: x == null để bắt cả null lẫn undefined.

Hay sai: viết const page = input || 1. Khi người dùng nhập 0, giá trị bị thay bằng 1. Dùng nullish coalescing input ?? 1 để chỉ thay khi là null hoặc undefined.

"I'd focus on the impact and what we're doing about it, not the technical details. For example: 'Some customers saw the wrong total in their cart when they applied two discount codes at once. No payments were affected. We've found the cause, the fix is being tested now, and it should be live tomorrow morning. Until then, we've limited orders to one code each.'"

Mẹo: cấu trúc ảnh hưởng – nguyên nhân (một câu đơn giản) – đã làm gì – khi nào xong. Tránh thuật ngữ như "null pointer", "race condition". Cụm hữu ích: "The good news is…", "To be safe, we have…".

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.