Hiệu quả của FizzBuzz và Beyond [đã đóng]

Là một phần của quá trình phỏng vấn, ban đầu chúng tôi yêu cầu các ứng viên thực hiện 'FizzBuzz' hiện nay tỷ lệ ứng viên có thể trả lời chính xác FizzBuzz đã tăng đáng kể - điều này có thể là do sự phổ biến trên web.

Khoảng một năm trước, như một câu hỏi thứ hai, chúng tôi bắt đầu hỏi một câu hỏi rất giống với FizzBuzz ban đầu. Câu hỏi được thiết kế đơn giản như FizzBuzz ban đầu, và cũng để đánh giá một khả năng cụ thể của ứng viên, cụ thể là khả năng đặt hàng và ưu tiên một cách có ý nghĩa và hợp lý một bộ "quy tắc kinh doanh" đã được cung cấp trong một số trật tự tùy ý. Từ ngữ của câu hỏi ban đầu có vẻ hơi mơ hồ, điều này có thể gây khó khăn cho những người không nói tiếng Anh bản địa, nhưng nếu suy nghĩ thấu đáo có thể được giải quyết chính xác - Ngoài ra, nó còn cho ứng viên cơ hội đặt câu hỏi để làm rõ, đây luôn là một điều tốt .

Chúng tôi thấy đây là một kỹ năng rất quan trọng cần có với tư cách là nhà phát triển, vì phát triển phần mềm thường dựa trên các yêu cầu chức năng xuất phát không theo thứ tự cụ thể theo thời gian, có thể đặt ra các ràng buộc và điều kiện đối với các khu vực khác của phần mềm mà không chỉ ra rõ ràng và đó là công việc của nhà phát triển sắc sảo ít nhất là điều tra các vấn đề tiềm ẩn và xung đột liên quan đến việc thực hiện.

Những gì chúng tôi tìm thấy là hơn 65% số ứng cử viên (cỡ mẫu 38) đã vượt qua FizzBuzz hoàn toàn thất bại FizzBuzz v2.0 Thông thường những ứng cử viên này sẽ được phát hiện sau đó trong quá trình, nhưng có vẻ là một cách hay để phát hiện họ sớm.

Câu hỏi của tôi không phải là về việc FizzBuzz có lỗi thời hay không, mà là những yếu tố nào có thể đóng góp cho số lượng lớn ứng viên thất bại trong câu hỏi FizzBuzz v2.

• Là câu hỏi quá mơ hồ?
• Có phải sự căng thẳng của một môi trường phỏng vấn làm giảm khả năng suy nghĩ nghiêm túc đến mức không thể hoàn thành một nhiệm vụ tầm thường như vậy?

Câu hỏi:

Viết một thói quen trong ngôn ngữ lập trình yêu thích của bạn sẽ lấy danh sách các chuỗi làm đầu vào và cho mỗi chuỗi trong danh sách sẽ thực hiện một trong các thao tác sau:

1. Chỉ in Fizz nếu chuỗi chứa chữ A
2. Chỉ in Buzz nếu chuỗi chứa chữ B
3. Chỉ in BuzzBuzz nếu chuỗi chứa cả A và B
4. Chỉ in FizzFizz nếu chuỗi không chứa cả A và B
5. Chỉ in FizzBuzz nếu chuỗi chỉ chứa một A và chỉ một B

Một số câu hỏi điển hình của các ứng viên là:

• Có nên phân biệt chữ hoa chữ thường?
• "Có chứa A và B" có nghĩa là A nên đến trước B không
• Những gì cần được in nếu không có điểm nào được đáp ứng?
• Điều gì sẽ xảy ra nếu nhiều hơn một điều kiện có thể được đáp ứng?

Chúng tôi thấy rằng phần lớn các ứng cử viên đã hoàn thành thành công câu hỏi, không hỏi bất cứ điều gì họ chỉ làm giống như họ đã làm FizzBuzz.

Nó có khả năng trở thành một bài kiểm tra tốt hơn nhiều so với FIZZBUZZ, nhưng nếu bạn có bất kỳ khái niệm nào về một câu trả lời đúng, thì đó là bài kiểm tra tồi tệ nhất trên thế giới. Những bài kiểm tra này có rất ít giá trị trong các cuộc phỏng vấn để bắt đầu.

Nếu một ứng viên trả lời "Chính xác" mà không đặt câu hỏi, thì bạn có một vấn đề là lựa chọn ứng viên sẽ chọn sai loại lập trình viên - Anh ta không thể xác định các yêu cầu mơ hồ hoặc không thể hiểu rằng hầu hết mọi người không thể viết các yêu cầu rõ ràng . Không có vấn đề gì nếu chương trình hoàn hảo về mặt kỹ thuật ở mọi khía cạnh, có khả năng anh ấy là kiểu người sẽ cung cấp phần mềm với câu "Tôi không quan tâm đó không phải là điều bạn muốn, đó là những gì bạn yêu cầu".

Phần của bài kiểm tra ở đây là thứ tự ưu tiên của các quy tắc. Bạn không chỉ định nó. Đầu vào "ABC" có thể in Fizz, Buzz, BuzzBuzz hoặc FizzBuzz - bất kỳ một trong số này là chính xác

Ứng cử viên mà tôi sẽ chọn là người có được (hầu hết) đúng, nhưng đã hỏi rất nhiều câu hỏi và, lý tưởng nhất, đã làm rất nhiều "lảng tránh" trên bảng trắng.

Chẳng hạn, tôi sẽ khám phá sự hiểu biết của tôi về những yêu cầu đó bằng cách đưa cho bạn một loạt các văn bản mẫu và hỏi bạn những gì bạn dự kiến ​​sẽ được in, và tại sao. - Thảo luận về đầu vào ví dụ "ABC" của tôi sẽ dẫn đến một số thông tin hữu ích cho bạn.

Giống như FIZZBUZZ, kết quả của bài kiểm tra này chỉ tốt như những quan sát của bạn về cách thu được kết quả - kết quả không liên quan.

Tôi sẽ điều chỉnh nó một chút - chỉ để làm cho nó thú vị hơn - lấy cái 'duy nhất' ra. Nó được trình bày trong dòng trên ("in một trong những điều sau đây") và xem có bao nhiêu người hỏi về nó. Nếu ứng viên bỏ lỡ "chỉ" và bạn có thời gian, hãy chỉ ra và xem điều gì sẽ xảy ra. Nếu anh ta xử lý "chỉ", hãy xóa nó khỏi yêu cầu và yêu cầu họ thay đổi mã.

Từ "chỉ" trong yêu cầu của bạn tạo ra mâu thuẫn trong tất cả các câu hỏi.

Do đó, câu hỏi của bạn kiểm tra các yêu cầu thu thập trong khi chịu áp lực, bạn có chắc chắn muốn kiểm tra sự kết hợp các kỹ năng đó không?

Nếu bạn muốn kiểm tra thu thập yêu cầu, tôi khuyên bạn nên tạo MỘT trong những câu hỏi mơ hồ. Nếu bạn muốn thay thế cho FizzBuzz, hãy xóa sự mơ hồ.

Ưu tiên các quy tắc kinh doanh chỉ có thể được thực hiện với kiến ​​thức cụ thể về tên miền - trừ khi bạn bao gồm một số bối cảnh đơn giản cho những gì bạn đang làm (có lẽ chúng là phiếu giảm giá để được đổi lấy các giá trị khác nhau), không có cơ sở nào để nhà phát triển đưa ra quyết định của riêng mình.

Nhưng yêu cầu ai đó yêu cầu làm rõ nơi làm như vậy có nguy cơ đáng kể về kết quả không mong muốn, có lẽ không phải là cách tốt nhất để đánh giá kỹ năng của họ trong việc nhận ra giới hạn kiến ​​thức của họ. Họ có thể đoán rằng sẽ an toàn hơn khi đoán và hiểu sai, hơn là chỉ ra rằng bạn không đủ năng lực trong yêu cầu viết hoặc nếu không có người phỏng vấn nào là nhà phát triển, bị coi là có thái độ không tốt.

Chúng tôi thấy rằng phần lớn các ứng cử viên đã hoàn thành thành công câu hỏi, không hỏi bất cứ điều gì họ chỉ làm giống như họ đã làm FizzBuzz.

Với sự mơ hồ của các yêu cầu, người ta không thể hoàn thành v2.0 một cách chính xác mà không đặt câu hỏi.

Nếu bạn muốn xóa bất kỳ sự mơ hồ nào, bạn có thể thay đổi các yêu cầu thành:

Viết một thói quen trong ngôn ngữ lập trình yêu thích của bạn sẽ lấy danh sách các chuỗi làm đầu vào và đối với mỗi chuỗi trong danh sách, hãy làm như sau:

1. In "Fizz" nếu chuỗi chứa ký tự '$' và không chứa '?'.
2. In "Buzz" nếu chuỗi chứa ký tự '?' và không chứa '$'.
3. In "FizzBuzz" nếu chuỗi chứa chính xác một '$' và chính xác một '?'.
4. In "BuzzBuzz" nếu chuỗi chứa chính xác một '$' và nhiều hơn một '?'.
5. In "BuzzBuzz" nếu chuỗi chứa chính xác một '?' và nhiều hơn một '$'.
6. In "FizzFizz" nếu chuỗi không chứa '$' và không chứa '?'.

Là câu hỏi quá mơ hồ?

Vâng, câu hỏi quá mơ hồ để được trả lời mà không làm rõ. Tuy nhiên, một quy tắc bổ sung nói rằng trong trường hợp khi áp dụng nhiều quy tắc, chương trình của bạn nên chọn điều cụ thể nhất, nên loại bỏ sự mơ hồ.

Có phải sự căng thẳng của một môi trường phỏng vấn làm giảm khả năng suy nghĩ nghiêm túc đến mức không thể hoàn thành một nhiệm vụ tầm thường như vậy?

Có nhiều khả năng là một dấu hiệu của ứng cử viên "nhồi nhét" FizzBuzz: căng thẳng hay không, chương trình rất đơn giản.

Tôi nghĩ rằng FizzBuzz đã sửa đổi không thể so sánh với bản gốc, bởi vì giải pháp lý tưởng của nó là khác nhau: mặc dù một chuỗi if-then-elsevẫn có thể chấp nhận được, tôi nghĩ rằng một giải pháp dựa trên bảng phù hợp hơn cho vấn đề này:

static string[,] FB = new string[3,3] {
    {"FizzFizz", "Buzz", "Buzz"}
,   {"Fizz", "FizzBuzz", "BuzzBuzz"}
,   {"Fizz", "BuzzBuzz", "BuzzBuzz"}
};
static string FizzBuzz(string str) {
    return FB[
        Math.Min(str.Count(c => c == 'a'), 2)
    ,   Math.Min(str.Count(c => c == 'b'), 2)
    ];
}

Kích thước của không gian vấn đề là 3x3, 2x2vì vậy, nó ánh xạ tới một bảng dễ dàng hơn nhiều so với FizzBuzz ban đầu. Trong thực tế, tôi tìm thấy một giải pháp dựa trên bảng cho vấn đề FizzBuzz ban đầu khó hiểu hơn.

private static string[] FB = new[] {"{0}", "Fizz", "Buzz", "BizzBuzz"};
public static void Main() {
    for (var i = 1 ; i <= 100 ; i++) {
        Console.WriteLine(FB[(i%5==0?2:0)+(i%3==0?1:0)], i);
    }
}

Hai điều ở đây:

1. vâng tôi nghĩ rằng hầu hết mọi người chỉ googled fizz buzz và sau đó vấp ngã khi họ cố gắng mở rộng nó
2. Kiểm tra: http://dave.fayr.am/posts/2012-10-4-finding-fizzbuzz.html Nó giải thích tốt về cách bạn có thể giải quyết buzz fizz bằng cách sử dụng trừu tượng thích hợp.

Chúng tôi thấy rằng phần lớn các ứng cử viên đã hoàn thành thành công câu hỏi, không hỏi bất cứ điều gì họ chỉ làm giống như họ đã làm FizzBuzz.

Tôi đã thấy các quy trình phỏng vấn khuyến khích các lập trình viên nghĩ lớn và đặt câu hỏi để xem quá trình suy nghĩ của họ. Tôi thích quá trình này tốt hơn.

Tôi đã đọc qua fizzbuzz v2.0 này và tôi sẽ hỏi về yêu cầu số 3 và số 5 ở đó. Tôi không biết về người khác nhưng tôi thấy trong kỹ thuật tôi không muốn có bất kỳ sự mơ hồ nào nên tôi đặt câu hỏi. Bởi vì sau này xuống dòng (được mã hóa và tất cả), tôi không muốn tìm hiểu rằng tôi phải đưa ra một giả định và nó đã sai.

Có lẽ cách dễ nhất để tránh sự mơ hồ là hiển thị một số ví dụ:

"A" trả về "Fizz" "aAbA" trả về "Fizz" "B" trả về "Buzz" "aBbB" trả về "Buzz" "AB" trả về "FizzBuzz" "ABaabb" trả về "BuzzBuzz" "" trả về "FizzFizz" "ab "trả lại" FizzFizz "

Thay vì đưa ra một ứng cử viên yêu cầu mâu thuẫn / không rõ ràng, chỉ cần hỏi họ cách họ xử lý các tình huống đó. Nếu không, bạn đang làm cho mình trông không đủ năng lực hoặc tệ hơn là đặt những người có thẩm quyền vào chùm cân bằng phản bội của "làm thế nào để tôi có được câu trả lời tôi cần mà không ngụ ý rằng câu hỏi phỏng vấn này hoặc người hỏi nó là ngu ngốc?"

Dù bằng cách nào, nó gây khó chịu vì tất cả đều thoát ra. Phỏng vấn là một quá trình phù hợp và theo đó, ý tôi là đường 2 chiều. Các câu hỏi trực tiếp và sự rõ ràng của ý định quan trọng hơn rất nhiều so với việc đưa ứng viên vào nồi áp suất, IMO. FizzBuzz là một ví dụ điển hình cho câu hỏi mã hóa vì nó ngắn và ngọt ngào. Đừng sử dụng lại trực tiếp. Viết những câu hỏi đơn giản như nó theo mô hình đó.

Nhưng đối với FFS, đừng có thông minh về nó và ẩn bài kiểm tra thực sự đằng sau bài kiểm tra khác. Chỉ cần hỏi mọi người làm thế nào họ xử lý vấn đề chết tiệt. Một nhà phát triển có kinh nghiệm sẽ liên tục xử lý các yêu cầu mơ hồ và sẽ vui mừng cho bạn biết chiến lược của họ. Bạn thậm chí có thể học được điều gì đó.

Và đừng cho rằng mọi người đều muốn sử dụng bảng trắng hoặc thời gian viết tay thoải mái. Một số người trong chúng tôi đã gõ từ khi chúng tôi 12 tuổi (rất cảm ơn Space Quest). Tôi thậm chí không thể nghĩ thẳng với một cây bút hoặc bút đánh dấu trong tay. Đó là 20-freaking-13, những gì với bảng trắng đã có? Khi mọi người đưa cho tôi một cây bút và tờ giấy và yêu cầu tôi làm một bài kiểm tra mã, thật khó để nhịn cười.

Tôi nghĩ rằng đó là một câu hỏi phỏng vấn tốt đẹp. Các yêu cầu không rõ ràng, giống như chúng thường có trong thực tế. Bạn kiểm tra xem ứng viên có đủ thông minh để nhận ra điều này (ngay cả khi bị căng thẳng) hay không, rằng anh ấy / cô ấy không ngại đặt câu hỏi mà họ thấy cần thiết và có thể đưa các yêu cầu vào một cấu trúc hợp lý. Và nó nói lên một chút về khả năng lập trình của họ, mặc dù bạn cũng nên đặt ra một số vấn đề phức tạp hơn chứa đệ quy và con trỏ, vì vấn đề này quá dễ dàng.

Tuy nhiên, tôi lo lắng một chút về những ứng viên "thành công" không đặt câu hỏi. Tôi sẽ cố gắng tìm hiểu xem họ có nhận ra bạn có thể áp dụng tối đa 4 quy tắc trong một số trường hợp hay không và không có gì trong câu hỏi sẽ giải quyết sự mơ hồ đó, và yêu cầu họ giải thích cách họ giải quyết vấn đề đó. Có lẽ câu hỏi của bạn không đủ mơ hồ để buộc họ phải hỏi, hoặc có lẽ bạn nên yêu cầu họ suy nghĩ nhiều.

BTW: Tôi thấy lạ khi bạn nói về một "giải pháp chính xác". Nếu bạn đặt câu hỏi như vậy, việc in "Fizz", "Buzz", "BuzzBuzz" hoặc "FizzBuzz" là hợp pháp nếu bạn nhận được "AB". Vì vậy, IMHO bất kỳ giải pháp không có câu hỏi được hỏi là hoàn toàn sai.