Kiểm tra Joel tương đương để đo một lập trình viên [đã đóng]

Tôi hiểu rằng để đo lường một dự án hoặc mã, chúng ta có thể sử dụng Thử nghiệm Joel , nhưng có thử nghiệm tiêu chuẩn đơn giản nào (như Thử nghiệm Joel) có thể đo lường và lọc mức độ tốt của một lập trình viên không?

Kế hoạch của tôi là có bài kiểm tra này dưới dạng bộ lọc nhanh trước khi đi kiểm tra chi tiết hơn.

Có ma trận năng lực lập trình viên .

Như với bài kiểm tra Joel, nó chỉ là một hướng dẫn mơ hồ. Cách duy nhất để đánh giá đúng một lập trình viên là hỏi những lập trình viên giỏi đã làm việc với họ.

Tôi sẽ chuyển bài kiểm tra Joel xung quanh:

Họ đã sử dụng kiểm soát nguồn?

Họ có biết làm thế nào để tự động hóa một bước xây dựng?

...

Câu hỏi duy nhất không có vẻ đặc biệt áp dụng là câu hỏi của người kiểm tra. Những câu hỏi khác có vẻ như không phù hợp với điều này là cách chúng tôi xử lý nó như thế nào bạn đã xử lý nó trong các câu hỏi trước đây (Đây là cách chúng tôi xử lý để giữ lịch trình của chúng tôi cập nhật cách bạn đã xử lý lịch trình trong quá khứ?) .

biên tập:

Về cơ bản, bạn không nhận được những thứ trong bài kiểm tra Joel miễn phí, bạn phải thuê những người có thể thực hiện nó. Bạn muốn thiết lập khả năng của họ để thực hiện điều đó.

Joel Test chỉ là một kiểm tra cơ bản không chính thức để nhanh chóng đánh giá xem một nơi có điều kiện làm việc tốt cho các lập trình viên hay không. Ngay cả khi nó đạt điểm 10 hoàn hảo, nó vẫn có thể là một lỗ địa ngục sắp phá sản sáu tháng. Điểm thấp là một dấu hiệu cho thấy điều gì đó không hoàn toàn đúng và đưa ra các câu hỏi phỏng vấn xuất sắc ("Bạn hiện không sử dụng kiểm soát nguồn; có kế hoạch nào để làm như vậy trong tương lai không?"), Và các câu trả lời có thể như vậy bạn sẽ chấp nhận công việc mặc dù điểm Joel thấp.

Bài kiểm tra Joel cũng không phải là bài kiểm tra 'tiêu chuẩn'; nó chỉ là một danh sách kiểm tra Joel Spolsky đăng trên blog của mình.

Theo như "đo lường" chất lượng của một lập trình viên; Thật không may, các kỹ năng và phẩm chất thực sự quan trọng của một lập trình viên giỏi là khó hoặc không thể định lượng được, vì vậy không có sự thay thế nào cho việc đánh giá con người kỹ lưỡng. Mặc dù vậy, bạn có thể loại bỏ các ứng viên hoàn toàn không biết gì, bằng cách sử dụng một nhiệm vụ lập trình rất đơn giản - lý tưởng, một cái gì đó liên quan đến đệ quy, cấu trúc cây hoặc con trỏ (một lập trình viên không 'nhận' những thứ này dường như không được sử dụng nhiều). Đối với những người vượt qua bài kiểm tra này, bạn sẽ phải đánh giá các kỹ năng theo cách thủ công: đọc mã họ đã viết, kiểm tra các ứng dụng mà họ đã viết, giao cho họ nhiều nhiệm vụ lập trình hơn (cả thiết kế và triển khai), xem chúng hoạt động, nói chuyện với họ, xem bạn có có thể châm ngòi cho một cuộc thảo luận chuyên nghiệp. Nếu bạn đang tìm kiếm một chuyên gia / chuyên gia ngôn ngữ,

Vâng:

Bạn có chương trình trong thời gian rảnh?

Theo tất cả kinh nghiệm của tôi, câu hỏi duy nhất này cho thấy hầu hết các lập trình viên giỏi như thế nào. Nếu họ thích nó; nếu họ có đam mê để thực hiện nhiệm vụ, thì họ sẽ giỏi về nó.

Và thẳng thắn, rất nhiều 9 đến 5 công việc không liên quan đến nhiều tiền mã hóa . Họ không liên quan nhiều đến việc lặp đi lặp lại trong suốt vòng đời thiết kế chương trình mới và xem cách thiết kế đó hoạt động / thất bại. Không có sự lặp lại đó, đơn giản là không có thực hành cần thiết cho các lập trình viên để có được các kỹ năng thiết kế chương trình cốt lõi.

Và họ không liên quan đến việc học. Các lập trình viên thậm chí chỉ đơn giản là hack mọi thứ ở nhà sẽ khám phá các giải pháp mới và thú vị mà không bị ràng buộc bởi các doanh nghiệp lớn.

Nó không chi tiết như Joel Test, nhưng yêu cầu họ viết chương trình buzz fizz sẽ là một dấu hiệu tốt để xem liệu họ có thể viết mã được không.

http: //www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html và http://imranontech.com/2007/01/24/USE-fizzbuzz-to-find-developers- ai-Grok-mã hóa /

Điều đó sẽ không cho bạn biết về sự trưởng thành về kỹ thuật phần mềm của cá nhân, nhưng nó sẽ sàng lọc điều tồi tệ hơn.

Eh, tôi có cảm giác với từ ngữ khi bắt đầu. Đó không phải là "bạn đã sử dụng X" hay "Bạn có biết về Y" không, đó là vấn đề thực sự sử dụng và làm. Bất kỳ lập trình viên nào chưa chạm hoặc nghe thấy các mục trong bài kiểm tra Joel chỉ đơn giản là bị ngắt kết nối và cần phải có manh mối. Nhưng bạn đã đúng, các cửa hàng mã thất bại trong bài kiểm tra Joel vì mọi người trong các cửa hàng đều thất bại. Cách phòng thủ duy nhất tôi có thể thấy chạy dọc theo dòng "Tôi đã thử, nhưng không có thẩm quyền. Và bây giờ tôi đang áp dụng ở đây".

Bạn có sử dụng kiểm soát nguồn?

Đúng nhưng

• Nó không thực sự cho bạn biết bất cứ điều gì.
• Làm thế nào để bạn biết liệu tôi chuyển tiếp hợp nhất?
• Làm thế nào để bạn biết liệu tôi kéo thay đổi trước khi đẩy?
• Làm thế nào để bạn biết liệu tôi xây dựng trước khi cam kết vào kho lưu trữ.

Bạn có thể thực hiện xây dựng trong một bước?

• Vâng, lãnh đạo CI của chúng tôi viết kịch bản và tôi chỉ chạy chúng trong powershell.

Bạn có thực hiện xây dựng hàng ngày?

• Máy chủ CI của chúng tôi không

Bạn có một cơ sở dữ liệu lỗi?

Có, nhưng tôi chưa cấu hình nó và tôi không quản lý nó, tôi chỉ đơn giản sử dụng nó.

Bạn có sửa lỗi trước khi viết mã mới không?

• Trong một thế giới hoàn hảo, nơi tôi có tài nguyên không giới hạn - vâng tôi làm. Trong thế giới thực, đôi khi tôi buộc phải đăng nhập chúng và làm việc trên một cái gì đó khác.

Bạn có một lịch trình cập nhật?

Không, đó không phải là công việc của tôi.

Bạn có một thông số kỹ thuật?

Tôi được cung cấp một thông số kỹ thuật, sau đó tôi phân tích nó và sản xuất các tài liệu liên quan.

Các lập trình viên có điều kiện làm việc yên tĩnh?

• Bạn sẽ không thuê tôi nếu tôi nghe nhạc, nói chuyện với đồng nghiệp của tôi và làm một trò đùa? Phát triển phần mềm được coi là sáng tạo - điều kiện làm việc sẽ thay đổi từ tổ chức này sang tổ chức khác.

Bạn có sử dụng các công cụ tốt nhất tiền có thể mua?

Bạn không biết công cụ tốt nhất là gì và nếu bạn nghĩ rằng bạn làm, sẽ luôn có ai đó tranh luận về quan điểm của bạn.

Bạn có người kiểm tra?

Đúng. Trên thực tế, có và họ không tốt lắm, nhưng đó không phải là câu hỏi.

Các ứng viên mới có viết mã trong cuộc phỏng vấn của họ?

Có và họ thất bại. Vâng và họ vượt qua. Thứ này nói lên điều gì?

Bạn có làm kiểm tra khả năng sử dụng hành lang?

Không, nhưng nếu chúng ta làm điều gì đó tốt hơn?

Để kết luận:

• Bài kiểm tra này có thể hoạt động tốt trong một thế giới học thuật hoàn hảo, nơi mọi thứ chỉ hoạt động, mọi người hòa đồng, chia sẻ kiến ​​thức và có nguồn lực không giới hạn.
• Những gì bạn muốn biết là tôi là loại kỹ sư. Những câu trả lời đơn giản sẽ không cho bạn biết bất cứ điều gì hữu ích và tôi nghĩ rằng ai đó phải rất ngây thơ khi yêu họ.
• Câu trả lời ở trên, cả tiêu cực và tích cực đều không cho bạn biết bất cứ điều gì về khả năng tạo mã sạch của tôi.

Đây không phải là một câu nói hay, nhưng tôi sẽ rất thích nghe loại nhà phát triển mà bạn nghĩ tôi dựa trên các câu trả lời mà tôi đã cung cấp. Điều này hy vọng sẽ chứng minh quan điểm của tôi.