У нас був кандидат інтерв'ю вищого рівня провалити нюанс питання FizzBuzz ^{1 2} .
Я маю на увазі, справді, абсолютно, повністю, не вдалося питання - навіть не близько.
Я навіть тренував його через думати про використання циклу і що 3і 5було на самому ділі варто розглядати як окремі випадки.

Він підірвав це.

Тільки для цілей якості я дав те саме точне запитання трьом товаришам по команді; дав їм 5 хвилин; а потім повернувся, щоб зібрати свій псевдо-код. Усі вони прибивали це і раніше не бачили питання. Двоє запитали, у чому трюк ...

Під час іншої логічної вправи кандидат показав деяке розуміння деяких функцій, доступних у мові, яку він обрав (C #). Тож це не так, як ніби він ніколи не писав рядок коду. Але його логіка все-таки приголомшила.

Моє запитання - чи я повинен був дати йому відповідь на логічні питання.

Він знав, що їх підірвав, і визнав це пізніше в інтерв'ю.
З іншого боку, він ніколи не просив відповіді або того, що я очікував побачити.

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

Я відчував, що я повинен був показати йому спосіб вирішення проблеми, щоб він міг хоча б навчитися досвіду. Але знову ж таки, він не питав.

Який правильний спосіб вирішити цю ситуацію?

² _{Щоб допомогти уточнити, це нюанс Fizz-Buzz, який я запитав, і це є першою проблемою Project Euler . Заміна друку Fizz | Поцікавтеся підсумовуванням чисел і у вас є те саме принципове питання.
If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Write a function that finds the sum of all the multiples of 3 or 5 below 1000.}

³ _{Це питання привернуло більше уваги, ніж я очікував, і я ціную всі відповіді. Деякі з пізніших відповідей дійсно потрапили до основи мого питання, тому я дозволю спільноті переглянути та проголосувати перед тим, як призначити відповідь "на".}

⁴ _{Я вибрав відповідь "" на основі голосів громади в той момент часу. І я вважаю, що відповідь Яніса є доречною для інтерв'ю з новими розробниками. Я думаю, що колективна відповідь, зосереджена на відсутності прохання про відповідь, також є місцем.}

Більшість моїх інтерв'ю були зі студентами, які шукали стажування, і найчастіше вони викручували прості (?) Вправи. Мені хотілося легкого і доброзичливого способу донести свої помилки, і те, що я придумав, було досить простим: я розв’язував вправи самостійно і показував їм свої рішення після того, як вони закінчили їх.

У мене було досить багато надзвичайно цікавих та показових дискусій з кандидатами, які розпочалися зі порівняння наших різних підходів до вирішення однієї і тієї ж проблеми. Через деякий час я навіть передбачив деякі помилки, лише перевіривши, яку школу відвідував кандидат (деякі «професори» - це… дебіли). І, ну, в кількох випадках, коли кандидат не міг знайти жодного рішення, я вже дав їм наступний раз.

Надання відповіді

Я збирався сказати, що якщо кандидат недостатньо зацікавлений, щоб запитати, я б не витрачав подих, але відповідь @Yannis_Rizos набагато краща.

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

Люди, які не можуть кодувати FizzBuzz Classic

Я думаю, що великим моментом є усвідомлення оператора%. Ви сподіваєтесь, що хтось може подумати, щоб порівняти, (myInt / 3) == (myDouble / 3.0)але, можливо, зі стресом інтерв'ю ... Все-таки FizzBuzz Classic змушує підходити з грубою силою, ставлячи його до категорії найпростіших проблем з алгоритмом для вирішення. Як підказка, чи намагалися ви попросити людей просто кодувати "Fizz" для отримання половинного кредиту та, можливо, пізніше додати "Buzz" як доповнення?

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

Питання для інтерв'ю взагалі

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

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

Сума (син) FizzBuzz

Ваше запитання про інтерв'ю не рівнозначне FizzBuzz:

Якщо перерахувати всі натуральні числа нижче 10, кратні 3 або 5, отримаємо 3, 5, 6 і 9. Сума цих кратних дорівнює 23. Напишіть функцію, яка знаходить суму всіх кратних 3 або 5 нижче 1000.

Якщо FizzBuzz Classic змушує вас пройти n ітерацій (для друку кожного номера або Fizz / Buzz), вашу проблему можна зробити в n / 5 + n / 3 + n / 15 ітерацій, а то і без ітерацій - прямо можливий підрахунок балів. Наступна програма порівнює ці три методи:

public static void main(String[] args) {
  long n = Long.valueOf(args[0]).longValue();
  long sum = 0;
  long ms = System.currentTimeMillis();
  // Brute force method  Performance: cn
  for (long i = 1; i <= n; i++) {
    if ((i % 3) == 0) { sum += i;
    } else if ((i % 5) == 0) { sum += i; }
  }
  System.out.print("Brute force sum:    " + sum);
  System.out.println(" time: " + (System.currentTimeMillis() - ms));
  ms = System.currentTimeMillis();

  // Second solution: iterate through only numbers we are
  // interested in.  Performance: c * (n/3 + n/5 + n/15)
  // We counted multiples of 15 twice, so subtract one of them
  sum = countSum(n, 3) + countSum(n, 5) - countSum(n, 15);
  System.out.print("Only multiples sum: " + sum);
  System.out.println(" time: " + (System.currentTimeMillis() - ms));
  ms = System.currentTimeMillis();

  // Third solution: Use high school algebra.  Performance: c
  sum = sumSeries(n, 3) + sumSeries(n, 5) - sumSeries(n, 15);
  System.out.print("Sum of series:      " + sum);
  System.out.println(" time: " + (System.currentTimeMillis() - ms));
}

// Iteravely sum all multiples of skip
private static long countSum(long n, long skip) {
  long skipTotal = skip;
  long grandTotal = 0;
  while (skipTotal <= n) {
    grandTotal += skipTotal; skipTotal += skip;
  }
  return grandTotal;
}

// Thanks to @Caleb for pointing this out!  High school algebra
// tells us that the sum of a series is: (n * (a1 + an)) / 2
// where a1 is the first term and an is the nth term.  E.g. The
// sum of a series of 3 is: (n/3 * (3 + n - (n % 3))) / 2
// Since we are thinking about performance here, we'll shift
// right one instead of dividing by 2 for style points.  ;-D
private static long sumSeries(long n, long skip) {
  return (n/skip * (skip + n - (n % skip))) >> 1;
}

Вихід (сума FizzBuzz <1000):

$JDK_HOME/bin/java FizzBuzzNot 999
Brute force sum:    233168 time: 0
Only multiples sum: 233168 time: 0
Sum of series:      233168 time: 0

З більшим n для порівняння продуктивності:

$JDK_HOME/bin/java FizzBuzzNot 1000000000
Brute force sum:    233333334166666668 time: 4744
Only multiples sum: 233333334166666668 time: 818
Sum of series:      233333334166666668 time: 0

Зверніть увагу на тих, хто проголосував це як поза темою

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

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

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

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

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

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

Якщо хтось підірвав FizzBuzz в інтерв'ю про програму Dev молодшого рівня, оскільки він не міг запам'ятати оператора модуля і просто не міг змусити його рухатися далі, але тоді вони захопилися повторно робити це, як тільки ви пояснили правильну відповідь, або принаймні розмовляти з вами правильним кодом, то це майже так само добре, як правильно відповісти на нього.

Я набрав fizzbuzz під час попереднього екрану по телефону з інтерв'юером. Це те, що, навіть якщо всі не чули, ви повинні мати змогу співучати після семестру курсової роботи, але, безумовно, після набуття статусу "старший".

Дійсно, відновлення від цього не вдасться. Це одне з тих необхідних неприємностей, що вам потрібно вийти з дороги на всякий випадок.

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

Я навіть тренував його до роздумів про використання циклу, і що 3 і 5 справді варто розглянути як особливі випадки.

Було б цікаво дізнатися, що ви вважаєте "правильною" відповіддю на ваше питання FizzBuzz-ish. Звідки я сиджу, хороший (на С), написаний на лист вашого запитання:

int f(void) {
    // sum the multiples of 3 and of 5 and subtract multiples of 15 so we don't count them twice
    return ((1000/3)/2)*(999+3) + ((1000/5)/2)*(995+5) - ((1000/15)/2)*(990+15);
}

Кращим може бути:

Чому чорт ти би написав програму, щоб це робити, коли ти можеш обчислити її безпосередньо?

Справа в тому, що існує кілька способів зняти кота, і те, що відповідний кандидат не відразу почав писати forпетлі і modоператори, не означає, що він дурний. Якщо ви хочете знати, що знає кандидат, обговоріть проблему - дізнайтеся, що він думає. Якщо він застряг або заплутався, з’ясуйте, де і чому. Він може привести вас до підходу, який ви ніколи не розглядали.

Моє запитання - чи я повинен був дати йому відповідь на логічні питання.

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

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

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

Тож якщо ви хочете дати співбесіднику рішення після факту, ви робите це виключно для себе. Загалом, я б скоріше скористався цим часом, щоб дозволити респонденту спробувати ще одну проблему. Але "старший" програміст, який не може відповісти на FizzBuzz, ймовірно, не в списку. Якщо ви вирішили дати рішення, переконайтеся, що ви не обманюєте себе на думці, що інтерв'ю пройшло краще, ніж це було (якщо ви думаєте, що "він не міг вирішити проблему, але коли я пояснив це, він це добре зрозумів", тоді ти на небезпечному шляху).

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

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

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

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

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

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

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

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

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

Більш актуальне питання - коли ви можете назвати себе старшим розробником? Це залежить від організацій та країн. Наприклад, компанія, з якою я працював, розглядала програмних інженерів з 5-річним досвідом роботи як літніх людей. Акцент на якості досвіду не робився, лише довжина.

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

Пару тижнів тому було задано питання "Коли ти повинен називати себе старшим розробником" . Я також написав допис у блозі на цю тему.