Невже "Кодування білою дошкою" недоцільно під час інтерв'ю? [зачинено]

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

Ми розділили наше технічне інтерв'ю на 4 частини. Напишіть код, прочитайте та проаналізуйте код, сесію дизайну та код на дошці.

Остання частина, яку ми просимо респондентів, - це написати на дошці невеликий фрагмент коду (4-5 рядків) і пояснити, як вони проходять його. Дозвольте мені зрозуміти, мета - не виловлювати людей. Ми не шукаємо ідеального синтаксису. Пекло це може бути навіть псевдо-код. але справа в тому, щоб дати їм дуже просту проблему і подивитися, чи може їхній мозок повідомити нам рішення. Під простими проблемами я маю на увазі "Зворотний рядок", "FizzBuzz" тощо.

Зауважте, що ми завжди спочатку просимо явної мови. Ми - .NET C # будинок. ми говорили лише про "псевдокод", коли хтось заблокував / насправді бореться з кодом.

Моє запитання: "Чи недоцільно / нерозумно очікувати, що програміст під час інтерв'ю напише фрагмент коду на дошці?"

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

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

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

Моє запитання "Чи неприйнятно / нерозумно очікувати, що програміст під час інтерв'ю напише фрагмент коду на дошці?"

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

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

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

Тож у такій ситуації навіть найкращі можуть закінчитися збоями.

Останню частину, яку ми просимо опитаних, - це написати невеликий фрагмент коду (4-5 рядків) на дошці та пояснити, як вони проходять через нього

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

Якби я був ти, я би робив це останньою частиною ...

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

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

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

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

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

• Хороший код не пишеться, він переписується. Біла дошка майже непорушна, оскільки важко змінити, як тільки ви її написали. Потрібно якомога простіше змінити свою думку, як тільки ви зрозумієте проблему краще.
• Перебування на співбесіді є стресовою ситуацією, якою вона є, немає необхідності чинити додатковий тиск на кандидата. Багато комп'ютерних людей не мають гарного почерку. Сучасні ІДЕ надають безліч інструментів, до яких ви звикли. І вміння гуглювати щось потрібне, це також є частиною робочого стилю більшості програмістів. Навіщо забирати всі ці речі і створювати штучне середовище, над яким їм ніколи не доведеться працювати, якщо ви зробите їм пропозицію?
• Нас також дуже цікавить вміння писати хороші тести, можливо навіть робити TDD. Це неможливо побачити під час кодування на дошці.

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

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

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

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

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

Дозвольте відповісти на інше питання:

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

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

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

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

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

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

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

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

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

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

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

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