Комментарии 51
Ну вот набрали вы Ответственных за результат с Критическим мышлением, Самостоятельных и Работающих на команду людей.
А код кто писать будет?
Благодаря Ответственности они будут отказываться от сложных задач и упрощать ТЗ. Благодаря Критическому мышлению они будут писать велосипеды. Благодаря Самостоятельности каждый будет писать свою версию конкретного велосипеда. Они будут Работать на команду, а значит будут поверхностно понимать свою часть работы
Или одно, или другое. Ну или что-то среднее.
Я не писал, что хард-скилы не важны. Мысль в том, что они переоценены
Я бы с удовольствием набрал "Ответственных за результат с Критическим мышлением, Самостоятельных и Работающих на команду людей" у меня только один нескромный вопрос - как???
Вы никак не проверите эти качества, только очень поверхностно!
Да и хард скилы проверить сложно, просто невероятно сложно, потому как конкретные вопросы плохо показывают реальность, на стандартные вопросы все уже выучили ответы (или через 5-6 собезов выучат, просто вы были первым в списке, вот кандидат и не подготовился)
А еще я не вижу самого главного скила - "Обучаемость и самообучаемость", то что позволяет растить человека дальше
Хардскиллы переоценены. Да, думаю сейчас это действительно так. Почти все разработчики большую часть своего времени создают микросервисы, суть которых в перекладывании json'ов из одного места в другое. Что касается творческих задач, их не так много, как хотелось бы.А при чём тут микросервисы? Круды что в монолите, что микросервисе одинаковы.
Также знание каких-то конкретных технологий (RabbitMQ) имеет мало смысла.Если в компании, куда человек устраивается, используют RabbitMQ, то вполне нормально спрашивать про него.
Тут вырисовывается одна из проблем современного рекрутинга — софтскиллы невозможно определить на собеседовании. Но тут на помощь уже приходит испытательный срок.Многие софт-скиллы и коммуникабельность как раз хорошо на интервью проверить. Проблемные кандидаты почти сразу отсеются.
Если в компании, куда человек устраивается, используют RabbitMQ, то вполне нормально спрашивать про него.
Если это стартап где ожидается что человек будет писать код в продакшен на второй рабочий день то наверно. А если нет, то зачем? Ну не знает он его, но при этом знает Кафку или ActiveMQ и что? За неделю-две разберется. Не велика разница.
Скажем, в стеке есть Кролик, Докер, k8s, нода и т. д. Человек работал с нодой, а с остальным нет. И вот выбирая между тем, кто может только код писать и тем, кто может и задиплоить всё, выбор будет за вторым при прочих равных.
У вас деплоится не по кнопке из чего-угодно типового? Что-то тут не так.
Все это на уровне типичного мидла опять таки изучается недели за 2. На уровне достаточном чтобы понимать как и с какими ограничениями твой код работает, и как это все запустить локально для дебага.
Эти знания современных технологий сильно переоценены. Оно надо тому кто первым на проекте это все делать будет. И тем девопсам которые это все подкручивают.
А тем кто в готовой инфраструктуре работает оно не сильно нужно. Со временем разберутся, не велика премудрость.
Я бы взял того кто на пальцах расскажет как на любой инфраструктуре которая ему нравится он сделает отказоустойчивый и масштабируемый сервис. И пусть он даже про кучку nginx, любых стейтлесс аппликейшен серверов и кластер ораклов на железе связно расскажет. Возьму. Перейти на любой другой стек этот человек сможет без проблем.
У вас деплоится не по кнопке из чего-угодно типового? Что-то тут не так.Да докерфайл тот же написать.
Все это на уровне типичного мидла опять таки изучается недели за 2. На уровне достаточном чтобы понимать как и с какими ограничениями твой код работает, и как это все запустить локально для дебага.Ну да, можно нанять того, кто будет изучать, а можно того, кто уже знает.
Я бы взял того кто на пальцах расскажет как на любой инфраструктуре которая ему нравится он сделает отказоустойчивый и масштабируемый сервис. И пусть он даже про кучку nginx, любых стейтлесс аппликейшен серверов и кластер ораклов на железе связно расскажет. Возьму. Перейти на любой другой стек этот человек сможет без проблем.
Если человек только на ноде умеет писать, как он вам расскажет про отказоустойчивую инфраструктуру, если у него не было опыта работы с технологиями, которые позволяют это сделать?
Да докерфайл тот же написать.
Обучение этому мастерству на требуемом для разработчика уровне занимает примерно час. С перерывом на попить чай.
Ну да, можно нанять того, кто будет изучать, а можно того, кто уже знает.
Да. Но этот критерий совершенно не важен, если вы ищите человека с рассчетом что он проработает у вас хотя бы пару лет. Потеря пары недель, на фоне двух лет работы, это примерно 2% рабочего времени. Ерунда. Любой другой критерий отбора более важен.
Мне смешно смотреть на собеседования где хотят знания очередного свежайшего фреймворка. Да он такой же как и пять прошлых. Надо будет разобраться? Вообще не проблема. Подходы не меняются уже лет 20. А бантики учатся быстро.
Если человек только на ноде умеет писать, как он вам расскажет про отказоустойчивую инфраструктуру, если у него не было опыта работы с технологиями, которые позволяют это сделать?
Вы же знаете что есть более одного способа сделать отказоустойчивую инфраструктуру? Человек может владеть другим способом. На весьма неплохом уровне причем. История у многих есть, и она очень разная. До этой ноды человек мог писать на трех других языках и заниматься всяким. В частности делать отказоустойчивый софт на любых иных технологих. И я бы взял именно его, а не того кто мне дословно перескажет типичную модную рекламную статейку о любой современной технологии.
Важно не забыть рассказать кандидату с чем ему тут придется работать и дождаться его согласия на работу с этим стеком.
Я чего-то не понял, а у вас что, очередь стоит из адекватных программистов с бэкграундом в разных технологиях и вы не знаете кого нанять?
Обычно людей ищут неделями, а то и месяцами!
Но это я опять же про хорошие кадры.
1) На моей памяти, работать с микросервисами намного сложнее в организационном плане. Повышается область ответственности разработчика - вот тут и причина.
2) На собеседовании мало что можно проверить. Только если откровенных социопатов. Все-таки прохождение собеседований это отдельный навык. И люди действительно могут отличаться на них и в реальной работе
Какая разница социопат человек или нет, поддерживает ли он ваш псевдо «командный дух» , главное чтобы в своей области разбирался и на людей не кидался)
Хардскиллы переоценены. Да, думаю сейчас это действительно так. Почти все разработчики большую часть своего времени создают микросервисы, суть которых в перекладывании json'ов из одного места в другое. Что касается творческих задач, их не так много, как хотелось бы.
Вы здесь причину со следствием путаете. Вакансий, где нужно "творить" действительно существенно меньше, чем тех, где нужно json по БД раскладывать. Но и людей с соответствующими хард и софт скилами - ещё меньше. Определённый уровень всех этих скилов в целом является необходимым минимумом на ту или иную роль.
И всякие вещи типа знания алгоритмов и структур данных, знания мат. статистики, и всякая подобная теория - всё это помогает предотвратить ошибки именно на раннем этапе проектирования. Без этого человек "натворит" так, что потом уж очень долго разгребать придётся.
Из моего опыта - человек с большим опытом но без знания этих самых структур данных (по его же признанию) наваял как-то для некоторого сервиса пред-заполнение кэша для поиска - сложный алгоритм со всякой денормализацией данных для последующей быстрой выдачи. В результате штука работала по несколько часов, тогда как свежие результаты поиска хотелось получать быстрее. Пара месяцев работы и рефакторинг в стиле "ArrayList.contains() замененить на Set.contains()" и кэш стал обновляться за 5 минут.
В целом, то что Вы описали - это middle engineer уровень без особых перспектив роста в senior+ engineer, зато с отличной возможностью вырости в engineering manager.
Да как вы задрали со своими софт-скиллами.
Щас работаю с отличным, ответственным и оч классным парнем. Только вот проблемка — когда надо было добавить новый функционал в запрос во фреймворке он тупо скопипастил сегенеренную функцию и впилил туда этот функционал. Композиция, переиспользование, абстракции? Не, говорит — а зачем, код-то работает. А я потом за ним переделываю. Зато парень реально ответственный, коммуникабельный. И к нему не придерешься — я хожу и чищу за ним код постоянно. Думаю как уволюсь — проект скатится в тухлое и неподъемное спагетти за пару-тройку месяцев
В целом, я понимаю — адекватно оценивать технические знания сложно, поэтому общий тренд на собеседование через софтскиллы. Но, блин, прямо в каждой статье "ХС переоценены. ХС не нужны. Вот параграф про хардскиллы и дальше 10 страниц про софтскиллы"
Причем одна вода:
Автор, какие вопросы следует задавать по ТЗ? ПРАВИЛЬНЫЕ
Автор, как определить, достаточно ли я самостоятелен? Сначала разберись В ТОМ вопросе, а потом приступай к ИНОМУ вопросу.
В сухом остатке идеальный современный backend-разработчик это полупрограммист-полуадмин
Понятно всё — в компании нет девопса и релизы происходят через ж, вот им и нужны "полуадмины", которые ещё в "другие отделы" будут ходить релизить. Сервер-то небось у бухгалтеров стоит, а сторожат его безопасники, угу.
Думаю как уволюсь — проект скатится в тухлое и неподъемное спагетти за пару-тройку месяцев
А зачем ждать, пока этот нарыв рванёт?
Закрадывается подозрение что вам просто нравится исправлять косяки за коммуникабельным парнем. Вы так самооценку поднимаете и ЧСВ чешете. Это не наезд. Я сам так периодически делаю.
Между тем гораздо сложнее объяснить ему, почему так делать нельзя, и привить культуру кода.
Вот жеш курва! Незаметно на софт скилы скатился...
Интересна точка зрения того парня. Он скажет возможно: есть парень, не общительный перфекционист, чистит код работающий зачем-то, но вроде вреда не приносит.
Объективной точки зрения мы по одному сообщению не увидим к сожалению.
И это ещё хорошо, если он скажет "необщительный", а не "токсичный" или "пока я фигачу бизнес-вэлью за один день он сидит неделю в коде ради штук, которые не приносят бизнес-вэлью". И с точки зрения недальновидного или не очень опытного руководителя очевидно кто молодец, а кого надо взашей гнать с работы. Потому что это как в анекдоте про "Спасаю Землю от зелёных человечков" (И не благодарите): вот есть какой-то парень который постоянно кричит "<s>волк, волк</s> надо снижать техдолг иначе потом сроки внедрения фич будут увеличиваться в десятки раз" -- а на деле этого никогда не происходит. И поймёт это дай бог если только через полгода после увольнения нормального разраба, когда уже будет поздно. (Один из таких кейсов числится даже за корпорацией Оракл, когда на фичу месяцы уходили - что уж говорить про более мелкие конторы?)
Почему, на беке у нас нормальный чел, его код приятно читать и использовать, я с ним регулярно консультируюсь по поводу похода. Мне не нравится исправлять косяки, в последнее время я смещаюсь в сторону "огородить говнокод с минимальными изменениями"
Между тем гораздо сложнее объяснить ему, почему так делать нельзя, и привить культуру кода.
Это уже тимлидство или даже ЕМство. И это я сейчас главный по фронту и решающее слово за мной — ещё можно как-то пробовать, хотя что тут делать, если человеку оно не надо?
А если бы это был мой равноправный коллега? Никакие софт-скиллы не подходят.
В этом и мой поинт — в своей погоне за важностью софтскиллов люди очень быстро скатываются на "за всё хорошее, против всего плохого", воду и отсутствие всяких границ, в то время как важность вопросов вроде "Ты написал фичу Х, могу ли я переиспользовать твой код с минимальными изменениями, чтобы написать Х2?" как-то игнорируется.
А точно ли было нужно эти "композиция, переиспользование, абстракция" в том примере? Не получится ли абстракции ради абстракций?
Интересная история. Это уже совсем крайний случай с копированием кода. В местах, где я работал такие бы испытательный срок не прошли.
Софт-скиллы софт-скиллами, но хард-скиллы не должны быть на нуле)
Понятно всё — в компании нет девопса и релизы происходят через ж, вот им и нужны "полуадмины", которые ещё в "другие отделы" будут ходить релизить. Сервер-то небось у бухгалтеров стоит, а сторожат его безопасники, угу.
Нет, совсем не так. Процесс деплоя очень хорошо настроен. Но если разработчик может поправить порт нужный в конфиге кубера или написать докер-композ, то это имхо делает его больше сеньором.
Ой, моё любимое :)
Вы кстати сейчас продемонстрировали отсутствие этого самого критического мышления. Но не об этом. Любое категоричное суждение не верно(такой вот парадокс получается). Если вы дополните статью фразами типо "в моём окружении", "среди людей которых я знаю" и так далее, то тогда это можно будет посчитать за кусочек правды.
Действительно есть такие проекты, и их сейчас много, в которых от программиста не требуется каких-то глубоких знаний именно технических. И вот для этих проектов, и только для этих проектов ваше утверждение будет верно. Но так как мир разнообразен, то есть еще много других проектов. И дело даже не в другом типе проекта, иногда дело в том как этот проект начинался и развивался.
Например я работал в проекте который был начат в режиме стартапа(давным-давно, в начале 2010-х), и начат он был не особо технически грамотными людьми, вот примерно такими как вы описываете. И вот как раз этому проекту не хватало людей с более глубокими техническими знаниями, которые могли бы собрать в кучу и причесать проект так чтобы он более стабилен технически, с меньшим количеством тех. долга, хрупкости и "гениальных" кастомных решений.
На каждом этапе жизни компании, в каждой конкретной ситуации, в каждой конкретной команде нужны разные люди. Условному Люксофту или ЕПАМу нужен один тип людей. Эти компании можно отнести к типу компаний у которых выстроена сильная менеджерская часть и от программистов требуется писать код. Софт скиллами занимаются другие люди. Есть стартап компании где либо все должны быть гармонично развитыми во все стороны, либо команда должна быть гармонично собрана чтобы все роли, а я сейчас говорю не о технических ролях, были закрыты. Ну то есть например вот у нас значит неформальный лидер команды который закрывает софт-скиллы и "разговаривает" с внешним миром, вот у нас "зануда" который следит за кодовой базой чтобы всё было чистенько и аккуратненько, вот у нас человек который в одного может "затащить" проект и так далее.
Это прям болезненная для меня тема сбора команды, навыков людей и так далее. Я могу долго говорить.
Просто включите то самое критическое мышление и посмотрите чуть дальше, или чуть глубже. А лучше смените работу :) Откроете для себя много нового, только смените прям кардинально, не на тот же...код...только в другой руке.
Отчего же только джейсончики всё время перекладываем? Бывает, легаси разбираем... Ну или плодим - как повезёт )
Почти все разработчики большую часть своего времени создают микросервисы, суть которых в перекладывании json'ов из одного места в другое.
Вся суть IT индустрии в перекладывании байтиков с одного места в другое...
Почти все разработчики большую часть своего времени создают микросервисы, суть которых в перекладывании json'ов из одного места в другое.
"Почти все" - это сильно сказано. А откуда эти jsonы берутся и куда потом деваются не задумывались?
Вообще по подобным статьям складывается впечатление, что вся разработка сводится к сборке некоего "продукта" из готовых кирпичиков типа конструктора Лего. При этом кирпичики эти возникают ниоткуда волшебным образом.
Не приходит в голову, что кто-то создает все эти фреймворки, контейнеры, очереди? И там на одних софтскиллах не выехать, нужно нечто большее.
Вообще в IT уже произошло расслоение как в остальных областях.
В медицине - есть няньки без образования, медсестры со средним специальным и врачи с высшим.
В промышленности - разнорабочие, квалифицированные рабочие, инженеры.
Аналогично и в IT - есть те, кому достаточно знать пару фреймворков, а есть те, кто эти фреймворки создает. И соотношение софт- и хардскиллов на каждом уровне свое.
Конечно, хард-скиллы не нужны, надо нанимать быстрообучаемых нацеленных на результат людей с софт-скиллами, они в процессе быстренько погуглят и скопипастят код со стековерфлоу.
Или даже через нейросетку от гитхаба сделают, сейчас будущее, старик, твои хардскиллы никому не нужны.
Когда человек говорит «хард скиллы не так важны», он «палится» тем, что проекты на которых он работал не сложные.
Потому что когда речь заходит о нагруженных, распределенных проектах, в которых считаются деньги - цена ошибки в коде резко возрастает. И нужен именно тот человек, который может и знает, как сделать все правильно и без ошибок.
Этот как сравнивать официанта и хирурга - в работе официанта не стоит вопрос жизни и смерти, по этому по отношению к нему можно требовать софт скиллы. А вот если лично вам нужно будет делать операцию, от которой будет зависеть жизнь или смерть, какому хирургу вы доверитесь? Логично, что тому, кто сделает операцию лучше. И плевать на его софт скиллы.
Негатив в комментах связан с тем, что обобщена частность. Сейчас действительно выделился класс систем, для построения которых скорее нужен бэкендер-аналитик нежели олдскульный бэкендер-хардкорщик.
Например, все мы наблюдали взрывной рост приложений, предлагающих доставку продуктов из супермаркета. Так вот соль такой системы в грамотно спроектированном домене и в архитектуре, заточенной под постоянное горизонтальное расширение. То есть сначала очень плотная работа по аналитике, а потом довольно рутинная, но аккуратная разработка (то самое перекладывание джейсонов). Прорывных алгоритмов тут ноль, инженерного новаторства ноль. Просто грамотный ремесленный труд и сборка продукта из готовых кирпичиков.
Другой полюс - это фреймворки, либы, высококритичные приложения. Тут софт-скиллы скромно уходят на второй план, и вылезает реальная потребность в computer science.
Хардскиллы переоценены.
А потом за такими ответственными с критическим мышлением и коммуникабельными людьми переписываешь код, чтобы джоб работал 5 минут, а не три часа.
Почти все разработчики большую часть своего времени создают микросервисы, суть которых в перекладывании json'ов из одного места в другое.
Нет, просто нет.
А потому и дальнейшие рассуждения ошибочны.
Толковый инженер, с широким кругозором и сильным бэкграундом разберется практически с любой технологией за пару дней (или даже часов).
Типа, кругозор и бэкграунд — это не хард-скилы?
В любой непонятной ситуации предпочту угрюмого хмыря, который пишет идеальный код. Если вы скажите мне, что такие хмыри не умеют работать в команде, то я вам скажу, что вы не умеете ставить им задачи.
Просто этот компонент джавист писал))
да, с менеджментом в IT часто полный швах…
В любой непонятной ситуации предпочту угрюмого хмыря
угрюмый хмырь по кличке Голый? )) (простите не удержался)
что такие хмыри не умеют работать в команде, то я вам скажу, что вы не умеете ставить им задачи.
это нечасто что кто-то работает в изоляции и полностью автономно, обычно что-то приходится узнавать у других и спрашивать. Сложно что-то выяснить у других если ты угрюмый хмырь. Хард скиллы важнее, но минимальные социальные навыки нужны, как то умение поговорить с кем-то так чтоб он голову не воротил. Особенно это актуально сейчас, когда многие сидят на удалёнке. Общение стало асинхронным, и нужно чтоб люди отвечали, ну не бегать же каждый раз к начальнику и продавливать каждый раз чтоб начальник ходил их пинал
Программист это человек который занимается профессиональной разработкой ПО.
Я бы сказал, что для него как раз soft-skills вторичны , а hard-skills первичны . Для меня очень странные такие посты, такое ощущение что IT это какая-то от отдельная область летающая в космосе….Никто же не пишет что «Инженеру-электронщику или инженеру который занимается разработкой двигателей» не очень важны хардскилы, вот софтскилы рулят , чем же «Инженер по ПО» так сильно отличается ?
Это первое, второе статья содержит логическую ошибку, а именно «Хороший разработчик разберётся»…У хорошего разработчика как раз будет перевес в сторону hard-навыков , soft-навыки просто достаточно на уровне «адекватного человека», для всего остального есть всякие срам-мастера и менеджеры
По такой логике можно сказать, что также было бы здорово, чтобы backend-разработчик мог и вёрстку подправить и клиентов для бизнеса найти. Несомненно, второстепенные скиллы они необходимы, однако ответственность backend-разработчик должен нести за код, который он написал на бэкенде, а не в конфиге того или иного ci/cd пайплана ( для этого всё же существует отдельная специализация ).
А если у такого разрабочика имеются все вышеперечисленные скиллы, то я сомневаюсь, что он подпадает только под определение "современный backend-разработчик", это больше напоминает универсального солдата.
пишет как-то рекрутеру ответственный, с критическим мышлением, самостоятельный и работающий на команду парень, а рекрутер ему: "извините, но нам нужен человек с минимум 5 лет опыта, 2 это мало" )
Софт скилы общая проблема, не обязательно кандидата. Часто бывает и так что рукрутер и остальная команда во время этапов собеседования показывают полное отсутствие софтскилов, а бывает что и хардскилы таких ребят вызывают вопросы.
Как по мне, софтскилы в своём большинстве - это не быть занудным мудаком, который распугает остальную команду. А Доктор Хаус ты или распрекрасный официант - это зависит от того, кто требуется на проекте и сможет влиться именно в данную команду. И если человек не подходит конкретной компании, то с его стороны жалеть об этом... простое самобичевание.
«Ответственность за результат» — что это значит ? Моя ответственность прописана в документе называемый «трудовой договор» Когда мне пытаются навязать другую ответственность, то это значит, что кто-то другой не выполнил свои обязанности. «Ответственность за результат» может быть только в том случае, когда ты отвечаешь своими деньгами за результат, в ином случае это профанация
«Критическое мышление, Самостоятельность»— ха, ну удачи вам проверить это на собеседование
«Работа на команду» — ага, значит мы перекладываем ответственность за кривые бизнес процессы на разработчика и называем это красивой фразой «работа на команду».
Есть одно правило, когда ответственных за конкретную задачу больше одного, ответственный никто . Это всё равно что говорить «Раз двигатель машины работает плохо, тогда колеса и кузов должен толкать машину вперёд»
А будет ли аналогичная статья о современном фронтенд-разработчике? Мне кажется, ее контент мог бы объяснить некоторые странности текущей статьи.
Например, если бы статья содержала аналогичные утверждения в духе "хард-скиллы фронтендеру не нужны, они просто жсоны на экран выводят, современный фронтенд разработчик это полуверстальщик-полупрограммист", то можно было бы понять, что автор из менеджеров и хочет показать место зажравшимся программистишкам.
И наоборот, если бы статья содержала рассказ про необычайную сложность и запутанность фронтенд-разработки, можно было бы сделать вывод о том, что автор жс-ник, которого на проекте явисты как-то покусами, вот он и затаил злобу.
В общем, очень жду продолжение.
Представление о современном backend-разработчике