210mev

человек вообще ни у чом не уиноват.
просто в компании не выстроены (или не правильно выстроены) бизнес-процессы.

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

Никак. Любой набор заголовков можно подделать не заходя даже на сайт) HTTP протокол открытый и управляется двумя пальцами

Что у самого стоит на полке: The Ruby Programming Language, The Ruby Way, The Rails 5 (у меня еще 4) Way. Ничего руби не отживает... просто хипстота перебежала на го и ноду. В СНГ не популярный, так и хрен бы с ним, вы на местных работать планируете? В рейтингах типо tiobe только на 15 месте? Так там Visual Basic на 6, даже выше пыха, стоит задуматься? Тот же пых если взять сколько там реальных проектов не на WP и прочих CSM с работой за еду? А в чем проблема с легаси? За 10+ лет ни разу не устраивался на проекте старше года, вот знал бы кобол, мог получать бы раза в 2 больше за работу над легаси, так что это такой себе критерий. А сколько лет хоронят джаву? Не слушайте прогнозы экспертов. Выберайте язык по личным предпочтениям, вам же с ним работать, а вакансий достаточно под любой спек.

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

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

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

Сначала указываете причину создания нешлифованного проекта:
"Проект, показывающий моё %умение/skill%...".
И потом, пишите пункты (в readme.md), которые Вы бы сделали до идеала.
Обязательно, после этих пунктов, приводите ссылку на проект с максимально отшлифованной игрой (чтобы могли сравнить слова с делом).

Чтобы заработала браузерная "Назад" браузеру нужно знать что был переход по маршруту.
Т.е. нажатие на таб должно изменять адрес в командной строке и изменилось window.history
В спа фреймворках удобной абстракцией для этого служит роутер.
В ангуляре это будет выглядеть примерно так https://ng-run.com/edit/zmORlCu2qJ5hI5G7Ggbk

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

upd:
Можно сделать все в одном компоненте при желании.
Сделать роут вида
{ path: 'tabs/:tab', component: TabsComponent },
А в самом табс следить route.params.subscribe(({ tab}) => { ... })

Указывайте свои пет-проекты. С помощью них можно будет оценивать ваш уровень как начинающего разработчика. Без них вряд ли будут приглашения на собеседования.

1. Создай единую точку входа, и оставь ее в корне сайта, остальные файлы вынеси за пределы (Это не только сделает твое приложении более гибким, понятным, и структурированным, но и в случае отваливания веб сервера, такое когда-то у меня было, после кривого обновлении до php7, исходный код показывался браузером)
2. Не забудь про SQL иньекции. Никакой конкатенации или вставок PHP. Только плейсхолдеры и байндинг
3. Если есть возможность загружать файлы, нужно исключить возможность исполнения в этой папке.

Нет, файл-PHP защищать не нужно, если веб-сервер передает его на обработку PHP-интерпретатору. То есть, если сценарии вообще работают, а не выдается содержимое PHP-файла при запросе по адресу ваш-сайт/action_page.php. Большинство PHP-движков спокойно хранят настройки в PHP-скриптах.

Однако, если данные очень критичны и есть боязнь сбоя сервера (например, администратор допустит случайную и временную ошибку, открыв доступ к содержимому скриптов, исключив интерпретацию), можете вынести все приватные данные за пределы action_page.php, например, в action_page_handler.php , в свою очередь находящийся за пределами публичной директории, и подключаемый, скажем, как require __DIR__ . '../../scripts/action_page_handler.php'; (и это будет единственная строчка в action_page.php, которую кто-либо когда-либо сможет увидеть).

Вставлю свои пять копеек. Имхо, по большому счету то, НА ЧЕМ ты пишешь имеет значение лишь в очень крупных проектах с большой командой и постоянными обновлениями. Там выбор стека на старте наложит отпечаток на все остальное. В 99% остальных случаев стек технологий совершенно не важен, если ЗАДАЧА ВЫПОЛНЯЕТСЯ.

Я такой же динозавр, только еще более древний, с нулевых годов пишу сайты. Слежу в пол глаза за всеми новыми течениями, языками, фреймфорками, IDE. Но категорически не вижу причин переходить на них для себя. 99% всех заказов под веб можно реализовать на том же вордпрессе или каком-то другом движке, на самописке и тд. И только один процент заказчиков реально знает что ему нужен например SPA на вуе с нереляционной БД и тд. Тот же SASS или лесс, который одно время взрывал фронтэнд тоже так и не убедил меня в своей нужности. Хотя я честно смотрел видосы с объяснениями-сравнениями, сам писал на них и тд. Если ты пишешь базовые css стили аккуратно и продуманно, разбиваешь на кусочки при необходимости и тд - у тебя и так никогда не возникнет проблем.

По факту, все что изменилось в моем личном мире за последние лет десять - это добавилось немного ООП в собственном коде и сменилась среда где я писал с дримвивера на atom. ВСЕ. Остальное как было php/mysql/html/css/js-jquery так и осталось. И знаете что? Этого с головой хватает чтобы решить ВСЕ задачи которые передо мной стоят. И я совершенно себя не чувствую каким-то ущемленным или устаревшим.

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

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

Тестовые для джуниора:
Какие тестовые проекты стоит написать

Фреймворки:

• Symfony
  
• Laravel
  
• Просто понимание PSR 7 фреймворка (откроет ворота и к Symfony и Laravel и к любому)
  

На CMS смотреть не стоит, разве только если CMS интернет-магазинов (кроме Битрикса — это тупиковые знания, замкнутые сами на себя, и сомнительного качества)

Примеры:
https://github.com/pepelsbey
https://github.com/Samdark
https://github.com/mdo

Как заинтересовать работодателя:
1. Аватарка. Да, она должна быть. Ещё лучше, если это будет ваша фотография. Если видишь в профиле дефолтную аватарку, возникает ощущение, что GitHub у человека всего лишь для галочки.
2. Контактный email.
3. Полоска активности должна быть зеленой (см. примеры выше), но в меру — не нужно стремиться окрасить каждую клеточку, отдыхать тоже нужно. Если заходишь в профиль, а салатовые клеточки изредка были год назад или наоборот появились только две недели назад, то страница работодателя не заинтересует.
4. Ссылка на персональный сайт.
5. Наличие собственных public репозиториев. Работодатель хочет увидеть ваш код, поэтому очень желательно наличие в них свежих коммитов. Каким должен быть отличный репозиторий на GitHub — тема для отдельного вопроса, тут напишу кратко: README, понятная структура, тесты, звезды.
6. Наличие вклада в Open Source проекты. Мне доводилось встречать профили, в которых были выполнены все пункты выше, но тем не менее их владельцы были очень слабыми разработчиками. Наличие вклада в крупные проекты с открытым исходным кодом — это однозначно вин. Очень желательно, чтобы он у вас был.
7. Stars, Followers, Following. Всё это тоже было бы неплохо завести. Если у вас много фолловеров на GitHub, значит скорее всего вы из себя что-то представляете в мире Open Source, раз другим интересно следить за вами.

P.S.: Хороший профиль на github сам может выступать в роли резюме. Очень часто хедхантеры через него и выходят на тебя.