Frontend ReactJS Developer

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.

Trước hết phân loại state:

• Server state (dữ liệu từ API): dùng TanStack Query hoặc SWR. Chúng lo cache, loading, refetch, đồng bộ. Phần lớn "global state" trong app thực ra thuộc loại này.
• UI state cục bộ: useState/useReducer ngay trong component.
• State trên URL (bộ lọc, trang): để trên query string, chia sẻ link được.
• Client state toàn cục thật sự (giỏ hàng, theme, user đang đăng nhập): Context nếu ít thay đổi; Zustand hoặc Redux Toolkit nếu thay đổi thường xuyên hoặc logic phức tạp.

Redux Toolkit hợp khi team lớn cần quy ước chặt và DevTools mạnh. Zustand gọn nhẹ hơn.

Hay sai: gom state hay thay đổi vào một Context lớn. Mọi component dùng Context đó render lại mỗi lần bất kỳ giá trị nào đổi. Hãy tách Context, hoặc dùng thư viện có selector.

Mỗi lần render tạo ra hàm mới, "chụp" lại props và state của lần render đó. Nếu effect chỉ chạy một lần, callback bên trong mãi thấy giá trị lúc mount.

useEffect(() => {
  const id = setInterval(() => {
    setCount(count + 1); // count luôn là 0
  }, 1000);
  return () => clearInterval(id);
}, []);

Cách sửa:

• Dùng functional update: setCount(c => c + 1), không cần đọc count.
• Khai báo đúng dependency (effect chạy lại khi giá trị đổi, nhớ cleanup).
• Với giá trị chỉ cần đọc mới nhất mà không muốn chạy lại effect: lưu vào useRef.

Hay sai: tắt cảnh báo exhaustive-deps của ESLint cho xong. Cảnh báo đó thường chính là dấu hiệu stale closure.

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.

Server Component chạy trên server (lúc build hoặc lúc request), có thể await dữ liệu trực tiếp từ DB hoặc API, và không gửi JavaScript của nó xuống trình duyệt. Trong App Router, component mặc định là Server Component.

• Dùng Server Component cho: lấy dữ liệu, render nội dung tĩnh, dùng secret hoặc thư viện nặng chỉ cần ở server.
• Cần "use client" khi dùng state, effect, sự kiện (onClick), API trình duyệt (window, localStorage).
• "use client" đánh dấu ranh giới: mọi module được import từ file đó đều vào bundle client.
• Server Component có thể truyền Server Component khác vào Client Component qua children.
• Props truyền từ server sang client phải serialize được (không truyền hàm thường; Server Action thì được).

Hay sai: đặt "use client" ở layout gốc, biến cả app thành client và mất lợi ích. Hãy đẩy phần tương tác xuống các component lá.

Người phỏng vấn muốn biết bạn tự quản lý được và giao tiếp chủ động khi không ngồi cạnh team.

• Cập nhật tiến độ thường xuyên trên công cụ chung (ticket, kênh chat của team), không để người khác phải hỏi.
• Viết rõ ràng: câu hỏi có ngữ cảnh, ghi lại kết quả thảo luận.
• Có khung giờ làm việc ổn định, phản hồi trong giờ làm, báo trước khi vắng.
• Dùng ngày lên văn phòng (nếu hybrid) cho thảo luận, brainstorm, gặp gỡ team.

Câu mẫu: "Team cũ của em làm hybrid hai ngày ở văn phòng. Những ngày remote em cập nhật trạng thái task mỗi sáng và cuối ngày, vướng gì thì gọi nhanh 10 phút thay vì nhắn qua lại."