Какие задачи на лайфкодинг давать, например найти уникальный элемент в массиве?

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

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

Как отвечать

Начните с вопросов: «уникальный» значит встречается один раз или нужно убрать дубли; какие типы в массиве; что вернуть, если такого элемента нет. Затем решения:

• подсчёт через Map: один проход считает частоты, второй ищет элемент с частотой 1. Время O(n), память O(n). Map сохраняет тип ключа, а обычный объект приводит ключи к строке, и вместо 1 вернётся "1";
• XOR: если все элементы, кроме одного, встречаются ровно дважды, arr.reduce((a, x) => a ^ x, 0) даёт ответ за O(n) без памяти. Только для целых чисел в пределах 32 бит: побитовые операторы приводят операнды к Int32;
• filter с indexOf === lastIndexOf: коротко, но O(n²), об этом нужно сказать самим;
• удаление дублей: если имелось в виду это, достаточно [...new Set(arr)].

Для лайфкодинга на фронтенде кроме таких задач хорошо работают практические: debounce и throttle, свой Promise.all, глубокое сравнение объектов, порядок вывода с setTimeout и промисами, компонент со списком, загрузкой и отменой запроса через AbortController.

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

Сразу пишут код, не уточнив условие. Потом выясняется, что нужно было убрать дубли, и решение переписывается.

Предлагают XOR как универсальный ответ. На строках, дробных числах или когда остальные элементы встречаются трижды он даёт мусор.

Считают частоты в объекте и возвращают ключ из Object.entries: число превращается в строку, и сравнение === в тесте падает.