Почему select 'account1' возвращает 5, а не 7

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

Умеете ли вы расследовать расхождение между ожидаемым и фактическим количеством строк. Синтаксис тут ни при чём, интервьюеру нужен ваш метод: какие гипотезы назовёте и чем проверите каждую. Это продолжение живой задачи, а не вопрос на память.

Как отвечать

Сразу сказать, что ответ зависит от данных, и перечислить причины по частоте:

• NULL в столбце фильтра. Сравнение с NULL не истина и не ложь, поэтому такие строки отсеивает любое =, <> и особенно NOT IN;
• тип соединения. INNER JOIN со справочником выбрасывает строки без пары, а условие на правую таблицу, перенесённое из ON в WHERE, превращает LEFT JOIN во внутренний;
• сама строка-значение: хвостовой пробел, другой регистр, неразрывный пробел, дополнение пробелами у типа char;
• схлопывание: DISTINCT, GROUP BY или оконная дедупликация уже убрали дубли, а семь вы насчитали по сырой таблице;
• забытый фильтр: диапазон дат, флаг мягкого удаления, партиция, LIMIT в подзапросе.

Проверять по шагам, снимая условия по одному:

select account, count(*) as rows_all, count(amount) as rows_filled
from ops
group by account;

Расхождение count(*) и count(колонка) мгновенно показывает NULL.

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

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

Забывают про троичную логику. Классический капкан это NOT IN с подзапросом, где встретился NULL: запрос честно вернёт пустой результат, и в нём нет ни ошибки, ни предупреждения.

Путают «строк стало меньше» и «сумма стала меньше». Соединение умеет не только терять строки, но и размножать их, поэтому проверять надо оба направления, а итоговую сумму сверять по независимому агрегату.