Gần đây tôi đã có một cuộc tranh cãi với một lập trình viên đồng nghiệp. Ông đang phỏng vấn cho một vị trí mới và được hỏi câu hỏi này:

Đưa ra một chuỗi các số bắt đầu từ X và kết thúc bằng Y nhưng thiếu một phần tử nên N là YX-1, tìm phần tử bị thiếu trong O (N) hoặc tốt hơn.

Bây giờ, câu trả lời là không liên quan ở đây (nhưng thú vị). Điều này đã bắt đầu một cuộc thảo luận về việc liệu đây có phải là một câu hỏi hay để hỏi trong một cuộc phỏng vấn.

Một mặt: Thuật toán là một phần kế thừa của lập trình và khả năng trả lời câu hỏi của ứng viên này cho thấy ứng viên này sẽ là một lập trình viên giỏi và có thể giải quyết các vấn đề lớn hơn và có thể xử lý hầu hết các nhiệm vụ lập trình dễ hiểu và dễ trả lời.

Mặt khác: Viết thuật toán từ đầu hiếm khi được sử dụng trong lập trình hiện đại và do đó không liên quan trong câu hỏi lớn hơn về việc liệu người đó sẽ là một lập trình viên giỏi. Một người có thể trả lời thành công câu hỏi này nhưng vẫn không thể thực hiện các nhiệm vụ lập trình phổ biến hơn.

Suy nghĩ của bạn? Câu hỏi phỏng vấn tốt hay không?

Tôi đồng ý với việc đặt câu hỏi về thuật toán, nhưng tôi không đồng ý với việc nhấn mạnh vào mức chất lượng O lớn cụ thể.

Đặt loại câu hỏi này rất thú vị để xem cách người đó tiếp cận vấn đề và những cạm bẫy mà họ xem xét trong nỗ lực của họ, nhưng trừ khi họ viết một cái gì đó không chính xác hoặc không hiệu quả, chi tiết thực tế của những gì họ viết không phải là sự thật như họ nói có được thông qua các bước giải quyết vấn đề / thiết kế một cách mạch lạc.

Tôi hỏi một câu hỏi tương tự, nhưng những người mà tôi gặp may mắn nhất sau khi thuê là những người đưa ra câu trả lời thiếu sót nhưng có ý tưởng chính xác trong cách tiếp cận của họ.

Tôi sẽ không đồng ý với ý kiến ​​rằng khả năng viết các thuật toán là không liên quan trong câu hỏi lớn hơn về việc liệu người đó sẽ là một lập trình viên giỏi. Ngay cả khi anh ta không bao giờ phải sử dụng nó, (nghi ngờ), điều đó vẫn cho thấy anh ta có sự linh hoạt cần thiết để đưa ra giải pháp hợp lý cho một vấn đề phức tạp hơn một bộ yêu cầu đơn giản đã được viết ra và đặt ra chi tiết bởi khách hàng

Tôi chắc chắn không muốn thuê một người không biết suy nghĩ và phân tích. Đó là điều làm nên sự khác biệt giữa khỉ mã và lập trình viên máy tính.

Tôi phải thừa nhận ở đây, rằng tôi là một trong những người thích đặt câu hỏi thuật toán trong các cuộc phỏng vấn, nhưng tôi phải nhấn mạnh rằng câu trả lời thực sự cho câu hỏi là hoàn toàn không liên quan. Tôi không quan tâm một chút nếu người được phỏng vấn có biết câu trả lời hay không. Thay vào đó, đối với tôi, câu hỏi này nhắm vào các khía cạnh khác nhau, như sau: theo thứ tự quan trọng:

Yêu cầu

Những câu hỏi như vậy được cố tình dưới quy định. Trong ví dụ của bạn, không có thêm chi tiết nào được đưa ra về trình tự. Nếu bạn có một người được phỏng vấn hỏi bạn liệu những con số này có thực sự được sắp xếp hay không, thì đó là một dấu hiệu tốt. Anh ấy có suy nghĩ đúng đắn để hỏi khách hàng về các chi tiết khác, điều đó sẽ giúp đi đến một giải pháp tốt hơn trong thời gian ngắn hơn. Ứng viên cũng có thể chơi với ý tưởng sử dụng không gian O (n) để lưu trữ một mảng số N, nhưng anh ta không nên làm điều đó mà không hỏi thêm chi tiết về X và Y. Hãy nói rằng X và Y nằm trong khoảng từ 1 đến 1000 , sau đó chắc chắn, đi trước và khởi động một giải pháp dựa trên mảng. Nhưng nếu tôi nói với bạn khoảng cách là 1 và 1 tỷ, thì vấn đề sẽ trở thành một vấn đề hoàn toàn khác. Hãy để tôi nhấn mạnh một lần nữa, rằng tôi không quan tâm đến giải pháp.

Kỹ thuật tiêu chuẩn

Tôi không muốn thuê một lập trình viên thậm chí không biết O (n) nghĩa là gì. Đó là một điều tuyệt đối phải biết nếu bạn có bất kỳ nền giáo dục tử tế nào trong khu vực đó. Nhưng điều quan trọng là không chỉ biết ý nghĩa của nó, mà còn thực sự áp dụng kiến ​​thức đó. Trong ví dụ của bạn, tôi muốn một ứng viên nhận ra rằng anh ta không được phép sắp xếp dữ liệu (mà không hỏi thêm câu hỏi nhắm mục tiêu tùy chọn sắp xếp xô hoặc các cách tiếp cận sắp xếp O (n) khác) do sắp xếp O (n log n) bắt buộc nói chung.

Tương tự, các câu hỏi thuật toán khác nhắm vào các kỹ thuật tiêu chuẩn như cây hoặc đồ thị, hoặc đệ quy. Một ứng cử viên có thể trượt ở một trong những kỹ thuật này, không tạo được ấn tượng tốt. Tuy nhiên, trong những trường hợp như vậy, tôi muốn tìm hiểu sâu hơn để tìm hiểu xem ứng viên có bất kỳ nền tảng CS nào không. Tất nhiên, nó phụ thuộc vào vị trí mục tiêu là gì, nhưng thường thì một nhà phát triển không biết về độ phức tạp của thời gian chạy, cũng như cấu trúc dữ liệu điển hình và các giao dịch của họ, sẽ không giúp ích được gì.

Tư duy xử lý vấn đề

Sau khi đặt câu hỏi, bạn theo dõi ứng viên chặt chẽ. Anh ấy / anh ấy phản ứng thế nào? Bạn nhận được kết quả tốt nhất ở đây từ những ứng viên hoàn toàn không có manh mối về cách giải quyết vấn đề lúc đầu . Về mặt đó, câu hỏi kiểm tra những gì có thể xảy ra nếu một tình huống tương tự xảy ra tại nơi làm việc sau đó. Bạn có thể gặp phải một vấn đề như vậy trong quá trình phát triển của mình và thật tốt khi biết ứng viên của bạn giải quyết những vấn đề này như thế nào, ngay cả khi họ không thể tự giải quyết tất cả.

Ví dụ: Bạn không muốn ứng viên của mình chuyển sang chế độ im lặng trong nửa giờ tới! Kiểm tra xem anh ta có thể đưa ra các câu hỏi thông minh không (xem Yêu cầu), kiểm tra xem anh ta có bắt đầu nghĩ ra khỏi hộp không khi anh ta nhận ra mình không thể làm điều đó. Ngay cả một câu hỏi phản biện "vui vẻ" như "Tôi có thể sử dụng tùy chọn điện thoại đồng nghiệp không?" là một dấu hiệu tốt.

Cách trả lời

Nói chung, câu trả lời tốt nhất bạn có thể đưa ra cho các loại câu hỏi này là câu hỏi ngược! Nói một câu trả lời ngay lập tức về cơ bản thất bại toàn bộ, và thực tế không phải là một câu trả lời tốt, bởi vì tất cả những câu hỏi này gợi ý về sự đánh đổi, mà câu trả lời của bạn ngụ ý, mà bạn chưa có thông tin cần thiết để đưa ra điều đó một cách thông minh đánh đổi Tất nhiên, chất lượng của các câu hỏi ngược khác nhau giữa các ứng cử viên.

Như một lưu ý chung về các câu hỏi phỏng vấn: Các câu hỏi ngược lại hiếm khi là một điều xấu. Trong một trong những cuộc phỏng vấn của riêng tôi, tôi đã được hỏi một câu như sau: "Nếu bạn phải thực hiện X, bạn sẽ chọn C ++ hoặc Java cho điều đó, và tại sao?" - Tôi chỉ đơn giản phản bác lại "Tôi có giới hạn ở hai người này không?". Hãy tự đoán, bạn sẽ nhận được phản ứng gì từ người phỏng vấn cho một câu hỏi ngược như vậy - và việc bạn thực sự cho người phỏng vấn thấy khả năng của bạn như thế nào.

Trừ khi bạn đang đặt câu hỏi về thuật toán / công thức mà ứng viên cần biết cho công việc (ví dụ, động lực học chất lỏng, nếu vị trí yêu cầu điều đó), tôi không thấy giá trị của chúng. Ứng cử viên có thể đã lo lắng về cách họ ăn mặc, cách họ nói, v.v ... liệu họ có thể trả lời một câu hỏi toán học ngay tại chỗ không chứng minh bất cứ điều gì ngoài khả năng họ có thể trả giá trên một chương trình trò chơi truyền hình.

Khi tôi phỏng vấn, tôi thậm chí không hỏi những câu hỏi 'lập trình' mỗi lần. Tôi có ứng cử viên mô tả các dự án trong quá khứ của họ, cách mã của họ đạt được mục tiêu, cách tiếp cận của họ, v.v. Từ đó tôi có thể nói khá nhanh rằng ứng viên có biết anh ta đang làm gì hay anh ta là người đặt ra.

Tôi đồng ý rằng các lập trình viên phải biết rất rõ các thuật toán, ngay cả với các khung mới lạ mắt, nhưng tôi không hoàn toàn bị thuyết phục về một lời trêu ghẹo não trong một cuộc phỏng vấn. Mối quan tâm lớn nhất của tôi sẽ là trong một môi trường thực tế, bạn viết các thuật toán trong các điều kiện rất khác nhau; hay, không phải chịu áp lực với ai đó đang theo dõi bạn mỗi lần cầm bút, với ít nhất vài phút để nghĩ về nó trong im lặng. Đối với những người ủng hộ phương pháp đánh giá này, bạn thường cho người đó giải quyết nó trong bao lâu? Tôi tin rằng mã không phải là quá nhiều về việc tạo ra một giải pháp trong cơn khủng bố 3 phút gây sốt, vì vậy hãy thuyết phục tôi rằng đây thực sự là một cách tốt để xem ai đó sẽ xử lý công việc hàng ngày như thế nào.

Vấn đề với câu hỏi cụ thể đó là nó gần như là một câu hỏi mẹo. Với một cái nhìn sâu sắc cụ thể, bạn sẽ dễ dàng đưa ra O (n), nếu không, bạn sẽ đấu tranh để có được tốt hơn O (n log n). Nó gần như giảm xuống thành "Bạn đã thấy cái này trước đây chưa?"

Tôi không chắc chắn có bất kỳ câu hỏi thuật toán tốt. Nếu bạn hỏi một người dựa trên lý thuyết đồ thị, thì nó sẽ phụ thuộc vào mức độ quen thuộc của người được phỏng vấn với lý thuyết đồ thị - và, nếu bạn thuê anh ta hoặc cô ta, anh ta hoặc cô ta có thể tăng tốc độ trên lý thuyết đồ thị khá nhanh. Một lần nữa, chúng tôi trở lại "Bạn đã từng tiếp xúc với điều này trước đây chưa?"

Không có thời gian trong một cuộc phỏng vấn thường xuyên để giải quyết vấn đề nghiêm trọng và tôi tiếp cận mọi thứ một cách khác biệt khi tôi có thể ngồi xuống, sử dụng Wikipedia và thường dành thời gian để tìm hiểu. Có lẽ không có thời gian để người phỏng vấn thảo luận kỹ về những gì người được phỏng vấn biết chi tiết và chọn ra một câu hỏi thuật toán phù hợp.

Tôi có một số câu hỏi giống như thuật toán mà tôi sử dụng thường xuyên, một số câu hỏi rất khó. Tôi sử dụng chúng để xem cách chúng tấn công tinh thần vào một vấn đề và để xem liệu chúng có mò mẫm các khái niệm nhất định hay không. (Tôi đã thấy quá nhiều ứng viên phát triển, những người không hiểu con trỏ.)

Bạn muốn một câu hỏi sẽ cung cấp cho bạn cái nhìn sâu sắc về ứng viên. Một câu hỏi thuật toán có thể cung cấp một câu trả lời tốt, hoặc nó có thể không. Và tôi không đề cập đến việc họ có thể trả lời hay không. Nếu họ làm việc thông qua nó, và bạn hiểu và làm theo lý luận của họ, đó là một chỉ báo tốt. Nếu họ chỉ ngồi đó, không có phản hồi thực sự, dường như thậm chí không biết bắt đầu từ đâu, đó là một chỉ báo tồi (có thể). Vấn đề sẽ là một số người đóng băng, và phân biệt đóng băng với việc không có kỹ năng giải quyết vấn đề có thể khó khăn.

Mọi người sẽ phàn nàn về việc hỏi bất cứ điều gì trong các cuộc phỏng vấn, vì nhiều lý do. Người nộp đơn có thể đóng băng, người nộp đơn có thể vừa xem câu hỏi đó, người nộp đơn có thể không biết câu đố cụ thể / công nghệ / bất cứ điều gì. Tất cả điều này là đúng, nhưng một cuộc phỏng vấn vẫn cần phải xảy ra, và nhiều người trong chúng ta trong nghề này ghét điều đó. Chúng tôi ghét ý tưởng về một người ngồi phán xét chúng tôi. Chúng tôi ngay lập tức đưa ra lý do tại sao chúng tôi có thể bị đánh giá không công bằng, hoặc làm thế nào bài kiểm tra có thể không có thật hoặc bị đánh bạc. Điểm mấu chốt là, nó không thành vấn đề.

Những gì bạn thực sự muốn là một người phỏng vấn với khả năng xác định các kỹ năng có thể hoặc không thể được trình bày trong cuộc phỏng vấn. Các câu hỏi chỉ là công cụ. Đối với tôi, tất cả các búa trông giống nhau. Nhưng với một người đủ tài giỏi với họ, tôi chắc chắn có sự khác biệt.

Tôi thích các câu hỏi thuật toán, bởi vì đó là những gì chúng ta làm. Tôi thích các ràng buộc, bởi vì đó là những gì chúng ta sử dụng. Big-O đặc biệt có liên quan trong ngành của tôi.

Tôi không thích yêu cầu câu trả lời cho các loại câu hỏi này là "viết mã lên bảng trắng". Người được phỏng vấn có thể nói chuyện một cách thông minh về cách tiếp cận giải pháp và tham gia vào một cuộc thảo luận đang diễn ra khi người phỏng vấn thay đổi các yêu cầu trong khi cuộc thảo luận đang diễn ra.

Câu hỏi ban đầu được hỏi, người được phỏng vấn nói, "bắt đầu từ đầu và tiến về phía cuối để tìm kiếm" lỗ hổng "". Người phỏng vấn nói rằng điều đó quá chậm, bởi vì N rất to lớn. Người được phỏng vấn bắt đầu thảo luận về tìm kiếm nhị phân. Người phỏng vấn nói rằng tất cả các dữ liệu đột ngột không còn được sắp xếp. Người được phỏng vấn nói "sắp xếp rồi tìm kiếm". "Bây giờ thì quá chậm". Vân vân.