Tại sao người phỏng vấn không yêu cầu người nộp đơn đọc một số mã? [đóng cửa]

Tôi đã có một tá cuộc phỏng vấn trong đời (tôi sắp tốt nghiệp) và tôi tự hỏi tại sao tôi chỉ được yêu cầu đọc và giải thích một số mã. Gần như, 90% việc làm chủ yếu là về việc duy trì các hệ thống hiện có. Khả năng IMO để đọc mã của người khác là một kỹ năng quan trọng.

Tại sao người phỏng vấn không kiểm tra nó? *

* _{Trong số bạn bè của tôi, tôi là người duy nhất được yêu cầu xem lại một số mã.}

Khi tôi đặt câu hỏi phỏng vấn, ban đầu tôi đã làm nhưng dần dần loại bỏ nó. Những ứng viên có thể viết mã tốt trong cuộc phỏng vấn đều có thể đọc mã tốt trong cuộc phỏng vấn. Những người nộp đơn không thể đọc mã cũng không thể viết nó. Các câu hỏi liên quan đến việc đọc mã không thực sự phân biệt bất kỳ ứng viên nào.

Phiên bản ngắn

Nếu công việc bao gồm duy trì một ứng dụng, các kỹ năng bạn cần kiểm tra trong các cuộc phỏng vấn là:

• Khả năng hiểu được cơ sở mã lớn với tài liệu, bài kiểm tra đơn vị , v.v.

• Khả năng cấu trúc lại mã và mang lại thay đổi mà không phá vỡ mọi thứ.

Yêu cầu mọi người đọc mã sẽ không giúp bạn đánh giá các khả năng đó.

Phiên bản dài

Bạn đã hỏi viết mã? Nếu có, như Sign đã lưu ý trong câu trả lời của anh ấy , điều này là đủ. Nếu chúng ta khái quát một chút, một người viết mã nguồn rõ ràng, dễ hiểu sẽ có thể đọc được mã nguồn do người khác viết.

Nếu bạn không được yêu cầu viết mã, thì, có lẽ bạn đã được phỏng vấn bởi một người từ phòng nhân sự. Các cuộc phỏng vấn như vậy không thể quá kỹ thuật và hầu như không có giá trị, vì họ không đánh giá cao kỹ năng và khả năng làm việc tốt của bạn, mà là số năm bạn đã học đại học và những việc khác không liên quan đến công việc.

Có một vài lý do nữa để không yêu cầu đọc mã cho công việc bảo trì:

1. Thật khó để làm một cách đáng tin cậy

Cụ thể, bạn sẽ làm gì nếu bạn là một người phỏng vấn? Làm cho ứng viên của bạn đọc một số mã. Mã gì? Trong ngôn ngữ nào? Làm thế nào tốt hay viết xấu? Có hay không có ý kiến? Có hay không có tài liệu?

Quan trọng hơn, nó nói gì về ứng viên? Làm thế nào nó tương quan tốt với chính codebase?

Giả sử bạn có một ứng dụng VB.NET cũ để duy trì. Bạn biết rằng mã nguồn chủ yếu là xấu xí và chưa được kiểm tra, và một vài bình luận đã lỗi thời hoặc sai lệch. Trong ba tháng qua, bạn đã có một nhà phát triển rất khéo léo làm việc về giải pháp; ông đã tái cấu trúc và đơn vị đã thử nghiệm các phần quan trọng nhất của ứng dụng, thêm ý kiến ​​khi cần bình luận và quan trọng nhất là viết tài liệu chi tiết về kiến ​​trúc tổng thể, các phần quan trọng và cạm bẫy.

Bây giờ bạn đang thuê một nhà phát triển để duy trì cơ sở mã này. Trong một cuộc phỏng vấn, bạn sẽ đưa ra một đoạn mã kế thừa (chưa được kiểm tra), hay đoạn mã được nhà phát triển trước đó tái cấu trúc?

Bạn sẽ cung cấp cho các tài liệu? Để đọc tài liệu, ứng viên sẽ cần dành ít nhất một vài giờ. Điều này làm cho nó không thể làm trong một cuộc phỏng vấn.

2. Đọc đoạn mã ngắn không giống như đọc mã của một dự án quen thuộc

Hãy nhớ rằng, công việc là duy trì một dự án. Thật khó để duy trì một cơ sở mã lớn trong những ngày hoặc tuần đầu tiên khi bạn không quen thuộc với dự án. Làm điều đó dễ dàng hơn nhiều sau một vài tháng khi bạn đã viết tất cả các tài liệu và có một cái nhìn rõ ràng về cơ sở mã tổng thể.

Điều quan trọng nhất để kiểm tra là nếu người đó sẽ có hiệu quả trong những tháng đó . Bạn không quan tâm nếu người đó sẽ không thể hiểu bất cứ điều gì trong hai ngày đầu tiên.

Bằng cách yêu cầu một người đọc một đoạn mã ngắn từ đầu, bạn không kiểm tra làm thế nào người này có thể đối phó với một mã hóa quen thuộc, được ghi chép lại của hàng ngàn LỘC .

3. Duy trì mã nguồn không chỉ là đọc nó

Khi bạn đang duy trì một cơ sở mã, bạn đang sửa đổi nó. Một nhà phát triển chỉ đọc mã không mang lại điều gì hữu ích cho công ty của anh ta.

Các kỹ năng hữu ích là khả năng cấu trúc lại mã , thêm các bài kiểm tra đơn vị , dự đoán tác động của thay đổi , v.v. Bạn không kiểm tra các kỹ năng đó bằng cách yêu cầu một người đọc mã trong cuộc phỏng vấn.

Đọc là một giả định dựa trên thực tế là khả năng có mặt để viết. Hãy xem xét các khái niệm trong bất kỳ ngôn ngữ. Lập trình chỉ là một ngôn ngữ để giao tiếp giữa con người và máy móc. Hãy xem xét một giao tiếp giữa người với người. Nếu bạn đang thuê một người làm phiên dịch cho tiếng Nhật, liệu có lý do gì nếu họ có thể viết một bài luận 1.000 từ về một chủ đề cụ thể mà họ có thể đọc được không?

Là lập trình viên, hoạt động chính của chúng tôi là tạo ra mã và dịch các ý tưởng trừu tượng thành các triển khai cụ thể. Điều này thường có nghĩa là viết. Tôi đồng ý rằng việc đọc cũng quan trọng như vậy, nhưng trong phần lớn các trường hợp, trong đó khả năng viết là khả năng đọc cũng có mặt. Trường hợp thực tế duy nhất mà tôi có thể thấy một sự khác biệt có thể phân biệt sẽ là trong một môi trường có rất nhiều trường hợp rất phức tạp đã phát triển theo thời gian. Mặc dù được đưa ra những điều này, mặc dù, bạn sẽ không mong đợi ai đó có thể đọc chúng và hiểu chúng mà không cần ít nhất một số nghiên cứu.

Ngoài ra, đọc mã và giải thích những gì bạn nghĩ nó không thực sự thể hiện với người phỏng vấn về cách bạn sử dụng các kỹ năng tư duy phê phán của mình. Nó cho thấy một chút phân tích, nhưng hầu hết các nhà tuyển dụng muốn xem liệu bạn có thể suy nghĩ mà không bị đặt vào một cái hộp không. Họ muốn biết liệu bạn có thể nắm bắt các khái niệm mà không có lợi ích (hoặc thậm chí là nạng) của mã hiện có để cho bạn biết những gì hoặc làm thế nào để làm một cái gì đó.

Trước đây tôi thường nghĩ rằng việc đọc mã nên là một điều gì đó được thể hiện trong các cuộc phỏng vấn, nhưng theo thời gian tôi đã nhận ra rằng điều này là lãng phí thời gian cho cả người phỏng vấn và người được phỏng vấn. Tại sao? Bởi vì ngay cả các lập trình viên xấu cũng có thể đọc một đoạn mã.

Khả năng đánh giá khả năng đọc mã của ai đó chỉ trở nên phù hợp khi bạn xem xét một thứ gì đó phức tạp hoặc mã bao trùm nhiều lớp và tệp. Có thể theo dõi mã để tìm ra những gì nó đang làm là một đặc điểm mong muốn, nhưng không có đủ thời gian để ai đó đưa ra một ví dụ hay (không phải mã sản xuất) cũng như không có thời gian trong một cuộc phỏng vấn để hỏi một câu hỏi như vậy .

Vì vậy, các lập trình viên xấu có thể đọc mã, nhưng họ không thể viết mã tốt. Yêu cầu xem các ví dụ về một ứng cử viên làm việc hoặc yêu cầu một ứng viên viết mã trong cuộc phỏng vấn là cách tốt hơn cho các kỹ năng của họ. Nếu họ có thể viết mã ngắn gọn sạch sẽ, rất có thể họ có thể đọc mã tốt.

Tôi hỏi mọi ứng viên tôi đang phỏng vấn một biến thể của vấn đề FizzBuzz . Nó nhanh chóng, đơn giản và thường có thể chọn ra các lập trình viên xấu nhanh hơn nhiều so với bất kỳ thứ gì khác mà tôi đã tìm thấy. Một lập trình viên giỏi sẽ nhận được nó rất nhanh chóng và dễ dàng và nó sẽ cho bạn cái nhìn nhanh về phong cách mã hóa và quá trình suy nghĩ của họ.