17 обязательных вопросов для технического интервью
Большинство IT рекрутеров знают, что им приходится выходить за рамки технической квалификации кандидата на работу при подборе ИТ-персонала.
Soft скиллы и инициатива, например, являются не менее важными факторами для рассмотрения. И чтобы получить такое понимание, вам нужно будет отложить резюме и придумать такие вопросы для интервью, чтобы грамотно оценить их.
1. Какие интернет-ресурсы вы используете, чтобы помочь вам делать свою работу эффективнее?
Большинство ит специалистов обращаются к таким сайтам, как StackExchange или Github, когда им нужна помощь в чем-то. Серьезные профессионалы будут иметь свой собственный выбор веб-сайтов, онлайн-сообществ, каналов социальных сетей и других ресурсов, специфичных для их интересов. Ответ на этот вопрос даст вам представление о том, насколько кандидат вовлечен в более широкий ИТ мир.
2. Как вы поддерживаете свои технологические навыки в актуальном состоянии?
Технические специалисты упорно работают, чтобы поддерживать свою базу знаний актуальной, читая блоги и форумы, посещая онлайн-курсы, присоединяясь к хакатонам и подключаясь к личным ИТ-проектам. Этот вопрос на интервью может помочь вам оценить энтузиазм кандидата к профессии, а также открыть разговор о профессиональном развитии.
3. Представьте, что я не технарь. Можете ли вы объяснить [соответствующую технологию] в простых терминах?
Он играет решающую роль практически в каждой компании, поэтому умение общаться с не техническими людьми является обязательным. Вы можете оценить коммуникативные навыки кандидатов с помощью этого вопроса. Избегают ли они непонятных аббревиатур и жаргона? Насколько хорошо могут сломать сложный процесс? Попробуйте задать несколько «тупых» последующих вопросов, чтобы получить представление о том, как кандидат будет взаимодействовать с коллегами не из ит сферы.
4. Какие сильные стороны, по вашему мнению, наиболее важны для разработчика [или другой соответствующей ИТ позиции]?
Такой вопрос может показать, как собеседник относится к этой позиции и что, по его мнению, он принесет в нее. Некоторые кандидаты могут сосредоточиться на технических способностях и ИТ сертификациях, в то время как другие могут больше говорить о решении проблем, внимании к деталям, общении и других общих навыках работы. Ищите кандидатов, которые дадут взвешенный ответ.
5. Какие три слова использовали бы ваши коллеги, чтобы описать вас?
Ответ может подсказать вам о чертах личности кандидата, которые не могут быть легко видны через резюме или традиционные вопросы интервью. Это также дает представление о том, как человек воспринимает себя и роль, на которую он претендует. Например, если ответ фокусируется на творческой стороне, но позиция очень аналитична по своей природе, работа может быть не очень подходящей.
6. Можете ли вы рассказать мне о том времени, когда все шло не так, как вы хотели на работе, например, о провалившемся проекте или о том, что вам не дали повышения по службе?
Каждый человек в какой-то момент своей карьеры сталкивается с профессиональными неудачами. То, что вы хотите знать, — это то, как люди справлялись с этими ситуациями и чему они научились. Лучшие сотрудники устойчивы, используя неудачи как трамплин к позитивным изменениям. Поэтому прислушайтесь не только к проблеме, о которой упоминает соискатель, но и к тому, что он сделал после разочарования.
7. Каковы ваши любимые и наименее любимые технологические продукты и почему?
В дополнение к изучению того, нравится ли потенциальным сотрудникам оборудование, операционная система и программное обеспечение, используемые вашей компанией, этот технический вопрос интервью поможет вам оценить энтузиазм и знания. Оживляются ли кандидаты, обсуждая преимущества и недостатки тех или иных инструментов? Восхищаются ли они качеством кода, безупречным дизайном, интуитивно понятным пользовательским интерфейсом или другим аспектом хорошей технологии?
8. Каковы преимущества и недостатки работы по Agile?
Большинство ИТ команд приняли ту или иную форму Agile — в настоящее время излюбленную методологию SDLC — что означает множество быстрых встреч и постоянный поток обратной связи от коллег / членов команды. Ответ кандидата на этот вопрос может рассказать вам не только об уровне его понимания этой методологии, но и об отношении к сотрудничеству и общению.
9. Как вы считаете, дальнейшее развитие технологий повлияет на вашу работу?
Достижения в области технологий продолжают изменять большинство ролей в ИТ. Насколько осведомлен об этом кандидат, с которым вы проводите собеседование? Знают ли они, например, что автоматизированное тестирование является основной частью DevOps, что позволяет ускорить циклы разработки и ускорить развертывание? Кандидат может рассказать об используемых им инструментах автоматизации или проблемах работы с машинным обучением и большими данными. Они также могут обсуждать проекты искусственного интеллекта, над которыми они хотят работать. Этот вопрос, хороший способ начать разговор о тенденциях и достижениях в этой области, а также даст вам представление о том, как кандидат воспринимает свою роль в долгосрочной перспективе.
10. Расскажите мне о техническом проекте, над которым вы работали в свободное время?
Вы хотите нанять ИТ специалиста, который посвящает свое личное время другим проектам. Почему? Это люди целеустремленные и любознательные, что, в свою очередь, сохраняют навыки актуальными. Спросите, как они держут мотивацию, что их интересует в проекте и какова их конечная цель. Если они могут продемонстрировать веб-сайт или приложение, которое они создали, тем лучше.
11. Какой была последняя презентация, которую вы дали?
Сегодняшние соискатели в ит не могут быть одинокими волками. Они должны обсуждать изменения с товарищами по команде, координировать свои действия с другими отделами, отстаивать платформы, которые они предпочитают, и многое другое. Хотя не все должны любить публичные выступления, ваш новый сотрудник должен уметь проводить исследования, составлять солидную презентацию и убеждать заинтересованных лиц, почему X лучше, чем Y.
12. Каковы качества успешного руководителя команды или проекта?
Всегда ищите лидеров, даже если вы не нанимаете человека на руководящую должность. Характер работы в IT означает, что людям часто приходится брать на себя ответственность за реализацию проектов, а это требует лидерских навыков, таких как организованность, позитивность, делегирование полномочий и коммуникация.
14. Чего бы вы хотели достичь в первые шесть месяцев после приема на работу?
Ответ на этот вопрос интервью зависит от роли. Разработчик, например, может надеяться разработать небольшой проект за это время, в то время как технический менеджер может захотеть проанализировать внутренние процессы. Ответ кандидата даст вам представление об общем понимании позиции. Если цели соискателя и амбиции не соответствуют описанию работы, это может быть не самая подходящая должность для него.
15. Как вы справляетесь с работой с сжатыми сроками?
ИТ команды часто сталкиваются с огромными временными ограничениями. Вам нужен кто-то, кто может работать эффективно и точно, когда находится под давлением. Задайте этот вопрос потенциальному сотруднику, и вы, по крайней мере, получите представление о том, как он справляется со стрессом и может ли он идти в ногу с темпами проектов в вашей компании. Вы также можете продолжить, спросив, пропускали ли он когда-либо сроки и, если да, то как справлялся с ситуацией.
17. Почему вы хотите работать у нас?
Люди, которые действительно хотят работать, проведут свои исследования и смогут рассказать о ценностях вашей компании, продуктах и услугах, а также о подходе к технологиям. Если они не могут сформулировать хотя бы несколько причин, по которым ваша компания будет хорошо соответствовать их навыкам и амбициям, значит, они не проявили должной осмотрительности, чтобы подготовиться к собеседованию.
Не забудьте дать кандидатам время в конце собеседования задать вам вопросы. Это не только полезно для соискателей — это также дает вам ключ к тому, что важно для них. Например, вы можете пересмотреть свой интерес к потенциальному сотруднику, если он кажется чрезмерно озабоченным начислением заработной платы и отпусков во время первого собеседования. Или вы можете быть впечатлены, когда услышите вопросы, которые демонстрируют их деловую хватку и глубокое понимание сильных и слабых сторон вашей компании. Техническое интервью со стороны рекрутера должно проходить максимально компетентно!
Ультимативный гайд по собеседованию DevOps-инженеров — что спрашивать и к чему готовиться
Я начал заниматься сетями еще в школе, а работаю за деньги больше 16 лет. Я много куда устраивался, в большие компании и маленькие, потом открыл свой бизнес и регулярно сам нанимаю людей. С годами и опытом у меня, да и у многих, вырабатывается интервьюшная интуиция.
Это когда никакого четкого алгоритма нет. Ты просто разговариваешь с человеком и что-то для себя понимаешь. Спрашиваешь, что кандидат делал на прошлой работе, цепляешься за тему — и вот вы уже просто обсуждаете инженерные темы, примерно на том же уровне, что и с коллегами. Если беседа клеится и человек нравится, то все хорошо.
Такой интуиции вряд ли научишься по книгам и текстам, она приходит сама с опытом. Вместе с ней в мышление просачиваются фразы вроде «мне не так важны конкретные знания, как общий кругозор, способность искать информацию, понимание, сработаемся ли» и все такое.
Но иногда, чтобы не терять хватку, надо все же напоминать себе, какими знаниями должен обладать инженер и какими вопросами можно максимально объективно оценить человека, которого видишь впервые в жизни.
Сперва я быстро просматриваю все резюме
Пока я перебираю отклики, обращаю внимание на ключевые слова и места работы. Всегда читаю сопроводительное письмо — много соискателей отсеивается на этом этапе. Я размещаю вакансию о поиске DevOps-инженера, а ко мне приходит отклик от python-разработчика, от golang-разработчика или от нынешнего курьера, которому «очень интересно и он хотел бы попробовать».
Мимо идут резюме, в которых указан опыт работы в госструктурах, что-то в духе «администратор первого разряда в ЦБ РФ». Все эти многословные рассказы про «администрирование информационных систем» я отсекаю сразу без раздумий. Чем официозней и канцеляритнее описание прошлой работы, тем выше шанс, что ничего в своей жизни, кроме винды и бэкапов с помощью графического интерфейса, такой соискатель не видел.
В быстром отборе резюме помогает правило: чем больше технологий я встречаю, тем лучше. Если у человека в резюме написано MySQL, Linux, Postgres, Apache и так далее — шансы есть. Человек по крайней мере слышал о технологиях и, кто знает, возможно, даже сам с ними работал. Хотя будем честны — в резюме можно написать все, что угодно.
На собеседовании первым делом проверяю базу
Когда я стану немощным стариком и меня будет стремно бить в ответ, я начну колотить палкой по спине всех, кто не знает сети! Это маст хэв для любого инженера. Мы живем в мире, где все происходит в сетях. Даже в закрытом госсекторе найдется локальный контур. И там сидит разработчик, который пишет какой-нибудь proxy-сервис или сочиняет сервис, работающий с API-шкой, и ничего не понимает в API.
Я не требую особых знаний, я не прошу настроить мне MPLS. Но что такое маска подсети, что такое IP-адрес — в 21 веке должны знать все IT-специалисты. Я понятия не имею, что у человека в голове происходит, когда он не понимает, что такое 127.0.0.1. Он сидит на локальной машине, у него запущен сервис на виртуалке. У сервиса прописан эндпоинт 127.0.0.1, коннект к базе. От незнания наш герой вхреначивает то же самое. Как результат: «у меня не коннектится к базе». Конечно, блин, не коннектится!
Если у человека есть сертификат CCNA, окей, даже если он не сдавал его, не получал физически, но готовился — мне достаточно этого факта за глаза.
Вот, например, стандартная задачка из CCNA, на понимание того, как работают сети
Есть два свича из разных сетей, между ними стоит роутер. Компьютер А хочет отправить данные в компьютер Б.
Затем я спрашиваю по всем уровням модели OSI
Слышал ли что-нибудь человек про Spanning Tree протокол? Про корневой протокол, про IP-уровень? Хорошо, а как это все работает? Понимает ли он, как происходит роутинг? Ну и скопом: таблицы маршрутизации, динамический протокол маршрутизации, транспортный уровень TCP. И так далее, и так далее.
Я хочу услышать, чем отличаются TCP и UDP. Хороший спец ответит мне, почему критичные системы (например, Domain Name System) используют протокол без гарантированной доставки сообщений (UDP).
Ответ простой — так быстрее. Пока устраиваешь TCP-сессию, ты можешь 3 раза отправить UDP пакетик туда и получить его обратно. И никакого оверхеда.
Задаю вопросы про DNS
Какие бывают типы записи? Знает ли мой собеседник, что такое MX-запись, как работает spf или как работает DKIM.
Да, в работе эти знания могут и не пригодиться. Но мне важно знать, понимает ли человек суть технологии, было ли ему интересно прочитать про это. Вот добавлял он какие-то записи в DNS и загуглил, что такое spf-запись, или не загуглил?
Абсолютно везде сейчас используется HTTP-протокол, и я про него спрашиваю
Я начинаю со стандартных вопросов об отличиях http-версий 1.0, 1.1 и второй версии. Интересуюсь, что такое headers и зачем они нужны. Как веб-сервер понимает, что ему пришел запрос на определенный virtual host, а не на любой другой. И всегда задаю пару вопросов по Nginx.
Дальше плавно переключаю внимание на TLS-протокол
Как работает SSL\TLS? Инженеру нужно понимать это хотя бы на базовом уровне — есть корневой центр сертификации, он подписал сертификат, и сертификат где-то используется.
В TLS меня обычно интересует процесс установки соединения. Зачем нужны приватный и публичный ключи и как они взаимодействуют? Если человек шарит, то задаю вопрос с подвохом: можно ли иметь несколько разных сертификатов на одном IP-шнике?
Перехожу к Linux и BASH
Надо знать все юниксовое, все Unix-like системы. Нужно уметь работать с Shell и Bash, знать основные команды. ls-ы всякие, mkdir и т.д.
Хорошо, если кандидат может немного скриптовать на BASH — значит, он пробовал хоть как-то автоматизировать эту историю.
По Linux спрошу, как заменить в файле строчки другими строчками. Или как распарсить какой-нибудь access.log в Nginx средствами BASH. Чтобы человек рассказал про awk, про cat, про sort, про все, что помогает быстрой работе.
Там всюду текстовые файлы, надо с ними правильно работать. Если соискатель предложит копировать их в эксельку и уже там что-то делать, то мне станет неловко.
Потом надо выяснить, как дела с виртуализацией
Обычная виртуализация, виртуализация через гипервизор. Если кандидат заводит разговор про паравиртуализацию — значит, что-то знает.
Основной мой вопрос: чем отличается контейнерная виртуализация от обычной гипервизорной виртуализации? Хорошо, если человек сравнит что лучше, что хуже, где что подобает использовать.
Перемещаемся к контейнерам
Узнаю, работал ли собеседник с Docker? Собирал ли он образы, писал ли Docker-файлы, использовал ли Docker compose, деплоил ли с его помощью. Зачем вообще нужны эти контейнеры и как они работают? Поднимал ли наш соискатель систему оркестрации контейнеров Swarm или Kubernetes? Можно задать целый блок вопросов, но главное понять, делал человек работу своими руками с контейнерами или нет?
Спрашиваю про CI/CD deployment
Меня интересует огромный список вещей: как он настраивает автоматический deployment, как настраивает Continuous Integration? Как у него собираются приложения, использует ли он системы анализа кода (PVS-Studio, SonarQube). Как он пишет тесты или как интегрирует тесты, написанные разработчиками.
Делает ли он какое-то интеграционное тестирование этих сборок? Что дальше происходит с тем, что он собрал? Это как-то складывается в артфекаты или это упаковывается в docker-контейнеры, пушится в registry? Пусть расскажет, какие системы использовал для настройки CI/CD-процесса. Это могут быть и GitLab CI, и Circle CI, и какие-то облачные решения. А может быть, Jenkins, ну и про самописные скрипты на PowerShell не стоит забывать.
Скажи мне, как человек деплоит, и я все пойму. Он может деплоиться с помощью Helm в Kubernetes, Ansible, скриптами или чем-то еще самописным.
Про систему управления конфигурациями
Говорим чаще всего по Ansible. Поскольку его знают большинство. Итак, зачем нужны роли, как зашифровать и хранить секретные данные, как закидывать пароли на Git-репозиторий? И все в таком духе.
Узнаю про умение писать код
Разбираться в разработке важно, чтобы понимать, как взаимодействуют сервисы, зачем нужны API, протоколы аутентификации, авторизации. Славно, если кандидат что-то писал сам. Мне достаточно даже базовых скриптов на Python или Shell. Важен не код, а то, какие задачи хотел решить человек, чего хотел добиться.
Кодинг нужен для поддержки инфраструктуры, написания локальных скриптов для бекапа, кастомных мониторингов, чтобы спокойно вытаскивать метрики. Часто бывает в работе, что стандартного решения для какой-то задачи попросту нет.
Последние вопросы на собеседовании касаются хранилищ баз данных
SQL, NoSQL — в чем различия, с чем работали? Чаще встречаю людей с опытом работы в PostgreSQL, реже — MySQL. Задаю вопросы про индексы, может ли соискатель настроить реплику, может ли настроить логическую репликацию между табличками или просто данными. А что он будет мониторить в этом случае? А как ускорить базу?
Кстати, это хороший вопрос. Допустим, база сейчас сидит и упирается в диск. И с ней ничего не сделать — больше сервер никто покупать не будет. Как сделать так, чтобы оно работало быстрее прямо сейчас?
Все это позволяет составить полную картину о человеке
Самое критичное в моем списке — базовые знания. Не знаешь базу — пора заканчивать собес.
Если человек не может мне ответить, что такое маска подсети, или не понимает, зачем нужны headers в HTTP — в большинстве случаев такой соискатель получает наижирнейший минус в моей тетради. Разве тебе не любопытно было узнать, как работают все эти штуки, в которых ты тыкаешь курсором мышки?
Очень тяжело работать с людьми, которые просто механически повторяют заученное, вместо того, чтобы разобраться, как все устроено. Новичок, не знающий Docker, спокойно в нем разберется, если у него есть понимание, что такое HTTP, TLS и сети.
Но вот, наконец, самый важный момент — весь этот список нужен не для того, чтобы идти по нему на настоящем собеседовании. Этот список надо пройти самому перед тем, как нанимать людей.
И если все получится, зовите кандидата на собеседование и задавайте ему всего один вопрос — какой самый большой фейл ты совершил в работе, как чинил его и какие выводы сделал из своих ошибок.
Когда человеку есть, что рассказать, такой собес пройдет как дружеская беседа двух инженеров под пиво.
Ну и по традиции, приглашаю присоединиться к нашему сообществу в телеге — там регулярно разбираем все эти темы и многие другие, которые пригодятся и на собеседовании, и в работе.
Как собеседовать технического специалиста
Как это бывает
В большинстве случаев для проведения оценки приглашают другого специалиста с высокой степенью технической компетенции, который, как правило, ничего не понимает в кадровых вопросах и методологиях сбора информации о личности человека, и просто начинается лобовой допрос «кто больше знает». Некоторые интервьюверы просто имеют чеклист вопросов. Также многие используют практику тестового задания, которое требуется выполнить до назначения очного собеседования. В общем, кто как может, тот так и решает задачу.
В целом, такой подход бывает эффективен, но он имеет ряд недостатков:
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 домов, как это лучше сделать? Для каких поверхностей какие средства для уборки лучше использовать?
