Software Engineer

Tổng quan

Đây là trải nghiệm phỏng vấn cho vị trí Software Engineer tại Công ty G, gồm 3 vòng:

Algorithm → System Design → Culture Fit

Theo quan sát của ứng viên, các vòng được thiết kế khá liền mạch: Round 1 kiểm tra problem-solving qua những dạng algorithm quen thuộc, Round 2 chuyển sang system design gắn với background thực tế, còn Round 3 dành cho Hiring Manager tập trung mạnh vào past experience và technical deep dive.

Một điểm đáng chú ý trong trải nghiệm này là ứng viên chủ động nghiên cứu pattern phỏng vấn trước khi chuẩn bị. Thay vì ôn toàn bộ LeetCode, ứng viên tập trung vào những nhóm bài mà mình quan sát thấy xuất hiện nhiều như Binary Search, Array, Sliding Window và Hash Table.

Round 1 — Algorithm

Vòng đầu tiên tập trung vào algorithm.

Theo quan sát cá nhân của ứng viên, các nhóm Binary Search, Array, Sliding Window và Hash Table là những dạng đáng ưu tiên khi chuẩn bị cho interview tại Công ty G.

Ứng viên vì vậy không ôn dàn trải mà tập trung vào các pattern này, đồng thời tìm hiểu thêm những dạng câu hỏi thường xuất hiện trong các interview process của các công ty công nghệ lớn.

Problem 1 — Binary Search

Bài đầu tiên là một câu Easy, xoay quanh Binary Search.

Input là một sorted array, yêu cầu tìm giá trị cần thiết; nếu giá trị cần tìm không tồn tại thì trả về phần tử lớn hơn gần nhất.

Điểm quan trọng của bài không nằm ở việc implement Binary Search cơ bản, mà ở cách xử lý boundary:

• Target có tồn tại hay không?
• Nếu không tồn tại thì vị trí nào là phần tử lớn hơn gần nhất?
• Target nhỏ hơn toàn bộ array thì trả về gì?
• Target lớn hơn toàn bộ array thì xử lý thế nào?
• Có duplicate hay không?

Đây là dạng bài khá tốt để kiểm tra việc ứng viên có thực sự hiểu search invariant và boundary condition hay chỉ nhớ template Binary Search.

Problem 2 — Invalid Transaction

Bài thứ hai là bài Invalid Transaction.

Theo chia sẻ của ứng viên, đề bài tương đối dài và điểm khó không nằm ở một algorithm quá phức tạp mà ở việc đọc kỹ requirement và xử lý corner cases.

Dù đề dài hơn, hướng giải vẫn chủ yếu xoay quanh Array và data processing.

Dạng bài này thường tạo ra một kiểu challenge khác với những câu LeetCode thuần algorithm: ứng viên phải xác định chính xác transaction nào được xem là invalid, sau đó đảm bảo implementation không bỏ sót những trường hợp biên.

Kết quả Round 1: chưa được ứng viên ghi rõ trong source.

Round 2 — System Design

Round 2 chuyển sang System Design.

Theo quan sát của ứng viên, đề system design có thể phụ thuộc khá nhiều vào team và background của candidate.

Một số hướng mà ứng viên quan sát thấy gồm:

• Chat System
• System Design liên quan trực tiếp đến team ứng tuyển
• System Design liên quan đến domain mà ứng viên đang làm

Ví dụ, nếu ứng viên làm ở một team liên quan đến payment thì bài toán có thể xoay quanh Payment System; trong trường hợp khác, interviewer có thể chọn một problem gần với domain hiện tại của candidate.

Design Meeting Booking System

Trong interview này, ứng viên được hỏi:

Design a Meeting Booking System

Đây cũng là một lựa chọn khá sát với background vì ứng viên đang làm trong mảng booking.

Điểm thú vị của dạng bài này là domain familiarity có thể giúp ứng viên hiểu requirement nhanh hơn, nhưng đồng thời interviewer có thể đi sâu hơn vào những vấn đề mà candidate đã từng gặp trong production.

Một system design cho meeting booking có thể bắt đầu từ những requirement cơ bản:

• User tạo meeting
• Chọn thời gian
• Mời participants
• Kiểm tra availability
• Xác nhận booking
• Cancel / update meeting

Sau đó bài toán có thể mở rộng sang những vấn đề mang tính hệ thống hơn:

• Làm thế nào để tránh double booking?
• Nếu hai request cùng lúc đặt cùng một time slot thì xử lý thế nào?
• Availability được lưu và query ra sao?
• Làm thế nào để scale khi số lượng booking tăng?
• Khi booking thành công nhưng notification thất bại thì state của hệ thống là gì?
• Làm thế nào để xử lý timezone?
• Nếu một meeting có nhiều participants thì consistency được đảm bảo như thế nào?

Với dạng bài này, việc hiểu domain là lợi thế, nhưng interviewer vẫn có thể dùng follow-up để kiểm tra khả năng reason về concurrency, consistency và failure handling.

Kết quả Round 2: chưa được ứng viên ghi rõ trong source.

Round 3 — Culture Fit & Hiring Manager

Round 3 được thực hiện với Hiring Manager (HM).

Theo chia sẻ của ứng viên, thời gian được chia tương đối cân bằng giữa:

Technical → Culture Fit

Phần culture fit không được ứng viên đánh giá là quá nặng và có thể chuẩn bị bằng cách tham khảo các nhóm behavioral questions phổ biến.

Phần đáng chú ý hơn nằm ở technical discussion.

Technical Deep Dive

HM tập trung nhiều vào past experience của ứng viên.

Đặc trưng của vòng này là cách hỏi khá freestyle: interviewer có thể bắt đầu từ một project trong CV, sau đó liên tục đào sâu vào những quyết định kỹ thuật mà ứng viên đã đưa ra.

Ví dụ, từ một project có thể tiếp tục đi vào:

• Tại sao chọn technology này?
• Architecture lúc đó như thế nào?
• Bạn trực tiếp chịu trách nhiệm phần nào?
• Bottleneck lớn nhất là gì?
• Tại sao không chọn approach khác?
• Nếu traffic tăng thì design hiện tại có còn phù hợp không?
• Bạn đã gặp failure nào?
• Bạn xử lý incident như thế nào?
• Có trade-off nào mà lúc đầu lựa chọn chưa tốt không?

Điều này khiến việc “biết nhiều về project mình từng làm” trở nên quan trọng.

Nếu một technology hoặc architectural decision xuất hiện trong CV, ứng viên nên chuẩn bị tinh thần rằng interviewer có thể không dừng ở mức “Bạn đã sử dụng X”, mà sẽ hỏi tiếp “Tại sao X?”, “X hoạt động như thế nào?” và “Nếu scale lên thì sao?”.

Interview Intelligence

1. Ôn theo pattern có thể hiệu quả hơn ôn dàn trải

Ứng viên chủ động quan sát các dạng câu hỏi xuất hiện trong những interview trước rồi tập trung vào:

Binary Search → Array → Sliding Window → Hash Table

Đây là một chiến lược preparation hợp lý về mặt thời gian nếu candidate đã có giới hạn về thời gian ôn tập.

Tuy nhiên, thay vì học thuộc từng bài, nên học theo pattern.

Ví dụ với Binary Search, mục tiêu không chỉ là nhớ template mà phải nhận ra:

• Search exact value
• Lower bound
• Upper bound
• First / last occurrence
• Search trong một answer space
• Boundary conditions

Khi đó, một đề bài có wording khác vẫn có thể quy về cùng một nhóm tư duy.

2. Đề dài không đồng nghĩa algorithm khó

Invalid Transaction là ví dụ khá điển hình.

Một problem có statement dài có thể khiến candidate cảm thấy khó hơn, nhưng phần algorithm phía sau đôi khi vẫn tương đối đơn giản.

Challenge thực sự có thể nằm ở:

Requirement parsing → Condition extraction → Edge cases → Implementation

Vì vậy, khi gặp một đề dài, thay vì code ngay, nên chuyển statement thành những điều kiện rõ ràng trước.

Ví dụ:

Transaction hợp lệ khi nào?

Transaction invalid khi nào?

Các điều kiện có độc lập với nhau không?

Có trường hợp nào hai rule cùng trigger không?

Cách làm này giảm đáng kể khả năng bỏ sót corner case.

3. System Design gắn với domain có lợi thế nhưng cũng có mặt trái

Meeting Booking System khá gần với domain hiện tại của ứng viên.

Điều này giúp candidate có thể nhanh chóng hiểu business context và đưa ra những scenario thực tế.

Nhưng khi interviewer biết candidate có domain experience, follow-up cũng có thể đi sâu hơn.

Một câu trả lời tốt không chỉ là:

“Em đã từng làm booking system nên em biết cách design.”

Mà cần giải thích được:

Requirement → Constraint → Architecture → Trade-off

Ví dụ, với booking system, câu hỏi về double booking có thể ngay lập tức dẫn đến concurrency control và consistency.

Nếu hai user cùng book một resource tại cùng thời điểm, system cần đảm bảo không có hai request cùng được xác nhận thành công cho cùng một slot.

Đây là lúc system design chuyển từ việc “vẽ vài boxes” sang reasoning về data consistency và concurrency.

4. HM round có thể biến CV thành syllabus

Một điểm rất đáng chú ý của Round 3 là technical discussion đi theo past experience.

Điều đó có nghĩa là CV không chỉ là tài liệu để HR screening.

Mỗi technology, project hoặc architectural decision được đưa vào CV đều có thể trở thành điểm bắt đầu cho một chuỗi follow-up.

Một cách chuẩn bị hiệu quả là chọn từng project quan trọng và tự trả lời:

• Tôi đã xây dựng cái gì?
• Tôi trực tiếp làm phần nào?
• Tại sao chọn architecture này?
• Technology này giải quyết vấn đề gì?
• Alternative là gì?
• Bottleneck nằm ở đâu?
• Failure scenario nào từng xảy ra?
• Nếu scale 10x thì thay đổi gì?
• Nếu làm lại từ đầu, tôi sẽ thay đổi điều gì?

Nếu trả lời được những câu này, candidate sẽ chủ động hơn rất nhiều khi HM bắt đầu deep dive.

Nhìn lại interview process

Ba vòng tạo thành một progression khá rõ:

Algorithm → System Design → Experience Deep Dive

Round 1 kiểm tra khả năng nhận diện algorithm pattern và xử lý edge cases.

Round 2 kiểm tra khả năng chuyển từ domain knowledge sang system-level reasoning thông qua Meeting Booking System.

Round 3 lại quay về những gì ứng viên thực sự đã làm, với trọng tâm là technical depth và khả năng giải thích engineering decisions.

Theo trải nghiệm của ứng viên, việc nghiên cứu pattern phỏng vấn trước khi chuẩn bị giúp thu hẹp phạm vi ôn tập. Tuy nhiên, đến vòng HM, kiến thức trong CV và mức độ hiểu sâu về những project từng làm mới trở thành phần khó có thể “học tủ”.

Nếu một vòng interview không đạt như kỳ vọng, ứng viên cũng chia sẻ một takeaway khá thực tế: đừng để một kết quả interview trở thành kết luận về năng lực của bản thân; xem nó như feedback cho vòng chuẩn bị tiếp theo.

Round 1 — Algorithm

• Binary Search
• Tìm giá trị trong sorted array
• Nếu target không tồn tại, tìm phần tử lớn hơn gần nhất
• Invalid Transaction
• Corner cases trong bài toán transaction

Round 2 — System Design

Design a Meeting Booking System

Các chủ đề có thể được đào sâu:

• Meeting availability
• Booking flow
• Double booking
• Concurrency
• Consistency
• Scalability
• Failure handling
• Notification
• Timezone

Round 3 — Hiring Manager

• Past experience
• Past projects
• Technical decisions trong project
• Technology choices
• Architecture
• Challenges đã gặp
• Cách xử lý technical issues
• Trade-offs
• Culture fit
• Behavioral questions

Kết quả: Pass

Interview loop gồm:

Algorithm → System Design → Culture Fit & Hiring Manager