- Нам нужен инженер. - Инженер чего? - А они что разные бывают?

Понимать -- нет (его и техлид полностью не понимает), а вот ориентироваться в целом -- очень желательно. Иначе может получиться ситуация такого примерно рода:

В вакансии в требованиях -- хорошее владение ClickBaitSQL.

Кандидат в сопроводительном -- я владею всем остальным, указанным в вакансии, и аналогом ClickBaitSQL -- AudienceCaptureSQL. Но вот конкретно ClickBaitSQL -- нет.

Если HR не ориентируется в этом стеке, не знает, подойдет ли такая замена и не знает, какие скиллы реально приоритетны, возможны и ложноположительные и ложноотрицательные результаты.

Заодно в процессе ориентирования можно уточнить и описание требований в вакансии. А то стоит, скажем, требование TCP. И что оно значит? Надо будет править линуксовые tcp.h/tcp.c в ядре? Или (противоположность) это -- наш сервис использует вебсокеты через Boost.Beast, который в конечном счете работает по TCP, поэтому надо примерно понимать, как работает TCP? Если HR будет выяснять, что это значит, описание в вакансии можно будет уточнить.

HR ведь первая линия. Задача - оценить не техническую суть, а эмоции при ответе, поймать нотки уверенности (или нет) в речи, постараться прочувствовать мотивацию и личность в целом.

Если HR задаёт hr вопросы, то нет. Если пытается задавать технические вопросы, то да :) А то сидит девочка, пытается зачитать мудреные слова, а у самой глаза стекленеют :))) Жалко же. :)

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

Нет - он должен очень хорошо понимать, что он его НЕ понимает.

Наверное, HR-у стоит иметь общее представление о технических вещах: что к чему относится и зачем это нужно. Понятно, что знание деталей - это уже обязанность специалиста.