Ефективність FizzBuzz і далі [закрито]

В рамках інтерв'ю ми спочатку просимо кандидатів зробити "FizzBuzz", а зараз відсоток кандидатів, які можуть правильно відповісти на FizzBuzz, різко збільшився - це може бути пов'язано з його популярністю в Інтернеті.

Приблизно рік тому, як друге питання, ми почали задавати питання, дуже схожі на оригінальний FizzBuzz. Питання було розроблено таким же простим, як оригінальний FizzBuzz, а також для оцінки конкретної здатності кандидата, зокрема здатності замовляти та визначати пріоритет у змістовному та логічному вигляді набір "правил бізнесу", які були надані в деяких довільний порядок. Формулювання питання спочатку здається дещо неоднозначним, що може ускладнити немовців, які володіють англійською мовою, але якщо продумка може бути правильно вирішена - Також це дає кандидату можливість задати питання для уточнення, що завжди добре .

Ми вважаємо це дуже важливим вмінням розробника як розробника, оскільки розробка програмного забезпечення, як правило, заснована на функціональних вимогах, що виводяться в певному порядку не з часом, що може ставити обмеження та умови для інших областей програмного забезпечення, не чітко вказуючи, і це завдання проникливого розробника принаймні досліджувати потенційні проблеми та конфлікти щодо впровадження.

Ми з'ясували, що трохи більше 65% кандидатів (розмір вибірки 38), які пройшли FizzBuzz, повністю провалили FizzBuzz v2.0. Зазвичай ці кандидати будуть виявлені пізніше в процесі, але це, мабуть, є гарним способом виявити їх рано.

Моє запитання полягає не в тому, застаріла чи ні FizzBuzz, а в тому, які фактори можуть сприяти такій великій кількості кандидатів, які не мають питання FizzBuzz v2.

• Це питання занадто неоднозначне?
• Чи знижує стрес для інтерв'ю здатність критично мислити до того, що вони не зможуть виконати таке тривіальне завдання?

Питання:

Напишіть процедуру на улюбленій мові програмування, яка буде приймати список рядків як вхідний, і для кожної рядок у списку буде виконано одне з наступного:

1. Друкуйте лише Fizz, якщо рядок містить літеру A
2. Друкуйте лише Buzz, якщо рядок містить букву B
3. Друкуйте лише BuzzBuzz, якщо рядок містить і A, і B
4. Друкуйте лише FizzFizz, якщо рядок не містить A і B
5. Друкуйте лише FizzBuzz, якщо рядок містить лише один A і лише один B

Деякі типові запитання, які задають кандидати:

• Чи слід це враховувати регістри?
• Чи означає "містить A і B" означає, що A має прийти перед B
• Що слід надрукувати, якщо жодна з пунктів не виконується?
• Що має відбутися, якщо можна виконати більше однієї умови?

Ми виявили, що переважна більшість кандидатів, які успішно виконали питання, взагалі нічого не запитували, вони просто робили так, як це робили FizzBuzz.

Це потенціал бути набагато кращим тестом, ніж FIZZBUZZ, але якщо у вас є якась концепція правильної відповіді, це найгірший тест у світі. Ці тести мають дуже мало значення в інтерв'ю для початку.

Якщо кандидат відповідає на це «Правильно», не задаючи запитання, у вас виникає проблема, що вибір кандидата вибере неправильний тип програміста. Він не в змозі визначити неоднозначні вимоги або не в змозі зрозуміти, що більшість людей не може написати однозначні вимоги . Не має значення, чи програма в технічному відношенні досконала в кожному аспекті, швидше за все, він такий тип хлопця, який доставить програмне забезпечення з "Мені все одно, не те, що ти хотів, це те, про що ти просив".

Частина тесту тут - це пріоритетний порядок правил. Ви не вказуєте його. Вхід "ABC" може друкувати Fizz, Buzz, BuzzBuzz або FizzBuzz - будь-яке з них є правильним

Кандидат, який я б взяв, - це той, хто отримав це (в основному) правильно, але задав багато питань і, в ідеалі, зробив багато "додавання" на дошці.

Наприклад, я досліджував би своє розуміння цих вимог, надаючи вам ряд зразків текстів і запитуючи, що ви очікуєте надрукувати, і чому. - Обговорення мого прикладу "ABC" має призвести до корисних наполягань для вас.

Так само, як і FIZZBUZZ, результат цього тесту є настільки ж хорошим, як і ваші спостереження щодо того, як результат був отриманий - результат не має значення.

Я хотів би трохи підправити це - лише щоб зробити його цікавішим - вийміть «тільки». Це висвітлено у рядку вище ("надрукувати одне з наступних"), і подивіться, скільки людей запитують про це. Якщо кандидат пропускає "єдине", а у вас є час, вкажіть це і подивіться, що станеться. Якщо він має справу з "єдиним", видаліть його з вимоги і змусьте їх змінити код.

Слово "тільки" у ваших вимогах створює протиріччя у всіх питаннях.

Таким чином, ваші запитання тестують вимоги, що збираються, перебуваючи під тиском, ви впевнені, що хочете перевірити на поєднання вмінь?

Якщо ви хочете перевірити збір вимог, я б запропонував зробити ОДНЕ з питань неоднозначним. Якщо ви хочете замінити FizzBuzz, усуньте двозначність.

Визначення пріоритетів для бізнес-правил може бути виконано лише з урахуванням конкретних доменних знань - якщо ви не включите простий контекст для того, що ви робите (можливо, вони є купонами, які слід викупити за різні цінності), розробник не має підстав приймати власне рішення.

Але вимагати від кого-небудь запитання про роз'яснення, коли це робить істотний ризик небажаного результату, можливо, не найкращий спосіб оцінити свою майстерність у визнанні меж своїх знань. Вони можуть зрозуміти, що безпечніше здогадуватися та помилятися, ніж вказувати на те, що ви некомпетентні у написанні вимог, або якщо жоден з інтерв'юерів не є розробниками, і його вважають поганим ставленням.

Ми виявили, що переважна більшість кандидатів, які успішно виконали питання, взагалі нічого не запитували, вони просто робили так, як це робили FizzBuzz.

З неоднозначністю вимог не можна правильно закінчити v2.0, не задаючи питань.

Якщо ви хочете усунути будь-яку неоднозначність, ви можете змінити вимоги на:

Напишіть процедуру на улюбленій мові програмування, яка буде приймати список рядків як вхідні дані, і для кожної рядок у списку виконайте наступне:

1. Роздрукуйте "Fizz", якщо рядок містить символ "$", а не містить "?".
2. Роздрукуйте "Buzz", якщо рядок містить символ "?" і не містить "$".
3. Роздрукуйте "FizzBuzz", якщо рядок містить рівно один "$" і рівно один "?".
4. Роздрукуйте "BuzzBuzz", якщо рядок містить рівно один "$" та більше "?".
5. Роздрукуйте "BuzzBuzz", якщо рядок містить точно одне "?" і більше одного "$".
6. Роздрукуйте "FizzFizz", якщо рядок не містить "$" і не містить "?".

Це питання занадто неоднозначне?

Так, на питання надто неоднозначне, щоб відповісти без уточнень. Однак додаткове правило, яке говорить про те, що у випадках, коли застосовується кілька правил, у вашій програмі слід вибрати саме конкретне, слід усунути неоднозначність.

Чи знижує стрес для інтерв'ю здатність критично мислити до того, що вони не зможуть виконати таке тривіальне завдання?

Це скоріше вказівка ​​кандидата, що "набиває" FizzBuzz: стрес чи ні, програма дуже проста.

Я думаю, що модифікований FizzBuzz не є порівнянним з оригінальним, оскільки його ідеальне рішення відрізняється: хоча ланцюжок if-then-elseзалишається прийнятним, я вважаю, що рішення на основі таблиці є більш підходящим для цієї проблеми:

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)
    ];
}

Розмір проблемного простору - 3x3ні 2x2, тому він відображається до таблиці набагато легше, ніж оригінальний FizzBuzz. Справді, мені важче зрозуміти рішення на основі таблиці оригінальної проблеми FizzBuzz .

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);
    }
}

Тут дві речі:

1. так, я думаю, що більшість людей просто гуляє фіз-гудом, а потім спотикаються, коли намагаються розширити його
2. Перевірте: http://dave.fayr.am/posts/2012-10-4-finding-fizzbuzz.html Це добре пояснює, як можна вирішити фіз-шум, використовуючи відповідні абстракції.

Ми виявили, що переважна більшість кандидатів, які успішно виконали питання, взагалі нічого не запитували, вони просто робили так, як це робили FizzBuzz.

Я бачив процеси інтерв'ю, які спонукають програмістів думати вголос і задавати питання, щоб побачити їх процес мислення. Мені подобається цей процес краще.

Я читав цей fizzbuzz v2.0, і я запитав про вимоги №3 та №5. Я не знаю про інших людей, але я знаходжу в техніці, я не хочу двозначності, тому я задаю питання. Оскільки пізніше внизу лінії (закодовано і все), я не хочу дізнатися, що я повинен був зробити припущення, і це було неправильно.

Мабуть, найпростіший спосіб уникнути двозначності - показати кілька прикладів:

"A" повертається "Fizz" "aAbA" повертається "Fizz" "B" повертається "Buzz" "aBbB" повертається "Buzz" "AB" повертається "FizzBuzz" "ABaabb" повертається "BuzzBuzz" "" повертається "FizzFizz" "ab "повертає" FizzFizz "

Замість того, щоб давати кандидату суперечливі / незрозумілі вимоги, просто запитайте їх, як вони впораються з цими ситуаціями. Інакше ти змушуєш себе виглядати некомпетентним або ще гірше, коли компетентних людей виставляє зрадницький промінь балансу "як я можу отримати відповіді, які мені потрібні, не маючи на увазі, що це питання інтерв'ю чи людина, яка його задає, дурна?"

У будь-якому випадку це дратує, як і всі вихідці. Інтерв'ю - це процес узгодження, і я маю на увазі двосторонні вулиці. Прямі питання та ясність намірів набагато важливіші, ніж ставити кандидата під скороварку, ІМО. FizzBuzz - хороший приклад кодування питання, оскільки він короткий і солодкий. Не використовуйте його повторно. Напишіть такі прості запитання, як це, за цією моделлю.

Але FFS не розуміє цього і ховає справжній тест за іншим тестом. Просто запитайте людей, як вони справляються з проклятою проблемою. Досвідчений розробник неодноразово розбирався з неоднозначними вимогами і з радістю розповість вам про їхні стратегії. Ви навіть можете чогось навчитися.

І не припускайте, що всі хочуть використовувати дошку або це зручний час написання рукописного тексту. Деякі з нас друкують з 12 років (завдяки спасибі Space Quest). Я навіть не можу думати прямо з пером чи маркером у руці. Це 20-диво-13, що вже з дошками? Коли люди передають мені ручку та папір і просять зробити тест на код, важко придушити сміх.

Я думаю, це приємне питання інтерв'ю. Вимоги незрозумілі, як і часто в реальності. Ви перевіряєте, чи кандидат достатньо розумний, щоб усвідомити це (навіть в умовах стресу), що він / вона не боїться ставити питання, які вважаєте за потрібне, і чи здатний він ставити вимоги до розумної структури. І це трохи розповідає про їхні можливості програмування, хоча ви також повинні поставити деякі складніші проблеми, що містять рекурсію та покажчики, оскільки ця проблема занадто проста.

Однак я трохи хвилююся, коли "успішні" кандидати не задають питань. Я б спробував дізнатись, чи зрозуміли вони, що ви можете застосовувати до 4 правил у деяких випадках, і що в питанні немає нічого, що могло б вирішити цю неоднозначність, і дозволити їм пояснити, як вони з цим боролися. Можливо, ваше запитання недостатньо неоднозначне, щоб змусити їх запитати, або, можливо, вам слід попросити їх подумати вголос.

До речі: мені дивно, що ви говорите про "правильне рішення". Якщо ви сформулюєте таке запитання, правомірно друкувати або "Fizz", "Buzz", "BuzzBuzz" або "FizzBuzz", якщо ви отримаєте "AB". Отже, IMHO будь-яке рішення без запитань є явно неправильним.