Software Engineer

Tổng quan

Công ty E là một sản phẩm học tiếng Anh ứng dụng AI, với môi trường engineering tương đối international và remote.

Theo chia sẻ của ứng viên, toàn bộ 3 vòng phỏng vấn đều được thực hiện online bằng tiếng Anh.

Điểm đáng chú ý của process là gần như không có một vòng algorithm interview truyền thống. Thay vào đó, technical assessment tập trung khá rõ vào System Design, technical reasoning và khả năng ownership feature end-to-end.

Dù ứng viên apply Frontend, interviewer vẫn đào sâu vào Backend và distributed systems. Điều này phù hợp với cách team tổ chức engineering: một engineer có thể tham gia ownership feature từ Backend → Frontend, thay vì chỉ phụ trách một layer riêng biệt.

---

Round 1 — Online Assessment

Vòng đầu tiên là một take-home System Design challenge:

Design a Real-Time Vocabulary Quiz

Candidate cần tự phân tích requirement, thiết kế solution và sau đó trình bày lại bằng một video có thời lượng không quá 10 phút.

Điểm khác biệt của dạng OA này là interviewer không chỉ đánh giá output cuối cùng mà còn có thể nhìn vào cách candidate break down problem và defend technical decisions.

Một flow hợp lý khi tiếp cận dạng bài này thường sẽ là:

Requirement → Core flow → Architecture → Data model → Communication → Scaling → Failure cases

Với một bài Real-Time Quiz, những vấn đề đáng quan tâm có thể bao gồm:

• Làm thế nào để các participant nhận được trạng thái quiz gần như real-time?
• Session của một quiz được quản lý ở đâu?
• Làm thế nào để đồng bộ state giữa nhiều backend instances?
• Nếu một server bị restart thì session đang diễn ra xử lý thế nào?
• Làm thế nào để tránh một bottleneck duy nhất khi số lượng concurrent users tăng?
• Những dữ liệu nào cần persistent, những dữ liệu nào có thể giữ tạm thời?

Với dạng take-home này, việc vẽ một architecture quá phức tạp chưa chắc có lợi. Quan trọng hơn là candidate phải giải thích được tại sao một component tồn tại và nó giải quyết vấn đề gì.

---

Round 2 — System Design

Round 2 được thực hiện với một Principal Engineer.

Interviewer không đưa ra một bài System Design hoàn toàn mới mà đi sâu vào chính bài OA candidate đã làm.

Đây là điểm khá đáng chú ý.

Khi interviewer đã có trước solution của bạn, gần như mọi technical decision trong architecture đều có thể trở thành điểm bắt đầu cho follow-up:

• Vì sao chọn component này?
• Vì sao dùng cách communication này?
• Nếu traffic tăng thì bottleneck nằm ở đâu?
• Nếu component này fail thì chuyện gì xảy ra?
• Có alternative architecture nào không?
• Trade-off giữa hai lựa chọn là gì?

Vì vậy, khi làm take-home System Design, việc hiểu rõ chính solution của mình quan trọng không kém việc hoàn thành design.

Behavioral

Bên cạnh System Design, interviewer cũng hỏi một số câu behavioral liên quan đến cách làm việc:

• Khi nhận một task mới, bạn sẽ bắt đầu như thế nào?
• Làm sao để clarify requirement?
• Nếu conflict với đồng nghiệp thì xử lý ra sao?
• Khi requirement chưa rõ, bạn sẽ làm gì trước?

Những câu hỏi này đặc biệt phù hợp với môi trường có mức độ ownership cao.

Một engineer không chỉ cần nhận task và implement, mà còn phải có khả năng đi từ:

Understand → Clarify → Design → Execute → Validate

---

Ownership End-to-End

Một điểm ứng viên đánh giá cao ở Công ty E là engineer có thể own một feature từ đầu đến cuối, bao gồm cả Backend và Frontend.

Điều này cũng giải thích tại sao một vị trí Frontend vẫn có thể được hỏi System Design khá sâu.

Trong một feature thực tế, boundary giữa FE và BE không phải lúc nào cũng tách biệt hoàn toàn.

Một flow đơn giản có thể đi theo hướng:

User → Frontend → API / WebSocket → Backend Services → Database / Cache / Message Broker

Frontend engineer không nhất thiết phải trở thành Backend specialist, nhưng cần hiểu được toàn bộ flow để có thể đưa ra quyết định phù hợp khi feature có yêu cầu về performance, consistency hoặc scalability.

---

Round 3 — Behavioral / Engineering Manager

Vòng cuối được thực hiện với Engineering Manager người Ấn Độ đang quản lý team Việt Nam.

Không khí interview được ứng viên đánh giá khá thoải mái.

Candidate được yêu cầu vẽ và trình bày một project cũ, sau đó interviewer follow-up về cách xử lý task và những tình huống xảy ra trong công việc.

Đây là một dạng interview khá hiệu quả để kiểm tra technical depth.

Khi candidate tự vẽ architecture của project mình từng làm, interviewer có thể tiếp tục đào sâu vào:

• Component này chịu trách nhiệm gì?
• Vì sao architecture được thiết kế như vậy?
• Data flow đi qua những đâu?
• Candidate trực tiếp ownership phần nào?
• Nếu traffic tăng thì bottleneck nằm ở đâu?
• Nếu một dependency bị down thì hệ thống phản ứng thế nào?

Ngoài ra còn có các câu hỏi về task management và conflict resolution.

---

WebSocket Load Balancing

Một câu hỏi khiến ứng viên gặp khó khăn ở vòng này là:

How to load balance WebSocket connections?

Đây là một câu hỏi thú vị vì WebSocket có lifecycle khác với HTTP request thông thường.

Với HTTP request/response, load balancer có thể tương đối dễ dàng phân phối các request độc lập tới nhiều backend instances.

Trong khi đó, WebSocket thường giữ một long-lived connection giữa client và một backend instance.

Có thể hình dung đơn giản:

Client → Load Balancer → Server A / Server B / Server C

Sau khi connection được establish, client thường tiếp tục giữ connection đó với một server.

Do đó, bài toán không chỉ là phân phối traffic mà còn liên quan tới:

• Connection lifecycle
• Connection health
• Heartbeat
• Failure recovery
• Shared state
• Message routing

Message Routing

Giả sử User A đang kết nối tới Server A.

User A → Server A

Nhưng một event liên quan tới User A lại được xử lý tại Server B.

Nếu mỗi server chỉ biết những connection đang tồn tại locally thì Server B không biết User A đang nằm ở đâu.

Một hướng xử lý phổ biến là sử dụng shared messaging layer:

Message Broker → Server A / Server B / Server C → WebSocket Clients

Các WebSocket servers chịu trách nhiệm giữ connection, trong khi message broker giúp các instances có thể trao đổi event với nhau.

Heartbeat

Một vấn đề khác là làm sao biết một WebSocket connection còn thực sự active.

Client có thể mất network, mobile device có thể sleep, process có thể crash hoặc một network intermediary có thể đóng connection.

Vì vậy, hệ thống thường cần cơ chế heartbeat / ping-pong để detect stale connections.

Flow có thể đơn giản là:

Server → Ping → Client → Pong

Nếu connection không phản hồi trong khoảng thời gian phù hợp, server có thể cleanup connection và giải phóng resource.

Sticky Session

Sticky session có thể giúp một client tiếp tục được route về cùng một backend instance, nhưng nó không tự giải quyết toàn bộ vấn đề của distributed WebSocket system.

Nếu quá nhiều state quan trọng chỉ nằm trên một server, việc server đó restart hoặc fail có thể ảnh hưởng trực tiếp tới các connection đang được giữ trên server.

Vì vậy, khi scale WebSocket system, cần phân biệt rõ:

Connection state local và application state / shared state.

Đây cũng là lý do câu hỏi "How to load balance WebSocket connections?" có thể mở rộng thành một bài toán distributed system tương đối lớn, thay vì chỉ đơn giản là đặt Load Balancer trước vài server.

---

Takeaway

Process này cho thấy một điểm đáng chú ý của những role có ownership rộng:

Frontend interview không nhất thiết chỉ xoay quanh Frontend.

Nếu engineer được kỳ vọng own feature end-to-end, interviewer có thể muốn candidate hiểu cả lifecycle của feature:

Client → API / WebSocket → Backend → Data → Messaging → Scaling → Failure Handling

Vì vậy, ngoài React và JavaScript fundamentals, việc chuẩn bị thêm các chủ đề như HTTP, WebSocket, caching, database, message queue, load balancing, distributed systems và observability sẽ giúp candidate xử lý tốt hơn những follow-up mang tính production.

Câu hỏi bạn còn nhớ

System Design

• Design a Real-Time Vocabulary Quiz.
• Explain the architecture của solution trong OA.
• Vì sao chọn architecture này?
• Khi nhận một task mới, bạn sẽ bắt đầu như thế nào?
• Làm thế nào để clarify requirement trước khi implementation?
• Làm thế nào xử lý conflict với đồng nghiệp?
• Làm thế nào để own một feature end-to-end từ Backend tới Frontend?

Past Project

• Vẽ và trình bày một project cũ.
• Bạn ownership phần nào trong project?
• Architecture của project hoạt động như thế nào?
• Những technical decisions quan trọng là gì?
• Nếu làm lại project, bạn có thay đổi decision nào không?

WebSocket / Distributed Systems

• How to load balance WebSocket connections?
• Làm thế nào để phân phối WebSocket connections giữa nhiều server?
• Khi nào cần sticky session?
• Làm thế nào detect một WebSocket connection đã stale?
• Heartbeat / ping-pong dùng để làm gì?
• Nếu một WebSocket server bị down thì chuyện gì xảy ra?
• Làm thế nào route message tới đúng server đang giữ connection của user?
• Có cần shared state hoặc message broker không?
• Làm thế nào monitor WebSocket connections trong production?

Kết quả

Sau 3 vòng phỏng vấn, ứng viên được đề xuất ở Middle level thay vì level ban đầu.

Theo chia sẻ của ứng viên, kết quả này tương đối hợp lý vì role có mức độ ownership end-to-end và yêu cầu hiểu cả Backend lẫn Frontend. Phần kiến thức còn thiếu rõ nhất nằm ở Backend / distributed systems, đặc biệt là các vấn đề liên quan đến WebSocket scaling, connection management và monitoring.

Đây cũng là điểm đáng chú ý của process: apply Frontend không có nghĩa technical scope chỉ dừng ở UI implementation.

Với những role yêu cầu engineer own feature từ BE → FE, khả năng hiểu architecture tổng thể và reasoning về production problems có thể trở thành một phần đáng kể của technical interview.