Всем привет! Меня зовут Илья, и я провожу собеседования *хлоп-хлоп-хлоп*. Сейчас работаю на позиции Principal iOS Engineer в inDriver, мой фокус смещен в сторону технических собеседований. До этого руководил мобильной разработкой в «Альфа-Банке» и был кем-то вроде нанимающего менеджера. Это тот человек, который говорит финальное слово по кандидату и определяет, какую циферку написать в оффере. Помимо «рабочих» собеседований, иногда провожу интервью на аутсорсе, а также помогаю разработчикам к ним готовиться.

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

Как понять, что пора менять работу?

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

• Хочу больше денег. 

• Не знаю, куда расти. 

• Неинтересные задачи. 

• Хочу в более крупную компанию. 

• Не нравятся процессы. 

• Не нравится продукт. 

• Слабая команда.

• Хочу другой стек. 

• И много чего еще. 

В этом вопросе прячется много нюансов. Буду ли я счастлив, если получу +20% к окладу? Что я получу, если буду работать в крупной компании? Что потеряю, если уйду с текущего места? Это те вопросы, которые надо задать самому себе, как только вы ощутили потребность в смене работы.

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

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

Я рекомендую потратить время на рефлексию и определить для себя, что важно, а что не очень. Это поможет не ошибиться в выборе и принять правильное решение. Самый простой способ отделить причину от следствия — попробовать исправить проблему, хотя бы в воображении. Останетесь ли вы на текущем месте, если получите +20% к окладу или к вам в команду выйдет сеньор, который всему научит? Будет ли этого достаточно или нужно что-то еще? Можно попробовать составить список, в каком случае я не буду уходить из компании. Например:

• Мне повысят ЗП на 20%.

• Сеньоры будут меня учить. 

• Печеньки будут вкуснее, а трава зеленее.

Когда с самим собой мы определились, следующий шаг — встреча 1 на 1 с вашим лидом. Обговорите основные переживания — возможно, у компании есть возможность закрыть ваши потребности. В таком случае выигрывают все: компания не теряет вас, а вы получаете желаемое. 

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

Вопросы для саморефлексии

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

Заранее подумайте над ответом на вопрос: «Почему вы сейчас рассматриваете предложения о работе?». Этот вопрос вас, скорее всего, сначала спросит HR, а потом будущий руководитель. Пожалуйста, не отвечайте на него из серии: «Я просто пособеситься пришел» или «Да я вообще не особо работу ищу». Есть вероятность поставить крест на всех ваших собеседованиях и потерять интерес со стороны работодателя. Зачем тратить время и ресурсы на кандидата, который не заинтересован к нему устраиваться?

Часто на этот вопрос отвечают сразу про деньги, например: «Я пришел за деньгами». Такой ответ может повесить на вас маркер «Только финансовая мотивация», что не всегда хорошо. Зачем работодателю сотрудник, которого через 3 месяца перекупят и он уйдет? Если вы зарекомендуете себя как проактивного и вовлеченного разработчика, ту же самую зарплату вам дадут гораздо охотнее, а вполне возможно большую сумму. Чем больше работодатель хочет вас нанять, тем охотнее он идет вам на встречу.

Мой любимый вопрос на финальном собеседовании: «Расскажи, что для тебя компания мечты?». Тут нет правильного или неправильного ответа, но через него я могу понять, что для кандидата важно на самом деле. Часто на этот вопрос отвечают в материальной плоскости: спортзал в офисе, кофе с печеньками, удобное кресло и так далее. Я бы рекомендовал размышлять более возвышенно, например: команда, культура, продукт, процессы и все в таком духе. Этот вопрос полезен всем: вы понимаете, что важно вам, интервьюер понимает, как более выгодно преподнести вакансию, чтобы вас заинтересовать.

Вот еще пара вопросов, о которых точно стоит подумать перед выходом на рынок: 

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

• О каких фичах я могу рассказать? Если вам задали этот вопрос, а вы к нему хорошо подготовились, это возможность пустить разговор по выгодному руслу. Советую подготовить 2-3 фичи, которые вы делали и которыми гордитесь. Неважно, что это — подняли CI, внедрили архитектуру или сделали классную табличку в 120 fps (ну вдруг). Если считаете, что здесь вы молодец, рассказывайте об этом обязательно. Однако нужно быть готовым пойти в технические тонкости реализации. Например, рассказать, что конкретно вы делали, как работает UITableView, констрейнты, как верстать фреймами и так далее. 

С чего начать поиск работы?

Любой поиск работы на рынке начинается с резюме. Возникает вопрос: нужно ли писать классное резюме? Коротко: если хотите — пишите. Если нет, то нет. Приведу пример.

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

Но совсем забивать на резюме я бы тоже не рекомендовал. Можно просто описать основной стек технологий, с которым вы работаете, опыт в годах, список компаний и ваши основные обязанности. Это поможет собеседующему понять, о чем с вами беседовать. Только, пожалуйста, без фраз «проактивный, целеустремленный, уверенный пользователь ПК».

Резюме подготовили, теперь пришла пора его опубликовать. Каждый раз, когда вы выходите на рынок в открытую, помните о двух вещах. Первая, достаточно капитанская: если вы выкладываете ваше резюме на HeadHunter, скорее всего, на нем сидят рекрутеры из вашей компании. Это их работа — мониторить новые резюме. А тут ваше резюме вдруг стало новым. Так что, если вы решили идти этим путем, будьте готовы к тому, что скоро к вам прибежит тимлид. И скажет, что ему HR передали, что вы выложили свое резюме на HH, и что вообще за фигня тут происходит.

Вторая вещь — если ваш тимлид не обходит стороной различные лидовские комьюнити, будьте готовы, что ему может написать лид или HR компании, куда вы собираетесь. Что-то вроде: «Тут твой разраб к нам на собес пришел. Что о нем скажешь?». Комьюнити разработчиков само по себе маленькое, а комьюнити лидов еще меньше. Это надо понимать и держать в голове.

Техническое собеседование

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

Немного про алгоритмы. На собеседовании не всегда просят перевернуть дерево. Но знать базовые алгоритмы все равно полезно. Вас могут спросить про строки и операции над ними, связанные списки, бинарный поиск, жадные алгоритмы, динамическое программирование, DFS/BFS, sliding window и так далее. Список достаточно большой и если вы планируете собеседоваться в крупные зарубежные компании, вам точно придется потратить пару десятков часов на LeetCode.

Если дела обстоят проще, есть минимум, который желательно знать всем: алгоритмическая сложность, бинарный поиск, операции с массивами и словарями, хеш-таблицы. Вне зависимости от того, как часто вы вращаете деревья, с массивами и словарями вы работаете часто. Нужно хорошо понимать, чем отличается вставка в начало и в конец массива, что такое коллизии хеш-таблиц, hash-flooding, hashable в Swift и так далее.

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

В целом, этого будет достаточно. Но если у вас проснулся аппетит — покупаем подписку на LeetCode (160 долларов — хорошая мотивация не забросить все это через неделю) и начинаем решать задачки. Если вы раньше никогда этого не делали, фильтруем задачи с уровнем easy и сортируем их по полю acceptance. Так вы гарантированно начнете с легких задач, которые решаются буквально в лоб. Если же вы понимаете, что даже на них застреваете, не спешите ставить на себе крест. На помощь придет YouTube и куча индусов, которые фанатеют от записи разбора задач с LeetCode на видео. Объясняют на плохом английском, зато с рисунками.

Итак, перейдем к части про платформу. Расскажу про некоторые часто задаваемые вопросы по Swift и iOS из моей практики.

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

Value и reference типы 

• В чем разница?

• Что такое вообще «передача по значению», копирование и указатель? 

• Какие еще типы данных передаются по значению?

• Что такое inout, когда его надо использовать и как работает?

• Что такое ключевое слово mutating, и самое важное как оно работает внутри? Создает новую структуру? Меняет текущую? 

Алокация в памяти

• Где хранятся value типы, а где — reference?

• Что такое стек и куча, в чем особенности каждой из них и как они работают?

• Всегда ли структуры и value типы хранятся в стеке? Сколько вмещает в себя стек?

Диспетчеризация

• Что это вообще такое? Какие виды бывают? 

• Как связаны диспетчеризация и наследование? 

• Как работает статическая и динамическая диспетчеризация?

• Чем отличается Table dispatch от message dispatch?

• Кто обрабатывает message dispatch? 

• Зачем нужен final и как он работает? 

• Что такое Whole module optimization?

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

2. Следующее поле для дискуссий — управление памятью.

Начнем с простого — с MRR. Говорим стандартную фразу: «когда мой дед под iOS писал, тогда использовали MRR, но я не помню, маленький был» и рассказываем про ручное управление памятью, что помним. Retain увеличивает счетчик ссылок, Release уменьшает, Autorelease уменьшит, но попозже. Далее можно и про Autorelease pool поговорить: что такое, зачем нужен, когда нужно использовать в Swift.

На ARC начинается самое интересное. Strong, weak, unowned — что такое, когда использовали, для чего, с какими проблемами сталкивались. Дальше можно углубляться, рассказывать, как слабые ссылки реализованы, что такое side таблицы, зачем они нужны, какую проблему решают. Почему unowned ссылки работают быстрее, чем weak ссылки. Из-за чего падает unowned, а unowned_safe отличается от unowned_unsafe. Эффектно завершить ответ на вопрос про управление памятью поможет понимание того, как ARC работает внутри. Здесь надо будет залезать в исходники Swift, например, сюда. Там и про реализацию счетчика ссылок, и про Heap object, и про state машину у объектов. 

3. Hit Testing и Responder Chain. Тут не очень много подводных камней. Стандартной документации и немного практики будет достаточно. Начинать советую издалека — с UITouch и UIGestureRecognizer: что это такое, как работает, какие виды бывают.

Потом можно переходить к первой части процесса обработки нажатий, то есть к Hit Testing. Он работает достаточно просто: методы sendEvent, hitTest, pointInside. Читаем, запоминаем документацию и переходим к практическим вопросам. Они, как правило, касаются области нажатий.

За Hit Testing следует Responder Chain, как бы обратный процесс. Поиск того, кто наше нажатие будет обрабатывать. Также открываем документацию и разбираем методы: next, target(forAction), canPerformAction, fordwardInvocation, forwardingTarget.

После этого переходим к UIControl и паттерну Target Action. Важно понимать, как Target Action дружит с Responder Chain и в чем их отличия. Вишенкой на торте станет понимание того, как взаимодействуют Responder Chain и UIGestureRecognizer.

Финальное собеседование

Основная задача финального собеседования — познакомиться с руководителем. Плюс замер софт скиллов, сопоставление ожиданий и возможностей. Этап не требует какой-то жесткой подготовки, так как речь пойдет про вас и ваш опыт. Но если вы подготовите ответы на следующие вопросы, это может помочь вам и собеседующему провести встречу более эффективно:

1. Почему вы пришли в разработку? Этот вопрос проверяет вашу мотивацию. Он помогает лучше понять, что именно вас привлекает в разработке, и может ли компания вам это предложить.

2. Куда хотите развиваться? Это история про ваше развитие. Если вы настойчиво через год хотите перейти в лиды или продакты, работодателю важно это понимать и сопоставлять свои возможности. 

3. Расскажите о самой интересной фиче, которую приходилось делать? Из ответа на этот вопрос можно многое понять о человеке и его взглядах на мир. Собеседующий может обращать внимание на то, какие слова вы используете, говорите ли вы только о себе или прячете свои успехи за спиной командного «мы». В общем, большое поля для построения разного рода гипотез. 

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

5. Есть ли у вас вопросы к нам? Может показаться, что этот вопрос больше из вежливости. Но это не всегда так. То, что вы будете спрашивать о компании может говорить о том, что вам действительно важно и интересно. Лично я всегда обращаю внимание на то, что и как кандидат спрашивает. Так что советую подготовиться, выписать 5-10 вопросов, о которых хотели бы поговорить.

Оффер в кармане. Что дальше?

Все собеседования позади. Оффер у вас на руках, до выхода на новую работу осталось совсем чуть-чуть. Осталось только принять оффер и сообщить своему руководителю об уходе. 2 основных пункта, которые стоит держать в голове:

Контроффер. С одной стороны, ситуация, когда вы хотите зарплату побольше, безуспешно обсуждали это на текущем месте, получили оффер и тут вам вдруг пошли на встречу — выглядит странно. Сразу напрашивается вопрос «А где вы раньше были». Не самая однозначная история. Где гарантии того, что это не повторится? 

С другой стороны, если вы уходите не из-за денег, и уже пытались что-то пофиксить перед выходом на рынок — плюс N денег проблему не исправят, вы также будете продолжать страдать, просто за чуть большие деньги. Так что, решать вам, лично я не фанат контрофферов, ни как сотрудник, ни как менеджер.

Расставайтесь на хорошей ноте. Бывшая работа — это как бывшая девушка или парень. Никогда не знаешь, кому захочется позвонить, когда будешь ехать в 3 часа ночи из бара.

На этом все. Задавайте любые вопросы или комментарии, с радостью отвечу на них.