Какие проблемные моменты с коллегами были в работе

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

Как вы ведёте себя в разногласии: идёте на прямой разговор, эскалируете или копите обиду. Интервьюеру важно, чтобы история закончилась решением и выводом, а не победой над коллегой. Следом обычно спрашивают: «а если бы договориться не получилось?».

Как отвечать

Возьмите одну реальную рабочую ситуацию и расскажите её по схеме STAR: ситуация, ваша задача, действия, результат. Для C#-разработчика подходят рабочие споры, а не личные ссоры:

• архитектура: строить ли доступ к данным на EF Core или на Dapper, делить ли монолит на сервисы, где проходит граница модулей;
• код-ревью: ревьюер неделями держит пул-реквест или спорит о стиле. Правила можно вынести в .editorconfig и анализаторы Roslyn, и тогда спор решает сборка, а не человек;
• контракты между командами: соседняя команда поменяла API без предупреждения, и ваш сервис упал. Уместно рассказать про контрактные тесты или версионирование API;
• сроки и качество: коллега коммитит без тестов, чтобы успеть, и ломает сборку остальным.

В действиях покажите, что говорили о проблеме, а не о человеке, пришли с фактами (логи, метрики, ссылки на задачи), предложили вариант и договорились о критерии выбора. Если договориться не вышло, эскалация к тимлиду тоже нормальный ход, когда вы приходите туда с вариантами, а не с жалобой.

Результат опишите измеримо: сколько времени стало уходить на ревью, сколько раз после этого падала сборка. Цифры берите свои. Если серьёзных конфликтов не было, так и скажите и расскажите о небольшом разногласии: это честнее придуманной драмы.

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

Рассказывают историю, в которой виноват только коллега. Интервьюер ищет, какую роль в конфликте сыграли вы сами.

Говорят «у меня никогда не было проблем с коллегами». Это звучит как отказ отвечать.

Не доводят историю до результата. Без итога и вывода, что вы сделали бы иначе, рассказ показывает только то, что конфликт был.