Алексей Дзюба

что должен знать идеальный джуниор (мое личное мнение):

- Сетевой стэк. Нужно иметь хотя бы базовое представление о том как с сервером общаются. Ну то есть не нужно лезть в дебри, но понимать что такое HTTP или чем TCP от UDP отличается - нужно. В целом это пара часов чтения википедии.
- GIT или любая другая распределенная VCS. Базовые навыки, что бы хотя бы понимал что есть git revert или git rebase, что такое фичабрэнчи и примерное представление как это работает и зачем надо.
- Базовые основы unix. Ну то есть что бы не пугаться таких вещей как ssh хотя бы.
- PHP. Без этого никуда. Он должен понимать что такое слабая динамическая типизация (не заучивать табличку кастов типов, а понимать плюсы и минусы, такая же история с приоритетами операторов - не заучивать а знать как избегать проблем с чтением кода)
- Понимать что код чаще читают чем пишут, а потому не экономить 5 минут на написании кода, а писать так, чтобы сэкономить 30 минут человеку, разбирающемуся в куске кода.
- Знать базовые вещи в плане безопасности. XSS и как защищаться, SQL инъекции и как защищаться, CSRF, MITM. Понимать что такое NDA, что данные пользователей - секретная информация. Как хэшировать пароли (не md5 а password_hash) и почему это важно.
- Знать SQL. Глубоких знаний не требуется, нужно лишь понимание того, что такое нормальная форма, желательно разобраться с вопросом денормализации данных. Идеально иметь хотя бы базовые представления о том как работать с NoSQL решениями.
- Процедурное программирование: почему глобальные переменные порождают сложность, что такое состояние, как можно использовать классы для изоляции состояния и т.д. Инкапсуляция. Инварианты, пост/пред условия, сохранение целостности...
- Разделение ответственности. Это один из важнейших принципов, и упрощать все это до "mvc фреймворк" слегка неправильно. Вы должны понимать что от чего отделяете и главное зачем.
- Автоматические тесты. Джуниор должен знать что это такое и иметь хотя бы минимальный опыт их написания. Должен понимать разницу между юнит и интеграционными тестами. Быть знакомым с пирамидой тестирования.
- Уметь решать стандартные задачи не задавая слишком много вопросов. Например регистрацию пользователя по email-у вы должны написать, или авторизацию через соц сети, или комментарии, или новостную ленту.
- Уметь дебажить. xdebug, blackfire и тд.

В целом где-то за годик весь этот список можно влегкую покрыть с нуля.

p.s. Я в списке специально не указывал ООП, поскольку всеравно первые пару лет у разработчиков выходит процедурщина на классах. Это не плохо, но того что в моем списке более чем должно хватать для решения стандартных задач. Но термины вроде "инкапсуляция/полиморфизм/наследование" требуются в обязательном порядке подавляющем количеством интервьюверов, а стало быть знать это надо. Единственное что - рекомендую в свободное время глубже погрузиться в этот вопрос а не тупо заучивать формулировки.

Так же вещи вроде docker джуниорам знать не обязательно просто потому, что их врядли допустят сходу к управлению инфраструктурой. А так пару неделек на изучение и вперед.

можно ли сочетать какую-нибудь cms + фреймворк пхпшный типа Laravel?

Можно, OctoberCMS

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

Там нет CMS с очень высокой вероятностью.
Ибо слишком уж много там нужно писать уникального кода.

Уберите слово бизнес и все становиться понятнее, а смысл не меняется.

Авторизация по api это easy. Проходишь как на обычном сайте авторизацию высылая логин + пароль и получаешь токен. Этот токен пихаете во все последующие запросы. Никаких кук, сессий.

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

Примерная структура может быть такой:

./
index.html
src/
  /scss
    _header.scss
    _slider.scss
    ...
  /js
    /header.js
    /slider.js
    ...

После этого собираете эти модули любимым сборщиком и радуетесь структуре)

Да, конечно можно. Логотип не выезжает за пределы сетки.

А для чего robots.txt или sitemap.xml одностраничному сайту? :)
Как минимум в title есть вхождение запроса. Поэтому я бы не сказал, что он совсем без мета-тегов :)

Гугл за одни поведенческие должен этот vit-avto выкинуть

Сейчас поисковики ранжируют по сотне факторов а не только по мета тегам
не девяностые же годы

Естественно нет.

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

Всегда всё по разному. Я вот как раз и работаю за %, но буду ли я браться за тот или иной новый проект сильно зависит от 3х вещей: ниши+регион (влияет на стоимость трафика) и личности заказчика (в топку неадекватов, чудаков на букву м, скупердяев и прочих некомфортных для совместной работы личностей).

У него ниша какая? Регион? Уже на основании этого можно прикинуть фин.модель и рассчитать прибыль по пессимистическому/оптимистическому сценарию, и принимать решение.
И платный трафик (контекстная реклама, таргет в соцсетях) заказчик рассматривает, или только "бесплатное" seo? Ведь ждать полгода, пока seo раскачается и только тогда пойдут покупатели — не вариант.

sketch, figma