Kỹ sư Tự động hóa (Embedded, C#, C++, Smart Home)

Undefined behavior (UB) là những thao tác mà chuẩn ngôn ngữ không quy định kết quả. Compiler được phép giả định UB không bao giờ xảy ra và tối ưu theo giả định đó, nên lỗi có thể chỉ lộ ra ở bản build -O2 hoặc trên một compiler khác.

Ví dụ hay gặp:

• Tràn số nguyên có dấu (tràn số không dấu thì được định nghĩa là quay vòng).
• Truy cập mảng ngoài phạm vi, dereference con trỏ null hoặc dangling.
• Đọc biến chưa khởi tạo, data race giữa các thread.
• Vi phạm strict aliasing, vd. ép float* sang int* rồi đọc (nên dùng memcpy hoặc std::bit_cast từ C++20).

Phát hiện: bật cảnh báo -Wall -Wextra, chạy test với -fsanitize=address,undefined, dùng static analysis (clang-tidy, cppcheck, MISRA checker).

Người phỏng vấn muốn nghe: "chạy đúng trên máy tôi" không chứng minh code không có UB.

Cần thu thập dấu vết từ thiết bị trước, sau đó tái hiện trong phòng lab.

• Lưu nguyên nhân reset: đọc thanh ghi reset cause (watchdog, brown-out, hard fault) khi khởi động và ghi vào flash hoặc gửi log lên.
• Hard fault handler: lưu các thanh ghi PC, LR và stack frame để biết lệnh gây lỗi, sau đó tra file .map hoặc addr2line.
• Stack overflow: bật kiểm tra stack của RTOS, tô mẫu (stack painting) để đo mức dùng tối đa.
• Watchdog: chỉ "đá" watchdog khi mọi task quan trọng còn sống, không đá trong ISR timer.
• Kiểm tra phần cứng: nguồn sụt áp, nhiễu, nhiệt độ.

Trong lab dùng JTAG/SWD với GDB, logic analyzer và chạy stress test dài.

Người phỏng vấn muốn nghe: một ca thật bạn đã xử lý, cách khoanh vùng và cách chứng minh đã sửa đúng.

Dữ liệu chia sẻ giữa các thread mà có ít nhất một thread ghi thì phải đồng bộ, nếu không là data race (undefined behavior).

• std::mutex với std::lock_guard hoặc std::scoped_lock (khoá nhiều mutex không deadlock): dùng cho vùng găng có nhiều biến hoặc logic phức tạp.
• std::atomic<T>: cho biến đơn lẻ như cờ, bộ đếm, không cần khoá.
• Memory order: mặc định seq_cst an toàn nhất. acquire/release dùng cho mẫu producer/consumer; relaxed chỉ cho bộ đếm thống kê không cần thứ tự.
• C++20 bổ sung std::jthread (tự join, có stop token), std::latch, std::barrier, std::counting_semaphore.

std::atomic<int> hits{0};
hits.fetch_add(1, std::memory_order_relaxed);

Hay sai: dùng memory order yếu khi chưa thật hiểu, hoặc lock-free hoá sớm khi mutex đã đủ nhanh. Kiểm tra bằng ThreadSanitizer.

Hai hướng chính: optimistic concurrency (phát hiện xung đột khi lưu) và pessimistic (khoá trước khi sửa).

Optimistic với EF Core: đánh dấu một cột làm concurrency token, EF thêm điều kiện so sánh vào UPDATE và ném DbUpdateConcurrencyException nếu không có dòng nào bị cập nhật.

public class Product {
    public int Stock { get; set; }
    [Timestamp] public byte[] RowVersion { get; set; } = [];
}

• Bắt exception, tải lại dữ liệu, rồi retry hoặc báo người dùng.
• PostgreSQL thường dùng cột hệ thống xmin làm token.
• Trường hợp đơn giản như trừ tồn kho có thể dùng một câu ExecuteUpdateAsync atomic kèm điều kiện Stock >= qty.

Người phỏng vấn muốn nghe: bạn cân nhắc mức độ tranh chấp: thấp thì optimistic, cao và nghiệp vụ quan trọng thì khoá hoặc đưa vào hàng đợi.

Bắt đầu bằng đo đạc (load test, APM, profiler), sau đó xử lý các điểm nghẽn phổ biến theo thứ tự tác động.

• I/O: async xuyên suốt, không sync-over-async; dùng connection pool đúng cách.
• Database: projection, AsNoTracking, index đúng, tránh N+1; với bulk update dùng ExecuteUpdateAsync.
• Cache: IMemoryCache, distributed cache (Redis), HybridCache từ .NET 9, output caching cho response công khai.
• Cấp phát bộ nhớ: giảm object tạm trong hot path, dùng Span<T>, ArrayPool, System.Text.Json với source generator.
• Hạ tầng: response compression, rate limiting middleware, scale ngang khi stateless.

Luôn so sánh số liệu trước và sau (p95 latency, throughput, CPU, GC). Micro-optimize nên đo bằng BenchmarkDotNet.

Hay sai: tối ưu code C# trong khi 90% thời gian nằm ở query DB.

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.

Tách phần phụ thuộc phần cứng ra sau một lớp trừu tượng, để logic nghiệp vụ chạy và test được trên máy tính.

• Phân lớp: driver thanh ghi / HAL → BSP → service (giao thức, lưu trữ) → application.
• Dependency inversion: application phụ thuộc interface (struct chứa con trỏ hàm trong C, abstract class hoặc template trong C++), không gọi thẳng thanh ghi.
• Single responsibility: mỗi module một việc, như đọc cảm biến, lọc tín hiệu, gửi dữ liệu.
• Unit test trên host với Unity, CppUTest hoặc GoogleTest bằng driver giả; test trên phần cứng (HIL) cho phần còn lại.
• Máy trạng thái (state machine) rõ ràng cho logic phức tạp.
• CI build nhiều target, chạy static analysis và kiểm tra theo chuẩn code (vd. MISRA).

Người phỏng vấn muốn nghe: bạn cân đối được giữa trừu tượng hoá và giới hạn RAM, flash, thời gian thực.

Con trỏ là biến chứa địa chỉ, có thể nullptr và trỏ sang đối tượng khác. Tham chiếu là tên gọi khác của một đối tượng đã tồn tại, phải khởi tạo ngay và không gán lại được.

int x = 1, y = 2;
int* p = &x;  p = &y;   // đổi đối tượng được trỏ
int& r = x;   r = y;    // gán giá trị y cho x

• Truyền tham số: dùng const T& cho đối tượng lớn chỉ đọc, T& khi cần sửa, con trỏ khi tham số có thể vắng mặt.
• Có con trỏ tới con trỏ và phép toán số học trên con trỏ; tham chiếu thì không.

Hay sai: trả về tham chiếu hoặc con trỏ tới biến cục bộ. Biến bị huỷ khi hàm kết thúc và dùng nó là undefined behavior.

Stack chứa biến cục bộ, cấp phát và giải phóng tự động theo phạm vi hàm, rất nhanh nhưng kích thước nhỏ. Heap cấp phát động (new/malloc), sống đến khi giải phóng thủ công, linh hoạt nhưng chậm hơn và dễ phân mảnh.

• Memory leak: cấp phát trên heap mà không giải phóng, bộ nhớ tăng dần. Trên thiết bị nhúng chạy lâu ngày đây là lỗi chết người.
• Dangling pointer: con trỏ vẫn giữ địa chỉ của vùng nhớ đã giải phóng hoặc biến đã hết phạm vi.
• Double free: giải phóng một vùng hai lần.

Phòng tránh: dùng RAII và smart pointer trong C++, đặt con trỏ về NULL sau free trong C, kiểm tra bằng AddressSanitizer hoặc Valgrind.

Người phỏng vấn muốn nghe (nhúng): nhiều hệ thống hạn chế hoặc cấm cấp phát động sau khi khởi động, dùng memory pool hoặc mảng tĩnh.

Trả lời thẳng thắn và cân bằng: sẵn sàng khi thật sự cần, nhưng không coi OT kéo dài là bình thường.

Câu mẫu: "Em sẵn sàng làm thêm khi có việc gấp như sự cố production hay trước một đợt release quan trọng. Nhưng nếu OT diễn ra thường xuyên, em nghĩ cần xem lại cách estimate hoặc phạm vi, và em sẽ chủ động nêu điều đó với team. Em cũng muốn hỏi thêm: ở team mình OT thường xảy ra trong trường hợp nào và được tính như thế nào ạ?"

Đây cũng là lúc bạn tìm hiểu ngược: OT có được trả lương hoặc nghỉ bù theo quy định không, tần suất ra sao. Câu trả lời của họ cho bạn biết nhiều về văn hoá công ty.

Hay sai: hứa "OT thoải mái" để lấy điểm, rồi vào làm mới thấy không chịu nổi.