Як реагувати на неправильні / не відповіді на запитання під час співбесіди? [зачинено]

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

• Напишіть функцію, яка повертає істину, якщо сторони трикутника (усі цілі числа) a, b і c можуть представляти правильний трикутник .
• FizzBuzz.
• Обчисліть N-й елемент Фібоначчі за допомогою рекурсії (якби вони не знали, що таке Фібоначчі , я навіть напишу їм визначення F (n) = F (n-1) + F (n-2); F (1) = 1; F (0) = 1).
• Структура реалізації Список для цілочисельної та записуючої функції, щоб змінити його.

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

Як я повинен діяти, коли вони борються з цими питаннями? Чи варто відмовитись від відповіді? Дайте підказки за підказками (я це зробив і врешті-решт вирішив проблему сам)? Або просто рухатися далі (а може просто зупинятися) з інтерв'ю?

пс. Маючи проблеми з питаннями, я не маю на увазі помилку, я маю на увазі, якщо вони навіть не можуть почати роботу. Так було і з питаннями щодо Фібоначчі та Ліста.

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

Коли ви берете інтерв'ю у стажистів, ви повинні пам’ятати, що вони, можливо, не закінчили навчання і що вони, можливо, вступили до коледжу без попереднього досвіду програмування та інформатики. Таким чином, вам потрібно розширити очікування того, що ви можете з розумом очікувати, що хтось знатиме, і до ступеня престижу своєї посади (тобто Google може відійти від очікувань, про які люди компанії не чули).

Переглядаючи запропоновані вами питання, я, швидше за все, розглядаю їх в інтерв'ю:

1) Напишіть функцію, яка повертає істину, якщо сторони трикутника (усі цілі числа) a, b і c можуть представляти правильний трикутник.

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

2) FizzBuzz

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

3) Обчисліть N-й елемент Фібоначчі за допомогою рекурсії (якби вони не знали, що таке Фібоначчі, я навіть напишу їм визначення F (n) = F (n-1) + F (n-2); F (1 ) = 1; F (0) = 1).

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

4) Створити структуру списку для цілочисельної та записаної функції, щоб змінити її.

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

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

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

• Зустрітися та вітати, проводити інтерв'ю.
• Коротке інтерв'ю з програмістами персоналу, основні питання про передумови.
• Презентація вікторини програмування.
• Перерву
• Повернення з перерви, звільнення деяких кандидатів, які не підходять.
• Розширене інтерв'ю з програмістами персоналу.
• Інтерв'ю з людськими ресурсами (якщо потрібно).
• Загорнути.

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

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

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

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

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

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

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

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

про стажування стажиста ви, можливо, будете просити дещо.

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

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

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

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

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

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

• Незначні проблеми з синтаксисом: Якщо ви очікуєте коду на певній мові, не рахуйте занадто сильно, якщо вони пропустять крапку з комою або неправильно написали один раз за допомогою якогось ідентифікатора. Більшість ІДЕ зараз це сприймають, і час від часу кожен робить помилки. Майже в кожному інтерв'ю, в якому від мене очікували щось кодувати, "псевдо-С-іш" був прийнятним до тих пір, поки алгоритм був належним чином переданий інтерв'юеру і логіка була обґрунтована.

• Незначна логічна вада: Якщо алгоритм поводитиметься так, як очікувалося в більшості, але не у всіх очікуваних сценаріях (скажімо, при кодуванні FizzBuzz, 15 приводить лише до "Fizz" або "Buzz", але не до того, як належить), то будьте "тестером одиниць" і зазначте, що алгоритм не зможе в цьому випадку, і подивіться, чи зможуть це виправити. Вони, можливо, не помітили цього конкретного випадку, або вони недостатньо зрозуміли вимоги. І те й інше - цілком зрозумілі, повсякденні випадки кодування, які слід легко подолати, просто надавши додаткову інформацію або зворотній зв'язок.

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

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

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

Тоді це буде його територія, щоб він не був божевільно нервовим. Коли ви знайдете відповідне місце, запитайте: "Гей, як ти це реалізував?". Якщо він може пояснити, це може дати вам деяке розуміння його способу мислення.

Поставте власні тести на порядок денний після цього.

Fizzbuzz - абсолютна вимога. Якщо вони не можуть кодувати Fizzbuzz, ви не повинні їх наймати.

Я, як правило, прошу кандидата на сеанс кодування перед інтерв'ю, де ми використовуємо Документи Google для вирішення проблеми програмування (як правило, Fizzbuzz + проблема вищого рівня, якщо вони можуть легко виконати Fizzbuzz).

Я зазвичай телефоную або скайпую з ними під час цього, і оскільки я спостерігаю, як вони закінчують проблему (і розмовляю з ними про те, що вони думають у певні моменти), я можу бути впевненим, що вони цього не зробили ' т просто відповідь Google.

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Намагайся бути приємним на них. З ваших запитань видно, що ви не намагаєтесь бути приємними навіть тут. Як ви думаєте, всі повинні знати цей термін "fizzbuzz"? Або ми повинні шукати в мережі, тому що ви лінувались написати це самостійно? Навпаки, я думаю, всі тут знають, що таке правильний трикутник.
2. Що таке "Список структур"? Не знаю. Я знаю "Структуру списку". Що це означає: Список для цілого числа? Список цілих чисел, які ви маєте на увазі? Я теж не знав би як почати. І будь ласка, не кажіть, що ви не англійці. Я також. І навіть я ніколи не бував у англомовній країні. Ви точно знаєте, що ціле число в множині буде цілим s . Якщо ти не намагаєшся бути зрозумілим зі своїми рівними тут, я можу уявити, як ти там робишся .
3. Будь-який грамотний програміст знає, що рядок Фібоначчі - це книжковий приклад того, що не слід робити рекурсією. Ви перевіряєте їх на здатність протидіяти вам або на вміння кодування? Зробіть свою роботу і знайдіть кращий приклад для тестування навичок використання рекурсії.
4. "Здатність працювати в стресі" для програміста означає, що він міг працювати ночами, коли це необхідно. Але якщо ви хочете мати хороших програмістів, вони б чекали, що їх начальник - дуже приємний, розуміючий та корисний хлопець. Якщо вас немає, у вас ніколи не буде хороших програмістів. Вони не альфа-щурі-самці. Якщо вони відчують будь-яку агресію, вони просто закриються в своїх оболонках і нічого не зроблять.

Отже, моя відповідь: будьте краще підготовлені самі.

PS Ви вже менеджер, тож вам справді слід стрес.