Как вести себя, если коллега предлагает решение, которое, по твоему мнению, не сработает

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

Умеете ли вы спорить о технических решениях так, чтобы команда выбрала лучшее, а отношения не пострадали. Отдельно интервьюер смотрит, допускаете ли вы, что ошибаетесь сами. Следом часто спрашивают: а если коллега не согласился и сделал по-своему?

Как отвечать

Каркас из четырёх шагов, на своём примере:

• сначала вопросы: уточните, какую проблему решает предложение и какие ограничения коллега учитывал. Нередко «не сработает» оказывается «не сработает в моём сценарии, о котором он не знал»;
• аргументы, а не мнение: в Go это чаще всего данные. Бенчмарк через go test -bench и сравнение benchstat, профиль pprof, прогон с -race, если спор о конкурентности. Небольшой прототип убеждает лучше получаса обсуждения;
• письменно и по делу: замечание в ревью или короткий дизайн-док с плюсами и минусами обоих вариантов. Критикуйте решение, а не человека;
• решение и эскалация: если цена ошибки мала, пусть коллега попробует, договоритесь о метрике успеха. Если решение архитектурное или трудно откатывается, зовите техлида. После решения работайте по нему, даже если были против.

Пример из практики сильнее всего звучит с конкретикой. Скажем, коллега предлагал запускать горутину на каждое входящее сообщение без ограничений, вы показали на нагрузочном тесте рост памяти и предложили пул воркеров или errgroup с SetLimit. Цифры приводите свои и настоящие, без круглых «плюс 30%».

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

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

Рассказывают историю, где кандидат прав, а коллега в конце признал ошибку. Интервьюер ищет готовность услышать другую сторону, а не победу в споре.

Спорят на уровне вкуса: «каналы лучше мьютексов». Без измерений и контекста это не аргумент.

Продолжают саботировать принятое решение или переписывают его втихую. Это хуже, чем проиграть спор.