Встретил фразу "верифицировать дефекты". Даже на секунду закралась мысль, что это я дикий и не понимаю контексь

Были лет 5 назад модны холивары про верификацию и валидацию - где отличия и т.д.
Нас вроде на экзамене после испыта это спрашивали на прошлой работе

Верификация, грубо, сравнение имплементации кода с дизайном. Валидация сравнение имплементации с потребностями юзера (в плане использования приложухи, конечно).

Но што такое Верификация дефектов, я прям решительно не понимат

Может, кто-то плохо понимал, о чем писал, но точно знал, что тестирование - это верифицировать и дефекты и решил соединить))

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

Другое дело что лучше уточнить что имелось в виду автором высказывания

Вообще, похоже на один из вариантов жц дефекта в системах управления разработкой/тестированием. Переход из статуса fixed в verified, и такое название статуса подтолкнуло автора написать "верификация"

Был у меня эпизод, когда я мог примерно так пару месяцев делать, каждый новый релиз можно было не глядя начинать с блокирующего бага "не загружаются файлы", и ждать потом несколько дней до починки и продолжения работы. Закончилось это только после того как эскалация проблемы поднялась на несколько уровней выше и разработчиков немножко вздрючили по полной.

Пример того, как не надо строить взаимодействие отделов, и почему добрые "соседские" отношения лучше чем формализм и отфутболивание

у меня на прошлой работе так было, когда тестил мобильные приложения одной продуктовой команды.
из приложения в приложение одни и те же баги, у меня даже шаблон на них был.
ни общение с командой, ни эскалация до ПМа и ПО не решили проблему

Классика жанра, когда все участники процесса рассматривают отдел qa как занозу, мешающую творческому полёту. Иногда интересно было бы посмотреть на ситуацию, когда отдел распускают, разрабов отпускают на волю, и потом "рыночек решает" судьбу продукта в его получившемся без qa виде

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

Проверить и закрыть или переоткрыть :)

Тогда верификация фикса

А у кого есть учетка на hh как работодатель?  
Работодателям так же видно,  кто просматривал их вакансию?

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

Видно. Но если ты скрыл от работодателя резюме, он тебя не увидит
https://kazan.hh.ru/article/501213

Все таки, это очень вредно читать текст вакансий. Требование:
- Внутреннее интуитивное понимание уровня качества продукта

Чую, код гуано...

Интересно, как на интервью будут проверять...

по шкале от 1 до 10 на сколько говно этот код?

По отчаянию, которое заставило написать это требование в вакансии, уже ясно, что не меньше 8