Как найти подходящего кандидата на должность "Разработчик 1С?"

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

• Сам я в сфере 1С более 10 лет – начал работу ИТС-ником, завершил руководителем проектов, являюсь сертифицированным преподавателем по программированию 1С для 6 курсов, и автором сертифицированного курса «Использование блокировок и методика проведения документов в среде 1С:Предприятие».

• Последние пять лет я занимаюсь именно подбором персонала – мы активно проводим поиски программистов, в неделю проверяем около 100 разработчиков, тестируем их знания и навыки. Из этих 100 разработчиков мы где-то 20-30 человек доводим до собеседования.

• Набор у нас в целом идет хорошо – как я сказал, за последние 5 лет я прособеседовал более двух тысяч кандидатов, и в целом, могу гордиться тем, что ни разу не ошибся в определении квалификации и знаний программиста, всегда знал, какие есть сильные стороны и слабые стороны в навыках именно разработки.

Когда я говорю про программистов, я имею в виду тех, кто разрабатывает – пишет программный код и выстраивает архитектуру. Это ни в коем случае не консультирование, не обучение пользователей, не настройка учета в программе и т.д. Почему-то в сфере 1С программистом очень часто называют человека, который больше консультирует, и немного программирует – но это, на самом деле, неправильно, поэтому мы будем разговаривать именно про программистов 1С.

Шаг 1. Определяемся, кто нам нужен: junior, middle или senior

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

Существует три уровня квалификации программиста:

• Junior – начинающий программист;

• Middle – середнячок;

• Senior – сильный разработчик, претендующий на должность архитектора или руководителя проектов.

Также существуют промежуточные квалификации – junior-middle и middle-senior.

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

Начнем с джуниора.

Junior – это начинающий программист, который обычно приходит работать в сферу 1С еще студентом. Уровень знаний у него минимальный, он, максимум, знает, как 1С открыть, какие нужно кнопки нажать и что-то еще в этом роде. Если повезет, то он проходил сертифицированные курсы от фирмы «1С» или от других компаний, которые проводят подобные курсы. Или, хотя бы, еще книжку почитал (Радченко «Практическое пособие разработчика» для начинающих). Если начинающий программист прошел курсы или прочитал книжку, то это хороший вариант, потому что, к сожалению, крайне редко даже действующие программисты с хорошим стажем проходят эти курсы – они очень много теряют, и грамотность пропадает.

На какие работы можно подключать джуниоров:

• Обновление типовых и не сильно доработанных конфигураций.

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

• Заведение пользователей.

В целом, такой начинающий программист подойдет для малого бизнеса, где стоит какая-то типовая конфигурация (например, УТ или БП), ее периодически нужно обновлять, а кроме того, заводить в базу пользователей и где-то немного проконсультировать о том, почему могут возникать те или иные проблемы в учете и как их поправить. С такими задачами начинающий программист должен справляться, а на что-то большее его лучше не подключать.

Дальше идет junior-middle

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

Но я не рекомендую подключать такого сотрудника на доработку каких-либо алгоритмов типа расчета себестоимости – у бухгалтерии часто бывает запрос на изменение логики «Закрытия месяца» и т.д. На такие задачи его лучше не подключать, а доверять ему минимальные штрихи по изменениям.

Следующим уровнем идет middle. Это уже «середнячки», разработчики, которые обладают достаточно хорошими знаниями и навыками в программировании.

Они могут:

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

• В целом у миддлов уже есть какие-то навыки по «Конвертации данных» (программа, которая позволяет написать правила обмена, что выгрузить и куда загрузить, и как это сделать).

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

Поэтому если у вас идет автоматизация торговой компании, то ищите именно тех разработчиков уровня middle, которые работали с УТ. Потому что сейчас, даже несмотря на то, что фирма «1С» стремится привести к единому стандарту все подходы и методики разработки, чтобы они были одинаковы во всех типовых прикладных решениях 1С, но, тем не менее, там есть какие-то нюансы.

Если, например, разработчик до этого работал только с УТ и если его подключают к БП, то он потратит время не только на изучение механизмов, которые используются в БП, но еще и будет тратить время на эти другие методики, на другие подходы к разработке, которые используются в БП, но не используются в УТ. Он будет «учиться на ходу» – но из-за этого будет больше тратиться времени на разработку и будет возникать больше ошибок. Поэтому, если вы набираете «середнячка» (а они обычно по рынку приемлемо стоят), то я рекомендую вам подбирать специалиста полностью «под себя» – если у вас УТ, то это должен быть человек, который работал с УТ, а если у вас ЗУП, то это должен быть человек, который работал с ЗУП.

Дальше по уровню идет middle-senior.

Эти разработчики уже обладают хорошими навыками программирования, хорошо разбираются в чужом коде, быстро «въезжают» в любую задачу. Но у них все равно еще есть какие-то пробелы в обменах.

Только 20% разработчиков на рынке хорошо знают обмены. Все остальные 80% крайне редко или вообще никогда не сталкивались с задачами по обменам. Хотя на сегодняшний день – это один из основных запросов, потому что очень часто идет интеграция с теми же самыми сайтами – у многих стоит Bitrix24, который необходимо интегрировать с 1С. Так что уровень запросов от пользователей растет, но разработчики даже уровня middle-senior почему-то еще не успевают в этом разобраться.

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

Также у этих разработчиков, кроме обменов, есть проблемы с так называемым «Разграничением прав доступа». Что это такое? Можно разграничить права доступа, например, к определенному документу, чтобы документ вообще не был доступен для какого-то пользователя. Это могут делать даже джуны.

Но если сделать более тонкое ограничение – например, указать, что доступен определенный вид документа, но только по определенной организации, здесь часто джуниор до middle-senior разработчики с этими механизмами не работали и они будут на изучение этого тратить много времени. Но в целом, middle-senior – это уже те разработчики, которых вам можно набирать. Если вам нужен сильный специалист, то на уровне middle-senior уже можно набирать себе в команду, где в кругу сильных разработчиков дотянуть их до уровня senior уже не будет проблемой.

И, наконец, уровень senior – это такой «лакомый кусочек».

• Данные разработчики уже подходят на должность архитектора, ведущего разработчика.

• Они могут полностью продумывать всю архитектуру – если вы поставите им задачу, они обязательно ее досконально разберут, зададут уточняющие вопросы, продумают все наперед.

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

• Скорость разработки у них всегда колоссальная – они очень быстро разрабатывают.

• И пишут они с минимальным количеством ошибок – это тоже немаловажно, потому что за исправление ошибок тоже приходится платить, вне зависимости от того, сидит он на окладе или работает по сделке, в любом случае, чем больше ошибок, тем больше мы переплачиваем.

Но у них есть существенные недостатки:

• Их очень мало – на рынке их порядка 5-6% с учетом демографического кризиса, который возник в 90-х годах, т.е. выборка этих разработчиков изначально мала. Можно найти сеньоров, которым 30-35, но найти разработчиков уровня senior, которым сейчас 25-27 очень тяжело. Хотя те, которым сейчас 30-35, в свое время в 25 лет уже были сеньорами.

• Они дорогие. Если взять рынок Москвы, то им нужно предлагать минимум 200 тысяч белыми на руки. И я знаю, что в Москве есть вакансии, где разработчика уровня senior предлагают по 350 тысяч, но они там работают чаще всего в роли архитектора.

• И самый интересный момент – они знают, что их мало, что они дорогие, поэтому, если им что-то не понравится, они просто развернутся и уйдут. У них есть абсолютная уверенность, что они обязательно найдут работу, и никаких проблем в этом у них нет.

Резюмируем, кого в каком случае нужно брать.

• Если у вас маленькая компания, в которой нужно просто поддерживать обновления конфигурации, еще что-то в этом роде, вам джуны подойдут.

• Если вам нужны доработки внешних печатных форм, отчетов или какие-то мелкие «бантики» добавить, в принципе, вам подойдут разработчики уровня junior-middle.

• Если вам все-таки нужно вносить уже какие-то значительные изменения в вашу программу – например, у вас в парке стоит УТ, ЗУП, БП и еще ДО, то здесь вам уже нужно выбирать разработчика уровнем не меньше middle, но здесь одна проблема – нужно выбирать разработчика именно по определенным конфигурациям, так будет меньше шансов, что вы наймете не того разработчика.

• А если у вас крупная компания, или идет крупное внедрение своими силами (сейчас очень много компаний разрабатывают собственные программные продукты, потому что те типовые или отраслевые решения от 1С им уже не подходят), то здесь уже нужно смотреть разработчиков уровня middle-senior, а лучше, конечно, senior.

Шкала квалификации кандидатов

Если посмотреть на шкалу квалификации кандидатов, то:

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

• Junior-middle уже получше знают оперативный учет (все, что связано с торговлей), СКД (механизм для формирования отчетов). Эти механизмы они уже знают и могут вести разработку – могут сделать отчет, печатную форму, внести какие-то изменения.

• Middle – здесь уже получше становится, но еще есть проблемы с обменами (с механизмами интеграции), с бухгалтерскими и расчетными задачами. Их нужно подбирать под определенную конфигурацию. Человек, в принципе, может с самого начала сидеть на ЗУП – он будет очень хорошо знать расчетные задачи, но с оперативным и бухгалтерским учетом у него будут проблемы.

• Middle-senior – здесь в целом все хорошо, но еще остаются небольшие проблемы с обменами и с RLS. В целом, этого разработчика можно успешно брать к себе на работу и подключать на любые проекты – минимальное количество ошибок возникает, но в качестве архитектора они не очень подходят.

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

Если посмотреть статистику собеседований за несколько месяцев – было прособеседовано чуть больше 1000 разработчиков, то здесь процентное соотношение:

• Джуниоров сейчас на рынке порядка 46%

• Junior-middle – 12%

• Middle – 23%

• Middle-senior – 13%

• Senior – 3,65%

Данная статистика была собрана зимой 2020 года, сейчас немного цифры поменялись, потому что зимой разработчики особо работу не ищут, они начинают ее активно искать весной и осенью.

Если взять среднюю статистику в целом за год, то количество senior будет где-то 5-6%, а разработчиков уровня middle – до 40%.

И вторая табличка внизу – это квалификация junior (деление по коэффициентам).

Уровень зарплат

Разобрались немного с уровнями программистов, переходим дальше.

Если смотреть заработную плату разработчиков по всей Российской Федерации, кроме Москвы и Санкт-Петербурга, то в целом зарплата по уровням:

• Junior – от 25 до 40 тысяч рублей. На эту зарплату без проблем можно набирать их в самих регионах или удаленно.

• Middle – от 40 до 80 тысяч рублей. У них разброс зарплат идет еще больше, потому что там есть коэффициенты уровня квалификации (от меньшего к большему идет), поэтому здесь идет очень сильный разнобой, и миддлов можно набирать и за 40 тысяч, и за 80 тысяч.

• Senior – от 80 до 120 тысяч рублей. Есть, конечно, предложения на рынке, где предлагают больше, но в среднем если взять по России (кроме Москвы и Питера), то на данных программистов идет именно такой диапазон зарплат.

Достаточно часто программисты даже уровня Junior, когда хотят устроиться на удаленную работу, запрашивают заработную плату 100 тысяч рублей. Не проблема – мы их собеседуем, проверяем уровень знаний и говорим, что можем предложить только 50-60 тысяч. Чаще всего, люди сами понимают, что больше не стоят, и соглашаются на эту заработную плату.

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

Шаг 2. Отбираем резюме кандидатов для обзвона по нескольким критериям

После того, как мы разобрались, кто нам нужен (junior, middle или senior), разобрались, какой у них уровень заработных плат идет (чтобы понимать, что невозможно за 20 тысяч нанять сеньора), дальше отбираем резюме кандидатов для обзвона по нескольким критериям.

• Первый критерий – это стаж работы. Мы набираем middle, middle-senior и senior. Поэтому я стаж работы смотрю от 3-4 лет (это если я смотрю миддлов). Если вам нужен middle, а у разработчика стаж меньше 3-4 лет, приглашать его бесполезно – за два года разработчик не станет хорошим специалистом, уверенным «середнячком», это будет уровень junior или junior-middle, не более того.

• Далее проверяем, не является ли он случайно «Универсальным солдатом» – изучаем в резюме описание, чем он занимался на прошлых работах. Зачастую бывает так, что человек сидит на должности программиста 1С по 5-6 лет, но когда начинаешь читать, чем он занимался – он занимается сайтами, серверами, программированием, консультированием и т.д. «10-в-одном» и т.д. От этого специалиста вы не получите хорошего программирования, у него все знания «рваные». Он то там, то здесь какие-то куски только знает. Лично я таких сам избегаю – бесполезно пытаться что-то из них выжать.

• Далее – важно проанализировать периоды работы в каждой компании. Здесь есть два момента:

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

  • «Старожила» – это когда человек работает в одной компании по 15 лет. Такой человек не хочет развиваться – он просто ищет, куда приткнуться, чтобы немного поднять себе зарплату. В целом, у нас профессия такая, что сильный специалист никогда долго на одном месте сидеть не будет. Ему все время хочется изучать что-то новое – и когда он приходит на новый проект, он занимается активным внедрением, разработкой, насыщает себя знаниями, навыками, опытом. А когда проект через 3-5 лет затухает, у него задачи становятся рутинными (он какие-то отчеты делает), ему становится скучно. И чисто профессионально стремится к новым знаниям и из-за этого идет искать новую работу. А «старожилам» в профессиональном плане ничего от жизни не нужно, поэтому большая вероятность, что он просто будет сидеть на рабочем месте, получать оклад, отсиживать часы, и не более того – никакой активности вы от него не получите.

Шаг 3. Выбираем наиболее подходящий вариант собеседования

После того, как мы отобрали резюме, теперь необходимо подобрать варианты собеседования. Вариантов собеседования огромное количество, но я выбрал 6 вариантов, которые чаще всего встречаются на рынке.

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

Плюсы этого варианта собеседования:

• Кандидат не может выбрать ответ из готовых вариантов – у него нет возможности отгадать ответ, нет возможности подсмотреть. Если он знает – то ответит, а если не знает, не сможет ответить.

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

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

Минусы:

• Тот, кто собеседует, должен обладать очень хорошими знаниями /навыками программирования. Он должен иметь хорошие знания и опыт в разделах, по которым задает вопросы.

• На каждого кандидата затрачивается большое количество времени сотрудника, который проводит собеседование. Лично у меня уходило где-то час-полтора на каждого кандидата. Это чисто теоретические вопросы. Я пробегался по всем механизмам 1С, которые есть, и задавал вопросы – порядка 50-60 вопросов. И на каждого кандидата я тратил час-полтора своего времени.

В целом, я больше всего склоняюсь именно к этому тесту, потому что он позволяет полноценно проверить разработчика на уровне его знаний по теоретической части.

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

Плюсы:

• У работодателя не тратится много времени на собеседование программистов – просто ссылку на тестирование выдали, а дальше кандидат уже сам проходит этот тест, просто отвечает на вопросы. По итогам прохождения теста мы сразу видим результат, можем подсчитать, сколько правильных/неправильных ответов.

Минусы:

• Такой тест также удобен для кандидата, потому что кандидат может просто угадать ответ или случайно куда-то тыкнуть, и это окажется правильным.

• Часто сам вопрос теста подсказывает правильный ответ, поэтому для объективной оценки надо очень хорошо подбирать вопросы.

• Нет возможности задавать дополнительные вопросы – часто человек может ответить неправильно только из-за того, что вопрос не очень хорошо поставлен (такое тоже бывает), или если он не до конца понял вопрос и из-за этого подобрал не тот ответ.

• Многие работодатели, чтобы проверить программистов, используют в ходе собеседования закрытый тест от фирмы 1С на сертификат «1C:Профессионал». Не стоит этого делать, потому что программисты, когда начинают свою карьеру, уже проходят этот тест – в нем легкие вопросы, их легко зазубрить, и сам тест не показывает реальных знаний.

Следующий вариант – практическая задача. Здесь дается задача на практику.

Плюсы:

• Можно сразу проверить синтаксис, можно проверить навыки.

Минусы:

• Практикой мы не можем проверить все знания программиста по платформе «1С:Предприятие» – например, если мы хотим проверить сеньора, то нет возможности задать ему все задачи, которые могли бы подтвердить его уровень.

Еще один методика оценки кандидатов – наличие сертификатов от фирмы «1С».

Плюсы:

• Раз сдал, то что-то знает.

• Мы всегда можем использовать данный сертификат для продажи коробок.

Минусы:

• Наличие сертификата не гарантирует, что перед вами сильный специалист, потому что даже на уровне джуна люди умудряются сдавать сертификат «Специалиста», если просто зазубрить варианты решений (тем более, никто не знает, с какого раза он сдал, и помнит ли сейчас, как решать ту или иную задачу на экзамене).

Есть еще методика «Расскажи, чем гордишься» – это когда кандидата просто спрашивают, чем он занимался и т.д. Здесь самый главный косяк в том, что человек может просто наврать о своих навыках и знаниях.

Методика «Листинг программного кода» – когда мы просим кандидата показать какой-нибудь вариант сделанного им решения. Здесь кандидат может воспользоваться «помощью зала» – кандидату могут помочь его коллеги или друзья – они могут подкинуть ему листинг собственного кода, и вы будете оценивать уже чужой труд.

Шаг 4. Анализируем результат собеседования по стажу и знаниям

В завершение, расскажу, как проанализировать результат собеседования по стажу и знаниям.

• Если вам нужен кандидат уровня middle, то смотрите разработчиков со стажем 3-4 года. Если к вам пришел на собеседование кандидат с квалификацией middle со стажем в 8 лет, не берите его, потому что за 8 лет он должен был стать уже уровнем senior – человек уже набрал уровень знаний и больше ему ничего не нужно, он не будет улучшаться, усиливаться. И в целом, он просто просиживает свои часы и будет работать только на оклад.

• У разработчика уровня senior стаж примерно будет 6-8 лет, как минимум.

Вопросы

Есть ли статистика зарплат по Москве и Санкт-Петербургу? И есть ли наблюдения о том, что сеньор из региона знает что-то лучше, чем сеньор из Москвы/Питера или наоборот?

По зарплатам – если смотреть по Москве, то junior 40-60 тысяч рублей, middle 80-140 тысяч рублей, а middle-senior 140-170 тысяч рублей, а программистов уровня senior можно начинать искать, предлагая зарплату 180 и выше. Недавно разговаривал с одним из своих московских клиентов, он искал программиста уровня senior, они сначала предложили зарплату 150 тысяч – не могли найти, потом предложили 200 – тоже не могли найти, и в итоге сделали 250 тысяч. Нашли сеньора, но, когда он уже должен был выйти, он позвонил и сказал, что нашел место поближе к дому. То есть найти специалиста в Москве даже на зарплату 250 тысяч не могут. По поводу навыков сеньоров в регионах – особой разницы нет, так как и в регионах есть крупные проекты, крупные клиенты и хорошие фирмы-франчайзи. Поэтому в навыках разницы нет никакой. Единственное, меняется процентное соотношение – сеньоров в Москве все-таки больше, чем в регионах. Например, если сравнивать с Воронежем или Волгоградом, то там уровень заработных плат меньше, очень мало крупных проектов, поэтому крупных специалистов намного меньше, чем в Казани. В Казани будет больше проектов, больше крупных компаний, которые могут давать разработчикам хорошие задачи, благодаря которым они получат хороший уровень знаний и опыт. Плюс в Казани уровень заработных плат все-таки выше, чем в Волгограде и в Воронеже. То есть в процентном соотношении миддлов/сеньоров есть разница, а по уровню знаний разницы нет.

Приведите пример вопросов, которые вы задаете в открытом или закрытом тесте.

Я чаще использую открытый тест. Потому что в закрытом тесте могут наврать/обмануть, плюс я могу неправильно задать вопрос, и человек выберет неправильный вариант ответа. А в сервисе у меня используется закрытый тест, т.е. у меня получается двухэтапное тестирование путем закрытого и открытого теста. Используются плюсы открытого теста, потому что человек мне сам отвечает, а от закрытого теста преимущество – то, что я время не трачу на тестирование. Вопросы – начиная с самого простого (в чем разница между структурой и соответствием – как оказалось, многие этого не знают, хотя это мелочь) и заканчивая вопросами об обменах. Вопросов очень много – какие из них самые любимые и распространенные я сказать не могу.

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

В целом, я джунов и не набираю. Я только сейчас начал набирать миддлов – я их смотрю в первую очередь по стажу. Если человеку надо, если он хочет к чему-то стремиться, улучшаться, становиться сильным профессионалом, то он будет изучать литературу и т.д. И к 3-4 годам стажа человек должен быть уже крепким середнячком. Простой пример – я нанял двух миддлов: один со стажем 4 года, у другого стаж 8 лет (в два раза разница). Но уровень знаний – одинаковый был. Обоим я поставил задачу – за три месяца подтянуть свои знания. Тот, у кого был стаж 4 года, смог подтянуть свои знания, и благодаря этому у него выросла заработная плата (когда человеку действительно больше всех надо, он стремится улучшаться, становится сильнее). Этот разработчик задавал кучу вопросов, если у него что-то где-то не получается или он чего-то не понимает и т.д., он обязательно задавал вопросы мне, коллегам и т.д. А другого разработчика я не слышал, не видел, и по истечении трех месяцев, когда я опять срез знаний проверил, я увидел, что человек никак не подтягивал свой уровень – его в принципе все устраивало и так. С первым разработчиком я до сих пор работаю – он выдает отличные показатели, а со вторым пришлось расстаться.

Важно ли для тебя при приеме на работу, как сотрудник расстался со своим предыдущим работодателем?

Нет. Это не показатель. Я при общении с человеком чувствую, стоит ли его брать или нет. А если есть какие-то сомнения, я 20 раз подумаю, а потом, скорее всего, скажу нет. Что касается его расставания с предыдущим работодателем – я не хочу быть арбитром между работодателем и им, потому что непонятно, как они расставались, и кто там на самом деле виноват. Если даже они расстались на негативе, далеко не факт, что у сотрудника все условия были прекрасные.

Оцениваете ли вы навыки группового взаимодействия – работу с трекерами, с хранилищем, с Git…

По поводу хранилища конфигураций я могу задать вопрос дополнительно, но, если опять же, брать разработчика уровня middle, middle-senior или senior – то они точно знают, как работать с хранилищем, потому что они часто участвовали в проектах, где шла групповая разработка. А что касается Git – мы сейчас сами начали использовать Git, SonarQube и т.д., но сам я его еще не тестировал, не проверял – не знаю, стоит с ним работать или нет. В целом, я не спрашиваю обычно разработчика по таким вещам. Если что, мы сами обучим, покажем и т.д.

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Оценка компетенций специалистов".