Перейти к основному содержимому

Потерял работу, завалил 10 собесов, но выжил — история мидл разработчика | GoGetPodcast №13

· 21 мин. чтения
Николай Тузов — Golang
Николай Тузов — Golang

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

Вопрос 1. Расскажите о себе и вашем опыте в Go-разработке.​

Таймкод: 00:00:30

Ответ собеседника: Правильный. Глеб занимается Go довольно давно, около года-полутора назад ушёл из компании и организовал компанию в России, связанную с Go-разработкой. Продолжает активно заниматься этим, совмещая роли менеджера и программиста.

Правильный ответ:

Ответ собеседника дан на общем уровне и корректен как вступительный. Для полноценного ответа на такое вопрос на интервью стоит структурировать рассказ следующим образом:

1. Общий бэкграунд Упомяните общий стаж в разработке, какие языки и технологии использовали до Go и почему перешли именно на него.

2. Опыт работы с Go Конкретные проекты, в которых применялся Go: микросервисы, highload-системы, CLI-утилиты, инфраструктурные инструменты. Важно указать масштаб — количество RPS, объём данных, архитектурные решения.

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

  • Работа с конкурентностью (goroutines, channels, sync primitives)
  • Профилирование и оптимизация (pprof, tracing)
  • Работа с базами данных (database/sql, ORM, миграции)
  • Написание тестов (table-driven tests, fuzzing, benchmarks)
  • Сборка и доставка (CI/CD, Docker, Kubernetes)

4. Роль в команде Если есть опыт менеджмента — как в ответе собеседника — стоит подчеркнуть, что это помет глубже понимать не только код, но и процессы: code review, планирование, онбординг разработчиков, выбор технологического стека.

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

Вопрос 2. Почему кандидат выбрал именно МТС среди нескольких офферов и как прошёл процесс переговоров о зарплате?​

Таймкод: 00:13:20

Ответ собеседника: Правильный. Кандидат выбрал МТС в первую очередь из-за интересного проекта — разработка компонента кинотеатра. По деньгам везде называл примерно одинаковые суммы. Вышел на рынок с ожиданием 300к, торговался — изначально говорил 310, предлагали 280, сошлись на 300 плюс гарантированные премии (ещё ~60к сверху). Руководитель в Вайберис при увольнении смог поднять только до 300, что совпало с предложением МТС. Также кандидат смотрел вебинары с Сергеем Помошником про МТС и сложилось положительное впечатление о компании.

Правильный ответ:

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

На что обратить внимание при подготовке к такому вопросу:

1. Мотивация выбором компании и проекта Интервьюер хочет понять, что кандидат не просто «ищет работу», а целенаправленно выбирает. Стоит подготовить конкретные аргументы:

  • Интерес к предметной области (стриминг, телеком, финтех и т.д.)
  • Масштаб и технические вызовы проекта
  • Технологический стек и возможность профессионального роста
  • Культура компании, публичные выступления инженеров, блоги, open-source проекты компании

2. Переговоры о компенсации Демонстрация рыночного подхода — плюс. Хорошо, когда кандидат:

  • Знает свою рыночную стоимость (исследование рынка, данные с Хабр Карьера, Glassdoor)
  • Говорит конкретные цифры, а не «на уровне рынка»
  • Рассматривает полный пакет: оклад, премии, ДМС, обучение, гибкий график, опционы
  • Не боится торговаться, но делает это уважительно

3. Сравнение офферов Если есть несколько офферов, можно честно сказать, что сравниваете варианты по совокупности факторов: интерес к проекту, технологический стек, команда, компенсация, перспективы роста. Это показывает зрелый подход к карьере.

Вопрос 3. Что вы думаете о практике назначения джуниора тимлидом команды из джуниоров?​

Таймкод: 00:16:15

Ответ собеседника: Правильный. Данил считает, что назначение джуниора тимлидом — это убыточное решение, так как джуниор сам является узким местом, а менеджерская работа требует других навыков. Глеб соглашается, что джуниор — это финансовая нагрузка для компании, и важно быстро довести его до уровня мидла. Виталий считает, что это может быть полезным опытом для джуниора, так как развивает soft skills, а технические ошибки могут корректироваться более опытными коллегами.

Правильный ответ:

Это вопрос на управленческую зрелость и понимание командной динамики. Все три мнения, озвученные в ответе, имеют право на существование. Разберём тему глубже.

1. Почему это рискованно

  • Технический долг. Джуниор-тимлид не имеет достаточного опыта для принятия архитектурных решений. В команде из джуниоров нет внутреннего экспертного контроля — ошибки будут множиться.
  • Узкое место. Тимлид должен разгружать команду, а сам джуниор нуждается в менторстве. Получается парадокс: человек, которому нужна помощь, тратит время на помощь другим.
  • Soft skills. Управление людьми — это отдельный навык. Даже технически сильный мидл не всегда готов к этому, не говоря о джуниоре.

2. Когда это может работать

  • Временная мера. Если это осознанный эксперимент на короткий срок с поддержкой со стороны руководства.
  • Технический тимлид vs менеджер. Если джуниор выполняет роль технического лидера (code review, стандарты кода), а менеджерскую часть (1-on-1, оценки, найм) берёт на себя кто-то другой.
  • Ротация лидерства. В учебных или pet-проектах это может быть частью развития.

3. Что важно для Go-разработчика

В контексте Go-экосистемы технический тимлид должен уметь:

  • Проводить code review с пониманием идиоматического Go (эффективное использование интерфейсов, обработка ошибок, конкурентность)
  • Настраивать CI/CD пайплайны
  • Принимать решения по выбору библиотек и фреймворков
  • Профилировать и оптимизировать код

Всё это требует опыта, которого у джуниора по определению нет.

Вывод: Назначение джуниора тимлидом — это красный флаг для компании. Исключения возможны, но только при наличии сильной системы менторства и чёткого понимания рисков.

Вопрос 4. Как проходил процесс поиска работы и собеседований после ухода с первой работы? Сколько оферов получил?​

Таймкод: 00:29:36

Ответ собеседника: Правильный. Кандидат прошёл множество собеседований, часть из которых не прошёл из-за слабого решения алгоритмических задач. В большинстве мест решал задачи неуспешно. Единственный офер получил от компании Вайберис, где на собеседовании были только теоретические вопросы, а не задачи на код. Также было одно место (работару), где на собеседовании сказали «в целом подходишь», но в итоге выбрали другого кандидата.

Правильный ответ:

Ответ демонстрирует честность и самосознание — это ценно. Однако на интервью стоит дополнительно показать, что кандидат извлёк уроки из неудач.

1. Типичные причины провалов на алгоритмических задачах

  • Недостаточная практика на платформах (LeetCode, Codeforces, HackerRank)
  • Стресс на собеседовании — задача, которую дома решаешь за 15 минут, на интервью может занять час
  • Неумение думать вслух — интервьюер оценивает ход мысли, а не только результат
  • Слабое знание базовых структур данных — хеш-таблицы, деревья, графы, стеки, очереди

2. Как подготовиться к алгоритмическим секциям

  • Решать 2-3 задачи в день на LeetCode (Easy → Medium → Hard)
  • Изучить паттерны: two pointers, sliding window, BFS/DFS, dynamic programming, binary search
  • Практиковать решение задач на время с таймером
  • Проговаривать решение вслух — это критически важный навык

3. Как презентовать неудачи на интервью

Вместо «я завалил много собеседований» лучше сказать:

  • «Я прошёл через интенсивный процесс собеседований, который помог мне понять пробелы в подготовке»
  • «Я сфокусировался на алгоритмической подготовке и заметил прогресс»
  • «Я научился лучше структурировать своё мышление и коммуницировать ход решения»

4. Разнообразие форматов собеседований

Хорошо, что кандидат упомянул разные форматы. Стоит быть готовым к:

  • Системному дизайну — проектирование архитектуры сервисов
  • Live coding — написание кода в реальном времени
  • Take-home заданиям — проект на дом с дедлайном
  • Теоретическим вопросам — глубокое знание языка, платформы, инструментов

Вопрос 5. Как вы оценивали свою продуктивность на второй работе и в чём измеряли выполнение задач?​

Таймкод: 00:43:10

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

Правильный ответ:

Ответ хороший — он показывает ориентацию на результат, а не на процесс. Это зрелый подход. Разберём, как можно дополнить и углубить этот ответ.

1. Метрики продуктивности разработчика

Ориентация на «залитый в продакшн» — это правильная базовая метрика. Для более полной картины можно использовать:

  • Lead time — время от создания задачи до деплоя в продакшн
  • Cycle time — время от начала работы над задачей до завершения
  • Deployment frequency — как часто деплоишь в продакшн
  • Change failure rate — процент деплоев, вызвавших инциденты
  • Mean time to recovery (MTTR) — время восстановления после инцидента

Это метрики из фреймворка DORA (DevOps Research and Assessment), который считается стандартом для оценки эффективности инженерных команд.

2. Качество vs скорость

Важно не только быстро закрывать задачи, но и обеспечивать качество:

  • Покрытие тестами (unit, integration, e2e)
  • Количество багов, найденных после релиза
  • Качество code review — сколько замечаний, как быстро исправляются
  • Технический долг — не накапливается ли он ради скорости

3. Для Go-разработчика конкретно

В контексте Go-разработки можно измерять:

  • Производительность кода — бенчмарки, профилирование с помощью pprof
  • Качество API — соответствие REST/gRPC стандартам, документация
  • Надёжность — корректная обработка ошибок, retry-логика, circuit breakers
  • Наблюдаемость — логирование, метрики, трейсинг

4. Рост и развитие

Упоминание кандидата о том, что он стал лучше укладываться в сроки — это показатель роста. Можно дополнить:

  • Сложность задач со временем увеличивалась
  • Уменьшалась потребность в менторстве
  • Появилась возможность помогать другим членам команды
  • Улучшилось понимание бизнес-контекста

Вопрос 6. Почему вы решили уйти из компании Вайберис и что именно вас не устроило?​

Таймкод: 00:50:55

Ответ собеседника: Правильный. Кандидат решил уйти по нескольким причинам: на более приоритетный проект находили сеньоров, а его проект был неприоритетным, продакшн лежал без пользователей; менеджер обещал повышение после выхода в продакшн, но через год разработки так и не выполнил обещание; бизнес был недоволен и уволил первого менеджера, нового менеджера тоже уволили через 2 недели; кардинально менялись требования, переписывались сущности целиком, менялась концепция проекта; кандидат не видел перспектив роста — развитие бизнес-логики, фикс багов, и хотел найти интересный проект.

Правильный ответ:

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

1. Что показывает хороший ответ

  • Осознанность. Кандидат понимает, что хочет от работы: интересные проекты, рост, стабильность.
  • Профессионализм. Нет обвинений в адрес конкретных людей, только факты.
  • Конкретика. Не «мне было плохо», а «проект не выходил в продакшн год, менялись требования, не выполнялись обещания».

2. Типичные красные флаги, которые стоит распознавать

Из ответа кандидата видно несколько классических проблем:

  • Неприоритетный проект. Работа над проектом без пользователей — это риск. Нет обратной связи, нет мотивации, нет видимого результата.
  • Невыполненные обещания о повышении. Если компания не держит слово по компенсации, это сигнал о проблемах с культурой или финансами.
  • Текучка менеджмента. Два менеджера за короткий срок — признак хаоса в управлении.
  • Нестабильные требования. Постоянные переписывания и смена концепции — это потеря времени и демотивация.

3. Как говорить об уходе на интервью

Никогда не стоит:

  • Обвинять бывших коллег или руководителей
  • Говорить «меня не ценили» без конкретики
  • Упоминать конфликты или скандалы

Стоит говорить:

  • «Я искал проект с бо́льшим влиянием на продукт»
  • «Хотел работать в команде с более сильной технической экспертизой»
  • «Искал возможности для роста, которые не видел на текущем месте»
  • «Хотел работать над продуктом с реальными пользователями и метриками»

4. Для Go-разработчика конкретно

При выборе следующего места работы стоит обращать внимание на:

  • Зрелость Go-инфраструктуры в компании (есть ли внутренние библиотеки, стандарты)
  • Масштаб системы (RPS, объём данных, количество сервисов)
  • Культуру code review и тестирования
  • Наличие SRE/DevOps команды или необходимость заниматься инфраструктурой самостоятельно

Вопрос 7. Как проходил испытательный срок в МТС и почему вас уволили?​

Таймкод: 01:07:15

Ответ собеседника: Правильный. Кандидат рассказывает, что в МТС была развитая корпоративная культура, полноценный онбординг, видеоуроки от коллег, мерч, чёткие процессы. Ему дали сложную задачу — распределённое копирование больших видеофайлов между хранилищами. Задача была очень сложной, он долго разбирался, мало задавал вопросы, старался делать всё сам. Параллельно с ним пришла коллега-мидл с опытом сеньора из Озона. К концу испытательного срока руководство решило поменять микросервисы между ними. Кандидат не успел завершить задачу, начальник отдела на планёрке спросил о новом сотруднике, тимлид ответил, что за испытательный срок тот ни одной задачи не закрыл, после чего было принято решение уволить. Также сказали, что не хотят учить и им нужен крутой спец. Тимлид позже признал, что это была ошибка найма, после чего ужесточили собеседования в три раза.

Правильный ответ:

Это один из самых важных вопросов на интервью. Ответ кандидата честный и самокритичный — это плюс. Однако есть несколько моментов, которые стоит учитывать при подготовке.

1. Ошибки, которые признаёт сам кандидат

  • Мало задавал вопросы. Это критическая ошибка на испытательном сроке. Ожидание, что новый сотрудник будет самостоятельно разбираться в незнакомой предметной области — нереалистично. Задавать вопросы — это не слабость, а эффективная стратегия.
  • Долго разбирался в одиночку. Для сложной задачи распределённого копирования нужна была помощь — архитектурная консультация, разбор требований, помощь с декомпозицией.

2. Системные проблемы со стороны компании

  • Сложная задача на испытательный срок. Распределённое копирование больших файлов — это нетривиальная задача даже для опытного разработчика. Выбор такой задачи для оценки нового сотрудника — сомнительное решение.
  • Смена требований на ходу. Обмен микросервисами между сотрудниками в процессе испытательного срока — это плохая практика.
  • Оценка по количеству закрытых задач. Если задача одна и сложная, оценка по «количеству закрытых» несправедлива.

3. Как говорить об увольнении на интервью

Никогда не стоит:

  • Обвинять компанию или руководство
  • Говорить «меня несправедливо уволили»
  • Уподоблять ситуацию или врать

Стоит говорить:

  • «Я недооценил сложность задачи и не вовремя попросил помощи — это мой главный урок»
  • «Задача требовала знаний, которых у меня тогда не было, и я не смог достаточно быстро их получить»
  • «Я понял, что на испытательном сроке важно показывать прогресс инкрементально, а не пытаться сделать всё идеально в конце»

4. Уроки, которые стоит извлечь

  • Декомпозируй задачу. Даже если задача одна — разбей её на этапы и показывай прогресс каждую неделю.
  • Коммуницируй. Рапортуй о проблемах сразу, не жди дедлайна.
  • Проси помощь. На испытательном сроке вопросы ожидаемы и приветствуются.
  • Управляй ожиданиями. Если задача кажется слишком сложной — скажи об этом тимлиду и предложи альтернативный план.

5. Техническая сторона задачи

Распределённое копирование больших файлов — это интересная задача. Вот ключевые аспекты, которые стоит знать:

  • Chunked transfer — разбиение файла на части и параллельная передача
  • Checksum verification — проверка целостности после копирования
  • Retry logic — повторные попытки при сбоях
  • Rate limiting — контроль нагрузки на сеть и хранилища
  • Progress tracking — отслеживание прогресса для больших файлов

Пример простого chunked reader на Go:

func copyChunked(src io.Reader, dst io.Writer, chunkSize int) error {
    buf := make([]byte, chunkSize)
    for {
        n, err := src.Read(buf)
        if n > 0 {
            if _, writeErr := dst.Write(buf[:n]); writeErr != nil {
                return writeErr
            }
        }
        if err == io.EOF {
            return nil
        }
        if err != nil {
            return err
        }
    }
}

Вопрос 8. Как вы считаете, что должны были поступить, осознав, что не справляетесь с задачами в МТС?​

Таймкод: 01:23:17

Ответ собеседника: Правильный. Кандидат считает, что нужно было осознать, что не справляешься, и самому пойти к менеджеру, чтобы обсудить проблемы и найти решение. Либо зафиксировать, что не подходишь, и уволиться самому. Также он осознал, что старался делать задачи идеально, в то время как коллега делала их не до конца, но быстрее, и поэтому закрывала больше задач.

Правильный ответ:

Ответ демонстрирует зрелую рефлексию. Кандидат не перекладывает ответственность, а анализирует свои ошибки. Это именно то, что хотят видеть интервьюеры.

1. Проактивная коммуникация — ключевой навык

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

  • Еженедельные 1-on-1. Используй их для обсуждания блокеров, а не только статуса задач.
  • Раннее предупреждение. Если задача занимает больше времени, чем планировалось — скажи об этом сразу, не жди дедлайна.
  • Предложи альтернативы. Не просто «я не справляюсь», а «я не справляюсь, потому что X. Предлагаю Y или Z».

2. Perfectionism vs. Pragmatism

Наблюдение кандидата о коллеге, которая делала задачи быстрее и неидеально — это важный урок:

  • Done is better than perfect. В бизнесе ценность приносит работающий код в продакшне, а не идеальный код в ветке.
  • Итеративный подход. Сделай минимально рабочую версию, получи обратную связь, улучши.
  • 80/20 правило. 80% ценности приносят 20% усилий. Оставшиеся 20% ценности — это 80% усилий. На испытательном сроке важно показать первые 80%.

3. Когда стоит уйти самому

Самостоятельное решение об уходе — это признак зрелости. Стоит рассмотреть, если:

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

4. Практические шаги в подобной ситуации

Если ты понимаешь, что не справляешься:

  1. Запроси встречу с тимлидом. Обсуди конкретные блокеры.
  2. Попроси декомпозицию задачи. Разбей большую задачу на маленькие и покажи прогресс по каждой.
  3. Попроси ментора. Если в команде есть более опытный разработчик — попроси его помощи.
  4. Пересмотри приоритеты. Может быть, часть задачи можно отложить или упростить.
  5. Документируй прогресс. Даже если задача не завершена — покажи, что ты сделал: исследование, прототип, частичная реализация.

5. Как презентовать этот опыт на интервью

Это не слабость, а демонстрация роста. Структурируй ответ так:

  • «Я столкнулся с ситуацией, когда задача оказалась сложнее, чем я ожидал»
  • «Я допустил ошибку, не попросив помощи вовремя»
  • «Я извлёк урок: теперь я коммуницирую проблемы раньше и декомпозирую задачи»
  • «Этот опыт сделал меня более эффективным разработчиком»

Вопрос 9. Как вы нашли работу в МегаМаркете после увольнения из МТС и как складывается ваша работа там?​

Таймкод: 01:34:55

Ответ собеседника: Правильный. После увольнения из МТС кандидат активно искал работу, но столкнулся с проседанием рынка — 70-80% вакансий имели вилку меньше 300к, а в Авито на запрос 330к сказали, что столько он не получит. Ранее ещё до МТС он проходил собеседование в Комтех (экосистема Сбербанка), но тогда проект не нашли. После увольнения из МТС ему снова вышли из Комтеха с подходящим предложением по зарплате. В МегаМаркете он работает над заменой большого компонента системы, переписывая его с нуля. Кандидат активно внедряет практики: написал обширную документацию по проекту, организовал доску задач, настроил линтеры. Берёт сложные задачи, делает их, иногда долго, но делает. Команда состоит из сеньоров, все заняты, и он помогает своими инициативами.

Правильный ответ:

Ответ очень сильный. Кандидат демонстрирует проактивность, инициативность и зрелый подход к работе. Разберём ключевые моменты.

1. Поиск работы на рынке

Кандидат честно описывает рыночные условия. Это полезный контекст:

  • Рынок 2024-2025. Действительно, рынок Go-разработчиков претерпел изменения. Компании стали более избирательными.
  • Реалистичные ожидания. Кандидат понимает рыночную ситуацию и адаптируется.
  • Повторный контакт с компанией. То, что Комтех вернулся с предложением — это хороший знак. Значит, кандидат произвёл положительное впечатление ранее.

2. Проактивность и инициатива

Это самая сильная часть ответа. Кандидат не ждёт, пока ему скажут, что делать:

  • Документация. Написание обширной документации по проекту — это огромный плюс. Документация — это то, что часто игнорируют, но она критически важна для поддержки и онбординга.
  • Доска задач. Организация рабочего процесса показывает лидерские качества.
  • Линтеры. Настройка линтеров — это инвестиция в качество кода.

3. Работа в команде сеньоров

Это отличная возможность для роста:

  • Обучение через наблюдение. Работая рядом с сильными разработчиками, можно многому научиться.
  • Code review. В команде сеньоров code review будет более строгим и полезным.
  • Инициатива. Кандидат берёт сложные задачи и делает их — это правильная стратегия для роста.

4. Как презентовать этот опыт на интервью

Стоит подчеркнуть:

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

5. Практические советы для Go-разработчика

Если ты работаешь над переписыванием компонента с нуля:

  • Начни с тестов. Напиши интеграционные тесты на старый компонент, чтобы понимать его поведение.
  • Используй feature flags. Постепенно переключайтрафик на новый компонент.
  • Документируй решения. Используй ADR (Architecture Decision Records) для фиксации ключевых решений.
  • Профилируй. Сравни производительность старого и нового компонента с помощью pprof.

Пример настройки линтера для Go:

# .golangci.yml
run:
  timeout: 5m
  go: '1.22'

linters:
  enable:
    - gofmt
    - golint
    - govet
    - errcheck
    - staticcheck
    - gosimple
    - ineffassign
    - misspell
    - gosec
    - prealloc
    - gocyclo

linters-settings:
  gocyclo:
    min-complexity: 15
  errcheck:
    check-type-assertions: true

Вопрос 10. Как вы оцениваете увольнение из МТС и какие выводы сделали для себя?​

Таймкод: 01:52:12

Ответ собеседника: Правильный. Кандидат в день увольнения до 6 утра жёстко анализировал всё, что делал. Основной вывод — если бы у него были лучше навыки, он бы прошёл испытательный срок без проблем. Проблема была именно в навыках, а не только в обстоятельствах. Он осознал, что старался делать задачи идеально, в то время как коллега делала их не до конца, но быстрее, и поэтому закрывала больше задач. Также понял, что нужно задавать больше вопросов и не бояться обращаться за помощью.

Правильный ответ:

Ответ демонстрирует глубокую рефлексию и готовность учиться на ошибках. Это именно то, что ценят интервьюеры. Разберём выводы кандидата и дополним их.

1. Анализ причин увольнения

Кандидат правильно разделил причины на два типа:

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

Важно, что кандидат не перекладывает всю ответственность на обстоятельства, а признаёт свою роль.

2. Ключевые выводы кандидата

  • Done is better than perfect. Перфекционизм — это ловушка. В бизнесе важнее показать результат, чем идеальный код.
  • Коммуникация. Задавать вопросы — это не слабость, а эффективная стратегия.
  • Просьба о помощи. Обращаться за помощью — это нормально и ожидаемо.

3. Дополнительные выводы, которые стоит сделать

  • Управление ожиданиями. Важно не только делать работу, но и показывать прогресс. Даже если задача не завершена — покажи, что сделано.
  • Декомпозиция. Большие задачи нужно разбивать на маленькие и показывать результат по каждой.
  • Приоритизация. Не всё одинаково важно. Сначала — критичное, потом — остальное.

4. Как использовать этот опыт для роста

Увольнение — это не конец, а начало нового этапа. Вот как можно использовать этот опыт:

  • Закрой пробелы в знаниях. Определи, каких навыков не хватало, и работай над ними.
  • Практикуйся. Решай задачи на LeetCode, участвуй в open-source проектах, делай pet-проекты.
  • Развивай soft skills. Коммуникация, тайм-менеджмент, работа в команде — это не менее важно, чем технические навыки.

5. Как говорить об увольнении на будущих интервьюях

Структура ответа:

  1. Контекст. «Я работал над сложной задачей распределённого копирования файлов»
  2. Проблема. «Задача оказалась сложнее, чем я ожидал, и я не попросил помощи вовремя»
  3. Вывод. «Я понял, что нужно раньше коммуницировать проблемы и декомпозировать задачи»
  4. Результат. «Сейчас я применяю эти уроки на новой работе и вижу прогресс»

6. Позитивный финал

Важно закончить на позитивной ноте:

  • «Этот опыт сделал меня сильнее»
  • «Я благодарен за этот урок»
  • «Теперь я лучше понимаю, как работать в команде и как показывать результат»

Вопрос 11. Какие у вас дальнейшие ожидания и планы по карьере?​

Таймкод: 01:56:43

Ответ собеседника: Правильный. Кандидат очень доволен текущим проектом в МегаМаркете, говорит, что у него лучший тайм на свете. Единственный момент — планируется дежурство, что зависит от того, насколько хорошо команда сделает проект. Он видит себя сеньором в этой же компании через год-два. Также он отметил, что после МТС проходил много собеседований, сложность которых выросла, и многие не брали из-за высоких зарплатных ожиданий. Он не считает работу в МТС приговором — у него было много хороших моментов, которые описал в Telegram-канале, и он подчеркивает, что то, что не подходит одному, может быть отличным местом для другого.

Правильный ответ:

Ответ позитивный и реалистичный. Кандидат показывает зрелый подход к карьере и понимание рынка. Разберём ключевые моменты.

1. Текущая ситуация

Кандидат доволен работой — это важно. Удовлетворённость работой напрямую влияет на продуктивность и качество кода.

  • Интересный проект. Переписывание компонента с нуля — это отличная возможность для роста.
  • Команда сеньоров. Работа с сильными разработчиками ускоряет профессиональный рост.
  • Проактивность. Кандидат не ждёт, а сам инициирует улучшения.

2. Карьерные планы

Цель «сеньор через год-два» — реалистичная и достижимая. Вот что нужно для этого:

  • Техническая экспертиза. Глубокое знание Go, стандартной библиотеки, популярных фреймворков и инструментов.
  • Аритектурные навыки. Умение проектировать системы, выбирать подходящие паттерны, оценивать trade-offs.
  • Лидерство. Наставничество младших разработчиков, code review, участие в принятии технических решений.
  • Влияние на продукт. Понимание бизнес-контекста, предложение улучшений, участие в планировании.

3. Дежурства

Упоминание о дежурствах — это нормальная часть работы в продуктовой компании. Вот как к этому подготовиться:

  • Наблюдаемость. Настрой логирование, метрики и алерты.
  • Runbooks. Документируй процедуры реагирования на инциденты.
  • Postmortems. После каждого инцидента проводи анализ и фиксируй выводы.

4. Рыночная ситуация

Кандидат правильно оценивает рынок:

  • Сложность собеседований выросла. Компании стали более избирательными.
  • Зарплатные ожидания. Важно быть реалистичным, но и не занижать свою стоимость.
  • Опыт МТС — не приговор. Это важный момент. Одно увольнение не определяет всю карьеру.

5. Как презентовать карьерные планы на интервью

Структура ответа:

  1. Краткосрочные цели (6-12 месяцев):

    • «Хочу глубже изучить архитектуру распределённых систем»
    • «Планирую взять на себя больше ответственности в code review»
    • «Хочу участвовать в проектировании новых сервисов»

  2. Среднесрочные цели (1-2 года):

    • «Вижу себя в роли технического лида команды»
    • «Хочу менторить младших разработчиков»
    • «Планирую развиваться в сторону системной архитектуры»

  3. Долгосрочные цели (3-5 лет):

    • «Интересна роль архитектора или технического директора»
    • «Хочу влиять на техническую стратегию компании»
    • «Планирую делиться знаниями через конференции и блоги»

6. Рекомендации для роста до сеньора

  • Изучи внутренности Go. Runtime, scheduler, garbage collector, memory model.
  • Практикуй системный дизайн. Читай «Designing Data-Intensive Applications» Мартина Клеппмана.
  • Участвуй в open-source. Контрибьюты в популярные Go-проекты — отличный опыт.
  • Пиши технические статьи. Это помогает структурировать знания и показывает экспертизу.
  • Выступай на конференциях. Даже на внутренних митапах — это развивает коммуникативные навыки.