Comments 366
Интересно узнать про ваш опыт взаимодействия с рекрутерами
Случай из жизни, один из многих: эйчар отбрасывала все резюме, в которых не было 100-% совпадения аббревиатур с перечисленными в описании вакансии.
Так, в корзину полетело резюме человека с сертификатами всяких Cisco и многолетним опытом в телекоме, потому что в нём не было аббревиатуры «TCP/IP».
К несчастью эйчара, это был тот случай, который в розничной торговле называется «тайный покупатель».
Интересный кейс)
А каких кандидатов взамен предлагала эйчар? Там были крутые специалисты?
Никаких. Отсутствие кандидатов и заставило заказчика задуматься о том, в кандидатах ли проблема.
С точки же зрения эйчара — они все не подходили.
При этом писать в резюме "знаю TCP/IP" для админа - это примерно как "умею писать ручкой на бумаге".
Недавно присылали вакансию, в которой требовалось знание dmesg. Жаль, не спросил, как он там оказался и зачем.
P.S. А в том случае был не админ, а менеджер довольно высокого уровня, но тем более.
При этом реально знают TCP/IP единицы. Чуть проблема с MTU - все, беда.
Про ipv6 я вообще молчу..
Так и ручкой на бумаге реально мало кто умеет писать. Чуть надо связное сочинение - всё, беда. Про грамматику я вообще молчу.
Пришлось оди раз настраивать MTU на сервере управления сетью зарядных станции для электромобилей, для корректной работы OCPP1.6 так как 75% пакетов терялось. Ничего страшного в настроил и заработало.
Ну так они обычно по ключевым словам и просматривают резюме. А после совпадения звонят и оценивают общую адекватность человека. Откуда им знать, что означают все эти термины?
Если человек даже не знает что означают ключевые термины по которым ведет подбор, то может ему лучше чем-то другим заниматься?
у этих странных букавак, которые в резюме пишут люди в графе навыки, есть определенные значения, которые иногда могут включать в себя значения тех странных букавак, которые хочет работодатель, но при этом это разные букавки. прекрасным хуман ресоурсез специалисткам совершенно неоткуда знать значения этих смешных слов, ведь они никогда не работали на настоящей работе. а держат их в компаниях для украшения интерьера ^^)
Никаких. Отсутствие кандидатов и заставило заказчика задуматься о том, в кандидатах ли проблема.
С точки же зрения эйчара — они все не подходили.
В данном случае тот, кто поставил задачу, не установил исполнителю порог в 80% совпадения резюме и описания вакансии.
Мне однажды отказали после собеседования, потому что у меня были MCP и MSCE, но не было CompTIA A+, а он был в списке рекомендованных сертификатов. HR просто выбирает кандидатов со 100% совпадением. Серьезно, я после этого пошел и сдал этот A+ - там два экзамена с элементарными вопросами. Чтобы просто было.
Сертификация именно так и работает. Человеку, который ничего не понимает - обычно менеджеру или, как в данном случае, хрюше - нужна бумажка, которая перекладывает ответственность на кого-то ещё. Она и называется "сертификат".
Да и сам процесс сертификации часто напоминает "покупку за $ с некоторыми телодвижениями". Ну типа в конце процесса надо пройти онлайн-тест(ы), ответы на который лежат на каждом углу, ага. Сертифицируется в итоге умение пользоваться Ctrl-F на время.
Я вам написал в личных сообщениях. Если не сложно, ответьте, пожалуйста.
этого HRa просто неверно проинструктировали.. нужно понять и простить)
так зачем было писать в вакансии TCP/IP? оно не входит в какие-то другие пункты?
да и как-то много делегировали эйчару без тех знаний.
Может быть проблема была в том, что эйчар выполнял работу, которую должен выполнять рекрутер?
Поскольку HR обычно не специалист в технических вещах, то должен быть (в среднем) перекос в плане весов софт-скилс при оценке кандидата. А многие программисты не очень общительные люди в принципе и лавное - работа этого и не требует. Мой друг рассказывал про свою работу - "Я утром здороваюсь, вечером говорю начальнику - вот - и показываю на экран - всё". Возможно это нерешаемая проблема в принципе - хард и софт скилс это противоречивые вещи, одно требует интроверсии и концентрации, другое - экстраверсии и внимания к куче внешних вещей - типа эмоций других людей.
Обычно специалистов, совмещающих в себе эти наборы качеств, руководство со временем пытается двигать на всякие менеджерские должности, дабы человек мог и контролировать непосредственно технарей, разговаривать с ними на одном языке, отслеживать их прогресс, и отчитываться начальству, переводя всё уже им.
Именно так. И денег на этих позициях больше, чем у программистов, да и работа куда интереснее (для человека, умеющего в коммуникации), так что они и не отказываются.
Насчет "куда интереснее" - сложный вопрос. Есть люди, которым интереснее создавать что-то самому, а не управлять другими людьми.
Во-первых, я — именно этот человек :)
Во-вторых, управляющий другими людьми именно что создаёт что-то сам — только это не кусок кода (железа, etc), а комплексная система, в которой написанный кем-то кусок кода является лишь одним из компонентов.
Программисты же в большинстве своём сами ничего не создают, у них просто нет простора для реального творчества — их задачей является реализация данного им (составленного и согласованного мной :) ТЗ на разработку.
Бывают же разного уровня программисты. Кто-то пилит низкоуровневый код, а кто-то - код верхнего уровня, который вызывает кучу других библиотек/процедур, написанных другими людьми. При этом параллельно конструирует GUI, например.
Я не очень понимаю, что значит "сами ничего не создают". Вот я написал процедуру, например, которая фильтром цифровой звук обрабатывает, с разными специфическими особенностями, т.е. это не тупо "взял готовую библиотеку для DSP и вызвал её". При этом я ничего сам не создал, что-ли?
Бывают же разного уровня программисты
Это количественная разница, не качественная.
При этом я ничего сам не создал, что-ли?
Вы решили проблему. При этом не только саму проблему, но и методы её решения вам довольно-таки жёстко задали другие люди.
Нет, это хорошая и важная работа. Но в её рамках у вас нет выбора, что вы создаёте, и весьма ограниченный выбор — как. Примерно как у штукатура, которому дали задание выровнять стены в квартире (и в принципе да, ровную стену в итоге он создал, можно и так сказать).
На менеджерском уровне выбор и того, и другого существенно расширяется (впрочем, как ниже отмечено, и спектр геморроя — тоже).
Почему количественная? Бывает программист, которому по силам внести только изменения в небольшую часть кода, а бывает - которому по силам структуру проекта перепроектировать.
При этом не только саму проблему, но и методы её решения вам довольно-таки жёстко задали другие люди.
Не факт. Допустим, сказали такое: "нужно реализовать эквалайзер для звука, работающих в реальном времени на процессоре такой-то производительности. Найди подходящее решение и реализуй его". То есть, здесь нужно и некоторое исследование провести. При этом, менеджер сам мог никогда с такими задачами в своей практике не сталкиваться, даже если он сам программист 80-го уровня.
ИМХО, это еще вопрос личного восприятия. Для меня и создать процедуру, которая хорошо решает поставленную задачу - вполне созидание чего-то. Особенно, если ничего готового ни в каких библиотеках нет.
Почему количественная? Бывает программист, которому по силам внести только изменения в небольшую часть кода, а бывает - которому по силам структуру проекта перепроектировать.
Потому что это — количественная разница. Единственное отличие между двумя — какое количество кода каждый из них способен написать, не сломавшись.
Не факт. Допустим, сказали такое: "нужно реализовать эквалайзер для звука, работающих в реальном времени на процессоре такой-то производительности. Найди подходящее решение и реализуй его"
Вы повторяете ровно то, что я вам написал: вам дали задачу и указали на метод её решения. Какие конкретно буквы будут написаны в рамках этой задачи и этого метода — это примерно тот же уровень самостоятельности, что у штукатура в выборе мастерка и марки штукатурки.
При этом, менеджер сам мог никогда с такими задачами в своей практике не сталкиваться, даже если он сам программист 80-го уровня.
Есть некоторая разница между «не сталкивался» и «не знает, что они вообще существуют».
Программист про задачи уровня менеджера — обычно второе.
Так ведь не указали метода решения. Сказали "сам найди метод".
работающих в реальном времени на процессоре такой-то производительности
На уровне проекта — это и есть метод.
Повторюсь: какими строчками кода вы его реализуете, значение имеет примерно такое же, «волмой» или «ротбандом» штукатур будет стену выравнивать. Просто в силу незначительности этого вопроса в общем масштабе.
Хотя если вы спросите любого опытного штукатура — он вам получасовую лекцию про разницу между ними выдаст. И про исследования там тоже будет.
На уровне проекта — это и есть метод.
Это не метод. Это граничные условия.
Странно, что менеджер этого не понимает.
Менеджеры тоже разные бывают. Есть такие, что сами от себя вне себя, их просто раздувает от "важности решаемых ими задач", а по факту они ничего из себя не представляют вше нежели "погонщик кобылы" - им сверху спустили указявку "перегнать телегу с грузом туда-то", вот они загрузили ее, кобылу запрягли и нахлестывают ее изо всех сил чтобы бежала быстрее. Сдохнет по дороге потому что покормить забыли - так это кобыла плохая попалась. Идет медленно потому что телега слишком тяжелая, а дорога плохая - опять кобыла виновата, надо сильнее ее кнутом...
Тогда и менеджер ничего не создает. Ему дали задачу сверху, дали ресурсы и методы решения, вот он и крутится. Только самые-самые топы в менеджементе что-то созидают. /s
Нет. На менеджера чуть выше среднего сверху уже не спускаются конкретные проблемы, сверху спускаются хотелки руководства, клиентов и т.п. Их отличие от конкретных проблем — в том, что про них неизвестно не только, каким образом их решать, но и можно ли их решить вообще в рамках ресурсов, располагаемых компанией.
Менеджер оценивает, можно ли это сделать, согласовывает варианты решения со всеми заинтересованными сторонами, оценивает ранее неучтённые факторы (например, проблемы соответствия законодательству, долгосрочные риски, перспективы рынка и т.п.), согласовывает ещё раз — после чего уже раскладывает на конкретные проблемы и спускает на исполнителей.
P.S. Например, не далее как вчера я объяснял архитектору очень, очень большого решения, что мне нужно носить данные на CD-R. Мне всё равно, что они подписаны ЭЦП и их нельзя подделать. Мне всё равно, что их любой желающий может сам скачать с сайта. Мне всё равно вообще на все технические соображения о том, как надо писать программы в 2023 году, потому что у меня есть параграф 9 пункта 6 статьи 33 федерального закона № 67-ФЗ, который в явном виде предполагает процедуру «получить от» — а значит, эта процедура должна быть. И практика, в рамках которой реализация данной процедуры с использованием CD-R другой стороной была признана разумной и не повлекла написания жалобы ни мне, ни в вышестоящую комиссию, ни в суд, у меня тоже есть.
Пес его знает, но многие программисты (и я тоже имею такой опыт), часто получают от менеджеров задачи, про которые "неизвестно не только, каким образом их решать, но и можно ли их решить вообще в рамках ресурсов, располагаемых компанией". Юридическими вопросами программисты, конечно, обычно не занимаются (их возвращают обратно менеджеру, фактически ставя перед ним конкретную задачу), но других тоже более чем хватает.
Есть много плохих менеджеров, есть много плохих программистов, а уж штукатура хорошего вообще днём с огнём, новости в том нет никакой.
Юридическими вопросами программисты не только не занимаются, но и не возвращают менеджеру — потому что даже не подозревают о существовании таких вопросов. В приведённом примере с точки зрения программиста — подписанный ЭЦП PDF, который любой желающий может скачать с публичного сайта, не просто не вызывает никаких подозрений, но и является очевидно много лучшим решением, чем какие-то CD-R, вы б ещё на дискеты бы записать предложили.
Юридическими вопросами программисты не только не занимаются, но и не возвращают менеджеру — потому что даже не подозревают о существовании таких вопросов.
Программисты разные бывают. Те, что решают только узкие задачи типа "написать процедуру с таким-то входом и таким выходом", естественно, до юридических вопросов никогда не опускаются.
Но если у программиста больше уровень самостоятельности, то юридические вопросы, вытекающие из ТЗ, он вполне должен уметь вычленить, и поставить перед руководством (ибо решать их не его дело).
Например, та же запись на CD-R.
Если программист замечает, что оно по закону должно быть, но не отражено в детально составленном ТЗ, то он должен поставить вопрос перед менеджером (если менеджер скажет "нафиг", то это уже его, менеджера, проблемы и его же зона ответственности).
Если же ТЗ составлено максимально неконкретно, то он сам должен сделать "как положено", ибо условная кнопка "сделать хорошо" предполагает в том числе и соответствие результата требованиям закона. И если по закону (или по ГОСТУ, если оный прописан в ТЗ, или по хотелкам заказчика, озвученных за пределами ТЗ) некоторый вариант должен быть реализован, то даже реализация лучших вариантов не основание для отсутствия реализации требуемого.
А еще бывают программисты, работающие в одно лицо, общаясь непосредственно с заказчиком, либо вообще являющиеся сами себе заказчиками.
Если программист замечает, что оно по закону должно быть, но не отражено в детально составленном ТЗ
Вы не очень понимаете, что такое «по закону должно быть».
В законе нигде ничего про CD-R не написано.
В законе написано, цитирую дословно, «знакомиться с протоколами избирательной комиссии, в которую он направлен, и протоколами непосредственно нижестоящих избирательных комиссий об итогах голосования, о результатах выборов, с документами, приложенными к протоколам об итогах голосования, о результатах выборов, получать от соответствующей избирательной комиссии заверенные копии указанных протоколов» (и пардон, я там рефлекторно номер закона перепутал, это конкретно из 20-ФЗ, хотя в 67-ФЗ есть такое же, конечно).
Вот из этого — а это всего один пункт большого и сложного закона, в котором одна только статья, из которой эта цитата, занимает несколько страниц — надо зацепиться глазом за «получать от соответствующей избирательной комиссии» и задуматься, а что это вообще значит — получать от комиссии?
А как это выглядит на практике, вживую? А с точки зрения наблюдателя? А что дальше он делает с этими копиями, после получения, а зачем он это делает? А что надо сделать, чтобы эту практику не сломать в случае, когда протоколы — это файлы PDF? Какие есть варианты, какие у них проблемы, как они будут восприняты и наблюдателями, и комиссией? А судами, если до судов дело дойдёт?
Это огромный объём информации, подразумевающий либо практику соответствующей работы (я — дважды зампредседателя и пока что только один раз председатель избирательной комиссии), либо целый список людей, с которыми по этим вопросам надо поговорить.
Если программист этими знаниями обладает — он давно уже не программист.
Ваше же «заметить, что по закону должно быть» выглядит примерно как совет программисту «заметить, что по Страуструпу должно быть».
Ну что ты тут в коде ошибки делаешь, по Страуструпу ошибок не должно быть.
В программировании тоже есть очень много подобного.
Я работаю в финтехе, девопсом, и чаще всего именно программисты мне рассказывают о том, что "это требование регулятора, и обычно в индустрии оно реализуется так или эдак, и мы выбрали это решение, потому что то и это"
Очевидно, что требование регулятора нужно как-то понимать, чтобы не реализовать дыру вместо стены.
Или "по требованию аудитора должно быть так и эдак, но в жизни это всё равно, что дыру в стене газеткой прикрыть, потому что с тех пор случилось это и вот это, а требования ещё не обновились, поэтому вот тут у нас штука, чтобы аудитор был счастлив, а тут настоящая кирпичная кладка в месте дыры"
И да, надо нос по ветру держать, что там у нас требуется от аудиторов, от регуляторов, от локации (потому что в разных локациях разные законы и разные правила, и разные все эти сущности), а также, что там нашли-обнаружили-открыли (тот же log4j, который "мы" заранее поменяли, а "они" только когда аудитор возбудился)
А также абсолютно обыденна ситуация, когда "вот у нас появились новые требования, а как их реализовать пока никто не знает", и нужно как-то подумать и что-то сделать, чтобы оно соответствовало новой policy.
И да, это-таки требует людей, с которыми можно поговорить и понимания предметной области вообще, и понимания, что делает конкретное приложение в частности.
я правильно понимаю, что в ваших терминах, если директор приказывет подчиненному: "создай новый классный продукт, потому что другие что-то показывают слабую доходность", и подчиненный создает новый продукт, то создатель продукта - директор?
а его подчиненный, так, просто маленький винтик, который выполнил задачу?
Нет, создатель продукта — подчинённый.
Но программисту не ставят задачу «создай продукт, который показывал бы доходность выше имеющихся».
Он её просто не решит никогда, у него нет на это квалификации.
Тут бы стоило добавить что-то, типа "на сколько я знаю", или "как показывает моя практика". ")
А то моя, например, практика показывает, что иногда програмисту такие задачи таки ставят :)
И програмист её таки вполне способен решить. Как минимум мне известен один такой случай.
Я абсолютно уверен, что в мире есть хотя бы один таксист, умеющий управлять гражданскими авиалайнерами.
Тем не менее, я могу уверенно утверждать, что у таксистов нет квалификации по управлению гражданскими авиалайнерами и что таксистам не ставят таких задач.
Как насчёт аэротакси? ;)
А с програмистами ситуация ещё хуже - они могут вообще практически любой квалификацией обладать. Я учился с человеком, который одновременно являлся и практикующим програмистом, и практикующим хирургом. И это не единичный случай, на сколько я знаю.
Так-то уверенно утверждать можно всё, что угодно. :)
Не в любых организациях четко разграничены полномочия между сотрудниками, так что "шаг влево - шаг вправо, и это уже не твоя обязанность".
очень часто менеджер может понимать, что нужно сделать, чтобы продукт взлетел, но сам он это сделать не может
и даже не знает в чем лежит проблема, и какой можно придумать план решения
а еще чаще менеджер вообще не видит проблемы, потому что его образования не хватает увидеть, что может быть лучше
например - сайт должен загружаться быстро, максимум за 0.2 с
или было бы прекрасно, если бы смартфон имел экономный режим, в котором мог бы работать пару недель; для этого уже сейчас есть все необходимые компоненты - супер энергоэффективные чипы, большие аккумуляторы, амолед экраны (для того, чтобы рисовать не весь экран 1440*3088, а только пару тысяч пикселей, чтобы нарисовать текст) и электронные чернила
то же самое касается умных часов - какая религия запрещает им работать хотя бы месяц?
или, было бы очень хорошо, если бы появилась система типа windows copilot, но доработанная - говоришь ей запустить проект А, и она находит все IDE у тебя на пк, находит среди проектов нужный и запускает среду
или по команде бл*** отменяет 3 последних действия
но менеджер никогда не сможет дать какой-то внятный план, кроме декларативного описания: "хочу, чтобы было так", потому это исключительно задача программистов понять, как этого можно добиться
ведь способов достижения множество, но каждый из них имеет преимущества и недостатки
определить лучший способ с учетом всех следствий этого способа - тоже задача программиста
из-за того же, что менеджеры не способны понять долговременные последствия своих решений, мы столь часто пользуемся столь ужасными продуктами - глючными, медленными, переусложненными, неудобными, выжирающими всю память и цпу
у меня смартфон 20 летней имеет приблизительно те же возможности, что и текущий (браузер правда работает получше), он работает примерно то же время от батареи, он приблизительно столько же заряжается, только камера хуже (сильно хуже)
при этом у старого смартфона в 15-20 раз слабее процессор, у него в 2000 раз меньше оперативной памяти, у него в 7 раз слабее аккум!
как показывает практика, любого человека можно обучить на менеджера, но только некоторые могут стать программистами
потому задача программистов как раз более творческая, но и более сложная
"Показать доходность выше имеющихся" -- как раз один такой программист недавно и давал показания в суде.
То есть вы хотите сказать, что программист, переведший ваше ТЗ в программу творчеством не занимается, а вы, переведший слова заказчика в ТЗ занимаетесь творчеством? Так что-ли?
Вообще говоря, да.
Программист — исполнитель, творчества у него в работе примерно как у штукатура. За излишнее творчество его и вовсе наказывают обычно.
А что, ТЗ уже стали писать как сочинение на свободную тему? Или там все-таки тоже свои правила есть? В чем творчество перефразировать слова заказчика, иногда проясняя места не до конца осознаваемые этим самым заказчиком места?
Вы хотя бы раз в жизни с реальными заказчиками работали?..
У них нет слов, которые можно «перефразировать». У них есть некоторое представление о том, что должно получиться в конечном итоге — не учитывающее технологические возможности, ресурсные ограничения, действующее законодательство и многое другое.
От слов заказчика до ТЗ обычно месяц работы. Иногда больше. И заказчику это «перефразирование» запросто может стоить от сотен тысяч до миллионов рублей.
Вот вы сами пишете, что ни аналитиком, ни продактом не работали - вот кто делает реальную творческую работу и спасает заказчику миллионы. Так что программисты/менеджеры и прочие там "штукатурщики" пусть не примазываются.
Гм. Ну не надо за меня додумывать, пожалуйста. Я пишу, что там, где я занимаюсь менеджерской работой — нет, на меня ни аналитику, ни PO/PM не вешают.
Продактом я работал, причём в нескольких разных качествах, не только программистском. С аналитиками работал. Код, если что, тоже руками писать умею.
Я за вас не додумываю. Я вас цитирую https://habr.com/ru/companies/outlines_tech/articles/772572/comments/#comment_26137184
«Не приходится» — настоящее время, «не работали» — прошедшее. So much for базовые навыки анализа информации.
Чем вы тогда отличаетесь от "штукатурщика" в настоящее время? Все детали про продукт выясняют продукты с аналитиками. Вам остаётся с заданным бюджетом и ТЗ в нужный срок поставить продукт. Планирование ресурсов, раскидывание задач в JIRA по программистам не выглядит как содержательно сложная задача по созиданию. Тут даже методология не так важна.
Все детали про продукт выясняют продукты с аналитиками
У вас заказчик им сам задачи ставит, напрямую?
Планирование ресурсов, раскидывание задач в JIRA по программистам не выглядит как содержательно сложная задача по созиданию.
Какого масштаба (в человеко-месяцах) проектами вы лично руководили?
Вместо ответов вопросом на вопрос вы могли бы привести пример творческой задачи менеджера, тогда возможно ваши оппоненты поняли бы что вы подразумеваете под словом "творчество")
Я нигде не утверждал, что у менеджера творческие задачи.
Но у него существенно меньше рутины и существенно большее разнообразие задач, чем у программиста.
В свете чего человеку, доросшему до нормальной менеджерской позиции, заниматься программированием попросту скучно.
Хм, давайте не будем всех программистов сваливать в одну кучу.
У какого процента программистов выполняемые задачи не являются рутинными? Какой процентов программистов в своей работе создаёт что-то новое?
По моей оценке рынка труда — меньше 1 %.
Олег, слежу за тредом, отвечу здесь) Это бесполезно программистам доказывать, что это "скучно" и "рутинно" и что они не делают что-то новое. И Вы тоже таким были. И я таким был. Это лечится годами в индустрии и ростом в ней. А у кого-то не лечится. И это тоже хорошо.
Я понимаю о чем вы говорите и поддерживаю Вашу точку зрения, но по сути идет разговор слепого с глухим.
Написал просто поддержать и пожелать добра)
«Кажется»? Я в одном из первых комментариев написал — жаль, что вы не прочитали — что к «кажется» у меня нет никаких претензий. Мне вот оливки кажутся невкусными.
Но зачем-то многие тут пытаются доказать мне, что она таковой является.
Вы тоже не горите желанием принимать другую точку зрения, только и всего) Возможно, никому из вас этого и не надо?) У всех свой путь и понимание мира, индустрии, происходящего. Вероятно, не всегда стоить убеждать человека в своей точке зрения.
Но ментальная гимнастика забавная у вас тут получилась.
Про менеджмент, просто вкину мысль, что менеджмент это тоже программирование, просто машины намного более сложные и забагованные по самый небалуй, а языков программирования для них нет. Но и возможностей у них пока что значительно больше.
Отлично, значит вы в принципе не отрицаете, что программисты создают что-то новое.
У какого процента программистов выполняемые задачи не являются рутинными?
Раскройте пожалуйста значение слова "рутинные" в вашем понимании.
«Утомительный, однообразный, лишённый творчества».
Написание кода именно такое.
А, так вы про "написание кода"? Тогда ладно.
У какого процента программистов выполняемые задачи не являются рутинными?
Ну тогда думаю у большинства, ну кроме стажеров и наверное большинства джунов.
Дело в том что, ну как по мне, "программирование" != "написание кода".
99 % (минимум) программистов не решают никаких задач, выходящих за рамки написания кода (и сопутствующих ещё более рутинных процессов: изучения документации, описывающей, как правильно писать этот код, поиска библиотечек, позволяющих писать меньше кода, поиска подходящих алгоритмов в случаях, когда библиотечек не нашлось, для написания на их базе кода).
изучения документации, описывающей, как правильно писать этот код, поиска библиотечек, позволяющих писать меньше кода, поиска подходящих алгоритмов в случаях, когда библиотечек не нашлось, для написания на их базе кода
Простите, но почти все композиторы тоже сочиняют произведение на основании изученной базы. Та самая "Теория музыки" ("документация"), которая позволяет композитору сочинить произведение из подходящих фрагментов ("алгоритмов") для получения нужного результата.
Рутина есть и там и там, но также и там и там есть творчество.
Ещё раз: результат работы композитора уникален. Он не может быть повторён другим композитором, и в этом ценность композитора. Вы не можете нанять композитора на Хедхантере и сказать «у нас раньше Эннио Морриконе музыку писал, теперь ты продолжай писать такую же» и рассчитывать, что музыка будет не хуже.
Это — творчество.
Результат работы программиста — не уникален, он может быть повторён другим программистом, что тысячекратно демонстрируют все устоявшиеся практики разработки, в которых bus factor обычно тождественно равен нулю. Вы можете нанять программиста на Хедхантере и сказать «у нас раньше вот этот коннектор к СУБД писал, теперь ты продолжай писать такой же» и рассчитывать, что коннектор будет не хуже.
Это — ремесло.
Ничего плохого в том, что работа программиста — это работа ремесленника, нет. Но это работа ремесленника. Рутинная и однообразная.
не можете нанять композитора на Хедхантере и сказать «у нас раньше Эннио Морриконе музыку писал, теперь ты продолжай писать такую же»
Простите, но вы не будете нанимать композитора, который пишет музыку как Эннио Морриконе, вы будете искать композитора, который будет писать музыку в определенном стиле, жанре. А вот тут уже можно найти и "такую же" (Настолько же подходящую к продукту, как и музыка написанная Эннио Морриконе).
PS: Я и не говорил, что ремесло – это плохо
Нанять композитора еще как можно. Откуда берется озвучка к современным играм, сериалам, фильмам, по-вашему? И то что выдают эти композиторы - прямо очередной Моцарт или Вивальди? Как раз наоборот - среди потока современной музыки еще попробуй найди что-то уникальное или хотя бы узнаваемое. Сегодня это на 99% ремесло. А то, что композиторов нанимают не обязательно на хэдхантере - другой вопрос. И, кстати, спросите какого-нибудь композитора, который пишет современную попсу, считают ли они свою работу рутиной или нет.
Ещё раз: результат работы композитора уникален. Он не может быть повторён другим композитором, и в этом ценность композитора. Вы не можете нанять композитора на Хедхантере и сказать «у нас раньше Эннио Морриконе музыку писал, теперь ты продолжай писать такую же» и рассчитывать, что музыка будет не хуже.
Даже насчёт композиторов вы не правы) Профессиональный композитор может, вообще говоря, писать музыку и "как Морриконе" и "как Моцарт". Другое дело, что, возможно, ему потребуется какое-то время на изучение стиля нужного композитора.
Результат работы программиста — не уникален, он может быть повторён другим программистом
Я неоднократно видел примеры задач с которыми одни программисты справлялись а другие - нет. Некоторые задачи могут "повторить" лишь несколько десятков человек в мире. Так что с практической точки зрения повторить можно не любой результат.
Я неоднократно так же видел как один программист создавал хороший продукт который потом долго жил и всех радовал а другой программист создавал формально работающий продукт который затем доставлял сплошную головную боль. То есть даже для выполненной работы результат существенно зависит от программиста и несет отпечаток уникальности. Один-в-один повторить не удастся.
Так что я тут вижу прямую аналогию с композиторами. Если Вам надо написать музыку к фильму, то подойдет не любой композитор и у разных композиторов будет немного разная музыка. Если композитор - гений, то найти ему замену будет сложно. Точно так же и у программистов.
Перед тем, как написать код, надо провести определенную работу: выбор алгоритмов, библиотек, анализ существующих решений и т.д. Это вполне творческая работа. ИМХО, конечно. Кому-то, возможно, это давно надоело. Лично мне нет.
Более важным (и сложным) для меня является анализ тз. Когда надо в голове (а в более сложных случаях рисовать на листочке или в draw.io) составить всю схему проекта и точно понять, возможно ли оно в принципе, что, как и с чем будет связано, Затем высыпать миллион вопросов тому кто это тз дал (в моем случае - тех.лиду). Даже элементарные - "а является ли эта штука (поле) уникальной для пользователя ибо тут в тз написано, что пользователь может добавить свой домен, но не указано, может ли быть один и тот же домен у многих пользователей, а так же может ли иметь пользователь более одного домена". Уже потом набросать простую схему, ещё более подробно подумать как это реализовать и потом уже приступать к работе.
То есть, в тз, вроде и описано всё. Но не встречал ни одного тз, когда не было бы по нему вопросов и обсуждений. Потому что кроме самого программиста, приступающего к работе над задачей, множество нюансов никто просто не увидит заранее. Да даже сам программист может с ними столкнуться уже в процессе.
Так что читать эту ветку от менеджера, который считает что программист=штукатурщик - забавно)
Не исключаю, что просто всегда не везло, а других всегда чёткие внятные ТЗ, которые уже заранее разбиты на элементарные задачи, а ты просто сиди и код пиши. Но я не встречался с таким(
По моей оценке менеджеров которые занимаются чем-то нетривиальным точно так же очень мало и это в основном топовые позиции которых по объективным причинам немного :).
В мелких компаниях есть некоторый перекос, т.к. там тоже нужен свой топ менеджмент а низовых менеджеров гораздо меньше + там обычно тупо нет сложных задач которые мелкая компания реалистично могла реализовать (ей просто ресурсов на это не хватит) и соответственно нет нужды в топовых программистах. В крупных IT компаниях картинка становится гораздо однороднее. Там есть и очень интересные позиции по программированию и куча менеджеров которые занимаются рутиной.
Но у него существенно меньше рутины и существенно большее разнообразие задач, чем у программиста.
Ой да ладно.
Постоянно на телефоне одни и те же слова (ну чуть другие после курсов типа "7 шагов к успеху", но суть та же).
Потом отчеты, бланки, кпи.
Менеджеры еще более погрязли в рутине. И как раз творческая задача менеджера это из рутины вылезти и делать что-то творческое. Но - огромная редкость.
Попробуйте как-нибудь месяцочек поработать менеджером. Вас может неприятно удивить тот факт, что просто механически произносить в трубку слова, когда вам, например, надо согласовать проект с тремя группами людей, у каждой из которых свои интересы, противоречащие интересам двух других групп, недостаточно.
И выстраивание устойчивых отношений между людьми — работа существенно более сложная и менее рутинная, чем написание кода (я слышал, с этим Copilot и ChatGPT с каждым днём справляются всё лучше).
Но да, зато нам и платят больше за меньшее :)
Попробуйте как-нибудь месяцочек поработать менеджером. Вас может неприятно удивить тот факт, что просто механически произносить в трубку слова, когда вам, например, надо согласовать проект с тремя группами людей, у каждой из которых свои интересы, противоречащие интересам двух других групп, недостаточно.
Вы может быть удивитесь, но просто так писать операторы и аргументы в коде, может быть недостаточно, когда нужно согласовать работу нескольких объектов, учитывая интересы версионирования, совместимости и типизации компонентов, фреймворков, платформы и архитектуры.
И выстраивание устойчивых отношений между людьми — работа существенно более сложная и менее рутинная
Что там сложного? Даешь всем достаточную зарплату, и взрослые люди сами себе устроят устойчивые отношения.
Во время собеседования выбираешь себе взрослых адекватных людей.
В процессе работы следишь кто занимается токсичностью, делаешь выговор вплоть до увольнения.
Сложнее - в детском садике отношения выстроить.
И да, опыт руководящей должности (несколько лет) имею.
Даешь всем достаточную зарплату, и взрослые люди сами себе устроят устойчивые отношения.
Сложный момент. Бывает, что в какой-то момент (лет через 5, 10) люди начинают "выгорать", или им кажется, что зарплаты недостаточно, или что-то еще в жизни происходит. И адекватные люди начинают пороть дичь. Или устраивают итальянскую забастовку. И тогда без руководителя не обойтись.
Во время собеседования выбираешь себе взрослых адекватных людей
Это примерно такая же гарантия, как "я замуж выходила за адекватного и нормального человека, а он через 10 лет превратился в ..., лежит на диване, работать не хочет" и т.д.
Сложнее - в детском садике отношения выстроить
У взрослых людей бывают куда сильнее развиты хитрость, изворотливость и прочие отрицательные черты.
Попробуйте решить вот такую задачку:
Есть две БД по десятку таблиц в каждой. Одна БД содержит ~50млн элементов, вторая - ~500тыс элементов. Структура элементов разная, но есть ряд неких общих признаков (5-7 штук). Обе БД регулярно изменяются и после каждого изменения требуется провести поиск совпадений и обносить таблицу текущих совпадений (т.е. не просто тупо занести туда, а анализировать - для этого элемента было совпадение по таким признакам, стало по таки, для этого было по таким, сейчас нет, для того не было, но появилось).
Ресурсы ограничены - вы не можете под эту задачу выделить дополнительные вычислительные ресурсы - работаете в тех рамках, что вам дано. И да, вы не можете просто так взять и поставить туда какой-то "супермощный движок который все за вас сделает". Должны сами придумать и написать то, что будет работать должным образом.
Временное окно жестко ограничено. Допустим, не более 2-х часов (решение "в лоб" занимает 15-17 часов на имеющихся ресурсах).
Выстраивание рабочих отношений между людьми - творчество?
я слышал, с этим Copilot и ChatGPT с каждым днём справляются всё лучше
Ну да, кусок индусского кода они написать могут. На основе анализа тонн другого индусского кода.
Не надо противопоставлять разработчика (а это немножко больше чем программист) и менеджера. Это совершенно разные вещи. Это даже две разных карьерных линии - экспертная (разработчик) и административная (менеджер). Все равно как сравнивать композитора и художника - кто из них более творец.
У каждого человека есть некая "превалирующая черта", которая позволяет ему достичь наилучшего результата в каком-то направлении. Есть талантливые разработчики, но никакие менеджеры. Или наоборот - талантливые менеджеры, но весьма посредственные разработчики.
Могу сказать за себя - я разработчик. У меня нет (и практически никогда не было) "рутинных задач". Каждая задача - головоломка, которую можно решить многими способами и нужно выбрать тот, который наилучшим образом подходит в данном конкретном случае. Самым быстрым в одном, потребляющем минимум ресурсов в другом, сбалансированным в третьем и т.п. Я не занимаюсь задачами где нужно просто из готовых кирпичиков что-то стандартное сделать. Просто не берусь т.к. не интересно. Только "задачки со звездочкой", где нужно подумать прежде чем писать код. Будь то работа с каим-то нестандартным железом, ковыряние в глубоких потрохах системы или обработка больших объемов данных за минимальное время.
Я знаю, что менеджера из меня не получится - просто не интересна эта деятельность. Предлагали пойти в архитекторы направления, быть ответственным за развитие. Попробовал - не мое. Много разговоров, которые ни к чему не ведут. Собрались, час проговорили, ничего не решили, отложили на не неделю. ППР (посидели, поп...дели, разошлись). Мне это кажется пустым времяпровождением.
При этом знаю людей, которым это нравится и у которых это получается. И в голову не приходит противопоставлять где больше творчества, где больше рутины. Каждый находит то, что ему по душе и там реализует себя наиболее полно.
Я прочитал, Олег, всю вашу переписку здесь и ниже, в целом кажется вас понимаю, и одновременно с этим меня не триггерят (как граждан ниже) темы про ОЧЕРЕДНЫЕ СТРАШНО СЛОЖНЫЕ ДРАЙВЕРА или БАЗАДАННЫХ100500КОРТЕЖЕЙ, так что я сделаю осторожное предположение, что вы на самом деле лукавите немного, или просто в разных ветках уже путаница пошла. Очевидно для составления ТЗ нужны компетенции продуктового аналитика, а также технический и менеджерский бэкграунд. А для качественного технического менеджмента - если разработка делается не "чисто по ТЗ, что бы ни вышло в итоге" - помимо компетенций менеджера требуется также и уметь пересматривать требования, и выходить снова на стейкхолдеров с альтернативными предложениями - тут опять требуется бэкграунд в аналитике и конкретных технических областях. Полагаю, что если вопрос поставить именно так, то ваши собеседники вас поймут. Сейчас же они очевидно считают, что вы просто тикеты в джире передвигаете - причем буквально "передвигаете", не задумываясь. Для этого конечно много ума не надо, и не слишком честный с собой ремесленник всегда видит в этом только "пустую болтовню" (см. ниже комментарий от несостоявшегося архитектора ПО). Но в комплексе - да, это то, что нужно, и это то, за что платят. И, да, зарплаты программистов определяются только соотношением спроса и предложения (которое неизбежно деградирует), а зарплаты вменяемых технических руководителей/аналитиков/тимлидов/техлидов принципиально ничем не ограничены, и в этой сфере никогда не будет оптимального для цивилизации соотношения спроса и предложения именно потому, что способности людей подчинены закону нормального распределения. Ремесленников же всегда будет достаточно, и дизруптивные переходы - лишь временное явление.
А этот ваш вопрос про проекты и ответственность - вы его кому задаете из ваших собеседников?)) Вас слышат сугубо как "сперва добейся", если даже вы пытаетесь вложить в свои слова филигранную иронию.
Гм, программист вообще с естественного на машинный переводит. И в ТЗ тоже нет "тут используем такую переменную, а тут вообще массив".
А по времени вообще реализация может длиться на порядок больше, чем составление ТЗ. Ну и опять же можно так ТЗ реализовать, что заказчику это в копеечку влетит.
Так где качественная разница? В чем она заключается?
И в ТЗ тоже нет "тут используем такую переменную, а тут вообще массив".
Потому что в 99,9 % случаев это абсолютно несущественные детали, в которых замена одного решения на другое не влияет ни на что значимое.
Господи, да даже замена языка программирования целиком в большинстве задач ни на что видимым невооружённым глазом образом не влияет.
А по времени вообще реализация может длиться на порядок больше, чем составление ТЗ.
Может. И задача менеджера — учитывать и это тоже, стогласовывать с заказчиком, распределять нагрузку по программистам, планировать ресуры.
Так где качественная разница? В чем она заключается?
Очевидно, в «не влияет ни на что значимое» vs «заказчику это в копеечку влетит».
Потому что в 99,9 % случаев это абсолютно несущественные детали, в которых замена одного решения на другое не влияет ни на что значимое.
Очевидно, в «не влияет ни на что значимое» vs «заказчику это в копеечку влетит».
То есть вы хотите сказать, что работа программиста не влияет практически никак? Ну что же, очень смелая мысль. Осталось только выяснить, зачем такой строгий отбор в программисты нужен.
Может. И задача менеджера — учитывать и это тоже, стогласовывать с заказчиком, распределять нагрузку по программистам, планировать ресуры.
А теперь объясните в чем творчество рассматривать диаграммы Ганта и набирать письма "разработка займет неделю, дайте стопицот денег".
То есть вы хотите сказать, что работа программиста не влияет практически никак?
Сейчас вы пытаетесь расширить ваше собственное «тут используем такую переменную, а тут вообще массив» на всю работу программиста задним числом.
Это либо примитивный демагогический приём, либо индикатор вашей некомпетентности, в рамках которой вы всю работу программиста искренне сводите к выбору между переменными и массивами (и, наверное, ещё структурами).
А теперь объясните в чем творчество рассматривать диаграммы Ганта и набирать письма "разработка займет неделю, дайте стопицот денег"
Проекты какого масштаба вы сами оценивали по срокам и ресурсам, лично отвечая за точность этой оценки?
Сейчас вы пытаетесь расширить ваше собственное «тут используем такую переменную, а тут вообще массив» на всю работу программиста задним числом.
Гм, разве не очевидно, что это был просто пример для иллюстрации? Вроде специально максимально примитивный выбрал.
Проекты какого масштаба вы сами оценивали по срокам и ресурсам, лично отвечая за точность этой оценки?
То есть от качественных показателей (написание писем и планирование) вы все-таки решили перейти к количественному (цена ошибки)? Я правильно понял?
Вроде специально максимально примитивный выбрал.
То есть это был сознательно применённый примитивный демагогический приём. В расчёте на что? Что я его не замечу?
То есть от качественных показателей (написание писем и планирование) вы все-таки решили перейти к количественному (цена ошибки)?
У вас слабость к примитивным демагогическим приёмам. Теперь вы вашу собственную фразу про «набирать письма» пытаетесь приписать мне.
Но нет. Мне просто всегда интересно посмотреть, как низко люди готовы ценить работу, которой сами никогда не занимались.
То есть это был сознательно применённый примитивный демагогический приём. В расчёте на что? Что я его не замечу?
То есть пример, показывающий схожесть работы, для вас "демагогический приём"? А как тогда с вами общаться?
У вас слабость к примитивным демагогическим приёмам. Теперь вы вашу собственную фразу про «набирать письма» пытаетесь приписать мне.
Если вы согласовываете не посредством писем, а как-то еще, почему не написали сразу? Ну и если вам не нравятся письма, давайте я перефразирую в "набирать в мессенджере", "звонить по телефону", "сообщать при личной встрече" или как хотите. На то, что вы пытаетесь сменить показатели это никак не повлияет.
@olartamonov, знаете, судя по вашим высказываниям, вы совершенно не имеете навыков к диалогу.
Софт скиллы ужасны, понимание процессов ужасны. Даже не пытаетесь вникнуть в точку зрения собеседников.
И вы еще что-то рассказываете что "выстраивать работу" это сложная задача? Ну для токсичного менеджера наверное сложная. Для менеджера, который не способен оторваться от своих предпочтений и объективно идти к диалогу - тоже сложно.
Осталось только выяснить, зачем такой строгий отбор в программисты нужен.
Простите, а где отбирают в программисты? Куда в очередь встать?
Не удрежался)
(глядя на утыканный как ёлка шариками unsafe'ами код на Rust) А безопасность и производительность, конечно, именно языком программирования и определяются. Ничем другим.
В значительной степени да, вы ведь не думаете что ваш пример с раст опровергает этот тезис?)
Постоянно — это сколько десятков решений за рабочий день? Перечислите первые двадцать влияющих на безопасность решений, которые вы приняли сегодня.
Сколько из этой сотни имеют уровень выше «не выходить за границы массива в цикле от 0 до N»?
То есть, в день вы принимаете десятки нетривиальных решений, каждое из которых непосредственно влияет на безопасность кода.
То есть, если допустить, что из этих решений правильны 95 %, то за два дня у вас в программе накапливается 50*0,05 = 2-3 ошибки, непосредственно влияющих на безопасность.
То есть, за время разработки программы (месяцы как минимум) таких ошибок накопится более сотни.
То есть, у программиста, имеющего качество принятия решений ниже вашего — а мы знаем, что качество принятия решений между людьми различается радикально — таких ошибок в программе будут сотни.
И все они непосредственно влияют на безопасность?
И где же тогда эти программы, на которые открыты сотни CVE?
А почему Вы всё время вопросом на вопрос отвечаете? Ответьте же наконец - чего такого менеджеры "творят"?
Вас послушать так можно подумать что менеджер двадцать критически важных решений в день принимает. Двадцать решений - да. Критических? Обычно нет. Иначе по вашей же логике при 95% удачных решений остальные 5% топили бы компанию.
То-то Яндекс везде, где нужна производительность, перешел на C++. Ну и сидели бы дальше на Java, в чем проблема?
Потому что в 99,9 % случаев это абсолютно несущественные детали, в которых замена одного решения на другое не влияет ни на что значимое
Сразу видно, сложнее hello world вы ничего не писали. Это влияет на читаемость и поддерживааемость кода. И следовательно на ттм и деньги, так понятнее?
Господи, да даже замена языка программирования целиком в большинстве задач ни на что видимым невооружённым глазом образом не влияет.
Язык это инструмент, и его выбор влияет опять же на скорость разработки и нефункциональные требования типа потребление ресурсов, время ответа и т.д. что в конечном итоге может вылиться в деньги, а иногда большие когда поймется что инструмент был выбран неверный.
Это влияет на читаемость и поддерживааемость кода. И следовательно на ттм и деньги, так понятнее?
А еще это может повлиять на все - скорость выполнения, потребление ресурсов...
Не так давно был случай - требовался некий кеш данных. И вот напрашиватеся туда один тип контейнера. Очень удобный в работе, использование его компактно по коду, читаемо.
Но прогон через PEX (Performance EXplorer) на нагрузочном тестировании вызвал некоторые подозрения по поводу его эффективности в данном конкретном случае. Взял другой тип контейнера. Не так удобно в работе, чуть хуже читаемость, но... Прогон через PEX показал увеличение эффектвности на 20%.
Или вот прямо сейчас в работе задача.
У нас некий специализированный язык где можно непосредственно в код вставлять SQL А можно напрямую читать из БД (позиционируемся по индексу, читаем запись из таблицы).
Обычно стараемся так - большие по объему выборки по нескольким таблицам со сложными условиям делать на SQL, что попроще (небольшие объемы, одна-две-три таблицы...) - прямым чтением.
И вот ситуация - делается некоторая выборка (сложная), для некоторых ее элементов нужно делать дополнительную выборку внутри основной.
Основная, понятно, что на SQL. А внутренняя... Сделал на SQL - работает 50 секунд (в целом хорошо, всех устраивает). Для интереса переделал внутреннюю выборку на прямое чтение. И получилось 20 секунд общее время работы.
А вы говорите "не влияет"...
Но такие вещи интуитивно приходят только с опытом...
Язык это инструмент, и его выбор влияет опять же на скорость разработки и нефункциональные требования типа потребление ресурсов, время ответа и т.д. что в конечном итоге может вылиться в деньги, а иногда большие когда поймется что инструмент был выбран неверный.
Более того, есть специализированные языки для решения конкретного класса задач, которые радикально упрощают работу.
Вот как раз с таким работаю. Мало того, что с БД работать просто и удобно, так еще и язык поддерживает все типы данных из БД нативно. Т.е. всякие типы с фиксированной точкой (decimal, numeric, date, time...). Т.е. описал структуру записи, прочитал туда запись из БД и работай с полями структуры... Не надо никаких "классов-оберток" для типов, которых нет в языке (ну вот нет в С++ ни decimal, ни numeric, ни date, ни time на уровне языка - только через классы новые, а это время на создание объекта каждый раз...)
Так что влияет и еще как влияет...
Некоторые вон до сих пор пишут на старом инструменте, а потом автоматически его в c++ переводят. Неужели потому, что "выбор языка практически ни на что не влияет"?
Задачи бывают разные. Почему именно месяц, а не день и не год? Про перефразирование за миллионы рублей - Вы правда считаете, что такое в любой организации с программистами в штате на каждом шагу встречается?
сами ничего не создают
их задачей является реализация данного им (составленного и согласованного мной :) ТЗ
Я правильно понимаю, что на самом-то деле, творец — это вы, писатель ТЗ?
Программисты же в большинстве своём сами ничего не создают, у них просто нет простора для реального творчества — их задачей является реализация данного им (составленного и согласованного мной :) ТЗ на разработку.
По личному опыту. Есть два виде ТЗ
Требующие вдумчивой работы и хорошей квалификации разработчика, где описан вход, выход и граничные условия. Остальное разработчик уже реализует по своему усмотрению. И, тем самым, создает некий продукт. Создавая и решая (потенциально) по дороге дополнительные задачи, необходимые для наиболее эффективной реализации основной.
Прописанные до "псевдокода". Самый тяжелый случай. Наихудший результат. Потому что у постановщика нет ни необходимого опыта в разработке, ни глубокого понимания тонкостей работы платформы и инструментария. Чтобы все это было он сам должен быть постоянно практикующим разработчиком достаточно высокого уровня (по сути, а не по наличию каких-то там лычек местного разлива).
Какие ТЗ пишете Вы?
Если первые, то разработчик таки создает. Конкретное решение, наилучшим образом удовлетворяющее поставленным условиям. Более того, разные разработчики могут одну и ту же задачу решить разными способами, используя разные подходы.
Если вторые, то Вы или сами квалифицированный разработчик, но тогда все ваши утверждения более чем странны, или же, написанное по Вашим ТЗ - плохой и неэффективный код, который просто не пройдет нормального нагрузочного тестирования.
Естественно, я не говорю о "формошлепстве" и леплении некоего типового продукта из типовых кирпичиков-фреймворков. Речь о бизнес-логике в достаточно нагруженных системах с жесткими требованиями по производительности эффективности использования ресурсов.
Не надо такие заявления делать: "Я творю и создаю", а "Вы исполняете". У тебя с софт скиллами проблемы - ты набросил на вентилятор и обидел разрабов тупо за счет формулировок (некорректно слова подобрал).
Аналогия: Архитектор, Бригадир, Бригада - кто построил дом?
Также и у тебя: Аналитик, Разработчики - кто создал систему?
А ответ простой. Вы ВМЕСТЕ создаете продукт, разработчик - не просто исполнитель. Он должен понимать какие проблемы и задачи решает продукт и каков должен выйти конечный результат. Обсуждать реализацию и давать свободу выбора этой реализации разработчику (с согласованием) - разгрузит тебя (ты не должен каждую мелочь продумывать в ТЗ) и поддержит доверительные отношения.
Хороший разработчик эффективно решает тарифную задачу для доступных ресурсов платформы - CPU time, memory usage. Менеджер видит программиста, "просто пишущего код".
Хороший менеджер управляет процессами, плохой менеджер управляет другими людбми.
Но и геморроя больше, потому некоторые все-таки отказываются.
Это вопрос квалификации. То, что для одного геморрой — для другого интересная задачка. С тем же успехом вы моггли сказать «у сеньора геморроя больше, поэтому многие миддлы от повышения отказываются».
Да нет, не отказываются, просто не доросли ещё.
И да, можно быть очень хорошим программистом, на очень высокой позиции, даже архитектором, но при этом не понимать и не ориентироваться в требованиях к задаче, выходящих за рамких чисто технических. Не такой уж редкий случай.
Это вопрос квалификации. То, что для одного геморрой — для другого интересная задачка.
Вопрос не столько квалификации, сколько интересов.
Я очень даже могу руководить группой людей (проверено на практике), т.е. квалификации хватает, но мне это совсем не интересно.
А геморрой - это не про интересные задачи, а про горы неприятной рутины, которые сопровождают эти интересные (не факт для конкретного человека) задачи, а у менеджеров этой рутины как правило на порядки больше, чем у простого программиста, будь он целый сеньор. Так что даже если эти задачи кому-то все-таки покажутся интересными, то цена, которую придется заплатить за возможность ими заняться, вполне может показаться ему непомерно высокой.
А геморрой - это не про интересные задачи, а про горы неприятной рутины
Написание программного кода является рутиной примерно в 100 % случаев. Вы его пишете на машине Тьюринга, в рамках конкретного языка программирования (нет, ввести в него новые конструкции вы не можете), даже алгоритмы, которые вы реализуете, примерно всегда разработаны не вами, вы в лучшем случае проводите их сравнительный анализ и иногда оптимизацию применительно к конкретной технической реализации.
У менеджера в силу более широкого спектра вопросов и меньшего количества ограничений как раз доля не-рутины в работе существенно (sic!) выше, чем у программиста».
Соответственно, ваше противопоставление — оно не про объективную разницу, а про «эта рутина мне приятна, а та — неприятна».
Можно я вам поклонюсь? Приобщусь к великой творческой менеджерской святыне, так сказать?
Расскажите лучше, что не рутинного вы сделали на позиции программиста за этот год.
Да куда мне :)
Влезу в разговор, хотя, наверное, поздновато )
Вот я сеньор дев, в менеджеры не рвусь. Правда, у меня есть сайд-проекты, где мне интересно что-то реализовывать для себя и немногих интересующихся. Там до черта интересного, и часто не рутинного.
А у менеджера все-таки (имхо) львиная доля времени - учитывать хотелки заказчика/бизнеса, и постоянно работать с переформулировками (которые, опять же, имхо, на содержание продукта не сильно влияют, чтобы там наверху не считали). Лично меня не привлекает; свободы самостоятельно выбирать интересные цели не хватает.
А вы работали программистом? Просто интересно, что недавно человек с завода примерно так же доказывал, что работать на производстве деталей намного важнее, чем писать какой-то там код. Со стороны выглядит именно так.
Насчет тз и написания кода - если вы делаете четкое тз, где все подробно расписываете что где и как сделать - то полноценный программист вам не нужен. Вам нужен человек, который переведет человеческий язык в машинный и все. Некоторые языки за пару недель можно выучить. Ничего сложного.
Вы рассуждаете о том, в чем, как мне кажется, не особо разбираетесь. Точно так же, как я бы начал рассуждать о бесполезности заводчанина, который только и делает, что болты да гайки клепает.
Многие программисты, как и я, приходят в профессию, чтобы что-то придумывать и создавать
До сих иногда пишу код (эмбеддед, C), не в рамках рабочих занятий. Рутинное, скучное, однообразное занятие.
Многие программисты, как и я, приходят в профессию, чтобы что-то придумывать и создавать
Что вы придумали и создали нового? Не стомиллионную комбинацию типовых алгоритмов, именуемую «программа», а нового, чего без вас бы не было?
Рутинное, скучное, однообразное занятие.
Ну значит вы не программируете, а просто код набираете
Что вы придумали и создали нового? Не стомиллионную комбинацию типовых алгоритмов, именуемую «программа», а нового, чего без вас бы не было?
Все что есть - было бы и без меня и без вас. Создавать что-то вовсе не значит делать то, что никто другой никогда бы не сделал. Но реализация будет такой, какой ее я придумал.
И нового делаю достаточно, чтобы радоваться работе и иметь желание к ней возвращаться ежедневно
Перефразирую вам ваш же вопрос:
Что вы придумали и создали нового? Не стомиллионную комбинацию типовых алгоритмов описаний, именуемую «программа» ТЗ, а нового, чего без вас бы не было?
Все что есть - было бы и без меня и без вас
Нет, это не так. У многих вещей в этом мире есть фамилия их создателя — даже, если брать область деятельности программистов, у многих алгоритмов.
Так вы пришли в профессию, чтобы создавать — и что вы создали?
Что вы придумали и создали нового?
Ничего. Но я и не приходил в эту профессию, чтобы создавать — если бы я хотел этого, я бы остался в науке, у меня была такая возможность.
Но по крайней мере у меня сложные многоплановые неалгоритмизируемые задачи, а не простынки алгоритмического кода, которые всё лучше и лучше пишет ИИ.
Но по крайней мере у меня сложные многоплановые неалгоритмизируемые задачи, а не простынки алгоритмического кода, которые всё лучше и лучше пишет ИИ.
А вы попробуйте всю информацию о задачах и людях не в голове держать, а выписать, как условия задачи. Я уверен, что ИИ с правильными решениями справится намного лучше, чем с написанием программы. Люди на самом деле прощают куда больше ошибок, чем программы.
Ох. Оххх. Охххххххххх. Программисты в гуманитарных проблемах — это каждый раз огонь, причём горящий с непременной уверенностью.
Попробуйте для начала простую, очень простую относительно реального мира задачу. Опишите персонажей и обстоятельства какого-нибудь художественного произведения так, чтобы по этому описанию ИИ вам сгенерировал его продолжение — и оно было бы не хуже оригинала.
Оцените объём и трудозатраты на это написание относительно объёма и трудозатрат на оригинальное произведение.
Добавьте к исходным условиям:
• вводные данные могут меняться в реальном времени, ваша реакция также должна следовать в реальном времени
• до личной встречи с персонажем вы не имеете информации о нём
• информации об окружающих персонажа обстоятельствах вы не имеете вообще
Когда решите — ну, в принципе, дверь к Сэму Альтману можете вышибать ногой, чтобы сообщить ему, сколько денег вы хотите.
Опишите персонажей и обстоятельства какого-нибудь художественного произведения так, чтобы по этому описанию ИИ вам сгенерировал его продолжение — и оно было бы не хуже оригинала.
Хм, самому стало интересно. Попросил написать небольшой рассказ в продолжение "Робинзон Крузо". Ну не знаю как получилось, не мне судить. Одна попытка генерации. Без "причесывания".
Получилось как-то так
Однажды вечером, когда солнце медленно садилось за горизонт, и кабинет Робинзона Крузо наполнялся приглушенным светом свечи, в дверь внезапно постучалось. Капитан Самюэль Аткинсон, старый друг и спутник многих морских приключений, вошел, снимая свою высокую шляпу.
"Робинзон, старина!" воскликнул капитан, их голоса слились в радостном хоре воспоминаний. Оба мужчины обнялись, словно вновь встречаясь после долгой разлуки.
"Самюэль, мой старый друг!" ответил Крузо, улыбаясь, "Ты как всегда вовремя. Заходи, присаживайся."
В тот вечер в комнате зазвучали старые морские рассказы, словно волны, несущие слушателей в прошлое. Серые глаза Крузо зажглись, когда речь зашла о его днях на диком острове, о построении убежища и выращивании плодов своего труда.
"А что сейчас, Робинзон?" спросил капитан, вглядываясь в карты, разбросанные по столу. "Каковы твои планы?"
Крузо взглянул в окно, где последние лучи солнца ласкали зеленые ветви деревьев. "Я хочу исследовать мир, помогать тем, кто нуждается. Но порой, мой друг, часть меня осталась на том острове."
"Но не забывай, Робинзон," сказал капитан с улыбкой, "ты сделал много для нас обоих. Ты научил меня верить в чудеса и силу человеческого духа."
И тут, словно ответ на внутренний вопрос Крузо, в дверь заглянул Пятница, ставший верным спутником после их встречи на острове. Он принес корзину с экзотическими фруктами, которые напомнили об их совместных буднях.
"Пятница!" воскликнул Крузо, с радостью встречая своего друга, "Ты всегда приносишь радость в наш дом."
Пятница улыбнулся в ответ, и в этот момент в комнате ощущалась невероятная связь между этими тремя друзьями. Капитан, Крузо и Пятница - каждый из них нес свой уникальный вклад в их общую историю, где встречи на диком острове стали лишь началом невероятных приключений.
"Мы создаем свою собственную историю, мой друг," сказал Крузо, прикоснувшись к фигурке из кокосовой скорлупы, которую он держал в руке, "и каждый из нас приносит свою неповторимую часть в этот бескрайний океан времени."
И так, в этот вечер, их рассказы остались в воздухе, словно морской бриз, несущий аромат приключений, дружбы и чудес, наполняя комнату светом воспоминаний о времени, когда они были за пределами цивилизации, но всегда вместе.
Мужик, читаю твои комментарии..прости за прямоту, но ты ооочень глуп :) Хватит себя закапывать, остановись.
Что вы придумали и создали нового?
Расскажите что вы создали нового, чтобы мы могли лучше понять каково это, творить а не использовать типовые конструкции, придуманные до нас)
Что вы придумали и создали нового? Не стомиллионную комбинацию типовых алгоритмов, именуемую «программа», а нового, чего без вас бы не было?
Заносчивая аргументация уровня демагога.
А что создал нового хотя бы один композитор? Вот прям нового, а не стомиллионную комбинацию типовых нот и ритмов?
А что создал нового хотя бы один художник? Вот прям нового, а не стомиллионную комбинацию цветов и штрихов?
А что созддал нового хотя бы один писатель? Вот прям нового, а не стомиллионную комбинацию букв и знаков препинания?
Программисты создают продукт. А код это просто кирпичики из которых он состоит.
А что создал нового хотя бы один композитор? Вот прям нового, а не стомиллионную комбинацию типовых нот и ритмов?
Композитор создал произведение, которое не создал бы другой композитор. Художник написал картину, которую не написал бы другой художник. И так далее.
Вы не сможете быстренько нанять другого композитора, художника или писателя, чтобы он вам создал то же самое. Его такого другого просто нет.
Что создаёт программист, что не может создать другой программист, нанятый через хедхантер примерно за те же деньги?
Вы не сможете быстренько нанять другого композитора, художника или писателя, чтобы он вам создал то же самое
А зачем мне создавать тоже самое, снова эта рутина?
Мне нужно не тоже самое, а то, что я хочу.
Например хочу простенькую мелодию на фон для игры. Чтобы не напрягала, чтобы была ритмичная, чтобы была воинственная. Сейчас с этим AI справится. Где же творчество, если даже AI может?
Это не рутина. Это уникальный стиль композитора (художника, писателя), за который вы его и цените.
Вы не будете слушать «простенькую мелодию на фон» ради самой музыки. Простенькая мелодия на фон — дешёвый низкокачественный продукт, который автор игры использует потому, что ничто более дорогое просто не сможет окупить.
Вы ждёте не любую музыку, а музыку любимых вами групп.
Точно так же вы не будете читать ChatGPT-сгенерированные книги (статьи про такие есть на Хабре, я не заметил в комментариях бурного восторга).
Вы ждёте не любую книгу, а книгу любимого вами писателя.
В какой из программ, которыми вы пользовались за последний месяц, вы видели уникальный стиль автора? Какие из пока не написанных программ этого автора вы с нетерпением ожидаете?
Вообще, вы зря защищаете такую великую ценность программирования. Программирование — это обычное ремесло, но в том нет ничего плохого, этот мир по большей части состоит из ремесленников.
Вот прям нового, а не стомиллионную комбинацию типовых нот и ритмов?
а ведь нот всего лишь 7... а атомов 129
Да каждый программист создает новое оттачивая то что есть смешивая, какие-то конструкции живут дольше какието развиваются и копируются
А Вы попробуйте что то сложнее ардуино и светодиода - сразу появится куча творческих задач. Разных, не повторяющихся!) К примеру на каком-то SoC поднимите ядро линуха на первом процессоре с драйверами, которые вы адаптировали и написали для вашего устройства, а на втором проце какую-нибудь РТОС. Организуйте коммуникацию между ними, разделение ресурсов. Напишите либы для обоих частей и не забудьте про ГУИ на Qt для тач дисплея - что бы сторонним разработчикам сразу и наглядно было видно как все работает. Оптимизируйте решение - вам ведь надо в риал тайм уложится с обоих сторон. Добавьте дебаг консоли для вывода всей информации с каждого проца. Составьте документацию описывающую ваш алгоритм, протоколы, разделение ресурсов. Опишите какие хард аппаратными проблемами вы столкнулись и как это обошли - ибо продукт новый и что сам чип, что СДК полны ньюансов - нигде ранее не описанных. И это будет все будет лишь одна единственная задача из проекта) Заскучаете - пишите, я Вам позавидую)
Да можно проще - вам дают задачу на... Ну что-то там в БД проверить - есть совпадения, нет совпадений. Вы радостно пишете SQL запрос, а вам говорят - "родной, твой запрос на проме работает 3 секунды (там реально сложно все - данных много, не самая удачная реализация БД...), а у нас требования чтобы укладывалось не более чем в 300мсек (дальше уже сервис, который ждет результата, отваливается по таймауту".
И вот начинаешь ежиков рожать... В результате получаешь 150-200мсек :-) Но это же подумать надо, придумать как...
Да и сАрдуино творчества может быть дофига и больше. Например, входной сигнал надо проинтегрировать, а ресурсов слабенького микроконтроллера не хватает. Что делать? Задача в лоб не решается. И надо искать нетривиальные решения - например вынести интегрирование из программной части в аналоговую - поставить на входе АЦП аналоговый интегратор на операционном усилителе.
работать на производстве деталей намного важнее, чем писать какой-то там код
Он вручную детали на станке вытачивает, интересно? Или таки нажимает кнопку "Старт" на ЧПУ? И при этом не знает, что внутри программа работает? :-)
Я вот бегло пролистал Ваши аргументы и заминусованные комментарии. И понял следующее: Вы просто менеджер (это не плохо) и видите красоту созидания в Вашей сфере. Просто поверьте на слово, у программистов даже при наличии ТЗ есть определённая свобода, в рамках которой у них тоже получается созидать и видеть красоту результатов своей работы.
И если бы всё было настолько рутинно в работе программистов, то нейросети давно бы их заменили, т.к., рутина - это их конёк.
UPD: Но да, на embedded-разработке это сложнее ощутить, конечно. Я про радость в условиях современных меняющихся требований в процессе разработки.
Написание программного кода является рутиной примерно в 100 % случаев. Вы его пишете на машине Тьюринга, в рамках конкретного языка программирования (нет, ввести в него новые конструкции вы не можете), даже алгоритмы, которые вы реализуете, примерно всегда разработаны не вами, вы в лучшем случае проводите их сравнительный анализ и иногда оптимизацию применительно к конкретной технической реализации.
Тогда в вашем наборе терминов я не программист (зотя я сам и все вокруг думают иначе). Особенно про алгоритмы повеселило.
А художник по вашему не творит (рисует на одном и том же холсте одними и теми же красками одни и те же вещи, рожи заказчиков, например). И чего потом его мазню в музеях выставляют и творчеством называют?
Соответственно, ваше противопоставление — оно не про объективную разницу, а про «эта рутина мне приятна, а та — неприятна».
Мне любая рутина неприятна. А у менеджера ее реально объективно больше.
Мне любая рутина неприятна.
Так и что не рутинного вы написали за этот год?
Тогда в вашем наборе терминов я не программист
Программист — техническая профессия, ей в ПТУ учат.
Программист — техническая профессия, ей в ПТУ учат.
Программист - это слишком широкое понятие. Кого только программистами не называли. Даже тех, кто просто вбивает чужую программу в ЭВМ.
В одной из систем определений те, кого "учат в ПТУ", это вообще не программисты, а всего лишь "кодеры". Программисты - это уже более широкий спектр обязанностей.
Хотя все это уже крайности.
ФГОС 09.02.03 «Программирование в компьютерных системах» процентов девяносто «спектра обязанностей» описывает.
Если опираться на всю эту бюракратию, то я точно не программист. По образованию математик (хотя специализация, каюсь, - таки системное пронраммирование, но в качестве квалификации в дипломе значится именно математик), работаю инженером (просто инженером, без расшифровки, в смысле не инженером-программистом, не инженером-технологом, какие там еще инженеры бывают). Но работа моя заключается именно в создании программ для ЭВМ (компьютеров).
Я даже ПТУ не закончил. Я даже не кодер получается? Так, обезьяна перед компом?))
Ну зачем сразу так грубо. Просто есть разные системы классификации.
В одной из систем определений, опирающейся на образование для классификации, вы не программист и не кодер.
Лучший программист, которого я лично знал, тоже не имел профильного образования. И в другой системе определений он вполне является программистом.
А вот мне тут в обсуждении уже разъяснили, что я совсем не программист.
Ну в таком случае менеджерам даже пту не нужно, они из кассиров вырастают) у вас нерепрезентативная выборка
Ок, что именно из computer science требуется в работе типовому программисту?
я не знаю что такое типовой программист в вашем понимании (хотя если судить по той вилке зп, про которую вы писали ниже - это что-то не очень квалифицированное). Если хотите могу ответить про себя, но пример опять будет нерепрезентативным. Если вы действительно хотите до кого-то здесь донести свое мнение, то будет намного более продуктивным ответить на те вопросы которые я вам задал выше - описать творческую составляющую своей работы. п.с. если что, я против менеджеров ничего не имею, а хороших и вовсе люблю)
Откройте вакансии, посмотрите, кого там много, расскажите, какими разделами computer science они пользуются. Ну, например, про то, какой процент программистов разрабатывает криптографические алгоритмы (это CS), а не просто подключает готовую библиотечку (это ФГОС).
А то некрасиво получается: вы утверждаете, что профессия программиста не описывается ФГОСом, но обосновать это отказываетесь.
Про разработку криптографических алгоритмов особенно повеселило, учитывая, что не разрабатывать свои алгоритмы (и даже не использовать свои реализации существующих алгоритмов) – это первое, что вдалбливают в курсе криптографии :)
Это не курс криптографии, это курс программирования. На курсе криптографии учат их разрабатывать (внезапно, вы не поверите, в мире ежемесячно появляется много новых работ по криптографическим алгоритмам, в том числе и новым, из чего можно сделать, что кто-то их таки разарабывает).
А программист действительно разрабатывать криптографические протоколы не должен, у него для этого квалификация недостаточна.
А программист действительно разрабатывать криптографические протоколы не должен, у него для этого квалификация недостаточна.
Все проще. Для разработки криптопротокола нужна соответствующая квалификация. А обладает ли этой квалификацией программист или кто еще - дело десятое.
Сколько курсов криптографии вы прослушали?) Я – несколько. Там действительно учат тому, как алгоритмы составляются, как они работают. Каким требованиям должен удовлетворять криптографический алгоритм и т.д. Но только при этом на каждом занятии долбят, что надо использовать готовые реализации и не заниматься самодеятельностью. И, в целом, понимаешь, почему, когда тебе рассказывают про векторы атаки в духе анализа энергопотребления блока питания :)
А, я понял) На самом деле криптографические алгоритмы создаёт криптографический менеджер :)
Ну кто-то должен разрабатывать новые криптоалгоритмы и их реализации. Другой вопрос, что это не "на коленке склепать", а требует определенных знаний, определенного уровня квалификации и выполнения некоторого набора правил (вроде обязательной проверки алгоритма и реализации на вшивость другими специалистами).
ВУЗы, где преподают дисциплины, связанные с программированием, не нужны? Ну, раз в ПТУ уже всему учат.
А вот закон приравнивает программу к литературному произведению, т.е. однозначно трактует программу как творческое произведение.
Числа вроде 99% и 100% слишком жёсткие приводишь, не так уж мало не программистов и уж тем более программистов которые способны и во флешке чё-то подпаять и ОС себе ребилднуть (приветь *NIX)
Глупости, дело навыков знания и кругозора, софт скилов. Работа менеджера такая же рутина, одни и теже паттерны. Особенно после лет 5 работы с людьми. А после 14 лет такой круговерти, работы с людьми, сложными ситуациями, уже не хочется ни подстраиваться, ни придумывать. Все одно и тоже. Людей считываешь за 5 минут разговора. Не интересно.
там дай бог 10% прибавки дают, а геморроя на все 200%. особенно в текущих реалиях рынка, который я отсмотрел за 4 месяца поиска работы. часто на лида сваливается еще и работа проджекта и аналитика а иногда и продакта на пол-шишечки. в целом работа интереснее, но спустя 3+ года я понял что лучше получать чуть меньше а оставшееся время и нервы потратить на свой проект.
p.s. работодателю эта должность беспорна очень выгодна.
А вы уверены, что это «там дай бог», а не что ваш уровень квалификации в этом качестве таков, что больше 10 % он не стоит?..
Мне вот почему-то не приходится работать ни проджектом, ни аналитиком, ни продактом. И вакансии, где от меня ещё и на баяне немного играть требуется, дальше этого требования не читаю.
Проблема в том, что в описании вакансии всего этого может не быть, но когда уже впряжешься, незаметно навалят дополнительных задач, и окажешься обвешан ими как новогодняя елка игрушками.
Впрочем, это и у простого программиста достаточно часто бывает, не только у лида, да и бежать оттуда надо. Но это совсем другая история (могут быть серьезные причины, заставляющие смириться, но это еще более другая история).
Учитесь говорить слово «нет».
Слово-то завсегда брякнуть можно. Просто нужно понимать последствия этого. А они могут быть намного хуже, чем если не сказать.
Вы откажетесь выполнять работу, не предусмотренную вашими должностными обязанностями, работодатель начнёт угрожать вам увольнением по его инициативе, вы укажете на незаконность такого увольнения и ваше последующее обращение в суд, в итоге сойдётесь на устраивающем обе стороны размере парашюта и увольнении по соглашению сторон.
Что тут может быть хуже? Вас к батарее отопления в офисе прикуют?
Вот даже описанный вами геморрой с судом может оказаться хуже необходимлсти выполнять дополнительную работу. А этим возможные неприятности не исчерпываются. Конечно, если для вас судебная процедура ничего не стоит, или даже приносит удовольствие, это другой вопрос.
«Я свои права отстаивать не хочу, я хочу, чтобы другие магическим образом перестали их нарушать» — заведомо неработающая позиция.
Всегда есть цена вопроса и готовность ее платить. Есть баланс между затратами на борьбу за права (не всегда только денежными и временными) и ее положительными результатами.
Конечно, можно подавать в суд каждый раз, когда вас толкнут в транспорте (тоже ведь нарушенные права), но это будет совсем крайность. А так случаи бывают разные. В одних лучше (опять же, лучше для конкретного человека в конкретной ситуации) подать в суд, в других лучше потерпеть (причем иногда дождаться другой жизненной ситуации и таки подать в суд, но не всегда оно так). Жизнь, к сожалению не столь проста и однозначна, как хочется.
Есть, это факт.
Но называть «проблемой» то, что вам просто не карману — это инфантилизм. Ребёнок рыдает, если ему не достаётся игрушка. Взрослый человек или зарабатывает на игрушку, или живёт без неё — потому что понимает, что никто ему в ответ на рыдания игрушку не даст.
Впрочем, можно отнести эти жалобы к психотерапевтическому выговариванию.
Но называть «проблемой» то, что вам просто не карману — это инфантилизм.
Проблема - это не обязательно что-то страшное. В этом слове нет ничего запредельного. Это всего лишь нечто не устраивающее, которое хочется исправить.
Есть проблемы решапмые, есть нерешаемые, есть те, очевидные решения которых не устраивают или по каким-либо причинам недоступны.
Если ребенок из вашего примера не получил игрушку, для него это таки проблема (в отличие от окружающих, у них могут быть другие проблемы, косвенно связанные с этой) , которую он (сознательно или несознательно) может попытаться решить через плач. Может сработать и разрешить проблему, а может не сработать. Других рычагов воздействия у него нет. Но есть и альтернативное решение - отложить решение, а там либо оно само решится, либо будет еще момент поплакать, либо оно просто забудется и перестанет быть проблемой.
У взрослых, внезапно, все то же самое, только больше сознательности в выборе решений или отказа от решения.
И куда потом пойдете устраиваться с таким бэкграундом сутяжничества?
По мне всё намного проще: не сошлись с работодателем - мирно разбежались, и не компостируем друг другу мзг.
А вы уверены, что это «там дай бог», а не что ваш уровень квалификации в этом качестве таков, что больше 10 % он не стоит?
стандартная демагогия работодателя... а вы уверены что работодателю есть разница нанимать лида среднего уровня и высокого, если он сам порой не понимает разницы? либо он ее понимает но сознательно размазывает ответственность в принятии решений между несколькими людьми, чтобы как раз уменьшить вероятность ошибки и потому снизить критерии к управленцу.
да и будем честны, выхлоп от хорошего лида намного меньше выхлопа от хорошего CTO, потому что лид это дно менеджерской цепочки и его решения в масштабе компании слишком малы чтобы как-то сильно влиять.
И вакансии, где от меня ещё и на баяне немного играть требуется, дальше этого требования не читаю.
ну во-первых не все об этом с порога пишут. а во-вторых сейчас много кто это практикует, потому что это выгодно. почитайте например роадмап тимлида от авито. фактически весь бигтех сейчас так устроен: есть PO, команда и лид. да есть всякие дискавери треки, там есть аналитик но только бизнесовый. системную аналитику и архитектуру делает лид и команда. проджектов тоже нет. процессы лежат на лиде. вы думаете я почему ходил 4 месяца по рынку
стандартная демагогия работодателя...
Замечу, что о 10 % вы писали не на основании исследования рынка (где у типового программиста 200-300 тысяч сейчас оклад, у менеджера легко может быть и 500+), а на основании вашего личного опыта.
Ну то есть корректно это формулируется как «лично мне и в местах, где я работаю, больше 10 % надбавки не предлагают». Что может говорить не столько о рынке, сколько о вас и местах, где вы работаете.
ну во-первых не все об этом с порога пишут. а во-вторых сейчас много кто это практикует, потому что это выгодно
Увольняться пробовали? Я пробовал, мне понравилось, парашют достойный.
Я вижу вы поисследовали рынок и исправили свой пост. Мне есть что вам ответить.
Большинство компаний предпочитают растить менеджера технического изнутри а не брать снаружи. Поэтому вы никогда не поймёте на основании статистики - это просто разные бакеты из разных компаний. А я вот на основании своего опыта работы в нескольких компаниях могу сказать какие там надбавки, ибо вилки видел в рамках одной компании. Обычно лид получает +10%, что в масштабе 400к за сеньора выливается в 450 за Лида. И это нормально, потому что он не делает ничего уникального. Все ребята довольно скилловые и самостоятельные. Конечно если компания рога и копыта и там студенты по объявлению то разница может быть больше но это именно что исключение.
Обычно специалистов, совмещающих в себе эти наборы качеств, руководство со временем пытается двигать на всякие менеджерские должности, дабы человек мог и контролировать непосредственно технарей, разговаривать с ними на одном языке, отслеживать их прогресс, и отчитываться начальству, переводя всё уже им.
а оно мне нада?
по факту такие люди через пару лет оказываются у разбитого корыта - братаном топ-менеджеров/владельцев бизнеса ему не стать (практически) никогда, а навыки программирования на современном стеке за пару лет менеджерской работы довольно сильно протухают ...
Я не согласна, что харды и софты противоречат друг другу. Софты - это не обязательно про экстраверсию, это и про внимание к деталям, умение доносить мысль, работать в команде и т.д. К каждой вакансии нужны определенные навыки, и опытные HR это знают. Условно, если в команду не требуется экстраверт, то и на собеседовании мы не станем смотреть на уровень общительности
Вот интересно, а как вы оцениваете ну конкретно "внимание к деталям" ??? Опишите с примерами
Вопрос был не ко мне, но вставлю немного. Самое простое: допустим, дали программисту задание реализовать что-то, а потом оказывается, что он реализовал то, что сам придумал, а не то, что от него просили. Хорошо, если он на замечания реагирует нормально и переделает, как надо. Но даже в таком случае из-за невнимательности и нежелания вникать в детали он, как минимум, потратит лишнее время на разработку (которое, как известно, выливается в деньги).
Другой вариант: быстро накидал какой-то код, но покрыть тестами забыл или поленился. В результате потом баги вылавливаются в 10 раз дольше, чем он код писал. Или, например, не вник как следует в детали, и оказалось, что в коде предусмотрел не 100% покрытия случаев, которые нужно покрыть, а в разы меньше.
Чтобы не допускать таких ошибок, надо общаться, переспрашивать, уточнять детали и т.д. Code review тоже никто не отменял. Бывают компании, в которых без code review минимум парой других человек не разрешается коммитить изменение кода.
Я читал даже про такую вещь. Не совсем относится к soft skills, но к вниканию в детали точно. Не секрет, что на данном ресурсе определенная часть и писателей, и читателей не вникают в правила русского языка. Некоторые чуть ли не гордятся тем, что "у меня в школе тройка по русскому была, но мне это не мешает быть крутым программистом". Так вот, натыкался я когда-то на исповедь одного руководителя компании, в подчинении которого было много программистов (если правильно помню, сотни). В какой-то момент он стал замечать четкую тенденцию: те программисты, которые не допускали или почти не допускали ошибок в письменном русском языке, и код выдавали более тщательно продуманный, грамотно написанный и т.д. Те же, у кого было много ошибок в русском языке, и код выдавали в духе "и так сойдет".
Умение четко и, главное, понятно для других формулировать свои мысли - с этим вообще бывает сложно. Иногда приходится сталкиваюсь с тем, что взрослые люди с высшим образованием этого делать не умеют. Я в последние годы уже не удивляюсь тому, что в переписке приходится сокращать количество вопросов до одного, ответ на который "да" или "нет". Да и на такой вопрос иногда не всегда удается ответ получить. Все эти, казалось бы, мелочи, тормозят рабочий процесс, а иногда и серьезно его усложняют.
Вот и не очевидно, так ли уж однозначно хорош интроверт, которому утром начальник дает задание, а вечером тот выдает результат с одним словом "вот".
Поэтому, на вопрос "Как вы оцениваете внимание к деталям" мне тоже интересно было бы ответ увидеть.
да, мне интересно как это оценивает HR, за 10 минут, по телефону. А так-то конечно внимательность к деталям проявляется на проекте через пару-тройку месяцев работы, само собой
Тем более внимательность к деталям может быть нестабильной у нестабильного человека)...
Это сделать весьма просто. Покрытие тестами и подобное здесь не нужно. Достаточно дать простейшую задачку с противоречивым условием, например с какой-нибудь двусмысленной деталью. Опытный спец должен сразу на эту противоречивость указать.
Мои 5 копеек по поводу внимания к деталям. Любое задание, что вам дают кто-то написал и значит в первую очередь от вас будут ожидать такого исполнения, как ожидает тот конкретный человек или команда.
Внимание к деталям это часть работы определённого уровня и опыта. Когда вы в практически автономном режиме умеете в лёгкой беседе / переписке получить интересующие вас данные. Отложить и использовать по теме все возможные социальные сигналы дополнит при этом недостающую картину.
Работа 1:1 с шефом это самая сложная среда, если он конечно не на одной волне с тобой. Но из моих заметок и опыта могу сказать, что часто вокруг даже работы 1:1 в нормальной живой фирме, не удаленке, деталей часто дрстаточно.
допустим, дали программисту задание реализовать что-то, а потом оказывается, что он реализовал то, что сам придумал, а не то, что от него просили.
Оно ж и наоборот может быть. Сделал, что ровно то, что просили, а потом оказалось, что в постановке задачи была ошибка. Но он всё равно продолжил делать, потому что "Не моя ответственность" 😀
Классика с гугловского (кажется) собеседования же:
— Нарисуйте домик.
— (рисует)
— До свидания, вы нам не подходите: вы должны были уточнить, какой домик и для кого. Это должен был быть домик для слепого жирафа.
Никогда не понимал смысла таких вопросов на собеседовании, если компания занимается недвижимостью для слепых жирафов, и человеку говорят "Нарисуйте домик", нормальный работник нарисует домик для слепого жирафа.
А они хотят нанять человека, который соберет 20 митингов, где будет уточнять для слона нужен домик или для жирафа?
если компания занимается недвижимостью для слепых жирафов, и человеку говорят "Нарисуйте домик", нормальный работник нарисует домик для слепого жирафа.
Нет, нормальный уточнит задачу. Вторичка, первичка, ИЖС, котлован, арктическая ипотека, жилмассив в 34 этажа или клубное в три этажа, и прочее, и прочее.
А получив откровенно* неполную задачу, бежать быстрее делать первое пришедшее в голову — это трата рабочего времени и, соответственно, денег работодателя.
* — не ведём речь об условиях, явно выходящих за пределы компетенции программиста, типа законодательных ограничений. Но понимание существования множества разных непохожих друг на друга домов, а также факта, что заказчику обычно нужен не любой дом, у него должно быть, это общие знания.
Такие вопросы надо ПМам задавать, и опытный ПМ уже знает, что если в тикете написано: "нарисуй домик", разработчик нарисует так, как представляется ему наиболее правильным.
И если ПМ написал просто тикет: "нарисуй домик", такой тикет просто не должен пройти.
Если же в тикете будет написано: "Поскольку мы заметили, что в Арктике в последнее время недостаток домов для слепых жирафов, надо нарисовать домик
- жилмассив в 20 этажей
- возле дома маленький ледовый парк.". И вопросов ни у кого не будет, а все технические детали разработчик знает и сам
и опытный ПМ уже знает, что если в тикете написано: "нарисуй домик", разработчик нарисует так, как представляется ему наиболее правильным
Это плохой работник. Не спорю, таких среди программистов сильно больше половины, приходится работать с тем, что есть.
Хороший, если видит несколько вариантов решения задачи, которые не эквивалентны, подходит к ПМ и уточняет.
Но среди программистов таких меньшинство, факт.
Я бы сказал это не плохой работник, а джун. Джун прибегает постоянно с уточняющими вопросами, а более опытный человек делает сам в силу своей экспертизы.
Когда я даю задачу, особенно объемную, я хочу чтобы разработчик сам додумал все детали, проанализировал и выбрал наилучший вариант в силу своего опыта и экспертизы. А уточнять каждую деталь - это какой-то микроменеджмент
А какой вариант в случае домика наилучший — ИЖС, вторичка, первичка, 34-этажный или клубный?
Ответ обоснуйте.
Если написано 20этажный, будет 20 этажный. Если не написано, тикет на доработку. И опытный программист будет рисовать такой дом, который можно быстро расширить/изменить под новые правила
А какой вариант в случае домика наилучший — ИЖС, вторичка, первичка, 34-этажный или клубный?
Вы знаете, если не указано какой конкретно, то любой, который соответствует остальным требованиям.
А вообще мне кажется задание из категории "нарисуй домик" не имеет правильного ответа. Начнешь задавать кучу уточняющих вопросов, получишь отказ "кандидат безинициативный и не умеет принимать решений". А нарисуешь просто домик – "кандидат проявил излишнюю инициативность и не стал задавать вопросы". И как понять в какую именно "игру" сейчас "играет" рекрутер?
А что, ПМ знает? Как правило, двусмысленность тянется от заказчика через менеджера, на каждом этапе только увеличиваясь. А хороший инженер (каких мало) должен задаваться вопросом ЗАЧЕМ, то есть видеть, какую проблему решаем, и что является ее решением.
Если ПМ не знает, он идёт уточнять дальше по вертикали.
Это плохой работник. Не спорю, таких среди программистов сильно больше половины, приходится работать с тем, что есть.
Забавно: у вас с одной стороны задача менеджера - это сделать внятное ТЗ для программиста, а с другой - если программист неправильно понял ТЗ то это плохой программист ибо уточнение и составление правильного ТЗ - это задача программиста. Это простите взаимоисключающие вещи. Если Ваш программист получает неполное ТЗ которое он вынужден уточнять и от результатов уточнения критично зависит результат, то он занимается творчеством а его менеджер прохалявил.
Вдвойне забавно то что выше вы утверждали что программиста можно заменить без ущерба для результатов работы. В рамках подобного подхода плохих программистов вообще быть не должно - как вы сформулировали, у них отличается лишь скорость решения. Менеджер ж сформулирует ТЗ, остается только его реализовать. А как дошло до реалистичной проблемы - так сразу программисты поделились на "плохих" и "хороших", причем чсх "хорошие" это те которые за менеджера выполняют ту работу с которой он не справился.
Нет, нормальный уточнит задачу
Если в голове менеджера была мысль "нужно нарисовать домик для слепых жирафов", а он написал "нарисуй домик", а потом удивляется что получил домик не для слепых жирафов, то менеджер странный.
Нормальный менеджер должен в рамках своих компетенций в задаче указывать как минимум все ключевые моменты задачи.
Человек решающий задачу головой предполагает, что и задачу ставит человек, который пользуется головой. Если все переложить на голову решающего, то можно задавать бесконечно вопросы о цвете, форме, размере, материале дома и т.п.
это не я плохо сделал, это мне задачу неправильно поставили
у меня на компьютере всё работает
тут надо на другую библиотеку переходить
И ещё 998 типовых отмазок плохих программистов.
Если все переложить на голову решающего, то можно задавать бесконечно вопросы о цвете, форме, размере, материале дома и т.п.
Не можно, а нужно. Потому что если вы, не обладая компетенциями и информацией о выборе цвета, выбрали голубой, потому что он вам нравится, виноваты в этом будете вы и только вы.
И понимание границ своих компетенций является базовым навыком любого минимально грамотного работника в любой области.
Которым вы, например, не обладаете.
Пример: нужна синяя кнопка с тенями. Менеджер ставит задачу - сделать кнопку. Программист возвращается за уточнениями - какой текст, где расположить, нужны ли закругления, что делать при наведении, что делать при нажатии и т.п. Кнопка появляется, но теней нет. И виноват программист, потому что среди сотен вопросов не было вопроса о тенях. Тени ведь в рамках компетенций программиста, а он среди 10 тысяч других вопросов потерял вопрос о них. По такой логике абсолютно всегда виноватым окажется он.
А менеджеру и в голову не придет, что можно было просто указать в задаче, что нужны тени и не нужно было бы тратить часы на бессмысленные вопросы и нерешенную в итоге задачу.
Проверять чужие компетенции конечно классно, но в первую очередь лучше бы проверять свои?
Я руковожу несколькими разработчиками и многие из них плохо пишут код, но мне бы и в голову не пришло ставить задачу так, чтобы ко мне потом возвращались за уточнениями
Вы описываете программиста, который, занимаясь кнопками, явно не имеет понятия, что такое design guide, не имеет даже базовых навыков коммуникации и не умеет расставлять приоритеты, просто бессистемно засыпая окружающих вопросами.
Я не спорю, что это реалистичное описание, но вам самому не кажется, что оно крайне унизительное? Это же характеристика человека с IQ где-то ниже 100.
Мне кажется, что если IQ человека выше 100, то при постановке задачи рисования домика для слепых жирафов он напишет "нужно нарисовать домик для слепых жирафов", а не "нарисовать домик". Ну или укажет, что его IQ ниже 100, чтобы решающий задачу понял, что лучше уточнить для кого этот домик.
Я вас понимаю и во многом согласен, но в нерешенной задаче виноват не только программист
Задача рекрутера — не продемонстрировать программисту свой IQ, а оценить IQ этого программиста.
Если со стороны программиста начинается «это вы неправильно задачу поставили, а что, я вам десять тысяч вопросов задавать должен» — ок, замечательно, мы только что сильно сэкономили рабочее время рекрутера, всё собеседование не заняло и десяти минут.
И да, в реальной жизни и работе всегда будут встречаться нечётко/неполно поставленные задачи.
а потом удивляется что получил домик не для слепых жирафов, то менеджер странный.
Менеджер не странный, он просто хочет видеть рядом с собой тех, с кем будет понимание с полуслова и намека, т.е. то, что в английском описывается как to be on the same page. Потому как пинг-понг с вопросами/ответами реализацию и сдачу проекта приближает сильно медленнее, чем с теми, кто может действовать по первому варианту.
Менеджер очень странный, он точно работника ищет или жену (мужа)?
Видимо такие менеджеры потом и ругают тупых разработчиков, которые "не понимают очевидного". Люди телепатическими способностями не обладают, а в любой задаче бывает такая масса разных ньюансов, что шанс получения нужного результата, при задаче поставленной "с полуслова" стремиться к нулю. Как по мне, очевидно что ключевые требования должны быть описаны при постановке задачи, иначе это кто угодно, но не постановщик и не менеджер, и начерта нужен такой лишний элемент в цепочке между разработчиком и пользователем, если он не может и не хочет ставить задачи адекватно? Тогда проще разработчику самому с пользователем общаться и разбираться что ему нужно, без испорченного телефона в виде менеджера ожидающего "понимания с полуслова".
To be on the same page - это скорее, что мы с вами обладаем одинаковыми апдейтами по текущей ситуации, что мы статус задачи и предстоящие действия понимаем одинаково. Это необязательно достигается с полуслова.
А чтобы с полуслова - это same vibe какой-нибудь
нормальный уточнит задачу. Вторичка, первичка, ИЖС, котлован, арктическая ипотека, жилмассив в 34 этажа или клубное в три этажа, и прочее, и прочее.
... и в итоге, сведет все к показыванию унитаза при покупке туалетной бумаги: https://pikabu.ru/story/idet_muzhik_po_ulitse_smotrit_novyiy_magazin_day_dumaet_zaydu_91793
Примерно равновероятные варианты:
Второй:
— Нарисуйте домик.
— А какой именно домик и для кого?
— Вы нам не подходите, в реальных задачах будете больше переспрашивать, чем работать.
Третий:
— Нарисуйте домик.
— (уходит)
И это замечательно. Цель собеседования не чтобы наняли вот такого прекрасного программиста, а разобраться, подходят ли сотрудник с работодателем друг другу, и ранний выход очень хорошая стратегия. Рекрутер является первой точкой, когда работник с компанией пересекаются и непосредственно взаимодействуют, так что процесс найма - это еще и вывеска. Другое дело, когда найм по знакомству, на конкретный проект и в конкретную команду, тогда рекрутера вы скорее всего просто не встретите.
Классика с гугловского (кажется) собеседования
Если не путаю, то это из Спольски.
Спасибо за вопрос. Честно, не ожидала, что фраза "внимание к деталям" вызовет такую дискуссию)
Из примеров, что указывает на возможную рассеянность: опечатки в тексте и знаки препинания, возле которых стоят лишние пробелы. Например , так . Обычно такие маячки выявляются при просмотре резюме или в переписке, когда обсуждаем время для собеседования. На интервью обращаю внимание, насколько внимательно человек слушает. Например, запоминает ли имя, не повторяется в речи и не задает ли вопросы, на которые уже были ответы. Да, это мелочи. Но они уже сигнализируют о возможной невнимательности.
У меня как-то сам собой выработался стиль речи, где минимум прямых обращений по имени. Потому что я их сразу просто не могу запомнить. Уж лучше уделю максимум внимания содержанию беседы, а не зубрёжке про себя имени. Что же теперь, побить меня и уволить?
Из примеров, что указывает на возможную рассеянность: опечатки в тексте и знаки препинания, возле которых стоят лишние пробелы. Например , так .
Обычно такие маячки выявляются при просмотре резюме или в переписке, когда обсуждаем время для собеседования.
серьезно ?! Или это новый уровень троллинга ? Т.е. hr ставит условный минус, за лишний пробел перед запятой ? А если два пробела, то резюме сразу в мусор ?
А когда сама HR при этом допускает грамматические ошибки, то это другое ? Я, как кандидат, должен игнорировать подобное или тоже заносить в черный список hr/фирму ?
Человек утверждает, что он - программист, то есть, как минимум, знает синтаксис хотя бы одного языка программирования. А действительно ли он способен выучить синтаксис языка, если допускает очевидные ошибки при написании текста на языке, который учил с рождения? А если он не способен в синтаксис - как он будет решать хотя бы самую простую приближенную к реальности задачу?
Если программист допустит опечатку в синтаксисе языка программирования, программа не скомпилируется, пока он ее не исправит. И современные IDE с автозаполнением во время набора сильно упрощают жизнь. Даже если забыл какую-то часть синтаксиса - гугл под рукой.
А если он не способен в синтаксис - как он будет решать хотя бы самую простую приближенную к реальности задачу?
Слишком общее утверждение. Я-то как раз за то, чтобы писать правильно и грамотно. Но совсем прямой и очевидной связи между умением грамотно писать и умением решать задачи нет.
Понимаю, что есть IDE. Синтаксис, на мой взгляд, это не про умение писать без синтаксических ошибок, а про представление чего-то (текста/кода) как набора блоков, имеющих смысл, и оперирование этими смысловыми блоками. Человек, который пишет с ошибками, подходит к языку как если бы это была регулярная грамматика (применяет регулярные эвристики, например: "всегда ставить запятую перед "как"). И тут нужно дополнительно удостовериться, что он не потеряется в задаче, требующей контекстно-свободной грамматики.
Человек утверждает, что он - программист, то есть, как минимум, знает синтаксис хотя бы одного языка программирования. А действительно ли он способен выучить синтаксис языка, если допускает очевидные ошибки при написании текста на языке, который учил с рождения?
т.е. IDE c автокомплитом и вот это вот все - для слабаков, а программисты у вас пишут код на бумажке )))
Опечатки в тексте и отсутствие знаков препинания также говорят о том, что у человека возможно дисграфия. Что полностью нивелируется при написании кода благодаря линтерам, спеллчекерам и автоподстановкой.
Вот интересно, а как вы оцениваете ну конкретно "внимание к деталям" ??? Опишите с примерами
ну или как то так
Dr. Bob Niedorf : All right, I'll start the questions, and I'll be timing your responses, and we'll be recording. Any questions?
George Malley : What's your first name?
Dr. Bob Niedorf : Uh, my first name is Bob.
George Malley : Shoot, Bob.
Dr. Bob Niedorf : Answer as quickly as you can... how old is a person born in 1928?
George Malley : Man or a woman?
Dr. Bob Niedorf : Why?
George Malley : Specifics, Bob.
Dr. Bob Niedorf : Okay, one more time. How old is a MAN born in 1928?
George Malley : Still alive?
Dr. Bob Niedorf : If a man is born in 1928, and he's still alive, how old is he?
George Malley : What month?
Dr. Bob Niedorf : If a man was born October 3rd, 1928, and he's still alive, how old is he?
George Malley : What time?
Dr. Bob Niedorf : 10 o'clock... PM!
George Malley : Where?
Dr. Bob Niedorf : Anywhere!
George Malley : Well, let's get specific, Bob! I mean, if the guy's still alive, born in California, October 3rd, 1928, 10 PM, he's 67 years, 9 months, 22 days, 14 hours, and...
[takes Bob's hand to see his wristwatch]
George Malley : ... and 12 minutes. If he was born in New York, he's 3 hours older, now isn't he?
харды и софты противоречат друг другу
Ресурсы, пошедшие на одно - это ресурсы, не пошедшие на другое, так что для большинства людей это именно что противоречие.
Сейчас любая более менее крупная разработка идёт в команде, и не редко в кросс-функциональной. Постоянно нужно общаться с командой, обсуждать какие-то проблемы и их решения.
Уже давно прошло то время когда разработчики сидели молча в одиночку и сами с собой писали код (в боле менее крупных компаниях). Поэтому софты сейчас в каких-то вакансиях даже важнее чем харды. Потому харды намного легче подтянуть по ходу работы, чем научиться общаться и работать в команде, и при этом не быть токсиком
Математическое интервью на позицию типа IT manager - сколько компьютеров было, сколько принтеров, сколько человек, сколько серверов и ни одного вопроса по сути - только цифры. И, вообще, вопросы по сути обычно только с некоторыми представителями бизнеса.
Мне рассказывали про ситуацию в одной небольшой компании. Они пытались нанять людей с опытом C/C++. А до техлида доходили исключительно молодые кандидаты 185+ см ростом, странными причёсками и нулевыми знаниями по стеку. При этом сами кандидаты, как выяснилось, тоже не понимали, что идут именно на пром.автоматику.
Когда стали разбираться, обнаружили что эйчарки устроили Тиндер на рабочем месте, игнорируя стек вообще. А набирали людей просто исходя из личных симпатий.
Это достоверный случай от хороших знакомых, но не единственный подобный случай, который до меня дошёл.
Теперь интересно, по каким критериям отбирали эйчаров, что они смотрины на работе устраивали Оо
Ситуация, конечно, странная. Очень жаль, что ваши знакомы с ней столкнулись
Не странная, всё гуглится.
"Опытному рекрутеру достаточно 10 секунд, чтобы оценить вас по-достоинству." (орфография сохранена)
"Мне достаточно 20 секунд, чтобы всё сказать про него. По щелчку пальца буквально."
"Кандидат берет трубку сонным, ленивым или недовольным голосом говорит "Алло" и я сразу понимаю, что это не наш кандидат."
Мне тоже интересно по каким критериям компании набирают себе эйчаров.
Очевидно что эйчаров должен выбирать эйчар для эйчаров.
Не имею большой выборки, но по личному опыту все эти оценки софт скилов не имеют ничего общего с тем как человек приживется в команде.
Может они просто отбирали людей с хорошими софт-скиллами?
Ну надо же - не все разработчики могут проводить технические собеседования, зато hr могут.
Иногда меня называют хинкали-рекрутером
И что это значит? Нанимаете только в грузинские офисы?
Зачем вкидывать неизвестный аудитории термин и не раскрывать его?
Хинкали-рекрутёр - вкидывает неизвестный аудитории термин и не раскрывает его.
Ник дали мне айтишники в одном из тг-чатов. Мы в Outlines Tech вели зарубежные проекты, и мне срочно нужен был разработчик из стран СНГ. Я искала выходы на крутых ребят из Армении или Грузии. Зашла в отчасти профильный чат и спросила у IT-специалистов, где найти профи. Один из ребят в беседе расстроился, что я не ищу его профиль, и написал мне в ответ: "нервно бросается хинкалями".
Я поддержала шутку. А потом ребята нашли мой профиль в соцсети и узнали, что я занимаюсь кавказскими танцами. Так и дали прозвище "Хинкали-рекрутер".
Вот такая история
tldr: стереотипы про HR правдивы, но на то есть причины, хотите работу — делайте хорошо, а плохо не делайте. Вот ссылка на TG
Всего сейчас в компании открыто более 80 вакансий.
Смотрю в профиль "Численность 101–200 человек". В голову приходит три идеи:
1. Стремительный рост компании (со всеми его проблемами)
2. Большая текучка кадров
3. - Вы покупаете рыбов?
- Нет, только смотрим.
Все проще: часть специалистов подбираем для наших клиентов из банков из ТОП-5 страны и лидеров в ритейле и логистике.
По поводу текучки кадров: сейчас у нас показатель около 10%. Служба заботы помогает коллегам развиваться в IT бережно к себе и без выгорания.
Недавно ушел из подобной галеры покрупнее, тоже работает в основном с банками. Судя по тому, что я вижу, банки сейчас стремятся избавиться от расходов на аутстаф специалистов, на рынке есть кого пылесосить от уходящих компаний
Картинка
Вот пример одного их таких резюме. И как из текста понять уровень и крутость специалиста?
А можно подробнее, в чём конкретно проблема с этим текстом?
Человек 5 лет разрабатывал Android-приложения, проводил код-ревью и формировал задачи разработчикам своей и смежной команды. Значит, был как минимум Senior на том месте работы. Явно не джун, да и явно за рамками мидла.
На другом месте - Ведущий программист, т.е. опять же не джун.
Это по уровню. По крутости - даже не знаю, по какой методике её оценивать через текст и чего в нём не хватает.
"Всегда был самым лучшим в команде, на голову выше всех остальных, написал за неделю фичу, которую другие вдвоём за месяц не смогли домучать" ?
Ну, во-первых некрасиво поливать грязью прошлых коллег, а во-вторых - это может быть "слегка недействительно" и субъективно.
Перечислять конкретные реализованные фичи? Да там за 5 лет такой список будет, что он и сам от скуки до конца не сможет доскроллить, не то, что HR.
Привести пример? Это самое плохое. Напишешь про игры - HR посчитает что "этот человек только игрушки и умеет делать, а у нас тут сурьёзный ГазМясСтрой, нам такого не надо". Напишешь про приложение для ГазМясСтроя - подумают "не, у нас тут маркетплейс глэмпингов, это другое". При том, что код там один и тот же может быть.
Так в итоге, что ожидается дополнительно в этом тексте?
Да хоть банальное "сделал фичу А, использовал то и то, добился прироста скорости/увеличения прибыли на х%", и так 2-3 раза. Для лида можно добавить про работу с людьми, пусть это даже "провел онбоардинг новой команды для проекта В".
Отличный пример!
Спасибо за комментарий)
Из резюме понятно, что кандидат выполнял функции сеньора или даже тимлида. По мне, так не хватает только количества человек в команде.
Зачем вам описания фич, реализованных в системе, о которой вы ничего не знаете?
Как может быть увеличение прибыли релевантно способностям кандидата? Вы же не продажника ищете.
Объясните конкретнее, как вы будете использовать информацию из "отличного примера"?
А если ты за 5 лет сделал сотню таких фич, при этом по разным областям и с самым разным результатом?
Допустим, впишешь в резюме, что сделал оптимизации для 2-3 либ. HR посмотрит и скажет, что «мы с этими либами не работаем» и отправит резюме в корзину. А на самом деле, у тебя таких либ штук 30.
А вы уверены, что программист, от джуна до суперлида, должен знать как фича в приложении повлияла на прибыль?)
Меня каждый раз на ха-ха пробивает, потому что такое возможно только в очень немногих случаях.
Но нет, все хотят числа. Даже сраный поломойщик должен в резюме вписать во сколько раз увеличилась площадь вымытых полов и оттого выросло количество клиентов, иначе всё, плохое резюме...
Ну если мойщик полов и лид разработчик имеют одинаковое влияние на успехи компании...
А если серьезно, то с уровня сеньора полезно знать, для чего разрабатывается та или иная фича. На уровне стартапа вполне реально выяснить влияние на прибыльность, в энтерпрайзе, естественно, с этим определенные проблемы. Не знаешь прибыль - возможно где-то ускорил приложение/сервис, сэкономил ресурсы, в век облаков это может быть вполне ощутимая экономия для компании. Не было подобных задач - ну напиши хоть что-то в стиле "сделал то, результат такой", пусть это даже будет благодарность от клиента.
Такие моменты:
Часто влияние примерно одинаковое. Т.е. лиду просто спускают запрос на фичу сверху и варианта не делать или делать не так, как написано просто нет. Т.е. привалили ответственности - делитесь полномочиями, иначе плохо работает.
Чтобы переживать о прибыли, надо иметь с нее долю, а еще иметь понимание о курсе развития компании и ценности конкретной фичи в обороте и репутации. Это дело менеджеров, причем ближе к верхушке, а не околонизового техспециалиста.
В чем проблема с текстом? Отвечаю: из резюме непонятно, какие задачи программист решал, за какие процессы отвечал, какое приложение разрабатывал, какой стек в каком проекте использовал.
Я же ищу человека на конкретные задачи команды, поэтому мне важно понимать его опыт. Утрирую и приведу аналогию: вы же не выбираете машину, потому что в ней есть руль, четыре колеса с наномикропротектором, многоцилиндрический двигатель ультра3000 и много другой начинки. Вы наверняка смотрите на то, что эта начинка такого делает невероятного, отвечает ли она вашим задачам: разгоняется ли до 100км/ч, может ли ездить по бездорожью, а по ровному асфальту умеет или она для этого не предназначена. Так же и в найме: недостаточно назваться программистом и перечислить стеки.
Хороший пример, что можно написать в резюме, привел @sva89
Простите, что ворвусь в диалог.
вы же не выбираете машину, потому что в ней есть руль, четыре колеса с наномикропротектором, многоцилиндрический двигатель ультра3000 и много другой начинки
Менеджеры по продажам существуют для того, чтобы продавать машину. У них же можно узнать детали о машине. Я, как покупатель узнаю у других владельцев их мнение. Если переносить это в сторону рекрутинга, я как соискатель узнаю у HR детали о компании, у других сотрудников (если удаётся таких найти) мнение о компании, о работе в ней. Но почему это же не работает в другую сторону. HR нужно, чтобы всё было открыто. Как в налоговой. Я сразу должен раскрыть все свои документы. И в этом поведении вроде бы нет проблемы. Типа, это просто лень соискателя - детально не описать свой опыт. Я это понимаю. Только я не понимаю, почему тогда HR не читают этот опыт? Существует прямая рекомендация не засорять резюме. Максимально сокращать его, если оно больше двух страниц. А как тогда свой опыт описывать? То есть какие-то двойные стандарты. Ваш тезис из статьи
Кандидат должен говорить ровно то, что эйчары хотят услышать
Он не просто правда, а мега ультра жиза. Именно так и нужно действовать. Если переносить это в область резюме, получается я как соискатель должен попасть в выборку, в набор технологий по списку. Дожен для каждого конкретной вакансии переписывать резюме просто повторяя всё то, что написано в вакансии. То есть получается, что для меня HR это просто прослойка-отсев, которую нужно пройти. И потому приходится играть в игру «Угадай список триггеров сегодняшнего HR». А сами HR при этом вопросы не задают. Типа, зачем тратить время на кандидата, с «непонятным» резюме.
У меня лично подгарает с того, что я пробовал все возможные варианты. И описывал весь опыт в резюме. И сокращал его в один лист A4. Подстраивал под конкретные вакансии. Результат - полнейший рандом. Вообще нет никакой корреляции. То есть я на своём опыте, как мне кажется, подтвердил часть тезисов из статьи. И поэтому сейчас триггернулся.
если так рассуждать, то в чём смысл тех комментов к опыту, что есть на скрине?
должность - программист
обязанности - программировал программы.
если уж и рассматривать это с такой прямой позиции, то уж лучше не описывать обязанности вообще, чем описывать их так.
я уж не говорю про то, что грейд судить по стажу (не опыту!) работы это путь вникуда. тут ты сеньор, в трудовой у тебя написано, что ты старший инженер, а в другой компании ты и на мидла не тянешь. зато 5 лет опыта, инженер-программист.
Ну Вы совсем уж в крайности ушли. Понятное дело что необходимо описывать чем занимался. Но у разных HR мнения по объему сильно различаются - сложно найти середину.
я уж не говорю про то, что грейд судить по стажу (не опыту!) работы это путь вникуда
А грейд это вообще просто ярлык для самодовольствования и способ сдерживания прав/ответственности сотрудника руководством. Какой-либо ценности не несет.
Ценность несут завершенные проекты - их объем, количество и проработанные ошибки при работе.
Первая причина, почему рекрутеры не приглашают на интервью —
нерелевантный опыт. Кандидат не подходит по скиллам, проектам или у него
не такой серьезный стаж работы, чем компания ожидает.
Стереотипы, шаблонность, уравниловка. Вы ищете идеально подходящего кандидата по какому-то не обязательно идеальному описанию или того, кто будет работать?
Профессия требует постоянного обучения: мы читаем статьи и проходим
дорогие курсы. Тратим время и ресурсы, чтобы говорить с соискателями на
одном языке, понимать стеки. Если рекрутер этого не делает, то задает на
собеседовании глупые вопросы, ...
Не те курсы, видимо, проходите. Программирование серверов, сайтов и игр, в сущности своей, имеет сильно больше общего, чем различий.
Программирование из написания кода на каком-то языке состоит процентов на 15-20. С хорошими ТЗ и тестировщиками может процентов на 30-40. Всё остальное время - обсуждение задач, проектирование логики, обсуждение требований, тестирование, дебаггинг (он на всех языках одного класса (императивные, например) одинаковый. Мне, помнится, приходилось дебажить код на С++, когда я его ещё не знал (знал Java7), исправил исходный код, перекомпилировал и запустил в работу платформу, на которой в итоге работал с целевым ЯП (не C++)), описание багов, приоритезация задач (у кого побольше опыта), системный анализ (который уже не может делать аналитик из-за технических тонкостей), оптимизация алгоритмов/процессов (это вообще общеинженерный навык, не только айтишный), проведение экспериментов и продуктовых тестов (профиль нагрузки, latency, отказоустойчивость), написание первичной документации.
И даже писанина на каком-то языке или на какой-то платформе состоит не из знания перечня всех возможных функций и их аргументов на этой технологии, а из общего знания "что должно быть, как это должно работать, в теории". Любой опытный айтишник запросто сменит свою проф. область за месяц-полтора-два при должной мотивации.
Но HR рынок по-прежнему продолжают искать по принципу:
Первая причина, почему рекрутеры не приглашают на интервью —
нерелевантный опыт. Кандидат не подходит по скиллам, проектам или у него
не такой серьезный стаж работы, чем компания ожидает.
Стаж работы? За 1 год интенсивной R&D работы можно изучить раз в 10 больше, чем за 5 лет поддержки готового legacy кода. Неужели менеджеры в IT этого не понимают? Сомневаюсь.
Все люди разные. Некоторые способны программировать на технологиях, которые впервые в жизни видят, а некоторые с уже хорошо знакомыми технологиями чуть в сторону отойти не могут - "этим всегда DevOps/тестировщик/аналитик/архитектор занимался, я не знаю ничего оттуда".
Но "стаж", "опыт", "проекты"...
...недавно мы публиковали чек-лист, который помогает усилить резюме
Нет! Называйте вещи своими именами: это чеклист, который позволяет HR проще отсеивать тех, кто не подходит под ваши шаблоны. Для кандидатов такие рекомендации не помогают!
У меня есть два резюме: в одном я соблюдал все возможные рекомендации - более "образцового" резюме не найти. На 140+ моих откликов штук 70 молчаливых отказов, около 40 просто тупо игноров, штук 30 опросов от HR, технических собеседований штук 15. Офферов 3-4. Приглашений от HR штук 5 за 4+ месяцев поиска.
Во втором резюме указаны всё те же самые навыки, нет фото, нет описания деятельности в компании, нет описания моих достижений, нет даже ФИО. Это резюме нарушает все возможные рекомендации, кроме одной: указывать свои навыки, которыми я уже владею или способен быстро освоить. Какой результат? 7 приглашений от крупных работадателей за 2 дня. После созвонов (на которых я старался давать минимально возможную и максимально общую информацию, никакого упоминания негатива про кого бы то ни было, даже если его было очень много) технических собеседований из них назначено некоторое кол-во. Сам ещё ни разу не откликался этим резюме.
Так кому вы помогаете своими советами?
И тимлиды ещё "молодцы": отсекают по каждой шероховатости, не стремятся вычленить толковых, стараются найти идеально подходящего под свои шаблоны видения кандидатов (которое тоже не всегда идеально). Даже по тем знаниям, которые гуглятся за 1 минуту и после двух-трех употребление в использовании запоминаются на долгие годы.
Может эти статьи по найму лучше не самим усваивать, а стараться научить тимлидов нанимать?
За все технические интервью, действительно толковые собеседователи попадались 2 раза. Многие из остальных - опытные нёрды с дутым ЧСВ, либо следующие формальным принакам отбора, которые они составляли как? Методологию проверки знаний тимлиды вряд ли изучают - им же некогда, они же и работают, ещё и уровень кандидатов определять. Особенно, когда нужно вытягивать из кандидатов информацию (а из айтишников надо, коммуникабельных нечасто видел).
И вишенка на торте: тимлиды не учитывают человеческий фактор. Люди - существа эмоциональные и эмоциональное состояние сильно влияет на степень воспроизводства той или иной информации. А ещё частое напряжение памяти и формулирование новых мыслей - очень утомительно. В итоге из-за волнения и перенапряжения человек через 5-10 минут расклеивается, начинает путаться в терминологии, забывает что-то (хотя минут через 10 после завершения с лёгкостью это вспомнит), начинает плохо соображать и всё такое. В итоге может выглядеть (не являться) неопытным, хотя может быть как раз идеально подходящим на роль техлида или ведущего разработчика.
Недавно на технческом интервью через 15 минут после начала переволновался, встал в ступор, в голове пропали все мысли и не смог написать простой SQL запрос, хотя вот только что написал уже несколько не проще этого и полностью назвал алгоритм, как надо его составлять. В итоге тимлид отказал в найме. Через 5 минут после завершения собеса проверил озвученный мной алгоритм - он правильный.
Ещё: есть люди соображающие быстро, а есть, у кого мысли должны повариться и хороший ответ приходит сильно потом. Я из вторых. И в моменте сильно теряюсь, такая вот специфика организма. Из-за этого заваливал многие интервью только потому что не смог сказать синонимичное слово к уже озвученному, а тимлид ожидал услышать именно его.
Рынок IT найма сломан (если хоть когда-то был работающим). И как его чинить/выстраивать - пока непонятно.
Стереотипы, шаблонность, уравниловка. Вы ищете идеально подходящего
кандидата по какому-то не обязательно идеальному описанию или того, кто
будет работать?
Логика в отсеивании кандидатов по их опыту мне кажется достаточно логичным. Какой смысл собеседовать джуна с опытом в пару месяцев, когда в команду нужен разработчик api шлюза условно. И он ведь будет работать, но много ли от такой работы пользы?
Вы привели пример про "вам нужен костёр? Вам он не нужен, вот есть спички - тут тоже есть огонь" и я про это не писал - само собой опыт должен быть сопоставим с уровнем ответственности и компетенциями.
Но часто происходит "шашечки или ехать":
- мне нужен костёр, мне написали, что на костре можно разогреть еду.
- предлагаю вам газовую горелку, она безопаснее, сразу даёт тепло, сразу можно убрать огонь, если надо - одни плюсы!
- не, мне написали, что нужен костёр, притом на берёзовых поленьях. Про газовую горелку ничего не написано, поэтому "вы нам не подходите".
Хотя очевидно, что в этом примере нужна функция - разогреть еду. Тут и микроволновка могла подойти, и паровая баня и всё что угодно, выполняющее функцию.
Любой опытный Java программист, претендующий на программирование серверов на Go с описанием того, что он в экосистеме Go разбирается или может освоиться (в курсе из чего экосистема состоит), скорее всего понимает на что он идёт и, значит, нужно рассмотреть вариант дообучить его до нужной лёгкости владения инструментами экосистемы Go и провести техническое собеседование, а не послать его куда подальше, потому что "к сожалению, у вас недостаточно опыта программирования на Go, а менеджеру это очень нужно". И неважно, если этот разработчик очень хорош в программировании серверных микросервисов/модулей, особенно многопоточных и без гонки данных.
Гораздо ценнее разработчик, который на практике владеет методами предотвращения гонки данных в любых системах (в которых они теоретически возможны), чем разработчик, подходящий под описание "имеет опыт работы на Go не меньше двух лет". Но поди объясни это менеджеру или HR'ам...
Хах, похоже это появились последствия от общения с кадрами, которые впадали в ярость от эйчаров, которые путали Java с Javascript.
Сколько там этому мему лет, десять? Ну вот через пять-десять лет маятник может качнуться обратно.
Гораздо ценнее разработчик, который на практике владеет методами предотвращения гонки данных в любых системах (в которых они теоретически возможны), чем разработчик, подходящий под описание "имеет опыт работы на Go не меньше двух лет".
И у меня такая же проблема. Сменила стэк, ушла на гоу. Но тут отлупы - нет стажа на гоу. А по сути это не ревалентно. Джун нулевой или человек поменявший стэк, но работавший с базами и серверами., знающий методологии и умеющий работать в команде.
есть люди соображающие быстро, а есть, у кого мысли должны повариться и хороший ответ приходит сильно потом
Бывают задачи, для которых сиюминутная идея, как ее решить, оказывается плохой. Иногда лучше остановиться, подумать, "поварить" задачу в голове день-два, и потом окажется, что в голову приходит совершенно другой метод решения, который оказывается и лучше, и эффективнее. Вплоть до того, что оказывается, что надо решать не поставленную задачу, а совершенно другую, и при этом удается "убить несколько зайцев сразу".
А бывает что для эффективного решения одной задачи нужно еще параллельно поставить и решить пару-тройку сопутствующих "подзадачек".
Вот занимаемся оптимизацией одного бизнес-процесса. И приходим к тому, что очень многое упирается в одну таблицу, где хранится история изменения некоей бизнес-сущности. Проблема в том. что каждый раз приходится тратить время на то, чтобы получить актуальное (последнее в истории изменения) значение. А это время.
Возникает параллельная подзадача - создание и ведение витрины где нет исторических значений, только текущее актуальное.
А это создание таблицы-витрины с нужными индексами, скрипт ее первичного наполнения (чтобы сразу при внедрении поставки витрина заполнилась), изменения в логике модыля ведения основной таблицы (чтобы сразу вносились изменения и в витрину) и изменения логики работы ретривера (теперь он не ищет значение по основной таблице, но берет нужную запись из витрины).
И такие решения идут от разработчика и аналитика, но никак не от менеджера.
Где их находят, этих неадекватных "деочек-эйчаров"? Я вот уже сбился со счету в скольких собесах поучаствовал, ни разу не припоминаю проблем именно с ними. Неадекватов технарей - тех полно было, но эйчары-то.. Они ведь на твоей стороне, им выгодно тебя "пристроить", топить тебя им смысла нет никакого. Все что надо - не быть муд..м в общении, и все по большему счету.
иногда такие люди проецируют своё ЧСВ на кандидатов (чит. синдром вахтёра). и они не ищут лучших людей на эту позицию в этой команде и компании, а пытаются вершить судьбы людей. тут возьму, тут не возьму.
Я такое встречал обычно как раз у нашего брата разработчика. Все эти техинтервью, на котором часто бывает что спрашивающий начинает просто явно вы..делываться, самоутверждаясь перед коллегами - мол посмотрите какой я крутой спец и как я сейчас этого лошка уделаю. Иногда, бывало, опускал таких с небес на землю, но это как по мне даже особого морального удовольствия не доставляет, теперь чаще всего видя такое, просто прерываю собес и раскланиваюсь с участниками, пускай там лучше коллеге хорошего психолога найдут что-бы он проработал с ним эти проблемы, а не сублимировал на собеседованиях.
хит парад "результатов" общения c HR:
Даже в случае отказа мы вам обязательно перезвоним. За 20 лет только двое перезвонили, и в одном случае развернутый ответ почему отказали.
Назначается собес на конкретное время с оговоркой что будет присутствовать еще кто-либо для технических вопросов, а по факту какое-то скомканное мероприятие где не звучит ни один технический вопрос, но пытаются узнать чуть ли не все мои домашние пристрастия и увлечения.
Собеседование более 45 минут без озвучивания технических подробностей выполняемой работы на должности вакансии, как будто это какой-то секрет.
Психологические тестирования с "раскрашиванием квадратов".
Найти работу (особенно первую) -- это почти всегда рандом. Иногда на техническом задают вопросы, которые сходу не знаешь (это может быть термин, например), но ответ гуглится за 3 минуты и в теме легко разобраться. Наверное, так проверяют, насколько ты вообще в контексте. Но если 2 человека без опыта и оба готовились (гуглили) перед собесом -- повезет тому, кто нагуглил ответ именно на вопрос от тимлида.
Даже если компания работает над своими процессами (хотя тяжело оценить, насколько эта "работа" имеет импакт -- работать можно и вхолостую) заруинить найм может неадекватный руководитель (и такие на моей памяти встречались).
Даже если не понравился человек, это не влияет на итоги собеседования.
Да ладно, неужели??
Похоже, статью написал ГПТ4
при таком заголовке требую фотку в полный упомянутой девочки - автора данного материала. будем материал оценивать по фотке автора ;)
Статья от представителя профессии-паразита сквозит именно этим подходом - "вы все равно прогнетесь под нас!".
Мой опыт взаимодействия с рекрутерами.
HR не занимается собеседованием. Совсем. Только первичный отбор резюме и отправка их в команду. Команда уже решает кого собеседовать и отправляет выбранное HR. Тот организует встречу (время, место...), но сам не участвует. Собеседование проходит с командой - там уже сразу видно кто как дышит, нравится не нравится. Если команда решила брать - HR получает резюме кандидата и уже занимается всеми формальностями оформления (вплоть до "привести за ручку на рабочее место)".
И никаких вопросом по поводу "да HR вообще не понял какой я хороший кандидат потому что ничего в теме не понимает" не возникает. Каждый занимается делами в рамках своей компетенции. И HR не нужно думать - "а понравится ли команде как этот кандидат дышит". Это команда сама решит.
Софт скилы, на мой взгляд, сильно переоценены. Например, вспомните университетские годы, когда человек приходил на экзамен неподготовленным, и начинал с уверенным видом жонглировать терминами, в которых ничего не понимал. Зачастую даже успешно сдавал экзамен. Чем не софт скил? Очень нужный доя торговцев и юристов; технарям мог бы пригодиться на конференции, когда вопросом из зала ставят в тупик. Но вот беда, я обнаружил, что почти весь чужой код, с которым мне приходится работать, грешит тем же: его писали люди, не до конца разобравшиеся в задаче, и плохо владеющие нюансами технологии. Зато код написан так, что с первого взгляда кажется, что там написано что-то умное.
Так вот, рекрутеров легко проходят именно булшиттеры, которые понахватали с миру по нитке, но ни в чем серьезно не разбирающиеся. Глубоким же спецам часто хочется прекратить собеседование, когда кто-то начинает их щекотать за пятки для проверки софтскилов.
Лонгрид
Мне искренне жаль, если кто-то сталкивается с некомпетентными специалистами.
Как так получается?
Примем за факт, что HR не способен проводить техническое интервью. Даже на джуниора, так как там надо оценить потенциал и понять в какие сроки и что кандидат уже успел сделать за короткий период. Мидла и сеньора уже проще оценить по опыту.
Итого, кандидат в любом случае будет проходить техническое интервью с техническим специалистом.
Что остается для HR? Сверка резюме по базовым параметрам, политикам компании и определенным ключевым словам. Какая квалификация для этого нужна кроме банальной логики и умения читать? Ну аккуратность. Ну немного проактивности. Но это те софт-скиллы, в которых считается, что HR обязан разбираться, еще и коучить.
Итого, квалификация HR специалиста изначально предполагается ниже. Ведь компания не планирует повышать свои расходы на найм, а наоборот сокращать.
Из-за этого все и происходит. Далеко не каждая компания готова профессионально заняться наймом. Это дорого, это возможно в крупных компаниях. И для этого нужен профессионализм и желание выстроить крутой рекрутинг в руководстве, который должен чем-то покрываться. Чтобы искать лучших из лучших, компания должна предлагать нечто лучшее.
А если нет, то....
Много мы видим рекрутеров хотя бы 30+ ? КРАЙНЕ редко. Мало. В таком возрасте это либо недавно из декрета, без опыта работы, зачастую с забытыми знаниями из образования, и забитым мозгом из области ухода за детьми (а это огромный труд, который на несколько лет забивает все). Либо это уже старший специалист, начальник отдела, который лично интервью не проводит и резюме не перебирает.
Да, я хочу извиниться за резкие слова, я допускаю огромное количество исключений, но буду настаивать, что это по большей части исключения из большого правила.
Итого, в своем подавляющем большинстве HR специалист - это позиция на которую не предполагается брать высококвалифицированный персонал, который может и способен расти в технической части. Запомним это.
Многие руководители считают, что молодые и привлекательные девочки на рецепшене должны продолжаться и в рекрутинге, это же "лицо компании". Но это также приводит к тому, что квалификация страдает, а мотивация часто подменяется амбициями. Молодость также дает тот момент, что человек у которого не только не было семьи и детей, но и вдобавок длительных отношений (еще же только карьеру строить), имеет довольно своеобразные взгляды на жизненные ценности.
Итого софт-скиллы тут используются по методичке, а не на жизненном опыте.
И добью еще одним.
Какие полномочия есть у HR специалистов?
Они могут предложить немного другую позицию? Нет. А технический специалист и тимлид на собеседовании могут увидеть и спланировать немного другие обязанности, подходящие человеку на ходу.
Они могут предложить другую вилку ЗП или какие-то бонусы? Нет. Это делает менеджер проекта. Частично тимлид может поднять грейд специалиста и сказать менеджеру что этого человека нельзя упускать, давайте поднимем.
Они могут что-либо поменять в политике компании или проигнорировать требования сверху (например пришла разнарядка брать только с корочкой высшего образования)? Нет. Хотя менеджер проекта вполне может иметь такие полномочия и игнорировать общую политику компании в разовых случаях.
Зато они могут проигнорировать резюме, или продвинуть резюме знакомых. Или попросить кандидата переоформить. И в принципе все. Хороший специалист конечно может задать дополнительные вопросы, как в примере статьи заподозрить, что в резюме указано далеко не все. Но к найму это не привело =)
Итого, по разным объективным причинам, довольно сложно найти компанию, где рекрутинг поставлен на хорошую систему, и в рамках этой системы действительно нанимаются хорошие рекрутеры, которые затем ведут хорошую рекрутинговую деятельность.
А дополнительный прикол в том, что эта деятельность в своем большинстве не нужна на высоком уровне. Линкедин и другие подобные штуки вполне себе представляют удобный инструмент и для стандартизации шаблона CV и поиск по нему, чтобы пользоваться подобными ресурсами можно было без лишней квалификации, поэтому и вкладываться в рекрутинг, если это не ваша основная деятельность, или вы не компания с 10+ тысяч сотрудников, нет особого смысла.
Поэтому да. В среднем - HR специалист - весьма посредственный специалист, от которого зависит мало. А то, что среди них встречаются личности о которых возникают истории в инете - ну так про хорошие случаи мало кто пишет.
P.S. В своей жизни у меня не было интервью прямо таки с ужасным HR, но было интервью, когда недооценили, переоценили и отклонили по техническим вопросам. И если первый случай я по молодости лет так и оставил, то во втором случае, понаглел, поуточнял что не так и прошел дальше (и устроился на приятную позицию). Второй случай - это было мое достоинство софт-скиллов? Не думаю. Считаю, что это была недоработка HR специалиста.
Они могут предложить немного другую позицию? Нет.
Спорно. В том плане что "Скорее нет.", а не категоричное "Нет.". Объясню на личном (что да, не релевантно) примере:
Соискатель нашел на известном-двубуквенном-ресуресе вакансию A в компанию N и пошел на собеседование. Ну и завалил его.
О том что в компании N есть вакансии помимо A, кандидат мог и не знать - проглядел/разместили после отклика на A/etc. - не суть, главное что - есть новая позиция.
И вот грамотный hr, КМК(!), может по результату собеседования на позицию A понять, а вдруг кандидат бы подошел на позицию B и предложить этот вариант.
Конкретизируя - вот пришел кандитат собеседоваться как разработчик, но во время интервью говорит что "мне интересно, не только код писать, но и то что происходит после того как я нажал merge в gitlab'е" - тут то и время подсуетиться рекрутеру и проверить - а может быть есть позиция в команде SRE, которой кандидат бы подошел.
А в остальном лонгриде да, скорее соглашусь.
И вот грамотный hr, КМК(!), может по результату собеседования на позицию A понять, а вдруг кандидат бы подошел на позицию B и предложить этот вариант.
Обычно на техническом собеседовании HR не присутствует.
А насчет других вакансий - так просто берется резюме, и по нему предлагается сразу несколько позиций. Кандидат проходит по очереди интервью - авось куда возьмут. Такое бывает.
Я имел ввиду, что ищут, например, сеньора разработчика.
"Пришел кандидат, который не тянет на сеньора, но тянет на хорошего мидла, причем с опытом как раз там, где в проекте нужно. И тут тимлид с менеджером могут подумать - у нас в принципе есть хороший почти сеньор Вася, можно его просто продвинуть на сеньора, а этого взять мидлом. В среднем по бюджету останется одинаково, еще и небось сэкономим на Васе."
Мой опыт общения с рекрутёрами на 95% положительный. Всегда получал информация о вакансии, о компании, о процессе собеседования и т. п. Если вакансия описана очень, требования невнятные, то тоже на этапе разговора с HR все детали прояснялись. Cиндрома вахтёра не наблюдал ни разу. Зато дальше мог начаться тупняк в стиле, тимлид не пришёл, техлид что-то недопонял и т. п. Но тоже, по большому счёту, придраться не к чему.
К чему я веду. Вежливое и спокойное общение творит чудеса. Да, всегда есть шанс нарваться на неадекватного собеседника, но он не делает погоды.
Интересно узнать про ваш опыт взаимодействия с рекрутерами.
ИТ ведь не только разработка, не так ли?
Взаимодействуя с рекрутерами как кандидат, за 20 лет я ни разу не был на личном собеседовании с рекрутером.. так что шутка про "рубашка не понравилась" - мимо. Рекрутер читал мое резюме и договаривался ( по телефону или почте) о встрече (личной, а затем и в форме телеконференции) с представителем подразделения, осуществлявшего поиск кандидата.
Взаимодействуя с рекрутером с другой стороны, я формирую четкие критерии, что точно должно быть в резюме и чего там точно быть не должно. Рекрутер направляет мне найденные резюме, редко их бывает более десятка в неделю. Я выбираю заинтересовавшие меня и рекрутер организует нам встречу.
В одном и другом случае ни разу не сталкивался с какими то явно выраженными проблемами именно в работе рекрутера, видимо потому что я не ожидаю от них чудес.
Я один не понимаю, почему HR'ы почти каждый день приходят на Хабру оправдываться и говорить что "не все HR плохие"? Как какие-то астрологи. Вон тот астролог шарлотан, а я нормальный
Потому что если некоторые практики отбора кадров заменить на подбор по знаку зодиака, результат не особо изменится
А еще довольно часто такие статьи публикуют. Может, потому, что и те, и другие стабильно собирают много просмотров и комментариев?
С программистом из Костромы какая-то сказочная история. Для оытного эйчара я думаю дело 5 минут было бы выяснить при созвоне достаточно ли релевантен его опыт, чтобы хватать и на собес затаскивать. Кандидатов таких на рынке не так чтобы избыток, а оценить хардскиллы разработчика с 5+ годами опыта хотя бы на уровне "на миддла не тянет" неразработчик все равно адекватно не сможет. Зачем было человеку в душу влезать настолько, что он побежал резюме переписывать и рынок мониторить не очень понятно, хотя и выглядит очень благородно:)
Чтобы понимать масштабы: наши IT-рекрутеры берут в работу по 500-800 CV в неделю каждый.
А также рекрутеры/HRы говорят что им надо такое резюме, чтение которого занимает максимум 5 секунд, и чтобы сразу зацепило... Допустим, у вас 1000 резюме, тогда работа по оценке займет 5000 секунд или 1 час 25 минут ... в неделю :)
...некоторые кандидаты описывают свой опыт одной строчкой.
Так вам 5 секунд или ехать?
HR не должен проводить оценку квалификации кандидата. работа HR определить базовую совместимость и пригодность. т.е. владение языком, умение общаться, ожидаемое вознаграждение, мотивация, переезд и т.п. Дальше кандидат отправляется к Hiring Manager, который либо сам либо через опытных сотрудников принимает решение. Сегодня HR системы типа Workday дают возможность Hiring Manager-у непосредственно мониторить пул кандидатов, как только они нажмут кнопочку "Apply" для позиции.
Задача кадровика оценить адекватность и оформить сотрудника. Выбирать резюме и оценивать компетентность должен специалист. Не понимаю почему делегируют обязанности с которыми не справятся.
Хороших эйчаров реально мало и тут дело даже не в понимании отдельных отраслевых скиллов и в частности в ИТ.
Нанимающие менеджеры часто не шарят в том, что они делают.
У компаний почти всегда нет профиля должности или вакансии.
Если руководитель уделяет мало внимания найму, никакой эйчар не вытащит свою работу.
У большинства компаний много мусора в голове или нелепых требований.
Найм - это сложный навык, который низвели до рутины с первым контактом на некомпетентном стажёре или вообще программе для скоринга резюме.
Толку от всех этих статей никакого, потому что приходят новые люди и повторяют всё те же прошлые ошибки.
О чём вообще статья понять не могу. Прохождение собеседований это лотерея - иногда цирк с конями, иногда невероятно адекватное общение, что даже самому кажется, что я не туда пришёл. То есть, знать о том, как оно будет практически не возможно. И статья не объясняет проблем, и не приводит примеров решения этих проблем. Покекать с HR можно просто сходив на собеседование
Что-то какая то фигня вырисовывается, не могу понять смысл подобного найма специалистов. Как может неспециалист (HR) оценивать специалиста? По формальным критериям? Но это же будет бить мимо цели.
В итоге, вижу, на первое место выходит натасканность на ответы собеседований. Т.е. получается формализм против формализма. Клин клином вышибают, как говорится.
ЗЫ:
Сына готовлю к ОГЭ по информатике, затрагиваем и задачи из ЕГЭ. Вчера увидел в тесте ФИПИ задачку №18. Там дано поле N x N, где N <= 30. Во всех клетках лежат монеты, также есть произвольные стены. Робот выполняет команды: вниз и вправо. При посещении клеток монеты он собирает и накапливает. Вопрос: какое наибольшее/наименьшее количество денег может собрать робот, двигаясь из левой верхней клетки до тупика?
Задачка (если не знать решения) не такая уж и простая - лобовые школьные решения полным перебором не подходят (для максимального поля 30x30 - там факториальная сложность получается). В общем лобовой перебор путей отпал, рекурсия (красивая из пяти строк) тоже отпала. Дальше решил вместо путей отталкиваться от накопленных сумм, выбирая очередной ход, основываясь на наибольшей (или наименьшей) сумме в клетках предыдущего шага... и тогда решение было найденно.
Мои мысли: подобную задачку не всякий спец смог бы сделать с нуля (заранее не зная подходящего способа) за очень ограниченное время в стрессовой ситуации - ведь на экзамене еще 20+ заданий надо решить. А вот если человека натаскали на решении именно этого задания, то любой натасканный школьник решит ее на питоне за 10-15 минут. Алгоритм то простой, но его еще надо найти, либо просто знать.
Прихожу к выводу, что все эти тесты/экзамены ориентированы исключительно на натасканность, на знание определенного набора решений. А умение анализировать и искать решения эти тесты не проверяют.
Дальше решил вместо путей отталкиваться от накопленных сумм, выбирая очередной ход, основываясь на наибольшей (или наименьшей) сумме в клетках предыдущего шага... и тогда решение было найдено.
То, что задача на "динамическое программирование" очевидно с самого начала, остается только придумать как этот метод применить. Сейчас пока сигарету на кухне курил как раз придумал :))
Справедливости ради, этот метод называется "динамическое программирование", и в моей картине мира это всё-таки ещё подходит под определение общей computer science эрудиции. Да, это уже ступень за быстрой сортировкой или там двоичным поиском, но всё-таки не специализированный алгоритм, который не зазорно не знать.
Да, это уже ступень за быстрой сортировкой или там двоичным поиском, но всё-таки не специализированный алгоритм, который не зазорно не знать.
Это всё понятно. Но я о том, что школьник, впервые увидевший эту задачу, не знающий заранее этот способ, наверняка не осилит эту задачу, особенно в рамках экзамена. Т.е. на первом месте стоит натасканность.
В моём понимании исходный смысл ЕГЭ был в том, чтобы обычный нормальный школьник не получал 100 баллов. То есть не натасканный и не должен решать эту задачу. Максимальный балл должны получать буквально доли процента по стране, а дальше уже вниз. То есть затея в том, чтобы суметь отранжировать всю публику, а не так что "освоил программу, получи 100 баллов", т.к. в этом случае будет непонятно, чем эти школьники отличаются друг от друга, хотя на практике один может знать в десять раз больше другого.
Ну так в текущих реалиях на 100 баллов скорее сдаст натасканный, чем умный.
Кстати, в этой задаче реально работающее решение нетривиальное. Да, его можно легко формально понять и применять. Школьнику это доступно. Но по хорошему счету, это решение еще надо доказать. Доказать, что перебираются абсолютно все возможные пути. А это уже сложнее. Но не требуется. Достаточно знать шаблон решения.
С учетом ограничения в возможных движениях у вниз и направо, минимальное будет 1 (это в ситуации, когда 2 стены заграждают какой либо путь) или 2N из-за механики движений, если дойдет до нижнего правого угла. (максимально он может сдвинуться N раз по вертикали и горизонтали.
Другой вопрос как реализовать алгоритм поиска максимально оптимального пути. Но это уже совершенно другая задача, т.к требуется другой ответ.
Кстати, при приёме на работу, демонстрация излишней квалификации и знаний тоже весьма вредна - не всякий начальник хочет иметь работника, который умнее, компетентен и более образован чем он ...
Еще есть хороший простой вопрос: "Что вокруг чего вращается - Солнце вокруг Земли или Земля вокруг Солнца?".
Если человек сходу без сомений отвечает: "Земля вокруг Солнца", то значит, человек мыслит штампами. Если нужен человек на шаблонную рутинную работу - это наверно будет подходящая кандидатура.
Если же человек сразу задает уточняющий вопрос: "Что принять за точку отсчета?" или "Что именно рассчитываем?". То это возможно хорошая кандидатура для разработки чего-то новенького или нетривиального.
для подвижной платформы вращения очага вокруг жаркого?
.. а может мир не вращается вокруг меня? (c) Эрик Картман, Южный парк
Вообще-то и Земля, и Солнце вращаются вокруг общего центра масс.
За начало координат мы можем произвольно взять любую точку. И необязательно рассматривать декартову систему. Это вопрос удобства и вопрос - что именно мы рассчитываем. Например, если я делаю солнечные часы, я за центр координат возьму точку на земле, куда воткну палку...
Вообще-то и Земля, и Солнце вращаются вокруг общего центра масс.
Зануда моде он.
* Вообще-то они еще и летят куда-то.
* Если брать терминологию "орбита", то Земля вращается вокруг солнца.
* Еще считается, что вращение вокруг общего центра масс это если этот центр масс не находится внутри одного из объектов. А то если задаваться деталями, то центр масс сам по себе может еще вращаться внутри объекта.
В системе отсчета, зафиксированной относительно Земли, таки Солнце вращается вокруг Земли.
Они вместе вращаются вокруг барицентра. :-)
А еще можно разработчика попросить пожонглировать. Если у него получилось - значит ловкость рук у него высокая, и ему можно давать задачи связанные с вводом больших количеств текста, если не справится - значит будет работать с аналитическими задачами!
У меня, если что, еще много идей такого-же плана, как у того раввина! Даёшь нескучные собесы!
А есть еще вариант с overskill.
Когда на одном из собеседований по контрольному примеру я привел результат, отличный от ожидаемого, мне указали, что я решил его неверно. Я проверил решение и не нашел ошибки, после чего мы вместе со спецом компании проверили "эталонное" решение от работодателя и нашли ошибку в нем.
В результате - отказ. Написал просьбу прислать комментарий и к моему удивлению получил ответ, в нем было написано как раз что-то вроде такого: overskill - мы считаем, что вы быстро уволитесь от нас так как квалификация выше, чем требуется...
Испытываю противоречивые чувства, с одной стороны меня атакуют рекрутеры который хотят мне продать свои услуги по найму специалистов (а стоят они не мало, около 20% от годовой зарплаты искомого сотрудника). С другой стороны мне самому периодически пишут в LinkedIn с предложениями работы. И вот из-за вторых у меня совсем нет уверенности в первых (какой-то просто базовый отрыв от реальности и даже логики). В итоге только личные связи, рекомменадции, набор стажеров и взращивание собственных кадров (долго и мучительно, но хоть как-то). Десяток студентов-стажеров на лето - как раз как те 20% рекрутеру, а эффективность выше - парочка останется и славно.
Понятно, что тимлиды не будут вчитываться в каждое резюме: это не их работа.
Разве?
Так зачем замкнутому специалисту притворяться экстравертом, если в итоге работать не в комфорте
Не то, чтобы такое было каждый день, но например, затем, что он может быть на H1B в NYC, а вокруг сентябрь 2008 года. А пассаж "зачем терпеть, если можно не терпеть" выглядит как-то близко к словам Марии-Антуанетты про нет хлеба и пирожные.
Если читать статти рекрутеровто на словах они все Лев Толстой, а в реальной жизни оказывается...🤷 немного по другому😏
Мой "любимый" случай - когда в вакансии указывают, что ищут интерна без опыта работы, я откликаюсь, и мне приходит отказ с формулировкой "мы изучили Ваше резюме, и к сожалению у нас нет подходящей Вашему опыту позиции" (опыт не очень связан с IT - 1С-ник). Неужели эйчары думают, что я в свои 30 лет читать не умею и откликаюсь на всё подряд? Смысл смотреть на предыдущий опыт, если вы ищете мать его интерна?
Ужас-ужас это когда на техническом собеседовании в одну крупную компанию минут через двадцать беседы начали спрашивать что-то в стиле "а помните команду top? а что за параметр там во третьей строке сверху четвертый слева?" (подглядывать низя! :
Наверно самое частое, это когда тебе написал эйчар, рассказал что ты тот самый кандидат которого они искали всю жизнь, уговорил прийти на собеседование. А потом резко всё меняется, как будто эйчару настройки сбросили, и он такой "Почему выбрали нашу компанию?"
А ещё раздражают те, которые говорят что, "мы прочитали ваше резюме и вы нам полностью подходите", при этом предлагаю скажем работу не Go разработчика а Java. Ну т.е. резюме вообще не читали, как и не читали зарплатные ожидания или позицию
В начале этого 2023 года мониторил вакансии администраторов Domino. Дык, встретилась вакансия. где необходимо было ОБЯЗАТЕЛЬНО иметь сертификаты по Domino от самой IBM.
Пришлось в обязательном отклике на вакансию написать, что все сертификаты от IBM уже не имеют силы, так как индусы из HCL купили Domino ещё в конце 2018 года. Даже приложил ссылку на официальный ресурс где темным по светлому написано, что все сертификаты по IBM Domino утратили силу.
Тут ни HR, ни сами IT-шники, которые составляли требования, просто "не в теме". А прошло уже более 4 лет...
99% IT-HR не знают, чем отличается c++ backend разработчик и c++ desktop разработчик.
С чем сталкивался лично я:
На одном из прошлым мест работы понадобился админ, я составил и передал HR-у перечень требований к соискателю. HR начал присылать мне любые резюме, в которых хоть как-то упоминается работа с компьютером, никакого предварительного отсева не делалось. Несколько раз служба найма умудрилась пригласить на техническое собеседование соискателей с "нулевыми" знаниями и навыками. На мой вопрос, зачем они это делают - был простой ответ "бери любого, они все равно потом все увольняются". Конторе > 15 лет, численность ~250 человек, ежемесячно увольняется 7-10-15 человек (не из моего IT-направления), идет постоянный набор, служба персонала получает %% к премии за каждого принятого нового сотрудника, что будет с ним дальше - их абсолютно не волнует, даже если он уволится через 4 часа (это реальные случаи).
Когда сам искал работу, прошел первое собеседование с HR, по ее словам - все отлично, передам вас дальше, на техническое собеседование. И все, тишина. Кое-как, недели через две, удалось связаться с HR, ответ, мягко говоря, расстроил "технический специалист сказал, что вы нам не подходите, у вас нет нужных нам компетенций", как выяснилось в дальнейшем разговоре, что эти "нужные компетенции" отсутствовали в вакансии, их просто забыли добавить.
Вакансия висит месяцами, отправил отклик и никакой реакции (Outlines Technologies тоже "грешит" подобным).
Почему просто не нанять на должность рекрутера человек который понимает что нужно делать?
так ну что все наговорились, можно подводить итоги? вроде как неплохое число плюсиков для первой статьи, не говоря уже о коментах. а началось то все с минусов.
У меня от hr осталось двойственное впечатление: я ведь даже получил фидбэк от hr. Но фотку "противной девченки" с хенкали мы так и не увидели поэтому пришлось оценивать за содержание.
А вообще, уважаемые господа, кучеряво живете. И кандитатов за забором много, и hr и рекрутеры есть, и делают некоторую работу, созваниваются, встречи организуют, даже интервью. проводят. Для кого то это - другая реальность.
По моим наблюдениям
Чем более красивая рекрутерша, тем тяжелее предстоит работа.
Не всегда) но спасибо за мнение.
Эйчары такие противные девочки, которые отказывают из-за цвета глаз: найм глазами IT-рекрутера