Как стать автором
Обновить

Эйчары такие противные девочки, которые отказывают из-за цвета глаз: найм глазами IT-рекрутера

Время на прочтение5 мин
Количество просмотров59K
Всего голосов 81: ↑54 и ↓27+42
Комментарии366

Комментарии 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? оно не входит в какие-то другие пункты?

да и как-то много делегировали эйчару без тех знаний.

Может быть проблема была в том, что эйчар выполнял работу, которую должен выполнять рекрутер?

Как понял здесь это совмещенная позиция.

которую должен выполнять рекрутер?

По своему опыту я вижу, что рекрутёры ничего не отличаются. Может конечно - это не настоящие рекрутёры, но других я не встречал. Я встречаю только тех, которые мне в linkedin пишут.

Поскольку 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 не вешают.

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

«Не приходится» — настоящее время, «не работали» — прошедшее. 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, знаете, судя по вашим высказываниям, вы совершенно не имеете навыков к диалогу.
Софт скиллы ужасны, понимание процессов ужасны. Даже не пытаетесь вникнуть в точку зрения собеседников.

И вы еще что-то рассказываете что "выстраивать работу" это сложная задача? Ну для токсичного менеджера наверное сложная. Для менеджера, который не способен оторваться от своих предпочтений и объективно идти к диалогу - тоже сложно.

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

Простите, а где отбирают в программисты? Куда в очередь встать?

Не удрежался)

Например, при устройстве на работу. В FAANG, как вариант. Да хоть в Яндекс.

НЛО прилетело и опубликовало эту надпись здесь

(глядя на утыканный как ёлка шариками 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 % он не стоит?..

Мне вот почему-то не приходится работать ни проджектом, ни аналитиком, ни продактом. И вакансии, где от меня ещё и на баяне немного играть требуется, дальше этого требования не читаю.

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

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

Учитесь говорить слово «нет».

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

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

Что тут может быть хуже? Вас к батарее отопления в офисе прикуют?

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

«Я свои права отстаивать не хочу, я хочу, чтобы другие магическим образом перестали их нарушать» — заведомо неработающая позиция.

Всегда есть цена вопроса и готовность ее платить. Есть баланс между затратами на борьбу за права (не всегда только денежными и временными) и ее положительными результатами.

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

Есть, это факт.

Но называть «проблемой» то, что вам просто не карману — это инфантилизм. Ребёнок рыдает, если ему не достаётся игрушка. Взрослый человек или зарабатывает на игрушку, или живёт без неё — потому что понимает, что никто ему в ответ на рыдания игрушку не даст.

Впрочем, можно отнести эти жалобы к психотерапевтическому выговариванию.

Но называть «проблемой» то, что вам просто не карману — это инфантилизм.

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

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

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

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

И куда потом пойдете устраиваться с таким бэкграундом сутяжничества?

По мне всё намного проще: не сошлись с работодателем - мирно разбежались, и не компостируем друг другу мзг.

90% своей карьеры работаю самозанятым
По причинам расставания с предыдущим "работодателем" никто справки особо не наводил

А вы уверены, что это «там дай бог», а не что ваш уровень квалификации в этом качестве таков, что больше 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 типовых отмазок плохих программистов.

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

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

И понимание границ своих компетенций является базовым навыком любого минимально грамотного работника в любой области.

Которым вы, например, не обладаете.

НЛО прилетело и опубликовало эту надпись здесь

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

Я не спорю, что это реалистичное описание, но вам самому не кажется, что оно крайне унизительное? Это же характеристика человека с 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/фирму ?

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

НЛО прилетело и опубликовало эту надпись здесь

Так и CV он не на обрывке газеты пишет. Он точно знает про "автокомплит и проверка синтаксиса"?
Для меня лично, неумение писать грамотно на родном и рабочем языке - сигнал тревоги.

Если программист допустит опечатку в синтаксисе языка программирования, программа не скомпилируется, пока он ее не исправит. И современные IDE с автозаполнением во время набора сильно упрощают жизнь. Даже если забыл какую-то часть синтаксиса - гугл под рукой.

А если он не способен в синтаксис - как он будет решать хотя бы самую простую приближенную к реальности задачу?

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

Понимаю, что есть IDE. Синтаксис, на мой взгляд, это не про умение писать без синтаксических ошибок, а про представление чего-то (текста/кода) как набора блоков, имеющих смысл, и оперирование этими смысловыми блоками. Человек, который пишет с ошибками, подходит к языку как если бы это была регулярная грамматика (применяет регулярные эвристики, например: "всегда ставить запятую перед "как"). И тут нужно дополнительно удостовериться, что он не потеряется в задаче, требующей контекстно-свободной грамматики.

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

т.е. IDE c автокомплитом и вот это вот все - для слабаков, а программисты у вас пишут код на бумажке )))

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

Но при этом делаете вывод о профессионализме на основании лишнего пробела в резюме. Ну ок ))

Я рад, что вы наконец-то меня поняли.

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

Вот интересно, а как вы оцениваете ну конкретно "внимание к деталям" ??? Опишите с примерами

ну или как то так

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 секунд, чтобы всё сказать про него. По щелчку пальца буквально."
"Кандидат берет трубку сонным, ленивым или недовольным голосом говорит "Алло" и я сразу понимаю, что это не наш кандидат."
Мне тоже интересно по каким критериям компании набирают себе эйчаров.

Погуглил все три фразы. Надо сказать, что вторая (вот эта)

"Мне достаточно 20 секунд, чтобы всё сказать про него. По щелчку пальца буквально."

это цитата слов кандидата в службу безопасности, а не HR.

Очевидно что эйчаров должен выбирать эйчар для эйчаров.

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

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

Иногда меня называют хинкали-рекрутером

И что это значит? Нанимаете только в грузинские офисы?

Зачем вкидывать неизвестный аудитории термин и не раскрывать его?

Хинкали-рекрутёр - вкидывает неизвестный аудитории термин и не раскрывает его.

Ник дали мне айтишники в одном из тг-чатов. Мы в Outlines Tech вели зарубежные проекты, и мне срочно нужен был разработчик из стран СНГ. Я искала выходы на крутых ребят из Армении или Грузии. Зашла в отчасти профильный чат и спросила у IT-специалистов, где найти профи. Один из ребят в беседе расстроился, что я не ищу его профиль, и написал мне в ответ: "нервно бросается хинкалями".

Я поддержала шутку. А потом ребята нашли мой профиль в соцсети и узнали, что я занимаюсь кавказскими танцами. Так и дали прозвище "Хинкали-рекрутер".

Вот такая история

tldr: стереотипы про HR правдивы, но на то есть причины, хотите работу — делайте хорошо, а плохо не делайте. Вот ссылка на TG

стереотипы про <любая профессия> правдивы, но на то есть причины, хотите работу — делайте хорошо, а плохо не делайте. Вот ссылка на TG