Собеседуем кандидата на должность Senior Software Developer

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

Итак, Senior Software Developer(aka Старший Разработчик) — это разработчик со значительным опытом(от 5 лет) и глубокими знаниями в коммерческой разработке софта. Опыт работы разработки за деньги — это необходимое, но недостаточное условие. Обязательно нужно поучаствовавать в каком-нибудь проекте уровня Enterprise, а если еще и с самого начала — вообще прекрасно, это дает незабываемый опыт и широкий кругозор. Senior от Middle отличается прежде всего тем, что может довести любую задачу до состояния production-ready. Он четко знает, что можно сделать, а что нельзя. Способен уловить момент, когда в ПО пора делать рефакторинг или просто переписывать с нуля. Пишет достаточно качественный код без критических и архитектурных ошибок.

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

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

Здесь единственно правильный ответ — непосредственный будущий начальник aka Team Lead. Частая ошибка — собеседовать по 2-3 человека со стороны собеседующего, задавая перекрестные и непоследовательные вопросы. Это все создает ненужный стресс для собеседуемого и мешает установлению психологического контакта.

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

Как я уже написал в «Целях», важно узнать сильные стороны собеседуемого, с чем он работал ранее, на чем съел собаку, какие подходы использовал, какие челенжи встретил по дороге.

Ключевые компетенции для Senior-разработчика:

Алгоритмы.
Архитектура, шаблоны проектирования.
Базы данных.
Параллельное выполнение и синхронизация работы процессов.
Основы производительности ПО.
Дебаг и логирование.

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

Очень часто собеседующие переходят на какие-то хорошо им знакомые частности, вот случаи из реальной практики:

Каким образом используя SQL удалить одну строку, если под критерии выборки попадает больше одной?
Какой командой git откатить последний коммит?
Какие методы объекта Object в Java Вы знаете? Тут могут быть другие варианты в других языках — то, что хорошо знает собеседующий.

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

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

Почему люк круглый?
Как налить ровно 4 литра воды в одно ведро, если есть два ведра — 3 и 5 литров?
Решите какую-нибудь головомку, например соберите кубик Рубика.

Проблема с такими вопросами — отсеиваются не только люди с низким IQ, но и значительная часть толковых ребят, просто не готовых к таким вопросам или находящихся под стрессом. Здесь вместо толковых ребят нередко проходят далее те, которые уже знают ответы и решения стандартных вопросов и задач.

Есть такой часто задаваемый вопрос со стороны собеседущего — «Почему Вы хотите работать у нас?». Подразумевается, что собеседуемый честно и откровенно раскроет свою мотивацию — «Хочу больше денег» или «Все лучше, чем там, где я сейчас». Но для собеседуемого такой вопрос может вызвать буквальное непонимание и он редко отвечает откровенно. Поэтому про мотивацию лучше выяснить косвенными вопросами.

Какие бывают мотивации:

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

Как работает редко нужный алгоритм XXX(например, quicksort). Зачем спрашивать то, что не нужно в повседневной работе разработчика, но гуглится за 5 секунд?
Владеете ли Вы несложным иструментом YYY(например git). Я еще не встречал разработчика, который бы не освоил базовые возможности git, нужные для повседневной работы, за день-два.
Умеете ли писать тесты. Вопрос со звездочкой. Сам процесс написания тестов — несложен, а вот научиться понимать, что именно нужно тестировать и в каком объеме — тут нужна длительная практика. На деле же достаточно одного опытного тестописателя в команде, который сможет контролировать этот процесс в эффективной манере.
Что такое Agile/Kanban/Scrum. Методологию, как будет вестись разработка, выбирает Team Lead, соответственно рядовым исполнителям знать ее досконально не обязательно, а базовые принципы постигаются за считанные дни.

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

Креативщик или Увлеченный. Его прет от самой работы, нетривиальных задач, там, где нужно что-то изобрести. Иногда получаются велосипеды, но с ростом компетенций производит весьма качественные продукты. Основная мотивация — интересные проекты и задачи.
Рутинщик. Способен выполнять весьма рутинную работу не снижая производительности со временем и не требуя какой-либо мотивации.
Супергерой. Выполнит задачу любой ценой, даже если не хватает компетенций и времени. Часто лепит из говна и палок но с ростом компетенций получается что-то более-менее приличное. Очень ценный для стартапов и требовательных начальников.
Грамотный. Его на мякине не проведешь, хайпом не обманешь, всегда старается постичь суть технологий и задач, мыслит глубоко и структурно. Ценный сотрудник в любом проекте.
Поверхностный. Нахватается умных слов, подходов, изучит(поверхностно) хайповые технологии и тулзы и пытается все это применить в проекте, насыпая большими горстями, даже если можно обойтись малым. Свойственно на заре карьеры и просто ведомым и впечатлительным товарищам.
Заложник настроения. Есть настроение — работа так кипит, что только подноси снаряды, нет настроения — больше будет делать задумчивый вид и философствовать, чем работать.
Карьерист. Четко нацелен на карьерный рост. Нет роста больше года — потенциальный кандидат на вылет.
Консерватор. Любитель стабильности и традиций, негативно относится ко всем этим новомодным штучкам, инструментам и подходам.
Манимен. Работает там, где больше платят, поэтому лояльность к компании довольно низка. Любит премии, бонусы, бесплатные ништяки и прочие финансовые мотивации.

Зачастую, у конкретного индивидуума сочетается несколько типов в различных пропорциях. Со временем типы и их пропорции у человека изменяются, а также есть индивидуумы, которые могут адаптироваться под задачи(свойственно Супергероям). Замечено, что с возрастом доля Консерватора растет у многих, Креативщик может выгореть, а Поверхностный может вырасти в Грамотного.

К сожалению, иногда у Senior-разработчиков развиваются совсем не те навыки и может испортиться характер, что сильно затрудняет взаимопонимание и эффективную командную работу.

Нередко встречаются такие состояния:

Жизнь — тлен. Иногда бывает так, что написанный код не идет в production по каким-то причинам (например по бизнес-решениям) или живет недолго(стартап или неумелое управление). Это серьезно деморализует со всеми вытекающими. Тут надо не путать со здоровым обычным цинизмом ввиду опыта работы.
Постигший дзен. За годы в статичном Enterprise-проекте разработчик изучает его вдоль и поперек и у него складывается ощущение, что он теперь редкий специалист. На самом деле его навыки и умения за пределами этого проекта почти не стоят ничего, налицо переоценка своих возможностей разработчиком.
Недооцененный и неуверенный. Череда неудачных проектов, плохого управления и прочих рисков заставляют разработчика сомневаться в своих способностях и умениях, хотя на деле он может оказаться весьма способным и ценным сотрудником. Часто недооценивает себя по зарплате и/или должности.
Переоцененный. В контраст недооцененному и неуверенному этот индивидуум словил удачный проект или серию, который прошел крайне удачно и на этой волне сильно переоценивает свои способности и возможности.

Проблема в коротком тестовом задании(2-3 часа) в том, что по его результатам нельзя сделать никаких определенных выводов, обладает ли автор опытом разработки уровня Senior или нет. С таким же успехом Вы можете просто подкинуть монетку в воздух.

По итогам собеседования должно сложиться объективное впечатление о разработчике:

Какие у него сильные стороны.
Как он может усилить команду.
Сколько ему времени нужно для выхода на «крейсерскую скорость».
Насколько желаемая зп соответствует вышеуказанным пунктам.
Есть ли психологический контакт и совместимость с командой.

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

P.S. Все моменты в одной статье не изложишь, поэтому если у Вас есть вопросы или хотите что-то обсудить — пишите в комментариях или на email.

10 комментариев

Аккаунт удален

11.12.2019

Комментарий недоступен

Ответить

Sergey Rastorguev

Частенько бывает такое: человек работает долго, таски свои делает, годков ему уже накапало достаточно. Его бац и "повышают" до сеньора. У него ничего не поменялось, работать он лучше не стал но тайтл имеет. В другой компании могут дать тайтл вместо денег. Вот тебе, Вася, ведро гемороя и шилдик. Иди, Вася, не подведи!
Даже деньги не показатель, неоднократно видел как зарплаты 2х сеньоров отличались в 1,5-3 раза. Это никак не связано с колличеством пользы, которую они приносили.

Именно по этому 90% синьоров можно и нужно называть мидлами. Ну либо вообще не обращать внимание на шилдики: хоть горшком назови... но тогда нужно знать как сильного программиста назвать...

если сеньор это тот кто любую задачу доведет до прода то:
А) кто такой мидл и чем он лучше джуна?
Б) как "рутинщик" сможет довести нечетко поставленную задачу до прода?

в типажах каша. Вызванная странным делением на сеньоров и мидлов. Типажи это многомерная история.

По самому собесу сеньоров:
1) узнаем что делал
2) узнаем границы компетенции по фундоментальным темам.
4) узнаем мотивацию.

Смотрим как эти качества могут усилить команду. Решит ли он те вопросы, которые стоят перед командой.
Продаем это видиние кандидату. Чтобы он сам хотел прийти к вам в команду.
Уходим "думать" если решили брать, он весьма вероятно согласится.