Як проводити співбесіду технічного спеціаліста


Якась не здорова п'янка» пішла останнім часом на хабре про співбесіди. Люди, досить вже, немає нічого страшного і особливого в співбесідах, я вже кілька років проводжу їх з ІТ-шниками, і в 95% випадків це адекватні і приємні люди. Тому хочу поділитися з вами «дзеном» про те, як краще проводити саме технічне співбесіду, та й взагалі оцінювати навички тех. спеціалістів, так як питання оцінки компетентності технічного фахівця може бути досить складним, особливо якщо ви не хочете проводити співбесіду на 3 години. З даною моделлю ви цілком можете укласти тех. співбесіду в 40-50 хвилин (а то й швидше) і бути впевненим в рішенні на 80-90%. Якщо про оцінку емоційного інтелекту, базової мотивації і просто рівня адекватності, інформації досить багато, то ось про те, як ефективно оцінювати технічні навички фахівця, найчастіше, «хто в ліс, хто по дрова». Дана стаття може бути також корисна і тим, хто просто хоче ефективно рости як фахівець, бо саме їх знання і розглядаються.

Як це буває
У більшості випадків для проведення оцінки запрошують іншого фахівця з високим ступенем технічної компетенції, який, як правило, нічого не розуміє в кадрових питаннях і методології збору інформації про особистість людини, і просто починається лобової допит «хто більше знає». Деякі интервьюверы просто мають чекліст питань. Також багато використовують практику тестового завдання, яке потрібно виконати до призначення очного співбесіди. Загалом, хто як може, той так і розв'язує задачу.

В цілому, такий підхід буває ефективний, але він має ряд недоліків:
1. Існує ймовірність, що в собеседующий технічний фахівець може сприйняти невідповідність досвіду здобувача його власним, як відсутність досвіду взагалі. Наприклад, можуть бути задані досить вузько-практичні питання, з якими претендент не стикався на практиці, що може бути витлумачено як «Так як же можна таке не знати, це ж так просто». А спеціаліст з кадрів, ніколи не зможе розпізнати в силу специфіки контексту.
2. Навіть якщо будуть задані відкриті питання виду «А які завдання вам доводилося вирішувати?», знову ж таки, невідповідність досвіду може бути витлумачено як «Він нам не підходить, тому що він не робив те, чим ми займаємося вже кілька років».
3. Окремі технічні фахівці, особливо вже з досить великим досвідом, мало визнають той факт, що незнання конкретних інструментів не є найчастіше великою перешкодою. Наприклад, якщо людина не працювала з GIT, але добре знає CVS, це значно скорочує поріг входу у володіння інструментом.
4. Також може мати місце проблема, коли здобувач володіє великим практичним досвідом і добре відповідає на питання щодо конкретних рішень, але коли його беруть на роботу, раптово, з'ясовується що він допускає досить типові помилки в областях, з якими він до цього не працював. Про таких людей складається враження, що вони «туплять на рівному місці» або «активно копіпастять код» зі своїх попередніх проектів.
5. Деколи попадається фахівець, який справляє враження новачка і його резюме показує малий практичний досвід, але важливо зрозуміти «вистрілить». Тому що якщо вистрілить, ви можете малими вкладеннями отримати хорошу «зірку» в команду. І не зрозуміло як це розпізнати максимально точно.

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

Класифікація знань
Для початку потрібно визначитися з класифікацією знань. Для цього їх треба розбити на 3 види:
1. Фундаментальні – це базові знання в конкретній області. Наприклад, це може бути питання «Які основні види запитів в SQL ви знаєте?».
2. Прикладні – це навичка вирішення конкретних завдань. Наприклад, це можуть бути завдання на правильне написання SQL-запитів для конкретних прикладів.
3. Інструментальні – це знання про те, як застосовувати конкретні інструменти. Наприклад, у чому відмінність між innodb і myisam сховищами?

Фундаментальні знання необхідні для того, щоб на їх основі розуміти як краще вирішувати практичні завдання. Практичні завдання формують прикладні знання, тобто розуміння того, як і що краще робити. З розумінням того, що окремі завдання краще вирішувати за допомогою конкретних інструментів, розвиваються та інструментальні знання. Часто, людина починає з якоїсь невеликої практики, потім вивчає «чому це працює саме так», потім намагається зробити щось схоже, і потім вже відточує свою майстерність за допомогою інструментів.
Наприклад, точно також людина розвиває навик володіння мовою: спершу просто намагається повторити за батьками окремі слова; потім вчить алфавіт; потім пише твори, статті або ділові листи; і іноді використовує для цього довідники і словники.

Коли щось пішло не так
Так як «академічну освіту» в області ІТ все ще досить слабо, більшість фахівців багато в чому є самоучками. Це створює певні відхилення, які добре можна зрозуміти на даній моделі якщо гіпертрофувати одну з областей знань. Наведу класичні портрети кандидатів та їх пояснення:
1. Всезнайко – має значний обсяг фундаментальних знань, наприклад придбаних в рамках будь-яких курсів і читання книг/статей, однак, практичних навичок їх застосування не має, що його ніяк не бентежить. Навіть якщо ви почнете його питати якісь практичні завдання, ви завжди почуєте масу знань про те, як це насправді має працювати, як влаштовані окремі частини, але зібрати всі разом для вирішення завдання, без ваших підказок, такого кандидата буде досить складно. Досить часта ситуація якщо питати про кандидата мало використовувані патерни ООП: почуєте опис патерну, коли його застосовують на якому-небудь академічному прикладі, але вбудовування в живу завдання буде йти «зі скрипом».
2. Stackoverflow-розробник – звичайно, такі розробники досить активно розповідають про свій досвід, про те, які завдання і як їм вдавалося вирішувати, але при спробі відповісти на питання «як зробити...?» з невідомою їм практичної області, ви почуєте або спробу «притягнути за вуха» інше рішення, або ж відповідь в стилі «Так це гуглится за 5 хвилин, я вже таке десь бачив». Подібні розробники часто намагаються притягти якісь готові рішення, які вони вже робили, аргументуючи це як «Навіщо робити 2 рази?», або ж просто копіпастять код з інтернету та інших проектів. При питаннях «А чому це працює саме так?» або «А як це можна зробити по-іншому?» часто можуть губитися і намагатися перевести тему.
3. Tools&Frameworks-розробник. Є старий анекдот: «Як почати робити сайт в 1995 році? Відкрити блокнот і почати писати код. Як почати робити сайт в 2015 році? Завантажити та встановити composer, framework, cms-extension, bootstrap, jquery, bower, less, поставити IDE, почати писати код». Ось приблизно теж саме для такого роду фахівців. Велика частина прикладного досвіду таких фахівців пов'язана виключено з конкретним інструментом. Таке поняття як «bitrix головного мозку» цілком конкретно характеризує цей випадок. Для таких кандидатів дуже складно даються завдання з «нативному» кодом, тому що без інструменту для них це практично неможливе завдання.
Ці приклади наведені для випадків, коли одна з областей знань займає провідну позицію, а так як відчуття «переваги» в цій області зароджує почуття власного «величі», то фахівець намагається втриматися за неї усіма можливостями («кожен хоче бути крутим»). Наприклад, Stackoverflow-розробник, при спробі з'ясування фундаментальних знань, до останнього буде аргументувати до того, що «так мені це і не потрібно знати, я таке вже сто разів робив і все працювало».

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

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

Наприклад: Що таке складові b-tree індекси і як вони працюють? А можете навести приклад, коли можуть знадобитися такі індекси або коли навпаки вони будуть недоречні? А як зрозуміти, що ці індекси працюють ефективно і що взагалі можна для цього використовувати?

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

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

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

Часто можна зустріти тестові завдання, які вузько сфокусовані тільки на фундаментальних питаннях, начебто мовних конструкцій, типових помилок при використанні «не інтуїтивно зрозумілого поведінки», питань про патерни ООП і т. п. Як ви вже могли зрозуміти з наведеної вище моделі, так ви не визначите «теоретиків», і до того ж фундаментальні знання чудово гуглятся. Так що ефективність таких тестів відносно мала.

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

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

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

Допитливість розуму. Наскільки кандидат намагається вирішити завдання, якщо не знає рішення «з ходу». Шукає альтернативні шляхи, аналізує підказки, запитує і аналізує запропоноване рішення. Слабкі кандидати «пропускають повз» все, що не змогли зрозуміти.
Здорова самовпевненість. Наскільки кандидат допускає, що може чогось не знати. В силу виховання, іноді, люди мають комплекси щодо власних знань («краснодипломники» тощо). Іноді такі люди різко категоричній формі видають рішення і не визнають альтернативних думок, якщо вони говорять про відсутність якихось знань у кандидата.
Прагнення до саморозвитку. Найкращі кандидати — це які прагнуть розвиватися як спеціалісти, або ж прагнуть «зробити світ кращим» через створення якоїсь користі. Слабкі кандидати вважають, що вони вже «у стелі знань» і просто хочуть заробляти на цьому якомога більше. Також бувають і кандидати, які вважають що їх повинен розвивати роботодавець, а не вони самі себе, тому як саме роботодавець ставить завдання.

Стратегія інтерв'ювання
Попередньо, до співбесіди, складіть список ключових областей, в яких вам потрібен досвід від фахівця. Добре, якщо їх буде не менше 10. Наприклад: PHP + патерни ООП; SQL + оптимізація запитів; архітектура високонавантажених проектів; робота з кешом і т. п.
У кожній з ключових областей складіть мінімум по 5 запитань для кожного виду знань, разом мінімум по 15 запитань на кожну область. Це краще зробити для того, щоб не придумувати питання на ходу. Бажано, щоб такі питання забезпечували між собою вертикальну зв'язаність.

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

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

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

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

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

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

висновки
Нещодавно я вирішив зібрати свої замітки з питань на співбесіди для PHP-розробників і викласти їх у відкритий доступ (проект «на коліні», так що вибачайте). Там, звичайно, не всі, але вистачить для того, щоб зібрати думки докупи і налаштуватися на проведення співбесіди. Ви можете подивитися запитання за посиланням:
pagerton.com/hr/question/all
Якщо будуть позитивні відгуки, то буду розвивати проект по мірі можливості, хотілося туди ще скинути посилання по хорошим курсів для розробників, так що буду вдячний за зворотній зв'язок.
Сподіваюся, ця модель зможе бути корисна і вам. Не тільки як собеседующим, але і як собеседуемым, бо як розуміння своїх сильних і слабких сторін допоможе вам ефективніше розвиватися.
Бажаю вам бути кращими, і працювати з кращими.

P. S.: Першоджерело я. Знання, досвід і модель — мої. Посилання «скинь оригінал» і «де пруфы, Біллі», не просити: )
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.