Software Engineer

Tổng quan

Đây là một quy trình tuyển dụng Frontend Engineer khá toàn diện tại Công ty E, kéo dài qua 5 vòng, gồm OA, HR Screening, 2 vòng Behavioral/Technical với Engineering Manager và một vòng Behavioral bổ sung.

Điểm đáng chú ý là technical interview không chỉ tập trung vào việc ứng viên có biết React hay giải được LeetCode hay không. Ở các vòng sau, interviewer đi khá sâu vào:

• Cách phân tích vấn đề trước khi đưa ra solution
• Vai trò thực tế của ứng viên trong những project đã làm
• Cách đưa ra technical decision
• Ownership và khả năng deliver trong sprint
• Cách làm việc với requirement chưa rõ
• Frontend performance optimization
• CORS
• Frontend System Design
• Khả năng follow-up khi interviewer đào sâu vào một design decision

Với những vòng như vậy, việc “biết câu trả lời” và việc “biết cách suy nghĩ để đi đến câu trả lời” là hai chuyện khá khác nhau.

---

Round 1 — OA

Vòng đầu tiên gồm khá nhiều dạng assessment khác nhau.

Personality & Cognitive Test

Có một bài test tính cách và một bài cognitive assessment, tập trung vào khả năng xử lý thông tin nhanh.

Một số dạng bài gồm:

• Chọn số theo yêu cầu trong thời gian ngắn
• Xếp hình
• Tìm lỗi sai trong câu tiếng Anh
• Các dạng pattern recognition / attention test

Phần này khá khác với DSA truyền thống vì ngoài kiến thức, ứng viên còn phải xử lý nhiều câu hỏi trong thời gian tương đối ngắn.

DSA

Có 2 bài DSA trên Codility, độ khó khoảng Easy → Medium.

Các topic chính:

• Two Pointers
• DFS

React

Ngoài DSA, OA có thêm 2 bài React.

Đề bài chủ yếu yêu cầu build các component frontend tương đối đơn giản, tập trung vào khả năng đọc requirement và implement đúng behavior thay vì một bài React architecture quá phức tạp.

Interview signal: OA đang kiểm tra khá rộng — từ cognitive ability, DSA cho tới khả năng code UI thực tế. Vì vậy chỉ ôn LeetCode là chưa đủ nếu target một role Frontend.

Các câu hỏi đáng chú ý

Behavioral / Experience

• Tại sao bạn rời công ty cũ?
• Hãy kể về một lần bạn giúp đỡ đồng nghiệp.
• Dự án nào bạn tự hào nhất?
• Trong project cũ bạn thực sự chịu trách nhiệm cho phần nào?
• Bạn đưa ra technical decision như thế nào?
• Bạn thường deliver công việc trong sprint ra sao?
• Bạn define requirement cho một task như thế nào?
• Bạn xử lý ownership của một task ra sao?
• Khi phối hợp với team, bạn thường làm gì để đảm bảo công việc được deliver?

Frontend Performance

Interviewer đưa một website và hỏi:

Nếu cần optimize performance cho website này, bạn sẽ bắt đầu từ đâu?

Điểm đáng chú ý không nằm ở việc kể ra thật nhiều technique như lazy loading, code splitting, caching hay image optimization.

Follow-up thực tế quan trọng hơn là:

• Bạn sẽ phân tích vấn đề như thế nào?
• Dựa trên metric nào để xác định bottleneck?
• Vì sao lại chọn action đó?
• Làm thế nào biết optimization thực sự có hiệu quả?
• Nếu có nhiều bottleneck cùng lúc, bạn ưu tiên xử lý cái nào trước?

Đây là dạng câu hỏi dễ khiến ứng viên “trả lời đúng nhưng vẫn chưa đủ”, vì interviewer đang muốn nhìn thấy reasoning process chứ không chỉ experience checklist.

CORS

• CORS là gì?
• Browser xử lý cross-origin request như thế nào?
• Khi nào xảy ra preflight?
• Request nào cần preflight?
• Server cần trả về những header nào?
• CORS khác gì với authentication / authorization?

Frontend System Design

Đề bài: Design notification feature cho một application.

Sau khi bắt đầu theo một framework System Design đầy đủ, interviewer yêu cầu narrow scope:

Chỉ tập trung design phần Frontend trước; nếu còn thời gian mới đi tiếp Backend.

Các vấn đề có thể được đào sâu trong FE design:

• Notification state được quản lý ở đâu?
• Component structure
• Data fetching
• Loading / empty / error states
• Read / unread state
• Pagination hoặc infinite scroll
• Realtime update nếu notification cần cập nhật tức thời
• Browser lifecycle
• Performance khi notification list lớn
• API contract giữa FE và BE
• UX khi có notification mới
• Cách tránh unnecessary re-render
• Caching / invalidation strategy

Điểm quan trọng của dạng interview này là scope control. Một design tốt không nhất thiết phải cover toàn bộ hệ thống; nó phải trả lời đúng vấn đề interviewer đang muốn đánh giá trong khoảng thời gian có hạn.

Interview Intelligence

1. Công ty E đang đánh giá “cách suy nghĩ” nhiều hơn một danh sách keyword

Nhìn xuyên suốt các vòng, có một pattern khá rõ:

OA → kiểm tra breadth

Behavioral → kiểm tra ownership + decision making

Technical → kiểm tra problem solving + reasoning

Final Behavioral → kiểm tra execution trong môi trường team

Điều này khiến profile “biết nhiều công nghệ” chưa chắc tạo ra lợi thế nếu ứng viên không giải thích được tại sao mình chọn một approach.

---

2. Performance question không nên trả lời bằng một checklist optimization

Đây là một dạng câu hỏi rất dễ mắc bẫy.

Ví dụ nếu interviewer hỏi:

“Optimize website này như thế nào?”

Một câu trả lời kiểu:

lazy loading → code splitting → image optimization → CDN → caching

có thể nghe rất technical nhưng vẫn thiếu phần quan trọng nhất: diagnosis.

Một flow reasoning tốt hơn thường là:

Measure → Identify bottleneck → Form hypothesis → Apply change → Measure again

Ví dụ:

• Dùng Lighthouse / Web Vitals để xác định vấn đề user đang gặp.
• Kiểm tra Network để xem resource nào nặng hoặc blocking.
• Kiểm tra bundle và dependency để tìm JavaScript không cần thiết.
• Phân tích rendering và long tasks nếu main thread bị block.
• Kiểm tra image/font loading.
• Sau optimization, đo lại metric để xác nhận impact.

Điểm interviewer có thể muốn nghe không phải “bạn thuộc bao nhiêu technique”, mà là:

Bạn có biết tìm đúng bottleneck trước khi sửa hay không?

---

3. Frontend System Design nên biết cách narrow scope

Với đề bài notification system, một ứng viên có thể rất dễ lao ngay vào:

WebSocket → Kafka → Redis → Database → Notification Service

Nhưng nếu interviewer yêu cầu chỉ design Frontend, việc tiếp tục đào sâu backend sẽ làm mất thời gian và có thể khiến discussion lệch khỏi mục tiêu.

Một approach phù hợp hơn:

Requirement → User flow → Component → State → Data fetching → Realtime update → Performance → Edge cases

Ví dụ notification UI có thể phải xử lý:

• Initial loading
• Empty state
• Error state
• Read/unread
• Pagination
• New notification arrival
• Mark as read
• Duplicate event
• Reconnect
• Large notification list

Sau đó mới discuss interface giữa FE và BE nếu còn thời gian.

---

4. Behavioral ở đây thiên về “evidence” hơn là câu trả lời chung chung

Các câu hỏi về:

• Ownership
• Sprint delivery
• Technical decisions
• Collaboration
• Requirement definition

thường khó trả lời tốt nếu chỉ nói:

“Em luôn chủ động và có tinh thần ownership.”

Cách thuyết phục hơn là đưa ra một situation cụ thể:

Context → Responsibility → Decision → Action → Result → Learning

Đặc biệt cần làm rõ:

“Phần này chính xác là mình làm, phần nào là team làm?”

Với interviewer là Engineering Manager, distinction này khá quan trọng vì họ thường muốn hiểu level of ownership thực tế của ứng viên chứ không chỉ scope của project.

---

5. Một chi tiết rất đáng chú ý: interviewer có thể liên tục đổi scope

Ở Round 4, câu hỏi bắt đầu từ performance optimization nhưng interviewer lại muốn nghe analysis process.

Frontend System Design ban đầu có thể được hiểu là full-stack, nhưng interviewer lại yêu cầu chỉ focus FE.

Đây là một signal quan trọng về interview style:

Đừng quá cố bám vào framework đã chuẩn bị.

Framework như 7-step System Design, STAR hay checklist performance chỉ nên là scaffolding.

Khi interviewer redirect:

“Focus vào FE thôi.”

thì việc quan trọng nhất là re-align ngay với scope mới.

---

Preparation Checklist

Nếu chuẩn bị cho một quy trình tương tự, nên cover ít nhất 5 nhóm:

DSA

• Two Pointers
• DFS / BFS
• HashMap
• Sliding Window
• Binary Search
• Basic recursion / tree traversal

Frontend

• React component design
• State management
• Rendering & re-render
• Performance optimization
• Browser lifecycle
• Network fundamentals
• CORS
• HTTP / caching

Frontend System Design

Có thể luyện các bài:

• Notification
• Chat
• Autocomplete
• File upload
• Feed
• Dashboard
• Real-time status

Với mỗi bài, tập trung vào FE architecture, không mặc định phải design cả backend.

Behavioral

Chuẩn bị trước các câu chuyện về:

• Project khó nhất
• Technical decision
• Conflict
• Mistake
• Ownership
• Helping teammate
• Requirement ambiguity
• Delivering under pressure
• Working with PM / Designer / Backend
• Một lần thay đổi approach sau feedback

Company Research

Đừng chỉ research để trả lời:

“Why Công ty E?”

Hãy research đủ để đặt được những câu hỏi có chất lượng cho interviewer:

• Team đang giải quyết problem gì?
• Frontend architecture hiện tại có challenge nào?
• Engineering team ownership tới đâu?
• Product đang ở giai đoạn nào?
• Những vấn đề technical nào team đang ưu tiên?

Ở các vòng với EM, chất lượng câu hỏi ngược đôi khi cũng giúp interviewer hiểu được mức độ chuẩn bị và mức độ quan tâm của ứng viên.

Outcome

Quy trình kết thúc ở vòng Behavioral bổ sung, tập trung vào ownership, sprint delivery, requirement và cách phối hợp với team.

Bài phỏng vấn này không chỉ xoay quanh “có pass được coding hay không”, mà cho thấy một Frontend interview ở level Mid/Senior có thể đi khá sâu vào decision-making, analytical thinking và khả năng chịu trách nhiệm cho công việc thực tế.