Audio Engineer (Embedded / Linux / Android)

volatile báo cho compiler rằng giá trị biến có thể thay đổi ngoài luồng code hiện tại, nên mỗi lần truy cập phải đọc hoặc ghi thật vào bộ nhớ, không được tối ưu bỏ hay cache vào thanh ghi.

Dùng cho:

• Thanh ghi phần cứng ánh xạ bộ nhớ (memory-mapped register).
• Biến chia sẻ giữa ISR (hàm phục vụ ngắt) và vòng lặp chính.

volatile bool data_ready = false;
void UART_IRQHandler(void) { data_ready = true; }
while (!data_ready) { }  // không có volatile có thể thành lặp vô hạn

Hay sai: nghĩ volatile đảm bảo thread-safe hoặc atomic. Nó không chống race condition và không tạo memory barrier giữa các core; cần atomic, tắt ngắt hoặc mutex.

Bốn tính chất: đóng gói (ẩn dữ liệu sau interface), kế thừa, đa hình (gọi cùng interface, hành vi theo kiểu thật) và trừu tượng (chỉ lộ cái cần thiết).

Đa hình lúc chạy trong C++ dùng virtual: mỗi class có hàm ảo có một bảng vtable chứa địa chỉ hàm, mỗi object giữ một con trỏ vptr tới bảng đó. Gọi qua con trỏ hoặc tham chiếu lớp cha sẽ tra vtable để gọi hàm của lớp con.

struct Sensor { virtual ~Sensor() = default; virtual int read() = 0; };
struct TempSensor : Sensor { int read() override { return 25; } };

Hay sai: quên destructor ảo ở lớp cha, khi delete qua con trỏ lớp cha sẽ không gọi destructor lớp con. Trên nhúng cũng nên nhắc chi phí: thêm vptr cho mỗi object và một lần gọi gián tiếp.

RAII (Resource Acquisition Is Initialization): gắn tài nguyên vào vòng đời một object; constructor lấy tài nguyên, destructor tự giải phóng. Nhờ vậy không rò rỉ kể cả khi có exception hoặc return sớm.

• unique_ptr: sở hữu duy nhất, chỉ move được, không tốn thêm chi phí so với con trỏ thường. Nên là lựa chọn mặc định.
• shared_ptr: sở hữu chung bằng bộ đếm tham chiếu (cập nhật atomic), giải phóng khi bộ đếm về 0.
• weak_ptr: quan sát một shared_ptr mà không tăng bộ đếm, dùng phá vòng tham chiếu (vd. con trỏ ngược từ con về cha).

auto dev = std::make_unique<Device>("/dev/i2c-1");

Hay sai: dùng shared_ptr khắp nơi "cho an toàn", làm mờ quyền sở hữu và tốn chi phí atomic.

Đi từ gần ra xa và từ tầng thấp lên cao, mỗi bước loại trừ một khả năng.

ip a                 # hoặc ipconfig /all: có IP, gateway, DNS?
ping <gateway>       # mạng nội bộ ổn?
ping 1.1.1.1         # ra Internet được bằng IP?
nslookup example.com # DNS phân giải được?

• Ping IP được mà tên miền không được: lỗi DNS.
• Chỉ một người bị hay cả phòng: cả phòng thì nghi switch, DHCP, đường truyền.
• Chỉ một trang web: proxy, firewall, hoặc chính trang đó.
• Dùng tracert/traceroute để xem gói dừng ở chặng nào.

Người phỏng vấn muốn nghe: hỏi thêm thông tin trước (ai, từ khi nào, có gì thay đổi).

VLAN chia một switch vật lý thành nhiều mạng L2 logic tách biệt, giúp thu nhỏ vùng broadcast và cô lập các nhóm (kế toán, khách, camera, server).

• Access port: thuộc một VLAN, nối với máy trạm; frame không gắn tag.
• Trunk port: mang nhiều VLAN giữa switch với switch hoặc router, frame gắn tag 802.1Q.
• Các VLAN muốn nói chuyện với nhau phải qua thiết bị L3 (router, switch L3, firewall), nơi có thể đặt ACL.

Hay sai: để Wi-Fi khách chung VLAN với mạng nội bộ, hoặc cho phép mọi VLAN đi qua trunk khi không cần.

Coroutine là tác vụ nhẹ có thể tạm dừng (suspend) mà không chặn thread. suspend fun chỉ gọi được từ coroutine hoặc từ suspend function khác.

• Scope quyết định vòng đời: viewModelScope, lifecycleScope tự huỷ coroutine khi ViewModel hoặc màn hình bị huỷ.
• Dispatcher quyết định chạy ở đâu: Main, IO, Default.
• Structured concurrency: coroutine con gắn với cha; cha huỷ thì con huỷ, con lỗi thì lan lên cha (trừ khi dùng SupervisorJob).

viewModelScope.launch {
    val user = withContext(Dispatchers.IO) { repo.fetchUser() }
    _state.value = UiState.Success(user)
}

Hay sai: dùng GlobalScope gây rò rỉ; bắt CancellationException trong catch (e: Exception) mà không ném lại, làm hỏng cơ chế huỷ.

Move semantics cho phép chuyển tài nguyên (buffer, handle) từ một object tạm hoặc sắp bị bỏ đi sang object khác thay vì sao chép sâu. Rvalue reference T&& nhận các object như vậy; std::move chỉ là phép ép kiểu để cho phép move.

std::vector<int> a(1'000'000);
std::vector<int> b = std::move(a);  // chuyển con trỏ, không chép 1 triệu phần tử

• Rule of 3: nếu tự viết destructor, copy constructor hoặc copy assignment thì gần như phải viết đủ cả ba.
• Rule of 5: thêm move constructor và move assignment.
• Rule of 0: tốt nhất là không tự viết hàm nào, để các thành viên RAII (vector, unique_ptr) lo.

Hay sai: dùng lại object sau khi đã move. Object vẫn hợp lệ nhưng ở trạng thái không xác định.

ISR phải ngắn và nhanh: ghi nhận sự kiện, lấy dữ liệu tối thiểu, rồi để phần xử lý nặng cho task hoặc vòng lặp chính.

• Không gọi hàm có thể block (delay, chờ mutex), không printf, tránh cấp phát động.
• Biến dùng chung với code chính khai báo volatile và truy cập atomic, hoặc tắt ngắt ngắn khi đọc dữ liệu nhiều byte.
• Xoá cờ ngắt đúng cách để không bị gọi lại liên tục.
• Với RTOS, chỉ dùng API dành cho ngắt (vd. hàm có hậu tố FromISR trong FreeRTOS) để báo task qua semaphore, queue hoặc task notification.
• Dùng ring buffer cho dữ liệu đến liên tục như UART.

Người phỏng vấn muốn nghe: bạn biết về độ ưu tiên ngắt, ngắt lồng nhau, và cách đo thời gian chạy ISR bằng cách bật tắt một chân GPIO rồi xem trên oscilloscope.

Super-loop chạy tuần tự các việc trong một vòng while(1), đơn giản nhưng một việc chậm sẽ làm trễ mọi việc khác. RTOS có scheduler preemptive theo độ ưu tiên, giúp các việc cần thời gian thực được đáp ứng đúng hạn.

• Mutex: khoá loại trừ cho tài nguyên dùng chung, có khái niệm sở hữu (ai khoá thì người đó mở) và thường có priority inheritance để giảm đảo ưu tiên.
• Binary semaphore: dùng để báo hiệu giữa ISR và task hoặc giữa các task, không có sở hữu.
• Counting semaphore: quản lý N tài nguyên giống nhau.

Hay sai: dùng semaphore thay mutex để bảo vệ tài nguyên, gặp priority inversion: task ưu tiên cao chờ task thấp đang giữ khoá, trong khi task trung bình chiếm CPU.

Người phỏng vấn muốn nghe: bạn biết đặt độ ưu tiên task và kích thước stack hợp lý, và từng phát hiện stack overflow.

Luôn có câu hỏi. Đây là cơ hội thể hiện sự quan tâm và cũng là lúc bạn đánh giá công ty.

Câu hỏi nên chuẩn bị (chọn 2–3 câu hợp với người đang phỏng vấn):

• "Một ngày làm việc của vị trí này thường như thế nào? Team có bao nhiêu người, gồm những vai trò gì?"
• "Ba tháng đầu, anh/chị kỳ vọng người vào vị trí này làm được gì?"
• "Team đang gặp thách thức kỹ thuật hoặc quy trình nào lớn nhất?"
• "Quy trình release và code review của team ra sao?"
• "Công ty đánh giá hiệu suất và review lương theo chu kỳ nào?"
• "Vì sao vị trí này đang tuyển: mở rộng team hay thay người?"

Hay sai: "Dạ không ạ", hoặc chỉ hỏi về nghỉ phép, lương thưởng ngay ở vòng kỹ thuật. Chuyện chế độ nên hỏi kỹ với HR.