Какие вопросы задавать для прояснения задачи

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

Бросаетесь ли вы писать код сразу или сначала выясняете, что именно нужно сделать. На лайвкодинге и системном дизайне часть условий специально не проговаривают: ждут, что вы спросите сами. Следом нередко просят вспомнить задачу, которую пришлось переделывать из-за непонятых требований.

Как отвечать

Покажите, что вопросы у вас разложены по уровням, и начните с тех, что меняют решение. Для алгоритмической задачи:

• входные данные: тип и размер, может ли прийти пустой список, None, дубликаты, отрицательные числа, строки не в ASCII;
• ограничения: при n до сотни хватит квадратичного решения, при миллионе нужно O(n log n) или лучше, и это стоит спросить до выбора алгоритма;
• выход: вернуть новый объект или изменить на месте, что делать с некорректным вводом, бросить ValueError или вернуть значение по умолчанию;
• инструменты: можно ли пользоваться collections, heapq, itertools или ждут реализацию руками.

Для рабочей задачи или системного дизайна:

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

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

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

Задают общие вопросы вроде «какова цель проекта», которые на решение не влияют. Интервьюер ждёт вопросов, от ответа на которые зависит алгоритм или архитектура.

Не спрашивают об объёме данных, пишут решение за квадрат и узнают про миллион элементов уже на разборе.

Перебарщивают: пятнадцать минут уточнений там, где хватило бы трёх вопросов. Спросите главное, а остальное проговорите вслух как допущение.