Как сеньор и тимлид собеседует других сеньоров

Анна Жаркова

---

Lead Mobile Developer в компании Usetech. Пишет приложения нативно под iOS (Swift/Objective-C) и Android (Kotlin/Java) и кросс-платформенно (Xamarin, Xamarin.Forms, Kotlin Multiplatform). В мобильной разработке больше восьми лет. Тимлид и ментор. Kotlin GDE. Преподаватель в Otus на курсах iOS Basic и Pro.

Автор на «Хабре» и Medium (SwiftUI, Kotlin Multiplatform, iOS). Пишет статьи, выступает на конференциях и митапах, (Mobius, Ontico, MobiFest, Android Worldwide, Swift Heroes, Podlodka Android и iOS и так далее). Член ПК Mobius, CodeFest, Podlodka Android. Амбассадор Woman Techmakers и компании Usetech. В свободное время изучает иностранные языки (китайский и немецкий). Увлекается живописью и участвует в выставках.

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

Не требую точных формулировок

Я не сторонник стрессовых собеседований и токсичного отношения к человеку. Моя позиция простая: поступай с другими так, как хочешь, чтобы поступали с тобой. И собеседование — это не площадка для моего самовыражения. Моя задача не мериться знаниями или демонстрировать кандидату, что он знает меньше меня. Собеседование проводится не для этого. Я просто подбираю специалиста на определённую позицию к себе в команду.

У нас система найма выстроена так, что о проекте и условиях рассказывают HR-специалисты. Я же занимаюсь именно технической частью и оцениваю хард-скиллы кандидатов. Прежде всего смотрю на резюме и в соответствии с заявленной в резюме квалификацией подбираю вопросы — чтобы они были посильными, но не слишком лёгкими. Если человек указывает в резюме, что знает ту или иную технологию, подразумевается, что он хотя бы своими словами может описать, как с её помощью реализовать какое-то решение.

Если человек указал, что он что-то делал, но не может об этом рассказать даже на уровне: «Нашёл готовое решение в интернете и скопировал», — это очень странно. Я по себе знаю, что все мы любим Stack Overflow и активно им пользуемся.

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

Не провожу лайвкодинг-сессий

Я не сторонник лайвкодинга, потому что это большой стресс для кандидата. И очень часто человек просто не успеет всю задачу решить за время собеседования. Да и я не могу себе позволить выделять 3–4 часа и ждать, пока кандидат справится с кодом. А именно столько займёт самое простое задание для сеньора — что-то же более мелкое будет просто бесполезным.

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

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

Изучаю GitHub-профиль кандидата и даю тестовое

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

Когда-то и у меня профиль на GitHub выглядел примерно так же — там были лишь примеры старше пяти лет, какая-то ерунда, которую я писала, самостоятельно изучая Android-разработку ещё в 2014–2015 годах. Тот мой профиль уж точно не соответствовал сеньорской должности.

Поэтому я просила дать мне тестовые задания — и где-то мне отказывали, говорили, что смотрят только на GitHub. Сейчас, когда я вижу, что у человека нет пет-проектов или репозиториев с примерами в GitHub/Bitbucket, даю ему тестовое. Или если на собеседовании у него возникли проблемы с теорией, я даю кандидату шанс и возможность проявить себя на практике — ведь эти проблемы могут возникать из-за стресса.

И я не понимаю, когда в подобной ситуации кандидат отказывается от тестового, говорит, что не будет его делать: на вопросы не ответил, примеров кода тоже нет — по каким ещё тогда признакам принимать решение. Были случаи, когда писали эйчарам отказы с формулировкой: «Ваш интервьюер не смогла меня мотивировать на выполнение тестового». Особенно странно, если я, как тимлид, подбираю людей к себе в команду и соискатель это знает, но всё равно реагирует подобным образом. Ведь интервью — это не только проверка знаний и навыков, но ещё и показатель того, насколько адекватно кандидат оценивает и воспринимает свою будущую работу.

Даже если вы собеседуетесь на должность сеньора, у вас огромный бэкграунд в технологиях, крутые пет-проекты, инновационные коммерческие решения, вас всегда ждёт куча рутинных задач — и не все из них можно повесить на джунов, пусть даже они и способны с ними справиться. Эту рутину придётся делать и вам, не получится просто сидеть сложа руки и ждать, когда прилетит настоящая сеньорская задача. Иначе и джуны повыгорят от нагрузки, и менеджер от накала — ведь работа не будет делаться, заказчики будут требовать крови менеджера, а менеджер — крови тимлида.

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

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

Но ведь не в каждом проекте можно незнакомого человека допустить до пробного дня. Предположим, на проекте есть определённый уровень секретности или он содержит элементы коммерческой тайны. И как подпустить человека с улицы к такой работе — ведь его сначала должна проверить служба безопасности.

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