Software Engineer

Tổng quan

Quá trình phỏng vấn tại Công ty G gồm 3 vòng, đi theo format:

Algorithm → System Design → Hiring Manager

Điểm đáng chú ý là interview loop không chỉ tập trung vào khả năng coding. Sau vòng algorithm, ứng viên phải chuyển sang một bài Payment System Design khá khác với format đã chuẩn bị trước đó. Đây là lúc khả năng xử lý một problem statement chưa quen thuộc và tự xác định các vấn đề cần giải quyết trở nên quan trọng.

Tất cả các vòng technical đều được thực hiện bằng tiếng Anh, ngoại trừ HR call. Theo chia sẻ của ứng viên, đây là một challenge đáng kể vì trước đó chưa có nhiều cơ hội sử dụng tiếng Anh trong interview.

Tuy nhiên, các interviewer chủ động tạo không khí khá thoải mái và khuyến khích ứng viên hỏi lại nếu chưa hiểu câu hỏi.

Round 1 — Algorithm Interview

Vòng đầu tiên là live coding trên Codility, gồm 2 bài algorithm.

Theo chia sẻ của ứng viên, độ khó của hai bài không quá cao và cũng không đi theo hướng đánh đố.

Problem 1 — Valid Anagram

Bài đầu tiên là Valid Anagram, yêu cầu kiểm tra hai string có chứa cùng tập ký tự với cùng frequency hay không.

Đây là dạng bài khá cơ bản nhưng vẫn có thể dùng để kiểm tra cách ứng viên xử lý frequency counting, string traversal và complexity trong thời gian giới hạn.

Problem 2 — Difference Between Elements

Bài thứ hai yêu cầu kiểm tra một mảng số nguyên dương có thỏa mãn điều kiện các phần tử không chênh lệch nhau quá 1 đơn vị hay không.

Ví dụ:

• [3, 4, 6, 5, 1, 2] → true
• [3, 3, 2, 1] → true
• [3, 6, 4, 7, 2, 1] → false

Về bản chất, bài toán có thể được nhìn theo hướng xác định minimum và maximum của tập giá trị, sau đó kiểm tra range của chúng có vượt quá 1 hay không, thay vì phải so sánh từng cặp phần tử.

Cả hai bài đều được thực hiện trực tiếp với interviewer trên Codility.

Kết quả: PASS

Round 2 — System Design: Payment System

Đây là vòng có sự khác biệt lớn nhất giữa những gì ứng viên chuẩn bị và problem thực tế.

Trước interview, ứng viên đọc các review phỏng vấn trước đó và thấy một số candidate được hỏi về Chat System, nên đã tập trung ôn khá nhiều vào dạng bài này.

Tuy nhiên, trong interview thực tế, interviewer đưa ra một bài toán Payment System.

Dù có phần bất ngờ về domain, ứng viên vẫn xử lý được bài toán và đáp ứng các yêu cầu mà interviewer đưa ra.

Các chủ đề chính được hỏi xoay quanh:

• Làm thế nào để scale system
• Xử lý exception / failure
• Lưu trữ user data như thế nào
• Đảm bảo privacy của user data
• Các thành phần nào cần được đưa vào architecture
• Cách xử lý khi hệ thống phải phục vụ lượng request lớn hơn

Một cách tiếp cận được ứng viên sử dụng là:

Problem → Solution → Component

Thay vì bắt đầu ngay bằng việc vẽ architecture, ứng viên xác định từng vấn đề trước, tìm cách giải quyết rồi mới đưa các solution tương ứng vào system architecture.

Đây là cách tiếp cận khá hữu ích trong system design interview vì giúp architecture có lý do rõ ràng thay vì chỉ đơn giản là một tập hợp các components quen thuộc.

Với Payment System, cách tư duy này đặc biệt quan trọng vì interviewer có thể liên tục mở rộng requirement từ payment flow cơ bản sang failure handling, scalability, data consistency hoặc privacy.

Kết quả: PASS

Round 3 — Hiring Manager Interview

Round 3 là buổi trao đổi với Hiring Manager (HM) và tập trung phần lớn vào past experience và past projects.

HM dành phần lớn thời gian để tìm hiểu những project ứng viên từng làm, những vấn đề đã gặp và cách ứng viên giải quyết chúng.

Một phần đáng chú ý là câu hỏi về việc join một project mới với một programming language mới.

Trong trường hợp này, ứng viên đang sử dụng Java, trong khi môi trường mới sử dụng Golang. Vì vậy, HM muốn tìm hiểu cách ứng viên tiếp cận việc học một ngôn ngữ mới và làm quen với một codebase/project mà mình chưa từng làm trước đó.

Câu hỏi này không đơn thuần kiểm tra ứng viên có biết Golang hay không, mà thiên về khả năng adapt vào một engineering environment mới.

Một engineer khi chuyển project không chỉ cần học syntax của language. Họ còn phải hiểu coding conventions, architecture, tooling, testing strategy, deployment flow và cách team tổ chức development workflow.

Kết quả: PASS

English Communication

Một điểm xuyên suốt cả 3 vòng là English communication.

Tất cả technical interviews đều được thực hiện bằng tiếng Anh, chỉ riêng HR call là không.

Theo chia sẻ của ứng viên, đây là một trở ngại khá lớn vì đây cũng là lần đầu tiên phải sử dụng tiếng Anh nhiều đến vậy trong một interview process.

Tuy nhiên, các interviewer đều khá thân thiện và ngay từ đầu đã chủ động nói rằng bản thân họ cũng không sử dụng tiếng Anh hoàn hảo. Ứng viên được khuyến khích hỏi lại nếu không hiểu câu hỏi, thay vì cố đoán requirement.

Điều này đặc biệt quan trọng trong technical interview.

Trong system design hoặc algorithm interview, việc hỏi lại không nhất thiết là dấu hiệu của việc không hiểu bài. Khi requirement chưa rõ ràng, clarification cũng là một phần của problem solving.

Interview Intelligence

1. System Design không nên bắt đầu bằng việc vẽ architecture

Một điểm đáng học từ vòng Payment System là cách tiếp cận:

Problem → Solution → Component

Thay vì bắt đầu ngay với Kafka, Redis, database hay load balancer, hãy xác định trước:

• Hệ thống cần làm gì?
• Những requirement nào là bắt buộc?
• Bottleneck nằm ở đâu?
• Failure scenario nào có thể xảy ra?
• Data nào cần lưu?
• Data nào nhạy cảm?
• Requirement nào cần consistency cao?
• Thành phần nào cần scale independently?

Sau khi những vấn đề này rõ ràng hơn, architecture components mới thực sự có lý do để xuất hiện.

2. Payment System có nhiều vấn đề hơn việc “charge tiền”

Ngay cả khi interviewer không yêu cầu thiết kế quá sâu, một Payment System thường mở ra nhiều engineering concerns:

• Idempotency: retry cùng một payment request không nên tạo ra nhiều transaction.
• Failure handling: payment provider timeout hoặc trả về trạng thái không rõ ràng thì xử lý thế nào?
• Consistency: trạng thái payment giữa hệ thống nội bộ và external payment provider phải được đồng bộ ra sao?
• Scalability: hệ thống xử lý traffic peak như thế nào?
• Security & Privacy: thông tin user/payment được lưu và access ra sao?
• Observability: làm sao trace một payment request từ lúc tạo đến khi hoàn tất?
• Retry: retry ở đâu và retry bao nhiêu lần trước khi chuyển sang cơ chế xử lý khác?

Điểm quan trọng không phải là đưa tất cả components này vào architecture ngay từ đầu.

Quan trọng hơn là nhận diện được problem và giải thích tại sao cần một mechanism tương ứng.

3. Đừng quá phụ thuộc vào “bài tủ”

Ứng viên đã chuẩn bị khá nhiều cho Chat System dựa trên interview reviews trước đó, nhưng cuối cùng lại gặp Payment System.

Điều này cho thấy việc học thuộc một vài system design template có thể không đủ để xử lý một interview mà problem thay đổi theo interviewer hoặc team.

Một framework có thể áp dụng rộng hơn là:

Requirement → Scale → Data → API → Core Components → Failure → Consistency → Security → Observability → Trade-offs

Khi framework này đã đủ chắc, việc chuyển từ Chat System sang Payment System sẽ ít phụ thuộc vào việc “đã gặp đúng bài hay chưa”.

4. Hiring Manager đang kiểm tra khả năng adapt

Câu hỏi về việc chuyển từ Java sang Golang khá đáng chú ý.

HM không chỉ hỏi “Bạn có biết Go không?”, mà muốn biết ứng viên sẽ làm gì khi bước vào một environment mà technology stack khác với những gì mình đang sử dụng.

Một cách tiếp cận có chiều sâu có thể bao phủ nhiều lớp:

Language → Codebase → Architecture → Tooling → Testing → Deployment → Team Practices

Trong engineering thực tế, học syntax của một programming language mới thường chỉ là bước đầu. Phần khó hơn là hiểu cách một team thực sự sử dụng language đó để xây dựng và vận hành production system.

5. English communication cũng là một phần của technical interview

Với interview bằng tiếng Anh, ứng viên không nhất thiết phải nói như native speaker.

Điều quan trọng hơn là có thể:

• Clarify requirement
• Explain reasoning
• Ask for missing information
• Communicate trade-offs
• Admit khi chưa hiểu
• Structure câu trả lời rõ ràng

Đặc biệt trong system design, câu “Could you clarify this requirement?” đôi khi có giá trị hơn việc lập tức đưa ra một architecture phức tạp.

Interview Process & Speed

Theo trải nghiệm của ứng viên, process tại Công ty G diễn ra khá nhanh.

Sau khi hoàn thành một vòng interview, chỉ khoảng 1–2 giờ sau ứng viên đã nhận được kết quả và lịch cho vòng tiếp theo.

Điều này khiến toàn bộ interview loop có nhịp khá nhanh, đồng thời cũng yêu cầu ứng viên có khả năng chuyển context nhanh giữa các dạng bài: từ algorithm sang system design rồi sang discussion về past experience.

Algorithm

• Valid Anagram
• Kiểm tra các phần tử trong mảng có chênh lệch nhau tối đa 1 đơn vị hay không

System Design

• Design a Payment System
• Làm thế nào để scale hệ thống?
• Xử lý exception / failure như thế nào?
• Lưu trữ user data như thế nào?
• Làm thế nào để đảm bảo privacy của user data?

Hiring Manager

• Past experience
• Past projects
• Những việc cần làm khi join một project mới
• Làm thế nào để bắt đầu khi project sử dụng một programming language mới?
• Cách tiếp cận khi chuyển từ Java sang Golang

PASS

Ứng viên pass cả 3 vòng phỏng vấn tại Công ty G.

Interview loop gồm:

Algorithm → Payment System Design → Hiring Manager