Tương tự như STAR model (Situation, Task, Action, Result) — một cái technique để trả lời các câu hỏi khi phỏng vấn thì đây là một cái guideline để trả lời các câu hỏi coding khi phỏng vấn vào các công ty công nghệ.
Lý do vì sao chúng ta cần có technique hay guideline thì chắc ai cũng biết. Vì đôi khi trong lúc phỏng vấn bạn sẽ lo lắng tới mức không biết mình nên nói gì tiếp theo, khiến cho bạn nói lan man, thiếu này thiếu nọ, nói lặp đi lặp lại vài thứ.
Bên cạnh đó, người phỏng vấn sẽ sử dụng ít nhất là 3 tiêu chí này để đánh giá một ứng cử viên:
- Khả năng giải quyết vấn đề.
- Kỹ năng giao tiếp.
- Kỹ năng code.
Cả ba kỹ năng này đều quan trọng. Tuy nhiên, nếu khả năng giao tiếp của bạn không tốt, người phỏng vấn sẽ khó có thể hiểu được hướng giải quyết vấn đề của bạn. Điều đó dẫn tới những đánh giá sai các skill khác bạn.
Vì thế mình đã tự chuẩn bị một guideline in very detail — 10 bước để trả lời một câu hỏi coding challenge. Mình đã thử và thành công còn bạn thì sao˜˜!✌️
- Làm rõ câu hỏi.
Khi nhận câu hỏi, nếu người phỏng vấn không đưa đề bài dạng text mà nói miệng thì bạn nên ghi lại / gõ lại những gì bạn nghe để đảm bảo mình hiểu đúng và đủ ý người phỏng vấn.
Sau khi nhận được câu hỏi, ngay lập tức đi làm rõ lại câu hỏi bằng cách hỏi lại người phỏng vấn các câu hỏi liên quan tới đề bài. Không phải câu hỏi phỏng vấn lúc nào cũng rõ ràng (không có nghĩa là câu hỏi sai hay đố mẹo). Bạn hoàn toàn có thể bị sót những thông tin ẩn (cần khai thác) của đề bài.
Những câu hỏi mình hay hỏi interviewer như sau (mình viết tiếng Anh nhé):
- Can the array be empty?
- Are there any negative numbers in the input array?
- Do I need to handle duplicates (or whitespace, or case-sensitive)?
- Are there any cycles in the graph?
- Are there any zero leading numbers?
Đặt câu hỏi còn là một cách cho người phỏng vấn thấy được bạn là một người cẩn thận. Nhưng lưu ý, đừng tốn quá nhiều thời gian cho việc đặt câu hỏi (tầm 5 phút thôi). Bạn phải tiết kiệm thời gian cho 9 bước tiếp theo nữa!
2. Hỏi test case và tạo thêm test cases.
Nếu người phỏng vấn không cho bạn bất cứ một input và output mẫu nào, bạn hoàn toàn có thể xin một test case mẫu.
Nếu họ đã đưa cho bạn test case, bạn có thể (nên) đưa ra thêm một vài test cases (input và output) nữa, đặc biệt là các trường hợp đặc biệt (corner case) để chắc chắn rằng bạn hiểu chính xác yêu cầu đề bài.
3. Đưa ra cách làm hiển nhiên nhất (mình hay gọi là naive solution).
Sau khi xong bước kiểm tra đề bài, mình luôn bắt đầu với một cách làm hiển nhiên nhất mà mình có thể nghĩ ra trong vòng chưa tới 1 phút. Thế thì làm sao để nghĩ 1 lời giải trong vòng 1 phút:
- Tất cả những gì nảy ra trong đầu bạn: backtracking, dùng ba bốn vòng lặp, đề kêu gì làm đó,…
- Tập một thói quen khi tự luyện tập trước phỏng vấn: khi đọc xong đề bài xong cố gắng nghĩ liền tới bất cứ một cách giải nào trong vòng 1 phút, đừng cố gắng nghĩ tới optimal solution khi vừa đọc đề bài xong.
Đừng quên phân tích độ phức tạp thuật toán sau khi đưa ra cách giải này nhé.
4. Tìm cách cải tiến.
Chắc chắn cách làm hiển nhiên sẽ khó có khả năng là cách làm tốt nhất rồi :)) Đưa ra cho có vậy thôi :))
Ở bước này chúng ta sẽ tìm một cách giải tốt hơn, không phải là cách giải tốt nhất.
Nếu bạn cho rằng mình cứ phải nghĩ tới cách làm tốt nhất thì mới đậu phỏng vấn thì bạn sai rồi. Đưa ra một lời giải tối ưu không quyết định bạn có đậu phỏng vấn hay không và ngược lại. Người phỏng vấn đặc biệt quan tâm tới quá trình suy nghĩ của ứng viên hơn là lời giải. Mình có giải thích ở trong bài viết này.
Sau 5 phút suy nghĩ ở bước này, nếu bạn không thể nghĩ ra một cách giải nào tốt hơn, hãy nhờ người phỏng vấn gợi ý. Khi người phỏng vấn đưa ra cho bạn một gợi ý, hãy bám sát nó và tiếp tục triển khai. Đừng quên tiếp tục thảo luận với người phỏng vấn những gì mình đang suy nghĩ đến.
Quan trọng không kém, khi suy nghĩ nên nói những gì mình nghĩ ra thành lời, đừng im lặng. Thứ nhất là để người phỏng vấn biết bạn đang nghĩ gì, sai chỗ nào, họ có thể giúp bạn sửa sai hoặc giúp bạn đi tiếp nếu thấy bạn đi gần tới. Thứ hai là cố gắng thể hiện kĩ năng giao tiếp (communication skill) và kĩ năng làm việc nhóm (collaboration skill).
5. Kiểm tra cách làm hiện tại.
Sau khi có cách làm rồi, đừng vội lao vào code ngay, đầu tiên bạn phải kiểm tra lại lần nữa rằng cách làm hiện tại liệu có cho ra kết quả đúng hay không bằng cách thử lại với một test case mình đã đưa ra ở bước 2 👆.
6. Phân tích độ phức tạp của bài toán.
Phân tích độ phức tạp của thuật toán là cực kì quan trọng, mình cũng đã giải thích trong tập trước rồi ✌️.
7. Tổng kết lại cách làm trước khi bắt đầu code.
Trong lúc phỏng vấn mình luôn cố gắng giao tiếp với người phỏng vấn nhiều nhất có thể. Không phải là nói nhiều nhưng cũng nên hỏi thăm để xem hai bên có hiểu ý nhau không. Tóm tắt lại cách làm mà bạn sẽ code giúp cho người phỏng vấn có thể dễ dàng theo dõi code của bạn. Hơn thế nữa, tóm tắt nhanh lại cách làm còn giúp cho bạn code nhanh và tránh được những thiếu sót.
8. Bắt đầu code.
Thường mình sẽ bắt đầu định nghĩa hàm trước, ví dụ như:
Để giải quyết bài toán này, chúng ta có một hàm solution, nhận vào hai biến a và b, và trả về một số integer là kết quả bài toán. Vừa nói vừa type:
Sau đó mình sẽ vừa code vừa giải thích từng dòng, không cần dừng lại và nói quá kĩ vì sẽ rất mất thời gian. Nhưng ít nhất cũng nên giải thích được vòng lặp này dùng để làm gì, những biến số (trừ biến của vòng lặp :)) ).
Nhiều bạn cảm thấy lo lắng khi quên syntax rồi code kiểu hên xui như đánh trắc nghiệm. Nhưng theo mình quên syntax là chuyện rất bình thường, nếu bạn không chắc chắn bạn có thể hỏi người phỏng vấn, nếu người phỏng vấn không rành ngôn ngữ bạn đang code thì họ cũng sẽ châm chước cho bạn đoạn code đó thôi.
9. Kiểm tra lại code.
Đừng vội kết thúc câu trả lời sau khi code xong. Nếu còn thời gian, bạn hãy kiểm tra code code bằng cách tự nhẩm chạy từng dòng lệnh với những test cases bạn đã đưa ra (càng nhiều càng tốt).
Sau đó kiểm tra lại độ phức tạp thời gian và không gian có giống như mình đưa ra hay không. Đôi khi bạn sẽ có những dòng code không được tốt lắm khiến cho độ phức tạp bài toán bị đội lên (ví dụ như việc xài built-in function).
Cuối cùng là xem lại code xem có thể refactor lại được hay không? Ví dụ như các biến không cần thiết sử dụng, gộp hai vòng for,…
10. Bàn rộng hơn về bài toán.
Cái này là không bắt buộc. Nếu vẫn còn dư thời gian, bạn có thể suy nghĩ và thảo luận thêm liệu có cách giải quyết nào tốt hơn hay không hoặc thảo luận thêm những trường hợp đặc biệt của bài toán. Ví dụ như là bài toán này có thể giải theo cách khác, tốn space hơn nhưng ít time hơn hoặc ngược lại.
Cuối cùng là chúc mọi người may mắn với vòng phỏng vấn của mình nhé :v
