Нужны ли хэш-мапы для решения задачи с массивом tickets

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

Умеете ли вы обосновать выбор структуры данных через сложность, а не «взял объект, потому что привычно». Дополнительно смотрят, различаете ли вы Object, Map и Set в JavaScript и понимаете ли, чем платите за ускорение.

Как отвечать

Сначала уточнить задачу: посчитать повторы, проверить наличие, найти пару с нужной суммой, сгруппировать. От этого и зависит ответ.

Если нужен быстрый поиск по ключу или подсчёт, хеш-таблица уместна: она даёт в среднем константное время на операцию и превращает вложенный перебор O(n^2) в один проход O(n) ценой O(n) дополнительной памяти. Если же нужен порядок, k-й по величине элемент или диапазон, хеш-таблица не помогает, там работают сортировка и куча. Когда возможных значений мало и они известны заранее, хватит нескольких счётчиков.

В JavaScript для словаря лучше Map: любые ключи, честный size, порядок вставки и никаких унаследованных полей. Для проверки принадлежности достаточно Set.

const count = new Map();
for (const t of tickets) count.set(t, (count.get(t) ?? 0) + 1);

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

Используют обычный объект и натыкаются на прототип: ключ toString или __proto__ ведёт себя не как данные. Плюс ключи приводятся к строкам, и число 1 со строкой '1' схлопываются в одну запись.

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

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