Скільки допомоги я повинен надати під час технічних співбесід? [зачинено]

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

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

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

Коли я був у подібній позиції, я сказав би респонденту: "Притворіться, що я Google. Якщо вам потрібно щось шукати, просто скажіть це".

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

З іншого боку, я не збирався говорити їм, що їм потрібна ця формула.

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

У вас є два підходи, які працюють як для вирішення проблем, так і для коротких технічних питань:

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

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

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

Приклад:

- Чи можете ви сказати мені, як ви створюєте властивості лише для читання в C #, тобто властивості зі значенням, яке може бути ініціалізовано лише в конструкторі і не може бути змінено пізніше?
- Звичайно. Я просто використовую ключове слово readonly.
- Ти впевнений? Чи можете ви пояснити мені різницю між властивістю та полем?
- Гм. Власність ... Ви бачите ... дістаньте і встановіть ...
- Гаразд. Таким чином, поле - це змінна, оголошена всередині класу або структури та дійсна в межах класу / структури, в той час як властивість схожа на поле, але також забезпечує механізм зчитування, запису чи обчислення значення. А тепер що readonly? Чи використовується з властивостями?
- Я вважаю, що він використовується лише для полів ...
- Правильно. То як щодо властивостей?
- Їх не можна читати лише.
- Ти впевнений? А як щодо властивостей, які мають тільки геттери?
- Вони читаються лише.
- Чи означає це, що їх значення завжди залишатиметься однаковим?
- Так.
- Ні, не дуже. Те, що у вас є властивість із getter, не означає, що його значення не змінюється протягом тривалості використання екземпляра класу. Якщо геттер посилається на поле, яке збільшується щоразу, коли ви отримуєте доступ до ресурсу, повернене значення буде постійно зростати.
- Правильно.
- Тому? Чи маєте ви уявлення про спосіб реалізувати властивість зі значенням, яке ніколи не змінюється?
- Ні.
- Ну, ви можете скористатись полем для повторного спостереження. Чи знаєте ви, що таке резервне поле?
[...]

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

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

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

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

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

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

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

Але врахуйте це все, приймаючи остаточне рішення про фактичний рівень компетентності заявника.

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

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

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

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

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

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

Іноді надання minor hintsпід час усного інтерв'ю допомагає зрозуміти, наскільки добре кандидат розуміє тему (теми). Однак повинні бути no hintsстандартні тести, які кожен кандидат повинен пройти.

В основному, two main thingsви можете дізнатися про потенційного кандидата:

а) Особисті характеристики - чи добре він вписується у вашу компанію чи команду

б) Технічні навички - чи має він хороший технічний досвід та інтерес до підбору нових речей

Для того, щоб дізнатися про ці згадані моменти, ви повинні залучати потенційного кандидата до бесіди. Також важливо переконатися, що кандидат є comfortable during the interviewдля того, щоб максимально зрозуміти його сучасні навички (як м'які, так і технічні), а також його потенціал для виконання роботи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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