"Тестування" на дошці під час інтерв'ю: законний спосіб резервного копіювання коду (дошки)? [зачинено]

Як я розумію, помилка (навіть типова помилка чи відсутність ";") у вашому дошці коду часто коштуватиме вам декілька балів інтерв'ю. Уникнення цього неминуче знову і знову зробить один код зчитування (втрачаючи час і, можливо, нейронну енергію / концентрацію) або навіть використовуючи простіший (і, таким чином, менш ефективний) алгоритм - і обидва ці способи знову "дорого коштують"!

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

Хтось намагався / бачив такий підхід? Чи ціла ідея гідна?

[це стосується звичайно і ручки з папером]

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

Ось кілька чудових способів провалити тест "Кодування на дошці":

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

(наприклад: напишіть це у Fortran, інтерпретуйте "display" або "print" як "записуйте в журнал подій", такого роду речі. Я можу дозволити це, якби ви сказали мені заздалегідь, це були ваші припущення)

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

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

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

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

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

Інші речі, які ви можете не вважати важливими на дошці, які для мене важливі:

• коли ти закінчиш, чи можу я все-таки його прочитати? Ви розмазали, прокреслили, змінили кольори, намалювали стрілки, перекреслили і взагалі залишили безлад, який зараз не можна використовувати? Або вам відомо, що дошки стираються, вказують на рядки коду в повітрі замість того, щоб обертати / стріляти ними, і залишили мені щось, про що я міг би сфотографуватись та зберегти у файлі дизайну?
• скільки ви мене запитували, як це робили? Вам подобається залишатися в спокої і не обговорювати свій код, або ви бачите код як спільну справу? Як ти відповів, коли я запитував у тебе речі, поки ти ще писав?
• ти насміхався над "легким" завданням чи непритомнів від "важкого"? Чи неодноразово вас просили показати, що ви можете кодувати? Ви легко залякуєтесь технічною проблемою або ви зарозуміли щодо своєї здатності придумати хороший алгоритм?
• ти це опрацьовуєш у голові чи згадуєш рішення, яке ти десь прочитав? Зазвичай я можу сказати про важкі проблеми.
• ви планували заздалегідь про те, з чого почали писати? Люди, які закінчуються на дошці, зазвичай починають занадто низько або пишуть занадто велико - я можу сказати, що вони не знали, що це буде 20 рядків коду і тому залишилося місце лише для 5 - вірите чи ні, ця маленька деталь відображається в більші оцінки завдань.
• ви придивились до того, як сказали, що закінчили? Я бачив, як ти вказуєш чи прослуховуєш свій шлях і тестуєш сам, перш ніж я попросив тебе Коли я запропонував тобі, або задав тобі конкретні запитання щодо цього, ти знову подивився на це чи просто пішов із пам’яті? Чи готові ви вважати, що ваш перший проект може бути не завершеним?

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

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

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

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

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

Як це буває, я все-таки влаштувався на цю роботу, але це змусило задуматися про те, що сталося. У реалістичному сценарії для подібних речей я збираюся отримати чіткі лінії, коли щось не так (це C # у Visual Studio), і річ не збирається збирати. Я ніколи не перевіряю цього в реальному житті, тому що це ніколи не відбувається (неможливо), і тому я де-налаштований бачити подібні речі. Зниклі напівколони - ще більш екстремальний приклад цього - абсолютно нереально в реальному світі, якщо ви не пишете в блокнот і не надсилаєте свій код кому-небудь іншому для складання!

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

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

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

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

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

Коли ресторан хоче найняти шеф-кухаря, власник не просить його приготувати «горщик au feu» зубочисткою та ковпачком.

Не вимагайте від розробника коду на дошці в інтерв'ю.

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

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

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

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

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