FizzBuzz - thực sự? [đóng cửa]

Khi nói đến câu hỏi "kiểm tra phỏng vấn", chủ đề của FizzBuzz thường xuất hiện. Ngoài ra còn có một bài viết Mã hóa kinh dị về nó.

Bây giờ, nếu bạn bận tâm đọc các trang web như thế này, có lẽ bạn sẽ ít có khả năng nằm trong nhóm nhân viên lập trình, những người sẽ tìm thấy FizzBuzz bất cứ điều gì ngoài tầm thường.

Nhưng có thật là 99% lập trình viên sẽ phải vật lộn với nó?

Có thật không?

Bằng chứng để sao lưu này là gì?

Một số ví dụ thực tế sẽ rất hữu ích trong việc trả lời câu hỏi này.

99%? Không. Một tỷ lệ đáng kể? Đúng. Từ kinh nghiệm trực tiếp của chính tôi khi phỏng vấn mọi người, tôi có thể làm chứng cho điều này. Nó có vẻ không đáng kể đối với bạn nhưng có rất nhiều người trong lĩnh vực lập trình đã ít nhiều giả mạo trong nhiều năm và áp dụng vào các vị trí không nhập cảnh và thất bại ở vị trí này.

Ngay cả khi bạn CÓ THỂ dễ dàng giải quyết nó, nhưng bạn cho tôi động tĩnh lớn về việc được yêu cầu thực hiện một nhiệm vụ nguy hiểm như vậy sẽ chống lại bạn. Ở trong một đội có nghĩa là đôi khi phải làm những việc bạn có thể không thích nhưng là cần thiết. Nếu ngay lập tức, trước khi chúng ta bắt đầu làm việc cùng nhau, bạn nghĩ rằng tốt nhất nên thử và khẳng định tình trạng đặc biệt của mình là làm điều gì đó mà tôi đã yêu cầu bạn làm thì nó sẽ đóng vai trò chống lại bạn.

Tôi không quan tâm nhất thiết là giải pháp của bạn thanh lịch như thế nào (mặc dù điều đó sẽ rất tốt) nhưng nhìn thấy bạn đâm vào nó trên bảng trắng và nói theo cách của bạn thông qua nó cho tôi thấy rằng bạn ít nhất sẵn sàng đâm vào nó . Nếu bạn trở nên phẫn nộ và nói điều gì đó dọc theo dòng chữ "Tôi là người giải quyết vấn đề, không phải là một con khỉ mã!" sau đó bạn sẽ bị đánh gục một cái chốt.

Tôi đã có những người được phỏng vấn thẳng thừng từ chối thậm chí bắt đầu thử nó. Chỉ đơn giản là từ chối. Không. Uh uh. Sẽ không làm điều đó. Tôi hỏi một hoặc hai câu hỏi lịch sự hơn, cảm ơn họ đã dành thời gian và kết thúc cuộc phỏng vấn.

Tôi nói điều này như một người quản lý và là một nhà phát triển.

Tôi nghĩ rằng 99% lập trình viên đi xin việc (và không nhận được nó) có thể đấu tranh vì nó. Nhưng không phải 99% lập trình viên đang có năng suất giữ một công việc.

Đó là bản chất của quá trình tìm việc hiện đại của chúng tôi. Nhiều người nộp đơn không đủ điều kiện.

Bài viết Kinh dị Mã hóa đó cũng nói lên cách chúng ta dạy Khoa học Máy tính ngày nay. Trước đây (đặc biệt là tại MIT), bạn được yêu cầu học những thứ như Lisp, điều này đòi hỏi bạn phải nắm bắt các khái niệm như đệ quy.

Ngày nay mọi người được dạy Java vì nó được sử dụng rộng rãi trong công nghiệp và trọng tâm đã chuyển sang cú pháp thay vì tư duy lập trình sâu. Tôi không thích Java; Trên thực tế, tôi nghĩ đó là một ngôn ngữ lập trình đầu tiên lý tưởng. Nhưng tôi chưa thấy giáo viên hướng dẫn của tôi dạy các nguyên tắc lập trình sâu với nó.

Tôi ghét phải nói điều này nhưng

Lý do chính tôi thấy các câu hỏi lập trình không được trả lời là lỗi của người hỏi chứ không phải người trả lời.

Tôi có thể nhớ rõ một cuộc phỏng vấn khi tôi được hỏi cách tạo một thuật toán tìm kiếm bộ sưu tập cụ thể sẽ chạy trong thời gian không đổi (Cùng một số lần tra cứu bất kể có bao nhiêu mục trong bộ sưu tập). Tôi dò dẫm và vấp ngã trong 20 phút trước khi bỏ cuộc. Sau đó, thiên tài thực hiện cuộc phỏng vấn này đã tiến hành chứng minh câu trả lời là một thứ hoạt động gần như không đổi, nhưng vẫn không phải là thời gian không đổi. Một chút như nói "Hãy cho tôi một câu trả lời bằng không" và sau đó chấp nhận 0.1.

Nói ngắn gọn là tôi đã thấy quá nhiều trường hợp ai đó đang phỏng vấn đang hỏi một câu hỏi không đáp ứng các tiêu chí sau:

1. Họ biết tất cả các câu trả lời đúng có thể.
2. Họ biết tại sao câu trả lời đúng là đúng.
3. Họ biết làm thế nào để thực sự cung cấp đủ thông tin mà không đưa ra câu trả lời.
4. Các câu hỏi "giải quyết vấn đề" không dựa vào kiến ​​thức về một sự kiện không được tiết lộ (đây là vấn đề lớn nhất tôi từng thấy).
5. Sẽ mất ít hơn 1 phút để viết câu trả lời nếu bạn không phải tìm ra câu trả lời. Nếu chỉ mất 5 phút để nhập mã, nó thực sự đòi hỏi nhiều cách giải quyết vấn đề hơn là có thể phù hợp với phần bằng lời của cuộc phỏng vấn.
6. Các câu hỏi được dựa trên nhiều hơn là "Một vấn đề tôi gặp phải một lần hoặc tôi được đưa ra ở trường và vì vậy bạn nên biết cách giải quyết nó ngay bây giờ ". Tôi cá là bạn đã có hơn 2 phút để trả lời, tại sao bạn không cho ứng viên lịch sự như vậy.

Nghiêm túc (1), tôi nghĩ yêu cầu mọi người viết mã trong phần bằng lời của một cuộc phỏng vấn là ngu ngốc.

Nghiêm túc (2), tôi nghĩ phỏng vấn mọi người mà không yêu cầu họ viết mã cũng là ngu ngốc.

Nghiêm túc (3), bạn nên cho họ "bài tập về nhà", yêu cầu họ mang theo các mẫu mã, hoặc đưa cho họ một máy tính xách tay và một vài câu hỏi và văn phòng yên tĩnh để làm việc với họ. Sau đó để chúng một mình trong khi họ làm việc trên chúng. Tôi thường đi theo cách tiếp cận thứ hai vì nó giới hạn khả năng của họ để có được sự giúp đỡ bên ngoài (gian lận) và tôi có thể bỏ thời gian.

Tất cả bạn cần làm là tìm kiếm trên FizzBuzz. Có một làn sóng lớn các bài đăng trên blog. Nói chung, blogger nói "Tôi đã nói với mọi người viết nó bằng [một số ngôn ngữ] và đây là những loại sai lầm mà họ đã gây ra:" và sau đó liệt kê một số cạm bẫy. Niềm vui bắt đầu từ những bình luận mà mọi người nói "ha! Đó là chuyện nhỏ trong [một số ngôn ngữ khác], tất cả những gì bạn phải viết là đây:" theo sau là mã. Bình luận tiếp theo luôn luôn tìm thấy lỗi trong cái đầu tiên đó. Có vẻ như một số nhà phát triển rất giỏi không hiểu đúng ngay từ lần đầu tiên, bằng bất kỳ ngôn ngữ nào. Một số lỗi:

• Tôi đã yêu cầu 1 đến 100 và bạn đã làm 1 đến 99 hoặc 0 đến 99
• nhầm lẫn về việc có nên in số cùng với fizz và / hoặc buzz
• những bất đồng về "fizzbuzz" và "fizz-buzz"
• bỏ lỡ tối ưu hóa, như so sánh hai lần khi một lần sẽ làm
• nhiều hơn

Khi tôi tuyển dụng, tôi yêu cầu mọi người viết mã cho bảng trắng cho tôi, không có gì phức tạp cả (tôi biết, bạn không nghĩ nó phức tạp) và nhiều ứng viên thất bại hoàn toàn. Ý tôi là thích viết kiểu vb If, Then, End If nhưng cũng đặt niềng răng (chỉ để ở bên an toàn tôi đoán) hoặc viết C # (và hỏi trước, C #?) Nhưng không có một dấu hai chấm ở bất cứ đâu. Đừng bắt đầu với tôi về lỗi logic!

Tôi đã đọc bài viết Kinh dị mã hóa mà bạn đề cập, và ý kiến ​​của tôi là Jeff nói đúng ... nhưng lần cuối cùng anh ta được phỏng vấn là khi nào?

Khi bạn được phỏng vấn, bạn thường bị căng thẳng cao độ và bạn thường phải trả lời các câu hỏi lý thuyết (không quan tâm, không google, không chia sẻ lại, ... chỉ có trí nhớ của bạn gặp rắc rối vì căng thẳng). Điều đó giống nhau trong các bài kiểm tra. Căng thẳng không giúp bạn.

Tôi đã nhận thấy rằng cách duy nhất để biết ai đó phù hợp với vị trí đó là làm việc với anh ta một thời gian ... Chỉ cần lấy 10 người cuối cùng bạn thuê trong số 100 (có thể nhiều hơn), bao nhiêu là một điều thực sự tốt Thuê???

Người sử dụng lao động nên thuê một người giải quyết vấn đề, không phải là một con khỉ mã biết về moduline.

Bạn không thể kiểm tra "trong một thời gian tất cả các ứng viên", vì vậy việc phỏng vấn họ là bắt buộc. Đó là lý do tại sao tôi tập trung câu hỏi của mình vào đó (giải quyết vấn đề) và kiểm tra tham chiếu trong quá khứ.

Ý kiến ​​của tôi là FizzBuzz là nguy hiểm cho công ty đang tìm kiếm các nhà phát triển để ngăn chặn sự tăng trưởng của nó.

Gần đây tôi được giao nhiệm vụ phỏng vấn hơn 50 lập trình viên cho một vị trí cấp cao nơi họ sẽ làm việc chủ yếu với PHP.

Tôi đã đưa ra vấn đề fizzbuzz trong bài kiểm tra sàng lọc, chủ yếu là để giải trí và vì tôi muốn có mười câu hỏi hay và chỉ có chín câu hỏi. Ý định của tôi, vào thời điểm đó là cho mọi người thấy rằng chúng ta cũng có thể vui vẻ, ngay cả trong các câu hỏi phỏng vấn.

80% ứng viên đã giải quyết vấn đề, nhưng không sử dụng toán tử mô đun.

15% ứng viên không thể giải quyết vấn đề.

5% ứng viên đã giải quyết vấn đề bằng cách sử dụng toán tử mô đun.

Mặc dù việc lấy mẫu của tôi khá hạn chế (50 ứng viên từ một quốc gia), tôi có thể nói với bạn rằng:

95% trong số họ có bằng BS trở lên trong chương trình giảng dạy CS (các trường đại học ở đây cạnh tranh bằng cách cố gắng làm cho âm thanh CS trở nên ngoạn mục hơn).

Tôi thực sự ngạc nhiên. Chà, sợ hãi .. nhưng kinh ngạc. Tôi không nghĩ rằng tôi đến gần để tái tạo kết quả, vì vấn đề đã trở nên rất phổ biến. Điều này cho tôi thấy rằng 5% ứng viên của tôi có thể không phải là siêu lập trình viên, nhưng ít nhất họ đọc các blog liên quan đến lập trình.

Trong vòng tuyển dụng cuối cùng của tôi, tôi có 3 công nhân xây dựng với 0, tôi lặp lại số 0, giáo dục lập trình hoặc kinh nghiệm áp dụng cho vị trí nhà phát triển phần mềm. ^* Vì vậy, đó là đáy của thùng. Nếu bạn giả định phân phối kỹ năng bình thường, thì bạn có thể thấy mức độ kỹ năng trung bình sẽ khá thấp và thậm chí 'trên trung bình' (trong số những người đăng ký) vẫn sẽ tương đối tệ.

Bây giờ, nếu bạn đang xì hơi chỉ những ứng viên có khả năng lập trình, bạn sẽ thấy rằng bây giờ bạn có:

1. kẻ nói dối
2. Những người đam mê buzzword (Tôi đã đọc một bài viết về .NET một lần)
3. lập trình viên thực tế xấu
4. những người đã sử dụng một công nghệ để hoàn thành một dự án, nhưng không tìm hiểu về nó (xem các câu hỏi của fizzbuzz về idis Dùng để xác định những điều này)

Ngoài ra, một số câu hỏi 'fizzbuzz' mà tôi đã thấy là tên miền cụ thể. Bạn có thể phát triển dần dần với ngôn ngữ / khung x trong một số năm (do đó, kinh nghiệm z năm với x) và không bắt gặp một số phần nhất định của nó (nhà phát triển thư viện không biết nhiều về phát triển thành phần UI chẳng hạn.)

Tương tự như vậy, rất nhiều nhà phát triển thực hiện bảo trì phát triển ngày nay, do đó kỹ năng thiết kế / kiến ​​trúc của họ có thể yếu ở một số khu vực.

Bây giờ, tôi không chắc 99% có chính xác không, nhưng IME vẫn còn khá cao. Ít nhất là trong phạm vi 80%.

^{* Không, chúng tôi đã không gọi hoặc thậm chí cung cấp cái nhìn thứ hai về các ứng dụng này.}

Vâng thật đấy. Có lẽ không phải 99% nhưng vẫn khá cao. Tôi đã từng phỏng vấn sinh viên khoa học máy tính cho các kỳ thực tập và tuyển dụng toàn thời gian. Tôi sẽ phỏng vấn khoảng 25 sinh viên tại một trường cao đẳng. Chúng tôi đã nói không được hỏi những câu hỏi tương tự, bởi vì các sinh viên đã nói chuyện. Tôi nhanh chóng biết rằng điều đó không thành vấn đề, bởi vì tôi sẽ chỉ nhận được 3 hoặc 4 sinh viên trong số 25 người có thể trả lời câu hỏi đầu tiên của tôi. "Viết strcmp"

Tôi yêu cầu họ viết một hàm để so sánh hai chuỗi. Có lẽ để sử dụng chức năng để sắp xếp các từ cho một từ điển. Bạn sẽ ngạc nhiên về số lượng sinh viên không hiểu cách so sánh hai từ, chứ đừng nói đến việc viết hàm. Và một số trong những sinh viên này tuyên bố họ có tất cả điểm A trong CSc.

Có điều là lập trình RẤT KHÁC BIỆT. Rất nhiều người thích nghĩ rằng họ biết cách lập trình, nhưng họ không làm thế.

Một vài suy nghĩ:

• Tôi sẽ không chống lại ai đó nếu chương trình của họ có một số lỗi nhưng rõ ràng họ có ý tưởng đúng. Gỡ lỗi là một phần của lập trình.

• Tôi nghĩ thật buồn khi có rất nhiều người đang xin việc mà họ không biết họ không thể làm được. Có vẻ như tôi là một vấn đề với nền kinh tế.

• Thật dễ dàng để hỏi mọi người những câu hỏi tồi, trong đó câu trả lời "đúng" duy nhất là câu hỏi mà người phỏng vấn sẽ đưa ra.

Bài kiểm tra này rất độc đáo bao gồm một số điều tôi muốn biết về một lập trình viên mà tôi có thể thuê:

1. Bạn thậm chí có thể lập trình được không?
2. Bạn có thể viết một chương trình từ đầu không (vì không phải ai cũng có thể !!!)
3. Bạn có thể giải quyết một vấn đề mà không qua -thinking nó.

Để giải thích về điểm cuối cùng, có vô số giải pháp cho fizz-buzz. Bạn có đi cho dễ đọc? Tốc độ? Lực hấp dẫn? Bạn có cố gắng hoàn thành việc viết chương trình một cách nhanh chóng? Làm thế nào một lập trình viên tấn công vấn đề đơn giản này là rất nói. Nếu một lập trình viên không thể chọn một giải pháp và xem nó đến cùng, điều đó cho bạn biết về cách người này sẽ thực hiện trong một nhiệm vụ thực sự?

Thật không may, nhiều người có sơ yếu lý lịch ấn tượng dường như thiếu các kỹ năng lập trình cơ bản. Tôi đã thấy nhiều trường hợp khi những người liệt kê C và C ++ trong sơ yếu lý lịch của họ không thể trả lời các câu hỏi cơ bản về con trỏ.

Có hai loại người tôi hy vọng rằng FizzBuzz sẽ giúp tôi tránh.

1. Vũ công không có kiến ​​thức về lập trình hoặc không có kiến ​​thức liên quan về lập trình. Thông thường bạn có thể nhận ra những điều này từ CV nhưng không phải lúc nào cũng vậy và giao cho họ một nhiệm vụ lập trình đơn giản là một cách tốt để làm rõ rằng họ không phải là lập trình viên.
2. Học sinh tốt nghiệp trường Java, người đã hoàn thành khóa học lập trình hoặc bằng cấp nhưng thực sự không biết cách lập trình. Những người này có thể khó lọc hơn vì họ có thể nói về lý thuyết nhưng họ không có kỹ năng thực tế. Đặt một vấn đề đơn giản trước mặt họ và yêu cầu một giải pháp và giải thích về giải pháp là một cách khá hay để thấy sự khác biệt giữa Petra Java và Paula Bean.

Trong cả hai trường hợp, tôi không thực sự quan tâm đến việc thực hiện hoàn hảo. Bài kiểm tra mà bạn cần thực hiện với những người xin việc cho nhà phát triển là họ có thể lập trình được gì không.

Điều đó nói rằng, tôi có lẽ sẽ không bận tâm với bài kiểm tra cụ thể đó vì nhiều lý do bây giờ. Đầu tiên, nó rất nổi tiếng và một trong các nhóm trên sẽ nhanh chóng thử nó. Thứ hai, tôi thích sử dụng các câu hỏi trên màn hình điện thoại của Steve Yegge để sàng lọc những người không phải là lập trình viên trước khi chúng tôi đưa họ vào. Nếu ai đó nhận ra những câu hỏi đó có nghĩa là họ đã đọc blog của Steve Yegge sẽ gợi ý cho tôi rằng họ đang ở trong top 1% các nhà phát triển coi trọng nghề nghiệp của họ và chắc chắn đảm bảo một cuộc phỏng vấn. Tương tự như vậy nếu ai đó có một số đại diện tốt ở đây hoặc trên SO tôi sẽ có xu hướng phỏng vấn họ.

Thật khó để tin rằng các nhà phát triển không thể mã hóa FizzBuzz cho đến khi bạn thấy "chín đến chín" sao chép và dán công việc của họ lại với nhau và cố gắng không viết mã. Tôi không thể tin được khi tôi nghe một trong những nhà phát triển cấp cao của chúng tôi dạy một nhà phát triển C #, với 3 năm "kinh nghiệm", cách sử dụng Từ điển. Giao diện? Thiết kế mẫu nào? cứng đầu? YAGNI? Sự dẫn dắt của tôi chưa bao giờ nghe nói về YAGNI! Thật đáng kinh ngạc những gì những người này không biết.

Tôi tin nó bây giờ. Tôi cũng nghĩ rằng có quá nhiều nhà phát triển chỉ cần làm đủ.

Tôi nghĩ một phần lý do tại sao nó là một câu hỏi phổ biến như vậy là bởi vì có nhiều cách để trả lời nó, và tùy thuộc vào cách ứng viên chọn đi có thể cung cấp cho bạn cái nhìn sâu sắc về cách họ viết mã. Một số ví dụ tuyệt vời có thể được nhìn thấy ở đây nếu bạn có 10K rep trên Stack Overflow.

Theo thống kê 99%, hãy kiểm tra xem con số đó đến từ đâu. Nó có lẽ là thiên vị. Nếu nó dựa trên các lập trình viên mới bắt đầu phỏng vấn cho công việc đầu tiên của họ, thì tôi có thể thấy điều đó là có thể, đặc biệt là nếu phần lớn các ứng cử viên của họ sắp ra khỏi trường đại học. Tôi thực sự có thể nghĩ về một người có lẽ sẽ viết ra một điều kiện 100 nếu tuyên bố là một giải pháp cho vấn đề đó.

Tôi thấy tuyên bố rằng 99% các lập trình viên không thể lập trình hoặc để giải một bài kiểm tra mã hóa đơn giản rất phóng đại. Trong trường hợp thử nghiệm FizzBuzz, bạn đã gặp phải vấn đề này trước đây và có thể dễ dàng giải quyết nó với toán tử modulo hoặc bạn chưa gặp phải nó trước đây và sẽ phải vật lộn với nó. Nó không nói gì với người phỏng vấn về kỹ năng lập trình của bạn.

Tôi nghĩ rằng vấn đề với nhiều lập trình viên dường như để lại ấn tượng xấu trong một cuộc phỏng vấn nằm ở bản chất của các phương pháp phỏng vấn kỹ thuật. Người phỏng vấn mong muốn ứng viên ghi nhớ và tái tạo ngay cú pháp ngôn ngữ, chi tiết và độ phức tạp tính toán của cấu trúc dữ liệu, kiến ​​trúc phần cứng, mẫu thiết kế, v.v., v.v. Lĩnh vực khoa học máy tính / kỹ thuật phần mềm là rất lớn. Không thể và vô cảm khi cố gắng ghi nhớ mọi thứ.

Trong thế giới thực, mấu chốt là có thể hiểu được vấn đề lập trình / thiết kế được giao cho bạn và biết nơi tìm thông tin (IDE, trang man, sách, google, v.v.) cách giải quyết vấn đề của bạn. Đây là một cái gì đó tuy nhiên người phỏng vấn không bao giờ kiểm tra.

Tôi vẫn còn là một lập trình viên tương đối mới (tôi đã viết mã được khoảng 2 năm và mã hóa ở một số khả năng chuyên môn như một trách nhiệm phụ trong khoảng 2 trước đó) vì vậy hãy sử dụng đủ hạt muối.

Tôi có một số kinh nghiệm làm màn hình đầu tiên cho các lập trình viên cho Dự án Doanh nghiệp Lớn (chúng tôi biết rằng dự án đã bị tiêu diệt, nhưng này, họ muốn trả tiền dù sao). Là lập trình viên duy nhất tại công ty tuyển dụng, tôi được giao nhiệm vụ xem xét hồ sơ xin việc và sàng lọc ứng viên.

Đây là một dự án của chính phủ nên có lẽ nó không thu hút được những ứng viên tài năng nhất, nhưng tôi đã không nhận được một ứng dụng từ bất kỳ ai có tài khoản github thực sự có mã hiển thị, cũng như bất kỳ ai có danh mục đầu tư, vì vậy tôi đã sử dụng fizzbuzz ( nghĩa đen là vấn đề chính xác) như là một lần đầu tiên vượt qua bất cứ ai trông giống như họ có thể lập trình.

Tôi đã mở đầu bằng một lời xin lỗi giả nói rằng tôi biết điều đó thật ngu ngốc nhưng tôi chỉ muốn xem bất kỳ mã làm việc nào, và nếu họ muốn họ có thể gửi một ví dụ khác có giá trị tương đương hoặc lớn hơn hoặc bất cứ điều gì, nhưng fizzbuzz sẽ đủ.

Kết quả: Tôi đã không nhận được một câu trả lời nào thực sự chính xác, điều này gây choáng váng khi xem xét khối lượng câu trả lời trên internet. Thậm chí không ai bận tâm đạo văn. Chúng tôi phải đi thuê những người trước đây đã làm việc trong các lần lặp lại thất bại trước đó của dự án.

Sau cú sốc ban đầu của cuộc tập trận và thất vọng về việc phần mềm / hợp đồng của chính phủ bị vặn vẹo như thế nào, tôi cảm thấy tốt hơn nhiều về kỹ năng của chính mình, những chiến thắng nhỏ như vậy?

Chỉnh sửa: Bằng cách không chính xác, tôi không có nghĩa là lỗi do lỗi (nghĩa là tôi đã yêu cầu từ 100 đến 99) hoặc một số lỗi vô tội khác là một sửa chữa dễ dàng. Tôi có nghĩa là không hoạt động, sẽ không chạy / biên dịch / vv hoặc cho thấy rõ rằng vấn đề chỉ là không đọc và hiểu, cũng là một phần đáng kể đã rút ứng dụng và thay vào đó không gửi một số mã nào khác.