Правильно ли лид ставил задачи
Что проверяют
Не оценку вашего бывшего руководителя, а вас. Слушают, как вы говорите о прошлой команде, и заодно выясняют, что для вас значит «задача поставлена»: разработчик, который берёт в работу одну строчку в чате, дорого обходится проекту.
Как отвечать
Сначала критерий, потом факт. Скажите, что задача для вас поставлена, когда понятно: зачем она нужна, что считается выполненным, что в объём не входит, какой у неё приоритет относительно остального и с кем сверяться по спорным местам.
Дальше честная оценка без ярлыков. Например: крупные задачи приходили описанными, мелкие правки часто прилетали устно, поэтому вы сами заводили тикет и присылали лиду формулировку на подтверждение. Такой ответ показывает, что вы решали проблему, а не терпели её.
Полезно назвать конкретные приёмы, которые вы применяли: разбор задачи до взятия в работу, вопросы про нефункциональные требования и обратную совместимость API, отдельный вопрос про миграцию данных, фиксация договорённостей в комментарии к тикету, ранний показ черновой реализации вместо готового решения в конце спринта.
Для разработчика важно привязать всё это к техническим последствиям: размытая постановка превращается в лишние абстракции, переделки и мёртвый код, который потом годами носит вся команда.
Закончите встречным вопросом: как задачи ставятся здесь, есть ли предварительный разбор, кто владеет критериями приёмки. Ответ скажет о будущем месте больше, чем описание вакансии.
Где спотыкаются
Переходят на личности: лид был слабый, в коде не разбирался. Это оценка человека, а не процесса, и собеседник примеряет её на себя.
Впадают в другую крайность и говорят, что всё было идеально и вопросов не возникало. Звучит неправдоподобно и лишает вас возможности показать, как вы уточняете требования.
Пересказывают заученную схему с придуманным финалом про снижение числа ошибок и рост удовлетворённости заказчика. Здесь ждут наблюдение о процессе, а выдуманный результат разваливается на вопросе о том, чем именно он измерялся.