Реальный опыт смены работы: 1200 откликов, 10 собеседований, 4 оффера. Узнайте, что действительно помогло — не DSA, а проекты и умение говорить. Начните готовиться уже сейчас.
Я начну с числа, которое большинство не решается произнести вслух. 1200 откликов. Именно столько заявок я отправил за 3–4 месяца, пытаясь перейти из сервисной компании в продуктовую. У меня были таблицы, сохранённые поиски и вкладки браузера, которые я обещал себе закрыть завтра. Некоторые ночи я отправлял отклики в 23:00, чтобы выполнить дневную норму. Из 1200 я получил около 10 приглашений на собеседования. Из 10 — 4 оффера. Отклики открыли мне дверь. А что происходило внутри — об этом эта статья.
В моей предыдущей компании я работал над многими вещами, но один проект всплывал буквально на каждом собеседовании. У нас был Python-модуль для парсинга файлов ASAM MDF. Бинарные логи с автомобилей и датчиков, часто гигабайтного размера. Парсер был мучительно медленным: около 8 минут на загрузку одного файла. Настолько медленным, что ты запускаешь его, идёшь обедать и надеешься, что к возвращению всё готово. Я переписал его на Rust. Время загрузки упало с 8 минут до 12 секунд. Ускорение в 40 раз на файлах гигабайтного размера.
Каждый интервьюер останавливался, как только я упоминал об этом. Вопросы были настоящими инженерными, а не шаблонными: «Почему Rust, а не Go или C++?», «Как ты профилировал узкое место?», «Какая была стратегия тестирования при переписывании такого критичного модуля?», «Что бы ты сделал иначе сейчас?». Я тратил 20–30 минут только на этот проект. Не потому что меня жёстко допрашивали, а потому что это был искренний разговор двух людей, которым небезразлична задача.
Почему это сработало: я жил этим. В процессе переписывания я натыкался на стены, которые требовали дней на решение. Контекст, неверные пути, конечное решение — всё это хранилось в голове. Когда задавали уточняющий вопрос, ответ был просто там. Это невозможно подделать. Первый же уточняющий вопрос мгновенно раскрывает учебный проект. Настоящая работа в реальных ограничениях даёт глубину, которую не воспроизвести никакой подготовкой.
Два пет-проекта, которые вызвали искреннюю реакцию у интервьюеров:
Ни один из них технически не сложен. Senior-разработчик мог бы собрать оба за выходные. Но интервьюеры всё равно удивлялись — не из-за кода, а из-за идеи и того, как я о них рассказывал. Когда я описывал FreeShare, я не говорил «это приложение для обмена файлами». Я рассказывал историю: тот раздражающий день, когда каждый способ передать файл казался нелепым; первая версия, которая почти работала; момент, когда всё наконец щёлкнуло; люди, которые попробовали, и их отзывы. У этой истории есть форма. Её интересно слушать.
Большинство разработчиков делают пет-проекты, чтобы «набить резюме», и это заметно. Ещё один todo-лист, ещё одна панель погоды, ещё один клон туториала. Нет ничего плохого в обучении, но на собеседовании нужно то, о чём можно говорить как человек, а не зачитывать по пунктам. Todo-лист без истории — это просто todo-лист.
Я пишу на dev.to и поддерживаю GitHub в разумной активности. Я упоминал об этом на собеседованиях, и случилось неожиданное. Один интервьюер листал мой GitHub прямо во время созвона и остановился на репозитории, о котором я почти забыл. Другой читал одну из моих статей до того, как мы вообще поговорили. Я не призываю строить личный бренд. Я говорю, что у большинства разработчиков нет ничего публично видимого: ни репозиториев, которые стоит посмотреть, ни статей. Планка для выделения здесь реально низкая, потому что почти никто не утруждается.
Последовательная история GitHub не обязана быть идеальной. Она просто должна показывать, что вы реально пишете код вне работы. Несколько постов в блоге демонстрируют, что вы умеете ясно объяснять технические идеи. Это сигналы, которые интервьюеры замечают, даже если не говорят об этом вслух. Не нужно становиться вирусным. Нужно просто существовать публично и быть последовательным.
Этот пункт спорный. Честно предупреждаю. Во время собеседований по коду я иногда намеренно делал небольшую ошибку. Не логическую. Что-то крошечное: несовпадение имени переменной, крайний случай, который я «забыл» на секунду. Затем я сам замечал её, вслух, исправлял за 10 секунд и продолжал. Почему? Потому что отладка под давлением — реальный навык, и большинство собеседований его не проверяют. Если вы пишете идеальный код молча и он работает, интервьюер узнаёт, что вы можете решить эту конкретную задачу. Если вы ловите свою ошибку на середине объяснения, вы показываете, как работает ваш мозг, когда что-то идёт не так. Это более ценно.
Правило простое: это работает только после того, как вы уже произвели сильное впечатление. Я делал так только в конце собеседований, после того как обсуждение проекта прошло хорошо. Если вы и так с трудом справляетесь, а сверху добавляете видимую ошибку, будет только хуже. Этот трюк сработал для меня на нескольких собеседованиях. Я не видел, чтобы кто-то ещё о нём писал.
Я не силён в DSA. Я практиковался ровно настолько, чтобы не опозориться: задачи среднего уровня, распространённые паттерны, просто чтобы оставаться в игре. Но на coding-раундах решающим было никогда не молчать. Когда я пишу код на собеседовании, я говорю постоянно. Я объясняю, почему выбираю подход, прежде чем его писать. Упоминаю сложность. Говорю вслух, когда в чём-то не уверен, и затем рассуждаю, отталкиваясь от того, что знаю. Если я в тупике, я говорю «я в тупике» и начинаю рассуждать.
Интервьюеры не просто проверяют, получите ли вы правильный ответ. Они также спрашивают себя, хотят ли они с вами работать. Молчаливые кандидаты, которые в итоге выдают корректный код, остаются загадкой. Кандидаты, которые думают вслух, — это известная величина. С ними можно представить совместную работу. Разрыв, который можно сократить хорошей коммуникацией во время coding-раунда, больше, чем многие думают. Особенно если вы не будете лучшим решателем алгоритмических задач в комнате.
1200 откликов были необходимы. Практика DSA была необходима. Но ни то, ни другое не конвертировало собеседования в предложения. Это сделали вещи, о которых я мог говорить 30 минут не замолкая. Переписывание на Rust, через которое я прошёл по-настоящему. Пет-проекты, рождённые из реального раздражения. Два года публичных статей и кода, показывающие, что я занимаюсь этим последовательно.
Когда кто-то спрашивает о том, что вы действительно создали и что вам небезразлично, вы не готовите ответ. Ответ просто там. Это нельзя сократить. Можно только начать строить это сейчас, чтобы материал был готов, когда придёт время поиска работы. Работайте над тем, что можете защитить. Остальное приложится.
Я пишу это, потому что потратил много времени во время поиска, желая, чтобы кто-то написал это для меня. Если вы сейчас в процессе перехода или планируете его — оставьте комментарий.
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →