50 câu hỏi phỏng vấn Frontend Developer thường gặp

Không ít Frontend Developer bước vào buổi phỏng vấn với tâm thế khá tự tin vì đã từng làm dự án, quen tay với React hoặc các framework phổ biến. Thế nhưng, khi buổi phỏng vấn đi sâu vào cách xử lý UI, hành vi của browser, state hay các tình huống thực tế, nhiều người lại lúng túng và trả lời rời rạc, dù kiến thức không hề thiếu.

Vấn đề thường không nằm ở việc bạn không biết, mà ở chỗ bạn chưa quen trả lời đúng thứ nhà tuyển dụng đang tìm. Phỏng vấn Frontend hiếm khi kiểm tra bạn nhớ cú pháp, mà tập trung vào cách bạn hiểu luồng chạy của ứng dụng, cách bạn xử lý lỗi UI và cách bạn giữ trải nghiệm người dùng ổn định trong các tình huống không lý tưởng.

Bài viết này tổng hợp 50 câu hỏi phỏng vấn Frontend Developer thường gặp, được sắp xếp theo đúng những nhóm mà interviewer hay khai thác nhất. Mỗi câu hỏi đi kèm định hướng trả lời giúp bạn hình dung nên nói gì, nói tới đâu là đủ, và làm sao để câu trả lời phản ánh đúng trải nghiệm của chính bạn, thay vì học thuộc một đáp án có sẵn.

Tham khảo thêm bộ câu hỏi cho lập trình viên Fullstack tại đây.

Phỏng vấn Frontend Developer thường đánh giá những kỹ năng nào?

Khi phỏng vấn Frontend, nhà tuyển dụng thường không chỉ quan tâm bạn dùng framework gì hay đã làm bao nhiêu dự án. Điều họ muốn đánh giá sâu hơn là cách bạn hiểu và kiểm soát hành vi của giao diện khi chạy trên trình duyệt, cũng như khả năng xử lý các tình huống thực tế phát sinh trong quá trình phát triển sản phẩm.

Ở vòng technical, các câu hỏi Frontend thường xoay quanh ba trục chính. Thứ nhất là nền tảng JavaScript và cách mã nguồn thực sự được thực thi trong browser, vì đây là gốc rễ của mọi hành vi UI. Thứ hai là tư duy xây dựng giao diện và quản lý state, nơi bạn thể hiện khả năng tổ chức component, dữ liệu và luồng tương tác một cách rõ ràng, dễ bảo trì. Cuối cùng là kinh nghiệm xử lý lỗi và tối ưu trải nghiệm người dùng, đặc biệt trong các tình huống như UI chậm, dữ liệu không đồng bộ, hoặc lỗi chỉ xuất hiện sau khi deploy.

Chính vì vậy, một câu trả lời tốt trong phỏng vấn Frontend thường không cần quá dài, nhưng phải có mạch rõ ràng: bạn hiểu vấn đề gì, bạn sẽ kiểm tra gì trước, và vì sao bạn chọn hướng xử lý đó. Khi bạn trả lời theo tư duy này, interviewer sẽ dễ dàng nhận ra bạn là người có thể làm việc hiệu quả trong môi trường thực tế, thay vì chỉ biết ghép các mảnh code lại với nhau.

50 câu hỏi phỏng vấn cho Frontend Developer hấp dẫn

Câu hỏi về JavaScript

Trong phỏng vấn Frontend, JavaScript thường được dùng để kiểm tra cách bạn hiểu hành vi thực thi của mã nguồn trong trình duyệt, chứ không phải để bắt bạn nhớ cú pháp. Interviewer sẽ lắng nghe cách bạn lý giải luồng chạy, xử lý bất đồng bộ và những lỗi UI phát sinh từ JavaScript, vì đây là nền tảng ảnh hưởng trực tiếp tới trải nghiệm người dùng.

1. Scope trong JavaScript ảnh hưởng gì tới bug UI?

Câu hỏi này giúp interviewer đánh giá khả năng bạn kiểm soát phạm vi biến và tránh lỗi khó debug.

• Phân biệt phạm vi của biến trong function và block khi viết logic UI.
• Nhận diện các bug do biến bị ghi đè hoặc dùng sai phạm vi.
• Thể hiện thói quen đặt biến và cấu trúc code rõ ràng để tránh side effect.

2. Closure là gì và bạn đã từng dùng nó trong Frontend ra sao?

Interviewer muốn biết bạn không chỉ hiểu khái niệm mà còn biết áp dụng vào UI thực tế.

• Mô tả cách closure giữ lại trạng thái giữa các lần render hoặc tương tác.
• Nêu tình huống thường gặp như handler, debounce, hoặc custom hook.
• Nhận diện rủi ro giữ reference không cần thiết gây memory leak.

3. Hoisting hay gây lỗi khó debug ở những tình huống nào?

Câu này nhằm kiểm tra khả năng đọc và dự đoán hành vi code trước khi chạy.

• Phân biệt hành vi hoisting của var so với let và const.
• Nêu các bug thường gặp khi biến hoặc hàm được dùng trước khi khai báo.
• Thể hiện thói quen viết code giúp tránh hiểu nhầm thứ tự thực thi.

4. Event loop liên quan gì tới UI bị delay hoặc click không ăn?

Interviewer muốn xem bạn hiểu mối liên hệ giữa bất đồng bộ và phản hồi UI.

• Mô tả cách task được đưa vào hàng đợi và thực thi.
• Nhận diện tình huống main thread bị block khiến UI không phản hồi.
• Thể hiện cách tránh chạy tác vụ nặng trên luồng chính của trình duyệt.

5. Promise và async/await khác nhau ở cách xử lý lỗi?

Câu hỏi này kiểm tra khả năng bạn kiểm soát lỗi bất đồng bộ một cách rõ ràng.

• Nêu cách bắt lỗi trong promise chain và async/await.
• Nhận diện những lỗi dễ bị bỏ sót khi không bao bọc đúng phạm vi.
• Thể hiện cách viết code giúp luồng xử lý dễ đọc và dễ debug hơn.

6. Race condition trong Frontend thường xảy ra khi nào?

Interviewer muốn biết bạn có từng gặp lỗi do nhiều tác vụ bất đồng bộ chạy chồng chéo.

• Nhận diện tình huống nhiều request cập nhật cùng một state UI.
• Thể hiện cách kiểm soát thứ tự cập nhật dữ liệu.
• Nêu cách tránh hiển thị dữ liệu cũ hoặc sai trên giao diện.

7. Tham chiếu và giá trị gây bug state như thế nào?

Câu này giúp phân biệt người hiểu cách dữ liệu thay đổi và người chỉ update cho chạy.

• Phân biệt truyền tham chiếu và truyền giá trị trong JavaScript.
• Nhận diện bug UI khi mutate object hoặc array trực tiếp.
• Thể hiện thói quen sao chép dữ liệu trước khi cập nhật state.

8. Immutability quan trọng ra sao trong render UI?

Interviewer dùng câu này để đánh giá tư duy quản lý state ổn định.

• Nêu mối liên hệ giữa immutability và việc phát hiện thay đổi.
• Thể hiện cách immutability giúp tránh render sai hoặc thiếu render.
• Nhận diện trade-off khi dữ liệu lớn và cần tối ưu.

9. Shallow copy và deep copy khác nhau ở đâu khi update state?

Câu hỏi này kiểm tra khả năng bạn tránh bug liên quan cấu trúc dữ liệu lồng nhau.

• Phân biệt phạm vi sao chép của từng cách.
• Nhận diện bug khi chỉ copy bề mặt nhưng mutate bên trong.
• Thể hiện cách chọn phương án phù hợp với độ phức tạp của state.

10. == và === có thể gây lỗi gì trong Frontend?

Interviewer muốn biết bạn hiểu so sánh kiểu dữ liệu ảnh hưởng logic UI ra sao.

• Nêu sự khác biệt trong so sánh giá trị và kiểu.
• Nhận diện bug do ép kiểu ngầm định.
• Thể hiện nguyên tắc nhất quán khi viết điều kiện trong UI.

11. Khi nào nên tránh mutate object hoặc array trực tiếp?

Câu hỏi này đánh giá khả năng bạn giữ logic UI dễ đoán.

• Nêu các tình huống mutate gây side effect khó lường.
• Thể hiện cách cập nhật dữ liệu an toàn hơn.
• Nhận diện trường hợp mutate có thể chấp nhận được nếu kiểm soát rõ.

12. Bạn debug lỗi JavaScript trên trình duyệt theo hướng nào?

Interviewer muốn nghe quy trình debug rõ ràng, không mò mẫm.

• Bắt đầu từ việc tái hiện lỗi và quan sát hành vi UI.
• Sử dụng log, breakpoint và công cụ devtools một cách có mục tiêu.
• Thu hẹp phạm vi nguyên nhân thay vì sửa thử nhiều chỗ.

Câu hỏi về Browser, DOM và cơ chế render

Nhiều ứng viên Frontend trả lời React rất ổn nhưng lại hụt hơi ở phần browser, DOM và cơ chế render, đơn giản vì họ quen làm qua framework nên ít khi phải gọi tên đúng vấn đề. Tuy nhiên, với interviewer, đây lại là nhóm câu hỏi cực quan trọng để xác định bạn có hiểu giao diện chạy thật sự ra sao, cũng như có đủ nền để xử lý các bug khó chịu như lag UI, click không ăn, layout nhảy hoặc memory tăng dần.

13. Browser render một trang web theo các bước nào?

Câu này kiểm tra bạn có tư duy tổng quan về luồng render, không cần quá chi tiết nhưng phải có mạch.

• Nêu trình tự ở mức high-level từ parse HTML/CSS tới layout và paint.
• Thể hiện bạn hiểu vì sao thay đổi CSS hoặc DOM có thể làm UI chậm.
• Nối được kiến thức này với cách bạn debug hoặc tối ưu trong dự án.

14. Reflow và repaint là gì, và khi nào chúng làm UI chậm thấy rõ?

Interviewer muốn biết bạn hiểu nguyên nhân lag UI ở những tình huống rất đời thường.

• Phân biệt reflow liên quan layout và repaint liên quan vẽ lại.
• Nhận diện các thao tác thường gây reflow nhiều: đo kích thước, thay đổi layout liên tục.
• Thể hiện cách bạn giảm reflow bằng cách gom thay đổi hoặc hạn chế đo layout trong vòng lặp.

15. DOM và Virtual DOM khác nhau ở góc nhìn thực dụng của Frontend?

Câu hỏi này không nhằm bắt bạn thuộc định nghĩa, mà để xem bạn hiểu hiệu ứng thực tế.

• Nêu DOM là cấu trúc thật trong browser, còn Virtual DOM là cách framework tối ưu cập nhật.
• Thể hiện bạn hiểu Virtual DOM không tự động làm mọi thứ nhanh, vẫn có thể chậm nếu render quá nhiều.
• Liên hệ tới việc tối ưu render ở component hoặc danh sách lớn.

16. Event bubbling và capturing là gì, và bạn đã từng gặp bug liên quan chưa?

Interviewer muốn nghe bạn hiểu event propagation và biết dùng nó để xử lý UI.

• Giải thích mạch lan truyền event theo hai chiều.
• Nêu tình huống thực tế như click trong modal, dropdown, nested component.
• Thể hiện bạn biết khi nào cần stopPropagation và khi nào không nên lạm dụng.

17. Khi addEventListener nhiều lần, rủi ro nào dễ xảy ra nhất?

Câu này giúp đánh giá ý thức về memory leak và hành vi lặp event khó chịu.

• Nêu nguy cơ handler bị gắn trùng khiến một thao tác chạy nhiều lần.
• Thể hiện bạn biết cần cleanup khi component unmount hoặc khi effect chạy lại.
• Nhắc tới cách kiểm tra nhanh bằng devtools hoặc log để xác nhận handler bị nhân đôi.

18. Debounce và throttle khác nhau thế nào, bạn dùng trong tình huống UI nào?

Interviewer kiểm tra khả năng kiểm soát tần suất xử lý sự kiện trong UI.

• Phân biệt debounce phù hợp input search, throttle phù hợp scroll/resize.
• Thể hiện bạn hiểu mục tiêu là giảm số lần chạy logic nặng và giảm call API.
• Nhắc tới việc chọn thời gian trễ hợp lý để không làm UX tệ đi.

19. requestAnimationFrame khác setTimeout ở điểm nào khi làm animation?

Câu này nhằm đánh giá bạn hiểu cách browser vẽ frame và tối ưu chuyển động.

• Nêu requestAnimationFrame đồng bộ theo frame render của browser.
• Thể hiện bạn hiểu setTimeout có thể lệch nhịp khiến animation giật.
• Liên hệ tới việc dùng requestAnimationFrame để cập nhật UI mượt hơn khi có animation hoặc hiệu ứng.

20. Khi DOM update rồi nhưng UI vẫn không phản ánh như bạn mong đợi, bạn nghi ngờ gì?

Interviewer muốn nghe cách bạn khoanh vùng thay vì đoán ngẫu nhiên.

• Xem lại CSS: visibility, display, z-index, overflow, specificity.
• Kiểm tra xem state UI và dữ liệu hiển thị có bị stale hoặc update sai thời điểm không.
• Thể hiện cách bạn dùng devtools để xác nhận DOM thực tế đã đổi hay chưa.

21. Browser cache ảnh hưởng tới trải nghiệm người dùng và bug sau deploy như thế nào?

Câu này kiểm tra hiểu biết về vấn đề rất hay gặp khi release.

• Nêu tình huống người dùng thấy giao diện cũ do cache static assets.
• Thể hiện bạn biết cách xử lý bằng versioning hoặc cache-control phù hợp.
• Nhắc tới việc khi debug cần kiểm tra hard reload hoặc kiểm tra network cache.

22. Bạn debug bug liên quan browser theo trình tự nào để không bị lan man?

Interviewer muốn thấy bạn có quy trình rõ ràng khi gặp lỗi UI chỉ xảy ra ở một môi trường.

• Xác định môi trường lỗi: browser nào, thiết bị nào, điều kiện nào tái hiện được.
• So sánh khác biệt: kích thước màn hình, extension, chế độ private, cache.
• Thu hẹp phạm vi bằng cách kiểm tra log, devtools, và thử cô lập phần UI gây lỗi.

Câu hỏi về HTML & CSS 

HTML và CSS là phần nhiều ứng viên nghĩ rằng dễ, nên thường chủ quan, tới lúc phỏng vấn lại trả lời khá cảm tính. Trong khi đó, interviewer thường dùng nhóm này để kiểm tra bạn có từng làm UI thật hay chưa: có hiểu layout hoạt động ra sao, có biết vì sao giao diện vỡ, và quan trọng nhất là có biết cách debug CSS nhanh gọn trong tình huống thực tế.

23. Box model gồm những gì và nó ảnh hưởng layout ra sao?

Câu này giúp interviewer đánh giá nền tảng layout của bạn có chắc không.

• Nêu các lớp chính và cách chúng cộng dồn kích thước.
• Liên hệ với bug thường gặp: element bị tràn, canh lệch, không đúng kích thước mong muốn.
• Thể hiện thói quen kiểm tra bằng devtools để nhìn đúng box model thay vì đoán.

24. display: block, inline, inline-block khác nhau thế nào trong thực tế?

Interviewer muốn xem bạn hiểu hành vi hiển thị và cách chúng ảnh hưởng bố cục.

• Phân biệt cách mỗi loại chiếm chỗ và nhận kích thước.
• Nêu tình huống thực tế: canh icon với text, button, menu ngang.
• Thể hiện bạn biết khi nào nên chuyển sang flex thay vì cố xử lý bằng inline-block.

25. Flexbox và Grid: bạn chọn cái nào trong trường hợp nào?

Câu này nhằm đánh giá bạn biết chọn công cụ phù hợp thay vì dùng một thứ cho mọi layout.

• Nêu flex phù hợp layout một chiều, grid phù hợp layout hai chiều.
• Liên hệ với các bài toán UI: card list, dashboard, form nhiều cột.
• Thể hiện bạn ưu tiên đơn giản và dễ maintain thay vì layout quá phức tạp.

26. position: relative, absolute, fixed, sticky khác nhau ra sao?

Interviewer thường hỏi để xem bạn có từng xử lý overlay, dropdown, header cố định.

• Nêu cách mỗi position định vị theo bối cảnh nào.
• Nhận diện bug hay gặp: absolute bị lệch do thiếu parent có relative, sticky không hoạt động do overflow.
• Thể hiện cách bạn debug bằng cách kiểm tra stacking context và container.

27. CSS specificity là gì và vì sao nó hay gây bug khó chịu?

Câu hỏi này kiểm tra khả năng bạn hiểu xung đột style thay vì chỉ thêm !important.

• Nêu nguyên tắc ưu tiên và vì sao selector phức tạp dễ “đè” style khác.
• Nhận diện dấu hiệu: sửa CSS đúng file nhưng UI không đổi.
• Thể hiện cách xử lý bền vững: đơn giản selector, chuẩn hoá quy ước, hạn chế lạm dụng !important.

28. Khi CSS bị override sai, bạn debug theo hướng nào?

Interviewer muốn nghe một quy trình debug CSS rõ, vì đây là kỹ năng đi làm dùng hằng ngày.

• Dùng devtools để xem rule nào đang thắng và đến từ đâu.
• Kiểm tra thứ tự load CSS, scope (module), và specificity.
• Thu hẹp phạm vi bằng cách tắt từng rule hoặc cô lập component.

29. Responsive design bạn thường làm theo cách nào để UI không vỡ?

Câu này đánh giá tư duy xây UI chạy tốt trên nhiều thiết bị, không chỉ chỉnh cho đẹp trên một màn hình.

• Nêu cách tiếp cận: mobile-first hoặc breakpoints theo layout.
• Thể hiện bạn quan tâm tới kích thước thật của nội dung: text dài, ảnh lớn, button nhiều.
• Nhắc tới việc test trên nhiều kích thước và dùng devtools responsive mode thay vì đoán.

30. Accessibility cơ bản trong HTML/CSS gồm những gì?

Interviewer hỏi để xem bạn có ý thức về trải nghiệm người dùng và chuẩn UI tối thiểu.

• Nêu các điểm cơ bản: semantic HTML, label cho form, focus state, contrast.
• Thể hiện bạn hiểu accessibility không chỉ là thêm aria cho có.
• Liên hệ với việc làm UI dễ dùng bằng bàn phím và screen reader ở mức tối thiểu.
  
   

Câu hỏi về React và tư duy xây dựng component

React gần như là nội dung xuất hiện thường xuyên nhất trong phỏng vấn Frontend hiện đại, nhưng điều thú vị là interviewer hiếm khi hỏi bạn thuộc API. Họ muốn nghe cách bạn tổ chức component, quản lý state và kiểm soát re-render, bởi những thứ này mới quyết định codebase có dễ mở rộng, dễ sửa và ít bug hay không.

31. React giải quyết vấn đề gì so với JavaScript thuần?

Câu này giúp interviewer biết bạn hiểu React là một cách tổ chức UI, không chỉ là công cụ dựng giao diện.

• Nêu vấn đề React giải quyết: tách UI thành component, quản lý trạng thái và cập nhật giao diện theo dữ liệu.
• Thể hiện bạn hiểu sự khác biệt giữa thao tác DOM trực tiếp và tư duy declarative.
• Liên hệ với trải nghiệm: UI lớn, nhiều trạng thái, nhiều tương tác thì React giúp code dễ quản lý hơn.

32. State và props khác nhau thế nào trong dự án thật?

Interviewer muốn biết bạn hiểu cách dữ liệu chảy trong UI và biết đặt dữ liệu đúng chỗ.

• Nêu props là dữ liệu truyền xuống, state là dữ liệu nằm trong component hoặc scope quản lý.
• Thể hiện bạn biết tránh nhét mọi thứ vào state nếu không cần.
• Liên hệ với tình huống: dữ liệu dùng chung giữa nhiều component thì nên đặt ở cấp cao hơn.

33. Khi nào component bị re-render?

Câu hỏi này nhằm đánh giá tư duy về hiệu năng và dự đoán hành vi của UI.

• Nêu các nguyên nhân phổ biến: state đổi, props đổi, parent re-render kéo theo child.
• Thể hiện bạn hiểu re-render không luôn xấu, chỉ cần kiểm soát khi nó gây vấn đề.
• Nhắc tới cách nhận diện bằng devtools hoặc profiling khi UI chậm.

34. useState và useRef khác nhau trong trường hợp nào?

Interviewer muốn xem bạn phân biệt được dữ liệu dùng để render và dữ liệu dùng để lưu tham chiếu.

• Nêu useState làm UI cập nhật, useRef giữ giá trị qua render nhưng không kích hoạt render.
• Liên hệ tình huống: lưu timer id, DOM node, hoặc giá trị tạm không cần render lại.
• Thể hiện bạn tránh dùng useRef để “lách” state khiến UI khó đoán.

35. useEffect hay bị dùng sai ở đâu?

Câu này kiểm tra trải nghiệm thật vì useEffect là nơi nhiều bug Frontend xảy ra.

• Nhận diện lỗi phổ biến: chạy quá nhiều lần, dependency sai, gọi API lặp.
• Thể hiện bạn hiểu effect nên dùng cho side-effect, không phải để thay thế logic render.
• Nhắc tới việc tách effect theo mục tiêu để dễ đọc và dễ kiểm soát.

36. Dependency array ảnh hưởng gì tới bug logic?

Interviewer muốn thấy bạn hiểu stale data và vòng lặp vô hạn trong effect.

• Nêu dependency quyết định khi nào effect chạy lại.
• Nhận diện bug: dùng biến trong effect nhưng không đưa vào dependency khiến dữ liệu cũ.
• Thể hiện bạn biết cân nhắc giữa đúng logic và tránh chạy lại không cần thiết.

37. Cleanup function trong useEffect dùng khi nào?

Câu này đánh giá bạn có ý thức dọn dẹp tài nguyên và tránh memory leak.

• Nêu các trường hợp: unsubscribe, clear timer, remove event listener, abort request.
• Liên hệ với bug thực tế: component unmount nhưng event vẫn chạy.
• Thể hiện bạn dùng cleanup để đảm bảo UI không bị cập nhật sau khi đã rời màn hình.

38. Controlled và uncontrolled component khác nhau thế nào?

Interviewer muốn biết bạn quản lý form và input một cách ổn định.

• Nêu controlled: value do state điều khiển, uncontrolled: value nằm trong DOM.
• Liên hệ tình huống: form validation, realtime update, submit dữ liệu.
• Thể hiện bạn chọn cách phù hợp với độ phức tạp của form và yêu cầu UX.

39. Lifting state up là gì và trade-off của nó?

Câu này kiểm tra tư duy thiết kế UI khi nhiều component cần chia sẻ dữ liệu.

• Nêu mục tiêu: đưa state lên component cha để chia sẻ cho các con.
• Trade-off: component cha phình to, props truyền nhiều, dễ props drilling.
• Thể hiện bạn biết khi nào nên dừng và cân nhắc context hoặc state management.

40. Key trong list render quan trọng ra sao? Dùng index có rủi ro gì?

Interviewer dùng câu này để kiểm tra hiểu biết về reconciliation và bug UI khó chịu.

• Nêu key giúp React nhận diện item giữa các lần render.
• Nhận diện rủi ro dùng index khi list thay đổi thứ tự: input nhảy focus, state bị lệch.
• Thể hiện bạn ưu tiên id ổn định và hiểu vì sao nó quan trọng.

41. Bạn tổ chức component thế nào để dễ maintain?

Câu này đánh giá tư duy kiến trúc ở mức codebase, không phải chỉ viết cho chạy.

• Nêu cách chia component theo trách nhiệm: presentational và container hoặc theo feature.
• Thể hiện bạn quan tâm tới tái sử dụng nhưng không lạm dụng trừu tượng hoá.
• Nhắc tới naming, folder structure và cách đặt boundary để team đọc code dễ.

42. Bạn debug bug React theo hướng nào khi UI không đúng như mong đợi?

Interviewer muốn thấy cách bạn suy luận, không chỉ thử sửa ngẫu nhiên.

• Xác định dữ liệu đầu vào: props/state hiện tại có đúng không.
• Kiểm tra luồng update: effect chạy lúc nào, setState có bị gọi nhiều lần không.
• Dùng devtools để xem component tree, props, state và xác nhận điểm sai.

Câu hỏi về state, data flow và lỗi UI thực tế

Nhóm câu hỏi này thường là nơi phân biệt rõ ứng viên đã từng làm sản phẩm thật với người chỉ làm demo. Interviewer không chỉ nghe bạn kể tên công cụ, mà sẽ chú ý cách bạn tổ chức luồng dữ liệu, xử lý trạng thái loading, error, đồng thời kiểm soát các bug UI khó chịu như dữ liệu hiển thị sai, flicker, hoặc giao diện chậm khi tương tác.

43. Local state và global state khác nhau thế nào?

Câu này kiểm tra bạn hiểu đặt state ở đâu để UI dễ quản lý và ít rối.

• Nêu local state phù hợp cho trạng thái gói gọn trong một màn hình hoặc một component.
• Nêu global state phù hợp cho dữ liệu dùng chung nhiều nơi như user session, cart, theme.
• Thể hiện bạn tránh biến mọi thứ thành global chỉ vì tiện.

44. Props drilling gây vấn đề gì trong dự án lớn?

Interviewer muốn nghe bạn đã từng “đụng” cảm giác khó chịu khi truyền props qua nhiều tầng.

• Nhận diện dấu hiệu: component trung gian không dùng props nhưng vẫn phải truyền.
• Nêu tác động: code khó đọc, khó refactor, dễ truyền sai hoặc thiếu.
• Thể hiện bạn biết các hướng xử lý phù hợp theo độ phức tạp, không nhất thiết phải kéo framework vào ngay.

45. Context API nên dùng trong trường hợp nào?

Câu hỏi này đánh giá bạn biết dùng context đúng mục đích, tránh lạm dụng.

• Nêu context hợp cho dữ liệu ổn định và dùng rộng như auth, theme, locale.
• Nhận diện rủi ro nếu context chứa dữ liệu thay đổi liên tục có thể làm nhiều component re-render.
• Thể hiện bạn cân nhắc phạm vi context và chia nhỏ nếu cần.

46. Derived state là gì và vì sao dễ gây bug?

Interviewer muốn biết bạn tránh được kiểu state bị lệch so với nguồn dữ liệu thật.

• Nêu derived state là state được tính từ props hoặc state khác.
• Nhận diện bug thường gặp: dữ liệu cập nhật một nơi nhưng derived state không cập nhật theo.
• Thể hiện bạn ưu tiên tính toán khi render hoặc dùng memo khi cần, thay vì lưu mọi thứ thành state.

47. Bạn xử lý loading và error state ra sao để UX tốt?

Câu này kiểm tra khả năng bạn biến trạng thái kỹ thuật thành trải nghiệm dễ chịu cho người dùng.

• Nêu rõ các trạng thái nên có: loading, success, empty, error.
• Thể hiện bạn tránh UI nhảy loạn bằng cách giữ layout ổn định hoặc dùng skeleton hợp lý.
• Nhắc tới việc hiển thị lỗi có ngữ cảnh và hướng dẫn người dùng làm gì tiếp theo.

48. Khi nhiều component cập nhật state cùng lúc, bạn tránh bug thế nào?

Interviewer muốn nghe cách bạn kiểm soát race condition và cập nhật chồng chéo.

• Nêu tình huống thường gặp: nhiều request về không theo thứ tự, UI bị “lật” qua lật lại.
• Thể hiện bạn biết cách khoá luồng cập nhật hoặc bỏ qua response cũ nếu cần.
• Nhắc tới việc đảm bảo mỗi cập nhật có tiêu chí rõ ràng, tránh setState theo cảm giác.

49. UI bị lag khi scroll hoặc nhập liệu, bạn kiểm tra gì trước?

Câu này đánh giá phản xạ xử lý performance UI ở mức thực dụng.

• Kiểm tra xem có đang render quá nhiều item hoặc logic chạy nặng trong event handler không.
• Thể hiện bạn biết dùng debounce/throttle hoặc tối ưu render cho danh sách dài.
• Nhắc tới việc dùng profiling để xác định điểm nghẽn thay vì đoán.

50. Sau deploy UI bị vỡ layout hoặc hiển thị sai dữ liệu, bạn ưu tiên làm gì?

Interviewer muốn thấy bạn có tư duy giảm rủi ro khi sự cố xảy ra trên production.

• Xác định mức độ ảnh hưởng và phạm vi: trình duyệt nào, thiết bị nào, màn hình nào.
• Thể hiện bạn kiểm tra nhanh thay đổi liên quan và quan sát lỗi qua log hoặc monitoring nếu có.
• Nhắc tới phương án an toàn: rollback hoặc tắt tính năng nếu ảnh hưởng lớn và có cơ chế hỗ trợ.

Lời khuyên giúp bạn luyện phỏng vấn Frontend hiệu quả hơn

Với phỏng vấn Frontend, đọc danh sách câu hỏi chỉ là bước khởi động. Thứ làm bạn tiến bộ nhanh thường nằm ở cách bạn luyện trả lời: bạn có biến mỗi câu hỏi thành một mạch suy nghĩ rõ ràng, bám sát trải nghiệm của mình hay không. Nếu bạn chỉ cố nhớ khái niệm, tới lúc phỏng vấn thật rất dễ rơi vào kiểu nói đúng nhưng không thuyết phục, vì người nghe không nhìn thấy cách bạn làm việc.

Một cách luyện hiệu quả là chọn lọc theo vị trí bạn ứng tuyển. Nếu bạn là fresher, hãy tập trung nhóm JavaScript nền tảng, browser, HTML/CSS và những câu về state, vì đây là nơi bạn dễ bị hỏi nhất. Nếu bạn đã lên mid-level, hãy ưu tiên nhóm React, data flow, debug UI và các tình huống thực tế, bởi interviewer thường muốn nghe cách bạn kiểm soát lỗi và giữ trải nghiệm người dùng ổn định hơn là nghe bạn kể framework.

Khi luyện từng câu, bạn có thể giữ một trình tự đơn giản để câu trả lời không bị lan man: bạn hiểu vấn đề gì, bạn kiểm tra gì trước, và bạn chọn hướng xử lý dựa trên dấu hiệu nào. Chỉ cần bạn nói được trình tự đó một cách mạch lạc, câu trả lời tự nhiên sẽ chắc hơn, đồng thời giúp người nghe cảm nhận được bạn làm việc có phương pháp chứ không xử lý theo cảm tính.

Cuối cùng, hãy chuẩn bị sẵn vài câu chuyện nhỏ từ dự án thật, kể cả là dự án cá nhân. Chỉ cần bạn mô tả được bối cảnh, lỗi nằm ở đâu, bạn tìm nguyên nhân thế nào và bạn rút ra điều gì, bạn đã có chất liệu rất mạnh để “kết nối” với gần như mọi câu hỏi trong bài này.

Vì sao bạn nên chọn Onschool Bootcamp cho sự nghiệp của mình

Đi phỏng vấn Frontend không khó ở việc nhớ kiến thức, mà khó ở chỗ bạn phải chứng minh được cách bạn tư duy, tổ chức code và xử lý vấn đề trong tình huống thật. Đây cũng là lý do nhiều Frontend Developer dù đã học qua React hoặc làm dự án nhỏ vẫn cảm thấy thiếu tự tin khi bước vào vòng technical.

Onschool Bootcamp tập trung giải quyết đúng điểm này. Thay vì học rời rạc từng kỹ thuật, chương trình được thiết kế xoay quanh làm sản phẩm hoàn chỉnh theo chuẩn Frontend hiện đại. Người học không chỉ viết được component chạy, mà còn luyện cách quản lý state, xử lý data flow, debug UI, tối ưu trải nghiệm người dùng và trình bày lại quá trình làm việc một cách mạch lạc.

Khi bạn đã từng tự tay xử lý bug UI, tối ưu render, hay refactor component để dễ maintain, bạn sẽ không cần học thuộc câu trả lời phỏng vấn mà bạn chỉ đang nói lại cách mình đã làm, với ví dụ rõ ràng và logic thuyết phục. Đây chính là lợi thế rất lớn khi cạnh tranh với các ứng viên khác trong vòng technical.

Kết luận

50 câu hỏi trong bài viết này được xây theo đúng những nhóm thường xuất hiện trong vòng technical của Frontend Developer: từ JavaScript nền tảng, browser và DOM, HTML/CSS thực chiến, React và tư duy component, cho tới state, data flow và các tình huống UI ngoài đời. Nếu bạn luyện có chọn lọc và luyện theo trình tự suy nghĩ rõ ràng, bạn sẽ thấy phỏng vấn Frontend bớt đáng sợ hơn rất nhiều, vì bạn luôn biết mình đang nói điều gì và vì sao điều đó quan trọng.

Nếu bạn đang chuẩn bị phỏng vấn Frontend trong thời gian tới, hãy chọn khoảng 15–20 câu phù hợp nhất với vị trí bạn ứng tuyển, luyện nói theo đúng mạch ưu tiên và gắn với dự án của bạn. Và nếu bạn muốn có lộ trình học thực hành dự án kèm mentor phản hồi để đi phỏng vấn tự tin hơn, tham khảo ngay Onschool Bootcamp để xem chương trình phù hợp và bắt đầu từ một roadmap rõ ràng ngay hôm nay.