Современный найм — отстой

    Прежде чем начать сей вопль отчаяния, вызванный безумием этого мира, хотелось бы кратко сказать о себе — рограммист, руководитель программистов (нанимался и нанимал), значительный опыт разработки только на языке Perl.

    Perl — это когда-то бывший популярным для веба, но ныне умирающий, язык. Умирающий вполне обоснованно, поэтому хотелось бы слезть с него на что-то массово востребованное (Java).

    Проблема


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

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

    Т.к. ИТ сфера достаточно новая, то не всем понятно почему это полнейший идиотизм. Для понятной иллюстрации разберём в качестве примера столярные работы. Если вам нужен столяр для изготовления деревянного стола, то вы не будете в вакансии писать что-то вроде “опыт работы железными фальцгебелями с пластмассовыми ручками”. Не исключаю, что вы напишете: “требуется опыт изготовления столов”, это хоть как-то можно понять, но и это не обязательно. Разве у кого-то есть сомнения в том, что хороший столяр может изготовить стол?

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

    Пример со столяром это конечно лишь аналогия, он облегчает понимание, но не даёт полной картины. Например, выдвигать программистам требования к владению инструментами ещё более глупо чем к столярам, ведь у столяров набор инструментов изменяется предельно медленно, а у программистов инструменты изменяются с космической скоростью. Программирование подразумевает постоянно изучение нового — сегодня вы нанимаете человека для работы с одними технологиями, а завтра ему придётся использовать другие. Я хоть и не client-side разработчик, но хорошо помню, что в 2007 году на клиентской стороне популярными библиотеками были jQuery и ExtJS (как сегодня ReactJS и Angular), а в 2017, когда я выступал на конференции The Rolling Scopes #37. Gomel выяснилось что в большом зале всего несколько человек помнят такие названия. И так везде — все постоянно внедряют новые технологии и никого почему-то не смущает, что текущие сотрудники не имеют опыта с этими технологиями (а если технология достаточно новая, то может быть, что во всём мире нет людей с опыт работы с ними). Помимо этого можно сказать, что программисты, в отличии от столяров, занимаются сложными задачами в достаточно новой сфере человеческой деятельности, ещё почти нет накопленного и тиражируемого отраслевого опыта. Это столяр может взять учебник или справочник с огромным количеством чертежей различных столов или проконсультироваться у более опытного специалиста, а в ИТ сфере этого нет — даже в типовых задачах вроде разработки сайтов нет готовых решений, например популярные и давно существующие CMS нередко в новых версиях переделывают свою архитектуру в поисках хорошего и универсального решения. А если взять чуть менее типовой проект, то будет совсем печально.

    Исходя из сказанного можно понять, что опыт работы в аналогичных проектах (в отличии от опыта с теми же инструментами) ценен. Оно и понятно — если человек работал в той же сфере, он знает предметную область (имеет в голове её модель), набил какие-то шишки и уже может делать лучше, чем делал в первый раз. Если не ошибаюсь, у Фредерика Брукса было утверждение, что программа становится хорошей, только после того как она переписана три раза, так вот, если вы нанимаете человека, который один раз уже написал, то вам остаётся всего два. Однако, как уже было сказано, найти человека с опытом в таких же проекта очень сложно и дорого. Подумайте сколько в мире людей создававших таск менеджеры (вроде Redmine)? Писавших биллинги хостинга? Создававших мессенджеры? Их опыт очень ценен если вы разрабатываете аналогичный проект, да вот только найти и нанять их предельно сложно по множеству причин.

    Кто виноват?


    Не знаю, точно не HR’ы, они играют как скажут. Может на самом деле всё нормально в этом мире, а я ненормальный.

    Что делать?


    Думайте хорошенько прежде чем сформулировать требования к кандидату. Ведь хороший программист должен уметь учиться, а значит способен освоить любые нужные вам технологии. А раз дело не в технологиях, то в чём? Очевидно, что он должен уметь программировать, решать алгоритмические задачи и это нужно проверять давая тестовое задание. Но надо делать это тестовое задание близким с реальной работе — если вы нанимаете системного программиста, то вполне допустимо дать ему задание требующее знания алгоритмов и т.п., чтобы проверить не только способность программировать, но и знания накопленных практик (в системном программировании как раз есть некий накопленный опыт, это старейшая часть отрасли, да и растёт корнями в более старой математике). А если вы берёте прикладного программиста, то вам надо проверить способность писать простой, ясный, читаемый код правильно решающий задачу и способность учиться и с высокой вероятностью вы получите нужного человека.
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 177
    • 0
      Кто виноват?

      Не знаю, точно не HR’ы, они играют как скажут.


      Но и не менеджмент любого ранга непрограммистского толка. Они не отличат JS от Java.
      Значит проблемма все равно внутри программистского сообщества.
      • 0
        Виноваты HR-ы и PM-ы
        Project Manager-ы дают требования по технологиям исходя из проектной необходимости. HR-ы отбирают кандидатов по простому соответствию того, что указано в резюме кандидата и тому, что написал PM. Соответственно до интервью доходят только те, у кого резюме соответствует требованиям.
        К тому же всем нужны готовые специалисты и мало кто готов дать 1-2 месяца чтобы научиться и разобраться в новой технологии.
        Что делать программистам (особенно умирающих языков):
        — Подгонять резюме под вакансию. Если написан Angular2, то пишем Angular 2 и оставшееся время до интервью зубрим теорию и делаем тестовые проекты.
        — Учить новые языки и технологии. Если видите в вакансиях React — то изучите его
        — Участвуйте в Open-Source проектах или заведите свой домашний проект, где вы будете обкатывать новые языки и технологии. А когда пойдёте на интервью, то будет что показать…
        • +4
          А жить когда?
          • +1
            2-3 часа в неделю вполне достаточно для того, что я выше перечислил.
            Подгонять резюме и осваивать технологии, требуемые в вакансии — такое случается только при смене работы, т.е. раз в 3-5 лет.
            Программирование настолько быстро развивается, что даже если интенсивно изучать новое, создаётся впечатление, что ты отстаёшь от поезда. А если забить и не учить, то придётся потом остаток жизни работать во второсортной фирмочке за скромную зарплату.
            • 0
              Хотите или не хотите, чем-то придется жертвовать. Как правило, 8 часов в день по будням — это достаточно, чтобы сидеть на тёплом месте, но обычно мало для того, чтобы двигаться вперед. Поэтому вы или жертвуете часть вашего досуга на своё развитие, или жертвуете развитием. Ничего плохого в первом варианте, особенно когда молодой и без семьи, я не вижу.
              • 0
                Ну а если возраст за 40, и работа это просто источник дохода для жизни — то как быть? Как не красноглазить, здоровье оно не вечное?
                • +2
                  Вы знаете, вопрос из серии «Как что-то получить, потратив как можно меньше усилий?», он не имеет четкого ответа. Можно в лотерею попробовать сыграть, вдруг повезет. Ну или внимательно смотреть по сторонам, когда идешь по улице, вдруг где-то кошелек валяется.
                  Могу сказать по своему примеру. Мне не за 40, но мне самое что ни на есть «под 40», так что этот вопрос для меня отнюдь не чуждый. У меня родители-пенсионеры, жена в декрете и маленькая дочь, ответственности хватает. А три года назад я потерял свой дом, да и в общем-то весь свой город.
                  И я стал красноглазить, как в юности. И знаете что? Не так уж это и страшно оказывается для здоровья, особенно когда жареный петух в задницу клюнул.
                  Мой товарищ, например, в той же ситуации вообще в 37 лет выучился на программиста с нуля, до этого он обувь продавал в своем магазине в том же городе. И ничего, поработал джуном, теперь уже миддл, неплохо знает кучу JS-фреймворков и ухитряется держаться в тренде даже в той мешанине, которая творится в мире JS. Так что моё ИМХО, все эти разговоры про «как тяжко работать, если тебе за...», это просто отмазки. Если сильно надо, то всё получится, лишь бы ленивую попу поднять. Проблема скорее всего в том, что чаще не настолько уже и надо.
          • +1
            В одной компании где работал, для всего отдела HR проводились курсы которые давали представление о предметной области. Курсы проводили руководители соответствующих отделов. Т.е. тех HR которые искали C++ программистов обучали базовым понятиям плюсов, таже безопасность, шарп и т.д. В итоге HR'ы понимали кого ищут, и качество набора реально возрастало, а также качество фильтрации на предсобеседовании. Сравнивая с текущим местом работы вижу насколько неэффективен поиск когда кадровики не разбираются совершенно.
          • +9
            Как-то поверхностно сравниваете столяров с программистами. Сравнивайте обычные вакансии столяра с программистом-интерном. Дальше столяр-краснодеревщик, мебельщик, столяр-фрезеровщик, ЧПУ-шник и т.д.

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

            И зря вы так возвышенно относитесь к программистам, не льстите себе. Большинство (не все) делают обычные сайты, фронтэнд. Что здесь уникальнее изготовления мебели на заказ? Или вы про тех программистов, кто алгоритмы пишет новые? Так и столяры бывают искусники резьбы по дереву…

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

            Хотите, чтобы требования к программистам были как у столяров? Вывесите резюме с ожидаемой зарплатой как у столяров с аналогичным опытом работы. Вас быстро возьмут на работу.
            • –1
              > Большинство (не все) делают обычные сайты, фронтэнд.

              в таких сферах думаю и набирают студентов, да учат их
              • +4
                как то вы недооцениваете сложность современного фронтенда
                • 0
                  Или вы переоцениваете?=) Какое нужно было образование для реализации фронтенда (или даже простенького бекэнда)? И сравните со временем на обучение для реализации конечных автоматов, алгоритмов, физических движков, математических моделей etc.
                  • 0
                    Можно нанять студентов и сделать дёшево.
                    Можно нанять профи и сделать качественно.
                    Можно нанять пару профи и десяток студентов и сделать хорошо.
                    • 0

                      Реализация многих алгоритмов заметно проще современного фронтэнда. А уж реализация конечного автомата вообще примитивна, вот его составление — это в общем случае и правда сложная задача.

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

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

                          • 0
                            Для этого их, конечно, нужно знать и нужно понимать чем они отличаются, но это за полгода учится без напряга даже одновременно с работой (особенно одновременно с работой).

                            Неправда, для этого есть пять лет высшего математического образования. Даже интересно, как вы за полгода подтянете двух годовой курс тервера для работы с попсовой нынче bigdata на хорошем уровне. Или трехгодовой курс матан+ТФКП+числ методы для выбора оптимального (или допиливания существующего) алгоритма обработки хитрой системы уравнений.

                            Я имел в виду задачи более широкого спектра, чем выбрать нужный алгоритм сортировки или даже решения задач линейного/динамичного программирования.
                            • 0
                              Я имел в виду задачи более широкого спектра

                              Вот здесь вы совершенно однозначно написали про реализацию существующих алгоритмов и всяких конечных автоматов:


                              И сравните со временем на обучение для реализации конечных автоматов, алгоритмов, физических движков, математических моделей etc.

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

                    • 0
                      на самом деле я считаю современный фронтенд переусложнённым, и мне кажется поэтому там кроме работы требующей опыта, есть масса рутинной работы для стажёров
                  • +2
                    Можно уточнить, вы про РФ пишете, что соискателей больше, чем надо рынку? В Канаде я вижу обратную картину, большой недостаток кодеров. Конечно, зависит от отрасли, много смуглых ребят с ограниченными навыками, но если опыт от 2-3 лет, то можно выбирать работодателя.
                    • 0
                      Мне кажется это вообще про какую-то другую планету речь, пока на Земле везде дефицит ИТ специалистов, недавно были слухи что в Индии сокращения, но непонятно насколько надёжные.
                      • 0
                        Смотреть по-разному можно. Еще пять лет назад в моем городе на hh.ru каждую неделю был пяток вакансий инженеров-интернов. По факту надо было учиться, а тебе за это денежку хоть и символическую платят. Сейчас такого нет.

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

                        Где дефицит кроме как в головах менеджеров?
                        • –1
                          Насколько помню пока везде общее количество вакансий в ИТ было больше чем соискателей.
                          • 0
                            Вот только сегодня на статьюнаткнулся, конкурс на ИТ вакансии 2.9 человека на место.
                            • –1
                              Но при этом там же написано «Особая история — IT-специалисты: из-за повсеместной цифровизации бизнес-процессов они сегодня в большом дефиците.», видимо часть соискателей хоть и хотят работать в ИТ, но никому не годятся.
                              И есть оценки величины этого дефицита — habrahabr.ru/company/infowatch/blog/328790
                              • 0
                                Не увидел оценки дефицита, увидел только прирост количества вакансий.

                                Вот смотрите, если я скажу — очень тяжело найти толкового столяра-краснодеревщика. Означает ли, что дефицит столяров? А мой друг скажет, что невозможно найти хорошего страховщика недвижимости. Здесь тоже дефицит?

                                Тогда можно вообще поставить вопрос так, что со всеми специалистами дефицит.
                                • –1
                                  Ну да, специалистов дефицит.
                          • +1
                            Мы не знаем как искать человека, который нам подойдёт. Я в этом честно признаюсь.
                            • +1
                              вы не знаете как искать != дефицит кадров
                            • 0

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

                              • 0
                                Так про любую профессию можно сказать, а не только ИТ. Применительно к статье столяров-ЧПУшников с хорошим опытом тоже днем с огнем не сыщешь.
                                • 0
                                  Ну мы-то про ИТ — хороших специалистов дефицит, а фильтруют так, что могут таких и не найти.
                                  • +1

                                    Разница в нехватке кадров — на порядок. У меня есть знакомый инженер оптик с высшим образованием по специальности и стажем уже 5+ лет. Ему не сыпятся предложения о новой работе даже раз в месяц. В аналогичных условиях программисту необходимо настраивать спам фильтр в почте и временами отпинываться от эйчаров по другим каналам связи.
                                    У вас есть другое объяснение этому явлению кроме принципиально другого уровня нехватки кадров? У меня — нет, но может быть я что-то упускаю из виду?

                                    • 0
                                      Ну не надо все сводить к тому, что программисты такие исключительные и их так не хватает=)
                                      Погуглите маржинальность и ROE бизнеса по отраслям, вы увидите, что стройка волс, или чем там занимается ваш знакомый, значительно ниже ИТ. Есть возможность переложить затраты на капитальные мощности в фонд оплаты труда.
                                      • 0

                                        Я ничего никуда не свожу. Есть факт — программистам с опытом пишут с предложениями работы постоянно и чем больше опыта тем больше. Я не знаю ни одной другой профессии в которой такое бы происходило. У меня есть объяснение: дефицит кадров больше чем в остальных областях.
                                        Вы утверждаете что дефицит кадров есть везде. Тогда объясните предъявленный факт другой теорией и, если в ней не будет логических ошибок, то я соглашусь что ваш вариант также может быть.


                                        P.S. В данном комментарии слова "везде" предполагают возможное наличие одиночных исключений.

                                        • 0
                                          Это касается любой высококвалифицированной работы.
                                          • 0

                                            Что "это"? Я точно могу сказать что журналист или инженер на заводе не начинает получать нескончаемый поток предложений о работе через полтора-два года стажа. Так что нет, факты говорят что мой вариант не касается любой высококвалифицированной работы. Если вам в данных примерах не хватает квалификации, то тоже самое можно сказать и про, например, астрономов с высшим образованием. И, наверняка, про других ученых тоже.

                                            • 0
                                              А вот нейробиолог, пилот самолета, те самые астрономы, которых Китай даже большими деньгами к себе приманить не может, без работы не сидят.
                                              • 0

                                                Не сидят. Но и потока интересных предложений у них нет. А у программистов есть.
                                                Я не до конца понимаю вашу позицию: вы пытаетесь утверждать что приведенный мной факт не существует или у вас есть отличное от моего объяснение этому факту?

                          • 0
                            Иногда от соискателя требуется владение определенным инструментарием для быстрого вхождения в проект. Ведь никто не будет двигать сроки для того, чтобы новый сотрудник успел все освоить.
                            • +2
                              да, но тогда придётся двигать сроки из-за поиска такого кандидата, уж больно разнообразны инструменты в ИТ сфере
                              • 0
                                Да и кандидатов не так мало. Другой вопрос — в стоимости его работ
                                • 0
                                  Если это не дикий эксклюзив, то сроки не пострадают. 2 недели должно хватить всем.
                                  Правда проект должен быть на должном уровне по документированию и хранению кодовой базы.

                                  В вашем примере «железные фальцгебели с пластмассовыми ручками» — больше похоже на требование использования конкретной IDE.
                                  А вот умение работать на фрезерном станке — было бы ближе к требованию по конкретному стеку технологий.
                                  • 0
                                    Не, конкретный стек технологий это умение работать на конкретном фрезерном станке, а не понимание работы на фрезерном станке.
                                    • +2
                                      Ок, есть столяр, который умеет работать молотком, рубанком, долотом и прочим инструментом на верстаке.
                                      Опыта работы на станках — 0.
                                      В компании используются станки. Верстаков нет.
                                      Какова будет польза от такого столяра?
                                      • 0
                                        Со столяром сравнить предлагаю так. Вы можете просто попросить соискателя выстругать вот такого офигенского питона с синим слоном в руке, используя свои, привычные инструменты. Получился офигенский конь за допустимое время? Слон правильно ориентирован по сторонам света? Ок, берите его на работу. С программистом как быть? Репутация и финансы фирмы пострадают, если он напишет новый браузер на Delphi вместо С++? Или отбросит IDE и будет все ваять через блокнот? Результат тот же? Браузер пашет? Так в чем проблема?
                                        • 0
                                          Вы ушли мимо контекста ветки.
                                          • 0
                                            А вы откажете столяру только потому, что он не умеет на станках? И неважно, что без них результат его работы может превосходить вон тех десятерых со станками? Что, нельзя будет ради такого купить верстак?
                                            • +1
                                              А вы не откажете столяру только потому, что он не умеет на станках?

                                              Откажу. Потому что те на станках делают в N-раз больше продукции, чем тот на верстаке, а значит приносят в N-раз больше прибыли.

                                              • +1
                                                С учетом, что производительность на верстаке будет ниже, а допуски скорее всего не будут соблюдаться, то все выльется в зря потраченные ресурсы.
                                            • +1
                                              Результат тот же? Браузер пашет? Так в чем проблема?

                                              Проблем много.
                                              Одна в том, что программисты не пишут браузеры в одиночку. И если у вас десять программистов пишут на JavaScript, а один гений на Delphi, они друг с другом будут фигово состыковываться в одном проекте.
                                              Другая в том, что ваш программист с вами не навечно. И если он круто пишет на чем-то странненьком или редком, то вам надо иметь в виду, что вам нужно будет потом ещё одного такого же искать.
                                              • 0
                                                Спасибо, довольно доходчиво.
                                              • 0
                                                Во первых, очень редко где требуются создатели продуктов с нуля — обычно основную часть времени сотрудники тратят на работу с существующим кодом. Даже микросервисы не очень помогают — накладно закреплять за каждым сервисом отдельного человека, владеющего нужным стеком технологий, для поддержки.
                                                Во вторых по качеству выполнения тестового задания (на которое соискатель не может потратить много времени) не всегда удается оценить, на сколько качественно будет выполнен сложный долговременный проект. Да и, даже если соискатель выполнит большой проект, скажем опенсорсный, сделанный для других целей, проверить, на сколько хорошо он сделан не дешево — фактически надо проводить полноценное тестирование и code review.
                                              • 0
                                                Такая же как и от тех кто владеет станками — он специалист во всех отношениях и может хорошо работать, а станок освоит за пару дней.
                                                • 0
                                                  Да этот столяр Match3 откроет и офигеет.
                                                  Да и через пару дней хорошо если научится станок с программой запускать.

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

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

                                                  Писать то, что человеку нужно 2 недели на освоение технологии, может только человек, который никогда не плакал, глядя на код, написанный сишниками с 10 летним стажем на Ruby on Rails.
                                                  • 0
                                                    Так это уже не столяр, совсем иная специальность, это примерно как сравнивать бухгалтеров и программистов 1С
                                        • +2
                                          За то время, как они ищут того, кто уже владеет мог бы переквалифицироваться не один программист.
                                          • 0
                                            Смотря какой инструментарий. У нас готовы брать разработчиков, готовых и способных переучиваться на Scala, так как свободных Scala-программистов найти проблематично. Знакомые из других организаций, использующие Scala или Haskell, говорили, что у них то же самое — часто берут, расчитывая на переучивание.
                                            • 0
                                              И какая статистика по скорости освоения новой технологии?
                                              • 0
                                                Двое джавистов вполне прижились. И учились не сильно дольше, чем все равно требовалосб для вхождения в предметную область.
                                                • 0
                                                  Ну так Scala же. Это с Java смежные инструменты разработки, и переходить с одной на другую — все равно что менять VB.NET на C#.
                                                  • 0
                                                    В принципе — да. Но я слышал отзывы, что с C# переходят на Scala даже быстрее, чем с Java.
                                                    Сам переходил с Haskell (и не до конца забытого C++), экосистему jvm практически не знал. Но оказалось, что в sbt простые вещи делаются просто, а без maven вполне можно обойтись. Так что проблем не возникло.
                                          • +5
                                            А если вы берёте прикладного программиста, то вам надо проверить способность писать простой, ясный, читаемый код

                                            Как я могу взять прикладного программиста на C++/Qt, если тот не имеет соответствующего бэкграунда? А сеньор на PHP/Perl пойдет работать джуниором на C++

                                            • 0
                                              что вы подразумеваете под бэкграудом?
                                              • +2
                                                Опыт работы. Если опыта маловата, то можно поспрашивать знания из книг.
                                            • 0
                                              Ну мне кажется, что всё в принципе логично. Все эти правила по сути устанавливаются самими программистами и они решают кто им нужен в команду.
                                              • +5
                                                Т.к. ИТ сфера достаточно новая, то не всем понятно почему это полнейший идиотизм.

                                                Нет, это не идиотизм, и не нужно программистов сравнивать со столярами. От столяра требуется сделать один конкретный продукт. Пусть делает его так, как умеет. От программиста зачастую требуется влиться в команду, которая уже работает с каким-то конкретным набором инструментов. Если программист им уже владеет, он будет тратить время на изучение проекта. Если программист не владеет инструментарием, он будет тратить много времени на первых порах ещё и на изучение инструментария. Поэтому первый вариант чисто экономически предпочтительнее. При прочих равных лучше тот, кто уже имеет подходящий опыт.
                                                у программистов инструменты изменяются с космической скоростью

                                                У JS-программистов. В остальных сферах фреймворки и инструменты успешно живут годами, лишь прирастая фичами. А некоторые — десятилетиями.
                                                • +1
                                                  От столяра требуется сделать один конкретный продукт. Пусть делает его так, как умеет.

                                                  Вы недооцениваете работу столяра :(
                                                  При прочих равных лучше тот, кто уже имеет подходящий опыт.
                                                  Как быть при неравных, например, программист с десятилетним стажем без знания фреймворка vs. программист с 3 летним стажем, но со знанием фреймворка?
                                                  • 0
                                                    Как быть при неравных, например, программист с десятилетним стажем без знания фреймворка vs. программист с 3 летним стажем, но со знанием фреймворка?

                                                    При неравных надо смотреть и думать :) Но «тезисно» сам по себе факт, что у кого-то стаж десять лет, а у кого-то три, ни о чем конкретном не говорит. Три года опыта вполне достаточно, чтобы стать неплохим самостоятельным миддлом.
                                                  • 0
                                                    > Если программист не владеет инструментарием, он будет тратить много времени на первых порах ещё и на изучение инструментария.

                                                    изучение инструментария это мелочь по сравнению с изучением проекта
                                                    • 0
                                                      изучение инструментария это мелочь по сравнению с изучением проекта

                                                      Это так, если происходит в рамках одного языка и сравниваются фреймворки. В случае разных языков мидл на java и мидл на perl, это как слесарь-сантехник и столяр. Оба хороши в своих стезях, но не обладают должной экспертизой в другой области.

                                                    • –1
                                                      > У JS-программистов. В остальных сферах фреймворки и инструменты успешно живут годами, лишь прирастая фичами. А некоторые — десятилетиями.

                                                      такое бывает, но не думаю что это правило, в серверной части точно также всё меняется, взять перл — сначала для параллельного программирования был популярен POE, потом Coro, потом AnyEvent, а потом народ поуходили на всякие node.js/Go, а самые умные на Erlang/Elixir
                                                    • +2
                                                      Слишком обще написано. Сейчас вполне можно найти человека с опытом React+Redux и на Angular 1.x и даже на Angular 2/4. Работодатель просто не всегда хочет платить за то, чтобы синьор за много денег обучался новому стеку, если на рынке уже достаточно тех, кто имеет опыт.
                                                      Плюс, когда вы берёте человека с опытом, то этот опыт поможет вам улучшить вашу технологию разработки. Потому что тот же React+Redux тоже надо уметь готовить и набивать шишки. Человек без опыта, скорее всего, будет просто повторять методы, которые уже используются в проекте.
                                                      Если вы говорите о какой-то экзотике, то тогда да, дешевле и быстрее научить, чем искать опытного.
                                                      Я бы на вашем месте написал какой-нибудь проект на React+Redux или на Angular, чтобы разобраться в концепциях, и потом спокойно указывал эти технологии в резюме.
                                                      А рыночек порешает.
                                                      • +1

                                                        В основном посыл верный. Везде, конечно же, есть свои подводные камни и нюансы (отсылка на сравнение различных категорий работяг и непосредственно работ, типа того же столяра и кодера), однако не лишним будет «выделить дополнительный слой абстракции» при восприятии данной статьи, уйти от придирок к мелочам, и скинуть своему штатному эйчару линк на подобный контент — ведь, как все мы знаем, повторение — это мать учения, и, вполне возможно, что именно эта статья станет ключевой, когда %username% будет собеседоваться с более осознанным интервьюером и получит крутую ЗэПэ.

                                                        • +14
                                                          значительный опыт разработки только на языке Perl
                                                          Перестаньте себя обманывать и винить окружающий мир. В проблеме на 99% виноваты вы сами — сидеть годами на перле, зная что он умирает, и не шевелиться. Я 10 лет назад точно также смекнул, что перл загибается и начал постепенно смотреть по сторонам. 10 лет назад, Карл!

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

                                                          Могу вам разве что посоветовать позиционировать себя не как perl-, а как backend-разработчик (ну или fullstack если фронтэнд тоже знаете). Не стоит отчаиваться, в мире полно компаний которые ищут именно «хорошего разработчика», а не «Java-сеньора, 5+ лет опыта».
                                                          • 0
                                                            Я работал ради денег, за перл мне платили больше всего, только теперь я могу себе позволить пойти на меньшие деньги.
                                                            • 0

                                                              То есть сайд-проектами вы не занимались и альтернативные технологии в принципе не изучали?

                                                          • 0

                                                            Аналогично, только лет прошло 17.

                                                          • +1
                                                            А вот когда начинающие начинают так говорить «Да я разберусь в ваших технологиях, я же умею программировать, просто возьмите на работу», так от опытных сразу начинается «Вы должны сами обучаться, программист должен знать то-то и то-то, никто не будет вас учить за свой счет») А как мировые тренды сменились, так сами жаловаться.
                                                            • 0
                                                              А вот когда начинающие начинают так говорить «Да я разберусь в ваших технологиях, я же умею программировать, просто возьмите на работу»,

                                                              Это везде сейчас. Думаете найти простого бухгалтера легко? Да убиться…
                                                            • +3

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


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

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

                                                                  Отлично. Слышали про такую штуку, как GIL? Знаете ли как работают декораторы в python? Итераторы? Генераторы? Ключевые слова типа yeild, yeild from?


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

                                                                  • 0
                                                                    Да, в основном про всё это слышал, и многое не специфично для питона, хотя чтобы применить потребуется гугление.
                                                                    > Слышали про такую штуку, как GIL?

                                                                    не очень детально знаю, но что-то про то, что интерпретатор использует блокировки которые затрудняют распараллеливание кода

                                                                    > Знаете ли как работают декораторы в python?

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

                                                                    > Итераторы?

                                                                    коллекция объектов с методом получения следующего объекта

                                                                    > Генераторы?

                                                                    специальный синтаксис для генерации списов

                                                                    > Ключевые слова типа yeild, yeild from?

                                                                    вроде для возврата из функций с запоминанием места возврата, чтобы при следующем вызове вернуться на это место
                                                                    • 0
                                                                      да вроде всё просто — функции которые оборачивают функции, даже синтаксис использования помню, перед функцией которую надо декорировать собаку с именем декоратора нужно написать

                                                                      Ну да, ведь все довольно просто, а вот как:


                                                                      1. А если нужен декоратор для класса
                                                                      2. А если нужен декоратор, который можно использовать с параметрами и без?
                                                                      3. А если нужен декоратор из класса для функции?

                                                                      Скорее всего, уже эти вопросы вы будете гуглить.


                                                                      коллекция объектов с методом получения следующего объекта
                                                                      И, как правильно вызывать range во втором python и в третьем? Что вернет map?

                                                                      специальный синтаксис для генерации списов
                                                                      А еще set, dict, tuple и так далее

                                                                      Ну и так далее. Есть довольно много тонкостей даже у такого простого в целом языка, как python. Что уже говорит про более сложные языки.

                                                                      • 0
                                                                        > Скорее всего, уже эти вопросы вы будете гуглить.

                                                                        и что в этом плохого? это окажет минимальное влияние на скорость выполнения задачи, а после нескольких раз я это запомню

                                                                        > Есть довольно много тонкостей даже у такого простого в целом языка, как python.

                                                                        конечно, но если знать концепции, то нет проблем узнать и запомнить эти тонкости за короткий срок
                                                                        • 0
                                                                          и что в этом плохого? это окажет минимальное влияние на скорость выполнения задачи, а после нескольких раз я это запомню

                                                                          Окажет ли? Проблема в том, что если для решения задачи, которую можно решить за 5 минут, если знать подход и за 2 часа, если его не знать, вы не будете гуглить этот самый подход, потому что он состоит из тонкостей, и, вы, скорее всего, будете слабо представлять о его существовании.


                                                                          конечно, но если знать концепции, то нет проблем узнать и запомнить эти тонкости за короткий срок

                                                                          К сожалению, это не помогает. Вот в python есть удобная штука для частичного фиксирования аргументов. Как много людей о ней знает? Иногда даже в популярных библиотеках для этого сначала городят свои костыли, а потом выпиливают.
                                                                          Концепции не дают знания о конкретной реализации и тонкостях работы. И опытные программисты должны знать тонкости инструмента, на самом деле, а не иметь опыт в построении программ в других условиях, с другими технологиями. Опыт — это, конечно, круто, но проблема в том, что в 70-90% случаев он вам будет не нужен.


                                                                          У вас есть опыт построения web-приложений на perl? Отлично. Но в python используется совершенно другой подход к разработке приложений (приложение + очередь), другой подход в выгрузке этого всего на прод, другие инструменты и прочее.


                                                                          Какой смысл в вашем опыте, если он понадобится в 10% случаев, для которых в компании найдется опытный специалист, которого можно будет временно перевести на этот проект? Что бы остальные 90% времени вы изучали инструменты как junior, а платить вам раза в три больше?


                                                                          Ну и да, изучить инструменты бывает довольно сложно, потому что опять же, вся проблема в тонкостях и подходах.

                                                                          • +2
                                                                            > Но в python используется совершенно другой подход к разработке приложений (приложение + очередь), другой подход в выгрузке этого всего на прод, другие инструменты и прочее.

                                                                            да нет там никаких других подходов, приложение плюс очередь это универсальный и очевидный паттерн, он есть везде (например для одного из фреймворков) и все опытные люди приходят к нему даже если не знают о его существовании
                                                                            • 0

                                                                              Что, правда? А вот почему-то, в java можно делать вот так. Никакого вам брокера сообщений, бекендов для хранения результатов и прочего — вуаля, и у вас в приложении отложенные задачи.


                                                                              Фишка в том, что очередь очень далеко не всегда вам нужна, особенно отдельная от приложения. Но python не дает вам выбора — все, что дольше эмпирического времени ответа должно уходить в очередь, иначе будете очень сильно страдать.

                                                                              • +1
                                                                                не понимаю в чём разница, в данном случае программист пользователь инструментов фреймворка, ему не особо важно как это очередь реализована, он использует механизм предоставленный фреймворком
                                                                            • +1
                                                                              Какой смысл в вашем опыте, если он понадобится в 10% случаев, для которых в компании найдется опытный специалист, которого можно будет временно перевести на этот проект?

                                                                              Какой тогда смысл нанимать нового программиста на постоянную работу?
                                                                              Что бы остальные 90% времени вы изучали инструменты как junior, а платить вам раза в три больше?

                                                                              Никто не запрещает, заключить письменное/устное соглашение о пересмотре зп.
                                                                    • 0
                                                                      Да, синтаксис языка можно выучить за 2 недели, даже меньше. Но сам язык ничего не значит без знания инфраструктуры — а это библиотеки, используемые смежные тулы и middleware знание готовых паттернов, знание решения типовых задач и так далее. А это займет возможно не один год.

                                                                      Типичный пример — есть программисты под андроид, есть java ee. Оба пишут на одном языке, но заменить их друг-другом почти невозможно. Практически ничего общего у них нет.
                                                                      Переход из одной области в другую на уровень достаточный, чтобы называться сеньором займет много времени, месяцы, а то и годы.
                                                                      • 0
                                                                        ну я больше речь не про полную смену специализации, тут конечно придётся учиться и доказывать что что-то знаешь, я про смену языка в рамках специализации — например был бэкэнд разработчик на перле, превратился в такого же на джаве
                                                                        • 0
                                                                          А и там придется учиться. Нет там ничего общего, я вам как человек бросивший перл примерно 10 лет назад говорю. Что там общего-то? Весь EE стек вам придется учить заново.
                                                                          • –1
                                                                            > Что там общего-то?

                                                                            MVC, ORM и тому подобные штуки
                                                                            • 0
                                                                              Писать маппинги под гибернейт — это уровень джуна и мидла, никак не сеньора.
                                                                              • –1
                                                                                Не очень понял зачем писать то что уже есть
                                                                  • +5
                                                                    И что помешало благородному дону попилить в свободное время какой-нибудь опенсорс на заветном языке/платформе/чем-там-ещё и гордо запилить его в резюме?
                                                                    • +6
                                                                      Сегодня не модно угорать по программированию, читать книжки, пилить что-то в свободное время и т.д. и т.п. Сегодня модно хотеть обучаться за чужой счет.
                                                                      • –1
                                                                        Отчасти соглашусь с вашим посылом, однако, даже если человек сделал пет-проекты и даже если их посмотрели (внимательно), а не просто прокрыжили (сайд-проекты — есть, опен-сорс — есть), то легко нарваться на кучу критики или на прямой отказ: знаете, мы посмотрели ваш проект, у вас там всё в процедурном стиле… нет, мы фанатеем от ООП (или функциональщины), а потому вас не возьмем. Или еще проще: да, у вас есть пет-проекты, но там сплошной говнокод, следующий!
                                                                        • +1
                                                                          Отчасти соглашусь с вашим посылом


                                                                          Да вы его даже не поняли, похоже. Прошли те времена, когда в программирование шли «по любви» и говнокодили в свободное время ради удовольствия, а не с целью впечатлить потенциального работодателя.
                                                                      • 0
                                                                        Лень (особенно когда по десять часов работаешь и каждую неделю ночуешь в поезде) и трудности выбора — метался между разными вариантами — смотрел хаскелл, питон, хотелось на них писать т.к. как языки они интересны, но потом (не так давно) понял что я недостаточно фанатею от программирования и мне нужно выбирать что-то массово востребованное.
                                                                        • 0
                                                                          Питон по-моему вполне себе востребованный.
                                                                          • 0
                                                                            В сравнении с перлом конечно, но как-то тоже не особо много вакансий было когда смотрел.
                                                                            • 0

                                                                              Вот например статистика за 16й год. Питон на 6м месте. Впрочем это по РФ, искать мировую статистику немного лень. В любом случае питон есть как минимум в трех больших областях — это веб с джанго (в основном), это автоматизация тестирования — здесь количество вакансий наоборот растет судя по ощущениям и это data science, где питон успешно конкурирует со всякими R и mathlab. В общем на ближайшие лет 10 перспективы вполне себе у языка, как мне кажется.

                                                                              • 0
                                                                                В перспективах питона у меня сомнений нет, но допустим по этому рейтингу питон на пятом, а джава на первом, причём двукратно обгоняя си стоящий на втором месте, так что разница есть.
                                                                                • 0

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

                                                                                  • 0
                                                                                    > что для вас поменяется, если вакансий нужного вам уровня будет не тысяча а две или три?

                                                                                    в такой ситуации конечно разница небольшая, но:
                                                                                    1. На практике даже в Москве такого выбора похоже нет: на java 500, на Python 186. Это не так много как кажется, там если начать вчитываться, то очень много придётся отбросить, а это Москва, если взять Минск, то уже 95 против 32, Гомель 6 против 2.
                                                                                    2. Подозреваю что на питоне больше мелких контор которые штампуют относительно типовые сайты, хотя это просто подозрение, не проверял.
                                                                                    3. Распределение может быть географически неравномерным, например, во всей Швейцарии джава вакансий 1251, а питонных 370.
                                                                      • 0
                                                                        А каков регион проживания и каков порядок цифр по ЗП на текущем месте? И каковы зарплатные ожидания на новом месте?
                                                                        • 0
                                                                          Сейчас я в Гомеле, в творческом отпуске, книгу дописываю.
                                                                          ЗП была разная, понятно, что когда я был руководителем отдела в мск, то зарабатывал значительно больше чем когда был просто разработчиком, как разработчик я считаю что 12.5$ в час это нормальная ЗП, понятно что надо делать поправки на место проживания, если релоцироваться в какую-нибудь дорогую страну вроде Швейцарии, то надо переоценивать исходя из стоимости жизни.
                                                                          • 0
                                                                            Что мешает по прежнему работать на перле? Например. Я в 2009 году работал в reg.ru и один из вариантов развития был переход в перл программисты (сам пишу на пыхе). Но уже тогда я видел, что нет смысла тратить время на это язык. Но сама кампания по прежнему активно использует его и в ближайшие годы врятли перейдет на что-то другое. Почему бы не попытаться туда?

                                                                            Я к тому, что мешает оставаться в рамках перла? Только соображение «нет перспектив»? Но перспективы есть даже на умирающих языках, т.к. можно остаться ХХ человеком знающим YY и получать из-за этого очень приличные деньги.
                                                                            • 0
                                                                              Перла для меня больше не существует.
                                                                              Он перестал нравиться мне как технология и моя нынешняя стратегия требует широко востребованных навыков.

                                                                              > Почему бы не попытаться туда?

                                                                              меня даже готовы были взять, но отказался

                                                                              > Но перспективы есть даже на умирающих языках

                                                                              это так, но только если ты прямо фанат этой технологии, когда тебе интересно ты изучаешь её до самой глубины и всегда будешь ценен, а если технология тебе не нравится, то те кто фанатеют опередят тебя и со временем тебя вытолкнет со сжимающегося рынка.
                                                                              • 0
                                                                                А данная статья появилась после походов на собеседования на какую должность? Программиста или руководителя проекта?
                                                                                • –1
                                                                                  Программиста, руководящие должности меня сейчас меньше интересуют, разве что должность Императора Земли рассмотрел бы )
                                                                                  • +1
                                                                                    Т.е. последний опыт работы не программерский, а руководство? Тогда получается, что при переходе на новый стек за плечами нет опыта на этом стеке и по сути нет програмерского опыта. Прямой путь в джуниоры. Не поверю, что не удалось найти ни одного места на эту позицию.
                                                                                    • 0
                                                                                      программерский, хотя какая разница какой опыт был последним?
                                                                        • 0
                                                                          Хороший хирург же всегда вылечит насморк!
                                                                          Отличные аналогии
                                                                          • 0
                                                                            Нет, врачи не очень подходящий пример т.к. врачам нужно просто запомнить большой объём данных.
                                                                            Именно поэтому врачей уже заменяются нейронные сети, а программистов пока нет.
                                                                            • +2

                                                                              Именно о том мой комментарий, что всегда можно подобрать аналогию, которая подтверждает идею, и всегда можно найти аналогию, которая её опровергает. И разделить их на подходящие и не подходящие
                                                                              "Я клёвый программист perl, почему бы не взять меня в программисты java, ведь ваша задача найти хорошего программиста"
                                                                              "Я клёвый столяр, почему бы не взять меня в столяры, ведь ваша задача найти хорошего столяра"
                                                                              "Я клёвый челюстно-лицевой хирург, почему бы не взять меня в психотерапевты. Ведь ваша задача найти хорошего врача"

                                                                              • 0
                                                                                Аналогии ничего не доказывают и не опровергают, они лишь упрощают понимание.
                                                                              • 0
                                                                                Ага, ну да, конечно заменяются… Да так, что госпиталь MD Anders в Техасе отказался от участия в проекте DrWatson и вышел из партнерства с IBM.
                                                                                • 0

                                                                                  Причин по выходу из эксперементальной программы у каждого конкретного госпиталя может быть вагон и маленькая тележка. Сам по себе факт такого выхода не говорит об эскперементальной программе ничего. А Ватсон на данный момент — однозначно не готовый к выходу на свободный рынок продукт.

                                                                                  • 0
                                                                                    Не очень понимаю вашего комментария, вышел потому что врачи испугались что их всех уволят?
                                                                              • 0

                                                                                Даже если ваше резюме будет читать не HR, а технический специалист — не возьмут или возьмут джуниором, и правильно сделают. Потому как между перлом и джавой пропасть не в плане языка (язык учится быстро), а в плане принятых подходов к написанию кода. В лучшем случае (если всё же есть достаточные знания за пределами перлового мира) — сможете относительно быстро вырасти.

                                                                                • 0
                                                                                  Хотелось бы примеров о каких подходах речь.
                                                                                  Ну и подходы язык не диктует, знавал перловика который на перле как на джаве и писал.
                                                                                  • 0
                                                                                    Ну и подходы язык не диктует, знавал перловика который на перле как на джаве и писал.

                                                                                    Зависит от языка. Самый жесткий пример диктования стиля, который я знаю, это golang, например.

                                                                                    • 0

                                                                                      Конкретно по перлу и джаве не скажу (не работал на них), но вот пара из моей практики — C++ и javascript.
                                                                                      Начнём с однопоточности js — что напрочь убивает привычку пользоваться примитивами синхронизации.
                                                                                      Дальше. Основной вид объектов — хэши (привет перлу). Что приводит к тому, что мы можем в любой объект добавить ещё немножко данных или перекрыть метод.
                                                                                      Дальше. Замыкания как сущности первого порядка. Плюс проблема с this (функция может быть вызвана с совершенно другим this) — что приводит к типовому шаблону пропихивания его в передаваемые куда-нибудь замыкания под другим именем (в современном js есть более прямые решения, но не всегда можно на него закладываться)
                                                                                      Возвращаясь к хэшам: prototype-based наследование. Поверх которого люди строят "классическую" систему классов, но это зачастую не лучшее решение.
                                                                                      Ну и вишенка на торте — C++ даёт возможность писать быстрый код — с соответствующими приёмами оптимизации. Js мало того, что медленней — приёмы оптимизации совершенно другие.

                                                                                      • +1

                                                                                        У Вас какое-то странное сравнение. Компилируемые языки сравниваете с интерпретируемыми, имея прекрасное понимание того, какие задачи решаются обычно этими языками.


                                                                                        На C++ не пишут сайты и блоги, это инструмент для абсолютно других задач, и в этом смысле, если говорить о веб-приложениях, то без разницы на чем писать — на Python, PHP, Perl, JavaScript и т.д.


                                                                                        В этом плане разницы между этими языками практически нет, они все императивные (с примесью функциональщины). И паттерны с SOLID'ом везде одинаковые.


                                                                                        Если человек хорошо ориентируется во всяких ActiveRecord, DataMapper, DAO, Front Controller и т.д., то это означает что он без проблем освоит любой из перечисленных языков (опять же в рамках веб-программирования), потому что он с этими принципами уже работал в другом языке.


                                                                                        И если завтра компания вместо React.js захочет взять Vue.js, значит ли это что нужно судорожно начинать искать специалистов по Vue, потому что программисты в компании пишут на React?


                                                                                        Либо наоборот, искать людей с опытом работы с фреймворком от двух лет, в то время как фреймворк вышел только полгода назад (были кажется такие приколы)?


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

                                                                                        • 0

                                                                                          Обратите внимание на языковую пару автора поста: perl и java. Так что насчёт странности сравнения не ко мне :-). Вот если бы он с перла переходил на какой-то из языков той же ниши…
                                                                                          А в остальном я с вами согласен, всё равно учиться в нашей профессии приходится много, и освоить ещё один язык или ещё один фреймворк — обычное дело.

                                                                                  • +1
                                                                                    1. Хороший программист сможет освоить новый язык довольно быстро — это правда. Вот только нюансы языка даже за 2 месяца освоить не получится. А сеньёр/техлид отличается от мидла именно знаниями этих нюансов.

                                                                                    2. Мой опыт говорит, что если человек способен за 1-2 недели выучить язык, то никто не будет его держать на джуниорской позиции больше, т.к. он просто уйдет. икакая вменяемая IT компания не хочет терять хороших программистов.

                                                                                    3. Я бы еще понял, если бы эта статья была написана программистом. Но в заголовке я вижу:
                                                                                    руководитель программистов (нанимался и нанимал)

                                                                                    Возникает вопрос, неужели автор этого текста нанял бы себе на проект на позицию Perl сеньёра/техлида того, кто раньше писал только на PHP и Perl в первый раз видит? Что-то у меня смутные сомнения.
                                                                                    • 0
                                                                                      На самом деле у меня был случай, когда мы взяли человека без опыта, он сделал тестовое задание и сразу было видно что это крутой чел и он реально отлично работал, не как джуниор, а как сеньёр — там где два опытных и много чего знающих хакера потратили в два раза больше времени и не довели ко конца, он навёл порядок и доделал.
                                                                                      Да и джуниоров я многих помню, которые приходили и работали нормально практически сразу, понятно начинали с простых задач, но очень быстро догоняли.
                                                                                      Конечно опыт штука ценная, но нельзя сказать что эти люди учились за счёт компании, они свою зп отрабатывали точно.
                                                                                      • +1
                                                                                        То, что ты описал в первом примере — бывает. Но это далеко не тренд. В последнее время я вижу сильно много сеньеров, которые стали сеньерами, потому что долго в компании работают. Нет, они конечно работают неплохо, свои деньги в данной компании отрабатывают, но вот брать бы их на сеньерскую должность в новый проект, со сменой технологии и языка — нет уж, увольте.
                                                                                        • 0
                                                                                          Да — далеко не всякий опыт в резюме вообще имеет какую-то ценность, надо тестировать человека на способность выполнять нужную вам работы.
                                                                                    • –2
                                                                                      хмм улыбнуло perl умирающий язык )))) я бы поспорил, знакомые есть кто на нем кодит аж с 96го года у них все работает, а значит клиентов устраивает
                                                                                      • 0
                                                                                        со статистикой не поспоришь, на коболе тоже много чего работает, но никто не спорит что это умирающий язык
                                                                                        • 0
                                                                                          Фортран так уже лет тридцать хоронят, всё никак не закопают. Хотя статистика, особенно в относительных цифрах, действительно неумалима.

                                                                                          Что-то мне подсказывает, что реально происходит примерно такая динамика — в какой-то момент новое поколение программистов изобретает новый язык. Кодит на нём разное бизнес-полезное. По мере роста накопленной кодовой базы в успешных компаниях, расползается по позициям, связанным с поддержкой имеющихся решений. К этому времени из колледжей выползают новые молодые программисты. Тёплые позиции в компаниях с имеющимся софтом им массово не светят, так что они пилят новый язык и поднимают хайп. Стартапчики и молодые бизнесы ведутся, и молодые программисты, постепенно старея, расползаются по новому поколению контор. Цикл.
                                                                                          • 0
                                                                                            Как-то так, хотя в среднем растёт уровень выразительности языков, условно говоря от низкоуровнего си перешли к высокоуровневому питону.
                                                                                      • +3
                                                                                        Пару лет назад успешно спрыгнул с флеша без единого наброса на бедных девочек из HR. Автор ленивый и жирный кот )
                                                                                        • 0
                                                                                          худой )
                                                                                          • 0
                                                                                            Кстати, наброс не на девочек, это прям явно написано.
                                                                                          • 0
                                                                                            В кровавом ентерпрайзе некоторые вещи с 60х годов работают, но это не повод считать всякие Коболы живими :)
                                                                                            • +1
                                                                                              По своему опыту скажу, что все эти фреймворки, стеки, языки в описаниях вакансии лишь мишура для завлекухи, некогда услышаные эйчаерами.

                                                                                              Из последнего.
                                                                                              Знакомый. Пэхэпешник. Смена работы. Вакансия, все как положено: php 5,6...100500.0, yii, laravel, ООП, mvc и дохрена прочего из мира php. В итоге пишет микросервисы на Go, а всем тем, что было в описании вакансии, даже и не пахнет.

                                                                                              И таких примеров, больше, чем хотелось бы.
                                                                                              • 0
                                                                                                Пэхэпешник

                                                                                                В итоге пишет микросервисы на Go,

                                                                                                Ну он же, я так понимаю, не огорчен этим фактом?
                                                                                                • 0
                                                                                                  Так вот и я о том, почему-то никто не считает проблемой пересадить уже нанятых людей на другую технологию, не кричит что это бесплатное обучение и всё такое, видимо потому что выгоды больше чем затраты.
                                                                                                  А новых надо нанимать с длинным список требований технологий используемых в сию секунду.
                                                                                                  • 0
                                                                                                    Ну а что нелогичного? Способности и возможности уже нанятого вы и так прекрасно знаете. И оплачиваете ему обучение, понимая, какая будет отдача. А что вы можете ожидать от человека, с которым вас связывает одно-два собеседования?
                                                                                                    с длинным список требований технологий используемых в сию секунду.

                                                                                                    Если на рынке таких людей нет, работодатель просто смягчает требования.
                                                                                                    Я бы на вашем месте все-таки «инвестировал в самого себя», а не ждал бы доброго дядю, который бы согласился это сделать. Дядя может найтись, может не найтись. А может найтись, но оказаться не добрым, и т.д. А так, основная проблема ведь не в том, что работодатели такие редиски. Просто ваше предложение пока не слишком конкурентоспособное по сравнению с другими. Переборите свою вышеупомянутую лень, и подучите что-то мейнстримовое. От соискателя же в большинстве случаев не требуется многолетний опыт работы именно на вон том фреймворке, достаточно просто опыт плюс умение работать с нужными инструментами.
                                                                                                    • 0
                                                                                                      > А что вы можете ожидать от человека, с которым вас связывает одно-два собеседования?

                                                                                                      мой опыт показывает что тестовое задание неплохо отражает способности человека, а дальше есть испытательный срок

                                                                                                      > Я бы на вашем месте все-таки «инвестировал в самого себя»

                                                                                                      Естественно я буду изучать (как только текущие задачи доделаю), статья не обо мне, а о подходе.
                                                                                                      • +1
                                                                                                        мой опыт показывает что тестовое задание неплохо отражает способности человека, а дальше есть испытательный срок

                                                                                                        Испытательный срок, это же не для проверки человека, чтобы потом принимать решение, годится он для работы или нет. Это что-то вроде стоп-крана. Когда при наборе кадров произошла серьёзная авария, и надо срочно принимать меры. Поэтому при наборе сотрудников надо исходить из того, что человек, которого берешь в коллектив, испытательный срок пройдёт. А значит, при прочих равных, он изначально должен как можно лучше соответствовать должности.
                                                                                                        • 0
                                                                                                          Вы себе же противоречите, чуть выше вы утверждали «А что вы можете ожидать от человека, с которым вас связывает одно-два собеседования?» т.е. говорили что по собеседованию нельзя хорошо оценить человека, а теперь вы утверждаете, что после собеседования надо быть уверенным в том, что человека нужно брать.
                                                                                                          Ведь очевидно, что опыт и список технологий указанные в резюме не значат ничего.
                                                                                                          • +1
                                                                                                            Я себе не противоречу. Выше я писал про то, почему «переучивать своих сотрудников» и «нанимать с улицы не имеющего нужной подготовки, и переучивать» — это разные вещи.
                                                                                                            • Малознакомый человек не знает инструмента, но обещает, что быстро выучится = высокий риск
                                                                                                            • Малознакомый человек знает инструмент = умеренный риск
                                                                                                            • Переучить на новый инструмент хорошо знакомого человека, который умеет
                                                                                                            учиться = низкий риск.
                                                                                                            Я думал, это очевидно.

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

                                                                                                            Не «быть уверенным в том, что нужно брать», а «нужно брать тех, кто лучше соответствует должности». По-моему, это совсем не одно и то же :)
                                                                                                            Вы не будете увольнять после испытательного срока человека, если он не оправдал ваших ожиданий, но при этом не полная бестолочь. Да и вообще, тратить месяц на то, чтобы протестить сотрудника, годится он или нет — непозволительная роскошь, как для работодателя, так и для самого сотрудника.