Вряд ли о собеседованиях возможно сказать что-то принципиально новое. Но, по-моему, читать и писать о них всё равно полезно: их проводят очень по-разному, поэтому чем больше понимаешь, как смотрят на них разные люди, тем лучше можешь проявить себя с обеих сторон (и как кандидат, и как собеседующий).
Кирилл Розов @kirich1409, известный многим Android-разработчикам, на нашей конференции Mobius выступал с докладом «Как пройти архитектурную секцию собеседования». А заодно на той же конференции ответил Анне Жарковой @anioutka на более общие вопросы о собеседованиях в целом, не обязательно связанные с мобильной разработкой.
По ссылкам вы уже можете увидеть обе видеозаписи, а для Хабра мне захотелось ещё и выписать текстом отдельные тезисы из его ответов. Не потому что подписываюсь под каждым словом (с чем-то можно поспорить), а как раз потому что считаю полезным видеть разные точки зрения. Смело дополняйте в комментариях своими мнениями — так точек зрения станет ещё больше, неплохой способ провести вечер пятницы.
NDA
Бывает, кандидат говорит, что вся прежняя работа под NDA, поэтому он не может ни код показать, ни проект описать. С кодом нормальная ситуация, думаю, что большая часть индустрии у нас такая. И если требуется увидеть код человека, скорее всего, нужно дать тестовое задание.
А вот про описание проекта нужно понимать, что NDA обычно не распространяется на технологический стек. Если вы работали в аутсорс-компании над проектом крупной компании, вам может быть запрещено называть заказчика или раскрывать детали имплементации, но можно рассказать, что вы работали с web-сокетами или делали сложный UI на Jetpack Compose. То есть описать, какого рода вы задачи решали, а не что конкретно делалось в рамках этих задач.
И если вы разрабатывали внутренний мессенджер, то обычно можно в целом сказать «разработка закрытого корпоративного мессенджера для 10 000 пользователей», не конкретизируя дальше.
Расслабиться
Нужно понимать, что любое собеседование — это стресс для кандидата. Можно испугаться того, что попал в какую-то большую компанию, столкнулся с тем, что не знал раньше. Все мы люди. И поэтому одна из задач интервьюера — дать человеку расслабиться. Не только кандидат должен хорошо пройти собеседование, но и человек, который его собеседует, тоже должен сделать это грамотно.
Кандидат может не пройти собеседование, но не должен уходить с такими мыслями: «Блин, меня намеренно завалили, черт пойми что было, я вообще больше туда не сунусь ни ногой». Если попался плохой собеседующий, есть повод подумать в следующий раз, идти ли в эту компанию снова, и вообще как у них обстоят дела с культурой. Так что это негативно влияет на репутацию компании — она в таком не заинтересована.
В худших случаях на месте собеседуемого можно даже быть очень наглым и сказать: «Собеседующий был не очень, возможно ли мне повторить эту секцию, но с другим человеком? Потому что вышел неприятный казус». Такое, к сожалению, бывает.
Я, например, всегда советую собеседующим: если вы в плохом настроении (например, поругались с женой) и есть возможность отказаться от проведения собеседования, лучше отказаться. Потому что все мы люди, все носим негатив с собой и начинаем переносить его на других.
Беспристрастность
Ещё один важный аспект для собеседующих: не собеседуйте людей, которых вы уже знаете. Просто потому что с ними уже складываются какие-то отношения. Хорошие, плохие — не важно. Интервьюеру очень важно быть объективным и не привязываться ни к чему.
Приведу пример стремления к объективности: я стараюсь не отсматривать резюме кандидатов и их результаты на предыдущих этапах. Если кандидаты дошли до меня — значит, они нормальные. Почему так? Потому что увидев в резюме, что человек ранее поработал в Google, Spotify, Lyft или Яндекс, можно начать завышать ожидания от человека или думать «он уже знает, о чем я его спрошу».
Либо, наоборот, может быть ситуация, когда не видишь ничего солидного: «Блин, у него три года опыта — какой он Senior? Как этого сеньора могли на предыдущем этапе оценить? Как он за три года до сеньора дотянулся?».
Интервьюеру очень важно иметь этот скилл — не привязываться к результату и оценивать человека в изоляции за час-два собеседования. Чем меньше факторов на вас влияет, тем более объективным вы можете быть и дать честную, независимую оценку.
Грейды
Весёлая эпопея нашей индустрии в том, что уровни вроде «джуниор» или «миддл» очень субъективны и зафиксированы только в рамках одной компании. То, что в одной компании вы считаетесь senior, ещё ничего не значит. Если вы сумеете найти похожую компанию, там тоже будете сеньором, но в других у вас окажется другой уровень.
А ещё эти грейды меняются со временем. В мобильной разработке, которой я занимаюсь, каждые два-три года поднимается уровень базовых знаний, которые требуют от джунов. Лет 10 назад я заходил в индустрию с определённым объёмом знаний, а по текущей планке я с таким объёмом и близко не попал бы. По той планке, которая сейчас стоит для джунов, тогда можно было спокойно идти на мидла или даже сеньора. Потому что стек знаний был меньше.
Я знаю много компаний, которые говорят «мы нанимаем только сеньоров», и скептически к такому отношусь. В случаях, когда я собирал команду для проекта, порой брал кандидатов, которые по уровню знаний не вполне соответствовали ожиданиям, но активно хотели что-то изучать и шевелили головой: я видел смысл в них вкладываться.
Если мне нужен сеньор, но выбор из «живого мидла» и «ленивого сеньора», я лучше возьму мидла. У него будет высокая мотивация, а сеньор все знает, но ему особо ничего не нужно: «У меня тут пять офферов, че мне ваш этот оффер?» Он не будет ценить возможность.
Всегда нужно помнить, что собеседование — это не только процесс оценки технических знаний, но и проверка вашей совместимости. Сработаетесь вы или нет? Есть ли компании смысл в вас вкладываться? Найм любого сотрудника, независимо от уровня — это инвестиция. Испытательный срок зачастую проходит для компании с небольшим выхлопом, если не в минус. Особенно, если компания крупная. Поэтому очень важно не только какой вы специалист, но и какой вы человек — и тут сеньор легко может проигрывать мидлу.
«Философы»
Есть люди, которые на вопрос «как что-то сделать» философски отвечают «есть куча способов», но не описывают по-настоящему детально ни один. Вообще философия — это хорошо, а способов действительно много. Но в IT нужны практики, которые могут взять и решить проблему. Хорошо, что он знает о существовании разных способов, но нужно уметь еще понять и применить их. Потому что можно прочитать много книг, но ничего не понять в них.
Свой GitHub-аккаунт
Мы особо не смотрим на наличие у кандидата GitHub. Да, на собеседование может прийти человек, который сделал популярный опенсорс-проект, которым ты сам пользуешься или хорошо его знаешь. Но это само всё подтверждает, там уже и не нужно смотреть на GitHub.
А предоставленный GitHub с какими-то своими разработками еще нужно подтвердить: как проверить, что человек действительно сам написал весь этот код, а не просто натренировался на чужом? Сам факт публикации репозитория ещё ни о чём не говорит. Требуется все равно как следует поговорить с человеком по этому коду. А если в любом случае подробно обсуждать код, тогда не так важно, на гитхабе он или нет.
Алгоритмы
Многие ругаются на «в компаниях вроде Google требуют алгоритмы».
По-моему, каждая компания может себе позволить проводить интервью так, как она это хочет и с тем, что она считает важным требованием для кандидатов. Понятно, что какой-нибудь Google или Amazon старается проверить всё, и они могут себе это позволить — у них много кандидатов, они стараются выбрать лучших. Да, к сожалению, порой это выкидывает людей, которые действительно классно знают технологии. Но таков процесс. Компания его приняла, какие-то у них причины были — может, это исторически сложилось. Я отношусь к этому нормально, если для них это имеет хоть какой-то прикладной смысл и хоть какую-то важность для оценки кандидата.
Но вот конкретно в мобильной разработке, которой я занимаюсь, как много людей применяет это на практике, кому по-настоящему требуется разбираться в алгоритмах и структурах данных? Только тем, кто глубоко занимается оптимизациями, а таких немного. Если берёшь человека ваять обычные клиент-серверные приложения, вряд ли ему это часто пригодится. А собеседование в моем понимании должно оценивать прежде всего именно те навыки, которые важны, и в которых человек проведет большую часть своего времени. Остальное может быть лишь какими-то дополнительными факторами.
Архитектурная часть собеседования
Идея доклада «Как пройти архитектурную секцию собеседования» возникла так. Я провёл немало собеседований в довольно практико-ориентированном формате, не требуя каких-то сверхъестественных вещей вроде идеального знания алгоритмов, структур данных или какого-то сферического коня в вакууме. И получилось так, что зачастую кандидаты не могут нормально пройти архитектурную секцию.
Не потому, что они ничего не знают. Что-то могут что-то нарисовать и рассказать. Но мы довольно легко можем закодить какой-нибудь Android-фрагмент, взять Compose в качестве UI, ViewModel, сделать слои и все прочее. А вот грамотно и красиво это отобразить не все могут: когда нужно показать не то, что ты умеешь закодить, а то, что ты умеешь отобразить и понимаешь связи. И возник такой крик души: «Всё, мне надоело на это смотреть, пора выйти и рассказать, как надо сделать».
Минутка рекламы напоследок
Если в этом посте вас заинтересовало, как пройти архитектурную секцию собеседования по мобильной разработке — вероятно, вам будет интересна и наша весенняя конференция Mobius, которая пройдёт в мае.
А если мобильная разработка для вас нерелевантна, так что вы дочитали из-за собеседований в целом — посмотрите на весь наш весенний сезон, в него входят и бесплатный онлайн-фестиваль TechTrain, и конференции по Java/JS/C++/тестированию.
