AI-Native Full-Stack Developer Intern

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.

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.

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

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.

Closure là khi một hàm "nhớ" được các biến ở phạm vi nơi nó được tạo ra, kể cả sau khi hàm bên ngoài đã chạy xong.

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// In ra 3, 3, 3

• var chỉ có một biến i cho cả vòng lặp. Khi callback chạy, vòng lặp đã xong và i bằng 3.
• Đổi sang let thì mỗi vòng lặp có một i riêng, in ra 0, 1, 2.

Ứng dụng thực tế: tạo biến private, hàm factory, debounce, memoize, và các hook trong React.

Hay sai: closure giữ tham chiếu đến biến chứ không chụp lại giá trị. Closure giữ object lớn quá lâu (ví dụ trong listener không gỡ) cũng là nguồn rò rỉ bộ nhớ.

Với function thường, this phụ thuộc vào cách gọi, không phải nơi định nghĩa:

• obj.method(): this là obj.
• Gọi hàm trơn fn(): undefined trong strict mode (module và class luôn là strict).
• new Fn(): object mới được tạo.
• fn.call(x), fn.apply(x), fn.bind(x): this là x.

Arrow function không có this riêng; nó lấy this của phạm vi bao ngoài. Arrow function cũng không có arguments và không dùng được với new.

const btn = { label: "OK", click() { setTimeout(() => console.log(this.label)); } };

Hay sai: truyền obj.method làm callback (setTimeout(obj.method)) rồi mất this. Cách sửa: bind, hoặc bọc trong arrow function.

JavaScript chạy trên một thread. Code đồng bộ chạy hết trên call stack trước, sau đó event loop lấy việc từ hàng đợi. Microtask (Promise .then, await, queueMicrotask) luôn được chạy hết trước khi sang macrotask tiếp theo (setTimeout, sự kiện I/O, sự kiện người dùng).

console.log(1);
setTimeout(() => console.log(2));
Promise.resolve().then(() => console.log(3));
console.log(4);
// 1, 4, 3, 2

• Trên trình duyệt, việc render thường diễn ra giữa các macrotask.
• Một vòng lặp đồng bộ dài, hoặc chuỗi microtask không dứt, sẽ làm treo giao diện.

Người phỏng vấn muốn nghe: setTimeout(fn, 0) không chạy ngay mà chỉ được xếp hàng, và vì sao microtask được ưu tiên.

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.