Vitsliputsli

Не обманывайте себя, он знает также мало, как и все остальные. Просто спрашивает он то, что знает, и разумеется не спросит то, что не знает. А получилось ли так, что ваш круг знаний не совпал с его, или действительно ваш круг знаний слишком мал однозначно сказать нельзя.
То, что вы плотно не работали с брокерами сообщений или ActiveRecord вообще ничего не значит. Тоже самое про алгоритмы, хотя тут с оговорками, смотря о чем была речь. Опять же, что подразумевается под "внутреннее устройство баз данных", если что из себя представляет B-Tree, то middle должен это знать, а если сколько раз MySQL в отличие от PostgreSQL записывает каждую строчку на диск, то не обязательно.
И это, не говоря о том, что спросить он мог не то, что вам понадобится для работы, и даже не то, что сам использует, а то что вчера прочитал на Хабре и чем решил выпендриться.

"Боюсь вас разочаровать, но это не так. Я могу написать ссылку вида site/?page=2 и отправить её через POST. Так что скажите нам какие есть еще отличия?".

Вы не найдете правильный ответ. Если бы собеседующий хотел проверить ваши знания, он бы уточнял вопрос, показывая о чем конкретно он хочет спросить. Но больше похоже на игру "я вот знаю, а ты нет". Нормальный человек обычно объяснит, что он имел ввиду.
Потому что, на такое замечание можно ответить только, что сделать можно что угодно, можно хоть вместо метода GET использовать метод в виде неприличного слова. А если его будут знать и клиент и сервер, то все будет отлично работать.
Поэтому это вопрос больше про договоренности, а если вопрошающий заявляет что ему пофиг на них, то угадать что для него важно, а что нет - очень сложно.
Например, avivasyuta вспомнил еще один интересный момент - кеширование браузером. Кто знает, может быть имелось ввиду оно, но и это ведь тоже договоренности.

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

PHP очень быстрый язык, используется в совершенно разных областях начиная от управления станками на производстве заканчивая финтехом. Выбор С#, Java, PHP, Python зачастую состоит в "тимлиду больше нравится", так здесь язык не имеет большого значения.
Почему не C++? Потому что долго и нет особого выигрыша в производительности. Так как отдельные модули требующие высокой скорости пишутся на Go или даже Си. А в остальном, дольше ждать ответы от базы и этих модулей, чем обрабатывать код Java или php.

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

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

Абсолютно не нужно, ни разворачивать фронт, ни думать что там не работает во фронте и по какой причине. У бека и фронта есть задача по реализации api в ней описано, как обращаться и что должен возвращать каждый метод. Соответственно, бек проверяет работоспособность api путем отправки запросов (через тот же Postman), и тесты тут будут не лишними. Если ошибка обнаруживается на фронте, то к беку летит баг, куда обращались, что получили в ответ, что ожидали получить.

Фронтэнд... Если какая ошибка то у него работа останавливается и он пишет просто в трелло "не работает метод такой то..."

После этого мокирует данный метод и работает дальше.

Зачем? Что вы хотите получить? Что вам не нравится сейчас?
Нет универсальных решений, чтобы все было хорошо, смотреть нужно по ситуации. К примеру, есть ли смысл контейнеризировать, на это вы сможете ответить только сами. Прикиньте плюсы и минусы, стоит ли сейчас тратить на это время, чтобы получить сомнительные (а может и нет) плюсы. Когда для всех разработчиков есть одинаковое готовое окружение - это хорошо, но когда эти все - 2 человека, стоит задуматься.
Насчет схемы, опять же, что вы хотите ей решить, что есть у вас сейчас. Если этой схемой вводите ветку dev - отлично, будет где интегрироваться разработчикам. Сказать, что это должно быть must have - да, но для спринтовой релизной системы, при rolling releases и отсутствии постоянной необходимости интегрироваться - не обязательно.
Если же хочется просто следовать трендам, то по этим вопросам docker и git-flow.

ПМ обычно не пишут ТЗ, т.к. ТЗ - это техническое задание, т.е. подразумевает техническую экспертизу. Если же речь, про некие функциональные требования, то писать обычным человеческим языком, придерживаясь правила писать то, что хотим получить и для чего, а не как это реализовывать. Этого вполне достаточно. Будет ли на основе этих требований формировать ТЗ отдельный специалист или сам разработчик, это вопрос организации компании.
Разработчик - это переводчик с человечьего языка на язык машин, если он не знает одного из языков, то беда. Поэтому этакий разработчик-интроверт, который не умеет общаться, но отлично пишет код, это проблема, т.к. переводчиком он работать не сможет.
Но как бы вы не писали ФТ или даже ТЗ, без коммуникаций во время разработки результат может неприятно удивить, отсюда и стали развиваться различные agile-направления. Насчет "писать обычным человеческим языком" тоже не нужно бросаться в крайности, а то были на моей памяти "одаренные", которые удаляли блок-схемы описывающие бизнес-логику и писали их человеческим языком в меру своих возможностей, это, конечно, уже бред.
Исходя из всего перечисленного, вполне возможно, что ваша проблема не в "правильном" написании ТЗ, а отсутствии коммуникаций и подхода "ничего не знаю, я сделал как в ТЗ" со стороны разработки. Проблема частая, но одним простым советом ее не решить.

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

Посмотрите в сторону мандатного контроля, это в первую очередь решения на основе SELinux, и основные СУБД их поддерживают.

А какова разница? В цифрах.
Post обычно подразумевает отправку данных в теле, а get в адресе. В принципе на размер запроса это не особо влияло бы, но обычно данные шлют в формате form-data, и используют громадные разделители, поэтому запрос в лёгкую может вырасти раза в 2 по сравнению с get. Второй момент, на другой стороне это все нужно ещё распарсить. Но, конечно, совсем не обязательно данные передавать как form-data.
Т.е. теоретически - да, post медленней, практически - не думаю, что эта разница сколько-нибудь существенна. И как правильно заметили, адрес не предназначен для передачи конфиденциальных данных, т.к. попадает в логи.

Если у вас "четкое" разделение на фронт и бэк, значит, по сути у вас 2 технических проекта, взаимодействующих между собой. И у них не может быть одной и той же задачи, т.к. делают они разное.
Судя по остальному тексту, вы не декомпозируете задачи, отсюда и такие вопросы. Тогда, у вас 2 варианта, начать декомпозировать задачи на отдельные подзадачи, где будет отдельный исполнитель, можно прикинуть трудозатраты, указывать зависимости и т.п. К тому же, в redmine из коробки можно строить древовидную структуру задач. Тогда у вас появится хоть какой-то контроль и вы сможете планировать. Либо не заморачиваться, т.к. 1 или 2 задачи на ситуацию не повлияют, и пусть разработчики сами делят задачи и планируют.

Как уже советовали git-flow (например от Винсента Дрейзена). У разработчиков есть право мержить в dev свои ветки, поэтому request не нужны (они хороши при запросах от удаленных разработчиков), из dev собираете и прогоняете тесты ежедневно (CI), затем из dev собираете релиз и кидаете его в master, это уже делает отдельный человек. На сервере (если речь про прод) git быть не должно, должен быть нормальный CD. И да, никаких доступов к боевым у разработчиков. В остальном верно описали.

Вы предлагаете проверять перед каждым созданием наличие такой записи?

У вас это и так происходит, иначе бы не было ошибки. Если вам действительно все равно на недобавившиеся строки, тогда скажите об этом СУБД, on conflict do nothing, или что-то в этом роде в зависимости от СУБД.
Но почему-то мне кажется, что ваши пользователи не согласятся с такой логикой.

Если вы про кеширование в браузере, то да, верно проверяете. Все URL разные, поэтому браузер их каждый раз загружает, а не берет из кеша. При повторной попытке загрузить ресурс по уже использовавшемуся URL, браузер возьмёт его из кеша.

Я не совсем понимаю как правильно написать коммит чтобы понятно было и мне и другим.

Что-то типа этого:
"PROJ-237. Добавлено описание продукта на странице 'О товаре'"
и если позволительно, то лучше на английском. PROJ-237 - номер задачи в вашей любимой системе управления проектами.

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

Избавьтесь от формы "выгружать в git", с git вы должны работать постоянно, а не выгружать в него. Сборка для тестирования должна быть такой же как для продакшн, иначе подобные ошибки будут вас преследовать постоянно. Автоматизируйте сборку, и не будет вопросов "деплоить после каждого чиха?".

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

Раз вы работаете в Gitlab, то у вас уже есть инструмент для организации CI/CD.

1. Хорошая ли идея стягивать все исключительно по тегам т.е. поставил я на фронте и на беке тег v0.4 и скрипт на сервере стянул и то и другое

Нет, это не очевидно и усложнит работу, если репы разные, то и версионирование у них должно быть разное. Если вам нужна последняя версия, вытаскивайте сразу master. А для обновления подключаемого внешнего ПО используйте специализированные программы (тот же composer в php).

2. Самонаписанный скрипт постоянно чекающий теги гитлаба это вообще идея хорошая? В чем +\- деплоя по тегам?

А зачем постоянно чекать? В Gitlab есть хуки, если нужно какие-то действия осуществлять по push.

3. Как быть с адресами и портами. К примеру в index.js на девелоперской машине у меня прописано windows.base_url = "localhost:1234" а на сервере мне нужно "10.1.2.6:9000" как это это автоматизировать?

Все настройки должны быть в конфиге, при деплое конфиг настраивается в зависимости от среды. Можно сделать разные файлы для каждой среды, но все равно что-то придется менять конфиг при сборке (например, пароли к БД вы же не будете держать в репозитории).