Comments 177
Кто виноват?
Не знаю, точно не HR’ы, они играют как скажут.
Но и не менеджмент любого ранга непрограммистского толка. Они не отличат JS от Java.
Значит проблемма все равно внутри программистского сообщества.
Project Manager-ы дают требования по технологиям исходя из проектной необходимости. HR-ы отбирают кандидатов по простому соответствию того, что указано в резюме кандидата и тому, что написал PM. Соответственно до интервью доходят только те, у кого резюме соответствует требованиям.
К тому же всем нужны готовые специалисты и мало кто готов дать 1-2 месяца чтобы научиться и разобраться в новой технологии.
Что делать программистам (особенно умирающих языков):
— Подгонять резюме под вакансию. Если написан Angular2, то пишем Angular 2 и оставшееся время до интервью зубрим теорию и делаем тестовые проекты.
— Учить новые языки и технологии. Если видите в вакансиях React — то изучите его
— Участвуйте в Open-Source проектах или заведите свой домашний проект, где вы будете обкатывать новые языки и технологии. А когда пойдёте на интервью, то будет что показать…
Подгонять резюме и осваивать технологии, требуемые в вакансии — такое случается только при смене работы, т.е. раз в 3-5 лет.
Программирование настолько быстро развивается, что даже если интенсивно изучать новое, создаётся впечатление, что ты отстаёшь от поезда. А если забить и не учить, то придётся потом остаток жизни работать во второсортной фирмочке за скромную зарплату.
Могу сказать по своему примеру. Мне не за 40, но мне самое что ни на есть «под 40», так что этот вопрос для меня отнюдь не чуждый. У меня родители-пенсионеры, жена в декрете и маленькая дочь, ответственности хватает. А три года назад я потерял свой дом, да и в общем-то весь свой город.
И я стал красноглазить, как в юности. И знаете что? Не так уж это и страшно оказывается для здоровья, особенно когда жареный петух в задницу клюнул.
Мой товарищ, например, в той же ситуации вообще в 37 лет выучился на программиста с нуля, до этого он обувь продавал в своем магазине в том же городе. И ничего, поработал джуном, теперь уже миддл, неплохо знает кучу JS-фреймворков и ухитряется держаться в тренде даже в той мешанине, которая творится в мире JS. Так что моё ИМХО, все эти разговоры про «как тяжко работать, если тебе за...», это просто отмазки. Если сильно надо, то всё получится, лишь бы ленивую попу поднять. Проблема скорее всего в том, что чаще не настолько уже и надо.
обычно требуется изготавливать что-то настолько редкое, что найти человека с таким опытом практически невозможно
И зря вы так возвышенно относитесь к программистам, не льстите себе. Большинство (не все) делают обычные сайты, фронтэнд. Что здесь уникальнее изготовления мебели на заказ? Или вы про тех программистов, кто алгоритмы пишет новые? Так и столяры бывают искусники резьбы по дереву…
По поводу рынка труда программистов с моей точки зрения все просто. Много контор (значительно больше столярских), как следствие большой спрос порождает много соискателей. Соискателей больше, чем надо рынку. Значит их можно тщательнее фильтровать. Как только предложение рабочей силы уменьшится, работодатель вынужден будет уменьшать критерии для фильтрации. Уменьшится оно тогда, когда у программистов зарплата станет средней для страны.
Хотите, чтобы требования к программистам были как у столяров? Вывесите резюме с ожидаемой зарплатой как у столяров с аналогичным опытом работы. Вас быстро возьмут на работу.
в таких сферах думаю и набирают студентов, да учат их
Можно нанять профи и сделать качественно.
Можно нанять пару профи и десяток студентов и сделать хорошо.
Реализация многих алгоритмов заметно проще современного фронтэнда. А уж реализация конечного автомата вообще примитивна, вот его составление — это в общем случае и правда сложная задача.
Ну в прошлом комментарии достаточно однозначно вами написано "реализация алгоритмов", а не выбор из доступных или разработка нового. Так что вот именно вы и говорите.
Но я бы даже сказал что выбрать из существующих алгоритмов не сложно зачастую. Для этого их, конечно, нужно знать и нужно понимать чем они отличаются, но это за полгода учится без напряга даже одновременно с работой (особенно одновременно с работой). Более того, если вернуться к теме что сложнее бэк или фронт, то для фронта выбор алгоритмов точно также важен.
Для этого их, конечно, нужно знать и нужно понимать чем они отличаются, но это за полгода учится без напряга даже одновременно с работой (особенно одновременно с работой).
Неправда, для этого есть пять лет высшего математического образования. Даже интересно, как вы за полгода подтянете двух годовой курс тервера для работы с попсовой нынче bigdata на хорошем уровне. Или трехгодовой курс матан+ТФКП+числ методы для выбора оптимального (или допиливания существующего) алгоритма обработки хитрой системы уравнений.
Я имел в виду задачи более широкого спектра, чем выбрать нужный алгоритм сортировки или даже решения задач линейного/динамичного программирования.
Я имел в виду задачи более широкого спектра
Вот здесь вы совершенно однозначно написали про реализацию существующих алгоритмов и всяких конечных автоматов:
И сравните со временем на обучение для реализации конечных автоматов, алгоритмов, физических движков, математических моделей etc.
Если вы под этим подразумевали более широкий круг задач совершенно другого порядка сложностей, то вам стоит поработать над формулировками. С тем, что для разработки нового алгоритма и даже для выбора из существующих (в каких-то областях) нужно образование больше полугода я не спорю. Я только указываю что то, что вы написали ранее — некорректно.
Еще пять лет назад зп программиста джуниора (блин, тогда слово это только в обиход входило) была в 1.5 раза больше инженеров в других сферах, сейчас это практически один-в-один.
Где дефицит кроме как в головах менеджеров?
И есть оценки величины этого дефицита — habrahabr.ru/company/infowatch/blog/328790
Вот смотрите, если я скажу — очень тяжело найти толкового столяра-краснодеревщика. Означает ли, что дефицит столяров? А мой друг скажет, что невозможно найти хорошего страховщика недвижимости. Здесь тоже дефицит?
Тогда можно вообще поставить вопрос так, что со всеми специалистами дефицит.
Дефицит именно специалистов с опытом. Если бы это было не так, то не было бы такого потока эйчаров в почте с предложениями работать. Этот поток начинается уже через полгода работы и в дальнейшем только растет.
Разница в нехватке кадров — на порядок. У меня есть знакомый инженер оптик с высшим образованием по специальности и стажем уже 5+ лет. Ему не сыпятся предложения о новой работе даже раз в месяц. В аналогичных условиях программисту необходимо настраивать спам фильтр в почте и временами отпинываться от эйчаров по другим каналам связи.
У вас есть другое объяснение этому явлению кроме принципиально другого уровня нехватки кадров? У меня — нет, но может быть я что-то упускаю из виду?
Погуглите маржинальность и ROE бизнеса по отраслям, вы увидите, что стройка волс, или чем там занимается ваш знакомый, значительно ниже ИТ. Есть возможность переложить затраты на капитальные мощности в фонд оплаты труда.
Я ничего никуда не свожу. Есть факт — программистам с опытом пишут с предложениями работы постоянно и чем больше опыта тем больше. Я не знаю ни одной другой профессии в которой такое бы происходило. У меня есть объяснение: дефицит кадров больше чем в остальных областях.
Вы утверждаете что дефицит кадров есть везде. Тогда объясните предъявленный факт другой теорией и, если в ней не будет логических ошибок, то я соглашусь что ваш вариант также может быть.
P.S. В данном комментарии слова "везде" предполагают возможное наличие одиночных исключений.
Что "это"? Я точно могу сказать что журналист или инженер на заводе не начинает получать нескончаемый поток предложений о работе через полтора-два года стажа. Так что нет, факты говорят что мой вариант не касается любой высококвалифицированной работы. Если вам в данных примерах не хватает квалификации, то тоже самое можно сказать и про, например, астрономов с высшим образованием. И, наверняка, про других ученых тоже.
Правда проект должен быть на должном уровне по документированию и хранению кодовой базы.
В вашем примере «железные фальцгебели с пластмассовыми ручками» — больше похоже на требование использования конкретной IDE.
А вот умение работать на фрезерном станке — было бы ближе к требованию по конкретному стеку технологий.
Опыта работы на станках — 0.
В компании используются станки. Верстаков нет.
Какова будет польза от такого столяра?
А вы не откажете столяру только потому, что он не умеет на станках?
Откажу. Потому что те на станках делают в N-раз больше продукции, чем тот на верстаке, а значит приносят в N-раз больше прибыли.
Результат тот же? Браузер пашет? Так в чем проблема?
Проблем много.
Одна в том, что программисты не пишут браузеры в одиночку. И если у вас десять программистов пишут на JavaScript, а один гений на Delphi, они друг с другом будут фигово состыковываться в одном проекте.
Другая в том, что ваш программист с вами не навечно. И если он круто пишет на чем-то странненьком или редком, то вам надо иметь в виду, что вам нужно будет потом ещё одного такого же искать.
Во вторых по качеству выполнения тестового задания (на которое соискатель не может потратить много времени) не всегда удается оценить, на сколько качественно будет выполнен сложный долговременный проект. Да и, даже если соискатель выполнит большой проект, скажем опенсорсный, сделанный для других целей, проверить, на сколько хорошо он сделан не дешево — фактически надо проводить полноценное тестирование и code review.
Да и через пару дней хорошо если научится станок с программой запускать.
А вот сделать изделие высокого класса, без дефектов, можно только путем подстройки станка под материал, для чего нужен не только большой опыт работы с материалом, но и со станком в целом
И с программистами тоже самое. Какой-то результат тебе любой выдаст, а вот результат хороший — только опытный профессионал.
Писать то, что человеку нужно 2 недели на освоение технологии, может только человек, который никогда не плакал, глядя на код, написанный сишниками с 10 летним стажем на Ruby on Rails.
А если вы берёте прикладного программиста, то вам надо проверить способность писать простой, ясный, читаемый код
Как я могу взять прикладного программиста на C++/Qt, если тот не имеет соответствующего бэкграунда? А сеньор на PHP/Perl пойдет работать джуниором на C++
Т.к. ИТ сфера достаточно новая, то не всем понятно почему это полнейший идиотизм.
Нет, это не идиотизм, и не нужно программистов сравнивать со столярами. От столяра требуется сделать один конкретный продукт. Пусть делает его так, как умеет. От программиста зачастую требуется влиться в команду, которая уже работает с каким-то конкретным набором инструментов. Если программист им уже владеет, он будет тратить время на изучение проекта. Если программист не владеет инструментарием, он будет тратить много времени на первых порах ещё и на изучение инструментария. Поэтому первый вариант чисто экономически предпочтительнее. При прочих равных лучше тот, кто уже имеет подходящий опыт.
у программистов инструменты изменяются с космической скоростью
У JS-программистов. В остальных сферах фреймворки и инструменты успешно живут годами, лишь прирастая фичами. А некоторые — десятилетиями.
От столяра требуется сделать один конкретный продукт. Пусть делает его так, как умеет.
Вы недооцениваете работу столяра :(
При прочих равных лучше тот, кто уже имеет подходящий опыт.Как быть при неравных, например, программист с десятилетним стажем без знания фреймворка vs. программист с 3 летним стажем, но со знанием фреймворка?
Как быть при неравных, например, программист с десятилетним стажем без знания фреймворка vs. программист с 3 летним стажем, но со знанием фреймворка?
При неравных надо смотреть и думать :) Но «тезисно» сам по себе факт, что у кого-то стаж десять лет, а у кого-то три, ни о чем конкретном не говорит. Три года опыта вполне достаточно, чтобы стать неплохим самостоятельным миддлом.
изучение инструментария это мелочь по сравнению с изучением проекта
изучение инструментария это мелочь по сравнению с изучением проекта
Это так, если происходит в рамках одного языка и сравниваются фреймворки. В случае разных языков мидл на java и мидл на perl, это как слесарь-сантехник и столяр. Оба хороши в своих стезях, но не обладают должной экспертизой в другой области.
такое бывает, но не думаю что это правило, в серверной части точно также всё меняется, взять перл — сначала для параллельного программирования был популярен POE, потом Coro, потом AnyEvent, а потом народ поуходили на всякие node.js/Go, а самые умные на Erlang/Elixir
Плюс, когда вы берёте человека с опытом, то этот опыт поможет вам улучшить вашу технологию разработки. Потому что тот же React+Redux тоже надо уметь готовить и набивать шишки. Человек без опыта, скорее всего, будет просто повторять методы, которые уже используются в проекте.
Если вы говорите о какой-то экзотике, то тогда да, дешевле и быстрее научить, чем искать опытного.
Я бы на вашем месте написал какой-нибудь проект на React+Redux или на Angular, чтобы разобраться в концепциях, и потом спокойно указывал эти технологии в резюме.
А рыночек порешает.
В основном посыл верный. Везде, конечно же, есть свои подводные камни и нюансы (отсылка на сравнение различных категорий работяг и непосредственно работ, типа того же столяра и кодера), однако не лишним будет «выделить дополнительный слой абстракции» при восприятии данной статьи, уйти от придирок к мелочам, и скинуть своему штатному эйчару линк на подобный контент — ведь, как все мы знаем, повторение — это мать учения, и, вполне возможно, что именно эта статья станет ключевой, когда %username% будет собеседоваться с более осознанным интервьюером и получит крутую ЗэПэ.
значительный опыт разработки только на языке PerlПерестаньте себя обманывать и винить окружающий мир. В проблеме на 99% виноваты вы сами — сидеть годами на перле, зная что он умирает, и не шевелиться. Я 10 лет назад точно также смекнул, что перл загибается и начал постепенно смотреть по сторонам. 10 лет назад, Карл!
Никто не мешал вам за все эти годы самостоятельно изучать другие технологии и делать на них хотя бы сайд-проекты, ради опыта и строчек в резюме.
Могу вам разве что посоветовать позиционировать себя не как perl-, а как backend-разработчик (ну или fullstack если фронтэнд тоже знаете). Не стоит отчаиваться, в мире полно компаний которые ищут именно «хорошего разработчика», а не «Java-сеньора, 5+ лет опыта».
Аналогично, только лет прошло 17.
Нигде не узнать сколько у Вас займет переход на новый язык и стек технологий — 2 недели, 2 месяца, 2 года. Приходя на новый проект Вы не только будете вникать в сам проект, но еще и в язык (то есть Вы вполне возможно вообще не поймете часть написанного кода). Код который Вы будете писать надо будет постоянно проверять, указывать на ошибки и недочеты. Нужна ли работодателю вся эта головная боль и рулетка, когда можно просто найти специалиста подходящего под требования (ведь мы говорим о распространенных технологиях).
Люди которые меняют язык обычно снова начинают с джуниоров. Если Вы толковый программист, 3-5 месяцев Вам хватит, чтобы освоить новые технологии и получить заветные строчки в резюме. Либо Вы можете сделать свой собственный проект с указанными технологиями и добавить его в резюме. Так или иначе, мне странно видеть подобные жалобы от хорошего специалиста
Да я писал немного медленнее т.к. много нужно гуглить поначалу (не всё ещё запомнилось), но я сразу начал писать вполне приемлемый код, так что освоение новой технологии это недели, а вот изучение предметной области проекта это месяцы, причём из-за плохо налаженного обучения обычно много месяцев.
Отлично. Слышали про такую штуку, как GIL? Знаете ли как работают декораторы в python? Итераторы? Генераторы? Ключевые слова типа yeild, yeild from?
Практически в любом языке есть куча тонкостей, без которых стать Senior программистом или иногда даже мидлом довольно сложно. Понятное дело, написать простой проект на любом языке можно довольно быстро, но вот как только появляется более сложный проект, возникают различные тонкости.
> Слышали про такую штуку, как GIL?
не очень детально знаю, но что-то про то, что интерпретатор использует блокировки которые затрудняют распараллеливание кода
> Знаете ли как работают декораторы в python?
да вроде всё просто — функции которые оборачивают функции, даже синтаксис использования помню, перед функцией которую надо декорировать собаку с именем декоратора нужно написать
> Итераторы?
коллекция объектов с методом получения следующего объекта
> Генераторы?
специальный синтаксис для генерации списов
> Ключевые слова типа yeild, yeild from?
вроде для возврата из функций с запоминанием места возврата, чтобы при следующем вызове вернуться на это место
да вроде всё просто — функции которые оборачивают функции, даже синтаксис использования помню, перед функцией которую надо декорировать собаку с именем декоратора нужно написать
Ну да, ведь все довольно просто, а вот как:
- А если нужен декоратор для класса
- А если нужен декоратор, который можно использовать с параметрами и без?
- А если нужен декоратор из класса для функции?
Скорее всего, уже эти вопросы вы будете гуглить.
коллекция объектов с методом получения следующего объекта
И, как правильно вызывать range во втором python и в третьем? Что вернет map?
специальный синтаксис для генерации списов
А еще set, dict, tuple и так далее
Ну и так далее. Есть довольно много тонкостей даже у такого простого в целом языка, как python. Что уже говорит про более сложные языки.
и что в этом плохого? это окажет минимальное влияние на скорость выполнения задачи, а после нескольких раз я это запомню
> Есть довольно много тонкостей даже у такого простого в целом языка, как python.
конечно, но если знать концепции, то нет проблем узнать и запомнить эти тонкости за короткий срок
и что в этом плохого? это окажет минимальное влияние на скорость выполнения задачи, а после нескольких раз я это запомню
Окажет ли? Проблема в том, что если для решения задачи, которую можно решить за 5 минут, если знать подход и за 2 часа, если его не знать, вы не будете гуглить этот самый подход, потому что он состоит из тонкостей, и, вы, скорее всего, будете слабо представлять о его существовании.
конечно, но если знать концепции, то нет проблем узнать и запомнить эти тонкости за короткий срок
К сожалению, это не помогает. Вот в python есть удобная штука для частичного фиксирования аргументов. Как много людей о ней знает? Иногда даже в популярных библиотеках для этого сначала городят свои костыли, а потом выпиливают.
Концепции не дают знания о конкретной реализации и тонкостях работы. И опытные программисты должны знать тонкости инструмента, на самом деле, а не иметь опыт в построении программ в других условиях, с другими технологиями. Опыт — это, конечно, круто, но проблема в том, что в 70-90% случаев он вам будет не нужен.
У вас есть опыт построения web-приложений на perl? Отлично. Но в python используется совершенно другой подход к разработке приложений (приложение + очередь), другой подход в выгрузке этого всего на прод, другие инструменты и прочее.
Какой смысл в вашем опыте, если он понадобится в 10% случаев, для которых в компании найдется опытный специалист, которого можно будет временно перевести на этот проект? Что бы остальные 90% времени вы изучали инструменты как junior, а платить вам раза в три больше?
Ну и да, изучить инструменты бывает довольно сложно, потому что опять же, вся проблема в тонкостях и подходах.
да нет там никаких других подходов, приложение плюс очередь это универсальный и очевидный паттерн, он есть везде (например для одного из фреймворков) и все опытные люди приходят к нему даже если не знают о его существовании
Что, правда? А вот почему-то, в java можно делать вот так. Никакого вам брокера сообщений, бекендов для хранения результатов и прочего — вуаля, и у вас в приложении отложенные задачи.
Фишка в том, что очередь очень далеко не всегда вам нужна, особенно отдельная от приложения. Но python не дает вам выбора — все, что дольше эмпирического времени ответа должно уходить в очередь, иначе будете очень сильно страдать.
Какой смысл в вашем опыте, если он понадобится в 10% случаев, для которых в компании найдется опытный специалист, которого можно будет временно перевести на этот проект?
Какой тогда смысл нанимать нового программиста на постоянную работу?
Что бы остальные 90% времени вы изучали инструменты как junior, а платить вам раза в три больше?
Никто не запрещает, заключить письменное/устное соглашение о пересмотре зп.
Вот например статистика за 16й год. Питон на 6м месте. Впрочем это по РФ, искать мировую статистику немного лень. В любом случае питон есть как минимум в трех больших областях — это веб с джанго (в основном), это автоматизация тестирования — здесь количество вакансий наоборот растет судя по ощущениям и это data science, где питон успешно конкурирует со всякими R и mathlab. В общем на ближайшие лет 10 перспективы вполне себе у языка, как мне кажется.
Разница, конечно, есть, но я сомневаюсь что она сильно ощутима для одного конкретного человека. На мой взгляд даже первая десятка самых популярных языков — это такое количество разных вакансий на рынке, что можно без проблем найти то, что хочется. Ну правда, вот что для вас поменяется, если вакансий нужного вам уровня будет не тысяча а две или три?
в такой ситуации конечно разница небольшая, но:
1. На практике даже в Москве такого выбора похоже нет: на java 500, на Python 186. Это не так много как кажется, там если начать вчитываться, то очень много придётся отбросить, а это Москва, если взять Минск, то уже 95 против 32, Гомель 6 против 2.
2. Подозреваю что на питоне больше мелких контор которые штампуют относительно типовые сайты, хотя это просто подозрение, не проверял.
3. Распределение может быть географически неравномерным, например, во всей Швейцарии джава вакансий 1251, а питонных 370.
ЗП была разная, понятно, что когда я был руководителем отдела в мск, то зарабатывал значительно больше чем когда был просто разработчиком, как разработчик я считаю что 12.5$ в час это нормальная ЗП, понятно что надо делать поправки на место проживания, если релоцироваться в какую-нибудь дорогую страну вроде Швейцарии, то надо переоценивать исходя из стоимости жизни.
Я к тому, что мешает оставаться в рамках перла? Только соображение «нет перспектив»? Но перспективы есть даже на умирающих языках, т.к. можно остаться ХХ человеком знающим YY и получать из-за этого очень приличные деньги.
Он перестал нравиться мне как технология и моя нынешняя стратегия требует широко востребованных навыков.
> Почему бы не попытаться туда?
меня даже готовы были взять, но отказался
> Но перспективы есть даже на умирающих языках
это так, но только если ты прямо фанат этой технологии, когда тебе интересно ты изучаешь её до самой глубины и всегда будешь ценен, а если технология тебе не нравится, то те кто фанатеют опередят тебя и со временем тебя вытолкнет со сжимающегося рынка.
Отличные аналогии
Именно поэтому врачей уже заменяются нейронные сети, а программистов пока нет.
Именно о том мой комментарий, что всегда можно подобрать аналогию, которая подтверждает идею, и всегда можно найти аналогию, которая её опровергает. И разделить их на подходящие и не подходящие
"Я клёвый программист perl, почему бы не взять меня в программисты java, ведь ваша задача найти хорошего программиста"
"Я клёвый столяр, почему бы не взять меня в столяры, ведь ваша задача найти хорошего столяра"
"Я клёвый челюстно-лицевой хирург, почему бы не взять меня в психотерапевты. Ведь ваша задача найти хорошего врача"
Причин по выходу из эксперементальной программы у каждого конкретного госпиталя может быть вагон и маленькая тележка. Сам по себе факт такого выхода не говорит об эскперементальной программе ничего. А Ватсон на данный момент — однозначно не готовый к выходу на свободный рынок продукт.
Даже если ваше резюме будет читать не HR, а технический специалист — не возьмут или возьмут джуниором, и правильно сделают. Потому как между перлом и джавой пропасть не в плане языка (язык учится быстро), а в плане принятых подходов к написанию кода. В лучшем случае (если всё же есть достаточные знания за пределами перлового мира) — сможете относительно быстро вырасти.
Ну и подходы язык не диктует, знавал перловика который на перле как на джаве и писал.
Ну и подходы язык не диктует, знавал перловика который на перле как на джаве и писал.
Зависит от языка. Самый жесткий пример диктования стиля, который я знаю, это golang, например.
Конкретно по перлу и джаве не скажу (не работал на них), но вот пара из моей практики — C++ и javascript.
Начнём с однопоточности js — что напрочь убивает привычку пользоваться примитивами синхронизации.
Дальше. Основной вид объектов — хэши (привет перлу). Что приводит к тому, что мы можем в любой объект добавить ещё немножко данных или перекрыть метод.
Дальше. Замыкания как сущности первого порядка. Плюс проблема с this (функция может быть вызвана с совершенно другим this) — что приводит к типовому шаблону пропихивания его в передаваемые куда-нибудь замыкания под другим именем (в современном js есть более прямые решения, но не всегда можно на него закладываться)
Возвращаясь к хэшам: prototype-based наследование. Поверх которого люди строят "классическую" систему классов, но это зачастую не лучшее решение.
Ну и вишенка на торте — C++ даёт возможность писать быстрый код — с соответствующими приёмами оптимизации. Js мало того, что медленней — приёмы оптимизации совершенно другие.
У Вас какое-то странное сравнение. Компилируемые языки сравниваете с интерпретируемыми, имея прекрасное понимание того, какие задачи решаются обычно этими языками.
На C++ не пишут сайты и блоги, это инструмент для абсолютно других задач, и в этом смысле, если говорить о веб-приложениях, то без разницы на чем писать — на Python, PHP, Perl, JavaScript и т.д.
В этом плане разницы между этими языками практически нет, они все императивные (с примесью функциональщины). И паттерны с SOLID'ом везде одинаковые.
Если человек хорошо ориентируется во всяких ActiveRecord, DataMapper, DAO, Front Controller и т.д., то это означает что он без проблем освоит любой из перечисленных языков (опять же в рамках веб-программирования), потому что он с этими принципами уже работал в другом языке.
И если завтра компания вместо React.js захочет взять Vue.js, значит ли это что нужно судорожно начинать искать специалистов по Vue, потому что программисты в компании пишут на React?
Либо наоборот, искать людей с опытом работы с фреймворком от двух лет, в то время как фреймворк вышел только полгода назад (были кажется такие приколы)?
Думаю что автор тут как раз пытается сказать что существует непонимание многими работодателями (и возможно даже самими программистами) принципов разработки ПО, и если человек, например, не работал с Vue, но работал с React, это не означает что его кандидатуру нужно немедленно режектить минуя оценку общих знаний и опыта кандидата.
Обратите внимание на языковую пару автора поста: perl и java. Так что насчёт странности сравнения не ко мне :-). Вот если бы он с перла переходил на какой-то из языков той же ниши…
А в остальном я с вами согласен, всё равно учиться в нашей профессии приходится много, и освоить ещё один язык или ещё один фреймворк — обычное дело.
2. Мой опыт говорит, что если человек способен за 1-2 недели выучить язык, то никто не будет его держать на джуниорской позиции больше, т.к. он просто уйдет. икакая вменяемая IT компания не хочет терять хороших программистов.
3. Я бы еще понял, если бы эта статья была написана программистом. Но в заголовке я вижу:
руководитель программистов (нанимался и нанимал)
Возникает вопрос, неужели автор этого текста нанял бы себе на проект на позицию Perl сеньёра/техлида того, кто раньше писал только на PHP и Perl в первый раз видит? Что-то у меня смутные сомнения.
Да и джуниоров я многих помню, которые приходили и работали нормально практически сразу, понятно начинали с простых задач, но очень быстро догоняли.
Конечно опыт штука ценная, но нельзя сказать что эти люди учились за счёт компании, они свою зп отрабатывали точно.
Что-то мне подсказывает, что реально происходит примерно такая динамика — в какой-то момент новое поколение программистов изобретает новый язык. Кодит на нём разное бизнес-полезное. По мере роста накопленной кодовой базы в успешных компаниях, расползается по позициям, связанным с поддержкой имеющихся решений. К этому времени из колледжей выползают новые молодые программисты. Тёплые позиции в компаниях с имеющимся софтом им массово не светят, так что они пилят новый язык и поднимают хайп. Стартапчики и молодые бизнесы ведутся, и молодые программисты, постепенно старея, расползаются по новому поколению контор. Цикл.
Из последнего.
Знакомый. Пэхэпешник. Смена работы. Вакансия, все как положено: php 5,6...100500.0, yii, laravel, ООП, mvc и дохрена прочего из мира php. В итоге пишет микросервисы на Go, а всем тем, что было в описании вакансии, даже и не пахнет.
И таких примеров, больше, чем хотелось бы.
Пэхэпешник
В итоге пишет микросервисы на Go,
Ну он же, я так понимаю, не огорчен этим фактом?
А новых надо нанимать с длинным список требований технологий используемых в сию секунду.
с длинным список требований технологий используемых в сию секунду.
Если на рынке таких людей нет, работодатель просто смягчает требования.
Я бы на вашем месте все-таки «инвестировал в самого себя», а не ждал бы доброго дядю, который бы согласился это сделать. Дядя может найтись, может не найтись. А может найтись, но оказаться не добрым, и т.д. А так, основная проблема ведь не в том, что работодатели такие редиски. Просто ваше предложение пока не слишком конкурентоспособное по сравнению с другими. Переборите свою вышеупомянутую лень, и подучите что-то мейнстримовое. От соискателя же в большинстве случаев не требуется многолетний опыт работы именно на вон том фреймворке, достаточно просто опыт плюс умение работать с нужными инструментами.
мой опыт показывает что тестовое задание неплохо отражает способности человека, а дальше есть испытательный срок
> Я бы на вашем месте все-таки «инвестировал в самого себя»
Естественно я буду изучать (как только текущие задачи доделаю), статья не обо мне, а о подходе.
мой опыт показывает что тестовое задание неплохо отражает способности человека, а дальше есть испытательный срок
Испытательный срок, это же не для проверки человека, чтобы потом принимать решение, годится он для работы или нет. Это что-то вроде стоп-крана. Когда при наборе кадров произошла серьёзная авария, и надо срочно принимать меры. Поэтому при наборе сотрудников надо исходить из того, что человек, которого берешь в коллектив, испытательный срок пройдёт. А значит, при прочих равных, он изначально должен как можно лучше соответствовать должности.
Ведь очевидно, что опыт и список технологий указанные в резюме не значат ничего.
- Малознакомый человек не знает инструмента, но обещает, что быстро выучится = высокий риск
- Малознакомый человек знает инструмент = умеренный риск
- Переучить на новый инструмент хорошо знакомого человека, который умеет
Я думал, это очевидно.
теперь вы утверждаете, что после собеседования надо быть уверенным в том, что человека нужно брать.
Не «быть уверенным в том, что нужно брать», а «нужно брать тех, кто лучше соответствует должности». По-моему, это совсем не одно и то же :)
Вы не будете увольнять после испытательного срока человека, если он не оправдал ваших ожиданий, но при этом не полная бестолочь. Да и вообще, тратить месяц на то, чтобы протестить сотрудника, годится он или нет — непозволительная роскошь, как для работодателя, так и для самого сотрудника.
по итогам своего опыта я понял что работать надо только с теми кого ты считаешь клёвыми специалистами и людьми, а кто не таков должен быть уволен как можно быстрее, пусть ищет то место где он подходит
> тратить месяц на то, чтобы протестить сотрудника, годится он или нет — непозволительная роскошь
Непозволительная роскошь годами платить зарплату тому кто недостаточно хорошо работает, хоть и не полная бестолочь
Я больше скажу, по моему опыту, оффер процентов на 80 обуславливается человеческими факторами, как со стороны нанимателей, так и со стороны соискателя, а вовсе не знанием или наличием в резюме конкретных технологий. Вот этот факт разработчики зачастую вообще не хотят признавать, и в таком контексте поднимать проблему влияния стека технологий на успешные офферы вообще смешно.
И да, извините, но глаз резануло — нет в русском языке слова «найм».
естественно надо брать того кто хочет, готов сменить технологию
> оффер процентов на 80 обуславливается человеческими факторами, как со стороны нанимателей
это понятно, но чтобы человеческие факторы сыграли роль надо начать человеческое общение, а этого не будет если тебя отсеивают по ключевым словам.
> И да, извините, но глаз резануло — нет в русском языке слова «найм».
ну формально видимо нет, а фактически может уже есть? Наём как-то не звучит.
Очевидно, что он должен уметь программировать, решать алгоритмические задачи и это нужно проверять давая тестовое задание.
У меня куча знакомых, которые целыми днями сидят на хакерранках и топкодерах и решают любые тестовые задачи (алгоритмы/структуры данных, математика, и т.д.) за пару часов (в худшем случае). Но надежными и терпеливыми разработчиками их язык не повернется назвать. Если им ставить неинтересные задачи (каковых немало на проектах) по работе, они чаще предпочтут отложить ее и порубиться в доту.
дать задачу на незнакомой технологии?
так специализация не в знании конкретных инструментов, а в знании области — бэкэнд веб разработчик он на любом языке/фреймворке свои задачи может решать
Booking.com и Амстердам — компания, которая пылесосит всех перловиков мира последние 15 лет. Пособеседуйтесь. По (ЗП — затраты на жизнь) будет примерно как Минск, может хуже, но получше Гомеля.
Ну или:
- прокачиваемся на вопросах на Java-интервью. Класслоадеры, многопоточность, модель памяти, коллекции, Спринг — в наших краях примерно такое спрашивают.
- вписываете в резюме в прошлых работах местами рядом с перлом Джаву. Для спокойствия спишитесь с тамошними вашими руководителями и объясните ситуацию.
- если HR-фильтр не проходится, пойдите на местную сходку джавистов, раззнакомьтесь, приходите на собеседование сразу к лидам команд без HR
- если не прошли, просите у собеседовавших вас людей фидбека, что не так. Очень может быть, что дело не в Перле, а в том, как вы речь свою строите, например.
Ну и дерзайте. Хороший прогаммист — он и на Java хороший программист, главное подкачаться.
Java можно заменить на что-то еще. Наверняка вам будет проще устроиться на Python, Rub. Node.
> Класслоадеры, многопоточность, модель памяти, коллекции, Спринг
благодарю, учту
> Java можно заменить на что-то еще. Наверняка вам будет проще устроиться на Python, Rub. Node.
Питон это отличный вариант, но по моим ощущениям вакансий сильно меньше.
Я не понимаю, как можно сидеть на одном языке.
Язык/платформа — это своего рода зона комфорта. Пока вы молодой, вы видите массу нового в каждом инструменте, вам интересно, вы постоянно развиваетесь. А спустя N лет в профессии и M изученных инструментов чувство новизны пропадает напрочь. И очередной модный фреймворк для вас уже выглядит как стодесятое повторение пройденного материала, и вызывает только чувство «горшочек, не вари». И изучать уже приходится не с удовольствием, а из-под палки, просто понимая, что тебе нужно быть в тренде, дабы не вылететь на обочину профессии.
И, соответственно, если у вас есть «тёплое место» и/или круг заказчиков на вашу привычную, хорошо знакомую (но стареющую) платформу, заставить себя начать заново учиться уже на новой платформе уже не так-то и просто. Надо или сделать сильный психологический рывок, или чтоб жареный петух в задницу клюнул, например, в виде потери работы.
А бизнес требует решения задачи, как правило наименее простым способом.
Угу. А ИТ-бизнес, с почасовой оплатой, наоборот, наиболее хитровымудренным :)
Столяр сегодня в деревообрабатывающей отрасли – это наемный работник с четкими требованиями по уровню владения определенными технологиями производства. Причем столяр не занимается больше никакими другими вопросами, такими как лесозаготовка, транспорт, снабжение, бухучет, планирование, сбыт и т.п. Хотя лет 100-150 назад решением этих вопросов занимался непосредственно сам столяр.
То же самое с программистом. Еще лет 20-30 назад программист мог создать на коленке операционную систему и продать ее крупной компании, которую сам же и нашел. Сегодня создание даже самой простой операционной системы – это сложный и затратный процесс, в который вовлечено большое количество людей различных профессий с разным уровнем опыта и знаний (можно конечно сделать и на коленке, то такая ОС даже даром никому не нужна).
Поэтому сегодня проблема найма в отрасли ИТ заключается в том, что в большой, зрелой и высококонкурентной сфере материального производства просто катастрофически не хватает профессиональных кадров, при этом служба по найму просто отсеивает наименее адекватных соискателей, которых на волне моды на ИТ в последние 10-20 лет расплодилось бессчетное множество. К тому же через отдел кадров ИТ-подразделения заказывают поиск сотрудников как правило только для решения типовых задач (для который perl сегодня особо не нужен).
По основной же теме статьи можно дать рекомендацию искать интересную работу не через отдел кадров, а выходить на руководителей производственных подразделений или проектов, как это делается во всех зрелых отраслях.
Даже с теоретическими знаниями пройти через скрининг HR просто.
А когда дойдёте до тех. специалиста на собеседовании, который по вашему мнению должен понимать что и как, ему и скажете.
Современный найм — отстой