Игорь

1) Большинство (если не все) лицензионных соглашений запрещают не только установку, но и использование контрафактного программного обеспечения. Т.е. использовать ПО, узнав о его пиратском происхождении, уже нельзя. Таким образом ссылаться на то, что ПО было установлено другим специалистом, практически бесполезно.
2) Маленькие компании считают, что они никому из проверяющих не нужны, большие - что у них "всё схвачено и все подмазаны". Чушь. Знаю о небольшом предприятии (порядка 200 сотрудников) пищевой промышленности в маленьком городе (50-70 тысяч населения), которое тряхнули за пиратский софт. Почему их, не знаю; рядом десятки таких же предприятий с тем же уровнем лицензионного порядка. На крупном предприятии в случае проблем как раз виновный будет один сисадмин, так как у руководства "всё на мази", а сисадмин - паршивая овца на абсолютно законном предприятии.
3) Любое письменное обращение к руководству с требованием/прошением/предупреждением о нелегальном программном обеспечении подтвердит информированность специалиста о наличии пиратского ПО и его понимание незаконности действий.

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

Начните с виртуалки, а там сами поймете

маст хев:

Понимание принципа работы ssh ключей, чтобы уметь настроить себе доступ на линукс машину или в гит (bitbucket/github/etc)

Базовое понимание git и то, что висит поверх него (github, bitbucket, etc) чтобы не путаться в пулл реквестах, понимать зачем они и как организована у вас работа - неймконвенш для веток, как ревью делается

Если пишете под докер, то Dockerfile - это в основном ответственность разработчика. Где его запускать - уже второй вопрос.

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

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

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

Вы можете продолжить коммерческое использование Java 8 без покупки каких-либо лицензий Oracle. Или вы можете использовать в коммерческих целях любую версию OpenJDK.

Подробно в ответе на похожий вопрос - Java теперь на платной основе?

Использую два способа:
1. Если задача типовая, делаю, как было сделано раньше.
2. Если задача новая, представляю, что я дебилу объясняю, что надо сделать по шагам.

1) Можешь почитать статьи от Рамблера, Варгейминга - у них вся инфраструктура идет на питоне. Там достаточно интересно рассказывается, почему был выбран питон, и какие сложности им приходится преодолевать.

2) Если коротко, то за скорость разработки ты платишь гемором при поддержке и расширении. Плюс есть некий дефицит кадров.

Так почему кто-то берет python, а не Java:

- 9 из 10 проектов будут адекватно работать на python (так как они не разростутся до уровня мега-компаний)
- многие любят python, на нем приятно писать проекты.

Самый типичный кейс интерпрайза на Питон:

1. Сделали какой-то стартапчик на питоне.
   
2. Стартап выстрельнул
   
3. Начали расширяться и расти.
   
4. Так как все было написано на питоне, остались на питоне.
   
5. Ключевые моменты стали переписывать/дополнять go/node.js сервисами
   

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

Как связать backend от Django и Frontend от Vue?

Через REST API (Django Rest Framework)

И вообще, стоит ли так делать?

Да