Software Engineer

Phỏng vấn Middle Software Engineer tại Công Ty W: Deep Dive System Design, Kafka, Golang và Clean Architecture

Điểm đặc biệt của experience này không nằm ở số lượng vòng phỏng vấn, mà ở cách interviewer đào rất sâu vào chính những gì candidate đã viết trong CV.

Database, Cache, Kafka, GCP, gRPC hay Clean Architecture đều không chỉ xuất hiện dưới dạng câu hỏi định nghĩa.

Interview liên tục đi theo một hướng khó hơn:

Bạn đã dùng nó như thế nào, nó hoạt động ra sao bên dưới, và tại sao bạn lại chọn nó?

Đây là một pattern khá điển hình cho Middle Engineer: interviewer muốn kiểm tra xem candidate thực sự hiểu những system mình từng xây dựng, hay chỉ quen sử dụng technology thông qua framework / abstraction có sẵn.

Toàn bộ 3 vòng được thực hiện bằng tiếng Anh với interviewer đến từ Singapore, Việt Nam và Hong Kong.

---

1. Round 1 — HR Catch-up

Vòng đầu tiên tập trung vào background và kỳ vọng của candidate.

Các chủ đề gồm:

• Work experience.
• Career goals.
• Expectations.
• Availability.
• Salary expectations.

Đây là phần khá quen thuộc trong engineering hiring process.

Tuy nhiên, với một quy trình tiếp theo thiên mạnh về resume deep dive, phần HR cũng là cơ hội để candidate xác định cách mình muốn kể câu chuyện career.

Một resume có nhiều technology không nhất thiết tạo ra lợi thế nếu candidate không thể giải thích rõ:

• Mình thực sự làm phần nào.
• Mình chịu trách nhiệm đến đâu.
• Vì sao technology đó được lựa chọn.
• Kết quả cuối cùng là gì.

Những điểm này thường trở thành nguyên liệu cho technical interview ở các vòng sau.

---

2. Round 2 — Technical Interview

Round 2 kéo dài khoảng 1 giờ 15 phút và là phần technical có phạm vi rộng nhất.

Interview bắt đầu bằng một bài LeetCode, sau đó chuyển sang System Design và deep dive vào current project.

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

System Design không bắt đầu từ một bài toán hoàn toàn xa lạ.

Thay vào đó, interviewer lấy chính project candidate đang làm để hỏi.

Điều này khiến resume trở thành một phần rất quan trọng của technical interview.

---

3. System Design dựa trên Project hiện tại

Candidate được yêu cầu trình bày architecture của project hiện tại và đi sâu vào các thành phần bên trong.

Với dạng câu hỏi này, interviewer có thể không chỉ muốn biết:

"System có những service nào?"

mà còn muốn hiểu:

• Request đi qua những component nào?
• Data flow như thế nào?
• Database được chọn ra sao?
• Cache nằm ở đâu?
• Message broker đóng vai trò gì?
• Service giao tiếp với nhau bằng cách nào?
• Bottleneck nằm ở đâu?
• Nếu traffic tăng thì component nào scale trước?
• Failure ở một dependency thì hệ thống phản ứng thế nào?
• Monitoring và observability được triển khai ra sao?

Ở level Middle, câu trả lời tốt thường không dừng ở architecture diagram.

Candidate cần giải thích được vì sao architecture đó hợp lý với workload cụ thể.

---

4. Technology Deep Dive: "Bạn dùng nó" chưa đủ

Một phần đáng chú ý của round này là interviewer hỏi sâu vào các technology candidate viết trong resume:

• Database
• Cache
• Kafka
• GCP
• gRPC

Pattern câu hỏi được mô tả khá rõ:

Deep Dive — How does it work under the hood?

Đây là một dạng câu hỏi rất dễ tạo ra khoảng cách giữa:

"đã từng sử dụng"

và

"thực sự hiểu technology".

Ví dụ, nếu CV ghi Kafka, interviewer có thể không dừng ở:

Kafka là message broker.

Mà có thể đi tiếp đến:

• Topic và partition hoạt động thế nào?
• Consumer group dùng để làm gì?
• Ordering được đảm bảo ở đâu?
• Consumer offset được quản lý như thế nào?
• Điều gì xảy ra khi consumer crash?
• Partition ảnh hưởng thế nào đến throughput?
• Vì sao Kafka phù hợp với workload này?

Tương tự với Database, câu hỏi có thể đi sâu từ việc "dùng PostgreSQL/MySQL" đến:

• Index hoạt động như thế nào?
• Query planner làm gì?
• Transaction isolation có ý nghĩa gì?
• Khi query chậm thì debug từ đâu?
• Read/write workload được phân tách như thế nào?

Với Cache:

• Cache invalidation xử lý thế nào?
• TTL có ý nghĩa gì?
• Cache stampede là gì?
• Khi cache unavailable thì application làm gì?

Với gRPC:

• Vì sao chọn gRPC thay vì REST?
• Protocol Buffers mang lại lợi ích gì?
• Unary và streaming khác nhau thế nào?
• Timeout và retry xử lý ra sao?
• Failure giữa các service được kiểm soát thế nào?

Điểm chung của các câu hỏi này là:

Technology chỉ là công cụ. Interviewer muốn biết candidate hiểu behavior và trade-off của công cụ đó.

---

5. System Design: Không chỉ có một đáp án

Một phần khác của Round 2 là một bài System Design yêu cầu candidate đưa ra nhiều solution và phân tích pros/cons của từng solution.

Đây là format rất đáng chú ý.

System Design trong thực tế hiếm khi có một architecture "đúng tuyệt đối".

Ví dụ, cùng một requirement có thể có:

Solution A — Simpler architecture

Ưu điểm:

• Dễ triển khai.
• Dễ debug.
• Chi phí vận hành thấp.
• Ít component hơn.

Nhược điểm:

• Khả năng scale hạn chế.
• Một số bottleneck có thể xuất hiện khi workload tăng.

Solution B — Distributed architecture

Ưu điểm:

• Scale tốt hơn.
• Có thể tách workload.
• Có nhiều lựa chọn để tối ưu từng component.

Nhược điểm:

• Complexity cao hơn.
• Distributed failure khó debug hơn.
• Observability cần tốt hơn.
• Operational cost cao hơn.

Điểm interviewer muốn nghe không nhất thiết là:

"Solution B tốt hơn."

Mà là:

"Với requirement X và constraint Y, tôi chọn B vì trade-off này phù hợp hơn."

Đó chính là tư duy architecture.

---

6. Kafka và bài toán Message Ordering

Một câu hỏi được nhớ lại ở Round 3 là:

How does Kafka preserve message ordering?

Một nuance quan trọng:

Kafka đảm bảo ordering trong phạm vi một partition.

Nếu các message thuộc cùng một partition, Kafka duy trì thứ tự của chúng.

Ví dụ:

Event A → Event B → Event C

được ghi vào cùng partition thì consumer đọc partition đó theo thứ tự:

A → B → C

Nhưng nếu các message nằm ở các partition khác nhau thì không có một global ordering guarantee giữa chúng.

Vì vậy, nếu application yêu cầu ordering theo một entity, chẳng hạn:

Order #123

thì một common approach là sử dụng key phù hợp để các event của cùng entity được route vào cùng partition.

Ví dụ:

key = order_id

Khi đó các event của cùng order có thể giữ được thứ tự trong partition tương ứng.

Đây cũng là lý do partitioning không chỉ là câu chuyện performance.

Nó có thể trở thành một phần của business correctness nếu thứ tự event có ý nghĩa.

---

7. Clean Architecture: "Show me your code"

Round 3 có một phần khá thực tế:

Share screen và show code.

Candidate được yêu cầu giải thích cách tổ chức Clean Architecture trong project.

Đây là lúc một khái niệm kiến trúc chuyển từ diagram hoặc slide thành code thực tế.

Một implementation thường có thể phân tách những responsibility như:

• Domain / Entity
• Use Case / Application logic
• Interface / Adapter
• Infrastructure
• Delivery / Transport

Mục tiêu không đơn giản là có nhiều folder.

Một architecture tốt cần trả lời được:

Dependency đang đi theo hướng nào?

Ví dụ, business logic không nên bị phụ thuộc quá chặt vào một database implementation hoặc framework cụ thể nếu architecture đang hướng đến dependency inversion.

Điều interviewer có thể quan sát qua code:

• Responsibility có được phân tách rõ không?
• Business logic nằm ở đâu?
• Database access được isolate thế nào?
• Interface được sử dụng ra sao?
• Dependency injection được tổ chức như thế nào?
• Testability có tốt không?
• Có abstraction quá mức không?

Đây là một điểm quan trọng:

Clean Architecture không phải là càng nhiều layer càng tốt.

Nếu một CRUD service đơn giản có quá nhiều abstraction chỉ để "đúng pattern", complexity có thể tăng mà business value không tăng tương ứng.

Architecture nên phục vụ requirement, chứ không phải requirement phục vụ architecture.

---

8. MCP Server trong Current Project

Một câu hỏi khác được nhắc lại:

What is the purpose of the MCP Server you built in your current company?

Do experience không cung cấp chi tiết implementation của MCP Server, không nên suy đoán cụ thể server đó dùng cho use case nào.

Tuy nhiên, ở interview, câu hỏi này cho thấy một pattern khá rõ:

Nếu candidate ghi một technology hoặc project đặc biệt vào CV, interviewer có thể yêu cầu candidate giải thích:

• Problem ban đầu là gì?
• MCP Server giải quyết problem nào?
• Architecture như thế nào?
• Các component giao tiếp ra sao?
• Candidate trực tiếp implement phần nào?
• Vì sao chọn approach đó?
• Có limitation gì?
• Nếu scale lên thì thay đổi gì?

Đây chính là lý do resume deep dive có thể khó hơn một câu hỏi technology độc lập.

Interviewer không chỉ hỏi:

"MCP là gì?"

mà hỏi:

"MCP mà bạn xây dựng thực sự giải quyết vấn đề gì?"

---

9. Golang Fundamentals

Golang cũng xuất hiện trong technical round.

Với Middle Software Engineer, những câu hỏi fundamental có thể xoay quanh:

• Goroutine
• Channel
• Interface
• Pointer
• Struct
• Error handling
• Concurrency
• Memory / allocation
• Package structure

Nếu candidate ghi Go là một trong những core skills, interviewer thường có cơ sở để đi sâu hơn vào cách runtime và language feature hoạt động thay vì chỉ hỏi syntax.

Một nguyên tắc chuẩn bị hữu ích:

Nếu một technology xuất hiện trong phần Skills của CV, hãy chuẩn bị cho khả năng interviewer hỏi đến ít nhất một tầng sâu hơn phần documentation-level definition.

---

10. Resume Deep Dive

Một pattern lặp lại ở cả Round 2 và Round 3 là:

Deep dive vào experience trong resume.

Khoảng 4–5 câu hỏi có thể được dành riêng cho những gì candidate đã viết.

Điều này khiến từng bullet point trong CV trở thành một potential interview question.

Ví dụ nếu CV viết:

"Improved API performance by 40%."

Interviewer hoàn toàn có thể hỏi:

• Performance trước đó là bao nhiêu?
• Đo bằng metric nào?
• Bottleneck nằm ở đâu?
• Bạn xác định bottleneck bằng cách nào?
• Thay đổi gì?
• Vì sao thay đổi đó giúp performance tăng?
• Benchmark được thực hiện thế nào?
• Có trade-off không?

Nếu candidate không trực tiếp thực hiện phần work đó, rất dễ bị lộ ở follow-up.

Vì vậy:

Đừng đưa vào CV những technical achievement mà bạn không thể defend trong 5–10 phút conversation.

---

11. Behavioral Interview

Round 3 không chỉ technical.

Một số câu hỏi behavioral:

What is the most challenging project you've worked on?

Đây là câu hỏi có thể dùng để đánh giá:

• Ownership.
• Technical complexity.
• Problem solving.
• Decision making.
• Impact.

Một câu trả lời tốt nên tập trung vào một project cụ thể, thay vì kể toàn bộ career.

Có thể sử dụng:

Context → Challenge → Action → Result → Learning

---

How do you handle a conflict with a team member?

Interviewer không nhất thiết tìm một câu chuyện "không bao giờ có conflict".

Điều đáng nói hơn là candidate xử lý disagreement như thế nào:

• Xác định vấn đề.
• Tách technical disagreement khỏi personal conflict.
• Dùng data/requirement để thảo luận.
• Tìm common goal.
• Escalate khi thực sự cần thiết.

---

How do you get familiar with a new job and a new team?

Câu hỏi này kiểm tra khả năng onboarding và autonomy.

Một approach thực tế có thể bao gồm:

1. Hiểu product và business context.
2. Đọc architecture/documentation.
3. Setup local environment.
4. Trace một request end-to-end.
5. Chạy qua codebase.
6. Nhận một task nhỏ để hiểu development workflow.
7. Chủ động hỏi những điểm chưa rõ.

---

How do you mentor a Fresher / Junior Engineer?

Với Middle Engineer, đây cũng là một cách kiểm tra khả năng collaboration.

Mentoring không nhất thiết có nghĩa là:

"Tôi chỉ cho junior cách code."

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

• Giải thích reasoning.
• Đặt câu hỏi thay vì đưa answer ngay.
• Review code và giải thích trade-off.
• Cho junior ownership phù hợp.
• Feedback thường xuyên.
• Tăng dần độ khó của task.

---

12. Điều experience này cho thấy về Middle-level interview

Có thể chia interview thành ba lớp:

Layer 1 — Can you code?

LeetCode / Algorithm.

Layer 2 — Do you understand your system?

System Design, Architecture, Database, Kafka, Cache, gRPC, GCP, Golang.

Layer 3 — Can you operate as an engineer?

Communication, ownership, conflict resolution, mentoring và khả năng giải thích technical decision.

Đây là điểm khiến interview ở Middle level khác khá nhiều so với một bài algorithm-focused interview.

Candidate không chỉ cần biết:

How to implement it?

mà cần trả lời được:

Why this architecture?

Why this technology?

What happens under the hood?

What are the alternatives?

What are the trade-offs?

Và cuối cùng:

Can you clearly explain why you made that decision?

Đó cũng là signal quan trọng nhất xuyên suốt experience này: độ sâu của technical ownership.

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

Round 1 — HR

• Hãy giới thiệu về background và work experience.
• Career goals và expectations?
• Khi nào có thể bắt đầu công việc?
• Salary expectations?
• HR giới thiệu về công ty và team.

---

Round 2 — Technical

Algorithm

• 1 bài LeetCode.

System Design / Current Project

• Hãy trình bày System Design của project hiện tại.
• Architecture của project được tổ chức như thế nào?
• Deep dive vào các technical decision trong project.
• Vì sao chọn architecture hiện tại?
• Nếu phải thiết kế lại, bạn sẽ thay đổi điều gì?

Technology Deep Dive

Các technology được hỏi dựa trên những gì candidate viết trong resume:

• Database
• Cache
• Kafka
• GCP
• gRPC

Follow-up có xu hướng đi sâu vào:

How does it work under the hood?

Why did you choose this technology?

What are the trade-offs?

System Design Case

• Giải quyết một bài toán System Design với nhiều phương án khác nhau.
• Trình bày ưu / nhược điểm của từng solution.
• Giải thích lý do chọn một solution cụ thể.

Golang

• Golang fundamentals.

Resume Deep Dive

• Project.
• Experience.
• Achievement.
• Technical contribution.

---

Round 3 — Technical & Behavioral

Technical

• Share screen và giải thích cách tổ chức Clean Architecture trong project.
• Deep dive vào 4–5 experience được ghi trong resume.
• How does Kafka preserve message ordering?
• MCP Server bạn xây dựng ở công ty hiện tại có mục đích gì?

Behavioral

• What is the most challenging project you've worked on?
• How do you handle a conflict with a team member?
• How do you get familiar with a new job and a new team?
• How do you mentor a fresher / junior engineer?