Что ищете в новом проекте
Что проверяют
Понимаете ли вы, куда идёте, и совпадают ли ваши ожидания с реальным проектом. В дотнет-командах это особенно чувствительно: заметная часть работы связана с системами, которые живут годами, и кандидат, настроенный только на разработку с нуля, разочаруется быстро.
Как отвечать
Назвать два-три критерия и превратить их во встречные вопросы про этот проект:
- состояние платформы: на какой версии живёт решение, остались ли части на старом
.NET Framework, есть ли план обновления и кто за него отвечает; - соотношение нового и поддержки: какая доля времени уходит на новые задачи, а какая на сопровождение, и как принимаются решения о переписывании;
- инженерная база: какие есть автотесты, собирается ли проект в CI, как выкатывают, как ловят ошибки на бою;
- зона решений: кто выбирает подход к слою данных и способ доступа к базе, есть ли архитектор поверх команды.
Хорошо звучит честная формулировка про наследованный код: готов с ним работать, если понятно, куда его ведут. Она снимает главное опасение нанимающего и одновременно задаёт ваш собственный критерий.
Где спотыкаются
Просят задачи только с нуля и только на свежей версии платформы. Проект, полностью свободный от наследства, встречается редко, поэтому такой ответ читается как заявка на скорый уход.
Перечисляют модные слова: микросервисы, облако, событийная архитектура. Дальше следует вопрос, зачем это здесь и что изменится в эксплуатации, и без внятного ответа весь список выглядит как пересказ вакансий, а не как опыт.
Говорят про развитие, но не могут назвать, чему именно хотят научиться. Желание расти без предмета не сообщает ничего. Формулировка про то, что хочется разобраться в производительности доступа к данным и в диагностике проблем на бою, звучит как план, а не как вежливая фраза.