Frontend Developer (Angular)

Cả bốn đều chạy nhiều Promise song song, khác nhau ở cách kết thúc:

• all: chờ tất cả thành công; một cái lỗi là reject ngay.
• allSettled: chờ tất cả xong, trả về trạng thái từng cái; không bao giờ reject.
• race: lấy kết quả (thành công hay lỗi) của cái xong đầu tiên; hay dùng để đặt timeout.
• any: lấy cái thành công đầu tiên; chỉ reject khi tất cả đều lỗi.

try {
  const [user, orders] = await Promise.all([getUser(id), getOrders(id)]);
} catch (err) {
  showError(err);
}

Hay sai: await lần lượt trong vòng lặp các request không phụ thuộc nhau, khiến tổng thời gian cộng dồn. Ngược lại, gọi Promise.all với hàng nghìn request cùng lúc có thể làm quá tải server; khi đó cần giới hạn số request đồng thời.

Cả hai đều mô tả hình dạng object và phần lớn trường hợp dùng thay nhau được.

• interface có thể gộp khai báo (declaration merging) và extends; hợp để mô tả object, API công khai.
• type mô tả được union, tuple, kiểu ánh xạ, kiểu điều kiện: type Status = "idle" | "loading".

Ba kiểu đặc biệt:

• any: tắt kiểm tra kiểu, lỗi lọt qua compiler.
• unknown: nhận mọi giá trị nhưng bắt buộc thu hẹp kiểu trước khi dùng. Hợp cho dữ liệu từ JSON.parse, API, catch (e).
• never: giá trị không bao giờ xảy ra; dùng để bắt thiếu case trong switch.

function assertNever(x: never): never {
  throw new Error("Unhandled: " + x);
}

Hay sai: dùng as SomeType để ép dữ liệu từ API. Đó chỉ là lời hứa với compiler; muốn chắc chắn phải validate lúc runtime (ví dụ bằng Zod).

Cả hai giới hạn số lần một hàm chạy khi sự kiện bắn liên tục.

• Debounce: chỉ chạy sau khi sự kiện ngừng một khoảng thời gian. Hợp với ô tìm kiếm gợi ý (gõ xong mới gọi API), validate form, resize xong mới tính lại layout.
• Throttle: chạy tối đa một lần mỗi khoảng thời gian. Hợp với scroll, kéo thả, theo dõi vị trí chuột.

function debounce(fn, ms) {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), ms);
  };
}

Hay sai: tạo hàm debounce mới mỗi lần render (trong React), khiến timer bị reset liên tục và debounce không có tác dụng. Với ô tìm kiếm, nhớ huỷ request cũ (AbortController) để kết quả cũ không đè kết quả mới.

Generics giúp viết hàm và kiểu dùng lại được mà vẫn giữ thông tin kiểu, thay vì rơi về any.

type Result<T> =
  | { ok: true; data: T }
  | { ok: false; error: string };

function show(r: Result<User>) {
  if (r.ok) return r.data.name; // TS biết có data
  return r.error;
}

• Field chung (ok, type, status) giúp TypeScript thu hẹp kiểu trong if/switch. Đây là cách mô hình hoá trạng thái không thể sai: không có chuyện vừa có data vừa có error.
• Ràng buộc generic: <T extends { id: string }>.
• Utility types hay dùng: Partial, Pick, Omit, Record, ReturnType, Awaited.
• Type guard tự viết: function isUser(x: unknown): x is User.

Người phỏng vấn muốn nghe: bạn dùng kiểu để làm trạng thái sai không biểu diễn được, chứ không chỉ để chú thích.

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.

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.

"My tech lead wanted to release a feature without load testing because of a tight deadline. I was worried because the feature would run during peak hours. I explained my concern and suggested a quick test on just the critical API, which took half a day. The test found a memory issue that we fixed before release. My lead appreciated it, and load testing became part of our release checklist."

Mẹo: giọng điệu nên tôn trọng: "I explained my concern", "I suggested", tránh "I told him he was wrong". Câu chuyện cần có kết quả tích cực cho team, không phải bạn thắng tranh luận.

Người phỏng vấn muốn biết mục tiêu của bạn có khớp với hướng phát triển ở công ty và bạn có định gắn bó không.

• Nêu hướng phát triển cụ thể, thực tế: đi sâu chuyên môn (senior, chuyên gia một mảng) hay quản lý (lead, PM).
• Kèm kế hoạch: kỹ năng cần học, trách nhiệm muốn nhận thêm.
• Gắn với cơ hội ở vị trí đang ứng tuyển.

Câu mẫu: "Trong 2–3 năm tới em muốn trở thành senior có thể tự thiết kế và chịu trách nhiệm một module lớn, đồng thời hướng dẫn được các bạn mới. Em đang học thêm về thiết kế hệ thống và thấy team bên mình có nhiều bài toán ở quy mô lớn, rất hợp để em phát triển theo hướng đó."

Hay sai: "Em muốn mở công ty riêng" hoặc "em chưa nghĩ tới". Cũng đừng nói muốn ngồi vào chỗ của người đang phỏng vấn.