App nhỏ không cần kiến trúc phức tạp vẫn chạy tốt, nhưng khi app lớn dần, thiếu kiến trúc rõ ràng sẽ khiến code khó test, khó maintain, khó thêm tính năng mới mà không phá vỡ tính năng cũ — nhà tuyển dụng dùng câu hỏi kiến trúc để đánh giá tầm nhìn dài hạn.
"MVVM giải quyết vấn đề gì so với MVC truyền thống?" — MVC (đặc biệt ở mobile) thường dẫn tới "Massive View Controller" — Controller ôm đồm cả logic hiển thị lẫn business logic, khó test vì gắn chặt với UI framework. MVVM tách ViewModel ra khỏi View, ViewModel không phụ thuộc trực tiếp vào UI framework nên test được độc lập (unit test) mà không cần chạy UI thật.
"ViewModel giao tiếp với View bằng cách nào mà không tham chiếu trực tiếp?" — Qua data binding hoặc observable pattern (LiveData/StateFlow ở Android, Combine/@Published ở iOS, ValueNotifier/Stream ở Flutter) — View "lắng nghe" thay đổi từ ViewModel, ViewModel không cần biết View là ai, giữ hướng phụ thuộc 1 chiều rõ ràng.
"Clean Architecture chia layer thế nào và nguyên tắc phụ thuộc ra sao?" — Thường chia 3 layer chính: Presentation (UI/ViewModel), Domain (business logic thuần, không phụ thuộc framework nào — chứa Use Case/Entity), Data (nguồn dữ liệu — API, database local). Nguyên tắc quan trọng: dependency luôn hướng vào trong (Presentation phụ thuộc Domain, Data phụ thuộc Domain) — Domain layer không biết gì về Presentation hay Data, giúp business logic độc lập hoàn toàn với chi tiết kỹ thuật bên ngoài.
"Lợi ích thực tế của việc tách Domain layer độc lập là gì?" — Business logic test được mà không cần mock UI framework hay database thật, và có thể đổi nguồn dữ liệu (vd. từ REST API sang GraphQL) mà không ảnh hưởng business logic, chỉ cần đổi implementation ở Data layer.
"App hiện tại không có kiến trúc rõ ràng, code dồn hết vào 1 file lớn — bạn refactor thế nào mà không làm gián đoạn phát triển tính năng mới?" — Câu trả lời tốt nhấn mạnh refactor từng bước (incremental), bắt đầu từ phần code hay thay đổi/dễ gây bug nhất, không "big bang rewrite" toàn bộ 1 lần dễ gây rủi ro và trễ deadline.
Nếu từng áp dụng kiến trúc cụ thể trong dự án thật, kể rõ: lý do chọn kiến trúc đó (không phải vì trend), khó khăn gặp phải khi áp dụng (đặc biệt nếu team chưa quen), và lợi ích đo được sau khi áp dụng (thời gian viết test giảm, thời gian debug bug giảm).