Tắt Quảng Cáo [X] Đăng Nhập để ẩn Tất Cả Quảng Cáo # **4 lỗi cần tránh khi phỏng vấn Coding Interview tại các công ty công nghệ** **#j2team_share** Coding interview (phỏng vấn viết code) là một trong những phần phỏng vấn được cho là “khó nhằn” nhất trong các module phỏng vấn vào vị trí Software hay Network Engineer tại các công ty công nghệ. Người phỏng vấn không chỉ chịu áp lực về tính thực dụng, tối ưu của những đoạn code mình viết ra, mà còn phải diễn giải thật tốt cách tư duy để giải các đề bài. Tuy nhiên, không gì là không thể cải thiện. Ở bài này, chúng ta sẽ tìm hiểu 4 lỗi sai khi tham gia phỏng vấn Coding interivew mà chúng ta cần tránh (và làm sao để có kết quả Coding interview tốt nhất). ## 1. KHÔNG NẮM VỮNG CẤU TRÚC DỮ LIỆU VÀ THUẬT TOÁN Trong coding interview, không có gì tệ hơn khi ứng viên trả lời rằng “Tôi thực sự không nắm được độ phức tạp của tính toán (Big O notation)”. Nếu bạn vẫn chưa nắm vững khái niệm này, thì đây nên là ưu tiên số 1 của bạn! Hãy đảm bảo rằng bạn nằm lòng độ phức tạp của tính toán. Hãy tạo thói quen suy nghĩ về độ phức tạp của tất cả những đoạn code mà bạn viết. Và cũng đừng quên Logarit, đây là một trong những phép toán được sử dụng rất thường xuyên mà bạn nên nắm vững. Trước khi tham gia bất kì một buổi Coding interview nào, hãy dành thời gian ôn luyện và đảm bảo rằng bạn hiểu tất cả các cấu trúc dữ liệu của khoa học máy tính. Biết điểm mạnh và điểm yếu của từng loại, và biết khi nào bạn nên sử dụng loại nào. ## 2. GIẢ VỜ HIỂU ĐIỀU MÀ BẠN KHÔNG HIỂU Đó là một sai lầm rất dễ mắc phải. Không chỉ trong Coding interview mà nó còn xuất hiện tại hầu hết các hình thức interview khác. Tâm lý chung của các ứng viên là “Đẹp khoe xấu che”. Bạn luôn muốn thể hiện những gì tốt nhất của bản thân và giấu đi những phần bạn không biết hoặc không nắm vững. Điều này không có gì sai. Tuy nhiên, cách xử lý này là một con dao hai lưỡi. Hầu hết những người phỏng vấn bạn về chuyên môn (cụ thể là coding interview) là những người có chuyên môn và kinh nghiệm ngang bằng hoặc cao hơn bạn. Họ sẽ dễ dàng “nắm thóp” được bạn khi bạn cố gắng giấu những yếu điểm trong code của mình. Trong trường hợp này, thành thực lại là giải pháp tốt hơn. Hãy nhớ rằng, không ai biết hết mọi thứ. Một thái độ thành thực và cầu tiến sẽ gây ấn tượng tốt hơn với nhà phỏng vấn, thay vì cố gắng che giấu khuyết điểm và cuối cùng vẫn bị lộ. Khi người phỏng vấn của bạn nói điều gì đó mà bạn không hiểu, hãy chỉ ra ngay lập tức, và đừng ngại nhờ họ giải thích lại. Bởi vì để họ nghĩ rằng bạn hiểu (trong khi bạn thực sự không hiểu) sẽ chỉ khiến mọi thứ trở nên lộn xộn sau này. Cố gắng trình bày cụ thể nhất có thể về những gì bạn không hiểu. Nó làm cho suy nghĩ của bạn nghe có tổ chức hơn nhiều. ## 3. VIẾT CODE TRƯỚC KHI BẠN BIẾT ĐOẠN CODE ĐÓ ĐỂ LÀM GÌ Một số người do thiếu kinh nghiệm phỏng vấn, và cũng chưa thật sự vững thuật toán thường có xu hướng vội vàng viết code do lo sợ thiếu thời gian. Điều này là không nên. Thay vào đó, hãy dành một chút thời gian để hoạch định cho toàn bộ lời giải của bạn. Hãy hít thở sâu. Lo lắng về thời gian sẽ không khiến bạn giải quyết vấn đề nhanh hơn. Nó thậm chí còn khiến bạn rơi vào tình trạng rối rắm và cuối cùng kết thúc với một mớ bòng bong. Hãy vẽ một bức tranh về cấu trúc dữ liệu, hãy động não, và hãy bình tĩnh. Việc không biết lời giải ngay lập tức là một điều rất bình thường và nó không có nghĩa là bạn kém cỏi. Trong thực tế, nếu bạn tìm được lời giải hợp lý ngay lập tức cho mọi bài toán trong Coding interview thì có lẽ bạn là một thiên tài! ## 4. VỘI VÀNG BỎ QUA DEBUG Sau khoảng 45 phút, bạn đã viết xong lời giải của mình. Bạn nhìn người phỏng vấn của mình một cách đầy kỳ vọng - bạn chỉ chờ họ nói, “Quá hoàn hảo!" (đoạn này hơi mơ mộng tí ). Nhưng thay vào đó, họ nói "bạn có thể tìm thấy bất kỳ lỗi nào trong code của mình không?" Bạn hy vọng đó là một câu hỏi mẹo, nhưng bạn miễn cưỡng nhìn lại code của mình. Bạn xem qua từng dòng, nhưng bạn không thực sự debug. Bạn chỉ đang giải thích ý định của từng dòng. Có một câu rất hay khi mô tả về điểm mù của một người là "bạn chỉ nhìn thấy những gì bạn muốn thấy". Vì vậy, nếu bạn không tỉnh táo và có cái đầu lạnh thì rất có thể, bạn sẽ bỏ lỡ các lỗi. Và tất nhiên, người phỏng vấn của bạn nhìn thấy chúng. Đây là một vài gợi ý cách debugging trong trường hợp xấu nhất - bạn phải viết code lên bảng trắng: Đầu tiên, hãy viết ra một đầu vào mẫu (input sample), input sample của bạn nên đủ ngắn để thử nghiệm, nhưng cũng nên đủ dài để đó không phải một trường hợp khó. Sau đó, xem qua từng dòng code của bạn. Khi bạn thay đổi đầu vào, hãy thực sự thay đổi nó trên bảng. Nếu nó tạo ra các biến mới, hãy viết các biến đó lên bảng. Đúng vậy - bạn đang sử dụng bộ não của mình làm bộ xử lý máy tính và bảng trắng làm bộ nhớ máy tính. Thật tẻ nhạt, nhưng đó là cách duy nhất để gỡ lỗi mã trên bảng trắng. Và khi bạn đã hoàn tất, hãy làm điều tương tự với tất cả các trường hợp phổ biến. Mảng trống, mảng một phần tử, số âm, đồ thị bị ngắt kết nối, v.v. Đó là một số lỗi coding interview phổ biến nhất. Nếu bạn có thể tránh được chúng, bạn đã có lợi thế hơn rất nhiều ứng viên khác! Bây giờ, việc còn lại của bạn là thực hành và thực hành. Hãy ôn luyện để nắm vững thuật toán và cấu trúc dữ liệu. Bên cạnh đó, nếu có cơ hội, hãy tham gia mock interview để làm quen với không khí của các buổi phỏng vấn. Bằng cách này, chắc chắn bạn sẽ đạt được kết quả tốt nhất trong các bài phỏng vấn Coding interview. Chúc các bạn may mắn! Nguồn: Future Software Engineers
một tip nữa là tương tác với interviewer, đừng mãi gõ mà nên nói kèm giải thích cho ý tưởng và những gì mình sắp code
Copy paste code vừa viết để duplicate trong lúc interview, đặt tên hàm, tên biến, tên class, access modifier để là public khi không cần thiết, không dùng shortkey của IDE... Còn nhiều cái lắm
klq nhưng mấy cty tầm khá trở xuống ở VN có hay phỏng vấn thuật toán viết code này nọ ko nhỉ, giả sử có đi thì ng pv gặp mấy đứa sinh viên chuyên gia cày trên leetcode, codforces thì có sợ bị quê hay out trình ko
Bài viết rất hay. Cá nhân mình thấy cũng tùy yêu cầu của từng đơn vị song muốn sử dụng lâu dài kiểu gì cũng phải bỏ thời gian đào tạo thêm. Nhân viên mà cái gì họ cũng biết và hiểu , họ ở tầm quản lý rồi