Cách tốt nhất để đánh giá lập trình viên mới là gì? [đóng cửa]

Cách tốt nhất để đánh giá các ứng viên tốt nhất để có một công việc mới (chỉ nói về kỹ năng lập trình) là gì? Trong công ty của tôi, chúng tôi đã có nhiều trải nghiệm tồi tệ với những người có điểm số tốt nhưng không có kỹ năng lập trình thực sự. Kỹ năng của họ chỉ đơn thuần giống như khỉ mã, không có khả năng phân tích vấn đề và tìm giải pháp.

Nhiều điều mà tôi phải lưu ý:

• Hệ thống giáo dục ở nước tôi tệ - thực sự tệ. Những người giỏi trong loại công việc này là tốt bởi vì họ có tài năng cho nó hoặc thực sự cố gắng tự học.

• Bằng đại học / sau đại học / sau đại học không có nghĩa là bạn biết chính xác cách thực hiện.

• Chứng chỉ cũng không có nghĩa gì ở đây vì những người phụ trách khóa học cấp chứng chỉ cũng không có kỹ năng (hoặc đang làm những công việc lương thấp).

Chúng tôi thực sự cần có được những ứng cử viên tốt, linh hoạt và không có suy nghĩ máy móc (bởi vì loại người này theo kinh nghiệm có hiệu suất thấp).

Chúng tôi ở trong một tổ chức chính phủ và những người là ứng cử viên không nhất thiết phải đến từ bên ngoài, nhưng chúng tôi có khả năng chấp nhận hoặc không chấp nhận bất kỳ ứng cử viên nào cho đến khi chúng tôi tìm thấy đúng.

Tôi hy vọng tôi không có vẻ quá tích cực trong câu hỏi của tôi; và BTW tôi là một lập trình viên.

chỉnh sửa: Tôi đã tìm ra rằng đã hỏi một cái gì đó thực sự phức tạp ở đây. Tôi sẽ bỏ chuyển "câu trả lời đúng" chỉ để cho cuộc thảo luận trôi chảy, không có bất kỳ sự thiên vị nào.

Về lựa chọn ứng cử viên, tôi thường đi với một kế hoạch ba lần:

• Kiểm tra thường xuyên với các câu hỏi mã hóa giống như FizzBuzz và nhiều câu hỏi kiến ​​thức mà họ phải đưa ra các ví dụ được mã hóa. Tùy thuộc vào vị trí, nó có thể là các nguyên tắc OO, nguyên tắc thiết kế SQL, v.v. Tôi tăng các khó khăn của các câu hỏi trong bài kiểm tra để xem chúng có thể đi được bao xa. Ý tưởng không thực sự là có tất cả các câu hỏi được trả lời (nếu có, càng tốt), mà còn để xem liệu họ có thể thừa nhận khi họ không biết điều gì không. Lòng tin là điều cần thiết và tôi không muốn có ai đó nói dối mình trong đội của mình.

• Quay trở lại bài kiểm tra với thí sinh và thảo luận xung quanh các câu trả lời. Có thể mở rộng các câu hỏi để đạt đến giới hạn của ứng viên. Điều này có thể được mở rộng, và càng mở rộng thì càng tốt.

• Phần cuối cùng nhưng không kém phần quan trọng, The Code Review . Tôi yêu cầu ứng viên mang một đoạn mã (tôi thường bỏ qua bài kiểm tra / thảo luận trước đó và bài đánh giá này trước một vài ngày, để họ viết và đánh bóng một đoạn mã). Sau đó, chúng tôi thực hiện đánh giá mã thường xuyên về nó với hai người: một người sẽ trực tiếp làm việc với ứng viên và người đã xem xét bài kiểm tra với ứng viên trước đó. Về đánh giá mã, bạn có thể đọc bài viết này từ JohnFX .

Khi kết thúc tất cả những điều này, bạn sẽ có thể quyết định xem bạn có muốn ứng viên này tham gia nhóm của bạn hay không.

Bắt đầu với việc cho họ FizzBuzz để giải quyết. Điều đó sẽ loại bỏ những điều tồi tệ nhất trong số họ.

Sau đó, một cái gì đó khó hơn một chút - ví dụ, làm thế nào để đảo ngược một chuỗi mà không được xây dựng trong các chức năng thư viện. Yêu cầu họ nói trong khi giải quyết để xem quá trình suy nghĩ của họ là gì.

Bạn có thể tiếp tục đưa ra những vấn đề khó khăn hơn nếu họ thấy những điều này rất dễ dàng, cho đến khi bạn tin chắc họ có thể đi bộ và không chỉ nói chuyện.

Chỉ cần tìm kiếm niềm đam mê trong công việc.

Để trích dẫn Joel, hãy tìm những người " Thông minh và hoàn thành công việc " .

Phần còn lại không quan trọng

Dựa trên 25 năm lập trình của tôi (trong đó, chỉ thừa nhận 5 hoặc 6 trường hợp thuê các lập trình viên khác):

Các chỉ số tích cực:

• Đam mê công nghệ

• Các chương trình như một sở thích

• Sẽ nói chuyện với bạn về một chủ đề kỹ thuật nếu được khuyến khích

• Các dự án cá nhân quan trọng (và thường là rất nhiều) trong những năm qua

• Tự học các công nghệ mới

• Ý kiến ​​về công nghệ nào tốt hơn cho các mục đích sử dụng khác nhau

• Rất khó chịu về ý tưởng làm việc với một công nghệ mà anh không tin là có quyền

• Rõ ràng thông minh, có thể có những cuộc trò chuyện tuyệt vời về nhiều chủ đề

• Bắt đầu lập trình từ lâu trước khi học đại học / đi làm

• Có một số tảng băng trôi ẩn giấu của người Hồi giáo, các dự án cá nhân lớn dưới radar CV

• Kiến thức về một loạt lớn các công nghệ không liên quan (có thể không có trong CV)

Các chỉ tiêu tiêu cực:

• Lập trình là một công việc hàng ngày

• Đừng thực sự muốn nói chuyện với cửa hàng, ngay cả khi được khuyến khích

• Học các công nghệ mới trong các khóa học do công ty tài trợ

• Rất vui được làm việc với bất kỳ công nghệ nào bạn đã chọn, tất cả các công nghệ đều tốt

• Có vẻ không thông minh lắm

• Bắt đầu lập trình tại trường đại học

• Tất cả kinh nghiệm lập trình là trên CV

• Tập trung chủ yếu vào một hoặc hai ngăn xếp công nghệ (ví dụ: mọi thứ phải làm với việc phát triển ứng dụng java), không có kinh nghiệm bên ngoài nó

Ngoài ra, tôi đề nghị:

• Các FizzBuzz kiểm tra (hoặc một cái gì đó giống như nó để kiểm tra khả năng cơ bản để viết một thuật toán.
• Phiên bản khó hơn của bài kiểm tra FizzBuzz (để đưa họ đến điểm thất bại hoặc gần thất bại.)
• Thảo luận về mã của họ và xem liệu họ có sẵn sàng tự phê bình và tìm kiếm các cải tiến (điều mà có lẽ họ không có thời gian thực hiện trong một bài kiểm tra ngắn), chẳng hạn như:
  • tên biến tốt (Tôi đã có các lập trình viên có kinh nghiệm rất giỏi sử dụng các biến trong sản xuất như "cờ" (WTF ??)
  • mô đun hóa.
  • Dự đoán các vấn đề và thực hiện "mã hóa phòng thủ"
• Một sự sẵn sàng để xem "lỗ hổng" là cơ hội để cải thiện. Tôi nghĩ rằng các lập trình viên giỏi nhất luôn luôn tìm kiếm những sai sót trong mã trước đó của họ. Họ không quá bình thường đến mức nghĩ rằng việc tìm ra một lỗ hổng của họ là một vấn đề cá nhân. Họ coi đó là một cơ hội để làm tốt hơn. (Những người không thể nhìn vào lỗ hổng một cách vô cảm hoặc bị choáng ngợp khi nhìn thấy một lỗ hổng (và trở nên siêu tự tin hoặc, để tránh điều đó, họ bỏ qua sai sót.
• Họ có thể gỡ lỗi không?
• Họ có thể kiểm tra đơn vị không? (Tôi đã nói chuyện với quá nhiều lập trình viên nói rằng "QC làm điều đó". Tôi không nói về Kiểm thử, tôi đang nói về kiểm thử: bạn viết một hàm, nó có hoạt động không? vấn đề có thể xảy ra (đầu vào NULL, v.v.)? Nếu bạn không thể làm điều đó, làm thế nào để bạn biết khi nào bạn hoàn thành?
• Họ có kỹ năng giao tiếp tốt? (ở mức tối thiểu: sự hiểu biết tốt và hiểu biết về bản thân khi họ làm và không hiểu và sẵn sàng nói "Tôi không hiểu, xin vui lòng giải thích lại".

Phần lớn tóm tắt ở trên là từ Làm thế nào để phát hiện ra một lập trình viên giỏi , đó là một bài viết tuyệt vời, tập trung hơn một chút vào các chỉ số phạm vi dài hơn. Nó chắc chắn xác nhận trực giác và kinh nghiệm của tôi. Đó cũng là rất nhiều thứ (như "đam mê") thường không được đề cập trong danh sách kiểm tra "những gì một lập trình viên giỏi".

Đánh giá trí thông minh lập trình là một hình thức của Turing Test. Do đó, hiện tại không có quy trình đánh giá mẫu kín nào được đảm bảo để hoạt động. Phải mất các lập trình viên thông minh để nhận ra các lập trình viên thông minh khác, nhưng chỉ với một số xác suất hợp lý.

Cơ hội của bạn sẽ tốt hơn nếu bạn có những người phỏng vấn trong nhóm của bạn có thể ngửi thấy công việc tuyết và không thích làm việc với những người ngu ngốc (ngay cả những người đẹp trai, có sơ yếu lý lịch ấn tượng và có thể tiết lộ tất cả các giải pháp đóng hộp thông thường từ bộ nhớ) .

. yêu cầu họ đăng nó nếu đó là một câu trả lời hay. Tương tự như một bản tóm tắt cho OCR có nguồn gốc đám đông.)

Cung cấp cho họ một vấn đề, tốt nhất là một vấn đề liên quan đến miền vấn đề mà họ sẽ giải quyết và yêu cầu họ thảo luận về cách họ sẽ tiếp cận nó. Bạn có thể yêu cầu họ thảo luận, mã giả hoặc viết các bit của mã thực tế tùy thuộc vào mức độ tự tin của bạn ở cấp độ kỹ năng của họ

Ví dụ: nếu tổ chức của bạn thực hiện hội nghị, hãy yêu cầu họ phác thảo cách họ sẽ mã hóa hệ thống đăng ký trực tuyến an toàn. Họ sẽ có thể bao gồm một số điều cơ bản và đặt câu hỏi tốt về chính xác những gì cần phải được thực hiện. Khi bạn tương tác, bạn sẽ có thể xác định xem họ có phù hợp với tổ chức của bạn không và vai trò bạn cần họ thực hiện.

Tôi không phải là một fan hâm mộ lớn của các bài kiểm tra đố lập trình và trêu ghẹo não. Mặc dù họ có thể vui vẻ đối với một số người, họ cũng có thể gây phiền nhiễu và / hoặc gây căng thẳng cho những người khác, bao gồm cả những người có thể phù hợp nhất với nhóm của bạn. Thêm vào đó, thông tin về nhiều bài kiểm tra như vậy có sẵn trực tuyến và sẽ khuyến khích nhồi nhét cho các bài kiểm tra và các chiến thuật khác sẽ làm giảm khả năng sống sót của chúng để đánh giá khả năng lập trình viên.

Đọc câu hỏi này và một số câu trả lời mà nó nhận được đã thôi thúc tôi viết một bài báo mà tôi cảm thấy có thể quan tâm:

Thực hành tuyển dụng kỳ quặc khi tuyển dụng nhà phát triển phần mềm

Ok, vì vậy tiêu đề bài viết là rác rưởi, nhưng bài viết đi vào trọng tâm của vấn đề. Đó không phải là vấn đề của ứng viên mà bạn đã chọn để phỏng vấn họ cho dù họ có thể không phù hợp với vai trò của bạn như thế nào. Nếu bạn không quản lý để xác định một quy trình tuyển dụng có nhiều yếu tố để cho phép bạn tìm ra những viên đá quý, thì bạn sẽ phải sống với hậu quả, và vâng, điều này có nghĩa là có được một vài ứng cử viên có thể không bao giờ đáp ứng với mong đợi của bạn. Lọc ứng viên của bạn dựa trên thư và sơ yếu lý lịch của họ đòi hỏi bạn trước tiên, yêu cầu ứng viên của bạn viết một lá thư về bản thân họ và những gì họ muốn từ vai trò, sau đó xem cách viết sơ yếu lý lịch. Nếu bạn chỉ có một hoặc hai ứng viên tiềm năng để phỏng vấn, thì có lẽ bạn đã thực hiện sàng lọc trước đúng cách.

Cuối cùng, khi bạn tìm thấy 1 hoặc 2 ứng cử viên mà bạn cho là thực sự xứng đáng với thời gian của mình, đừng chỉ hỏi một số câu hỏi của người kiểm tra inane, mà thay vào đó hãy đầu tư thời gian để tìm hiểu những người này và tham gia vào các cuộc thảo luận mở về phần mềm kỹ thuật nói chung. Bạn sẽ học được nhiều hơn từ cách tiếp cận thông thường về ứng viên hơn bao giờ hết trong tình huống phỏng vấn truyền thống (và có phần bất lợi). Ngoài ra, không chỉ đơn giản là giải quyết cho một cuộc phỏng vấn, mà thay vào đó hãy đối xử với các ứng cử viên chính của bạn cho một số cuộc họp nơi sử dụng thảo luận mở và nơi ứng viên có thể gặp gỡ các đồng nghiệp tương lai của họ. Thời gian không bao giờ lãng phí, vì các ứng cử viên không phù hợp sẽ không phát triển mạnh trong một cuộc thảo luận kỹ thuật cao, và sẽ cho thấy những sai sót của họ rất nhanh khi họ mất cảnh giác.

Bạn chưa nói ngôn ngữ nào, nhưng khá dễ để kiểm tra kiến ​​thức của ai đó. Nó cũng phụ thuộc vào mức độ bạn đang tìm kiếm, nhưng có một nhóm câu hỏi khá lớn liên quan đến các câu hỏi phỏng vấn.

Tuy nhiên, bạn quyết định tổ chức cuộc phỏng vấn của mình, đừng hỏi những câu hỏi phỏng vấn "câu đố tư duy bên" đó .

Tôi đề nghị bạn nên đi với một câu hỏi FizzBuzz và thuê người đầu tiên vượt qua. Các bài kiểm tra tiếp theo có xu hướng thiếu sót vì không phải mọi lập trình viên giỏi sẽ tiếp cận một vấn đề như bạn, hoặc xử lý một cuộc phỏng vấn mà không nói lắp, hoặc biết các ngôn ngữ bạn muốn hoặc quan tâm hoặc trao đổi như trao đổi số nguyên mà không cần biến số thứ ba (dù sao ai cũng cần điều đó? có nghĩa là, vì RAM vượt quá 128 byte?).

Hãy suy nghĩ về nó. Nếu câu hỏi FizzBuzz loại bỏ 199 trên 200, thì nó chỉ loại bỏ hàng trăm cuộc phỏng vấn. Bạn có thực sự sẽ phỏng vấn hàng trăm khách hàng tiềm năng?

Có vẻ như lợi nhuận giảm dần sau FizzBuzz. Đó là giả định rằng 199/200 thậm chí gần xấp xỉ. Và tôi cho rằng thời gian của BẠN cũng có giá trị ...

Tôi không chắc đây là bình luận hay trả lời nhưng về cơ bản những gì Matthieu nói. Bạn muốn những câu hỏi dễ ngu ngốc mất một hoặc hai phút (nhưng không quá 5) phút để làm và chúng nên về các lĩnh vực khác nhau.

Những ví dụ về câu hỏi dễ ngu ngốc như vậy là một câu hỏi về đệ quy như bạn có một danh sách và bạn phải in nó theo thứ tự ngược mà không sử dụng một vòng lặp. Một câu hỏi regex đơn giản nếu regex thường được thực hiện trong quá trình phát triển của bạn. Một câu hỏi về bit và byte nếu sử dụng C ++ (viết một mẫu chấp nhận char dài và in ra biểu diễn nhị phân. Không yêu cầu chuyên môn hóa, chỉ cần sử dụng sizeof () để tìm ra độ dài bit)

Bạn sẽ mất khoảng <= 3 phút mỗi câu hỏi

Hỏi họ về thử thách lập trình thú vị nhất mà họ từng cố gắng giải quyết nhưng không thể, họ đã sử dụng phương pháp nào trong khi giải quyết nó, tại sao họ không thể giải quyết và cách tiếp cận nào khác mà họ nghĩ có thể giải quyết.

Điều này là đủ để tôi đánh giá khả năng lập trình viên như một lập trình viên.

1. Họ có thể bảo vệ những gì họ tuyên bố họ biết? Họ đưa nó vào sơ yếu lý lịch / CV như một kỹ năng hoặc một cái gì đó họ đã làm trong một dự án khác. Xem làm thế nào sâu họ có thể đi vào chủ đề.

2. Họ có thể học được điều gì mới không? Nói về khía cạnh cấp cao của công nghệ bạn đang sử dụng hoặc một cái gì đó cụ thể cho nhà quản trị doanh nghiệp bạn làm việc và xem liệu họ có thể nắm bắt được chủ đề hay không. Họ có hỏi những câu hỏi thông minh không? Họ có thể đưa ra một sự tương tự? Nó có giống với những gì họ đã làm trong một ngành công nghiệp hoặc công nghệ khác không?

3. Họ có muốn lập trình không? Nó không phải là số một trong danh sách của họ, nhưng họ phải thể hiện sở thích viết mã. Và tôi có nghĩa là thực sự viết mã và làm một cái gì đó, không phải ngồi và nói về nó hoặc vẽ trên bảng cả ngày. Không phải để giảm thiểu lập kế hoạch hoặc để thúc đẩy mã hóa cao bồi, nhưng cuối cùng bạn phải có mã. Tránh những người tránh bàn phím. Đây không phải là một vị trí quản lý.

Bạn có thể thực hiện một số điểm trên thang điểm từ một đến mười điều hoặc chỉ dựa vào việc có thể ngửi thấy mùi của chính bạn.

Nếu nó làm cho bạn cảm thấy tốt hơn các lập trình viên xấu tồn tại ở hầu hết các quốc gia. Làm thế nào để loại bỏ chúng là vấn đề.

Làm cỏ đầu tiên là sơ yếu lý lịch. Một điều tôi tìm kiếm là rất nhiều kinh nghiệm ngôn ngữ được tuyên bố và không có gì để mô tả những gì họ đã làm trong ngôn ngữ đó. Tôi đã thấy sơ yếu lý lịch rằng họ biết mọi ngôn ngữ từng được phát minh và kinh nghiệm của họ cho thấy họ chỉ thực sự làm việc với Access và Visual Basic. Những người đi ngay trong thùng rác. Sơ yếu lý lịch 10 trang đi ngay vào thùng rác (đặc biệt là mười trang sơ yếu lý lịch từ những người có ít hơn 2 năm kinh nghiệm mà tôi đã nhận được). Từ những sinh viên tốt nghiệp đại học gần đây với ít kinh nghiệm, bạn phải thực sự kén chọn về cách họ thể hiện bản thân. Các candiates tốt nhất cẩn thận với sơ yếu lý lịch của họ, họ không có lỗi. Bạn có thực sự đang tìm kiếm một người quan tâm quá ít đến nỗi anh ấy không bận tâm đến việc đọc lại sơ yếu lý lịch của mình?

Sơ yếu lý lịch chuẩn bị chuyên nghiệp đi trong thùng rác quá. Khi bạn đã đọc hàng trăm hồ sơ xin việc, bạn có thể chọn chúng khi họ sử dụng cùng một cụm từ. Bạn không thể tin tưởng vào nội dung trong một bản lý lịch được chuẩn bị chuyên nghiệp và bạn biết người đó đã không tự chuẩn bị. Đây là kiểu người sẽ dựa vào người khác để giải quyết vấn đề của mình cho anh ta, bạn có thực sự muốn điều đó ở vị trí lập trình không?

Tìm kiếm những thứ làm cho người đó nổi bật cho những người bạn chọn. Tất nhiên điều đó khó hơn với những người vừa mới ra trường, nhưng hãy tìm kiếm những thành tựu, đóng góp cho nguồn mở, v.v.

Loại cỏ tiếp theo là phỏng vấn qua điện thoại. Hỏi về các khái niệm cơ bản liên quan đến công việc thực tế bạn có. Nếu mọi người không có kiến ​​thức cơ bản về các khái niệm bạn cần họ có, họ không đáng bận tâm để đưa vào một cuộc phỏng vấn cá nhân. Giới trẻ thường nghĩ rằng điều này là không công bằng vì họ có thể tra cứu mọi thứ trên Internet, nhưng sự thật là tôi chưa bao giờ gặp một lập trình viên giỏi, người phải tìm kiếm mọi thứ trên Internet. Bạn nên có một số kiến ​​thức về nghề nghiệp của bạn mà bạn không cần phải tìm kiếm mỗi lần.

Sau cuộc phỏng vấn qua điện thoại, bạn nên chọn 4-5 ứng viên tốt nhất và phỏng vấn. Tất nhiên, nếu bạn chỉ có 1-2 ứng cử viên tốt, đừng bận tâm đến việc phỏng vấn những người bạn đã loại. Bây giờ bạn sẽ hỏi những câu hỏi khó và cảm nhận về cách họ tiếp cận vấn đề. Tôi sẽ không bao giờ sử dụng bài kiểm tra fizzbuzz vì nó quá nổi tiếng nên câu trả lời không cho bạn biết gì. Thay vào đó tạo ra một số vấn đề từ cơ sở mã của riêng bạn. Tôi có thể cung cấp cho họ một yêu cầu và một đoạn mã và hỏi họ xem mã có đáp ứng yêu cầu không và nếu không thì tại sao không và họ có thể làm gì để đáp ứng yêu cầu đó. Tôi sẽ yêu cầu họ mô tả vấn đề lập trình khó khăn nhất mà họ phải giải quyết và những bước họ đã thực hiện để tìm câu trả lời. Tôi sẽ hỏi một số câu hỏi kỹ thuật sâu hơn. Hãy nhớ rằng bạn đang cố gắng để cảm nhận về năng lực kỹ thuật của họ, khả năng giải quyết và gỡ lỗi của họ và khả năng của họ để phù hợp với nhóm hiện tại của bạn. Tôi cũng đặt câu hỏi rằng họ không biết câu trả lời để đánh giá mức độ họ xử lý căng thẳng tốt như thế nào, đó là một công việc căng thẳng, tôi không muốn ai đó gấp trong cuộc phỏng vấn vì sự căng thẳng của công việc lớn hơn căng thẳng trong cuộc phỏng vấn . Tôi tìm kiếm những điểm mạnh trong các lĩnh vực chúng tôi hiện đang yếu và khả năng làm việc theo nhóm và để trình bày với khách hàng (nhà phát triển của chúng tôi giao dịch rộng rãi với người dùng), danh sách của bạn có thể khác. t muốn ai đó gấp trong cuộc phỏng vấn vì sự căng thẳng của công việc lớn hơn căng thẳng cuộc phỏng vấn. Tôi tìm kiếm những điểm mạnh trong các lĩnh vực chúng tôi hiện đang yếu và khả năng làm việc theo nhóm và để trình bày với khách hàng (nhà phát triển của chúng tôi giao dịch rộng rãi với người dùng), danh sách của bạn có thể khác. t muốn ai đó gấp trong cuộc phỏng vấn vì sự căng thẳng của công việc lớn hơn căng thẳng cuộc phỏng vấn. Tôi tìm kiếm những điểm mạnh trong các lĩnh vực chúng tôi hiện đang yếu và khả năng làm việc theo nhóm và để trình bày với khách hàng (nhà phát triển của chúng tôi giao dịch rộng rãi với người dùng), danh sách của bạn có thể khác.

Các ứng cử viên phải được đưa ra một vấn đề thực tế để giải quyết với quyền tự do sử dụng bất kỳ công nghệ nào.

Nếu cô ấy xuất hiện trong màu sắc bay, cô ấy vào!