My first journey — What I learnt from coding interview
Kết thúc phần 1, phần hai mình sẽ tập trung nói tất tần tật về những kinh nghiệm dành cho phần Coding Interview, phần quan trọng nhất khi bạn muốn phỏng vấn cho vị trí Software Engineer.
Xu hướng phỏng vấn đầu vào thuật toán (coding interview) ở các công ty công nghệ Việt Nam ngày càng trở nên phổ biến. Bài viết này mình không chỉ hướng tới cách công ty công nghệ lớn, mà còn dành cho những bạn muốn phỏng vấn các công ty công nghệ ở Việt Nam. Những gì mình chia sẻ sau đây cũng không quá khác những nguồn luyện interview khác. Nhưng mình sẽ tóm tắt những thứ mình cho là rất quan trọng cho một buổi phỏng vấn tốt theo kinh nghiệm của mình.
Câu hỏi phỏng vấn
Những câu hỏi phỏng vấn cũng xoay quanh những thuật toán rất cơ bản, các bạn có thể tìm hiểu những thuật toán đó trong cuốn Cracking the Coding Interview. Khả năng cao bạn sẽ không bị hỏi những thuật toán nằm ngoài đó đâu. Như mình đã đề cập nguồn tài liệu ở bài trước, bạn có thể luyện thêm trên những website như leetcode, hackerrank, hoặc interviewbit.
Bao nhiêu câu hỏi cho một buổi phỏng vấn
Có một vài chia sẻ là một buổi phỏng vấn thường có hai câu hỏi. Nhưng những gì mình trải nghiệm, mình đã từng có buổi phỏng vấn chỉ có 1 câu hỏi và một câu follow up, hoặc chỉ một câu hỏi hơi khoai (khoai với mình), hoặc có tới 3 câu.
Các lỗi sai mà chúng ta thường mắc phải.
- Không làm rõ lại đề bài.
Không phải đề bài phỏng vấn nào cũng sẽ rõ ràng. Không rõ ràng ở đây không có nghĩa là khó hiểu hay đánh đố. Đề bài sẽ được đưa ra một cách tổng quát nhất. Công việc của bạn là làm rõ lại đề bài. Những câu hỏi các bạn có thể hỏi để làm rõ đề bài đại loại như:
- Mảng này có thể rỗng không?
- Mảng có chứa số âm không?
- …
Đừng tự giả định bất cứ điều gì trong đề bài phỏng vấn. Việc đặt câu hỏi cũng giúp bạn ghi điểm với interviewer, họ sẽ cảm nhận được sự cẩn thận của bạn.
Có thể đưa ra thêm một vài testcase (input/output) để xác định là bạn đang hiểu chính xác câu hỏi.
2. Không phân tích độ phức tạp.
Theo cá nhân mình thì phân tích độ phúc tạp mỗi khi đưa ra một thuật toán rất quan trọng. Giống như nó là thứ duy nhất có thể chứng minh cách làm của bạn tốt hay chưa. Ví dụ một bài bạn có thể nghĩ tới được 2 solution, thì việc bạn chỉ ra độ phức tạp sẽ giúp bạn lựa chọn nên làm cách nào. Bạn nên đưa ra độ phức tạp trước khi bắt tay vào code. Có thể kèm theo câu hỏi kiểu “Đây có phải là cách làm tối ưu mà bạn đang mong muốn không?”. Đây là một trong những điểm khác biệt trong hai lần mình phỏng vấn với Facebook (một đậu một rớt T.T).
3. Lao vào code một cái thuật toán chưa tốt.
Có nhiều bạn cứ một mạch đưa lời giản, độ phức tạp rồi bắt tay code luôn. Không thảo luận với người phỏng vấn là bạn đã làm tốt chưa, bạn có cần cải tiến gì không,… Đôi khi bạn đang hiểu sai đề, đôi khi bạn đang làm sai hướng, hoặc bạn làm chưa tối ưu (gần sắp tới). Nếu bạn thảo luận, người phỏng vấn phần lớn sẽ rất vui vẻ chỉ ra cho bạn lỗi sai.
Nghe có vẻ kì lạ phải không? Ai lại đi chỉ bài cho ứng viên bao giờ. Nhưng mình luôn giữ một quan điểm khi phỏng vấn: “Họ phỏng vấn để tuyển mình, không phải phỏng vấn để loại mình.” Tâm lý mình phần nào cũng sẽ ổn hơn, cái suy nghĩ tích cực cũng sẽ làm cho bạn tự tin hơn, não hoạt động tốt hơn.
Lần đầu tiên phỏng vấn FB, mình cũng làm một mạch hết hai bài. Excellent. Và rớt. Mình đã giải thích không quá nhiều. Mình cũng không thảo luận với người phỏng vấn là idea mình như thế nào. Vì lúc đó mình rất tự tin là mình biết làm bài này. :))
Vì thế, thậm chí khi bạn có chắc chắn là thuật toán mình đã tốt rồi (vì bạn đã từng làm bài này rồi), thì cũng nên thảo luận với người phỏng vấn. Như thế bạn cũng đã thể hiện được cái team work ability rồi.
4. Tạo test để kiểm tra lại code.
Sau khi làm, nếu còn thời gian bạn nên kiểm tra lại code một lần nữa. Hoàn hảo hơn nữa, bạn có thể tự tạo một vài testcase và coi thuật toán mình làm việc đã đúng chưa. Theo mình, bạn có phát hiện ra lỗi sai mà hết giờ vẫn được đánh giá cao hơn là bạn không kiểm tra lại code.
Thông thường mình sẽ tạo hết testcase ví dụ như chuỗi rỗng, mảng rỗng, toàn số âm, có số 0, … một vài trường hợp đặt biệt như vậy thôi thì người phỏng vấn cũng cảm giác được bạn cẩn thận rồi.
5. Đừng ngại hỏi hint
Không có bất kì vấn đề gì nếu bạn hỏi người phỏng vấn một cái hint khi bạn đang bí. Đừng ngại hỏi. Như mình đã đề cập phía trên, hầu hết các bạn phỏng vấn sẽ đều vui vẻ giúp bạn. Nhưng nên nhớ rằng, hỏi hint ở đây là một vài cái hint, tránh hỏi hint cả bài nhé.
Trong các buổi phỏng vấn thì mình thích phỏng vấn với Google nhất. Vì 80% các câu mình được hỏi mình chưa gặp bao giờ. Mình đã ‘phải’ hỏi hint vài bài. Nhưng hỏi hint như thế nào cho trí tuệ :)) Là một khi bạn đã đưa hint, bạn nên bám sát vào cái hint đó để phát triển ra, không nên nhận được một cái hint rồi lại tiếp tục với hướng đi của mình. Đợt đó mình còn pass phỏng vấn với positive feedback nữa.
ME AT GOOGLE SINGAPORE
6. Bối rối khi quên syntax lúc phỏng vấn
“Nên chọn một ngôn ngữ mà mình thông thạo nhất, không nên quên syntax trong phỏng vấn” không có nghĩa là không được quên. Chuyện quên là chuyện hết sức bình thường nếu bạn đã không sử dụng nó một thời gian. Điều này hoàn toàn có thể xảy ra với bất cứ lập trình viên nào.
Có lần mình đi phỏng vấn onsite ở một big tech ở Việt Nam. Mình “run code” mãi không được, thế là mình xin phép bạn phỏng vấn cho mình lên Google kiểm tra syntax. Bạn đó ok luôn. Và mình vẫn đậu lần phỏng vấn đó.
Một vài câu chuyện “bựa”
Lần thứ hai mình phỏng vấn Facebook, bài đầu tiên mình đã hiểu sai đề rồi. Mình đưa ra một O(n) solution. Nhưng bạn phỏng vấn bảo là bạn đó muốn O(logn). Hoang mang khủng khiếp. Rồi mình lấy hết bình tĩnh ngồi chứng minh là “Với bài toán này mình không thể nào nghĩ được O(logn)” (thật dũng cảm). Xong bạn nói là mình hiểu sai đề rồi. Lại vẫn đậu.
Một vòng phỏng vấn onsite ở Google, mình đã tự kiếm ra cái solution vớ vẩn nào đó dùng KMP. Mà 2 năm rồi không đụng tới KMP làm sao mình nhớ nó code như nào. Mình thẳng thắn luôn với người phỏng vấn. “Em quên cách code rồi, cho em chừa lại tí code tiếp hàm này nhé.” Bạn ấy đồng ý. Còn 15 phút cuối mình quay lại chứng minh lại nguyên cái KMP. Trông ảnh thích thú lắm. Rồi mình bay vô code nhăng code cuội. Chả biết code đúng hay không nhưng vẫn đậu.
Mình chưa làm người phỏng vấn bao giờ hết nên không thể nào nói được là nguời phỏng vấn nghĩ gì (giờ mà đi làm người phỏng vấn chắc cũng không được ngồi đây chém gió). Nhưng theo cá nhân mình cảm nhận sẽ là như vậy. Nghĩa là dù bạn có không đi tới lời giải cuối cùng, nhưng cách suy luận của bạn hay, bạn cũng sẽ có khả năng không rớt. Bạn có đi tới lời giải cuối cùng mà không có một tí logic nào trong suy luận bạn vẫn có thể rớt. Đó là lí do vì sao ở tập 1 mình bảo bạn không nên học thuật lời giải. Học thuật 500 bài leetcode chưa chắc bạn sẽ đậu phỏng vấn.
Ngoài những điều mình chia sẻ dưới đây, nếu bạn nào có thêm câu hỏi thì cứ bình luận phía dưới nhé 👇👇👇!!!
