Мотивация

Решение о смене работы в это нестабильное время было для меня непростым.

В «ПиццаФабрике» мне посчастливилось задизайнить и вместе с командой реализовать систему по контролю внешнего вида пиццы. Она вывела компанию на совершенно новый уровень понимания производимой продукции и надолго стала главным news maker-ом для её PR отдела. Потом было несколько не менее удачных проектов, где мы старались сделать тяжелую работу сотрудников ресторанов менее напряжной. Но за последний год накопилось столько никак неразрешенной неудовлетворённости от работы, что захотелось бросить всё это и уйти. Уйти в компанию с более зрелым процессом продуктовой разработки и большими возможностями для развития.

Стало понятно, что настала пора нетомных вечеров.

Из Java в Go

Имея strong Java background, за эти 3 года я на ней почти не писал и вообще перестал следить за её развитием и экосистемой. На первый план вышли PHP и Go. Познав всю глубину PHP-шных глубин, я понял, что у меня просто нет столько лишних нервов, чтобы продолжать на нём писать.

Go привлёк своей внешней простотой, за которой стоят достаточно нетривиальные идеи. Особенно для тех, кто не писал на C и сразу перескочил на Java. Программируя на нём, я оценил альтернативное мнение о работе с исключениями, интерфейсами, подходах к структурированию программ и тестированию. Занятно было попробовать реализовать идеи Domain Driven Design на Go. Произошёл детокс от Java фреймворков и магии на каждом шагу. Ну и конечно куда же без новых игрушек: горутин и каналов.

За месяц до планируемого выставления резюме я провёл ревизию по тем темам, где не чувствовал себя достаточно уверенно. Перечитывал статьи по «тонким моментам» из блога Ardan Labs и их Ultimate Go Notebook. Если хотите разобраться с многопоточностью, то ваш выбор – книга «Concurrency In Go». Эти источники я выделил тем, что в них раскрывается множество концептуальных моментов о языке и многопоточности, которые почему-то отсутствуют в дефолтных книгах о языке: в них не просто описаны примеры языковых конструкций, а как и когда ими пользоваться, какие идеи за ними лежат. Это всё помогает писать идиоматичный код, не «идти против шерсти» авторов языка, получая на выходе быстрые и корректные программы.

Подготовка к собеседованиям

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

Я писал код прямо в их редакторе и поставил себе дополнительный челлендж: стараться не получать ошибки компиляции. Переходил в IDE только когда понимал, что без отладчика не получается в уме отдебажить очередное рекурсивное решение. Было интересно порешать задачи на работу со структурами данных на указателях. Поглубже погрузился в гошные приколы со строками. Шестеренки в голове реально начали скрипеть от такого, ведь на работе 90% времени только и делал, что перекладывал JSON-ы и писал простые конвертации данных. А оставшиеся 10% занимал дизайн комплексных доработок в сервисах.

Рекомендую обзавестись нормальной веб-камерой – это прямо must have для собеседований и вообще для созвонов. Свою Razor Kio я купил, когда ушёл на удалёнку. Она нормально работает с Linux и Windows.

Резюме

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

Фото

Добавляйте своё фото в резюме. Это делает его более личным, живым и выделяет вас на фоне сотен безликих cv.

Результаты

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

Ключевые компетенции

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

Я раньше работал с Clojure и ClojureScript. Это был прикольный опыт, но сейчас я сосредоточен только на Go и не хочу получать предложения о работе на том, что может и знаю. Разумно сузив список указанных технологий, вы, возможно, и получите меньше предложений, но каждое из них будет для вас более ценным.

Сразу нет

Если вы заведомо не готовы рассматривать предложения по каким-то критериям, то обязательно это укажите: есть шанс, что вас будут тревожить зря чуть реже.

Рынок вакансий

Когда резюме было размещено на HeadHunter, мне было торжественно объявлено, что есть «25 подходящих вакансий», что сперва немного напрягло. Но потом начались сообщения от работодателей о вакансиях с их корпоративных сайтов, и уверенности найти работу прибивалось. Почти везде возможна удалёнка, но некоторые ограничивают её только пределами РФ. Из новых фишечек сайта – возможность посмотреть информацию о компании и отзывы о ней на DreamJob.

Предложения

Самые высокооплачиваемые вакансии были от компаний, которые ищут людей, готовых на релокейт. Увы, на это пойти я был не готов. Потихоньку начали приходить вакансии от известных компаний и даже российского big tech.

В какой-то момент встаёт задача приоритизации собеседований: с кем начинать их прямо сейчас, а кого оставить на потом. Бытует мнение, что лучше размяться на «запасных вариантах», а желаемые оставить на конец. Соглашусь, что это неплохой вариант, если у вас много времени и вы чувствуете, что будете на первых собеседованиях сильно волноваться и тупить в банальных вещах, а потом успокоитесь, и всё пойдёт как по маслу. С этим есть только одна проблема: собеседования – это не рассказ одного и того же заученного стихотворения. В компаниях «попроще» вас вряд ли спросят то, что спросят в серьёзных, куда вы и хотели пройти. Соответственно, поступая так, вы можете потерять много времени впустую. А его можно потратить на полировку тех тем, в которых вы слабоваты. Тут я не готов дать рекомендации. Каждый должен принять решение по своей ситуации. Поверив в свои силы, я решил сразу нацелиться на самые интересные предложения.

Требования

Анализ показал, что в отличие от Java, для Golang Developer-a не требуется знание кучи фреймворков (что вообще логично, т.к. они тут не приняты). Требуются базовые навыки профессиональной разработки, опыт разработки на Go 1-3 года, знание многопоточки на нём. Микросервисная архитектура, Docker. Базовый SQL. Из технологий: Kafka || RabbitMQ, Redis || Memcache. Местами есть MongoDB. Совсем нет Oracle, почти нет MySQL, почти везде PostgreSQL.

Собеседование

В итоге, я начал одновременно собеседоваться в первые несколько big tech компаний, которые пришли с вакансиями не в инфраструктурные проекты. Остальным вежливо сообщал, что возможно рассмотрю их вакансии позже. В big tech компаниях процесс собеседования как правило состоит из нескольких технических секций. Иногда разные секции могут быть объединены в рамках одной беседы, и к этому марафону нужно быть готовым. Критерии успешности прохода технического этапа могут отличаться, но лучше не рассчитывать, что какую-то секцию не страшно завалить (наверно, за исключением System Design). При планировании стоит учитывать, что собеседования могут растянуться на неделю или даже больше: всё зависит от загруженности экспертов в компании.

Скрининг

Вы созваниваетесь с техническим специалистом, и за пол часика вас прогоняют по необходимому минимуму в разных темах: golang, sql, операционные системы, Unix. Уже на этом этапе надо быть готовым написать какой-то код или SQL запрос.

Алгоритмы и структуры данных Программирование

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

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

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

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

Платформа

Тут пойдёт речь о самом Go. Я лично не встретил всякой жести, какая упоминалась в нескольких статьях на Хабре. Кому-то нравится ковыряться в этих нюансах. А для кого-то важнее получить подтверждение, что вы можете писать законченные куски кода в целом. Скорее всего, сначала пойдёт речь про базовые вещи типа структур, ссылок и значений, работы со слайсами, интерфейсами. Тут могут опять попросить написать код в том же online редакторе. Апофеозом скорее всего станет тема конкурентных вычислений. Могут попросить написать как отдельные блоки, так и целые программы, которые что-то конкурентное делают. Поэтому полезно освежить знания пакетов sync, sort, http, context, runtime и горутин с каналами.

Проектирование систем

Также известная как «System Design Interview» и пришедшая к нам из зарубежного big tech.

Часто она используется для отделения мидлов от сеньоров в компаниях, где подразумевается, что последние должны быть в состоянии создавать системы с нуля. Тут пойдёт речь о проектировании системы под требования, которые вам даст интервьюер. Подготовка к этому этапу сложнее: аналога leetcode нет. Если нет опыта проектирования систем, то даже беглое чтение литературы по подготовке к этому испытанию вряд ли поможет: опытный интервьюер скорее всего поймёт, что вы всё знаете только по верхам. Сперва я хотел описать свою подготовку и опыт участия в нём прямо в этом блог-посте, но потом понял, что материала набирается слишком много. Поэтому он выйдет отдельно (UPD: статья на Хабре).

Финал

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

Я обычно спрашиваю про:

• команду: размер, роли, кто кому подчиняется.
• процесс работы над задачами: от определения откуда они приходят до момента выкатки в прод, как вы будете вести удалённую разработку продукта (особенно важно в ситуации, когда локально проект полностью не развернуть), дежурства и прочие дополнительные активности.
• оценка работы и компенсации: как людей оценивают, какие возможности для роста, какие плюшки сотрудники получают.

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

По моему опыту, отказы на этом этапе возможны и наиболее болезненно воспринимаются. Вы и компания потратили много сил, чтобы сюда дойти и обламаться в конце всегда обиднее всего. Если на технических сессиях вы можете и сами предсказать максимально пессимистичный вердикт, если были очевидные проблемы с задачами, то тут предугадать его сложнее, т.к. остаётся только пытаться считывать его по лицу и голосу собеседующих. Более того, компании редко дают фидбэк максимально откровенно и понятно, т.к. тут всё менее стандартизировано и нанимающему менеджеру даётся полный кард-бланш на решение, а выставлять его в плохом свете не хочется. В общем, готовьтесь к ответам типа “не сработаемся”, “не видим инициативности” и прочее в духе “потому что пошёл/пошла ты н****”.

Итоги

Практика показала, что мой метод подготовки сработал: на момент написания статьи я прошёл все технические собеседования, и остались финальные собеседования с командами. Вне зависимости от результата поиска работы, могу сказать, что подготовка и собеседования взбодрили меня после ухода и придали мне уверенности в том, что дальше всё будет только лучше. Чего и вам желаю 😄