Максим Морев

Нашел решение, может кому пригодится.

myPlacemark.events
            .add('mouseenter', function (event) {
                let _this = event.get('target').getOverlaySync().getLayoutSync().getElement(); // Родительский контейнер html.
                let pinner = _this.children[0]; // Вложенный элемент.

                $(pinner).addClass('interested');
            })

Для того чтобы идти на собеседование нужны только ноги

Нет, не будет.
Закрытие других вкладок лишь освободит оперативную память.

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

Говорить о том, что некие фичи устарели - крайне глупо, если знать, что они ведут себя иначе, чем более модные альтернативы. Предлагаю немного разобраться и начать с того что на поверхности:
- getElementById и querySelector возвращают конкретную ноду в единственном экземпляре
- querySelectorAll и getElementsByName возвращает статичную коллекцию NodeList
- getElementsByClassName, getElementsByTagName и getElementsByTagNameNS возвращают динамическую коллекцию HTMLCollection
Как видим результат у разного апи различен, а значит и говорить, что некоторые из них устарели - глупо.
С устареванием вроде разобрались, но в вопросе еще есть часть "чем лучше". И тут есть теория, что getElementsBy* быстрее querySelector*. Чисто теоретически звучит логично, querySelector* должен делать полный поиск по дереву со сложностью O(n), а getElementsBy* могут использовать индексы на базе HashMap и получать данные со сложностью O(1), тут и особенности HTMLCollection будут кстати, так как можно не копировать коллекцию, а отдавать одну и ту же (и браузеры действительно так делают). Но без пруфов теория так и останется теорией.Гораздо лучше тут выглядят исходники. И я выбрал исходники chromium, как самого распространенного:
- getElementsBy* методы все как один обращаются к некой шаблонной функции EnsureCachedCollection, которая в свою очередь обращается к некоему NodeLists кэшу, устроенному внутри действительно как HashMap или что-то наподобие. Никакого поиска тут нет, просто берутся готовые значения, сложность у всего этого действительно константная O(1).
- querySelector* используют абстракцию SelectorQuery, которая и в самом деле делает поиск по DOM. Но данный поиск неплохо оптимизирован и обвешан кэшами. Притом CSSOM использует абсолютно тот же алгоритм поиска DOM нод для каждого селектора в css.

На этом спор думаю можно закрыть. querySelector* методы действительно могут быть медленнее, но чтоб убить ими производительность, нужно очень постараться. На фоне того, что пишут кривые ручки среднестатистического дешевого js-кодера это будет незначительной потерей измеряемой в наносекундах. Используйте то что удобнее в каждой конкретной ситуации.

Чтобы ответить на этот вопрос, достаточно подумать над тем, как будет выглядеть подключение ещё одного обработчика в каждом из представленных случаев.

console.log(this.$slots.header) // не работает

Ложь, работает. Между "не работает" и "результат работы отличается от желаемого" есть существенная разница, попытайтесь её осознать.

created () {

Что насчёт mounted? Или, если и так не увидите контент слота, mounted + nextTick?

Вес!

1. собаки
2. кровати
3. ребенка

Под ножки тензо датчик.
1+2 - тревога
1+2+3 - тревога

Это чудесное изобретение гугла называется Scroll anchoring. Чтобы отключить, добавьте в CSS:

body {
  overflow-anchor: none;
}

Ну не какие-то, но хочу понять как лучше сделать многостраничный сайт

понятие лучше не совсем применимо к технологиям вообще. Как и вопрос "хочу понять как лучше сделать многоквартирный дом", смысла он не имеет. То есть все сильно зависит от типа конкретного изделия и хотелок заказчика. В вашем случае - либо быстро и просто - взять готовую систему цмс, настроить по готовым гайдам в интернете и все готово. Или есть длинный путь - читаем про архитектуры веб приложений, ООП, пишем простенькие сайты для обучения, потом берем фреймворк, читаем, разбираемся, пишем серьезные проекты. Понадобится так же знание SQL и общие принципы работы сетевых протоколов, хотя бы на базовом уровне.

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

Хороший препод это не машина, как те совковые тетки которые нас учили. Это человек, который показывает как выглядит предмет, а не чистая сухая теория

может, вам нужен наставник, а не курсы?