Чи мають технічні інтерв'ю суб’єктивні? [зачинено]

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

В інтерв'ю нещодавно я сказав щось про використання алгоритму дерева AVL для вирішення конкретної проблеми, про яку було задано. Інтерв'юєр відповів: "Що таке дерево AVL?". Ще один приклад - все навколо синтаксису; Я стикався з цим в основному в інтерв'ю, де потрібен код Ruby, оскільки існує багато способів втілити рішення певної проблеми. Дуже поширеними є проблеми навколо об'єктно-орієнтованих конструкцій.

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

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

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

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

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

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

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

Я знайшов нещодавно, коли я щось сказав про використання алгоритму дерева AVL для вирішення конкретної задачі. Інтерв'юер запитав мене назад: "Що таке дерево AVL?".

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

Але взагалі: так, технічні інтерв'ю завжди суб'єктивні. І вони повинні бути. Якщо ви збираєтесь щодня проводити з людиною 8 годин + щодня, не було б розумним вибрати когось, хто зуміє звести вас з розуму під час 60-хвилинного інтерв'ю.

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

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

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

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

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

Боюся, що суб'єктивну частину не можна буде зняти, а лише зменшити. Я часто маю технічні інтерв'ю, де інтерв'юер "забруднює" інтерв'ю своїми суб'єктивними ідеями.

Один з простих прикладів, як ви згадуєте, - це те, що інтерв'юер хоче відповіді дуже близької до власної відповіді. Інший приклад - коли інтерв'юер більше зацікавлений перевірити, він знає більше, ніж кандидат. І ще один простий - коли інтерв'юер хоче, щоб кандидат знав конкретне місце меню для операції програмування IDE (Visual Studio, Eclipse, NetBeans).

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

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

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

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

Ось як я це роблю:

• Спочатку я прошу кандидата вирішити реалістичну проблему. Зазвичай це проблема, яку я легко вирішую; зазвичай у набагато менше, ніж відведений час.

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

Ось що я шукаю.

• Тільки тому, що я знаю, що добре вирішити проблему, це не означає, що я шукаю це рішення. Будь-яке дійсне рішення в межах початкових обмежень є прийнятним. Мене цікавить, як вони планували своє рішення, як використовували надані інструменти. Мене цікавить, які недоліки вони здатні виявити у власних рішеннях.

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

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

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

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

Ось як я знаю, що кандидат є поганим вибором:

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

Чи вважаєте ви, що, як співбесідник, ваше прийняття на роботу певною мірою не є суб'єктивним? Рекрутинг - це двосторонній процес.

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

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

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

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

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

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

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

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