Записи с метками собеседования

Сегодня решил написать очередную статью из серии статей на тему отбора сотрудников. Статья будет короткой, но я постараюсь сделать ее интересной. Будут рассмотрены несколько вещей, на которые я обращаю большое внимание при отборе кандидатов, при этом не связанные напрямую с его уровнем подготовки.

Итак, первый тип «плохих» кандидатов – так называемые бегунки. Это люди, которые постоянно меняют работу и не могут проработать на одном месте больше полугода. Когда таких места 2 или 3, это еще не вызывает подозрения. В этом случае можно сослаться на неудачный опыт, быстрый карьерный рост, короткие проекты и т.д. Но если кандидат за 4 года сменил 6-8 проектов, то для меня это практически красный флаг. 

Я хочу брать в проект людей, которые потенциально готовы работать в нем достаточно долго (хотя бы год-полтора). Ради нескольких месяцев нет смысла вкладывать в человека – передавать ему знания доменной модели, технологического стека, процессов и практик. Это замедляет команду, поэтому такие инвестиции хочется потом вернуть сполна. А бегунок уже имеет совершенно другие планы.

Приведу несколько примеров почему такие кандидаты встречаются. Наиболее распространенный типаж – «я работаю работу там где больше платят и лучше живется». Это значит, что при появлении на рынке более «жирной» вакансии этот человек может не раздумывая «подать на развод». 

Второй пример – «карьеристы». Они действуют по принципу «каждые полгода я очень сильно расту и мне нужны новые горизонты». Но вам то нужен надежный грамотный человек на изначальной позиции. У вас может не быть интереса в такой короткий срок на другие позиции. И, признаться откровенно, большая часть подобных «карьеристов» только мнят себе профессиональный рост. На самом деле они знают все по верхам и пытаются вылезть наверх, пользуясь ситуацией на рынке.

Третий тип – люди, которые ни с кем не могут ужиться в команде. Вот сидит перед вами отличный технический специалист, но в команде он скорее тормозит работу, чем помогает добиваться поставленных целей.

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

Второй тип «подозрительных» кандидатов, о котором я хочу поговорить, легко распознать по отношению к собеседованию. Обычно такой кандидат опаздывает на собеседование или же и вовсе приходит со второй попытки. К вопросам на собеседовании у него похожее отношение – все знания очень поверхностные, несколько «неряшливые». При этом в резюме у человека перечислены все возможные технологии, с которыми он хотя бы раз в жизни сталкивался. Обновлять резюме такие кандидаты ленятся.

Часто создается ощущение, что человеку эта работа вообще не так уж и нужна. Он может задавать встречные вопросы наподобие «а зачем мне это знать» или «почему мне задают такие вопросы». Из моего опыта точно так же кандидат будет относиться и к работе в вашей компании – не утруждать себя приходить вовремя на важные мероприятия, не заморачиваться детальным пониманием системы и технологий, выполнять только работу, за которую по его мнению ему платят. Работать с таким человеком в одной команде сложно. Мы работаем далеко не за маленькие деньги в IT индустрии и стоит нанимать только тех людей, которые хотят работать и понимают ответственность этой работы.

Удачного вам найма!

В последнее время стало модно писать про проведение собеседований. Вопросам правильного найма сотрудников уделяется все больше внимания. Я хочу поделиться своим мнением по поводу подхода, в котором у кандидата не спрашивают про конкретные примеры использования инструментов, API, библиотек языка программирования. Мол, главное чтобы соображал хорошо, а для остального есть Google.

Мне данный подход кажется более чем неправильным. Я не призываю спрашивать наизусть заученные названия классов и методов. Это как раз можно решить с помощью IDE и того же Google. Но вот в какую сторону копать надо знать четко. Особенно если именно в этой области вам предстоит работать достаточно долго.

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

А если начать искать, то в топе будут обычные классические примеры на «чистой» Java или другом языке программирования. И что происходит дальше? Человек просто копирует решение к себе и не переживает. Откуда ему знать про Java Concurrency API, про Google Guava и другие полезные библиотеки? Что получается в итоге? Куча времени на поиск и понимание решения, бездумное копирование и минимум новых знаний. Потом это решение в коде находит грамотный разработчик и исправляет его на более быстрое, надежное и грамотное. А за все уже заплачено!

И зачем платить больше? Ведь дешевле нанять заведомо хорошо разбирающегося в данной области человека, возможно за большее количество денег, чем платить постоянно. Расходы гораздо более предсказуемы. И это мы рассмотрели позитивный сценарий, когда найденное решение или его копирование не приводит к ошибке. Иначе стоимость будет гораздо выше.

Еще один банальный пример из Java мира – поиск в строке. Казалось бы безобидный поиск, но каждый раз создается и компилируется шаблон регулярного выражения, что замедляет работу метода в десятки раз. Это нереально найти, если ты заранее не знаешь о таком поведении. Логично ли задать такой вопрос для проекта, где работа со строками идет очень интенсивно? Или лучше потерять потом часы и дни на отладку и тюнинг производительности?

Приведу еще один пример, более «бытовой». Все знают, что ORM библиотеки умеют подгружать коллекции дочерних элементов автоматически по заданному маппингу. Но задумается ли человек, который не изучал как работает используемый в вашем проекте ORM инструмент, как и когда это происходит? Я думаю нет! И, в итоге, код будет делать сотни запросов в базу данных по совершенно простому действию с коллекцией (к примеру поиску по ней). И ничего не будет предвещать беды, пока приложение не будет под реальной нагрузкой. Стоит ли разбирать такие куски кода на собеседовании, если ORM у вас используется очень активно? Думаю да!

Резюмируя, очень важно убедиться, что кандидат понимает важную для вашего проекта область разработки на должном уровне. И для этого можно и нужно разбирать реальные примеры, задачи из жизни и реальный код. Ничего плохого в этом нет. Но и требовать от кандидата держать в памяти все методы и классы глупо. Важно убедиться в том, что при проблеме человек точно знает направление поиска. Беспорядочный поиск будет стоить вам очень дорого! Помните, что дешевле не нанять правильного человека чем нанять неправильного!

Резюме – это то, с чего начинается знакомство между компанией и кандидатом. Его размещают на сайтах о работе, высылают, публикуют, выпрашивают… Вообщем, резюме играет очень важную роль как для кандидата так и для компании. Часто именно с помощью просмотра резюме определяется подходит ли данный кандидат потенциально на определенный проект и стоит ли приглашать его на дальнейшие собеседования. Если резюме содержит неверную или устаревшую информацию, то решение может быть принято неверно. Это повлечет за собой пустую трату времени кандидата, рекрутеров, интервьюера и других звеньев в цепи найма сотрудников.

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

• Выделите время на его составление. Это время вы инвестируете прежде всего в себя, повышая шансы быть нанятым на подходящую вам работу. Также вы повышаете свою оценку в глазах работодателя. Ведь человек, который не справился даже с резюме, вызывает подозрения к своей последующей деятельности на рабочем месте. Но время действительно понадобится. Возможно от нескольких часов до целого дня.

  Вы должны аккуратно собрать воедино все свои знания и навыки, правильно их структурировать и преподнести, уделяя особое внимание вашим сильным сторонам. Также вам понадобится описать проекты, в которых вы принимали участие. Время на эту часть пропорционально количеству проектов. Не торопитесь – спешка порождает ошибки.

• Укажите свои навыки и знания. Этот пункт вроде бы выглядит простым. Тем не менее с ним возникает большая часть проблем. Эта часть резюме отвечает именно за ваши актуальные знания, которые вы готовы и желаете применять на будущем месте работы (в реальных проектах).

  Не включайте сюда технологии, с которыми вы работали только в юном возрасте в университете. Они захламляют резюме и прячут действительно полезную информацию. Врядли вы будете снова программировать на Delphi. Если вас все же одолевает желание указать эту информацию, то вынесите ее в отдельную секцию для дополнительных умений за пределами основной части резюме.

  Также не пытайтесь указать как можно больше бесполезных аббревиатур – пишите кратко и по существу. К примеру, » …HTML, XHTML, CSS, CSS2, CSS3, DHTML, JavaScript … « можно сократить в два раза, практически не потеряв сути. Особенно когда речь идет не о специализированном разработчике web UI.

  Старайтесь указывать только технологии, в которых вы действительно разбираетесь. Это не значит, что вы обязаны работать с ними половину своей карьеры. Но и включать все технологии к себе в послужной список из проекта, где вы работали несколько месяцев и в основном поправляли конфигурацию, тоже не стоит. Либо упомяните о низ в разделе проектов, указав свой уровень причастности.

  Не указывайте огромного списка баз данных только потому, что они были на ваших проектах. Если вы работали с ними только через стандартный SQL, то это никак не поможет вашему работодателю. Указывайте только те базы данных, для которых вы знаете об отличительных особенностях, занимались проектированием или специфическими вещами (отладкой, настройкой, инструментами). Иначе можно смело включать все базы данных, что многие и делают.

  Обязательно разбейте технологии на группы, так будет удобнее искать по резюме конкретную информацию. Примеры групп: Web, Search engines, Data access, Utilities. Делайте акцент на тех навыках, которые являются вашими сильными сторонами и в которых вы уверены. Остальную информацию либо убирайте, либо выносите в дополнительную секцию.

• Укажите информацию о проектах. Выберите те проекты, которые вы считаете важными с точки зрения вашего опыта и навыков. Вовсе необязательно расписывать все из них. Для каждого проекта укажите следующую информацию: специфика проекта, технологические особенности, процесс разработки и состав команды, ваши ключевые обязанности.

  Специфика проекта должна присутствовать минимально. Во-первых, потому что это не всегда открытая информация и не следует нарушать соглашения о неразглашении. Даже для резюме. Во-вторых, она интересна только тогда, когда является очень специфической и представляет из себя ценность как отрасль. К примеру, банковская сфера или финансовые приложения. В противном случае информация практически бесполезна, потому что она несет в себе чисто информационный характер. Гораздо более важно что представлял собой проект с технологической стороны и ваша роль в нем.

  Не расписывайте детально архитектуру и решения, сделанные на проекте. Вместо этого сосредоточьте внимание на том, как проект отразился на вашем опыте и карьере. Ведь рассматривают вас, а не проект. Ограничьте себя заранее определенным количеством предложений, чтобы не появилось желания написать роман на каждый проект. Сэкономьте ваше время и время людей, изучающих ваше резюме.

  Особое внимание уделите названию вашей позиции на проекте. Поймите, что вы делали на проекте в действительности. Вы не могли быть лидером команды, в которой были только вы и еще один работник, а еще лучше только вы. Укажите обязательно состав команды и выделенные роли в ней. Не преувеличивайте свою роль на проекте – вам могут задавать вопросы, на которые вы просто не будете знать ответов, хотя для указанной роли они очень важны.

• Сделайте краткую секцию о себе. В эту секцию вы должны включить информацию об основных ваших заслугах, знанию иностранных языков, позициях в прошлой карьере, планах на будущее, дополнительные важные сведения, которые могут сыграть вам на пользу. Эта секция помогает быстро понять чем вы занимались и чем планируете.

  Не пишите в нее о ваших блогах, которые не имеют отношения к работе, о сумасшедших хобби, о вашей порядочности или приверженности к какой либо религии. Эта информация будет в любом случае проверяться рекрутерами, поэтому писать ее бесполезно. Не тратьте место и время. Не указывайте сертификаты и звания, которые не представляют ценности для вашего текущего направления работы. Постарайтесь сделать эту секцию лаконичной, но в тоже время достаточно информативной.

• Укажите свои контакты. К контактной информации относятся не только телефон и почтовый адрес. Укажите ссылки на ваши профили в специализированных социальных приложениях. По ним можно будет посмотреть отзывы, ваш круг знакомств и профессиональных интересов. Старайтесь не указывать профили в социальных сетях, не имеющих отношения к работе. Это может не только негативно отразиться на вашем трудоустройстве, но и выглядеть вызывающе.

  Укажите контакты людей, которые могут вас порекомендовать. Маловероятно, что их побеспокоят, но тем не менее это добавляет очки в вашу копилку, потому что вы не боитесь отрицательных отзывов. Также укажите альтернативные каналы связи, такие как Skype. Это удобный способ быстро обсудить детали предстоящей встречи или ответить на предварительные вопросы. Вы избежите постоянных звонков по телефону в самое неподходящее время.

В результате у вас должно получиться коротенькое, но содержательное резюме. Не пытайтесь раздуть его дополнительной информацией только ради объема. Если оно получилось на одну страницу, но содержит все о вас и вашей карьере, то вы можете собой гордиться. Соберите отзывы о вашем резюме от различных рекрутеров и ваших коллег, сделайте поправки. Вам редко будут сами указывать на недостатки, поэтому не стесняйтесь спрашивать. Через некоторое время ваше резюме придет к стабильному состоянию и изменения будут необходимы только при смене проекта или компании. Инвестируйте свое время в себя и удачи вам на собеседованиях!

Хотел бы в очередной раз коснуться темы собеседований. Скоро возьмусь за вторую часть серии статей про найм сотрудников, а пока лишь короткий призыв к соискателям. Этот призыв обращен ко всем людям, которые ищут работу и ходят по собеседованиям: «Не врите на собеседованиях!». Ведь, пускаясь по извилистой дорожке лжи, вы попросту потратите свое и чужое время.

Первая ложь у большинства начинается с резюме. 80% людей включают в свое резюме все известные им аббревиатуры и технологии, о которых только когда либо приходилось слышать. А сотрудники HR-отдела по наличию этих аббревиатур выбирают вас для первичного рассмотрения на роль кандидата в проект. Ведь у них нету больше никакой информации о вас. Альтернативой ложью является приписывать себе все технологии, на которых работал ваш проект, даже если вы в нем поработали всего 2 месяца и то на поддержке. В итоге, добираясь до собеседования, вы представляетесь совершенно другим человеком, чем есть на самом деле. Опытный интервьюер будет полностью разочарован в ваших знаниях после серии ответов из набора: «Ой, это уже давно было и я не помню», «Я вообще не разбирался как оно работает», «Я только поправлял уже существующий код» и т.д. Какой прок от ваших «знаний» в этой области? Как вы сможете помочь команде работать с этими технологиями уже завтра, после приема на работу? Вдруг все вспомните или сядете и разберетесь? Где гарантия, что вы сделаете это быстрее и лучше, чем человек, который видит их впервые, но хорошо знает основы разработки и языка программирования?

Вторая ложь начинается при попытке ответить на вопросы, ответы на которые вы точно не знаете. Вместо того, чтобы честно об этом сказать, достаточно большая часть начинает «сочинять решение» на лету. Причем часто делает это с очень серьезным видом. Некоторые решения просто поражают своей безграмотностью и могут перечеркнуть полчаса позитивных эмоций от собеседования. И снова, это является все той же тратой времени. Ведь быстро такие решения не «рождаются». Зато ваш честный ответ о том, что вы не сильно разбирались с областью, по которой задан вопрос, оставляет о вас очень приятное впечатление как о честном и грамотном человеке. Слово – серебро, молчание – золото. Представьте, что вы бы навязывали подобное «решение» своим коллегам в команде. Оно могло бы очень пагубно отразиться на проекте и на ваших взаимоотношениях. Таких «экспертов во всем и везде» никто не любит, особенно когда они несут откровенную чушь.

И, наконец, третья ложь встречается при разговоре о проекте. Вы увлеченно киваете головой, нахваливаете технологии, методологии и доменную область проекта. Даете понять, что с удовольствием бы начали работать на этом проекте. А, спустя несколько дней, после предложения о работе, отвечаете отказом по причине неинтересности для вас проекта. Вы разом потратили время интервьюера, HR-менеджера, менеджера проекта вместе взятых. Зачем? Скажите прямо, что вы сомневаетесь в интересности проекта. Если не собираетесь в нем участвовать, то попросите не продолжать более детальный рассказ. В этом случае компания сразу будет рассматривать вас в другие проекты и не потратит своего времени. В то же время, вы покажете себя как честный и открытый кандидат. Эти качества очень ценятся в людях, поэтому, по возможности, компания продолжит с вами сотрудничать по вопросам трудоустройства.

Будьте честны и вы сэкономите свое время, при этом зарекомендовав себя с лучшей стороны!