Làm thế nào để kiểm tra hoặc đánh giá kỹ năng sửa lỗi của một người? [đóng cửa]

Loại kỹ năng nào xác định một người có khả năng gỡ lỗi mã dễ dàng? Cách đây một thời gian, bạn tôi đã thực hiện một cuộc phỏng vấn với một lập trình viên tương đối giỏi. Các lập trình viên đã được thuê. Anh ta có thể viết mã tốt, hiểu các khung và các mẫu thiết kế. Thứ anh ta thiếu là - kỹ năng sửa lỗi. Anh ta không thể gỡ lỗi chút nào và việc tìm ra vấn đề với mã của anh ta hoặc người khác là nỗi đau lớn đối với anh ta.

Kể từ đó, chúng tôi đang suy nghĩ về cách chúng tôi có thể đánh giá hoặc ước tính các kỹ năng sửa lỗi của một người.

Vì vậy, câu hỏi đầu tiên là: kỹ năng nào xác định xem một người có thể gỡ lỗi phần mềm một cách hiệu quả không?

Và thứ hai: làm thế nào để kiểm tra những kỹ năng đó trong cuộc phỏng vấn?

Nếu điều đầu tiên mà người đó muốn làm là xem mã và bước qua nó với trình gỡ lỗi thì người đó không phải là người gỡ rối tuyệt vời.

Nếu bạn chưa có kế hoạch hành động và bạn sẽ đi sâu vào trình gỡ lỗi, về cơ bản bạn là Easter Egging. Điều này đúng cho bất kỳ loại xử lý sự cố.

Trong một tình huống phỏng vấn, một người hỏi cách hệ thống vận hành và hỏi về lịch sử của hệ thống sẽ là một người có thể là người khắc phục sự cố tốt. Một người nghĩ rằng hệ thống đầu tiên và cơ học thứ hai có thể là một người khắc phục sự cố tốt.

Điều này đúng với bất kỳ hệ thống phức tạp nào.

Tôi sẽ lập luận rằng thước đo tốt nhất của một nhà phát triển phần mềm tốt trong một ngôn ngữ hoặc khung cụ thể là khả năng phân tích phê phán các vấn đề phức tạp và có kỹ năng sửa lỗi tốt trong ngôn ngữ hoặc khung. Họ phải có khả năng chứng minh gỡ lỗi cấp thấp cũng như thành thạo gỡ lỗi cấp cao với các công cụ gỡ lỗi phổ biến.

Điều này có nghĩa là tạo ra một kịch bản cho chúng thể hiện khả năng gỡ lỗi cao trong IDE đã chọn của chúng. Bạn nên tìm những thứ như:

• Chạy ứng dụng hoặc máy chủ hộp cát trong chế độ gỡ lỗi hoặc xây dựng ứng dụng có ký hiệu để gỡ lỗi

• Cung cấp sẵn và thể hiện các cổng gỡ lỗi từ xa hoặc gỡ lỗi ứng dụng không có hộp cát được xây dựng bằng các ký hiệu (nếu có thể áp dụng cho ngôn ngữ)

• Chiến lược sử dụng điểm dừng

• Thuộc tính tùy chỉnh của điểm dừng, biểu thức điều kiện trên điểm dừng (nếu áp dụng cho ngôn ngữ)

• Sử dụng biểu thức hoặc đồng hồ biến để theo dõi giá trị biến hoặc tham chiếu

• Sử dụng giá trị biến ad-hoc hoặc tham chiếu hoặc thao tác con trỏ trong thời gian thực

• Thể hiện khả năng bước vào, vượt và ra khỏi dòng ứng dụng

• Đánh giá quan trọng của ngăn xếp cuộc gọi

• Gỡ lỗi các ứng dụng đa luồng và hiểu điều này.

Các chiến lược sửa lỗi khác không có công cụ cũng nên được thể hiện, chẳng hạn như phân tích nhật ký và mã nguồn, cũng như khả năng thực hiện một số gỡ lỗi cấp thấp mà không cần sử dụng IDE.

Tôi muốn nói chắt lọc một lỗi mà bạn có trong hệ thống của mình với điều gì đó có thể được thảo luận trong bối cảnh của một cuộc phỏng vấn. Bật trình gỡ lỗi và để anh ta vào nó.

Đặt câu hỏi cho anh ấy như thế này:

1. Làm thế nào để bạn giải quyết một vấn đề?

2. Một trong những dự án phức tạp mà bạn đã làm là gì và làm thế nào bạn đạt được nó?

3. Bạn đã sử dụng công cụ sửa lỗi nào?

4. Bạn có bất kỳ ưu tiên cho các công cụ nhất định?

5. Cho một ví dụ về kịch bản của riêng bạn và hỏi anh ấy anh ấy sẽ giải quyết nó như thế nào?

6. Làm thế nào bạn đánh giá khả năng của bạn để có được vào mã người khác?

Bạn có thể giải quyết mối quan tâm của bạn bằng cách đặt câu hỏi. Luôn luôn có một rủi ro anh ta có thể hoặc không thể giỏi trong một số kỹ năng nhất định. Nhưng nếu anh ấy là một người học giỏi, điều đó sẽ giúp ích rất nhiều.

Nếu bạn muốn xem một lập trình viên có thể gỡ lỗi hay không, hãy cung cấp cho họ mã để sửa. Đó là cách tiếp cận tương tự nếu bạn muốn xem liệu họ có thể viết mã hay không. Cung cấp cho họ một vấn đề và yêu cầu họ viết mã.

Bây giờ, tôi bối rối về lập trình viên này, người không gặp vấn đề gì khi viết mã nhưng thất bại khi bị yêu cầu gỡ lỗi. Có phải người này lấy lại các ví dụ mã hoặc chỉ dính vào các lĩnh vực anh ta có kinh nghiệm như đọc và viết vào cơ sở dữ liệu? Trừ khi họ nhận được mã ngay lần đầu tiên, họ không thể sửa nó?

Có lẽ người đó không thích gỡ lỗi và không nỗ lực? Tôi không giỏi trong việc này nên hãy ngừng yêu cầu tôi làm điều đó - học được sự bất lực.

Làm việc trên một cơ sở mã hiện có đòi hỏi phải xem qua mã, tài liệu và có thể thực hiện một số ghi chú và giải thích của riêng bạn.

Tôi biết chúng tôi nghĩ về việc gỡ lỗi là sửa mã sản xuất đã thất bại, nhưng tôi cần gỡ lỗi mã trong khi tôi đang viết nó. Người này không phải là một lập trình viên giỏi hoặc họ chỉ thích viết mã mới. Đừng tất cả chúng ta.

Cũng giống như cách bạn xác định khả năng mã hóa của ai đó, hãy hỏi họ các câu hỏi về gỡ lỗi.

Hỏi họ "làm thế nào" họ sẽ theo dõi một lỗi trong một tình huống nhất định.

Tiến lên một bước nữa và ngồi xuống trước máy tính và xem chúng gỡ lỗi một vấn đề.

Tôi thường đưa ra cho các ứng viên những tình huống giả định ... ví dụ, một hệ thống sản xuất đã ngừng đáp ứng. Bạn làm nghề gì? Họ có thể trả lời "kiểm tra nhật ký" và tôi nói "nhật ký cho thấy không có gì bất thường, ngoại trừ việc không có gì được viết trong đó kể từ khi vấn đề bắt đầu xảy ra". Và cứ thế, cho đến khi tôi hài lòng rằng tôi đã đánh giá khả năng giải quyết vấn đề của thí sinh.

Thông thường những người có năng khiếu tốt cũng là người có kỹ năng sửa lỗi tốt.

Trong cuộc phỏng vấn, (tùy thuộc vào thâm niên của họ), bạn có thể giao cho họ một bài tập giống như câu đố như thuật toán nào đó. Đó là cách đơn giản.

Nếu bạn có thể, bạn có thể in mã ra khỏi một số công việc, hãy hỏi người đó nếu có gì đó không đúng ở đây và nếu có cách khắc phục.

Tôi không thích hỏi những câu hỏi phỏng vấn khó hiểu có xu hướng tập trung vào khả năng đọc và sửa lỗi cú pháp của mọi người.

Trong một cuộc phỏng vấn, hãy yêu cầu họ nói với bạn về một lỗi mà họ đã sửa trong quá khứ và các bước mà họ đã sử dụng để gỡ lỗi.

Làm cho họ nói với bạn về những gì họ đã làm trong công việc cuối cùng của họ, giao bài tập về nhà, vv Và những gì họ đã trải qua trong việc tìm ra vấn đề.

Tôi sẽ chia sẻ kinh nghiệm cùng với quan điểm tuyển dụng về kiểm tra kỹ năng ứng viên trong việc gỡ lỗi. Tôi đã tham gia một cuộc phỏng vấn có ba giai đoạn. Giai đoạn thứ hai là một "trường hợp thực tế". Tôi không biết nhiều hơn vào lúc đó. Trong khi ở đó tôi được thông báo có một hệ thống ngừng hoạt động và họ không biết. Một số lỗi đang nằm phía sau.

Nó được sắp xếp như một máy tính để bàn từ xa đến một môi trường thử nghiệm cũ. Có lẽ là đến một môi trường không được cắm hoặc bị cô lập. Dự án là một vài biểu mẫu web với một số điều khiển ASP.NET và mã tập tin mã liên quan. Codefile đề cập đến một loại lớp nghiệp vụ mà tôi chỉ có một dll, không có mô tả mã nguồn và phương thức. Các Webforms đã thực hiện các chức năng CRUD mà bạn có thể mong đợi. Cũng là một chức năng tìm kiếm nhỏ. Đến lượt, lớp doanh nghiệp đã nói chuyện với Views và SP trong một máy chủ sql.

Họ môi giới một số phần ở các cấp độ khác nhau. Tôi đã nhận được một bài báo với các triệu chứng. "Không thể tìm kiếm" "Trường 'vùng' biến mất sau lần cập nhật trước" và như vậy. Chẳng hạn như bạn có thể nhận được từ người dùng của bạn.

Tôi không nhớ tất cả các chi tiết nhưng ít nhất một trường bảng đã được đổi tên, dẫn đến SP bị hỏng, được sử dụng bởi chức năng tìm kiếm. Điều đó có nghĩa là không có lỗi trong VS và không có mã nguồn BL để theo dõi tên trường. Một tham số CHỌN chống lại Sqlcommand đã bị sai chính tả và khiến một dạng web bị trục trặc. Ngoài ra, một trường đã bị bỏ qua, đó là trường bị thiếu trong GridView (Autogeneratecolumns). Một nút ASP.NET đã được đề cập đến một cái gì đó có nghĩa là một phương pháp trùng lặp, nâng cao, và "quên" để trỏ đến phương thức mới.

Ngoài ra điều nhỏ như vậy bằng cách sử dụng tiêu đề trong thẻ html không cho phép nó. Ngoài ra thẻ ALT đối diện đã bị bỏ qua trong một điều khiển yêu cầu nó. Cũng có một số lỗi với các thẻ html đóng không chính xác nhưng không gặp trục trặc. Không chắc chắn nếu tất cả những thứ đó là một lỗi dự án thuần túy hoặc có lẽ cùng một dự án cho các tuyển dụng khác nhau. Tôi chưa bao giờ hỏi. Mức độ khó tất nhiên phải phù hợp với nhu cầu tuyển dụng.

Thử nghiệm như vậy có lẽ nên được sàng lọc (không theo dõi) để xem, sau khi phỏng vấn, cách gỡ lỗi đã được thực hiện. Đối với bản thân tôi ở giai đoạn đó, tôi thấy bài kiểm tra hơi vô lý, nhưng đó cũng sẽ là điểm lớn. Nếu đó là hoặc không, nên có giá trị rất nhiều ứng cử viên ở đúng nơi.

* Tôi nghĩ rằng bài kiểm tra đã chứng minh các ứng cử viên / kỹ năng của tôi *
* Phân tích hệ thống nước ngoài
* Sử dụng tối thiểu thông tin để tìm lỗi và lỗi
* Trong thời gian căng thẳng và không có ai giúp bạn, mã giả định sửa chữa
* Các mức độ kiến ​​thức khác nhau;
** db sql và các thủ tục được lưu trữ,
** sử dụng dll trong dự án,
** kỹ thuật asp.net,
** kiến ​​trúc phân lớp
** khía cạnh hướng đến vấn đề

Nhưng cũng những điều rõ ràng hơn như xử lý môi trường nhà phát triển, tìm và hiểu công cụ quản lý máy chủ Db. Chắc chắn có những ứng cử viên trông thực sự đẹp trên giấy nhưng, trong thực tế, có thể bị mắc kẹt trong các nhiệm vụ như vậy.

Tôi chọn một vấn đề thực tế mà tôi gặp phải liên quan đến vị trí đó và tôi trình bày nó cho ứng viên nhiều như nó đã được trình bày cho tôi. Tất nhiên tôi cung cấp cho họ một số nền tảng chung và một lượng nhỏ tài liệu liên quan như đoạn mã hoặc sơ đồ.

Tôi nói với họ công việc của họ là giải quyết vấn đề và tôi đề nghị trả lời bất kỳ câu hỏi kỹ thuật nào họ có và cho họ biết kết quả của bất kỳ thí nghiệm nào họ muốn thực hiện. Nếu họ nói: "Tôi sẽ đặt một thăm dò phạm vi ở đây", thì tôi sẽ phác thảo cho họ một dấu vết về những gì họ có thể tìm thấy. Nếu họ muốn chèn một printfvòng lặp, tôi sẽ nói với họ rằng nó không bao giờ xuất hiện (!) Hoặc đầu tiên in "7" và sau đó lặp lại "5". Nếu chúng đi quá xa trong đám cỏ dại mà tôi không thể đưa ra câu trả lời có ý nghĩa, tôi sẽ thừa nhận rằng chúng ta đang đi sai đường và quay trở lại nơi khác. Nếu chúng bị kẹt, tôi sẽ hỏi những câu hỏi hàng đầu hoặc đưa ra gợi ý cho đến khi chúng ta có thể tiếp tục.

Những gì tôi muốn thấy là các quá trình suy nghĩ có trật tự, quyết tâm đi đến giải pháp, xem xét tốt các câu hỏi và thí nghiệm, và lý tưởng là xác định thành công vấn đề. Đôi khi tôi chọn những vấn đề quá phức tạp để ai đó có thể gỡ lỗi hoàn toàn trong một cuộc phỏng vấn kéo dài một giờ và cuối cùng tôi cho họ câu trả lời thực sự. Tại thời điểm đó, tôi đang tìm kiếm một phản ứng cho thấy rằng họ đã tham gia vào vấn đề và trải nghiệm khoảnh khắc "aha" và sự hài lòng khi tìm hiểu nguyên nhân. Các ứng cử viên tốt nhất sẽ tự phát đặt câu hỏi tiếp theo vào thời điểm đó, cố gắng liên kết bản đồ tinh thần của họ về vấn đề với những gì đang thực sự xảy ra.

Ngồi xuống máy tính với một số ký hiệu nhị phân đơn giản (có gỡ lỗi) phân tách bằng tham chiếu con trỏ null hoặc mã nguồn + gdb như vậy và xem liệu chúng có thể tìm ra nguyên nhân của sự cố không?

Nếu bạn yêu cầu ứng viên của mình thực hiện kiểm tra mã sơ bộ, hãy yêu cầu họ sửa đổi mã trong cuộc phỏng vấn để giải quyết lỗi hoặc thêm một tính năng mới hoặc tốt hơn cả hai. Nếu bạn thực hiện các thông số kỹ thuật kiểm tra mã khá mơ hồ, điều đó sẽ giúp việc tạo các trường hợp kiểm thử có "lỗi" dễ dàng hơn sau đó.

Tìm "lỗi" trong một đoạn mã nhỏ là một tình huống rất giả tạo. Tôi cho rằng nó có thể hữu ích giống như các câu đố và trêu ghẹo não.

Một cách tiếp cận toàn diện hơn sẽ đặt câu hỏi hành vi về cách ứng viên đã thực hiện gỡ lỗi trong quá khứ trích dẫn các sự cố cụ thể và sau đó theo dõi các câu hỏi.

Một người giỏi xử lý sự cố sẽ có thể nói về nhiều thứ hơn là các phương tiện gỡ lỗi trong IDE. Thế còn ... các công cụ báo cáo lỗi, tương tác của người dùng cuối, tái tạo lỗi, phân tích logfile, xác minh thì sao?

Có NHIỀU HƠN để gỡ lỗi hơn là truy tìm thông qua một khối mã và mọi đánh giá về kỹ năng gỡ lỗi của ai đó sẽ phản ánh điều đó.

Cung cấp cho ai đó một số mã tuyệt vời công ty của bạn chạy trong sản xuất. Yêu cầu họ giới thiệu một lỗi tinh tế. Hỏi họ tại sao họ chọn cái đó. Hỏi họ làm thế nào họ sẽ đi tìm và sửa nó.

Điểm thưởng nếu họ tìm thấy một lỗi trong mã gốc.

Nhân đôi điểm thưởng nếu họ có thể sửa lỗi trong mã gốc.

Tôi có xu hướng yêu cầu mọi người mô tả cho tôi lỗi khó khăn nhất họ từng phải theo dõi và sửa chữa và những gì họ đã làm để tìm ra nó và sửa nó. Tôi cũng biết rằng nếu lỗi khó nhất là điều mà bạn chỉ mong đợi người mới bắt đầu gặp khó khăn, thì có khả năng họ không phải là người khắc phục sự cố tốt (trừ khi đây là một cuộc phỏng vấn cho cấp nhập cảnh). Nếu đó là một điều gì đó thực sự khó khăn và họ mô tả quá trình suy nghĩ của họ khi họ cố gắng theo dõi nó, thì tôi có thể cảm nhận được mức độ kỹ năng của họ là gì. Điều làm tôi ngạc nhiên là số lượng người có vẻ ngoài "con nai trong đèn pha" và không thể nghĩ ra một ví dụ duy nhất về việc họ đã làm điều đó rất phức tạp. Xin lỗi, một người để lại những vấn đề khó khăn cho người khác sửa chữa không phải là người mà tôi quan tâm vì bất cứ điều gì ngoại trừ trường học thẳng,

Tôi sẽ hỏi một vài câu hỏi bất khả tri về công nghệ như sau:

• Đưa tôi qua tất cả các bước bạn thực hiện để xác định nguyên nhân gốc và sửa lỗi (lỗi)
• Bạn sẽ sử dụng Call Stack như thế nào trong khi gỡ lỗi một ứng dụng đa luồng

Điều này hoạt động thực sự đặc biệt tốt trong các cuộc phỏng vấn qua điện thoại vì bạn chỉ cần người đó cung cấp cho bạn một câu trả lời thuyết phục cho thấy cách anh ấy thực sự làm việc trong khi khắc phục sự cố.