Вряд ли о собеседованиях возможно сказать что-то принципиально новое. Но, по-моему, читать и писать о них всё равно полезно: их проводят очень по-разному, поэтому чем больше понимаешь, как смотрят на них разные люди, тем лучше можешь проявить себя с обеих сторон (и как кандидат, и как собеседующий).
Кирилл Розов @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++/тестированию.
