DollyPapper

Если у вас обычный среднестатистический сайт/интернет магазин/CRM/etc. берите тот который знают разрабы которые будут реализовывать. Если у вас ожидается высокий RPS, то тут нужно в сторону более производительных языков смотреть. Оптимальный на текущий момент это Go/Node. И среди них есть разделение. Если у вас CIA (CPU intensive application), то Go лучше взять. Если DIA (data intensive application), берите либо ноду либо go, тут разницы нет. А так при прочих равных уже сказали - берете тот, который знает команда

Пулишь свою задачу из апи асинхронно, всё по классике. Дальше используешь Worker Threads.

Надеюсь никогда не попаду в компанию, где вы являетесь ПМом :) Без обид, ничего личного, но даже возникновение мысли об этом поспорить уже абсурд. Сначала заказчик/начальник хочет чтобы функционал был сделан еще вчера, а на архитектуру, практики кодирования мы положим ботл, а потом у них возникают вопросы откуда баги. Ну вот оттуда и баги. Производство ПО это такое же производство как и любое другое производство. Если бы мы говорили про автомобильную индустрию, то на сколько бы вам хотелось ездить на машине которую сделали за вечер потому что сроки горят, конкуренты нас обходят? Мне вот тоже не хотелось бы. По этому в любом другом производстве уже давно выстроены процессы, есть отделы тестирования качества и прочие вещи, которые позволяют уменьшить/исключить брак. И только в ИТ почему то до сих пор является нормальным забить болт на все практики производства и потом спрашивать за баги с разработчика. Когда у вас появится формальное описание ТЗ (именно формальное, т.е. формализованное) в котором просто не может иносказаний одного и того же пункта, когда у вас появится опытный архитектор который будет довольно долго планировать архитектуру проекта, когда у вас появится нормальная процедура тестирования специально обучеными людьми и у вас все равно будут баги, тогда можно и задуматься, а стоит ли платить разработчику за баги, ведь теперь у меня есть все условия для того, чтобы багов не было. А до тех пор советую на эту кривую дорожку не вставать. Вот простой пример, рассудите сами:
Есть некоторый код который использует некоторую библиотеку. В библиотеке есть баг который всплыл у вас на проде. Разработчик в этом виноват? Может он виноват в том, что выбрал не качественную библиотеку? А у вас выстроен формальный процесс верификации запчастей из который состоит ваш проект? А у разработчиков библиотеки хорошие процессы разработки были? Это ведь тоже программный код который так же кто-то разрабатывал.

Тут все зависит от того как вам удобно, кто бы что не говорил, нет единого стандарта нужно/не нужно. Я наоборот чаще вижу что вместо прямого источника данных подают репозитории в сервисы. И сам так делаю. Это банально удобней тестировать.

Вам нужна оркестрация. Есть решения большие и сложные типа кубера, но вам вероятно подойдет docker swarm

Разница в том, что одичка создает объект который доступен в единственном экземпляре в системе. А статические классы это не объекты, это классы.

Обратите вмание на выделеное красным. Тут уже 1000 раз повторили про важность практики, и я не буду исключением. Практика исключительно важна. Темы сами будут запоминаться если вы будете писать код который использует базу которую вы прочитали. Блок "интервальное повторение" это как раз про кривую забывания которую здесь уже упоминали.

Не могу сказать за Python, но не уверен, что вы правильно понимаете его механизм await. Сомневаюсь, что он продолжает выполнять текущий исполняемый поток после await, т.к. это нарушит исполение кода.
Про JS могу сказать, что вы видимо не до конца понимаете какой код будет исполнен действительно асинхронно, а какой последовательно (т.е. блокируя основной поток).

const axios = require('axios')

async function doReq1(){
    const res = await axios.get('http://localhost:12000?id=1')
    return res
}

async function main(){
    doReq1().then((data) => {
        console.log(data.data)
        console.log("After req")
    });
    console.log("Before req")
}
main()

Данный код выведет 1) Before req 2) Hello 1! 3) After req
Т.е. AfterReq будет исполнен после того как асинхронная операция получит результат, т.е. подождет (await) результата.
Аналогичный код с await

const axios = require('axios')

async function doReq1(){
    const res = await axios.get('http://localhost:12000?id=1')
    return res
}

async function main(){
    console.log("Before req")
    let res = await doReq1()
    console.log(res.data)
    console.log('After req')
}

main()

Если говорить про собесы - хз, как повезет. Обычно гоняют на столько, насколько собеседующий сам разбирается. Непосредственно в работе тоже по разному бывает. Из своего опыта могу сказать так: непосредственно при написании системы редко пригождаются какие то специфические вещи типа оконных функций. С другой стороны приходилось пилить сложные запросы когда делал отчеты. Там приходилось даже свои аггрегатные функции писать на plpgsql. Так что единого ответа тут нет.

Суть в том, что как вы и сказали: интерфейс это контракт. Можно его еще назвать "тип". Т.е. завязываясь на интерфейс мы обязуем вызывающий код передать нам штуку которая умеет делать определенный список вещей. Собственно все. Немного не правильно противопоставлять интерфейсы наследованию. Наследование это когда одна штука является спицифичной версией другой штуки. Интерфейс же в свою очередь это больше клиентская часть, когда код говорит - я хочу на вход переметр такого-то типа. Давайте простой высосаный из пальца, но довольно ясный пример:
Есть класс Parser

class Parser
{
	public function getPage($url){
		return $this->load($url);
	}
	protected function load($url){
		return file_get_contents($url);
	}
}

Есть класс Exchanger

class Exchanger extends Parser
{
	public function getRate($currency){
		return $this->load('...?id=' . $currency);
	}
}

В примере выше в классе Exchanger мы унаследовали метод load из базового класса. Дальше используем

$parser = new Parser();
$parser->getPage('...');

$exchanger = new Exchanger();
$exchanger->getRate('USD');

Т.е. и там и там должен быть метод load который по http что-то откуда-то грузит и выдает данные которые дальше как-то используются и т.к. метод load уже есть в классе Parser, ну мы просто унаследовали его и все работает. Но при таком подходе появляются проблемы. Не понятно по какому принципу вообще Exchanger наследуется от Parser, это два семантически друг с другом не связанных класса. И почему у Exchanger есть метод getPage тоже не ясно. Можно пойти по другому. Сделать отдельный класс Loader с методом load и оба унаследовать от него. Это в целом тоже задачу решает, но если появится еще специфичная функциональность которую могут использовать оба наших класса? Множественного наследования нет. Добавлять эту функциональность в Loader? Опять же нарушится консистентность нашего Loader. Можно пойти третим путем. Сделать интерфейс Loader и указать что Parser и Exchanger требуют в качестве зависимости что-то, что имеет метод load. В этом случае нет проблем описанных выше, и есть доп. плюшки, например упрощается тестирование, потому что можно будет вместо обьекта который реально лезет куда-то по http передать заглушку которая просто в методе load возвращает готовые данные.

Сама поставновка вопроса говорит о том, что никуда вы в этом плане не продвинулись. Посмотрите курс "Дмитрий Елисеев - Неделя ООП". Там примеры на PHP, но это не должно пугать, т.к. в ООП платформозависимое по сути только наследование, и то, синтаксически во всех С-подобных языках оно +- одинаковое.

В том беда современного обучения программированию, что учат ООП на наследовании кошечек и собачек от абстрактных животных, а нахера это делать и зачем это появилось не учат. Плохая для вас новость - вы не поймете прелести подхода пока не проработаете хотя бы годик на реальном проекте. Но понять сам ООП вы можете не работая. Попытаюсь натолкнуть вас на мысль, и обьяснить истоки, откуда пошло ООП и зачем, через какое-то время вы осознаете эти концепции. Итак.
Когда мы пишем программу, мы так или иначе моделируем какую-то часть реальности. Модель это несовершенное представление самой этой реальности, с выделенными атрибутами необходимыми для нашей решаемой задачи (абстрагирование, один из принципов ООП), например детская игрушка самолет, это модель реального самолета который копирует лишь внешний реального самолета, при этом игнорируется его внутреннее устройство, и игрушка таким образом не умеет летать, но наша задача (развлечь ребенка) при этом выполняется.
Существует несколько парадигм праграмирования. Каждая парадигма это стиль моделирования программы. Затронем например процедурное программирование. В нем существуют для моделирования задачи такие сущности как: структуры данных и процедуры которые эти структуры обрабатывают. Дело в том, что в программе есть всего две еденицы которыми мы управляем: данные и поведение. Структуры данных это собственно данные, процедуры это поведение. Смысл зачем появилось процедурное программирование именно чтобы дать программисту абстрагировать поведение (засунуть код обработки данные в именованную сущность, она еще называется функция или процедура). Что это нам дает? Раньше у нас была простыня кода которая расчитывала например зп сотрудников, если нам нужно было посчитать зп в разных местах нам нужно было копипастить эту простыню. А сначала нужно было разобраться что простыня делает. Это сложно. Теперь у нас появилась именованная сущность (процедура) которпя имеет метку имени calculateSalary. Ну и что? А то, что теперь нам во первых не нужно копипастить код, во вторых (в идеале) не нужно разбираться как он работает. Мы просто знаем что calculateSalary считает зп для сотрудника. Как оно это делает, нам совершенно похер. Снизилась когнитивная нагрузка на мозг при моделировании задачи и повысилась переиспользуемость кода, тем самым сократилось время разработки. Но умные люди на этом не остановились и стали развивать идею дальше. Дальше они подумали, что не плохо было бы обьеденить в одной сущности данные и действия над этими данными, назвали это обьектами, которые могут формироваться на основе классов. Теперь у нас обьеденены данные и процедуры в одной именованной сущности (это инкапсуляция). Подробнее об инкапсуляции можете почитать в другом моем ответе https://qna.habr.com/q/1174988#answer_2194198
В общем вы не поймете прелесть ООП пока не поработаете по той причине, что нужно набрать массу сложности в проекте, которую генерируете как вы сами так и другие программисты, и не поймете прелесть повторного использования кода которое дает ООП, потому что у вас нет горящих сроков. Тут еще можно в целом много чего написать на тему ООП, но я бы вам посоветовал следующие книги:

Стив Макконел - Совершенный код
Гради Буч - Обьектно ориентированный анализ и проектирование
Сергей Типляков - Паттерны проектирования на платформе .NET (это вместо банды четырех, т.к. там более современно раскрывается тема паттернов, не пугайтесь что она про C# .NET, книга в самом деле очень хорошая)

Так же список терминов на погуглить
GRASP - Information Expert
Information Hiding
Software Complexity (это то откуда всё начинается, управление сложностью)
Cohesion & Coupling

Если вы все эти темы осознаете, то будете понимать в ООП и проектировании больше 95% ваших будующих коллег, я вам гарантирую.

Не знаю правда ли в 22 году сложно найти работу, но если реально трудно, то попробуйте тут помониторьте стажировки