мейвен надо все таки знать.

А что бывает по-другому?
------
Процентов у 80 нынешних ИТшников оно именно по-другому.

Это невозможно. Судя по документации и коду плагинов его сами аффтары не знают :)
Я бы сформулировал как: надо знать что такое maven, что такое плагины и выучить магическую фразу "документация на этот плагин неполная, надо смотреть исходники" (верно для 99% мейвеновских плагинов).

Ага. А с программированием вы в эти 3 года как-то пересекались? Потому как их этого описания видно только что вы занимались анализом данных.

Maven простой как 3 копейки - главное понять основную структуру проекта, lifecycles, и наследование в многомодульных проектах - после этого достаточно идти на страницу конкретного плагина чтобы найти как называются опции и goals

Ага. А следующий шаг - биться головой об стенку.
Потому что один плагин не спрашивая (convention over configuration жа!, чо, все так делают!) расширяет список каталогов с исходниками, второй, наоборот игнорирует этот расширенный список и обрабатывает только то, что лежит в main/java, третий втихомолку пользуется настройками maven-compile, а узнать об этом можно только посмотрев в исходники, потому не удивляемся когда поменяв кодировку для компайлера с latin-1 на utf-8 у нас внезапно перестают нормально генерироваться ресурсы. Следующий молчит как партизан и не признается как его заставить переписывать созданные файлы. Документация? Не, не слышали, зачем тебе? сonvention over configuration жа. Все работает из коробки. Ну а что не работает - то судьба такая.
Иерархические pom-ы, наследование от родителей, переопределение параметров, настроек плагинов и прочая и прочая. Вопрос. Как найти в каком именно поме из иерархии параметр был переопределен? effective-pom по всем 14 уровням... (рвёт на себе волосы, рыдает, уходит в запой)
Не надо мне про мэйвен, мне с ним регулярно воевать приходится. У моей группы одна из ответственностей - разработка и поддержка плагинов для этого сволочизма.
Мэйвен хорош если надо быстренько на коленке что-то склепать - раз, сделал структуру каталогов, выбрав нужный архетип, два - написал пару классов, три - уже собрал jar, war, ear что тебе надо. Но как только что-то сложное попадается, чесслово, антом было проще. Т.е. в принципе все работает, если тебе нужно именно то, о чем думали авторы плагина, и если твой use case четко совпадает с одним из двух, которые они соблаговолили описать в документации. Но не дай бог сделать шаг в строну.
Вообще, спор maven vs. ant или они же против make это как с языками программирования... Но, елки-палки, как достало в 100-й раз слышать в ответ на "как поменять эту настройку" - "ну ты что, это ж convention over configuration, оно по дефолту завсегда так", только у всех авторов плагинов какие-то свои представления о стандартных значениях...
P.S. Мое любимое - как удалить или скопировать файлик? Используйте maven-antrun-plugin. Что из таких советов выходит? Ленивые разработчики тупо копируют свои старые антовские скрипты в пом-ы и радостно рапортуют о миграции на maven. Профит, №^&%.

Госпидя, какие ужасы. Почему у меня в проектах не возникает странных желаний? Конкретно по вопросу: resources:copy-resources? Не, не слышал.

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

Не-а. Оно только копирует. Удалять оно не умеет-с, может только после clean-а в пустой каталог все скопировать. Иногда надо генерировать код или ресурсы не в target, и не в основном lifecycle. Потому что генерирование занимает 2-3 минуты (а то и больше). И прикаждом clean install ждать - и разработчики и тестеры воют. Ну так у нас convention over configuration, плагин все одно уверен что все что он сгенерирует в clean-е само по себе, "мэйвеновским колдунством" уберется. Приходится помогать ручками.
Да, вынести в отдельный артефакт - низзя. При каждой сборке проверятся актуальность исходников, и еще парочка ограничений от безопасников.

ДА!!! Это хорошая перспектива, с моей точки зрения. За питон не беспокойтесь. Соглашайтесь.

Если вы никогда не работали по специальености после 96-го года прошлого века, можете выкинуть его.

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

Это нормально, ВУЗ не может вас научить всем профессиям ИТ индустрии.

Скажем так, математикам в программировании делать нечего. Программирование это инженерная наука. На самом деле это ваша слабая сторона.
Все важные алгоритмы уже давно имплементированны в в библиотеках, чем программисты невозбранно и пользуются (привет Дональду нашему Кнуту).

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

Это хорошая идея, портфолио программиста говорит о нем больше, чем самый хороший бевербунг.

Можно, но занимаются этим не программисты а оперейшн/дев оперейшн абтайлунг. Хотя да, программистом не помешает знать малость об этом.

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

Всегда пожалуйста, если что, обращайтесь.