Я этого не писал. Всем вакансиям нереально соответствовать.

Давайте по пунктам) 1. Ничто не вечно, некоторые знания/умения со временем обесцениваются. Раньше быт охотником добывающим дичь было жизненно необходимо, сейчас это уже хобби. Это не минус рынка - это жизнь) 2. Без опыта конкретного инструмента - требуется время на его изучение, обучение, ошибки. Когда опыт есть - обучатся не нужно. Выбирать соискателей по «потенциалу», вместо фактических знаний инструментов может привести к большим бедам 3. А за что платить большие деньги, если запрос на низкоквалифицированного специалиста?

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

1. Некоторые опыт/знания - да. Но когда они обесцениваются, на мой взгляд, по надуманным причинам, то это минус. Отличаются ли REST или SOAP от языка к языку? Отличается ли работа с IDE и таск-трекерами? Паттерны проектирования? Софт-скиллы? Проектная рутина? Принципы ООП, SOLID, KISS, DRY? Только если с поправкой на синтаксис и особенности языка, которые, по большей части, закрываются знаниями, не опытом. Всё остальное - рубль в рубль.

2. Даже с опытом конкретного инструмента последует адаптация под конкретный проект/продукт/команду. Все равно первые 1-3 месяца специалист будет тормозить. Отсутствие опыта с конкретной технической единицей хуже почти не сделает.

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

1. Знание протокола soap - классно что есть, но можно ли это знание применить не зная инструментов, к примеру вы знаете что есть гвоздь, какой он, но не умеете пользоваться молотком - будет ли от вас польза если требование забивать гвоздь молотком? Работа с ide отличается, разный функционал, разные возможности, разные хоткеи и тд и тп. Работа с таск-трекерами тоже разная, redmine jira yougile - об одном, но очень разные. Софт скилл это не хард. Проектная рутина, если требуется по вакансии здорово, если нет - то а зачем? Ооп паттерны - здорово, но это требования сейчас везде, а не что-то уникальное. 2. Адаптация нужна, но срок меньше, так как идет адаптация только под продукт, а не под новый инструмент -> время на получение прибыли/пользы от работы меньше. 3. Тут я скажу вопрос ваших запросов, кто-то комфортно может жить и на 20к и не возмущаться и возможно запросы просто нереальный относительно текущего рынка, то есть требовать того чего не существует на данный момент)

1. Как раз таки умею молотком пользоваться. Разница для нормального специалиста будет в том, что у вашего молотка ручка другая или боёк другой формы.  Работа с IDE отличается на уровне состава горячих клавиш и расположения кнопок в меню. Вам так нужны тонкие особенности внутри конкретной среды? Типовые операции (написание кода, отладка, компиляция и т. п.) везде реализованы похожим образом.  Таск-трекеры - тоже. Разработчику нужно лишь знать, как создавать и двигать задачи, а также наполнять их.  Под проектной рутиной я, скорее, имею ввиду опыт работы на реальных проектах. У стажёров его, например, нет.  Опыт с паттернами тоже везде нужен. Это не языкозависимый скилл.  2. Нормальный специалист способен адаптироваться параллельно и под инструментарий, и под проект.  3. Я не про уровень зарплат, а про уровень потребления. С возрастом он растёт. Родители уже не помогают, здоровье начинает требовать внимания и т. д. Тех, кто это игнорирует, я не могу воспринимать всерьёз.

1. Вот в примере с соапом, вы знаете гвоздь, а не молоток. Так как с помощь библиотеки которая умеет работать с соап вы заставляете приложение отправлять запрос, получать ответ. Так же как молотком вы вбиваете гвоздь или выдергиваете его, а изучив другую библиотеку вы расширяете свой инструментарий, как если бы изучили как работать с пневматическим гвоздеметом. А гвоздь какой был, такой и остался, соап какой был такой и остался) 2. Читая 2 книги вместе упускается много смысла, нежели если читать только одну. 3. А рост уровня потребления - это проблема компании?

1. Работая 10-15 лет с разными инструментами, опытному специалисту труда не составит выучить новый в кратчайшие сроки при помощи методов индукции и дедукции. 2. Так предлагается не книги читать, а щупать инструментарий и погружаться в детали проекта. 3. Нет, так же как и для работника рост уровня требований, кредитной ставки для бизнеса или количества откликов. Но мы же тут про взаимовыгодное сотрудничество, а не решение проблем компании за счёт сотрудника.

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

Я обобщу свой ответ.

Я лишь расписал свой субъективный взгляд со стороны кандидата. Он никак не поменяется от большей или меньшей выгоды для компании, так как я могу только рассуждать со своей колокольни. Преференции противоположной стороны меня касаются, только если у нас договор о взаимовыгодном сотрудничестве.

Почему-то я начал скроллить дискуссию и не понял в итоге истины 😂

Истина в отсутствии истины)

До истины не дошли: мои наблюдения обратно коррелируют с позицией оппонента 😊