[Remote] Unity Developer (WebGL / C# / JavaScript)

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

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.

Interface mô tả khả năng (hợp đồng) mà nhiều kiểu không liên quan có thể cùng thực hiện; abstract class là lớp cha dùng chung code và trạng thái cho một họ lớp gần nhau.

• Một class implement nhiều interface nhưng chỉ kế thừa một class.
• Abstract class có field, constructor, method có sẵn thân.
• Từ C# 8 interface có default implementation, nhưng vẫn không có field trạng thái.

Dùng interface cho các phụ thuộc cần thay thế hoặc mock trong test (IEmailSender, IOrderRepository). Dùng abstract class khi các lớp con thật sự chia sẻ logic, vd. BaseHandler xử lý log và retry chung.

Người phỏng vấn muốn nghe: bạn ưu tiên composition và interface, chỉ dùng kế thừa khi có quan hệ "là một" rõ ràng.

IQueryable giữ biểu thức truy vấn (expression tree) để provider như EF Core dịch thành SQL chạy trên DB. IEnumerable chạy LINQ trong bộ nhớ trên dữ liệu đã tải về.

// Lọc trong SQL: chỉ tải đơn đã thanh toán
var paid = db.Orders.Where(o => o.Status == Status.Paid).ToList();

// Tải cả bảng rồi mới lọc trong RAM
IEnumerable<Order> all = db.Orders;
var paid2 = all.Where(o => o.Status == Status.Paid).ToList();

• Cả hai đều deferred execution: chỉ chạy khi duyệt hoặc gọi ToList(), Count(), First()...
• Duyệt cùng một IEnumerable lazy nhiều lần có thể chạy truy vấn nhiều lần.

Hay sai: gọi ToList() hoặc AsEnumerable() quá sớm rồi mới lọc, phân trang, khiến tải cả bảng về.

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.

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

ASP.NET Core có DI container sẵn; lifetime quyết định khi nào tạo instance mới.

• Transient: mỗi lần resolve tạo mới. Hợp với service nhẹ, không trạng thái.
• Scoped: một instance cho mỗi request (mỗi scope). DbContext mặc định là scoped.
• Singleton: một instance cho cả vòng đời ứng dụng. Phải thread-safe.

builder.Services.AddScoped<IOrderService, OrderService>();
builder.Services.AddSingleton<IClock, SystemClock>();

Hay sai: inject service scoped (như DbContext) vào singleton, gọi là captive dependency: DbContext bị giữ mãi và dùng chung giữa nhiều thread. Môi trường Development sẽ báo lỗi khi validate scope. Nếu singleton cần dữ liệu scoped, hãy inject IServiceScopeFactory và tự tạo scope.

Chọn một hai điểm mạnh liên quan tới vị trí, và chứng minh bằng ví dụ thật, không liệt kê tính từ.

Cấu trúc: điểm mạnh, ví dụ ngắn, kết quả, liên hệ với công việc mới.

Câu mẫu: "Điểm mạnh của em là chủ động tìm nguyên nhân gốc. Ở dự án trước, hệ thống thỉnh thoảng bị timeout mà không ai tái hiện được. Em tự đọc log, thêm theo dõi ở các điểm nghi ngờ và tìm ra một truy vấn bị khoá bảng vào giờ cao điểm. Sau khi sửa, lỗi đó không còn xuất hiện. Em nghĩ điều này hữu ích với vị trí bên mình vì hệ thống có lượng truy cập lớn."

Hay sai: "Em chăm chỉ, ham học hỏi, chịu được áp lực" mà không có ví dụ. Ai cũng nói vậy nên không đọng lại gì.