Что интересного вы делали и чему научились на ошибках

Что проверяют

Умеете ли вы признать ошибку и сделать из неё вывод, и заодно ваш реальный уровень: по тому, какую ошибку человек считает поучительной, видно, с какими задачами он работал. Для Go ждут случай из практики языка, а не общие слова про ответственность.

Как отвечать

Возьмите один случай и разложите его: что сломалось, как узнали, в чём была причина, что изменили в коде и в процессе. Темы, которые в Go звучат достоверно:

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

Вывод формулируйте как механизм, а не как намерение: добавили прогон с -race в сборку, включили линтер, закрыли случай тестом, ввели обязательный контекст с таймаутом во всех клиентах. Механизм работает без вашего участия, намерение «буду внимательнее» нет.

Где спотыкаются

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

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

Третье: история есть, вывода нет. Либо виноваты сроки и коллеги, либо вывод общий, «нужно больше тестов». Ценность в том, что именно вы поменяли, чтобы конкретный класс ошибок не повторился.