Middle/Senior Developer (NodeJS, ReactJS, AI)

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.

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á.

NestJS tổ chức app thành module. Mỗi module khai báo controller, provider (service, repository) và exports những gì module khác được dùng. IoC container của Nest tự tạo provider và inject qua constructor.

@Injectable()
export class OrdersService {
  constructor(private readonly repo: OrdersRepository) {}
}

Thứ tự một request đi qua: middleware, guard, interceptor (trước), pipe, handler, interceptor (sau); exception filter bắt lỗi ở bất kỳ bước nào.

• Guard: quyết định request có được đi tiếp không (xác thực, phân quyền).
• Pipe: biến đổi và validate input (ValidationPipe với DTO).
• Interceptor: bọc quanh handler: log, đo thời gian, đổi định dạng response, cache.

Hay sai: hai provider phụ thuộc vòng tròn rồi xử lý bằng forwardRef khắp nơi. Thường đó là dấu hiệu nên tách lại trách nhiệm giữa các module.

Trước hết xác nhận có leak thật: theo dõi heap qua thời gian (process.memoryUsage(), metrics của APM). Heap tăng rồi giảm sau GC là bình thường; chỉ tăng không giảm mới là leak.

Nguyên nhân hay gặp:

• Cache trong bộ nhớ (Map, object) không giới hạn kích thước hoặc thời hạn.
• Event listener đăng ký mỗi request mà không gỡ (thường kèm cảnh báo MaxListenersExceededWarning).
• Closure giữ object lớn; timer không clearInterval.
• Mảng toàn cục lưu dữ liệu request để debug rồi quên xoá.

Cách điều tra:

1. Chạy với --inspect, mở Chrome DevTools, chụp heap snapshot trước và sau khi bắn tải, so sánh object tăng thêm và chuỗi retainers.
2. Dùng --heapsnapshot-near-heap-limit để tự chụp snapshot khi sắp hết bộ nhớ.

Người phỏng vấn muốn nghe: cache thì dùng LRU có giới hạn hoặc Redis, và biết rằng tăng --max-old-space-size chỉ làm lỗi đến chậm hơn.

Xây một bộ đánh giá (eval set) đại diện cho câu hỏi thật, chạy tự động như test hồi quy mỗi khi đổi prompt, mô hình hay cách truy xuất.

• Dữ liệu: câu hỏi thật đã ẩn danh, trường hợp khó, câu hỏi ngoài phạm vi, câu cố tình phá.
• Đánh giá truy xuất: tài liệu đúng có nằm trong top-k không (recall@k).
• Đánh giá câu trả lời: đúng sự thật, bám nguồn, đầy đủ, đúng định dạng; dùng kiểm tra bằng code khi được, LLM-as-judge có rubric rõ, và người chấm mẫu để hiệu chỉnh.
• Sau ra mắt: thu phản hồi người dùng, log và soi các ca thất bại để bổ sung bộ eval.

Hay sai: chỉ thử vài câu bằng tay rồi kết luận "ổn".

Đo trước: React DevTools Profiler (bật "Highlight updates" và xem component nào render nhiều, tốn bao lâu) và tab Performance của Chrome để tìm long task.

Các hướng xử lý thường gặp:

• Giảm phạm vi render: đưa state xuống gần nơi dùng; tách component; memo các hàng của bảng với props ổn định.
• Virtualization cho list hoặc bảng dài: chỉ render các dòng đang hiện (TanStack Virtual, react-window).
• Ưu tiên cập nhật: useDeferredValue hoặc useTransition để ô input phản hồi ngay, còn việc lọc bảng chạy sau và có thể bị ngắt.
• Tính toán nặng: useMemo, hoặc chuyển sang Web Worker.
• Bundle lớn: lazy() và Suspense để tách code theo route hoặc theo modal.

Người phỏng vấn muốn nghe: bạn tìm ra nguyên nhân cụ thể (render thừa, DOM quá nhiều, JS nặng) rồi mới chọn kỹ thuật, không rải useMemo khắp nơi.

• CSR: trình duyệt tải JS rồi mới render; nội dung hiện chậm, kém cho SEO.
• SSR: server render HTML cho mỗi request. Dữ liệu luôn mới, tốn tài nguyên server.
• SSG: render sẵn lúc build. Rất nhanh, hợp nội dung ít đổi.
• ISR / revalidate: trang tĩnh được làm mới định kỳ hoặc theo sự kiện.

Hydration là bước React gắn sự kiện vào HTML do server render. Mismatch xảy ra khi lần render đầu ở client khác HTML từ server:

• Dùng Date.now(), Math.random(), múi giờ, window hoặc localStorage trong lúc render.
• HTML lồng sai (<div> trong <p>), extension trình duyệt sửa DOM.

Cách sửa: chuyển phần chỉ có ở client vào useEffect, hoặc render component đó chỉ ở client; định dạng ngày giờ bằng múi giờ cố định.

Người phỏng vấn muốn nghe: bạn chọn cách render theo từng trang, dựa trên độ tươi dữ liệu và nhu cầu SEO.

React 19 tập trung vào việc xử lý thao tác bất đồng bộ (gửi form, mutation) gọn hơn:

• Actions: truyền hàm async vào <form action={fn}> hoặc chạy trong startTransition. React tự theo dõi trạng thái pending, lỗi, và reset form.
• useActionState: giữ kết quả của action (thông báo lỗi, dữ liệu trả về) và cờ isPending.
• useFormStatus: component con (nút submit) đọc trạng thái pending của form cha mà không cần truyền props.
• useOptimistic: hiện kết quả ngay (like, thêm comment) trong lúc chờ server, tự quay về nếu lỗi.
• use(): đọc Promise hoặc Context, gọi được trong điều kiện.
• ref được truyền như prop thường, ít cần forwardRef.

Người phỏng vấn muốn nghe: những API này bỏ bớt code tự quản lý isLoading, error và rollback, và kết hợp tự nhiên với Server Actions trong Next.js.

Chọn điểm yếu thật, không chí mạng với vị trí, và cho thấy bạn đang cải thiện.

Cấu trúc: điểm yếu, ảnh hưởng đã gặp, việc bạn đang làm để khắc phục, tiến bộ đến nay.

Câu mẫu: "Trước đây em hay ngại hỏi khi bị kẹt, tự loay hoay quá lâu, có lần làm trễ task. Giờ em tự đặt giới hạn: kẹt quá một hai giờ mà không có hướng thì em hỏi đồng đội, kèm những gì đã thử. Từ khi làm vậy em xong việc đúng hạn hơn và học được nhanh hơn từ người khác."

Ví dụ khác có thể dùng: chưa quen nói trước đám đông, tiếng Anh nói chưa trôi chảy, hay ôm việc.

Hay sai: "Điểm yếu của em là quá cầu toàn" (nghe như né câu hỏi), hoặc nêu điểm yếu là kỹ năng cốt lõi của vị trí.