Написанные тезисы абсолютно верны, и я с ними полностью согласен.
Только статья несколько про другое. Она про то, что я на своем опыте сталкиваюсь с множеством кандидатов, которые знают теорию, но не могут в практику. И проблематика в том, что техническое интервью не выполняет своей прямой функции.
По поводу галер не понял комментарий. Зная специфику работы на галерах, я понимаю как потенциальные сильные стороны кандидата, так и слабости, которые нужно будет проверять на интервью.
Равно как и остальные пункты в разборе CV - это якоря, от которых я отталкиваюсь при общении про опыт и решаемые задачи.
Также полностью согласен с тем, что содержание не отражает форму. Это истинная правда. Я лично неоднократно сталкивался с тем, что кандидат с бледным резюме оказывался неграненым алмазом. Были и ситуации ровно наоборот. Это правда жизни.
А вот это очень правильный замечание. Вы правы, что многие компании ищут себе готового кандидата, который умеет в наши инструменты.
Особенно остро этот момент ощущается, когда ребята переходят из одной области в другую. Например из Embedded в Web. Знания инструментов нет, тонкостей работы с определенными аспектами тоже. И очень многие высококлассные специалисты получают отказы, потому что даже до джуна не дотягивают.
И здесь я с вами полностью согласен - когда я собеседую кандидатов, мне вторично, с чем он работал. Для меня важно - понимает ли он, как решать ту или иную задачу. Инструмент освоить проще, нежели научиться думать.
Возьмем пример из реального собеседования.
У кандидата написано - кроссплатформенное тестирование. Задаю вопрос, что делал - отвечает, что запускал скрипт на win и *nix машине. Все.
Но написано же кроссплатформенное тестирование, может действительно опыт был сильно ограниченный, но есть видение, как это в принципе происходит?
Уточняем у кандидата, что за скрипт, что делал. И задаем дополнительный вопрос - как бы он протестировал работу определенной функциональности этого скрипта на разных платформах?
И вот если кандидат не может ничего сказать, кроме как "запустить скрипт", то для меня это сигнал.
Мы очень трепетно относимся к подобной строгости в IT. Как же так можно? Вы нелюди, не даете кандидатам проявить себя! Но давайте проведем параллель.
Если у хирурга будет написано "опыт проведения операций на сердце", но на вопрос о том, что он делал, выяснится, что он подал зажим оперирующему хирургу. А на вопросы, как делается операция он не может ответить ничего, кроме как того, что пациента нужно разрезать, и обязательно нужно приготовить зажим, вы пойдете под нож к такому хирургу?
Также многие забывают, что IT бывает разным, и требования в разных областях отличаются, цена ошибки также может сильно разниться.
Раньше я работал в области разработки электроники. Цена ошибки - отзыв продукции и разорение компании.
Затем была медицина. Думаю комментировать цену пропуска ошибки не стоит.
Аналогично по другим направлениям, с которыми я работал и продолжаю работать. Цена ошибки в этих отраслях очень высока, и это одна из причин, по которым я ставлю высокие требования к кандидатам. Я готов научить инструментам, я готов погружать в предметную область, но только если кандидат демонстрирует способность к этому обучению.
В то же время я прекрасно понимаю, что есть множество других направлений бизнеса, где можно закрыть глаза на многие вещи, что-то в принципе не делать. И в этих компаниях действительно нет столь острой необходимости требовать от кандидатов глубоких знаний и понимания работы в разных областях.
Правильнее сказать, что это мои предпочтения к составлению резюме.
Вообще тема содержимого резюме - тот еще раскрученный вентилятор... Посмотреть рекомендации разных компаний и рекрутеров по составлению резюме, так по доброй половине пунктов рекомендации будут строго противоположными.
Junior - знание + понимание теории, умение применить ее на практике. Если заявлены ЯП - знание базовых структур данных, умение написать простой код. Умение рассуждать.
Middle - все, что junior + знание своей профильной предметной области, знание и понимание тех инструментов, с которыми работал. Системный подход к решению задач. Понимание внутренних процессов. Если заявлена автоматизация - умение читать и анализировать чужой код, понимание принципов работы инструментов. Алгоритмистика. Знание и умение применять архитектурные подходы. Базовые знания CI/CD
Senior - Middle + глубокие знания своей предметной области, инструментов, эффективности их применения. Умение работать в условиях недостаточных вводных, учитывать при решении задач внешние факторы. Если заявлена автоматизация - знания тонкостей работы инструментов, Ci/CD, умение реализовать методы, спрятанные под капотом тест фреймворков.
Lead - Senior + менеджерские качества, знания процессов, подходов к оптимизации работы команды, оценка и планирование. Умение декомпозировать задачи, оценивать риски.
Софт скиллы:
Помимо классических аспектов вроде общения, невербалики, я крайне ценю кругозор, умение быстро погрузиться в предметную область, умение слушать и слышать. Это хорошо заметно, когда даешь подсказки, либо дополнительные вводные в задачах.
По итогу выбор делается по принципу: хард скиллы позволяют выполнять задачи, не потребуется инвестировать несколько месяцев в обучение. Софт скиллам отдается очень большой вес. И оценка перспектив развития сотрудника (эти последние пункты я и называю "чуйкой").
Если рассмотреть на примере, то, допустим, есть 3 кандидата: 1. Супер харды, но большие вопросы по софтам
2. Слабые харды (ниже требуемого минимума), но "рубаха-парень"
3. Харды на грани, возможно даже чуть ниже минимума, но обучаем, широкий кругозор и хорошие софты.
Из трех кандидатов я выберу кандидата (3). И ключевая причина - софты, кругозор и обучаемость.
Обучать придется всех, и моя задача найти того, чье обучение пройдет наиболее быстро, гладко, и чей потенциал не ограничится этими начальными задачами.
Также стоит отметить, что критерии могут отличаться в зависимости от того, насколько "горит" та или иная вакансия. но это тема, заслуживающая отдельного поста, т.к. там придется лезть в вопросы бюджетов, законодательства, бизнеса, развития, ROI и т.д.
Я вполне могу чего-то не знать. Это нормально. И готов исправить недочеты в статье, если таковые есть.
Расскажите мне, пожалуйста, пример применение кросс-браузерного тестирования в мобильном приложении.
Не кросс-платформенное тестирование, а именно кросс-браузерное. И не мобильной верстки, а именно приложения. Того, что в конечном счете попадает в маркет.
Вы правильно говорите, что собеседование - это взаимная история. И именно поэтому очень важны в том числе и вопросы соискателей.
По вашему комментарию я приведу такой пример...
В детстве мы часто во дворе играли в футбол, и капитаны набирали команды по принципу "драфта". То есть по очереди выбирали себе в команду игроков и общей массы.
И задайте себе сами вопрос - если вы хотите победить, вы будете выбирать друзей, или лучших, исходя из ваших потребностей?
По поводу "будет неприятно работать" - это зависит от множества факторов. Нанимаются не набор качеств, а люди, личности. И итоговый результат работы зависит во многом от того, как вы сможете выстроить совместную работу. Будешь ли ты, как работодатель, закрывать потребности сотрудника, будет ли он разделять твои ценности, и будешь ли ты прислушиваться к потребностям сотрудника.
Если ваши интересы пересекутся, то, с высокой долей вероятности, вас ждет успех.
На текущем месте работы я вскрыл эту проблему и она в процессе решения. Проблема как раз на этапе технического собеседования - шаблонность вопросов и ответов. На предыдущем месте работы, где я провел огромное число собеседований, мы придерживались другой системы собеседований.
Если кратко, то был скрининг со стороны HR + один очный этап длительностью час-полтора с экспертами + в некоторых случаях технический тест на пару часов. По итогу компании такие собеседования обходятся дороже, но календарно они очень быстрые, и оценка кандидатов была более широкой. Конверсия была высокой за счет отсева на этапе скрининга со стороны HR.
Но, справедливости ради, там была довольно узкая область и поток кандидатов в принципе был не такой большой, как в вебе.
Как понять, подходит кандидат или нет - та самая незамысловатая "чуйка". Практика показывает, что она намного надежней тестов, поскольку учитывает софт скиллы. Когда я собеседую кандидатов, я уже понимаю, кто мне нужен. Если у меня позиция автоматизатора на определенном проекте, я прекрасно понимаю, какие мне нужны качества и уровень кандидата. Аналогично по ручникам. В зависимости от проекта и состава имеющейся команды я понимаю, могу ли я себе позволит инвестировать больше в развитие кандидата, или мне нужен сотрудник с твердой базой и знаниями в определенных областях.
Данная статья скорее про то, как сэкономить время и себе, и кандидатам, чтобы не проходить через все этапы собеседования, чтобы не разочаровываться низким процентом найма на финале.
Вам спасибо за комментарий.
Писать буду, но совершенно на другие темы :)
Спасибо за комментарий.
Написанные тезисы абсолютно верны, и я с ними полностью согласен.
Только статья несколько про другое. Она про то, что я на своем опыте сталкиваюсь с множеством кандидатов, которые знают теорию, но не могут в практику. И проблематика в том, что техническое интервью не выполняет своей прямой функции.
По поводу галер не понял комментарий. Зная специфику работы на галерах, я понимаю как потенциальные сильные стороны кандидата, так и слабости, которые нужно будет проверять на интервью.
Равно как и остальные пункты в разборе CV - это якоря, от которых я отталкиваюсь при общении про опыт и решаемые задачи.
Также полностью согласен с тем, что содержание не отражает форму. Это истинная правда. Я лично неоднократно сталкивался с тем, что кандидат с бледным резюме оказывался неграненым алмазом. Были и ситуации ровно наоборот. Это правда жизни.
А вот это очень правильный замечание. Вы правы, что многие компании ищут себе готового кандидата, который умеет в наши инструменты.
Особенно остро этот момент ощущается, когда ребята переходят из одной области в другую. Например из Embedded в Web. Знания инструментов нет, тонкостей работы с определенными аспектами тоже. И очень многие высококлассные специалисты получают отказы, потому что даже до джуна не дотягивают.
И здесь я с вами полностью согласен - когда я собеседую кандидатов, мне вторично, с чем он работал. Для меня важно - понимает ли он, как решать ту или иную задачу. Инструмент освоить проще, нежели научиться думать.
Возьмем пример из реального собеседования.
У кандидата написано - кроссплатформенное тестирование. Задаю вопрос, что делал - отвечает, что запускал скрипт на win и *nix машине. Все.
Но написано же кроссплатформенное тестирование, может действительно опыт был сильно ограниченный, но есть видение, как это в принципе происходит?
Уточняем у кандидата, что за скрипт, что делал. И задаем дополнительный вопрос - как бы он протестировал работу определенной функциональности этого скрипта на разных платформах?
И вот если кандидат не может ничего сказать, кроме как "запустить скрипт", то для меня это сигнал.
Мы очень трепетно относимся к подобной строгости в IT. Как же так можно? Вы нелюди, не даете кандидатам проявить себя! Но давайте проведем параллель.
Если у хирурга будет написано "опыт проведения операций на сердце", но на вопрос о том, что он делал, выяснится, что он подал зажим оперирующему хирургу. А на вопросы, как делается операция он не может ответить ничего, кроме как того, что пациента нужно разрезать, и обязательно нужно приготовить зажим, вы пойдете под нож к такому хирургу?
Также многие забывают, что IT бывает разным, и требования в разных областях отличаются, цена ошибки также может сильно разниться.
Раньше я работал в области разработки электроники. Цена ошибки - отзыв продукции и разорение компании.
Затем была медицина. Думаю комментировать цену пропуска ошибки не стоит.
Аналогично по другим направлениям, с которыми я работал и продолжаю работать. Цена ошибки в этих отраслях очень высока, и это одна из причин, по которым я ставлю высокие требования к кандидатам. Я готов научить инструментам, я готов погружать в предметную область, но только если кандидат демонстрирует способность к этому обучению.
В то же время я прекрасно понимаю, что есть множество других направлений бизнеса, где можно закрыть глаза на многие вещи, что-то в принципе не делать. И в этих компаниях действительно нет столь острой необходимости требовать от кандидатов глубоких знаний и понимания работы в разных областях.
Подкол засчитан =)
Правильнее сказать, что это мои предпочтения к составлению резюме.
Вообще тема содержимого резюме - тот еще раскрученный вентилятор... Посмотреть рекомендации разных компаний и рекрутеров по составлению резюме, так по доброй половине пунктов рекомендации будут строго противоположными.
Попытаюсь формализовать свои критерии:
Хард скиллы:
Junior - знание + понимание теории, умение применить ее на практике. Если заявлены ЯП - знание базовых структур данных, умение написать простой код. Умение рассуждать.
Middle - все, что junior + знание своей профильной предметной области, знание и понимание тех инструментов, с которыми работал. Системный подход к решению задач. Понимание внутренних процессов. Если заявлена автоматизация - умение читать и анализировать чужой код, понимание принципов работы инструментов. Алгоритмистика. Знание и умение применять архитектурные подходы. Базовые знания CI/CD
Senior - Middle + глубокие знания своей предметной области, инструментов, эффективности их применения. Умение работать в условиях недостаточных вводных, учитывать при решении задач внешние факторы. Если заявлена автоматизация - знания тонкостей работы инструментов, Ci/CD, умение реализовать методы, спрятанные под капотом тест фреймворков.
Lead - Senior + менеджерские качества, знания процессов, подходов к оптимизации работы команды, оценка и планирование. Умение декомпозировать задачи, оценивать риски.
Софт скиллы:
Помимо классических аспектов вроде общения, невербалики, я крайне ценю кругозор, умение быстро погрузиться в предметную область, умение слушать и слышать. Это хорошо заметно, когда даешь подсказки, либо дополнительные вводные в задачах.
По итогу выбор делается по принципу: хард скиллы позволяют выполнять задачи, не потребуется инвестировать несколько месяцев в обучение. Софт скиллам отдается очень большой вес. И оценка перспектив развития сотрудника (эти последние пункты я и называю "чуйкой").
Если рассмотреть на примере, то, допустим, есть 3 кандидата:
1. Супер харды, но большие вопросы по софтам
2. Слабые харды (ниже требуемого минимума), но "рубаха-парень"
3. Харды на грани, возможно даже чуть ниже минимума, но обучаем, широкий кругозор и хорошие софты.
Из трех кандидатов я выберу кандидата (3). И ключевая причина - софты, кругозор и обучаемость.
Обучать придется всех, и моя задача найти того, чье обучение пройдет наиболее быстро, гладко, и чей потенциал не ограничится этими начальными задачами.
Также стоит отметить, что критерии могут отличаться в зависимости от того, насколько "горит" та или иная вакансия. но это тема, заслуживающая отдельного поста, т.к. там придется лезть в вопросы бюджетов, законодательства, бизнеса, развития, ROI и т.д.
Я вполне могу чего-то не знать. Это нормально. И готов исправить недочеты в статье, если таковые есть.
Расскажите мне, пожалуйста, пример применение кросс-браузерного тестирования в мобильном приложении.
Не кросс-платформенное тестирование, а именно кросс-браузерное. И не мобильной верстки, а именно приложения. Того, что в конечном счете попадает в маркет.
Вы правильно говорите, что собеседование - это взаимная история. И именно поэтому очень важны в том числе и вопросы соискателей.
По вашему комментарию я приведу такой пример...
В детстве мы часто во дворе играли в футбол, и капитаны набирали команды по принципу "драфта". То есть по очереди выбирали себе в команду игроков и общей массы.
И задайте себе сами вопрос - если вы хотите победить, вы будете выбирать друзей, или лучших, исходя из ваших потребностей?
По поводу "будет неприятно работать" - это зависит от множества факторов. Нанимаются не набор качеств, а люди, личности. И итоговый результат работы зависит во многом от того, как вы сможете выстроить совместную работу. Будешь ли ты, как работодатель, закрывать потребности сотрудника, будет ли он разделять твои ценности, и будешь ли ты прислушиваться к потребностям сотрудника.
Если ваши интересы пересекутся, то, с высокой долей вероятности, вас ждет успех.
На текущем месте работы я вскрыл эту проблему и она в процессе решения. Проблема как раз на этапе технического собеседования - шаблонность вопросов и ответов.
На предыдущем месте работы, где я провел огромное число собеседований, мы придерживались другой системы собеседований.
Если кратко, то был скрининг со стороны HR + один очный этап длительностью час-полтора с экспертами + в некоторых случаях технический тест на пару часов. По итогу компании такие собеседования обходятся дороже, но календарно они очень быстрые, и оценка кандидатов была более широкой.
Конверсия была высокой за счет отсева на этапе скрининга со стороны HR.
Но, справедливости ради, там была довольно узкая область и поток кандидатов в принципе был не такой большой, как в вебе.
Как понять, подходит кандидат или нет - та самая незамысловатая "чуйка". Практика показывает, что она намного надежней тестов, поскольку учитывает софт скиллы.
Когда я собеседую кандидатов, я уже понимаю, кто мне нужен.
Если у меня позиция автоматизатора на определенном проекте, я прекрасно понимаю, какие мне нужны качества и уровень кандидата.
Аналогично по ручникам. В зависимости от проекта и состава имеющейся команды я понимаю, могу ли я себе позволит инвестировать больше в развитие кандидата, или мне нужен сотрудник с твердой базой и знаниями в определенных областях.
Данная статья скорее про то, как сэкономить время и себе, и кандидатам, чтобы не проходить через все этапы собеседования, чтобы не разочаровываться низким процентом найма на финале.