[Ho Chi Minh] Full-Stack Developer (ReactJS/ NodeJS)

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.

Mỗi lần state hoặc props đổi, React gọi lại component để tạo cây element mới, so sánh với cây cũ (reconciliation), rồi chỉ cập nhật phần DOM thật sự thay đổi.

• Với list, key cho React biết phần tử nào là phần tử nào giữa hai lần render. Key phải ổn định và duy nhất trong list, thường là id từ dữ liệu.
• Dùng index làm key chỉ ổn khi list không bao giờ chèn, xoá hay đổi thứ tự.

Hay sai: dùng index cho list có thể xoá hoặc sắp xếp. React ghép nhầm state của item cũ sang item mới: ô input giữ nội dung của dòng đã bị xoá, checkbox tick sai dòng.

Mẹo hay được hỏi thêm: đổi key của một component là cách chủ động reset toàn bộ state của nó.

Props là dữ liệu cha truyền xuống, component con chỉ đọc. State là dữ liệu component tự quản lý; đổi state sẽ khiến component render lại.

• React so sánh state cũ và mới bằng tham chiếu (Object.is). Sửa trực tiếp state.items.push(x) thì tham chiếu không đổi, React có thể không render lại, và các tối ưu như memo cũng hỏng.
• Luôn tạo object hoặc array mới:

setItems(prev => [...prev, newItem]);
setUser(prev => ({ ...prev, name: "An" }));

• setState không cập nhật biến ngay trong lần render hiện tại. React gom nhiều lần set lại (batching) rồi mới render.

Hay sai: gọi setCount(count + 1) ba lần liên tiếp và mong tăng 3. Kết quả chỉ tăng 1; muốn tăng 3 phải dùng dạng hàm setCount(c => c + 1).

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.

CommonJS dùng require/module.exports, nạp đồng bộ lúc chạy. ES Modules dùng import/export, là chuẩn của ngôn ngữ, được phân tích tĩnh nên hỗ trợ tree-shaking và top-level await.

• Bật ESM bằng "type": "module" trong package.json hoặc đuôi .mjs.
• Trong ESM không có sẵn __dirname; dùng import.meta.dirname (Node mới) hoặc tính từ import.meta.url.
• ESM import được CommonJS. Chiều ngược lại trước đây phải dùng import() động; các bản Node gần đây đã cho require() module ESM đồng bộ (trừ module có top-level await).

Dự án mới nên dùng ESM, vì cả hệ sinh thái đang chuyển dần sang đó.

Hay sai: khi viết ESM thuần, quên ghi đuôi file trong đường dẫn import tương đối (./utils.js), dẫn đến lỗi không tìm thấy module.

useEffect dùng để đồng bộ component với hệ thống bên ngoài: subscribe sự kiện, kết nối WebSocket, gọi thư viện không phải React, gọi API.

• Không có dependency array: chạy sau mỗi lần render.
• []: chạy sau lần mount đầu tiên.
• [a, b]: chạy lại khi a hoặc b đổi.
• Hàm return là cleanup, chạy trước lần effect kế tiếp và khi unmount.

useEffect(() => {
  const id = setInterval(tick, 1000);
  return () => clearInterval(id);
}, []);

Ở development, Strict Mode cố ý chạy effect hai lần để bạn phát hiện thiếu cleanup.

Hay sai: dùng effect để tính dữ liệu dẫn xuất từ state/props (setFullName(first + last)). Hãy tính thẳng trong lúc render; effect thừa gây render hai lần và dễ lệch dữ liệu.

Controlled: giá trị input nằm trong state React, mọi thay đổi đi qua onChange. Uncontrolled: DOM tự giữ giá trị, bạn đọc khi cần qua ref hoặc khi form submit.

<input value={name} onChange={e => setName(e.target.value)} />
<input defaultValue="An" name="name" />

• Controlled hợp khi cần validate ngay khi gõ, định dạng giá trị, hoặc ô này phụ thuộc ô kia.
• Uncontrolled đơn giản hơn, ít render hơn; hợp với form lớn hoặc khi dùng thư viện như React Hook Form. React 19 còn hỗ trợ truyền hàm vào <form action> và đọc dữ liệu bằng FormData.

Hay sai: chuyển một input từ value={undefined} sang có giá trị, khiến React cảnh báo đổi từ uncontrolled sang controlled. Khởi tạo state bằng "" thay vì undefined.

Cả ba dùng để tránh tính toán hoặc render lại không cần thiết:

• useMemo: nhớ kết quả của phép tính tốn kém.
• useCallback: nhớ hàm, để tham chiếu không đổi giữa các lần render.
• React.memo: bỏ qua render component con nếu props không đổi (so sánh nông).

Chúng thường phải đi cùng nhau: truyền hàm mới mỗi lần render vào component đã memo thì memo vô tác dụng.

Dùng tràn lan làm code khó đọc, tốn công so sánh dependency, và dễ sai khi thiếu dependency. Chỉ nên dùng khi đã đo bằng React DevTools Profiler và thấy chậm, hoặc khi giá trị đó là dependency của effect.

React Compiler có thể tự thêm memo khi build, giảm nhu cầu viết tay.

Người phỏng vấn muốn nghe: trước khi memo, hãy thử đưa state xuống thấp hơn hoặc truyền component qua children để giảm phạm vi render lại.

Cho thấy bạn có cách làm cụ thể, không chỉ nói "em chịu được áp lực".

• Chia nhỏ việc, ưu tiên phần quan trọng nhất cho mục tiêu.
• Báo sớm cho lead/PM nếu thấy không kịp, đề xuất cắt phạm vi hoặc xin hỗ trợ.
• Giữ chất lượng ở phần cốt lõi; ghi lại nợ kỹ thuật để xử lý sau.
• Giữ bình tĩnh, giao tiếp ngắn gọn, rõ ràng với team.

Câu mẫu theo STAR: "Trước buổi demo cho khách, team phát hiện lỗi tích hợp chỉ còn hai ngày. Em liệt kê các phần bị ảnh hưởng, cùng PM chọn luồng nào bắt buộc phải chạy cho demo, phần còn lại hẹn bàn giao tuần sau. Demo diễn ra suôn sẻ và khách đồng ý với lịch mới."

Hay sai: khoe thức trắng nhiều đêm. Người phỏng vấn muốn thấy bạn quản lý được áp lực, không chỉ chịu đựng.