> Чем должна отличаться новая компания от текущей (Go)

Короткий ответ

Новая компания должна отличаться зрелостью инженерной культуры: наличием code review, CI/CD, автоматизированного тестирования и чёткого процесса онбординга. В текущей компании эти практики могут быть формальными или отсутствовать. Также важна архитектурная зрелость - микросервисы вместо монолита, observability вместо "почини на проде руками". Ключевое отличие - системный подход к разработке, где технический долг управляется осознанно, а не накапливается.

Подробное объяснение

Основные отличия новой компании от текущей:

1. Процессы разработки - в новой компании должен быть настроен Git Flow или trunk-based development, обязательный code review, автоматические проверки линтерами и статическими анализаторами. В текущей - возможно, всё это существует, но не enforced.

2. Инфраструктура - новая компания должна иметь полноценный CI/CD pipeline: сборка, тесты, деплой. В текущей - деплой может быть ручным, через SSH и git pull.

3. Тестирование - покрытие unit-тестами, интеграционные тесты, e2e. В текущей - тесты могут быть только на критических путях или отсутствовать вовсе.

4. Observability - structured logging, метрики (Prometheus), трейсинг (Jaeger/OpenTelemetry). В текущей - логи в stdout и "посмотрим в Grafana, если есть".

5. Архитектура - новая компания должна иметь продуманную архитектуру: чёткие границы сервисов, event-driven подходы, асинхронное взаимодействие. В текущей - возможно, всё на синхронных HTTP-вызовах.

6. Управление техническим долгом - в новой компании есть процесс: backlog для техдолга, рефакторинг планируется, а не "когда-нибудь".

На практике

При переходе в новую компанию важно оценить:

• Онбординг - есть ли документация, ментор, первые задачи адаптированы под уровень.
• Code review - реально ли ревьюеры читают код, а не просто ставят approve.
• Тестовое окружение - можно ли локально поднять проект одной командой, или нужен день танцев с бубном.
• Продакшен - как выглядит выкатка: автоматический pipeline или ручные шаги.
• Коммуникация - как решаются конфликты между разработкой и продакшеном, есть ли on-call.

На собеседовании стоит уточнить: "Как выглядит типичный день разработчика?", "Что происходит после merge в main?", "Как вы отслеживаете ошибки в проде?".

Как отвечать на собеседовании

Отвечайте конкретно, с примерами из текущего опыта:

• "В текущей компании деплой занимает два часа ручных действий, хочу автоматизацию".
• "У нас нет e2e-тестов, релиз - это стресс, хочу предсказуемости".
• "Хочу работать в команде, где code review - это норма, а не исключение".

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

Что проверяет интервьюер

Интервьюер оценивает:

• Понимание инженерных практик - знаете ли вы, что такое CI/CD, observability, code review, и зачем они нужны.
• Критическое мышление - можете ли вы оценить зрелость процессов, а не просто перечислить buzzwords.
• Мотивацию - почему вы хотите уйти, что для вас важно в работе.
• Уровень самоосознанности - понимаете ли вы, чего именно вам не хватает в текущей компании.

Также проверяется, не уходите ли вы "от проблем" вместо "к возможностям" - это красный флаг.

Типичные ошибки

1. Общие фразы - "хочу больше зарплату" или "хочу интересные задачи" без конкретики.
2. Критика без конструктивности - "у нас всё ужасно, все тупые" - звучит незрело.
3. Незнание терминов - если вы говорите "хочу CI/CD", но не можете объяснить, как он устроен, это провал.
4. Игнорирование культуры - если вы говорите только про технологии, но не про процессы и людей, это подозрительно.
5. Сравнение без контекста - "в новой компании должно быть лучше" без объяснения, что именно лучше и почему это важно для вас.