Я провалив FizzBuzz, ти б мене найняв? [зачинено]

Я розробник з рівнем CS та маю досвід роботи, який займаюся розробкою декількох мов протягом майже 3 років.

Сьогодні у мене було співбесіда, загалом це пройшло досить добре, я підготувався до більшості питань і відчув, що готовий до всього. Наприкінці інтерв'ю вони поставили мені ОДНЕ програмне запитання ... така проблема, як FizzBuzz (без друку числової частини). Я вважаю, що я допустив занадто багато помилок і, таким чином, "провалив" це. Чи втрачена вся надія для мене?

Ось мій код:

  void FizzBuzz()
  {
    for(int i = 0; i <= 100; i++)
    {
      bool isThree = i % 3;
      bool isFive = i % 5;

     if (isThree)
     {
         print "Fizz\n";
     }
     else if(isFive)
     {
         print "Buzz\n";
     }
     else
     {
         print "FizzBuzz\n";
     }
  }
 }

Як ви бачите, я переплутав булі, які повинні мати синтаксис i% 3 == 0; Якщо я добре пам’ятаю це питання, я також ставлю інше, а не інший з isThree && isFive. Я був досить підкреслений, але це не привід для пропуску простої проблеми.

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

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

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

Так

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

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

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

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

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

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

Ці люди ТОЧНО того, що я хочу відмити за допомогою цієї вправи.

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

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

Мене бентежить те, що інтерв'юер не питав вас про цей код. Хороший інтерв'ю бачив достатньо власного коду, щоб знати, що люди роблять помилки - особливо коли поспішають. Зазвичай вони кажуть: "Тепер ви бачите щось не так з цим кодом?" "Ні? Ну давайте перевіримо". Ви придумуєте кілька наборів результатів, а потім запускаєте їх через функцію. Тоді ви кажете: "О, лайно, це не вийшло". "Гаразд, як би ви це виправили ..." тощо. Якщо ви пережили цей діалог, він насправді вражає і демонструє здатність критично мислити, придумувати тестові випадки та налагоджувати власний код.

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

Крім того, це може вас здивувати, але ви змагаєтесь з багатьма людьми, які навіть не можуть почати працювати на fizzbuzz. Ми схильні вважати, що всі інші пересувають дерева b + уві сні .... але насправді вони навіть не можуть з'ясувати кратні 3 та 5 та використовувати оператор модуля. Ви можете бути приємно здивовані тим, наскільки краще ви зробили, ніж інші кандидати.

Моя порада, просто вичешіть її. Нещодавно я брав інтерв'ю у великих програмних компаніях (Microsoft, Amazon тощо), і мені вперше вдалося пройти такий ретельний процес співбесіди. Я змайстрував себе дурнем під час інтерв'ю в Microsoft здебільшого через нерви, але також я просто не знав, чого чекати або що саме вони шукали. Я прибив найкоротшу проблему шляху лише для того, щоб підірвати деякі справді прості проблеми. Я вискочив значення з неправильного кінця стека, забув у int atoi(char* value)реалізації щоint val = value[i] - '0';дав би мені ціле значення символу та кілька інших дурних помилок. Я був задоволений здебільшого інтерв'ю, але все ж зрозумів, чому не отримав пропозиції. Мені довелося усвідомити, що це не стільки відображення моїх здібностей, скільки показник того, що мені просто потрібно продовжувати намагатися, поки мені не вдалося освоїти нерви. Врешті-решт я прибив деякі інтерв’ю із набагато важчими питаннями і висадив свою роботу мрії. Це насправді - для більшості людей, які насправді знають, що вони роблять, - лише питання з'ясувати, чого хочуть інтерв'юери, бути впевненими в собі і дати їм це. Проходить певний час.

Я мав би сказати "ні", але не з тієї причини, яку ви назвали, а з тим, що ви поставили розділ FizzBuzz останнім. З тим, як працює ваш код, він ніколи не надрукує FizzBuzz, коли ви цього очікуєте. Як зауважив Лі, він надрукує його для кожного значення, яке не ділиться на 3 або 5.

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

Ні. Сенс FizzBuzz полягає в тому, щоб зрозуміти, чи вмієте ви відпрацьовувати базову умовну логіку, яка охоплює всі випадки. Всупереч думкам деяких людей, FizzBuzz не про оператор модуля, знаючи потрійні операційні або булеві операнди. Це звичайна вправа в умовних умовах, і ви її провалили.

Проблема побудована таким чином, що весь «елегантний» вигляд коду не може охопити принаймні один випадок.

Прийнятні відповіді:

if div3 print fizz
if div5 print buzz
if !div3 && !div5 print x


if div3 {
    print fizz;
    if div5 {
        print buzz;
    }
} else {
    if div5 {
        print buzz;
    } else {
        print x;
    }
}

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

Я детальніше розбираюся в "тестуванні" дошки під час інтерв'ю: законний спосіб створити резервну копію коду (дошки)?

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

Якби я оцінював це, я б шукав наступні речі:

1. Чи намагається кандидат отримати чітке розуміння вимог перед тим, як перейти до впровадження? Кандидат намагається вирішити мою проблему чи використати інструменти для домашніх улюбленців у своїй програмі інструментів програмування? Як кандидат іде на вирішення проблем?
2. Чи володіє кандидатом принаймні однією мовою програмування?
3. Чи розуміє у кандидата булева логіка?
4. Що кандидат робить для забезпечення якості своїх рішень?
5. Як кандидат відповідає на відгуки про свій код?

-

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

Я б наділив вас частковим кредитом №2 та №3. Ви знали використовувати оператор модуля і мали структуру робочого рішення, але пропустили частини обох.

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

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

-

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

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

2. Задайте питання щодо проблеми, щоб підтвердити свої припущення.

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

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

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

Це може бути одним із елементів у рішенні прийняти на роботу вас чи ні, але для мене це, безумовно, не повинно бути єдиним.

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