Software Engineer

Phỏng vấn Engineer tại Công ty A: SQL Internals, Hash Map, System Design và bài toán chọn công nghệ

Đây là một interview loop có độ phủ khá rộng.

Thay vì tập trung toàn bộ vào algorithm, các vòng phỏng vấn lần lượt đi qua:

Technology Choice → Coding & Design → Database Internals → Algorithm → System Design → Behavioral / Management

Điểm đáng chú ý là nhiều câu hỏi không dừng ở việc "biết khái niệm", mà thường có một lớp follow-up sâu hơn:

• Không chỉ implement được code mà còn phải nghĩ đến khả năng mở rộng.
• Không chỉ biết index mà phải hiểu query planner sử dụng index như thế nào.
• Không chỉ biết MVCC mà phải hiểu nó liên quan gì đến transaction và isolation.
• Không chỉ giải được algorithm mà còn phải đưa ra alternative approach.
• Không chỉ vẽ architecture mà phải explain được vì sao architecture đó phù hợp với workload.

---

1. HR Screening — 30 phút

HR liên hệ khoảng 30 phút.

Hai nội dung chính được đề cập:

• Khả năng giao tiếp tiếng Anh.
• Lý do muốn thay đổi công việc.

Sau HR screening, toàn bộ 5 vòng interview tiếp theo được thực hiện bằng tiếng Việt.

---

2. Round 1 — Technology Choice + Evaluate Expression

Round đầu tiên được thực hiện với một Engineer Manager.

Khoảng 30 phút đầu tập trung vào work experience và cách candidate đưa ra quyết định về công nghệ.

Đây là một dạng question khá phổ biến ở level Engineer trở lên:

Khi gặp một bài toán mới, bạn dựa vào đâu để chọn technology?

Một câu trả lời tốt thường không nên chỉ là danh sách technology quen thuộc.

Thay vào đó, có thể bắt đầu từ:

• Functional requirements.
• Expected traffic / scale.
• Latency requirement.
• Consistency requirement.
• Data model.
• Team expertise.
• Operational complexity.
• Cost.
• Ecosystem / maintainability.
• Existing infrastructure.

Ví dụ, thay vì nói:

"Em chọn Kafka vì hệ thống cần scale."

có thể đi sâu hơn:

"Nếu communication pattern là asynchronous event processing và cần nhiều consumer độc lập, Kafka có thể phù hợp. Nhưng nếu caller cần synchronous response ngay lập tức thì em sẽ cân nhắc RPC như gRPC thay vì đưa Kafka vào giữa."

Điểm quan trọng là technology choice nên xuất phát từ requirement và trade-off, không phải từ việc technology đó đang phổ biến.

---

3. Coding — Evaluate Expression

30 phút tiếp theo là coding.

Đề bài bắt đầu từ việc evaluate một expression đơn giản, sau đó được interviewer mở rộng dần.

Các extension được candidate nhớ lại gồm:

• Cộng / trừ.
• Số La Mã.
• Floating-point number.

Candidate implement được phần floating point nhưng solution chưa hoàn toàn đúng với expectation của interviewer.

Điểm interviewer muốn thấy là cách tổ chức solution theo hướng OOP / extensible design.

Đây là một distinction khá hay giữa:

"Code chạy được."

và

"Code có thể tiếp tục phát triển khi requirement thay đổi."

---

4. Tại sao OOP lại trở thành follow-up của một bài Expression Parser?

Giả sử ban đầu chỉ có:

1 + 2 - 3

Candidate có thể viết một parser rất đơn giản.

Nhưng sau đó requirement liên tục thay đổi:

1 + 2.5

rồi:

X + V

rồi thêm operator hoặc data type mới.

Nếu implementation ban đầu chứa quá nhiều logic kiểu:

if input is integer → ...

if input is Roman numeral → ...

if input is floating point → ...

thì mỗi requirement mới lại buộc phải sửa core logic.

Một hướng có tính mở rộng hơn là tách abstraction.

Ví dụ về mặt conceptual:

Expression

→ Operator

→ Operand

→ Number / RomanNumber / FloatingPointValue

Khi thêm một loại operand mới, phần parser / evaluator chính không nhất thiết phải thay đổi quá nhiều.

Đây là nơi interviewer có thể đang đánh giá những kỹ năng như:

• Separation of concerns.
• Encapsulation.
• Abstraction.
• Polymorphism.
• Open/Closed Principle.
• Khả năng thiết kế code để đáp ứng requirement thay đổi.

Không nhất thiết phải dùng một design pattern cụ thể.

Điểm quan trọng hơn là candidate có thể giải thích:

"Nếu requirement tiếp tục thay đổi, em sẽ thay đổi ở đâu và tại sao?"

Candidate vẫn pass vòng này dù solution floating-point chưa hoàn toàn khớp expectation.

---

5. Full Loop — Database + Hash Map

Vòng đầu tiên trong full loop đi khá sâu vào database.

Các chủ đề gồm:

• SQL.
• Index strategy.
• Multi-column index.
• EXPLAIN ANALYZE.
• MVCC.
• Isolation level.
• Hash Map.
• Rehash.

Đây là một combination khá đặc trưng của backend interview vì nó kiểm tra cả:

Query performance + database internals + data structure fundamentals.

---

6. Index Strategy

Một câu hỏi quan trọng:

Làm thế nào để lựa chọn index strategy?

Không có một câu trả lời kiểu:

"Column nào query nhiều thì add index."

Index phải được thiết kế dựa trên query workload.

Ví dụ một query:

WHERE user_id = ? AND status = ? ORDER BY created_at DESC

Có thể khiến candidate cân nhắc composite index phù hợp với access pattern thay vì tạo ba single-column index một cách máy móc.

Nhưng index nào tốt còn phụ thuộc vào:

• Selectivity.
• Query frequency.
• WHERE conditions.
• JOIN conditions.
• ORDER BY.
• GROUP BY.
• Data distribution.
• Write frequency.
• Index size.

Index giúp đọc nhanh hơn nhưng không miễn phí.

Mỗi index bổ sung cũng có:

• Storage cost.
• Write amplification.
• Maintenance cost.
• Insert/update/delete overhead.