Andrey Chursin

Представьте такую ситуацию. У вас огромный проект с множеством составляющих, над ним работает 4-6 человек и у каждого собственные js и css к примеру, плюс ко всему вы работает с GIT-ом (а сейчас без него никуда). В девелоперской сборке творится корпоративный бардак, куча файлов, куча несжатых картинок и css-файлы на 8К+ строк.

Собственно, тут нам и понадобится сборщик, который соединит воедино все .css, .scss, .styl в один единый минифицированный css-файл. Тоже самое сделает и со скриптами, пожмет картинки и положит их в положенную папку. Вы на выходе имеете довольно оптимизированный и хорошо потерявший в весе проект. Отсюда вы грузите нужное вам на нужную ветку вашего Git-а и отправляется оттуда на сервер. В итоге на сервере вы имеете готовый продукт, без бардака и конечный пользователь не получает ничего лишнего.

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

Спрашивали на senior (всё, что удалось вспомнить):
можно ли взломать ssl
для чего нужны интерфейсы и абстрактные классы
чем отличается сервисно-ориентированная разработка от доменно-ориентированной
как сделать так, чтобы никто не смог угнать куки через джаваскрипт, как сделать чтобы нельзя было перехватить куки
кроссдоменные запросы
как добавить поле в высоконагруженную базу в таблицу на продакшене где 100 миллионов записей, без отказа бля базы
что такое партиционирование, шардинг, репликация
как работает http
что такое rest и soap
что такое репликация и как передаются данные при репликации между серверами, виды репликаций
триггеры, процедуры в базе
про способы кеширования веб приложений
джоины в базе
просили написать функцию нахождения ближайшего числа в массиве, для заданного числа
что такое рефакторинг
DIC, ServiceLocator
Какие паттерны знаешь и т.д.

CREATE TABLE `table_tmp` SELECT DISTINCT * FROM `table`;
DROP TABLE `table`;
RENAME TABLE `table_tmp` TO `table`;

Иерархия навыков упрощённо выглядит так:

1. Верстальщик (умеет только html + css)
2. Фронтендер (умеет также в JS)
3. Full-Stack (умеет и фронтенд и бекенд)

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

Фронт-энд разработчик не умеющий верстать, это как сантехник, не умеющий починить кран. CSS - это наверное самое легкое, что есть во фронт-энд, так что учите его, иначе вы не можете претендовать на его звание. Тем более на full-stack.

Как хранить исходники вместе или раздельно по разным репозиториям? Какие плюсы и минусы каждого способа?

Мне кажется тут вопрос не столько в "плюсах и минусах" сколько в здравом смысле. Мне не совсем понятно, что в конечном счёте означает "бекенд на python, фронтэнд на angular". Это два независимых проекта, способных работать автономно друг от друга и "общаться", например, через API, разработка которых происходит параллельно и независимо друг от друга, при этом какие-либо части проектов не пересекаются между собой (например, куски HTML/CSS/JS/etc кода не копируются в бекенд-часть)? Если так - то крайне логично разделить это на два отдельных репозитория, т.к. это по сути два разных проекта, связанных между собой весьма косвенно. Если же у Вас проекты имеют более прочную связь между собой или степень контаминации исходного кода выше той, что я описал ранее - то это один проект и дробить его на множество репозиториев, лично я смысла не вижу никакого (а то мы так дойдём до "давайте хранить HTML-код в одном репозитории, CSS в дургом, JS в третьем и т.д.).

P.S. Обычно, такие вещи разъясняет штатный тимлид, а не коллеги по форуму :)

Если хорошо знаете Laravel -- пишите на Laravel. Но учитывайте, что писать придется всё.
Что касается Битрикс, то у него поверх фреймворка Bitrix Framework написана полноценная CMS, которая содержит мощный интернет-магазин. Кроме того, в дальнейшем это все легко интегрируется с CRM.
Если опасаетесь модулей, не используйте их. Познакомьтесь с файлом init.php, обработчиками событий и базовым API. И пишите код в указанном файле. Немного некрасиво, но работать будет однозначно.
Также, не стоит забывать о лицензии.