Robur

Что стоит использовать type или интерфейс?

Что хотите

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

Если повальное использование типов приведет к более однообразному коду - то да.
А в другом проекте может так получиться что использование интерфейсов приведет к более однообразному коду.

В любом случае - однообразие - это хорошо. Что вас к нему приближает, так и пишите.

яваскрипт - структурно крайне простой язык и практически все шифрование сводится к игре в перестановку букв и дописание ненужного кода чтобы было запутаннее.

как шифровать,

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

чтобы "расшифровать" берете "_0x2e3074" и переименовываете в то что подходит по смыслу, если смысл пока не ясен, то в "param1"

После деобфускации код перестаёт выполнять свои функции, это нормальное явление?

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

Там же не будут условно все 3-4 человека работать над версткой,

почему нет? будут, если так будет работа построена.

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

есть несколько вариантов:
1. создание UI - библиотеки компонентов, из которых уже разработчики строят что им нужно. Это требует грамотного подхода, но если сделано как надо - то весьма удобно. Разработчик в идеале вообще ни одного html тега не пишет - везде просто компоненты из библиотеки. на элементы и на лэйаутинг. Ответственный за библиотеку уже там внутри пишет стили, верстку, обновляет под дизайн и так далее.
2. каждый разработчик создавая компонент сразу продумывает и полностью создает верстку для него.
3. разработчики пилят что-то работающее но выглядещее как мечта кубизма, потом это отдается верстальщику, который уже стизилует, поправляет теги, делает чтобы было хорошо-красиво.

во всех вариантах тот кто отвечает за верстку должен конечно знать JSX и хотя бы базовое представление о том как компоненты рендерятся в DOM-дерево.

но как перебороть упадок дохода, сам психологический факт

никак. Либо вы выбираете один путь и принимаете все его стороны - крутое развитие и упавший доход, либо другой - хороший доход и скучная работа без перспектив.
Конкретно для вас - без семьи, кредитов, ипотеки, это вопрос исключительно личного выбора, обязательств держать доход на том же уровне у вас нет.

Один из важных навыков это умение делать этот выбор и принимать ответственность за получаемые минусы так же как и плюсы.

Есть ли смысл

Тут каждый день пачка вопросов "есть ли смысл мне сделать вот это". Кто же вас знает, в 21 год пора решать самому - есть он для вас или нет.

ПС. Если вам прямо вообще никак, и желание избежать падения дохода намного сильнее вашей потребности в росте и самореализации, то можете еще попробовать зарабатывать столько же за меньшее время. Как это сделать - волшебного решения нет, сами думайте. Переехать например туда где сможете получить и то и другое. Или еще что-то, что для вас доступно и подойдет.

берете картинку, ставите на фон, сверху svg полигоны рисуете, делаете чтобы цвет менялся при наведении мышки, и будет как на том сайте.

Если не подходят варианты разместить вакансию на жоб-сайтах и искать исполнителя на фриланс-биржах, то остается немного - сарафанное радио, и объявления везде где можно (тут насколько хватит креативности)

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

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

начните отсюда https://developer.mozilla.org/en-US/docs/Web/JavaS...

1. Убедиться что действительно по софт-скиллам. фидбек "почему-то было трудно наладить диалог, а у нас важна коммуникация" - вообще ни о чем. Может им было трудно наладить диалог потому что у интервьюера плохие софт-скиллы с незнакомыми людьми, а коммуницировать может только в привычной ему команде, где от уже 5 лет работает.

2. Если у вас действительно проблема в них, то на этапе выяснения этого вы уже должны были понять какие конкретно проблемы, как и когда проявляются, что за ситуации и так далее. Берете этот список и думаете как исправлять, тут зависит от того что это за проблемы. Если у вас такой список не получился, то возвращаетесь к пункту 1 - вы его не сделали как надо, либо переходите к пункту 3, если сделали а списка так и нет.

3. Если проблема не в софт-скиллах, то просто считайте такой фидбек за крайне неумелую попытку "мягко отказать". Проблема в чем-то другом. Тут уже нужна статистика по интервью, сходите хотя бы на 5, лучше 10.

У вас у каждого программиста скорее всего только один мозг. Поэтому он может делать только одну задачу.
Если у вас несколько несвязанных задач одновременно, это значит что программисты постоянно прыгают с одной на другую, или их постоянно дергают то по одной то по другой. Начал он делать функционал А, погрузился в работу а тут ему говорят "ну как там с Б у нас дела"? и много других проблем.
Такой подход сложно назвать эффективным.

одновременно запускается в разработку около 3-4 разных функционалов

можно прочитать как "мы наваливаем неструктурированную кучу задач на команду и они как-то там сами разгребают".

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