Как понять, что вы провалили собеседование, потому что не так дышите или выбесила ваша рубашка? А как понравиться рекрутерам, чтобы трудоустроиться? Рассказываю о буднях эйчаров и списке, по которому отсекаются даже самые талантливые кандидаты.
А если серьезно, я столько мемов и комментариев про рекрутеров посмотрела, что сложилось впечатление, что в профессии только недалекие и надменные девочки, которые выбирают тех, кто им покажется симпатичным. Хотя это не так. В статье рефлексирую, почему рекрутеры и айтишники оказались по разные стороны баррикад, хотя у нас одна цель — трудоустройство. Где проколы эйчаров, а в каких моментах мы не так друг друга понимаем.
Меня зовут Анастасия Эллисон, я руководитель команды IT-рекрутинга в Outlines Tech. Иногда меня называют хинкали-рекрутером. В HR я с 2009 года: нанимала людей для различных компаний и выстраивала внутренние процессы. В 2019 году перешла в IT-рекрутинг.
Если хочешь огрести от IT-специалистов и нарваться на насмешки, то просто скажи, что ты эйчар
Наверное, смеются над теми рекрутерами, которые не стремятся к развитию. Профессия требует постоянного обучения: мы читаем статьи и проходим дорогие курсы. Тратим время и ресурсы, чтобы говорить с соискателями на одном языке, понимать стеки. Если рекрутер этого не делает, то задает на собеседовании глупые вопросы, что бросает тень на профессию.
Возможно, некоторым IT-специалистам не везет и они попадают на новичков. Когда рекрутер переходит в IT, он теряется в стеках. Признаюсь, первые мои собеседования были провальными. Я ничего не знала о разработке и не понимала, что у соискателей спрашивать. Мой переход в IT был спонтанным: руководитель попросил найти программистов. Пришлось учиться на ходу.
Бывает, процесс трудоустройства затягивается, и это ужасно расстраивает. К сожалению, тут не все зависит от рекрутера. У работодателя свои задачи, графики и планы. Бывает, тимлид уходит в отпуск или болеет. Все мы люди. Со своей стороны, моя команда проводит кандидата через все этапы собеседования и честно обозначает сроки.
Не так дышал на собеседовании: если ты не понравился эйчару, то не пройдешь дальше. И все равно, какой ты специалист
Недавно читала похожие комментарии на просторах интернета. Мне искренне жаль, если кто-то сталкивается с некомпетентными специалистами. Профессиональный же рекрутер оценивает человека не для себя, а для команды. Даже если не понравился человек, это не влияет на итоги собеседования. При этом понимаю, почему у соискателя складывается впечатление, что ему отказали из-за антипатии. Даже крутой разработчик может не пройти собеседование из-за, как кажется, мелочей, которые не относятся к работе.
Рекрутер смотрит на человека в целом: на характер, мотивацию, отношение к работе и софт-скиллы. Задача — сделать всем хорошо: соединить профессионала с командой, которая подходит. Если в коллективе все щуки, то лебедь и рак там не уживутся. Допустим, приходите в команду, где привычки, атмосфера, рабочий уклад не соответствует вашим особенностям. Все дышат бесяче громко, а ты — тихо (это я утрирую). Вам комфортно будет? Поработаете немного и уйдете, а кому от этого лучше? Команде, которая потратила время на онбординг, или соискателю, который, например, уволился ради этой должности?
Поэтому при собеседовании рекрутеры обращают внимание не только на профессиональные качества. При этом наша команда даёт обратную связь, почему отказываем в трудоустройстве. Это снимает тревогу от неопределенности у соискателя, почему не подошел. А еще помогает человеку понять свои точки роста и определиться с проектами, где будет комфортно.
Кандидат должен говорить ровно то, что эйчары хотят услышать, а не отвечать на вопросы честно. Тогда найдёшь работу
Частенько сталкиваюсь и с таким мнением. Снова представим ситуацию: обманули, сказали «нужные» слова, а что дальше? Вам команда не подходит по стилю работы. Сбежите или будете терпеть? Есть команды, где не нужны коммуникабельные люди, а есть те, где человеку придется каждый день общаться. Так зачем замкнутому специалисту притворяться экстравертом, если в итоге работать не в комфорте?
Если вижу, что человек не подходит по софт-скиллам, я помогаю скорректировать резюме, чтобы он нашел подходящую работу, или предлагаю другую вакансию. Так будет честнее.
Собеседуете, хотя ничего не понимаете в моей работе
Правда в том, что некоторые IT-рекрутеры умеют проводить и техническое собеседование. Мы постоянно учимся, изучаем стеки и взаимодействуем с тимлидами. Среди специалистов чаще всего есть разделение, кто нанимает, например, Java-специалистов, а кто разработчиков на C++, чтобы тщательнее разбираться в теме.
Другой вопрос, нужно ли IT-рекрутеру проводить технические собеседования? Представьте, вас гоняют по хард- и софт-скиллам на одном собеседовании сразу. Дальше приходите как выжатый лимон на техничку, потому что тимлидам важно оценивать потенциальных коллег, и слушаете практически те же вопросы. Поэтому рекрутер больше оценивает софт-скиллы и первичные харды. Он сужает воронку кандидатов, которая идет к тимлиду.
Да и будем честны, у технических специалистов нет времени общаться со всеми соискателями. Чтобы понимать масштабы: наши IT-рекрутеры берут в работу по 500-800 CV в неделю каждый. Всего сейчас в компании открыто более 80 вакансий.
Понятно, что тимлиды не будут вчитываться в каждое резюме: это не их работа.
Одна строчка, а сколько боли! Говоря о резюме, почему не приглашают на собеседование даже профессионалов?
Первая причина, почему рекрутеры не приглашают на интервью — нерелевантный опыт. Кандидат не подходит по скиллам, проектам или у него не такой серьезный стаж работы, чем компания ожидает.
Вторая причина — некоторые кандидаты описывают свой опыт одной строчкой. Из-за этого сложно понять, чем человек занимался. Если время позволит, рекрутер вчитается в резюме и поищет алмаз, а если откликов слишком много, то пройдет дальше.
Недавно был случай: разработчик описал свой опыт в двух строчках, как будто совсем недавно в профессии. Я направила ему уточняющие вопросы и оказалось, что он сеньор, который себя недооценивает. Он давно перерос свой грейд.
Я запросила обратную связь по итогам общения и получила ответ:
«Спасибо большое за вопросы. При размышлении над ответом, я пришёл к выводу, что вы правы, и мое резюме действительно не отражает всего опыта. Высылаю отредактированное резюме и сообщаю, что принял решение ещё посмотреть рынок с обновленным CV».
В итоге он трудоустроился в другую компанию. А я поняла, что больше, чем просто рекрутер и руководитель: я помогаю увидеть свой опыт со стороны и действительно построить карьеру.
Кстати, зачастую наша команда помогает усилить резюме, чтобы классный соискатель нашел работу мечты. Пусть даже не у нас. Земля круглая, и с человеком рано или поздно пересечемся на рынке труда. В моих интересах выстраивать хорошие отношения. Тем более я получаю заряд мотивации и положительных эмоций, когда вижу, что человек благодаря мне нашел классную работу и стал счастливее.
Кстати, совсем недавно мы публиковали чек-лист, который помогает усилить резюме. Надеюсь, он поможет трудоустроиться как можно скорее и без лишних нервов.
Вместо эпилога
Интересно узнать про ваш опыт взаимодействия с рекрутерами.
Поделитесь в комментариях историями про свои кринжовые или приятные собеседования
Комментарии (345)
Daddy_Cool
08.11.2023 11:26+14Поскольку HR обычно не специалист в технических вещах, то должен быть (в среднем) перекос в плане весов софт-скилс при оценке кандидата. А многие программисты не очень общительные люди в принципе и лавное - работа этого и не требует. Мой друг рассказывал про свою работу - "Я утром здороваюсь, вечером говорю начальнику - вот - и показываю на экран - всё". Возможно это нерешаемая проблема в принципе - хард и софт скилс это противоречивые вещи, одно требует интроверсии и концентрации, другое - экстраверсии и внимания к куче внешних вещей - типа эмоций других людей.
sensem
08.11.2023 11:26+16Обычно специалистов, совмещающих в себе эти наборы качеств, руководство со временем пытается двигать на всякие менеджерские должности, дабы человек мог и контролировать непосредственно технарей, разговаривать с ними на одном языке, отслеживать их прогресс, и отчитываться начальству, переводя всё уже им.
olartamonov
08.11.2023 11:26+1Именно так. И денег на этих позициях больше, чем у программистов, да и работа куда интереснее (для человека, умеющего в коммуникации), так что они и не отказываются.
voldemar_d
08.11.2023 11:26+29Насчет "куда интереснее" - сложный вопрос. Есть люди, которым интереснее создавать что-то самому, а не управлять другими людьми.
olartamonov
08.11.2023 11:26Во-первых, я — именно этот человек :)
Во-вторых, управляющий другими людьми именно что создаёт что-то сам — только это не кусок кода (железа, etc), а комплексная система, в которой написанный кем-то кусок кода является лишь одним из компонентов.
Программисты же в большинстве своём сами ничего не создают, у них просто нет простора для реального творчества — их задачей является реализация данного им (составленного и согласованного мной :) ТЗ на разработку.
voldemar_d
08.11.2023 11:26+17Бывают же разного уровня программисты. Кто-то пилит низкоуровневый код, а кто-то - код верхнего уровня, который вызывает кучу других библиотек/процедур, написанных другими людьми. При этом параллельно конструирует GUI, например.
Я не очень понимаю, что значит "сами ничего не создают". Вот я написал процедуру, например, которая фильтром цифровой звук обрабатывает, с разными специфическими особенностями, т.е. это не тупо "взял готовую библиотеку для DSP и вызвал её". При этом я ничего сам не создал, что-ли?
olartamonov
08.11.2023 11:26Бывают же разного уровня программисты
Это количественная разница, не качественная.
При этом я ничего сам не создал, что-ли?
Вы решили проблему. При этом не только саму проблему, но и методы её решения вам довольно-таки жёстко задали другие люди.
Нет, это хорошая и важная работа. Но в её рамках у вас нет выбора, что вы создаёте, и весьма ограниченный выбор — как. Примерно как у штукатура, которому дали задание выровнять стены в квартире (и в принципе да, ровную стену в итоге он создал, можно и так сказать).
На менеджерском уровне выбор и того, и другого существенно расширяется (впрочем, как ниже отмечено, и спектр геморроя — тоже).
voldemar_d
08.11.2023 11:26+16Почему количественная? Бывает программист, которому по силам внести только изменения в небольшую часть кода, а бывает - которому по силам структуру проекта перепроектировать.
При этом не только саму проблему, но и методы её решения вам довольно-таки жёстко задали другие люди.
Не факт. Допустим, сказали такое: "нужно реализовать эквалайзер для звука, работающих в реальном времени на процессоре такой-то производительности. Найди подходящее решение и реализуй его". То есть, здесь нужно и некоторое исследование провести. При этом, менеджер сам мог никогда с такими задачами в своей практике не сталкиваться, даже если он сам программист 80-го уровня.
ИМХО, это еще вопрос личного восприятия. Для меня и создать процедуру, которая хорошо решает поставленную задачу - вполне созидание чего-то. Особенно, если ничего готового ни в каких библиотеках нет.
olartamonov
08.11.2023 11:26-5Почему количественная? Бывает программист, которому по силам внести только изменения в небольшую часть кода, а бывает - которому по силам структуру проекта перепроектировать.
Потому что это — количественная разница. Единственное отличие между двумя — какое количество кода каждый из них способен написать, не сломавшись.
Не факт. Допустим, сказали такое: "нужно реализовать эквалайзер для звука, работающих в реальном времени на процессоре такой-то производительности. Найди подходящее решение и реализуй его"
Вы повторяете ровно то, что я вам написал: вам дали задачу и указали на метод её решения. Какие конкретно буквы будут написаны в рамках этой задачи и этого метода — это примерно тот же уровень самостоятельности, что у штукатура в выборе мастерка и марки штукатурки.
При этом, менеджер сам мог никогда с такими задачами в своей практике не сталкиваться, даже если он сам программист 80-го уровня.
Есть некоторая разница между «не сталкивался» и «не знает, что они вообще существуют».
Программист про задачи уровня менеджера — обычно второе.
voldemar_d
08.11.2023 11:26+6Так ведь не указали метода решения. Сказали "сам найди метод".
olartamonov
08.11.2023 11:26работающих в реальном времени на процессоре такой-то производительности
На уровне проекта — это и есть метод.
Повторюсь: какими строчками кода вы его реализуете, значение имеет примерно такое же, «волмой» или «ротбандом» штукатур будет стену выравнивать. Просто в силу незначительности этого вопроса в общем масштабе.
Хотя если вы спросите любого опытного штукатура — он вам получасовую лекцию про разницу между ними выдаст. И про исследования там тоже будет.
SpiderEkb
08.11.2023 11:26+5На уровне проекта — это и есть метод.
Это не метод. Это граничные условия.
Странно, что менеджер этого не понимает.
Менеджеры тоже разные бывают. Есть такие, что сами от себя вне себя, их просто раздувает от "важности решаемых ими задач", а по факту они ничего из себя не представляют вше нежели "погонщик кобылы" - им сверху спустили указявку "перегнать телегу с грузом туда-то", вот они загрузили ее, кобылу запрягли и нахлестывают ее изо всех сил чтобы бежала быстрее. Сдохнет по дороге потому что покормить забыли - так это кобыла плохая попалась. Идет медленно потому что телега слишком тяжелая, а дорога плохая - опять кобыла виновата, надо сильнее ее кнутом...
geher
08.11.2023 11:26+21Тогда и менеджер ничего не создает. Ему дали задачу сверху, дали ресурсы и методы решения, вот он и крутится. Только самые-самые топы в менеджементе что-то созидают. /s
olartamonov
08.11.2023 11:26Нет. На менеджера чуть выше среднего сверху уже не спускаются конкретные проблемы, сверху спускаются хотелки руководства, клиентов и т.п. Их отличие от конкретных проблем — в том, что про них неизвестно не только, каким образом их решать, но и можно ли их решить вообще в рамках ресурсов, располагаемых компанией.
Менеджер оценивает, можно ли это сделать, согласовывает варианты решения со всеми заинтересованными сторонами, оценивает ранее неучтённые факторы (например, проблемы соответствия законодательству, долгосрочные риски, перспективы рынка и т.п.), согласовывает ещё раз — после чего уже раскладывает на конкретные проблемы и спускает на исполнителей.
P.S. Например, не далее как вчера я объяснял архитектору очень, очень большого решения, что мне нужно носить данные на CD-R. Мне всё равно, что они подписаны ЭЦП и их нельзя подделать. Мне всё равно, что их любой желающий может сам скачать с сайта. Мне всё равно вообще на все технические соображения о том, как надо писать программы в 2023 году, потому что у меня есть параграф 9 пункта 6 статьи 33 федерального закона № 67-ФЗ, который в явном виде предполагает процедуру «получить от» — а значит, эта процедура должна быть. И практика, в рамках которой реализация данной процедуры с использованием CD-R другой стороной была признана разумной и не повлекла написания жалобы ни мне, ни в вышестоящую комиссию, ни в суд, у меня тоже есть.
geher
08.11.2023 11:26+11Пес его знает, но многие программисты (и я тоже имею такой опыт), часто получают от менеджеров задачи, про которые "неизвестно не только, каким образом их решать, но и можно ли их решить вообще в рамках ресурсов, располагаемых компанией". Юридическими вопросами программисты, конечно, обычно не занимаются (их возвращают обратно менеджеру, фактически ставя перед ним конкретную задачу), но других тоже более чем хватает.
olartamonov
08.11.2023 11:26Есть много плохих менеджеров, есть много плохих программистов, а уж штукатура хорошего вообще днём с огнём, новости в том нет никакой.
Юридическими вопросами программисты не только не занимаются, но и не возвращают менеджеру — потому что даже не подозревают о существовании таких вопросов. В приведённом примере с точки зрения программиста — подписанный ЭЦП PDF, который любой желающий может скачать с публичного сайта, не просто не вызывает никаких подозрений, но и является очевидно много лучшим решением, чем какие-то CD-R, вы б ещё на дискеты бы записать предложили.
geher
08.11.2023 11:26+3Юридическими вопросами программисты не только не занимаются, но и не возвращают менеджеру — потому что даже не подозревают о существовании таких вопросов.
Программисты разные бывают. Те, что решают только узкие задачи типа "написать процедуру с таким-то входом и таким выходом", естественно, до юридических вопросов никогда не опускаются.
Но если у программиста больше уровень самостоятельности, то юридические вопросы, вытекающие из ТЗ, он вполне должен уметь вычленить, и поставить перед руководством (ибо решать их не его дело).
Например, та же запись на CD-R.
Если программист замечает, что оно по закону должно быть, но не отражено в детально составленном ТЗ, то он должен поставить вопрос перед менеджером (если менеджер скажет "нафиг", то это уже его, менеджера, проблемы и его же зона ответственности).
Если же ТЗ составлено максимально неконкретно, то он сам должен сделать "как положено", ибо условная кнопка "сделать хорошо" предполагает в том числе и соответствие результата требованиям закона. И если по закону (или по ГОСТУ, если оный прописан в ТЗ, или по хотелкам заказчика, озвученных за пределами ТЗ) некоторый вариант должен быть реализован, то даже реализация лучших вариантов не основание для отсутствия реализации требуемого.
А еще бывают программисты, работающие в одно лицо, общаясь непосредственно с заказчиком, либо вообще являющиеся сами себе заказчиками.
olartamonov
08.11.2023 11:26+2Если программист замечает, что оно по закону должно быть, но не отражено в детально составленном ТЗ
Вы не очень понимаете, что такое «по закону должно быть».
В законе нигде ничего про CD-R не написано.
В законе написано, цитирую дословно, «знакомиться с протоколами избирательной комиссии, в которую он направлен, и протоколами непосредственно нижестоящих избирательных комиссий об итогах голосования, о результатах выборов, с документами, приложенными к протоколам об итогах голосования, о результатах выборов, получать от соответствующей избирательной комиссии заверенные копии указанных протоколов» (и пардон, я там рефлекторно номер закона перепутал, это конкретно из 20-ФЗ, хотя в 67-ФЗ есть такое же, конечно).
Вот из этого — а это всего один пункт большого и сложного закона, в котором одна только статья, из которой эта цитата, занимает несколько страниц — надо зацепиться глазом за «получать от соответствующей избирательной комиссии» и задуматься, а что это вообще значит — получать от комиссии?
А как это выглядит на практике, вживую? А с точки зрения наблюдателя? А что дальше он делает с этими копиями, после получения, а зачем он это делает? А что надо сделать, чтобы эту практику не сломать в случае, когда протоколы — это файлы PDF? Какие есть варианты, какие у них проблемы, как они будут восприняты и наблюдателями, и комиссией? А судами, если до судов дело дойдёт?
Это огромный объём информации, подразумевающий либо практику соответствующей работы (я — дважды зампредседателя и пока что только один раз председатель избирательной комиссии), либо целый список людей, с которыми по этим вопросам надо поговорить.
Если программист этими знаниями обладает — он давно уже не программист.
Ваше же «заметить, что по закону должно быть» выглядит примерно как совет программисту «заметить, что по Страуструпу должно быть».
Ну что ты тут в коде ошибки делаешь, по Страуструпу ошибок не должно быть.
evadesad
08.11.2023 11:26+2В программировании тоже есть очень много подобного.
Я работаю в финтехе, девопсом, и чаще всего именно программисты мне рассказывают о том, что "это требование регулятора, и обычно в индустрии оно реализуется так или эдак, и мы выбрали это решение, потому что то и это"
Очевидно, что требование регулятора нужно как-то понимать, чтобы не реализовать дыру вместо стены.
Или "по требованию аудитора должно быть так и эдак, но в жизни это всё равно, что дыру в стене газеткой прикрыть, потому что с тех пор случилось это и вот это, а требования ещё не обновились, поэтому вот тут у нас штука, чтобы аудитор был счастлив, а тут настоящая кирпичная кладка в месте дыры"
И да, надо нос по ветру держать, что там у нас требуется от аудиторов, от регуляторов, от локации (потому что в разных локациях разные законы и разные правила, и разные все эти сущности), а также, что там нашли-обнаружили-открыли (тот же log4j, который "мы" заранее поменяли, а "они" только когда аудитор возбудился)
А также абсолютно обыденна ситуация, когда "вот у нас появились новые требования, а как их реализовать пока никто не знает", и нужно как-то подумать и что-то сделать, чтобы оно соответствовало новой policy.
И да, это-таки требует людей, с которыми можно поговорить и понимания предметной области вообще, и понимания, что делает конкретное приложение в частности.
sergyalosovetsky
08.11.2023 11:26+8я правильно понимаю, что в ваших терминах, если директор приказывет подчиненному: "создай новый классный продукт, потому что другие что-то показывают слабую доходность", и подчиненный создает новый продукт, то создатель продукта - директор?
а его подчиненный, так, просто маленький винтик, который выполнил задачу?
olartamonov
08.11.2023 11:26Нет, создатель продукта — подчинённый.
Но программисту не ставят задачу «создай продукт, который показывал бы доходность выше имеющихся».
Он её просто не решит никогда, у него нет на это квалификации.
Tolomuco
08.11.2023 11:26+7Тут бы стоило добавить что-то, типа "на сколько я знаю", или "как показывает моя практика". ")
А то моя, например, практика показывает, что иногда програмисту такие задачи таки ставят :)
И програмист её таки вполне способен решить. Как минимум мне известен один такой случай.
olartamonov
08.11.2023 11:26Я абсолютно уверен, что в мире есть хотя бы один таксист, умеющий управлять гражданскими авиалайнерами.
Тем не менее, я могу уверенно утверждать, что у таксистов нет квалификации по управлению гражданскими авиалайнерами и что таксистам не ставят таких задач.
Tolomuco
08.11.2023 11:26+6Как насчёт аэротакси? ;)
А с програмистами ситуация ещё хуже - они могут вообще практически любой квалификацией обладать. Я учился с человеком, который одновременно являлся и практикующим програмистом, и практикующим хирургом. И это не единичный случай, на сколько я знаю.
Так-то уверенно утверждать можно всё, что угодно. :)
voldemar_d
08.11.2023 11:26Не в любых организациях четко разграничены полномочия между сотрудниками, так что "шаг влево - шаг вправо, и это уже не твоя обязанность".
sergyalosovetsky
08.11.2023 11:26+2очень часто менеджер может понимать, что нужно сделать, чтобы продукт взлетел, но сам он это сделать не может
и даже не знает в чем лежит проблема, и какой можно придумать план решения
а еще чаще менеджер вообще не видит проблемы, потому что его образования не хватает увидеть, что может быть лучше
например - сайт должен загружаться быстро, максимум за 0.2 с
или было бы прекрасно, если бы смартфон имел экономный режим, в котором мог бы работать пару недель; для этого уже сейчас есть все необходимые компоненты - супер энергоэффективные чипы, большие аккумуляторы, амолед экраны (для того, чтобы рисовать не весь экран 1440*3088, а только пару тысяч пикселей, чтобы нарисовать текст) и электронные чернила
то же самое касается умных часов - какая религия запрещает им работать хотя бы месяц?
или, было бы очень хорошо, если бы появилась система типа windows copilot, но доработанная - говоришь ей запустить проект А, и она находит все IDE у тебя на пк, находит среди проектов нужный и запускает среду
или по команде бл*** отменяет 3 последних действия
но менеджер никогда не сможет дать какой-то внятный план, кроме декларативного описания: "хочу, чтобы было так", потому это исключительно задача программистов понять, как этого можно добиться
ведь способов достижения множество, но каждый из них имеет преимущества и недостатки
определить лучший способ с учетом всех следствий этого способа - тоже задача программиста
из-за того же, что менеджеры не способны понять долговременные последствия своих решений, мы столь часто пользуемся столь ужасными продуктами - глючными, медленными, переусложненными, неудобными, выжирающими всю память и цпу
у меня смартфон 20 летней имеет приблизительно те же возможности, что и текущий (браузер правда работает получше), он работает примерно то же время от батареи, он приблизительно столько же заряжается, только камера хуже (сильно хуже)
при этом у старого смартфона в 15-20 раз слабее процессор, у него в 2000 раз меньше оперативной памяти, у него в 7 раз слабее аккум!
как показывает практика, любого человека можно обучить на менеджера, но только некоторые могут стать программистами
потому задача программистов как раз более творческая, но и более сложная
Keeper10
08.11.2023 11:26"Показать доходность выше имеющихся" -- как раз один такой программист недавно и давал показания в суде.
yewuv
08.11.2023 11:26+17То есть вы хотите сказать, что программист, переведший ваше ТЗ в программу творчеством не занимается, а вы, переведший слова заказчика в ТЗ занимаетесь творчеством? Так что-ли?
olartamonov
08.11.2023 11:26-22Вообще говоря, да.
Программист — исполнитель, творчества у него в работе примерно как у штукатура. За излишнее творчество его и вовсе наказывают обычно.
yewuv
08.11.2023 11:26+6А что, ТЗ уже стали писать как сочинение на свободную тему? Или там все-таки тоже свои правила есть? В чем творчество перефразировать слова заказчика, иногда проясняя места не до конца осознаваемые этим самым заказчиком места?
olartamonov
08.11.2023 11:26-9Вы хотя бы раз в жизни с реальными заказчиками работали?..
У них нет слов, которые можно «перефразировать». У них есть некоторое представление о том, что должно получиться в конечном итоге — не учитывающее технологические возможности, ресурсные ограничения, действующее законодательство и многое другое.
От слов заказчика до ТЗ обычно месяц работы. Иногда больше. И заказчику это «перефразирование» запросто может стоить от сотен тысяч до миллионов рублей.
tenzink
08.11.2023 11:26+1Вот вы сами пишете, что ни аналитиком, ни продактом не работали - вот кто делает реальную творческую работу и спасает заказчику миллионы. Так что программисты/менеджеры и прочие там "штукатурщики" пусть не примазываются.
olartamonov
08.11.2023 11:26Гм. Ну не надо за меня додумывать, пожалуйста. Я пишу, что там, где я занимаюсь менеджерской работой — нет, на меня ни аналитику, ни PO/PM не вешают.
Продактом я работал, причём в нескольких разных качествах, не только программистском. С аналитиками работал. Код, если что, тоже руками писать умею.
tenzink
08.11.2023 11:26Я за вас не додумываю. Я вас цитирую https://habr.com/ru/companies/outlines_tech/articles/772572/comments/#comment_26137184
olartamonov
08.11.2023 11:26«Не приходится» — настоящее время, «не работали» — прошедшее. So much for базовые навыки анализа информации.
tenzink
08.11.2023 11:26+1Чем вы тогда отличаетесь от "штукатурщика" в настоящее время? Все детали про продукт выясняют продукты с аналитиками. Вам остаётся с заданным бюджетом и ТЗ в нужный срок поставить продукт. Планирование ресурсов, раскидывание задач в JIRA по программистам не выглядит как содержательно сложная задача по созиданию. Тут даже методология не так важна.
olartamonov
08.11.2023 11:26Все детали про продукт выясняют продукты с аналитиками
У вас заказчик им сам задачи ставит, напрямую?
Планирование ресурсов, раскидывание задач в JIRA по программистам не выглядит как содержательно сложная задача по созиданию.
Какого масштаба (в человеко-месяцах) проектами вы лично руководили?
ruslan_sverchkov
08.11.2023 11:26+8Вместо ответов вопросом на вопрос вы могли бы привести пример творческой задачи менеджера, тогда возможно ваши оппоненты поняли бы что вы подразумеваете под словом "творчество")
olartamonov
08.11.2023 11:26-6Я нигде не утверждал, что у менеджера творческие задачи.
Но у него существенно меньше рутины и существенно большее разнообразие задач, чем у программиста.
В свете чего человеку, доросшему до нормальной менеджерской позиции, заниматься программированием попросту скучно.
olartamonov
08.11.2023 11:26-7У какого процента программистов выполняемые задачи не являются рутинными? Какой процентов программистов в своей работе создаёт что-то новое?
По моей оценке рынка труда — меньше 1 %.
hlogeon
08.11.2023 11:26-8Олег, слежу за тредом, отвечу здесь) Это бесполезно программистам доказывать, что это "скучно" и "рутинно" и что они не делают что-то новое. И Вы тоже таким были. И я таким был. Это лечится годами в индустрии и ростом в ней. А у кого-то не лечится. И это тоже хорошо.
Я понимаю о чем вы говорите и поддерживаю Вашу точку зрения, но по сути идет разговор слепого с глухим.
Написал просто поддержать и пожелать добра)
MiraclePtr
08.11.2023 11:26+14но по сути идет разговор слепого с глухим
Вот, именно. Конструктивного разговора не получится, когда одно из сторон демонстрирует категоричность уровня школьника средних классов: если вдруг кого-то не привлекает менеджерская работа и кажется скучной и не интересной, то в его мире это может быть только в случае если говорящий ещё "не достиг нужного уровня развития", никаких других вариантов в принципе быть не может. Естественно, с такой позицией, полным непринятием альтернативных мнений, обесцениванием чужой работы и эгоцентризмом это напоминает разговор с глухим.
olartamonov
08.11.2023 11:26«Кажется»? Я в одном из первых комментариев написал — жаль, что вы не прочитали — что к «кажется» у меня нет никаких претензий. Мне вот оливки кажутся невкусными.
Но зачем-то многие тут пытаются доказать мне, что она таковой является.
voldemar_d
08.11.2023 11:26+2Вам пытаются донести, что программист даже работу, которая выглядит рутинной со стороны, может вполне считать и созиданием, и творчеством. Для себя считать, понимаете? И от этого зависит, нравится ему его профессия и работа, или нет.
MiraclePtr
08.11.2023 11:26+5Вот именно. Могу предположить, что комментатор выше прирожденный менеджер, но хреновый программист. У него хорошо получается руководить людьми и решать проблемы на этом уровне, но ему скучно и не интересно программировать и быстро надоедает это дело. А у многих ровно наоборот - они испытывают реальный кайф от программирования, они находят в нем в том числе и возможность творить и решать интереснейшие для них задачи, но вот руководить людьми и решать сопутствующие задачи для них скучно, не интересно и совсем не привлекает (даже если это у них получается успешно и с хорошими результатами - такое тоже нередко бывает, да). Это не хорошо и не плохо, люди разные, таланты и характеры у них разные, опыт тоже разный. Просто не надо принижать других и обесценивать их работу.
hlogeon
08.11.2023 11:26Вы тоже не горите желанием принимать другую точку зрения, только и всего) Возможно, никому из вас этого и не надо?) У всех свой путь и понимание мира, индустрии, происходящего. Вероятно, не всегда стоить убеждать человека в своей точке зрения.
Но ментальная гимнастика забавная у вас тут получилась.
Про менеджмент, просто вкину мысль, что менеджмент это тоже программирование, просто машины намного более сложные и забагованные по самый небалуй, а языков программирования для них нет. Но и возможностей у них пока что значительно больше.
Rorg
08.11.2023 11:26+5Отлично, значит вы в принципе не отрицаете, что программисты создают что-то новое.
У какого процента программистов выполняемые задачи не являются рутинными?
Раскройте пожалуйста значение слова "рутинные" в вашем понимании.
olartamonov
08.11.2023 11:26-5«Утомительный, однообразный, лишённый творчества».
Написание кода именно такое.
Rorg
08.11.2023 11:26+2А, так вы про "написание кода"? Тогда ладно.
У какого процента программистов выполняемые задачи не являются рутинными?
Ну тогда думаю у большинства, ну кроме стажеров и наверное большинства джунов.
Дело в том что, ну как по мне, "программирование" != "написание кода".
olartamonov
08.11.2023 11:26-399 % (минимум) программистов не решают никаких задач, выходящих за рамки написания кода (и сопутствующих ещё более рутинных процессов: изучения документации, описывающей, как правильно писать этот код, поиска библиотечек, позволяющих писать меньше кода, поиска подходящих алгоритмов в случаях, когда библиотечек не нашлось, для написания на их базе кода).
Rorg
08.11.2023 11:26+9изучения документации, описывающей, как правильно писать этот код, поиска библиотечек, позволяющих писать меньше кода, поиска подходящих алгоритмов в случаях, когда библиотечек не нашлось, для написания на их базе кода
Простите, но почти все композиторы тоже сочиняют произведение на основании изученной базы. Та самая "Теория музыки" ("документация"), которая позволяет композитору сочинить произведение из подходящих фрагментов ("алгоритмов") для получения нужного результата.
Рутина есть и там и там, но также и там и там есть творчество.
olartamonov
08.11.2023 11:26-5Ещё раз: результат работы композитора уникален. Он не может быть повторён другим композитором, и в этом ценность композитора. Вы не можете нанять композитора на Хедхантере и сказать «у нас раньше Эннио Морриконе музыку писал, теперь ты продолжай писать такую же» и рассчитывать, что музыка будет не хуже.
Это — творчество.
Результат работы программиста — не уникален, он может быть повторён другим программистом, что тысячекратно демонстрируют все устоявшиеся практики разработки, в которых bus factor обычно тождественно равен нулю. Вы можете нанять программиста на Хедхантере и сказать «у нас раньше вот этот коннектор к СУБД писал, теперь ты продолжай писать такой же» и рассчитывать, что коннектор будет не хуже.
Это — ремесло.
Ничего плохого в том, что работа программиста — это работа ремесленника, нет. Но это работа ремесленника. Рутинная и однообразная.
Rorg
08.11.2023 11:26+4не можете нанять композитора на Хедхантере и сказать «у нас раньше Эннио Морриконе музыку писал, теперь ты продолжай писать такую же»
Простите, но вы не будете нанимать композитора, который пишет музыку как Эннио Морриконе, вы будете искать композитора, который будет писать музыку в определенном стиле, жанре. А вот тут уже можно найти и "такую же" (Настолько же подходящую к продукту, как и музыка написанная Эннио Морриконе).
PS: Я и не говорил, что ремесло – это плохо
voldemar_d
08.11.2023 11:26+7Нанять композитора еще как можно. Откуда берется озвучка к современным играм, сериалам, фильмам, по-вашему? И то что выдают эти композиторы - прямо очередной Моцарт или Вивальди? Как раз наоборот - среди потока современной музыки еще попробуй найди что-то уникальное или хотя бы узнаваемое. Сегодня это на 99% ремесло. А то, что композиторов нанимают не обязательно на хэдхантере - другой вопрос. И, кстати, спросите какого-нибудь композитора, который пишет современную попсу, считают ли они свою работу рутиной или нет.
antonkrechetov
08.11.2023 11:26+4Ещё раз: результат работы композитора уникален. Он не может быть повторён другим композитором, и в этом ценность композитора. Вы не можете нанять композитора на Хедхантере и сказать «у нас раньше Эннио Морриконе музыку писал, теперь ты продолжай писать такую же» и рассчитывать, что музыка будет не хуже.
Даже насчёт композиторов вы не правы) Профессиональный композитор может, вообще говоря, писать музыку и "как Морриконе" и "как Моцарт". Другое дело, что, возможно, ему потребуется какое-то время на изучение стиля нужного композитора.
0serg
08.11.2023 11:26+5Результат работы программиста — не уникален, он может быть повторён другим программистом
Я неоднократно видел примеры задач с которыми одни программисты справлялись а другие - нет. Некоторые задачи могут "повторить" лишь несколько десятков человек в мире. Так что с практической точки зрения повторить можно не любой результат.
Я неоднократно так же видел как один программист создавал хороший продукт который потом долго жил и всех радовал а другой программист создавал формально работающий продукт который затем доставлял сплошную головную боль. То есть даже для выполненной работы результат существенно зависит от программиста и несет отпечаток уникальности. Один-в-один повторить не удастся.
Так что я тут вижу прямую аналогию с композиторами. Если Вам надо написать музыку к фильму, то подойдет не любой композитор и у разных композиторов будет немного разная музыка. Если композитор - гений, то найти ему замену будет сложно. Точно так же и у программистов.
voldemar_d
08.11.2023 11:26+2Перед тем, как написать код, надо провести определенную работу: выбор алгоритмов, библиотек, анализ существующих решений и т.д. Это вполне творческая работа. ИМХО, конечно. Кому-то, возможно, это давно надоело. Лично мне нет.
tempick
08.11.2023 11:26Более важным (и сложным) для меня является анализ тз. Когда надо в голове (а в более сложных случаях рисовать на листочке или в draw.io) составить всю схему проекта и точно понять, возможно ли оно в принципе, что, как и с чем будет связано, Затем высыпать миллион вопросов тому кто это тз дал (в моем случае - тех.лиду). Даже элементарные - "а является ли эта штука (поле) уникальной для пользователя ибо тут в тз написано, что пользователь может добавить свой домен, но не указано, может ли быть один и тот же домен у многих пользователей, а так же может ли иметь пользователь более одного домена". Уже потом набросать простую схему, ещё более подробно подумать как это реализовать и потом уже приступать к работе.
То есть, в тз, вроде и описано всё. Но не встречал ни одного тз, когда не было бы по нему вопросов и обсуждений. Потому что кроме самого программиста, приступающего к работе над задачей, множество нюансов никто просто не увидит заранее. Да даже сам программист может с ними столкнуться уже в процессе.Так что читать эту ветку от менеджера, который считает что программист=штукатурщик - забавно)
Не исключаю, что просто всегда не везло, а других всегда чёткие внятные ТЗ, которые уже заранее разбиты на элементарные задачи, а ты просто сиди и код пиши. Но я не встречался с таким(
0serg
08.11.2023 11:26+2По моей оценке менеджеров которые занимаются чем-то нетривиальным точно так же очень мало и это в основном топовые позиции которых по объективным причинам немного :).
В мелких компаниях есть некоторый перекос, т.к. там тоже нужен свой топ менеджмент а низовых менеджеров гораздо меньше + там обычно тупо нет сложных задач которые мелкая компания реалистично могла реализовать (ей просто ресурсов на это не хватит) и соответственно нет нужды в топовых программистах. В крупных IT компаниях картинка становится гораздо однороднее. Там есть и очень интересные позиции по программированию и куча менеджеров которые занимаются рутиной.
saboteur_kiev
08.11.2023 11:26+6Но у него существенно меньше рутины и существенно большее разнообразие задач, чем у программиста.
Ой да ладно.
Постоянно на телефоне одни и те же слова (ну чуть другие после курсов типа "7 шагов к успеху", но суть та же).
Потом отчеты, бланки, кпи.
Менеджеры еще более погрязли в рутине. И как раз творческая задача менеджера это из рутины вылезти и делать что-то творческое. Но - огромная редкость.
olartamonov
08.11.2023 11:26-7Попробуйте как-нибудь месяцочек поработать менеджером. Вас может неприятно удивить тот факт, что просто механически произносить в трубку слова, когда вам, например, надо согласовать проект с тремя группами людей, у каждой из которых свои интересы, противоречащие интересам двух других групп, недостаточно.
И выстраивание устойчивых отношений между людьми — работа существенно более сложная и менее рутинная, чем написание кода (я слышал, с этим Copilot и ChatGPT с каждым днём справляются всё лучше).
Но да, зато нам и платят больше за меньшее :)
saboteur_kiev
08.11.2023 11:26+7Попробуйте как-нибудь месяцочек поработать менеджером. Вас может неприятно удивить тот факт, что просто механически произносить в трубку слова, когда вам, например, надо согласовать проект с тремя группами людей, у каждой из которых свои интересы, противоречащие интересам двух других групп, недостаточно.
Вы может быть удивитесь, но просто так писать операторы и аргументы в коде, может быть недостаточно, когда нужно согласовать работу нескольких объектов, учитывая интересы версионирования, совместимости и типизации компонентов, фреймворков, платформы и архитектуры.
И выстраивание устойчивых отношений между людьми — работа существенно более сложная и менее рутинная
Что там сложного? Даешь всем достаточную зарплату, и взрослые люди сами себе устроят устойчивые отношения.
Во время собеседования выбираешь себе взрослых адекватных людей.
В процессе работы следишь кто занимается токсичностью, делаешь выговор вплоть до увольнения.
Сложнее - в детском садике отношения выстроить.И да, опыт руководящей должности (несколько лет) имею.
voldemar_d
08.11.2023 11:26Даешь всем достаточную зарплату, и взрослые люди сами себе устроят устойчивые отношения.
Сложный момент. Бывает, что в какой-то момент (лет через 5, 10) люди начинают "выгорать", или им кажется, что зарплаты недостаточно, или что-то еще в жизни происходит. И адекватные люди начинают пороть дичь. Или устраивают итальянскую забастовку. И тогда без руководителя не обойтись.
Во время собеседования выбираешь себе взрослых адекватных людей
Это примерно такая же гарантия, как "я замуж выходила за адекватного и нормального человека, а он через 10 лет превратился в ..., лежит на диване, работать не хочет" и т.д.
Сложнее - в детском садике отношения выстроить
У взрослых людей бывают куда сильнее развиты хитрость, изворотливость и прочие отрицательные черты.
SpiderEkb
08.11.2023 11:26+1Попробуйте решить вот такую задачку:
Есть две БД по десятку таблиц в каждой. Одна БД содержит ~50млн элементов, вторая - ~500тыс элементов. Структура элементов разная, но есть ряд неких общих признаков (5-7 штук). Обе БД регулярно изменяются и после каждого изменения требуется провести поиск совпадений и обносить таблицу текущих совпадений (т.е. не просто тупо занести туда, а анализировать - для этого элемента было совпадение по таким признакам, стало по таки, для этого было по таким, сейчас нет, для того не было, но появилось).
Ресурсы ограничены - вы не можете под эту задачу выделить дополнительные вычислительные ресурсы - работаете в тех рамках, что вам дано. И да, вы не можете просто так взять и поставить туда какой-то "супермощный движок который все за вас сделает". Должны сами придумать и написать то, что будет работать должным образом.
Временное окно жестко ограничено. Допустим, не более 2-х часов (решение "в лоб" занимает 15-17 часов на имеющихся ресурсах).
voldemar_d
08.11.2023 11:26+2Выстраивание рабочих отношений между людьми - творчество?
я слышал, с этим Copilot и ChatGPT с каждым днём справляются всё лучше
Ну да, кусок индусского кода они написать могут. На основе анализа тонн другого индусского кода.
SpiderEkb
08.11.2023 11:26+5Не надо противопоставлять разработчика (а это немножко больше чем программист) и менеджера. Это совершенно разные вещи. Это даже две разных карьерных линии - экспертная (разработчик) и административная (менеджер). Все равно как сравнивать композитора и художника - кто из них более творец.
У каждого человека есть некая "превалирующая черта", которая позволяет ему достичь наилучшего результата в каком-то направлении. Есть талантливые разработчики, но никакие менеджеры. Или наоборот - талантливые менеджеры, но весьма посредственные разработчики.
Могу сказать за себя - я разработчик. У меня нет (и практически никогда не было) "рутинных задач". Каждая задача - головоломка, которую можно решить многими способами и нужно выбрать тот, который наилучшим образом подходит в данном конкретном случае. Самым быстрым в одном, потребляющем минимум ресурсов в другом, сбалансированным в третьем и т.п. Я не занимаюсь задачами где нужно просто из готовых кирпичиков что-то стандартное сделать. Просто не берусь т.к. не интересно. Только "задачки со звездочкой", где нужно подумать прежде чем писать код. Будь то работа с каим-то нестандартным железом, ковыряние в глубоких потрохах системы или обработка больших объемов данных за минимальное время.
Я знаю, что менеджера из меня не получится - просто не интересна эта деятельность. Предлагали пойти в архитекторы направления, быть ответственным за развитие. Попробовал - не мое. Много разговоров, которые ни к чему не ведут. Собрались, час проговорили, ничего не решили, отложили на не неделю. ППР (посидели, поп...дели, разошлись). Мне это кажется пустым времяпровождением.
При этом знаю людей, которым это нравится и у которых это получается. И в голову не приходит противопоставлять где больше творчества, где больше рутины. Каждый находит то, что ему по душе и там реализует себя наиболее полно.
hhba
08.11.2023 11:26Я прочитал, Олег, всю вашу переписку здесь и ниже, в целом кажется вас понимаю, и одновременно с этим меня не триггерят (как граждан ниже) темы про ОЧЕРЕДНЫЕ СТРАШНО СЛОЖНЫЕ ДРАЙВЕРА или БАЗАДАННЫХ100500КОРТЕЖЕЙ, так что я сделаю осторожное предположение, что вы на самом деле лукавите немного, или просто в разных ветках уже путаница пошла. Очевидно для составления ТЗ нужны компетенции продуктового аналитика, а также технический и менеджерский бэкграунд. А для качественного технического менеджмента - если разработка делается не "чисто по ТЗ, что бы ни вышло в итоге" - помимо компетенций менеджера требуется также и уметь пересматривать требования, и выходить снова на стейкхолдеров с альтернативными предложениями - тут опять требуется бэкграунд в аналитике и конкретных технических областях. Полагаю, что если вопрос поставить именно так, то ваши собеседники вас поймут. Сейчас же они очевидно считают, что вы просто тикеты в джире передвигаете - причем буквально "передвигаете", не задумываясь. Для этого конечно много ума не надо, и не слишком честный с собой ремесленник всегда видит в этом только "пустую болтовню" (см. ниже комментарий от несостоявшегося архитектора ПО). Но в комплексе - да, это то, что нужно, и это то, за что платят. И, да, зарплаты программистов определяются только соотношением спроса и предложения (которое неизбежно деградирует), а зарплаты вменяемых технических руководителей/аналитиков/тимлидов/техлидов принципиально ничем не ограничены, и в этой сфере никогда не будет оптимального для цивилизации соотношения спроса и предложения именно потому, что способности людей подчинены закону нормального распределения. Ремесленников же всегда будет достаточно, и дизруптивные переходы - лишь временное явление.
А этот ваш вопрос про проекты и ответственность - вы его кому задаете из ваших собеседников?)) Вас слышат сугубо как "сперва добейся", если даже вы пытаетесь вложить в свои слова филигранную иронию.
yewuv
08.11.2023 11:26+5Гм, программист вообще с естественного на машинный переводит. И в ТЗ тоже нет "тут используем такую переменную, а тут вообще массив".
А по времени вообще реализация может длиться на порядок больше, чем составление ТЗ. Ну и опять же можно так ТЗ реализовать, что заказчику это в копеечку влетит.
Так где качественная разница? В чем она заключается?
olartamonov
08.11.2023 11:26-3И в ТЗ тоже нет "тут используем такую переменную, а тут вообще массив".
Потому что в 99,9 % случаев это абсолютно несущественные детали, в которых замена одного решения на другое не влияет ни на что значимое.
Господи, да даже замена языка программирования целиком в большинстве задач ни на что видимым невооружённым глазом образом не влияет.
А по времени вообще реализация может длиться на порядок больше, чем составление ТЗ.
Может. И задача менеджера — учитывать и это тоже, стогласовывать с заказчиком, распределять нагрузку по программистам, планировать ресуры.
Так где качественная разница? В чем она заключается?
Очевидно, в «не влияет ни на что значимое» vs «заказчику это в копеечку влетит».
yewuv
08.11.2023 11:26+9Потому что в 99,9 % случаев это абсолютно несущественные детали, в которых замена одного решения на другое не влияет ни на что значимое.
Очевидно, в «не влияет ни на что значимое» vs «заказчику это в копеечку влетит».
То есть вы хотите сказать, что работа программиста не влияет практически никак? Ну что же, очень смелая мысль. Осталось только выяснить, зачем такой строгий отбор в программисты нужен.
Может. И задача менеджера — учитывать и это тоже, стогласовывать с заказчиком, распределять нагрузку по программистам, планировать ресуры.
А теперь объясните в чем творчество рассматривать диаграммы Ганта и набирать письма "разработка займет неделю, дайте стопицот денег".
olartamonov
08.11.2023 11:26-5То есть вы хотите сказать, что работа программиста не влияет практически никак?
Сейчас вы пытаетесь расширить ваше собственное «тут используем такую переменную, а тут вообще массив» на всю работу программиста задним числом.
Это либо примитивный демагогический приём, либо индикатор вашей некомпетентности, в рамках которой вы всю работу программиста искренне сводите к выбору между переменными и массивами (и, наверное, ещё структурами).
А теперь объясните в чем творчество рассматривать диаграммы Ганта и набирать письма "разработка займет неделю, дайте стопицот денег"
Проекты какого масштаба вы сами оценивали по срокам и ресурсам, лично отвечая за точность этой оценки?
yewuv
08.11.2023 11:26Сейчас вы пытаетесь расширить ваше собственное «тут используем такую переменную, а тут вообще массив» на всю работу программиста задним числом.
Гм, разве не очевидно, что это был просто пример для иллюстрации? Вроде специально максимально примитивный выбрал.
Проекты какого масштаба вы сами оценивали по срокам и ресурсам, лично отвечая за точность этой оценки?
То есть от качественных показателей (написание писем и планирование) вы все-таки решили перейти к количественному (цена ошибки)? Я правильно понял?
olartamonov
08.11.2023 11:26-5Вроде специально максимально примитивный выбрал.
То есть это был сознательно применённый примитивный демагогический приём. В расчёте на что? Что я его не замечу?
То есть от качественных показателей (написание писем и планирование) вы все-таки решили перейти к количественному (цена ошибки)?
У вас слабость к примитивным демагогическим приёмам. Теперь вы вашу собственную фразу про «набирать письма» пытаетесь приписать мне.
Но нет. Мне просто всегда интересно посмотреть, как низко люди готовы ценить работу, которой сами никогда не занимались.
yewuv
08.11.2023 11:26+2То есть это был сознательно применённый примитивный демагогический приём. В расчёте на что? Что я его не замечу?
То есть пример, показывающий схожесть работы, для вас "демагогический приём"? А как тогда с вами общаться?
У вас слабость к примитивным демагогическим приёмам. Теперь вы вашу собственную фразу про «набирать письма» пытаетесь приписать мне.
Если вы согласовываете не посредством писем, а как-то еще, почему не написали сразу? Ну и если вам не нравятся письма, давайте я перефразирую в "набирать в мессенджере", "звонить по телефону", "сообщать при личной встрече" или как хотите. На то, что вы пытаетесь сменить показатели это никак не повлияет.
saboteur_kiev
08.11.2023 11:26+3@olartamonov, знаете, судя по вашим высказываниям, вы совершенно не имеете навыков к диалогу.
Софт скиллы ужасны, понимание процессов ужасны. Даже не пытаетесь вникнуть в точку зрения собеседников.
И вы еще что-то рассказываете что "выстраивать работу" это сложная задача? Ну для токсичного менеджера наверное сложная. Для менеджера, который не способен оторваться от своих предпочтений и объективно идти к диалогу - тоже сложно.
hlogeon
08.11.2023 11:26Осталось только выяснить, зачем такой строгий отбор в программисты нужен.
Простите, а где отбирают в программисты? Куда в очередь встать?
Не удрежался)
voldemar_d
08.11.2023 11:26+1Например, при устройстве на работу. В FAANG, как вариант. Да хоть в Яндекс.
MiraclePtr
08.11.2023 11:26+2замена одного решения на другое не влияет ни на что значимое
да даже замена языка программирования целиком
Производительность и безопасность вышли из чата. А потом удивляемся, почему все адово тормозит и жрет батареи, а в софте находят CVE, вызывающие убытки на много $.
olartamonov
08.11.2023 11:26(глядя на утыканный как ёлка шариками unsafe'ами код на Rust) А безопасность и производительность, конечно, именно языком программирования и определяются. Ничем другим.
ruslan_sverchkov
08.11.2023 11:26+4В значительной степени да, вы ведь не думаете что ваш пример с раст опровергает этот тезис?)
MiraclePtr
08.11.2023 11:26+3Во многом языком, да. А ещё теми самыми "незначительными решениями", которые постоянно должен принимать разработчик в процессе написания кода.
olartamonov
08.11.2023 11:26-4Постоянно — это сколько десятков решений за рабочий день? Перечислите первые двадцать влияющих на безопасность решений, которые вы приняли сегодня.
MiraclePtr
08.11.2023 11:26+2За сегодня и вчера - около полусотни, наверное. Как раз пишу парсер пакетов для одного довольно сложного протокола и сопутствующую логику, которую они триггерят. Источник пакетов - недоверенный. На C++, поэтому любое ошибочное действие легко может привести к перезаписи памяти и последующему RCE. А на плюсах - потому что ресурсы железки очень ограничены, как раз во имя перформанса, плюс в ряде случаев вообще требуется мягкое реальное время (не уложились в установленные лимиты - не соответствуете требованиям регуляторов). Поэтому приходится принимать решения, в том числе что в соблюсти баланс между потреблением ресурсов и вероятности проблем с безопасностью.
Перечислять уж не буду, извините, это уже коммерческая тайна.
olartamonov
08.11.2023 11:26-5Сколько из этой сотни имеют уровень выше «не выходить за границы массива в цикле от 0 до N»?
olartamonov
08.11.2023 11:26-1То есть, в день вы принимаете десятки нетривиальных решений, каждое из которых непосредственно влияет на безопасность кода.
То есть, если допустить, что из этих решений правильны 95 %, то за два дня у вас в программе накапливается 50*0,05 = 2-3 ошибки, непосредственно влияющих на безопасность.
То есть, за время разработки программы (месяцы как минимум) таких ошибок накопится более сотни.
То есть, у программиста, имеющего качество принятия решений ниже вашего — а мы знаем, что качество принятия решений между людьми различается радикально — таких ошибок в программе будут сотни.
И все они непосредственно влияют на безопасность?
И где же тогда эти программы, на которые открыты сотни CVE?
ssn3
08.11.2023 11:26+1А почему Вы всё время вопросом на вопрос отвечаете? Ответьте же наконец - чего такого менеджеры "творят"?
0serg
08.11.2023 11:26+4Вас послушать так можно подумать что менеджер двадцать критически важных решений в день принимает. Двадцать решений - да. Критических? Обычно нет. Иначе по вашей же логике при 95% удачных решений остальные 5% топили бы компанию.
voldemar_d
08.11.2023 11:26+2То-то Яндекс везде, где нужна производительность, перешел на C++. Ну и сидели бы дальше на Java, в чем проблема?
Ravager
08.11.2023 11:26+5Потому что в 99,9 % случаев это абсолютно несущественные детали, в которых замена одного решения на другое не влияет ни на что значимое
Сразу видно, сложнее hello world вы ничего не писали. Это влияет на читаемость и поддерживааемость кода. И следовательно на ттм и деньги, так понятнее?
Господи, да даже замена языка программирования целиком в большинстве задач ни на что видимым невооружённым глазом образом не влияет.
Язык это инструмент, и его выбор влияет опять же на скорость разработки и нефункциональные требования типа потребление ресурсов, время ответа и т.д. что в конечном итоге может вылиться в деньги, а иногда большие когда поймется что инструмент был выбран неверный.
SpiderEkb
08.11.2023 11:26+1Это влияет на читаемость и поддерживааемость кода. И следовательно на ттм и деньги, так понятнее?
А еще это может повлиять на все - скорость выполнения, потребление ресурсов...
Не так давно был случай - требовался некий кеш данных. И вот напрашиватеся туда один тип контейнера. Очень удобный в работе, использование его компактно по коду, читаемо.
Но прогон через PEX (Performance EXplorer) на нагрузочном тестировании вызвал некоторые подозрения по поводу его эффективности в данном конкретном случае. Взял другой тип контейнера. Не так удобно в работе, чуть хуже читаемость, но... Прогон через PEX показал увеличение эффектвности на 20%.
Или вот прямо сейчас в работе задача.
У нас некий специализированный язык где можно непосредственно в код вставлять SQL А можно напрямую читать из БД (позиционируемся по индексу, читаем запись из таблицы).
Обычно стараемся так - большие по объему выборки по нескольким таблицам со сложными условиям делать на SQL, что попроще (небольшие объемы, одна-две-три таблицы...) - прямым чтением.
И вот ситуация - делается некоторая выборка (сложная), для некоторых ее элементов нужно делать дополнительную выборку внутри основной.
Основная, понятно, что на SQL. А внутренняя... Сделал на SQL - работает 50 секунд (в целом хорошо, всех устраивает). Для интереса переделал внутреннюю выборку на прямое чтение. И получилось 20 секунд общее время работы.
А вы говорите "не влияет"...
Но такие вещи интуитивно приходят только с опытом...
Язык это инструмент, и его выбор влияет опять же на скорость разработки и нефункциональные требования типа потребление ресурсов, время ответа и т.д. что в конечном итоге может вылиться в деньги, а иногда большие когда поймется что инструмент был выбран неверный.
Более того, есть специализированные языки для решения конкретного класса задач, которые радикально упрощают работу.
Вот как раз с таким работаю. Мало того, что с БД работать просто и удобно, так еще и язык поддерживает все типы данных из БД нативно. Т.е. всякие типы с фиксированной точкой (decimal, numeric, date, time...). Т.е. описал структуру записи, прочитал туда запись из БД и работай с полями структуры... Не надо никаких "классов-оберток" для типов, которых нет в языке (ну вот нет в С++ ни decimal, ни numeric, ни date, ни time на уровне языка - только через классы новые, а это время на создание объекта каждый раз...)
Так что влияет и еще как влияет...
voldemar_d
08.11.2023 11:26+1Некоторые вон до сих пор пишут на старом инструменте, а потом автоматически его в c++ переводят. Неужели потому, что "выбор языка практически ни на что не влияет"?
voldemar_d
08.11.2023 11:26+2Задачи бывают разные. Почему именно месяц, а не день и не год? Про перефразирование за миллионы рублей - Вы правда считаете, что такое в любой организации с программистами в штате на каждом шагу встречается?
mapnik
08.11.2023 11:26+1сами ничего не создают
их задачей является реализация данного им (составленного и согласованного мной :) ТЗЯ правильно понимаю, что на самом-то деле, творец — это вы, писатель ТЗ?
SpiderEkb
08.11.2023 11:26Программисты же в большинстве своём сами ничего не создают, у них просто нет простора для реального творчества — их задачей является реализация данного им (составленного и согласованного мной :) ТЗ на разработку.
По личному опыту. Есть два виде ТЗ
Требующие вдумчивой работы и хорошей квалификации разработчика, где описан вход, выход и граничные условия. Остальное разработчик уже реализует по своему усмотрению. И, тем самым, создает некий продукт. Создавая и решая (потенциально) по дороге дополнительные задачи, необходимые для наиболее эффективной реализации основной.
Прописанные до "псевдокода". Самый тяжелый случай. Наихудший результат. Потому что у постановщика нет ни необходимого опыта в разработке, ни глубокого понимания тонкостей работы платформы и инструментария. Чтобы все это было он сам должен быть постоянно практикующим разработчиком достаточно высокого уровня (по сути, а не по наличию каких-то там лычек местного разлива).
Какие ТЗ пишете Вы?
Если первые, то разработчик таки создает. Конкретное решение, наилучшим образом удовлетворяющее поставленным условиям. Более того, разные разработчики могут одну и ту же задачу решить разными способами, используя разные подходы.
Если вторые, то Вы или сами квалифицированный разработчик, но тогда все ваши утверждения более чем странны, или же, написанное по Вашим ТЗ - плохой и неэффективный код, который просто не пройдет нормального нагрузочного тестирования.
Естественно, я не говорю о "формошлепстве" и леплении некоего типового продукта из типовых кирпичиков-фреймворков. Речь о бизнес-логике в достаточно нагруженных системах с жесткими требованиями по производительности эффективности использования ресурсов.
PSZ
08.11.2023 11:26+3Не надо такие заявления делать: "Я творю и создаю", а "Вы исполняете". У тебя с софт скиллами проблемы - ты набросил на вентилятор и обидел разрабов тупо за счет формулировок (некорректно слова подобрал).
Аналогия: Архитектор, Бригадир, Бригада - кто построил дом?
Также и у тебя: Аналитик, Разработчики - кто создал систему?А ответ простой. Вы ВМЕСТЕ создаете продукт, разработчик - не просто исполнитель. Он должен понимать какие проблемы и задачи решает продукт и каков должен выйти конечный результат. Обсуждать реализацию и давать свободу выбора этой реализации разработчику (с согласованием) - разгрузит тебя (ты не должен каждую мелочь продумывать в ТЗ) и поддержит доверительные отношения.
1dmitry
08.11.2023 11:26Хороший разработчик эффективно решает тарифную задачу для доступных ресурсов платформы - CPU time, memory usage. Менеджер видит программиста, "просто пишущего код".
Хороший менеджер управляет процессами, плохой менеджер управляет другими людбми.
geher
08.11.2023 11:26+4Но и геморроя больше, потому некоторые все-таки отказываются.
olartamonov
08.11.2023 11:26-8Это вопрос квалификации. То, что для одного геморрой — для другого интересная задачка. С тем же успехом вы моггли сказать «у сеньора геморроя больше, поэтому многие миддлы от повышения отказываются».
Да нет, не отказываются, просто не доросли ещё.
И да, можно быть очень хорошим программистом, на очень высокой позиции, даже архитектором, но при этом не понимать и не ориентироваться в требованиях к задаче, выходящих за рамких чисто технических. Не такой уж редкий случай.
geher
08.11.2023 11:26+9Это вопрос квалификации. То, что для одного геморрой — для другого интересная задачка.
Вопрос не столько квалификации, сколько интересов.
Я очень даже могу руководить группой людей (проверено на практике), т.е. квалификации хватает, но мне это совсем не интересно.
А геморрой - это не про интересные задачи, а про горы неприятной рутины, которые сопровождают эти интересные (не факт для конкретного человека) задачи, а у менеджеров этой рутины как правило на порядки больше, чем у простого программиста, будь он целый сеньор. Так что даже если эти задачи кому-то все-таки покажутся интересными, то цена, которую придется заплатить за возможность ими заняться, вполне может показаться ему непомерно высокой.
olartamonov
08.11.2023 11:26-10А геморрой - это не про интересные задачи, а про горы неприятной рутины
Написание программного кода является рутиной примерно в 100 % случаев. Вы его пишете на машине Тьюринга, в рамках конкретного языка программирования (нет, ввести в него новые конструкции вы не можете), даже алгоритмы, которые вы реализуете, примерно всегда разработаны не вами, вы в лучшем случае проводите их сравнительный анализ и иногда оптимизацию применительно к конкретной технической реализации.
У менеджера в силу более широкого спектра вопросов и меньшего количества ограничений как раз доля не-рутины в работе существенно (sic!) выше, чем у программиста».
Соответственно, ваше противопоставление — оно не про объективную разницу, а про «эта рутина мне приятна, а та — неприятна».
FreeNickname
08.11.2023 11:26+4Можно я вам поклонюсь? Приобщусь к великой творческой менеджерской святыне, так сказать?
olartamonov
08.11.2023 11:26Расскажите лучше, что не рутинного вы сделали на позиции программиста за этот год.
janvarev
08.11.2023 11:26+3Влезу в разговор, хотя, наверное, поздновато )
Вот я сеньор дев, в менеджеры не рвусь. Правда, у меня есть сайд-проекты, где мне интересно что-то реализовывать для себя и немногих интересующихся. Там до черта интересного, и часто не рутинного.
А у менеджера все-таки (имхо) львиная доля времени - учитывать хотелки заказчика/бизнеса, и постоянно работать с переформулировками (которые, опять же, имхо, на содержание продукта не сильно влияют, чтобы там наверху не считали). Лично меня не привлекает; свободы самостоятельно выбирать интересные цели не хватает.
iburanguloff
08.11.2023 11:26+2А вы работали программистом? Просто интересно, что недавно человек с завода примерно так же доказывал, что работать на производстве деталей намного важнее, чем писать какой-то там код. Со стороны выглядит именно так.
Насчет тз и написания кода - если вы делаете четкое тз, где все подробно расписываете что где и как сделать - то полноценный программист вам не нужен. Вам нужен человек, который переведет человеческий язык в машинный и все. Некоторые языки за пару недель можно выучить. Ничего сложного.
Вы рассуждаете о том, в чем, как мне кажется, не особо разбираетесь. Точно так же, как я бы начал рассуждать о бесполезности заводчанина, который только и делает, что болты да гайки клепает.
Многие программисты, как и я, приходят в профессию, чтобы что-то придумывать и создаватьolartamonov
08.11.2023 11:26-4До сих иногда пишу код (эмбеддед, C), не в рамках рабочих занятий. Рутинное, скучное, однообразное занятие.
Многие программисты, как и я, приходят в профессию, чтобы что-то придумывать и создавать
Что вы придумали и создали нового? Не стомиллионную комбинацию типовых алгоритмов, именуемую «программа», а нового, чего без вас бы не было?
iburanguloff
08.11.2023 11:26+2Рутинное, скучное, однообразное занятие.
Ну значит вы не программируете, а просто код набираете
Что вы придумали и создали нового? Не стомиллионную комбинацию типовых алгоритмов, именуемую «программа», а нового, чего без вас бы не было?
Все что есть - было бы и без меня и без вас. Создавать что-то вовсе не значит делать то, что никто другой никогда бы не сделал. Но реализация будет такой, какой ее я придумал.
И нового делаю достаточно, чтобы радоваться работе и иметь желание к ней возвращаться ежедневно
Перефразирую вам ваш же вопрос:
Что вы придумали и создали нового? Не стомиллионную комбинацию типовыхалгоритмовописаний, именуемую«программа»ТЗ, а нового, чего без вас бы не было?
olartamonov
08.11.2023 11:26Все что есть - было бы и без меня и без вас
Нет, это не так. У многих вещей в этом мире есть фамилия их создателя — даже, если брать область деятельности программистов, у многих алгоритмов.
Так вы пришли в профессию, чтобы создавать — и что вы создали?
Что вы придумали и создали нового?
Ничего. Но я и не приходил в эту профессию, чтобы создавать — если бы я хотел этого, я бы остался в науке, у меня была такая возможность.
Но по крайней мере у меня сложные многоплановые неалгоритмизируемые задачи, а не простынки алгоритмического кода, которые всё лучше и лучше пишет ИИ.
ruslan_sverchkov
08.11.2023 11:26+5Что вы придумали и создали нового?
Расскажите что вы создали нового, чтобы мы могли лучше понять каково это, творить а не использовать типовые конструкции, придуманные до нас)
olartamonov
08.11.2023 11:26-3Ничего. Но я и не приходил в эту профессию, чтобы создавать — если бы я хотел этого, я бы остался в науке, у меня была такая возможность.
Но по крайней мере у меня сложные многоплановые неалгоритмизируемые задачи, а не простынки алгоритмического кода, которые всё лучше и лучше пишет ИИ.
saboteur_kiev
08.11.2023 11:26+6Что вы придумали и создали нового? Не стомиллионную комбинацию типовых алгоритмов, именуемую «программа», а нового, чего без вас бы не было?
Заносчивая аргументация уровня демагога.
А что создал нового хотя бы один композитор? Вот прям нового, а не стомиллионную комбинацию типовых нот и ритмов?
А что создал нового хотя бы один художник? Вот прям нового, а не стомиллионную комбинацию цветов и штрихов?
А что созддал нового хотя бы один писатель? Вот прям нового, а не стомиллионную комбинацию букв и знаков препинания?
Программисты создают продукт. А код это просто кирпичики из которых он состоит.
olartamonov
08.11.2023 11:26-5А что создал нового хотя бы один композитор? Вот прям нового, а не стомиллионную комбинацию типовых нот и ритмов?
Композитор создал произведение, которое не создал бы другой композитор. Художник написал картину, которую не написал бы другой художник. И так далее.
Вы не сможете быстренько нанять другого композитора, художника или писателя, чтобы он вам создал то же самое. Его такого другого просто нет.
Что создаёт программист, что не может создать другой программист, нанятый через хедхантер примерно за те же деньги?
saboteur_kiev
08.11.2023 11:26+1Вы не сможете быстренько нанять другого композитора, художника или писателя, чтобы он вам создал то же самое
А зачем мне создавать тоже самое, снова эта рутина?
Мне нужно не тоже самое, а то, что я хочу.
Например хочу простенькую мелодию на фон для игры. Чтобы не напрягала, чтобы была ритмичная, чтобы была воинственная. Сейчас с этим AI справится. Где же творчество, если даже AI может?
olartamonov
08.11.2023 11:26Это не рутина. Это уникальный стиль композитора (художника, писателя), за который вы его и цените.
Вы не будете слушать «простенькую мелодию на фон» ради самой музыки. Простенькая мелодия на фон — дешёвый низкокачественный продукт, который автор игры использует потому, что ничто более дорогое просто не сможет окупить.
Вы ждёте не любую музыку, а музыку любимых вами групп.
Точно так же вы не будете читать ChatGPT-сгенерированные книги (статьи про такие есть на Хабре, я не заметил в комментариях бурного восторга).
Вы ждёте не любую книгу, а книгу любимого вами писателя.
В какой из программ, которыми вы пользовались за последний месяц, вы видели уникальный стиль автора? Какие из пока не написанных программ этого автора вы с нетерпением ожидаете?
Вообще, вы зря защищаете такую великую ценность программирования. Программирование — это обычное ремесло, но в том нет ничего плохого, этот мир по большей части состоит из ремесленников.
ssj100
08.11.2023 11:26+4Вот прям нового, а не стомиллионную комбинацию типовых нот и ритмов?
а ведь нот всего лишь 7... а атомов 129
Да каждый программист создает новое оттачивая то что есть смешивая, какие-то конструкции живут дольше какието развиваются и копируются
Stan88
08.11.2023 11:26+5А Вы попробуйте что то сложнее ардуино и светодиода - сразу появится куча творческих задач. Разных, не повторяющихся!) К примеру на каком-то SoC поднимите ядро линуха на первом процессоре с драйверами, которые вы адаптировали и написали для вашего устройства, а на втором проце какую-нибудь РТОС. Организуйте коммуникацию между ними, разделение ресурсов. Напишите либы для обоих частей и не забудьте про ГУИ на Qt для тач дисплея - что бы сторонним разработчикам сразу и наглядно было видно как все работает. Оптимизируйте решение - вам ведь надо в риал тайм уложится с обоих сторон. Добавьте дебаг консоли для вывода всей информации с каждого проца. Составьте документацию описывающую ваш алгоритм, протоколы, разделение ресурсов. Опишите какие хард аппаратными проблемами вы столкнулись и как это обошли - ибо продукт новый и что сам чип, что СДК полны ньюансов - нигде ранее не описанных. И это будет все будет лишь одна единственная задача из проекта) Заскучаете - пишите, я Вам позавидую)
SpiderEkb
08.11.2023 11:26+2Да можно проще - вам дают задачу на... Ну что-то там в БД проверить - есть совпадения, нет совпадений. Вы радостно пишете SQL запрос, а вам говорят - "родной, твой запрос на проме работает 3 секунды (там реально сложно все - данных много, не самая удачная реализация БД...), а у нас требования чтобы укладывалось не более чем в 300мсек (дальше уже сервис, который ждет результата, отваливается по таймауту".
И вот начинаешь ежиков рожать... В результате получаешь 150-200мсек :-) Но это же подумать надо, придумать как...
nivorbud
08.11.2023 11:26Да и сАрдуино творчества может быть дофига и больше. Например, входной сигнал надо проинтегрировать, а ресурсов слабенького микроконтроллера не хватает. Что делать? Задача в лоб не решается. И надо искать нетривиальные решения - например вынести интегрирование из программной части в аналоговую - поставить на входе АЦП аналоговый интегратор на операционном усилителе.
voldemar_d
08.11.2023 11:26+1работать на производстве деталей намного важнее, чем писать какой-то там код
Он вручную детали на станке вытачивает, интересно? Или таки нажимает кнопку "Старт" на ЧПУ? И при этом не знает, что внутри программа работает? :-)
igorp1024
08.11.2023 11:26+4Я вот бегло пролистал Ваши аргументы и заминусованные комментарии. И понял следующее: Вы просто менеджер (это не плохо) и видите красоту созидания в Вашей сфере. Просто поверьте на слово, у программистов даже при наличии ТЗ есть определённая свобода, в рамках которой у них тоже получается созидать и видеть красоту результатов своей работы.
И если бы всё было настолько рутинно в работе программистов, то нейросети давно бы их заменили, т.к., рутина - это их конёк.UPD: Но да, на embedded-разработке это сложнее ощутить, конечно. Я про радость в условиях современных меняющихся требований в процессе разработки.
geher
08.11.2023 11:26+5Написание программного кода является рутиной примерно в 100 % случаев. Вы его пишете на машине Тьюринга, в рамках конкретного языка программирования (нет, ввести в него новые конструкции вы не можете), даже алгоритмы, которые вы реализуете, примерно всегда разработаны не вами, вы в лучшем случае проводите их сравнительный анализ и иногда оптимизацию применительно к конкретной технической реализации.
Тогда в вашем наборе терминов я не программист (зотя я сам и все вокруг думают иначе). Особенно про алгоритмы повеселило.
А художник по вашему не творит (рисует на одном и том же холсте одними и теми же красками одни и те же вещи, рожи заказчиков, например). И чего потом его мазню в музеях выставляют и творчеством называют?
Соответственно, ваше противопоставление — оно не про объективную разницу, а про «эта рутина мне приятна, а та — неприятна».
Мне любая рутина неприятна. А у менеджера ее реально объективно больше.
olartamonov
08.11.2023 11:26-8Мне любая рутина неприятна.
Так и что не рутинного вы написали за этот год?
Тогда в вашем наборе терминов я не программист
Программист — техническая профессия, ей в ПТУ учат.
geher
08.11.2023 11:26Программист — техническая профессия, ей в ПТУ учат.
Программист - это слишком широкое понятие. Кого только программистами не называли. Даже тех, кто просто вбивает чужую программу в ЭВМ.
В одной из систем определений те, кого "учат в ПТУ", это вообще не программисты, а всего лишь "кодеры". Программисты - это уже более широкий спектр обязанностей.
Хотя все это уже крайности.
olartamonov
08.11.2023 11:26+2ФГОС 09.02.03 «Программирование в компьютерных системах» процентов девяносто «спектра обязанностей» описывает.
geher
08.11.2023 11:26Если опираться на всю эту бюракратию, то я точно не программист. По образованию математик (хотя специализация, каюсь, - таки системное пронраммирование, но в качестве квалификации в дипломе значится именно математик), работаю инженером (просто инженером, без расшифровки, в смысле не инженером-программистом, не инженером-технологом, какие там еще инженеры бывают). Но работа моя заключается именно в создании программ для ЭВМ (компьютеров).
hlogeon
08.11.2023 11:26+2Я даже ПТУ не закончил. Я даже не кодер получается? Так, обезьяна перед компом?))
geher
08.11.2023 11:26+1Ну зачем сразу так грубо. Просто есть разные системы классификации.
В одной из систем определений, опирающейся на образование для классификации, вы не программист и не кодер.
Лучший программист, которого я лично знал, тоже не имел профильного образования. И в другой системе определений он вполне является программистом.
А вот мне тут в обсуждении уже разъяснили, что я совсем не программист.
ruslan_sverchkov
08.11.2023 11:26+7Ну в таком случае менеджерам даже пту не нужно, они из кассиров вырастают) у вас нерепрезентативная выборка
olartamonov
08.11.2023 11:26Ок, что именно из computer science требуется в работе типовому программисту?
ruslan_sverchkov
08.11.2023 11:26+2я не знаю что такое типовой программист в вашем понимании (хотя если судить по той вилке зп, про которую вы писали ниже - это что-то не очень квалифицированное). Если хотите могу ответить про себя, но пример опять будет нерепрезентативным. Если вы действительно хотите до кого-то здесь донести свое мнение, то будет намного более продуктивным ответить на те вопросы которые я вам задал выше - описать творческую составляющую своей работы. п.с. если что, я против менеджеров ничего не имею, а хороших и вовсе люблю)
olartamonov
08.11.2023 11:26-2Откройте вакансии, посмотрите, кого там много, расскажите, какими разделами computer science они пользуются. Ну, например, про то, какой процент программистов разрабатывает криптографические алгоритмы (это CS), а не просто подключает готовую библиотечку (это ФГОС).
А то некрасиво получается: вы утверждаете, что профессия программиста не описывается ФГОСом, но обосновать это отказываетесь.
FreeNickname
08.11.2023 11:26+4Про разработку криптографических алгоритмов особенно повеселило, учитывая, что не разрабатывать свои алгоритмы (и даже не использовать свои реализации существующих алгоритмов) – это первое, что вдалбливают в курсе криптографии :)
olartamonov
08.11.2023 11:26-3Это не курс криптографии, это курс программирования. На курсе криптографии учат их разрабатывать (внезапно, вы не поверите, в мире ежемесячно появляется много новых работ по криптографическим алгоритмам, в том числе и новым, из чего можно сделать, что кто-то их таки разарабывает).
А программист действительно разрабатывать криптографические протоколы не должен, у него для этого квалификация недостаточна.
geher
08.11.2023 11:26А программист действительно разрабатывать криптографические протоколы не должен, у него для этого квалификация недостаточна.
Все проще. Для разработки криптопротокола нужна соответствующая квалификация. А обладает ли этой квалификацией программист или кто еще - дело десятое.
FreeNickname
08.11.2023 11:26Сколько курсов криптографии вы прослушали?) Я – несколько. Там действительно учат тому, как алгоритмы составляются, как они работают. Каким требованиям должен удовлетворять криптографический алгоритм и т.д. Но только при этом на каждом занятии долбят, что надо использовать готовые реализации и не заниматься самодеятельностью. И, в целом, понимаешь, почему, когда тебе рассказывают про векторы атаки в духе анализа энергопотребления блока питания :)
FreeNickname
08.11.2023 11:26+8А, я понял) На самом деле криптографические алгоритмы создаёт криптографический менеджер :)
geher
08.11.2023 11:26Ну кто-то должен разрабатывать новые криптоалгоритмы и их реализации. Другой вопрос, что это не "на коленке склепать", а требует определенных знаний, определенного уровня квалификации и выполнения некоторого набора правил (вроде обязательной проверки алгоритма и реализации на вшивость другими специалистами).
voldemar_d
08.11.2023 11:26+1ВУЗы, где преподают дисциплины, связанные с программированием, не нужны? Ну, раз в ПТУ уже всему учат.
nivorbud
08.11.2023 11:26+3А вот закон приравнивает программу к литературному произведению, т.е. однозначно трактует программу как творческое произведение.
Offensive
08.11.2023 11:26Числа вроде 99% и 100% слишком жёсткие приводишь, не так уж мало не программистов и уж тем более программистов которые способны и во флешке чё-то подпаять и ОС себе ребилднуть (приветь *NIX)
Insurgent2018
08.11.2023 11:26+2Глупости, дело навыков знания и кругозора, софт скилов. Работа менеджера такая же рутина, одни и теже паттерны. Особенно после лет 5 работы с людьми. А после 14 лет такой круговерти, работы с людьми, сложными ситуациями, уже не хочется ни подстраиваться, ни придумывать. Все одно и тоже. Людей считываешь за 5 минут разговора. Не интересно.
Ravager
08.11.2023 11:26+5там дай бог 10% прибавки дают, а геморроя на все 200%. особенно в текущих реалиях рынка, который я отсмотрел за 4 месяца поиска работы. часто на лида сваливается еще и работа проджекта и аналитика а иногда и продакта на пол-шишечки. в целом работа интереснее, но спустя 3+ года я понял что лучше получать чуть меньше а оставшееся время и нервы потратить на свой проект.
p.s. работодателю эта должность беспорна очень выгодна.
olartamonov
08.11.2023 11:26-6А вы уверены, что это «там дай бог», а не что ваш уровень квалификации в этом качестве таков, что больше 10 % он не стоит?..
Мне вот почему-то не приходится работать ни проджектом, ни аналитиком, ни продактом. И вакансии, где от меня ещё и на баяне немного играть требуется, дальше этого требования не читаю.
geher
08.11.2023 11:26+3Проблема в том, что в описании вакансии всего этого может не быть, но когда уже впряжешься, незаметно навалят дополнительных задач, и окажешься обвешан ими как новогодняя елка игрушками.
Впрочем, это и у простого программиста достаточно часто бывает, не только у лида, да и бежать оттуда надо. Но это совсем другая история (могут быть серьезные причины, заставляющие смириться, но это еще более другая история).
olartamonov
08.11.2023 11:26Учитесь говорить слово «нет».
geher
08.11.2023 11:26Слово-то завсегда брякнуть можно. Просто нужно понимать последствия этого. А они могут быть намного хуже, чем если не сказать.
olartamonov
08.11.2023 11:26Вы откажетесь выполнять работу, не предусмотренную вашими должностными обязанностями, работодатель начнёт угрожать вам увольнением по его инициативе, вы укажете на незаконность такого увольнения и ваше последующее обращение в суд, в итоге сойдётесь на устраивающем обе стороны размере парашюта и увольнении по соглашению сторон.
Что тут может быть хуже? Вас к батарее отопления в офисе прикуют?
geher
08.11.2023 11:26+4Вот даже описанный вами геморрой с судом может оказаться хуже необходимлсти выполнять дополнительную работу. А этим возможные неприятности не исчерпываются. Конечно, если для вас судебная процедура ничего не стоит, или даже приносит удовольствие, это другой вопрос.
olartamonov
08.11.2023 11:26-1«Я свои права отстаивать не хочу, я хочу, чтобы другие магическим образом перестали их нарушать» — заведомо неработающая позиция.
geher
08.11.2023 11:26+6Всегда есть цена вопроса и готовность ее платить. Есть баланс между затратами на борьбу за права (не всегда только денежными и временными) и ее положительными результатами.
Конечно, можно подавать в суд каждый раз, когда вас толкнут в транспорте (тоже ведь нарушенные права), но это будет совсем крайность. А так случаи бывают разные. В одних лучше (опять же, лучше для конкретного человека в конкретной ситуации) подать в суд, в других лучше потерпеть (причем иногда дождаться другой жизненной ситуации и таки подать в суд, но не всегда оно так). Жизнь, к сожалению не столь проста и однозначна, как хочется.
olartamonov
08.11.2023 11:26-2Есть, это факт.
Но называть «проблемой» то, что вам просто не карману — это инфантилизм. Ребёнок рыдает, если ему не достаётся игрушка. Взрослый человек или зарабатывает на игрушку, или живёт без неё — потому что понимает, что никто ему в ответ на рыдания игрушку не даст.
Впрочем, можно отнести эти жалобы к психотерапевтическому выговариванию.
geher
08.11.2023 11:26+1Но называть «проблемой» то, что вам просто не карману — это инфантилизм.
Проблема - это не обязательно что-то страшное. В этом слове нет ничего запредельного. Это всего лишь нечто не устраивающее, которое хочется исправить.
Есть проблемы решапмые, есть нерешаемые, есть те, очевидные решения которых не устраивают или по каким-либо причинам недоступны.
Если ребенок из вашего примера не получил игрушку, для него это таки проблема (в отличие от окружающих, у них могут быть другие проблемы, косвенно связанные с этой) , которую он (сознательно или несознательно) может попытаться решить через плач. Может сработать и разрешить проблему, а может не сработать. Других рычагов воздействия у него нет. Но есть и альтернативное решение - отложить решение, а там либо оно само решится, либо будет еще момент поплакать, либо оно просто забудется и перестанет быть проблемой.
У взрослых, внезапно, все то же самое, только больше сознательности в выборе решений или отказа от решения.
nivorbud
08.11.2023 11:26+1И куда потом пойдете устраиваться с таким бэкграундом сутяжничества?
По мне всё намного проще: не сошлись с работодателем - мирно разбежались, и не компостируем друг другу мзг.
p07a1330
08.11.2023 11:2690% своей карьеры работаю самозанятым
По причинам расставания с предыдущим "работодателем" никто справки особо не наводил
Ravager
08.11.2023 11:26+3А вы уверены, что это «там дай бог», а не что ваш уровень квалификации в этом качестве таков, что больше 10 % он не стоит?
стандартная демагогия работодателя... а вы уверены что работодателю есть разница нанимать лида среднего уровня и высокого, если он сам порой не понимает разницы? либо он ее понимает но сознательно размазывает ответственность в принятии решений между несколькими людьми, чтобы как раз уменьшить вероятность ошибки и потому снизить критерии к управленцу.
да и будем честны, выхлоп от хорошего лида намного меньше выхлопа от хорошего CTO, потому что лид это дно менеджерской цепочки и его решения в масштабе компании слишком малы чтобы как-то сильно влиять.
И вакансии, где от меня ещё и на баяне немного играть требуется, дальше этого требования не читаю.
ну во-первых не все об этом с порога пишут. а во-вторых сейчас много кто это практикует, потому что это выгодно. почитайте например роадмап тимлида от авито. фактически весь бигтех сейчас так устроен: есть PO, команда и лид. да есть всякие дискавери треки, там есть аналитик но только бизнесовый. системную аналитику и архитектуру делает лид и команда. проджектов тоже нет. процессы лежат на лиде. вы думаете я почему ходил 4 месяца по рынку
olartamonov
08.11.2023 11:26-4стандартная демагогия работодателя...
Замечу, что о 10 % вы писали не на основании исследования рынка (где у типового программиста 200-300 тысяч сейчас оклад, у менеджера легко может быть и 500+), а на основании вашего личного опыта.
Ну то есть корректно это формулируется как «лично мне и в местах, где я работаю, больше 10 % надбавки не предлагают». Что может говорить не столько о рынке, сколько о вас и местах, где вы работаете.
ну во-первых не все об этом с порога пишут. а во-вторых сейчас много кто это практикует, потому что это выгодно
Увольняться пробовали? Я пробовал, мне понравилось, парашют достойный.
Ravager
08.11.2023 11:26+1Я вижу вы поисследовали рынок и исправили свой пост. Мне есть что вам ответить.
Большинство компаний предпочитают растить менеджера технического изнутри а не брать снаружи. Поэтому вы никогда не поймёте на основании статистики - это просто разные бакеты из разных компаний. А я вот на основании своего опыта работы в нескольких компаниях могу сказать какие там надбавки, ибо вилки видел в рамках одной компании. Обычно лид получает +10%, что в масштабе 400к за сеньора выливается в 450 за Лида. И это нормально, потому что он не делает ничего уникального. Все ребята довольно скилловые и самостоятельные. Конечно если компания рога и копыта и там студенты по объявлению то разница может быть больше но это именно что исключение.
dprotopopov
08.11.2023 11:26+2Обычно специалистов, совмещающих в себе эти наборы качеств, руководство со временем пытается двигать на всякие менеджерские должности, дабы человек мог и контролировать непосредственно технарей, разговаривать с ними на одном языке, отслеживать их прогресс, и отчитываться начальству, переводя всё уже им.
а оно мне нада?
по факту такие люди через пару лет оказываются у разбитого корыта - братаном топ-менеджеров/владельцев бизнеса ему не стать (практически) никогда, а навыки программирования на современном стеке за пару лет менеджерской работы довольно сильно протухают ...
EllisonHR Автор
08.11.2023 11:26+3Я не согласна, что харды и софты противоречат друг другу. Софты - это не обязательно про экстраверсию, это и про внимание к деталям, умение доносить мысль, работать в команде и т.д. К каждой вакансии нужны определенные навыки, и опытные HR это знают. Условно, если в команду не требуется экстраверт, то и на собеседовании мы не станем смотреть на уровень общительности
Ivan22
08.11.2023 11:26+3Вот интересно, а как вы оцениваете ну конкретно "внимание к деталям" ??? Опишите с примерами
voldemar_d
08.11.2023 11:26+10Вопрос был не ко мне, но вставлю немного. Самое простое: допустим, дали программисту задание реализовать что-то, а потом оказывается, что он реализовал то, что сам придумал, а не то, что от него просили. Хорошо, если он на замечания реагирует нормально и переделает, как надо. Но даже в таком случае из-за невнимательности и нежелания вникать в детали он, как минимум, потратит лишнее время на разработку (которое, как известно, выливается в деньги).
Другой вариант: быстро накидал какой-то код, но покрыть тестами забыл или поленился. В результате потом баги вылавливаются в 10 раз дольше, чем он код писал. Или, например, не вник как следует в детали, и оказалось, что в коде предусмотрел не 100% покрытия случаев, которые нужно покрыть, а в разы меньше.
Чтобы не допускать таких ошибок, надо общаться, переспрашивать, уточнять детали и т.д. Code review тоже никто не отменял. Бывают компании, в которых без code review минимум парой других человек не разрешается коммитить изменение кода.
Я читал даже про такую вещь. Не совсем относится к soft skills, но к вниканию в детали точно. Не секрет, что на данном ресурсе определенная часть и писателей, и читателей не вникают в правила русского языка. Некоторые чуть ли не гордятся тем, что "у меня в школе тройка по русскому была, но мне это не мешает быть крутым программистом". Так вот, натыкался я когда-то на исповедь одного руководителя компании, в подчинении которого было много программистов (если правильно помню, сотни). В какой-то момент он стал замечать четкую тенденцию: те программисты, которые не допускали или почти не допускали ошибок в письменном русском языке, и код выдавали более тщательно продуманный, грамотно написанный и т.д. Те же, у кого было много ошибок в русском языке, и код выдавали в духе "и так сойдет".
Умение четко и, главное, понятно для других формулировать свои мысли - с этим вообще бывает сложно. Иногда приходится сталкиваюсь с тем, что взрослые люди с высшим образованием этого делать не умеют. Я в последние годы уже не удивляюсь тому, что в переписке приходится сокращать количество вопросов до одного, ответ на который "да" или "нет". Да и на такой вопрос иногда не всегда удается ответ получить. Все эти, казалось бы, мелочи, тормозят рабочий процесс, а иногда и серьезно его усложняют.
Вот и не очевидно, так ли уж однозначно хорош интроверт, которому утром начальник дает задание, а вечером тот выдает результат с одним словом "вот".
Поэтому, на вопрос "Как вы оцениваете внимание к деталям" мне тоже интересно было бы ответ увидеть.
Ivan22
08.11.2023 11:26+5да, мне интересно как это оценивает HR, за 10 минут, по телефону. А так-то конечно внимательность к деталям проявляется на проекте через пару-тройку месяцев работы, само собой
Offensive
08.11.2023 11:26Тем более внимательность к деталям может быть нестабильной у нестабильного человека)...
nivorbud
08.11.2023 11:26Это сделать весьма просто. Покрытие тестами и подобное здесь не нужно. Достаточно дать простейшую задачку с противоречивым условием, например с какой-нибудь двусмысленной деталью. Опытный спец должен сразу на эту противоречивость указать.
monte1977
08.11.2023 11:26Мои 5 копеек по поводу внимания к деталям. Любое задание, что вам дают кто-то написал и значит в первую очередь от вас будут ожидать такого исполнения, как ожидает тот конкретный человек или команда.
Внимание к деталям это часть работы определённого уровня и опыта. Когда вы в практически автономном режиме умеете в лёгкой беседе / переписке получить интересующие вас данные. Отложить и использовать по теме все возможные социальные сигналы дополнит при этом недостающую картину.
Работа 1:1 с шефом это самая сложная среда, если он конечно не на одной волне с тобой. Но из моих заметок и опыта могу сказать, что часто вокруг даже работы 1:1 в нормальной живой фирме, не удаленке, деталей часто дрстаточно.
nivorbud
08.11.2023 11:26Любое задание, что вам дают кто-то написал и значит в первую очередь от вас будут ожидать такого исполнения, как ожидает тот конкретный человек или команда.
Не факт, что написанное на бумаге соответствует ожиданиям написавшего.
tommyangelo27
08.11.2023 11:26допустим, дали программисту задание реализовать что-то, а потом оказывается, что он реализовал то, что сам придумал, а не то, что от него просили.
Оно ж и наоборот может быть. Сделал, что ровно то, что просили, а потом оказалось, что в постановке задачи была ошибка. Но он всё равно продолжил делать, потому что "Не моя ответственность" ????
voldemar_d
08.11.2023 11:26Да много чего может быть. Для того и нужно общаться. Если сделал часть работы и увидел, что она идёт куда-то не туда - спроси руководителя, что делать.
olartamonov
08.11.2023 11:26+5Классика с гугловского (кажется) собеседования же:
— Нарисуйте домик.
— (рисует)
— До свидания, вы нам не подходите: вы должны были уточнить, какой домик и для кого. Это должен был быть домик для слепого жирафа.
AzatJ
08.11.2023 11:26+7Никогда не понимал смысла таких вопросов на собеседовании, если компания занимается недвижимостью для слепых жирафов, и человеку говорят "Нарисуйте домик", нормальный работник нарисует домик для слепого жирафа.
А они хотят нанять человека, который соберет 20 митингов, где будет уточнять для слона нужен домик или для жирафа?olartamonov
08.11.2023 11:26если компания занимается недвижимостью для слепых жирафов, и человеку говорят "Нарисуйте домик", нормальный работник нарисует домик для слепого жирафа.
Нет, нормальный уточнит задачу. Вторичка, первичка, ИЖС, котлован, арктическая ипотека, жилмассив в 34 этажа или клубное в три этажа, и прочее, и прочее.
А получив откровенно* неполную задачу, бежать быстрее делать первое пришедшее в голову — это трата рабочего времени и, соответственно, денег работодателя.
* — не ведём речь об условиях, явно выходящих за пределы компетенции программиста, типа законодательных ограничений. Но понимание существования множества разных непохожих друг на друга домов, а также факта, что заказчику обычно нужен не любой дом, у него должно быть, это общие знания.
AzatJ
08.11.2023 11:26+6Такие вопросы надо ПМам задавать, и опытный ПМ уже знает, что если в тикете написано: "нарисуй домик", разработчик нарисует так, как представляется ему наиболее правильным.
И если ПМ написал просто тикет: "нарисуй домик", такой тикет просто не должен пройти.Если же в тикете будет написано: "Поскольку мы заметили, что в Арктике в последнее время недостаток домов для слепых жирафов, надо нарисовать домик
- жилмассив в 20 этажей
- возле дома маленький ледовый парк.". И вопросов ни у кого не будет, а все технические детали разработчик знает и самolartamonov
08.11.2023 11:26-6и опытный ПМ уже знает, что если в тикете написано: "нарисуй домик", разработчик нарисует так, как представляется ему наиболее правильным
Это плохой работник. Не спорю, таких среди программистов сильно больше половины, приходится работать с тем, что есть.
Хороший, если видит несколько вариантов решения задачи, которые не эквивалентны, подходит к ПМ и уточняет.
Но среди программистов таких меньшинство, факт.
AzatJ
08.11.2023 11:26+2Я бы сказал это не плохой работник, а джун. Джун прибегает постоянно с уточняющими вопросами, а более опытный человек делает сам в силу своей экспертизы.
Когда я даю задачу, особенно объемную, я хочу чтобы разработчик сам додумал все детали, проанализировал и выбрал наилучший вариант в силу своего опыта и экспертизы. А уточнять каждую деталь - это какой-то микроменеджментolartamonov
08.11.2023 11:26-1А какой вариант в случае домика наилучший — ИЖС, вторичка, первичка, 34-этажный или клубный?
Ответ обоснуйте.
AzatJ
08.11.2023 11:26Если написано 20этажный, будет 20 этажный. Если не написано, тикет на доработку. И опытный программист будет рисовать такой дом, который можно быстро расширить/изменить под новые правила
Rorg
08.11.2023 11:26+4А какой вариант в случае домика наилучший — ИЖС, вторичка, первичка, 34-этажный или клубный?
Вы знаете, если не указано какой конкретно, то любой, который соответствует остальным требованиям.
А вообще мне кажется задание из категории "нарисуй домик" не имеет правильного ответа. Начнешь задавать кучу уточняющих вопросов, получишь отказ "кандидат безинициативный и не умеет принимать решений". А нарисуешь просто домик – "кандидат проявил излишнюю инициативность и не стал задавать вопросы". И как понять в какую именно "игру" сейчас "играет" рекрутер?
olartamonov
08.11.2023 11:26-2И как понять в какую именно "игру" сейчас "играет" рекрутер?
Проявив свои коммуникативные навыки и понимание человеческой психологии?..
Сложно?
А менеджер этим занимается каждый день.
dkuzminov
08.11.2023 11:26А что, ПМ знает? Как правило, двусмысленность тянется от заказчика через менеджера, на каждом этапе только увеличиваясь. А хороший инженер (каких мало) должен задаваться вопросом ЗАЧЕМ, то есть видеть, какую проблему решаем, и что является ее решением.
olartamonov
08.11.2023 11:26Если ПМ не знает, он идёт уточнять дальше по вертикали.
AzatJ
08.11.2023 11:26Отлично, и срок на проект "рисунок дома", вместо одного дня растягивается на два месяца
olartamonov
08.11.2023 11:26+2Ещё очень полезно уметь не пытаться решать проблемы, не входящие в вашу сферу компетенции.
Если вы программист — не надо мыть в офисе полы, готовить отчёты в налоговую и планировать сроки проектов.
dkuzminov
08.11.2023 11:26+2Как правило, менеджер хочет, чтобы его снизу не беспокоили и присылали лишь отчеты о выполененной работе. Желание все сделать правильно быстро настроит всех против вас.
0serg
08.11.2023 11:26+5Это плохой работник. Не спорю, таких среди программистов сильно больше половины, приходится работать с тем, что есть.
Забавно: у вас с одной стороны задача менеджера - это сделать внятное ТЗ для программиста, а с другой - если программист неправильно понял ТЗ то это плохой программист ибо уточнение и составление правильного ТЗ - это задача программиста. Это простите взаимоисключающие вещи. Если Ваш программист получает неполное ТЗ которое он вынужден уточнять и от результатов уточнения критично зависит результат, то он занимается творчеством а его менеджер прохалявил.
Вдвойне забавно то что выше вы утверждали что программиста можно заменить без ущерба для результатов работы. В рамках подобного подхода плохих программистов вообще быть не должно - как вы сформулировали, у них отличается лишь скорость решения. Менеджер ж сформулирует ТЗ, остается только его реализовать. А как дошло до реалистичной проблемы - так сразу программисты поделились на "плохих" и "хороших", причем чсх "хорошие" это те которые за менеджера выполняют ту работу с которой он не справился.
iburanguloff
08.11.2023 11:26+5Нет, нормальный уточнит задачу
Если в голове менеджера была мысль "нужно нарисовать домик для слепых жирафов", а он написал "нарисуй домик", а потом удивляется что получил домик не для слепых жирафов, то менеджер странный.
Нормальный менеджер должен в рамках своих компетенций в задаче указывать как минимум все ключевые моменты задачи.
Человек решающий задачу головой предполагает, что и задачу ставит человек, который пользуется головой. Если все переложить на голову решающего, то можно задавать бесконечно вопросы о цвете, форме, размере, материале дома и т.п.olartamonov
08.11.2023 11:26-5это не я плохо сделал, это мне задачу неправильно поставили
у меня на компьютере всё работает
тут надо на другую библиотеку переходить
И ещё 998 типовых отмазок плохих программистов.
Если все переложить на голову решающего, то можно задавать бесконечно вопросы о цвете, форме, размере, материале дома и т.п.
Не можно, а нужно. Потому что если вы, не обладая компетенциями и информацией о выборе цвета, выбрали голубой, потому что он вам нравится, виноваты в этом будете вы и только вы.
И понимание границ своих компетенций является базовым навыком любого минимально грамотного работника в любой области.
Которым вы, например, не обладаете.
iburanguloff
08.11.2023 11:26+8Пример: нужна синяя кнопка с тенями. Менеджер ставит задачу - сделать кнопку. Программист возвращается за уточнениями - какой текст, где расположить, нужны ли закругления, что делать при наведении, что делать при нажатии и т.п. Кнопка появляется, но теней нет. И виноват программист, потому что среди сотен вопросов не было вопроса о тенях. Тени ведь в рамках компетенций программиста, а он среди 10 тысяч других вопросов потерял вопрос о них. По такой логике абсолютно всегда виноватым окажется он.
А менеджеру и в голову не придет, что можно было просто указать в задаче, что нужны тени и не нужно было бы тратить часы на бессмысленные вопросы и нерешенную в итоге задачу.
Проверять чужие компетенции конечно классно, но в первую очередь лучше бы проверять свои?
Я руковожу несколькими разработчиками и многие из них плохо пишут код, но мне бы и в голову не пришло ставить задачу так, чтобы ко мне потом возвращались за уточнениямиolartamonov
08.11.2023 11:26-8Вы описываете программиста, который, занимаясь кнопками, явно не имеет понятия, что такое design guide, не имеет даже базовых навыков коммуникации и не умеет расставлять приоритеты, просто бессистемно засыпая окружающих вопросами.
Я не спорю, что это реалистичное описание, но вам самому не кажется, что оно крайне унизительное? Это же характеристика человека с IQ где-то ниже 100.
iburanguloff
08.11.2023 11:26+5Мне кажется, что если IQ человека выше 100, то при постановке задачи рисования домика для слепых жирафов он напишет "нужно нарисовать домик для слепых жирафов", а не "нарисовать домик". Ну или укажет, что его IQ ниже 100, чтобы решающий задачу понял, что лучше уточнить для кого этот домик.
Я вас понимаю и во многом согласен, но в нерешенной задаче виноват не только программист
olartamonov
08.11.2023 11:26-2Задача рекрутера — не продемонстрировать программисту свой IQ, а оценить IQ этого программиста.
Если со стороны программиста начинается «это вы неправильно задачу поставили, а что, я вам десять тысяч вопросов задавать должен» — ок, замечательно, мы только что сильно сэкономили рабочее время рекрутера, всё собеседование не заняло и десяти минут.
И да, в реальной жизни и работе всегда будут встречаться нечётко/неполно поставленные задачи.
selkwind
08.11.2023 11:26а потом удивляется что получил домик не для слепых жирафов, то менеджер странный.
Менеджер не странный, он просто хочет видеть рядом с собой тех, с кем будет понимание с полуслова и намека, т.е. то, что в английском описывается как to be on the same page. Потому как пинг-понг с вопросами/ответами реализацию и сдачу проекта приближает сильно медленнее, чем с теми, кто может действовать по первому варианту.
vvbob
08.11.2023 11:26+1Менеджер очень странный, он точно работника ищет или жену (мужа)?
Видимо такие менеджеры потом и ругают тупых разработчиков, которые "не понимают очевидного". Люди телепатическими способностями не обладают, а в любой задаче бывает такая масса разных ньюансов, что шанс получения нужного результата, при задаче поставленной "с полуслова" стремиться к нулю. Как по мне, очевидно что ключевые требования должны быть описаны при постановке задачи, иначе это кто угодно, но не постановщик и не менеджер, и начерта нужен такой лишний элемент в цепочке между разработчиком и пользователем, если он не может и не хочет ставить задачи адекватно? Тогда проще разработчику самому с пользователем общаться и разбираться что ему нужно, без испорченного телефона в виде менеджера ожидающего "понимания с полуслова".
evadesad
08.11.2023 11:26To be on the same page - это скорее, что мы с вами обладаем одинаковыми апдейтами по текущей ситуации, что мы статус задачи и предстоящие действия понимаем одинаково. Это необязательно достигается с полуслова.
А чтобы с полуслова - это same vibe какой-нибудь
JBird
08.11.2023 11:26нормальный уточнит задачу. Вторичка, первичка, ИЖС, котлован, арктическая ипотека, жилмассив в 34 этажа или клубное в три этажа, и прочее, и прочее.
... и в итоге, сведет все к показыванию унитаза при покупке туалетной бумаги: https://pikabu.ru/story/idet_muzhik_po_ulitse_smotrit_novyiy_magazin_day_dumaet_zaydu_91793
Bluewolf
08.11.2023 11:26+6Примерно равновероятные варианты:
Второй:
— Нарисуйте домик.
— А какой именно домик и для кого?
— Вы нам не подходите, в реальных задачах будете больше переспрашивать, чем работать.
Третий:
— Нарисуйте домик.
— (уходит)
Gryphon88
08.11.2023 11:26+1И это замечательно. Цель собеседования не чтобы наняли вот такого прекрасного программиста, а разобраться, подходят ли сотрудник с работодателем друг другу, и ранний выход очень хорошая стратегия. Рекрутер является первой точкой, когда работник с компанией пересекаются и непосредственно взаимодействуют, так что процесс найма - это еще и вывеска. Другое дело, когда найм по знакомству, на конкретный проект и в конкретную команду, тогда рекрутера вы скорее всего просто не встретите.
nronnie
08.11.2023 11:26Классика с гугловского (кажется) собеседования
Если не путаю, то это из Спольски.
EllisonHR Автор
08.11.2023 11:26+3Спасибо за вопрос. Честно, не ожидала, что фраза "внимание к деталям" вызовет такую дискуссию)
Из примеров, что указывает на возможную рассеянность: опечатки в тексте и знаки препинания, возле которых стоят лишние пробелы. Например , так . Обычно такие маячки выявляются при просмотре резюме или в переписке, когда обсуждаем время для собеседования. На интервью обращаю внимание, насколько внимательно человек слушает. Например, запоминает ли имя, не повторяется в речи и не задает ли вопросы, на которые уже были ответы. Да, это мелочи. Но они уже сигнализируют о возможной невнимательности.SuperTEHb
08.11.2023 11:26+2У меня как-то сам собой выработался стиль речи, где минимум прямых обращений по имени. Потому что я их сразу просто не могу запомнить. Уж лучше уделю максимум внимания содержанию беседы, а не зубрёжке про себя имени. Что же теперь, побить меня и уволить?
ALexhha
08.11.2023 11:26+1Из примеров, что указывает на возможную рассеянность: опечатки в тексте и знаки препинания, возле которых стоят лишние пробелы. Например , так .
Обычно такие маячки выявляются при просмотре резюме или в переписке, когда обсуждаем время для собеседования.
серьезно ?! Или это новый уровень троллинга ? Т.е. hr ставит условный минус, за лишний пробел перед запятой ? А если два пробела, то резюме сразу в мусор ?
А когда сама HR при этом допускает грамматические ошибки, то это другое ? Я, как кандидат, должен игнорировать подобное или тоже заносить в черный список hr/фирму ?
Vpan
08.11.2023 11:26+3Человек утверждает, что он - программист, то есть, как минимум, знает синтаксис хотя бы одного языка программирования. А действительно ли он способен выучить синтаксис языка, если допускает очевидные ошибки при написании текста на языке, который учил с рождения? А если он не способен в синтаксис - как он будет решать хотя бы самую простую приближенную к реальности задачу?
MiraclePtr
08.11.2023 11:26+1У человека может быть дисграфия, и при этом он вполне себе нормально может программировать. Благо, в IDE есть автокомплит и проверка синтаксиса :)
select26
08.11.2023 11:26Так и CV он не на обрывке газеты пишет. Он точно знает про "автокомплит и проверка синтаксиса"?
Для меня лично, неумение писать грамотно на родном и рабочем языке - сигнал тревоги.
voldemar_d
08.11.2023 11:26+2Если программист допустит опечатку в синтаксисе языка программирования, программа не скомпилируется, пока он ее не исправит. И современные IDE с автозаполнением во время набора сильно упрощают жизнь. Даже если забыл какую-то часть синтаксиса - гугл под рукой.
А если он не способен в синтаксис - как он будет решать хотя бы самую простую приближенную к реальности задачу?
Слишком общее утверждение. Я-то как раз за то, чтобы писать правильно и грамотно. Но совсем прямой и очевидной связи между умением грамотно писать и умением решать задачи нет.
Vpan
08.11.2023 11:26Понимаю, что есть IDE. Синтаксис, на мой взгляд, это не про умение писать без синтаксических ошибок, а про представление чего-то (текста/кода) как набора блоков, имеющих смысл, и оперирование этими смысловыми блоками. Человек, который пишет с ошибками, подходит к языку как если бы это была регулярная грамматика (применяет регулярные эвристики, например: "всегда ставить запятую перед "как"). И тут нужно дополнительно удостовериться, что он не потеряется в задаче, требующей контекстно-свободной грамматики.
ALexhha
08.11.2023 11:26Человек утверждает, что он - программист, то есть, как минимум, знает синтаксис хотя бы одного языка программирования. А действительно ли он способен выучить синтаксис языка, если допускает очевидные ошибки при написании текста на языке, который учил с рождения?
т.е. IDE c автокомплитом и вот это вот все - для слабаков, а программисты у вас пишут код на бумажке )))
lilac1982
08.11.2023 11:26Опечатки в тексте и отсутствие знаков препинания также говорят о том, что у человека возможно дисграфия. Что полностью нивелируется при написании кода благодаря линтерам, спеллчекерам и автоподстановкой.
ALexhha
08.11.2023 11:26+6Вот интересно, а как вы оцениваете ну конкретно "внимание к деталям" ??? Опишите с примерами
ну или как то так
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?
SergioT4
08.11.2023 11:26Man or a woman
В этом диалоге мне всегда было интересно как ответ "how old is a person born" зависит от пола этого персноа, ну а так конечно шикарный пример.
Был похожий рассказ про интервью где обсуждали написание простой программы толи для чтения, толи для записи в файл.
ALexhha
08.11.2023 11:26По статистике женщины живут дольше мужчин. Поэтому, косвенно эта информация могла дать понять, жив или нет этот человек. Кстати, следующий вопрос был именно об этом.
Но это лишь мои догадки
ymishta
08.11.2023 11:26харды и софты противоречат друг другу
Ресурсы, пошедшие на одно - это ресурсы, не пошедшие на другое, так что для большинства людей это именно что противоречие.
Triton556
08.11.2023 11:26Сейчас любая более менее крупная разработка идёт в команде, и не редко в кросс-функциональной. Постоянно нужно общаться с командой, обсуждать какие-то проблемы и их решения.
Уже давно прошло то время когда разработчики сидели молча в одиночку и сами с собой писали код (в боле менее крупных компаниях). Поэтому софты сейчас в каких-то вакансиях даже важнее чем харды. Потому харды намного легче подтянуть по ходу работы, чем научиться общаться и работать в команде, и при этом не быть токсиком
Kelv13
08.11.2023 11:26Математическое интервью на позицию типа IT manager - сколько компьютеров было, сколько принтеров, сколько человек, сколько серверов и ни одного вопроса по сути - только цифры. И, вообще, вопросы по сути обычно только с некоторыми представителями бизнеса.
Sunrise33g
08.11.2023 11:26+33Мне рассказывали про ситуацию в одной небольшой компании. Они пытались нанять людей с опытом C/C++. А до техлида доходили исключительно молодые кандидаты 185+ см ростом, странными причёсками и нулевыми знаниями по стеку. При этом сами кандидаты, как выяснилось, тоже не понимали, что идут именно на пром.автоматику.
Когда стали разбираться, обнаружили что эйчарки устроили Тиндер на рабочем месте, игнорируя стек вообще. А набирали людей просто исходя из личных симпатий.
Это достоверный случай от хороших знакомых, но не единственный подобный случай, который до меня дошёл.EllisonHR Автор
08.11.2023 11:26+6Теперь интересно, по каким критериям отбирали эйчаров, что они смотрины на работе устраивали Оо
Ситуация, конечно, странная. Очень жаль, что ваши знакомы с ней столкнулись
Xenos_rus
08.11.2023 11:26+21Не странная, всё гуглится.
"Опытному рекрутеру достаточно 10 секунд, чтобы оценить вас по-достоинству." (орфография сохранена)
"Мне достаточно 20 секунд, чтобы всё сказать про него. По щелчку пальца буквально."
"Кандидат берет трубку сонным, ленивым или недовольным голосом говорит "Алло" и я сразу понимаю, что это не наш кандидат."
Мне тоже интересно по каким критериям компании набирают себе эйчаров.antonkrechetov
08.11.2023 11:26Погуглил все три фразы. Надо сказать, что вторая (вот эта)
"Мне достаточно 20 секунд, чтобы всё сказать про него. По щелчку пальца буквально."
это цитата слов кандидата в службу безопасности, а не HR.
lex899
08.11.2023 11:26+3Очевидно что эйчаров должен выбирать эйчар для эйчаров.
Не имею большой выборки, но по личному опыту все эти оценки софт скилов не имеют ничего общего с тем как человек приживется в команде.
Plamenirium
08.11.2023 11:26+22Ну надо же - не все разработчики могут проводить технические собеседования, зато hr могут.
SpectrumOS
08.11.2023 11:26+14Иногда меня называют хинкали-рекрутером
И что это значит? Нанимаете только в грузинские офисы?
Зачем вкидывать неизвестный аудитории термин и не раскрывать его?
Breathe_the_pressure
08.11.2023 11:26+22Хинкали-рекрутёр - вкидывает неизвестный аудитории термин и не раскрывает его.
EllisonHR Автор
08.11.2023 11:26+1Ник дали мне айтишники в одном из тг-чатов. Мы в Outlines Tech вели зарубежные проекты, и мне срочно нужен был разработчик из стран СНГ. Я искала выходы на крутых ребят из Армении или Грузии. Зашла в отчасти профильный чат и спросила у IT-специалистов, где найти профи. Один из ребят в беседе расстроился, что я не ищу его профиль, и написал мне в ответ: "нервно бросается хинкалями".
Я поддержала шутку. А потом ребята нашли мой профиль в соцсети и узнали, что я занимаюсь кавказскими танцами. Так и дали прозвище "Хинкали-рекрутер".
Вот такая история
a35012a
08.11.2023 11:26+38tldr: стереотипы про HR правдивы, но на то есть причины, хотите работу — делайте хорошо, а плохо не делайте. Вот ссылка на TG
larasage
08.11.2023 11:26+28Всего сейчас в компании открыто более 80 вакансий.
Смотрю в профиль "Численность 101–200 человек". В голову приходит три идеи:
1. Стремительный рост компании (со всеми его проблемами)
2. Большая текучка кадров
3. - Вы покупаете рыбов?
- Нет, только смотрим.EllisonHR Автор
08.11.2023 11:26-2Все проще: часть специалистов подбираем для наших клиентов из банков из ТОП-5 страны и лидеров в ритейле и логистике.
По поводу текучки кадров: сейчас у нас показатель около 10%. Служба заботы помогает коллегам развиваться в IT бережно к себе и без выгорания.
AntoineLarine
08.11.2023 11:26+9Сорри, не удержался )
банков из ТОП-5 страны
"ТОП-5" звучит как будто это FAANG. А по факту, это известные "зелёный", "синий", "красный", "жёлтый" и "голубой" банки. Т.е. всем известные конторы, каждая со своими закидонами и скелетами, и от которых в общем зачёте лучше держаться подальше.
Xambey97
08.11.2023 11:26Недавно ушел из подобной галеры покрупнее, тоже работает в основном с банками. Судя по тому, что я вижу, банки сейчас стремятся избавиться от расходов на аутстаф специалистов, на рынке есть кого пылесосить от уходящих компаний
i86com
08.11.2023 11:26+29Картинка
Вот пример одного их таких резюме. И как из текста понять уровень и крутость специалиста?
А можно подробнее, в чём конкретно проблема с этим текстом?
Человек 5 лет разрабатывал Android-приложения, проводил код-ревью и формировал задачи разработчикам своей и смежной команды. Значит, был как минимум Senior на том месте работы. Явно не джун, да и явно за рамками мидла.
На другом месте - Ведущий программист, т.е. опять же не джун.
Это по уровню. По крутости - даже не знаю, по какой методике её оценивать через текст и чего в нём не хватает.
"Всегда был самым лучшим в команде, на голову выше всех остальных, написал за неделю фичу, которую другие вдвоём за месяц не смогли домучать" ?
Ну, во-первых некрасиво поливать грязью прошлых коллег, а во-вторых - это может быть "слегка недействительно" и субъективно.
Перечислять конкретные реализованные фичи? Да там за 5 лет такой список будет, что он и сам от скуки до конца не сможет доскроллить, не то, что HR.
Привести пример? Это самое плохое. Напишешь про игры - HR посчитает что "этот человек только игрушки и умеет делать, а у нас тут сурьёзный ГазМясСтрой, нам такого не надо". Напишешь про приложение для ГазМясСтроя - подумают "не, у нас тут маркетплейс глэмпингов, это другое". При том, что код там один и тот же может быть.
Так в итоге, что ожидается дополнительно в этом тексте?
sva89
08.11.2023 11:26+2Да хоть банальное "сделал фичу А, использовал то и то, добился прироста скорости/увеличения прибыли на х%", и так 2-3 раза. Для лида можно добавить про работу с людьми, пусть это даже "провел онбоардинг новой команды для проекта В".
EllisonHR Автор
08.11.2023 11:26-1Отличный пример!
Спасибо за комментарий)
Mur466
08.11.2023 11:26+4Из резюме понятно, что кандидат выполнял функции сеньора или даже тимлида. По мне, так не хватает только количества человек в команде.
Зачем вам описания фич, реализованных в системе, о которой вы ничего не знаете?
Как может быть увеличение прибыли релевантно способностям кандидата? Вы же не продажника ищете.
Объясните конкретнее, как вы будете использовать информацию из "отличного примера"?
PsihXMak
08.11.2023 11:26+3А если ты за 5 лет сделал сотню таких фич, при этом по разным областям и с самым разным результатом?
Допустим, впишешь в резюме, что сделал оптимизации для 2-3 либ. HR посмотрит и скажет, что «мы с этими либами не работаем» и отправит резюме в корзину. А на самом деле, у тебя таких либ штук 30.
sva89
08.11.2023 11:26Выбрать самые технически сложные и интересные. Это как минимум повод обсудить имеющийся опыт на интервью.
Если области настолько разные - сделать >1 резюме, со специализацией. Хотя адекватные компании обычно понимают что не все используют их стек и смотрят на похожие.
Areso
08.11.2023 11:26+2А вы уверены, что программист, от джуна до суперлида, должен знать как фича в приложении повлияла на прибыль?)
Меня каждый раз на ха-ха пробивает, потому что такое возможно только в очень немногих случаях.
Но нет, все хотят числа. Даже сраный поломойщик должен в резюме вписать во сколько раз увеличилась площадь вымытых полов и оттого выросло количество клиентов, иначе всё, плохое резюме...sva89
08.11.2023 11:26-1Ну если мойщик полов и лид разработчик имеют одинаковое влияние на успехи компании...
А если серьезно, то с уровня сеньора полезно знать, для чего разрабатывается та или иная фича. На уровне стартапа вполне реально выяснить влияние на прибыльность, в энтерпрайзе, естественно, с этим определенные проблемы. Не знаешь прибыль - возможно где-то ускорил приложение/сервис, сэкономил ресурсы, в век облаков это может быть вполне ощутимая экономия для компании. Не было подобных задач - ну напиши хоть что-то в стиле "сделал то, результат такой", пусть это даже будет благодарность от клиента.
EllisonHR Автор
08.11.2023 11:26-1В чем проблема с текстом? Отвечаю: из резюме непонятно, какие задачи программист решал, за какие процессы отвечал, какое приложение разрабатывал, какой стек в каком проекте использовал.
Я же ищу человека на конкретные задачи команды, поэтому мне важно понимать его опыт. Утрирую и приведу аналогию: вы же не выбираете машину, потому что в ней есть руль, четыре колеса с наномикропротектором, многоцилиндрический двигатель ультра3000 и много другой начинки. Вы наверняка смотрите на то, что эта начинка такого делает невероятного, отвечает ли она вашим задачам: разгоняется ли до 100км/ч, может ли ездить по бездорожью, а по ровному асфальту умеет или она для этого не предназначена. Так же и в найме: недостаточно назваться программистом и перечислить стеки.
Хороший пример, что можно написать в резюме, привел @sva89
AnimeSlave
08.11.2023 11:26+5Простите, что ворвусь в диалог.
вы же не выбираете машину, потому что в ней есть руль, четыре колеса с наномикропротектором, многоцилиндрический двигатель ультра3000 и много другой начинки
Менеджеры по продажам существуют для того, чтобы продавать машину. У них же можно узнать детали о машине. Я, как покупатель узнаю у других владельцев их мнение. Если переносить это в сторону рекрутинга, я как соискатель узнаю у HR детали о компании, у других сотрудников (если удаётся таких найти) мнение о компании, о работе в ней. Но почему это же не работает в другую сторону. HR нужно, чтобы всё было открыто. Как в налоговой. Я сразу должен раскрыть все свои документы. И в этом поведении вроде бы нет проблемы. Типа, это просто лень соискателя - детально не описать свой опыт. Я это понимаю. Только я не понимаю, почему тогда HR не читают этот опыт? Существует прямая рекомендация не засорять резюме. Максимально сокращать его, если оно больше двух страниц. А как тогда свой опыт описывать? То есть какие-то двойные стандарты. Ваш тезис из статьи
Кандидат должен говорить ровно то, что эйчары хотят услышать
Он не просто правда, а мега ультра жиза. Именно так и нужно действовать. Если переносить это в область резюме, получается я как соискатель должен попасть в выборку, в набор технологий по списку. Дожен для каждого конкретной вакансии переписывать резюме просто повторяя всё то, что написано в вакансии. То есть получается, что для меня HR это просто прослойка-отсев, которую нужно пройти. И потому приходится играть в игру «Угадай список триггеров сегодняшнего HR». А сами HR при этом вопросы не задают. Типа, зачем тратить время на кандидата, с «непонятным» резюме.
У меня лично подгарает с того, что я пробовал все возможные варианты. И описывал весь опыт в резюме. И сокращал его в один лист A4. Подстраивал под конкретные вакансии. Результат - полнейший рандом. Вообще нет никакой корреляции. То есть я на своём опыте, как мне кажется, подтвердил часть тезисов из статьи. И поэтому сейчас триггернулся.
kma21
08.11.2023 11:26+1если так рассуждать, то в чём смысл тех комментов к опыту, что есть на скрине?
должность - программист
обязанности - программировал программы.
если уж и рассматривать это с такой прямой позиции, то уж лучше не описывать обязанности вообще, чем описывать их так.
я уж не говорю про то, что грейд судить по стажу (не опыту!) работы это путь вникуда. тут ты сеньор, в трудовой у тебя написано, что ты старший инженер, а в другой компании ты и на мидла не тянешь. зато 5 лет опыта, инженер-программист.
Krouler7
08.11.2023 11:26Ну Вы совсем уж в крайности ушли. Понятное дело что необходимо описывать чем занимался. Но у разных HR мнения по объему сильно различаются - сложно найти середину.
я уж не говорю про то, что грейд судить по стажу (не опыту!) работы это путь вникуда
А грейд это вообще просто ярлык для самодовольствования и способ сдерживания прав/ответственности сотрудника руководством. Какой-либо ценности не несет.
Ценность несут завершенные проекты - их объем, количество и проработанные ошибки при работе.
sibirier
08.11.2023 11:26+25Первая причина, почему рекрутеры не приглашают на интервью —
нерелевантный опыт. Кандидат не подходит по скиллам, проектам или у него
не такой серьезный стаж работы, чем компания ожидает.Стереотипы, шаблонность, уравниловка. Вы ищете идеально подходящего кандидата по какому-то не обязательно идеальному описанию или того, кто будет работать?
Профессия требует постоянного обучения: мы читаем статьи и проходим
дорогие курсы. Тратим время и ресурсы, чтобы говорить с соискателями на
одном языке, понимать стеки. Если рекрутер этого не делает, то задает на
собеседовании глупые вопросы, ...Не те курсы, видимо, проходите. Программирование серверов, сайтов и игр, в сущности своей, имеет сильно больше общего, чем различий.
Программирование из написания кода на каком-то языке состоит процентов на 15-20. С хорошими ТЗ и тестировщиками может процентов на 30-40. Всё остальное время - обсуждение задач, проектирование логики, обсуждение требований, тестирование, дебаггинг (он на всех языках одного класса (императивные, например) одинаковый. Мне, помнится, приходилось дебажить код на С++, когда я его ещё не знал (знал Java7), исправил исходный код, перекомпилировал и запустил в работу платформу, на которой в итоге работал с целевым ЯП (не C++)), описание багов, приоритезация задач (у кого побольше опыта), системный анализ (который уже не может делать аналитик из-за технических тонкостей), оптимизация алгоритмов/процессов (это вообще общеинженерный навык, не только айтишный), проведение экспериментов и продуктовых тестов (профиль нагрузки, latency, отказоустойчивость), написание первичной документации.
И даже писанина на каком-то языке или на какой-то платформе состоит не из знания перечня всех возможных функций и их аргументов на этой технологии, а из общего знания "что должно быть, как это должно работать, в теории". Любой опытный айтишник запросто сменит свою проф. область за месяц-полтора-два при должной мотивации.Но HR рынок по-прежнему продолжают искать по принципу:
Первая причина, почему рекрутеры не приглашают на интервью —
нерелевантный опыт. Кандидат не подходит по скиллам, проектам или у него
не такой серьезный стаж работы, чем компания ожидает.Стаж работы? За 1 год интенсивной R&D работы можно изучить раз в 10 больше, чем за 5 лет поддержки готового legacy кода. Неужели менеджеры в IT этого не понимают? Сомневаюсь.
Все люди разные. Некоторые способны программировать на технологиях, которые впервые в жизни видят, а некоторые с уже хорошо знакомыми технологиями чуть в сторону отойти не могут - "этим всегда DevOps/тестировщик/аналитик/архитектор занимался, я не знаю ничего оттуда".
Но "стаж", "опыт", "проекты"......недавно мы публиковали чек-лист, который помогает усилить резюме
Нет! Называйте вещи своими именами: это чеклист, который позволяет HR проще отсеивать тех, кто не подходит под ваши шаблоны. Для кандидатов такие рекомендации не помогают!
У меня есть два резюме: в одном я соблюдал все возможные рекомендации - более "образцового" резюме не найти. На 140+ моих откликов штук 70 молчаливых отказов, около 40 просто тупо игноров, штук 30 опросов от HR, технических собеседований штук 15. Офферов 3-4. Приглашений от HR штук 5 за 4+ месяцев поиска.
Во втором резюме указаны всё те же самые навыки, нет фото, нет описания деятельности в компании, нет описания моих достижений, нет даже ФИО. Это резюме нарушает все возможные рекомендации, кроме одной: указывать свои навыки, которыми я уже владею или способен быстро освоить. Какой результат? 7 приглашений от крупных работадателей за 2 дня. После созвонов (на которых я старался давать минимально возможную и максимально общую информацию, никакого упоминания негатива про кого бы то ни было, даже если его было очень много) технических собеседований из них назначено некоторое кол-во. Сам ещё ни разу не откликался этим резюме.Так кому вы помогаете своими советами?
И тимлиды ещё "молодцы": отсекают по каждой шероховатости, не стремятся вычленить толковых, стараются найти идеально подходящего под свои шаблоны видения кандидатов (которое тоже не всегда идеально). Даже по тем знаниям, которые гуглятся за 1 минуту и после двух-трех употребление в использовании запоминаются на долгие годы.
Может эти статьи по найму лучше не самим усваивать, а стараться научить тимлидов нанимать?
За все технические интервью, действительно толковые собеседователи попадались 2 раза. Многие из остальных - опытные нёрды с дутым ЧСВ, либо следующие формальным принакам отбора, которые они составляли как? Методологию проверки знаний тимлиды вряд ли изучают - им же некогда, они же и работают, ещё и уровень кандидатов определять. Особенно, когда нужно вытягивать из кандидатов информацию (а из айтишников надо, коммуникабельных нечасто видел).
И вишенка на торте: тимлиды не учитывают человеческий фактор. Люди - существа эмоциональные и эмоциональное состояние сильно влияет на степень воспроизводства той или иной информации. А ещё частое напряжение памяти и формулирование новых мыслей - очень утомительно. В итоге из-за волнения и перенапряжения человек через 5-10 минут расклеивается, начинает путаться в терминологии, забывает что-то (хотя минут через 10 после завершения с лёгкостью это вспомнит), начинает плохо соображать и всё такое. В итоге может выглядеть (не являться) неопытным, хотя может быть как раз идеально подходящим на роль техлида или ведущего разработчика.Недавно на технческом интервью через 15 минут после начала переволновался, встал в ступор, в голове пропали все мысли и не смог написать простой SQL запрос, хотя вот только что написал уже несколько не проще этого и полностью назвал алгоритм, как надо его составлять. В итоге тимлид отказал в найме. Через 5 минут после завершения собеса проверил озвученный мной алгоритм - он правильный.
Ещё: есть люди соображающие быстро, а есть, у кого мысли должны повариться и хороший ответ приходит сильно потом. Я из вторых. И в моменте сильно теряюсь, такая вот специфика организма. Из-за этого заваливал многие интервью только потому что не смог сказать синонимичное слово к уже озвученному, а тимлид ожидал услышать именно его.
Рынок IT найма сломан (если хоть когда-то был работающим). И как его чинить/выстраивать - пока непонятно.
iburanguloff
08.11.2023 11:26+1Стереотипы, шаблонность, уравниловка. Вы ищете идеально подходящего
кандидата по какому-то не обязательно идеальному описанию или того, кто
будет работать?Логика в отсеивании кандидатов по их опыту мне кажется достаточно логичным. Какой смысл собеседовать джуна с опытом в пару месяцев, когда в команду нужен разработчик api шлюза условно. И он ведь будет работать, но много ли от такой работы пользы?
sibirier
08.11.2023 11:26+2Вы привели пример про "вам нужен костёр? Вам он не нужен, вот есть спички - тут тоже есть огонь" и я про это не писал - само собой опыт должен быть сопоставим с уровнем ответственности и компетенциями.
Но часто происходит "шашечки или ехать":
- мне нужен костёр, мне написали, что на костре можно разогреть еду.
- предлагаю вам газовую горелку, она безопаснее, сразу даёт тепло, сразу можно убрать огонь, если надо - одни плюсы!
- не, мне написали, что нужен костёр, притом на берёзовых поленьях. Про газовую горелку ничего не написано, поэтому "вы нам не подходите".Хотя очевидно, что в этом примере нужна функция - разогреть еду. Тут и микроволновка могла подойти, и паровая баня и всё что угодно, выполняющее функцию.
Любой опытный Java программист, претендующий на программирование серверов на Go с описанием того, что он в экосистеме Go разбирается или может освоиться (в курсе из чего экосистема состоит), скорее всего понимает на что он идёт и, значит, нужно рассмотреть вариант дообучить его до нужной лёгкости владения инструментами экосистемы Go и провести техническое собеседование, а не послать его куда подальше, потому что "к сожалению, у вас недостаточно опыта программирования на Go, а менеджеру это очень нужно". И неважно, если этот разработчик очень хорош в программировании серверных микросервисов/модулей, особенно многопоточных и без гонки данных.
Гораздо ценнее разработчик, который на практике владеет методами предотвращения гонки данных в любых системах (в которых они теоретически возможны), чем разработчик, подходящий под описание "имеет опыт работы на Go не меньше двух лет". Но поди объясни это менеджеру или HR'ам...
Rive
08.11.2023 11:26Хах, похоже это появились последствия от общения с кадрами, которые впадали в ярость от эйчаров, которые путали Java с Javascript.
Сколько там этому мему лет, десять? Ну вот через пять-десять лет маятник может качнуться обратно.
kimisa
08.11.2023 11:26+1Гораздо ценнее разработчик, который на практике владеет методами предотвращения гонки данных в любых системах (в которых они теоретически возможны), чем разработчик, подходящий под описание "имеет опыт работы на Go не меньше двух лет".
И у меня такая же проблема. Сменила стэк, ушла на гоу. Но тут отлупы - нет стажа на гоу. А по сути это не ревалентно. Джун нулевой или человек поменявший стэк, но работавший с базами и серверами., знающий методологии и умеющий работать в команде.
voldemar_d
08.11.2023 11:26+1есть люди соображающие быстро, а есть, у кого мысли должны повариться и хороший ответ приходит сильно потом
Бывают задачи, для которых сиюминутная идея, как ее решить, оказывается плохой. Иногда лучше остановиться, подумать, "поварить" задачу в голове день-два, и потом окажется, что в голову приходит совершенно другой метод решения, который оказывается и лучше, и эффективнее. Вплоть до того, что оказывается, что надо решать не поставленную задачу, а совершенно другую, и при этом удается "убить несколько зайцев сразу".
SpiderEkb
08.11.2023 11:26+1А бывает что для эффективного решения одной задачи нужно еще параллельно поставить и решить пару-тройку сопутствующих "подзадачек".
Вот занимаемся оптимизацией одного бизнес-процесса. И приходим к тому, что очень многое упирается в одну таблицу, где хранится история изменения некоей бизнес-сущности. Проблема в том. что каждый раз приходится тратить время на то, чтобы получить актуальное (последнее в истории изменения) значение. А это время.
Возникает параллельная подзадача - создание и ведение витрины где нет исторических значений, только текущее актуальное.
А это создание таблицы-витрины с нужными индексами, скрипт ее первичного наполнения (чтобы сразу при внедрении поставки витрина заполнилась), изменения в логике модыля ведения основной таблицы (чтобы сразу вносились изменения и в витрину) и изменения логики работы ретривера (теперь он не ищет значение по основной таблице, но берет нужную запись из витрины).
И такие решения идут от разработчика и аналитика, но никак не от менеджера.
vvbob
08.11.2023 11:26+12Где их находят, этих неадекватных "деочек-эйчаров"? Я вот уже сбился со счету в скольких собесах поучаствовал, ни разу не припоминаю проблем именно с ними. Неадекватов технарей - тех полно было, но эйчары-то.. Они ведь на твоей стороне, им выгодно тебя "пристроить", топить тебя им смысла нет никакого. Все что надо - не быть муд..м в общении, и все по большему счету.
kma21
08.11.2023 11:26+1иногда такие люди проецируют своё ЧСВ на кандидатов (чит. синдром вахтёра). и они не ищут лучших людей на эту позицию в этой команде и компании, а пытаются вершить судьбы людей. тут возьму, тут не возьму.
vvbob
08.11.2023 11:26+5Я такое встречал обычно как раз у нашего брата разработчика. Все эти техинтервью, на котором часто бывает что спрашивающий начинает просто явно вы..делываться, самоутверждаясь перед коллегами - мол посмотрите какой я крутой спец и как я сейчас этого лошка уделаю. Иногда, бывало, опускал таких с небес на землю, но это как по мне даже особого морального удовольствия не доставляет, теперь чаще всего видя такое, просто прерываю собес и раскланиваюсь с участниками, пускай там лучше коллеге хорошего психолога найдут что-бы он проработал с ним эти проблемы, а не сублимировал на собеседованиях.
DarkWolf13
08.11.2023 11:26+8хит парад "результатов" общения c HR:
Даже в случае отказа мы вам обязательно перезвоним. За 20 лет только двое перезвонили, и в одном случае развернутый ответ почему отказали.
Назначается собес на конкретное время с оговоркой что будет присутствовать еще кто-либо для технических вопросов, а по факту какое-то скомканное мероприятие где не звучит ни один технический вопрос, но пытаются узнать чуть ли не все мои домашние пристрастия и увлечения.
Собеседование более 45 минут без озвучивания технических подробностей выполняемой работы на должности вакансии, как будто это какой-то секрет.
Психологические тестирования с "раскрашиванием квадратов".
jevius
08.11.2023 11:26+1Найти работу (особенно первую) -- это почти всегда рандом. Иногда на техническом задают вопросы, которые сходу не знаешь (это может быть термин, например), но ответ гуглится за 3 минуты и в теме легко разобраться. Наверное, так проверяют, насколько ты вообще в контексте. Но если 2 человека без опыта и оба готовились (гуглили) перед собесом -- повезет тому, кто нагуглил ответ именно на вопрос от тимлида.
Даже если компания работает над своими процессами (хотя тяжело оценить, насколько эта "работа" имеет импакт -- работать можно и вхолостую) заруинить найм может неадекватный руководитель (и такие на моей памяти встречались).
sergyalosovetsky
08.11.2023 11:26+6Даже если не понравился человек, это не влияет на итоги собеседования.
Да ладно, неужели??
Похоже, статью написал ГПТ4
NutsUnderline
08.11.2023 11:26+11при таком заголовке требую фотку в полный упомянутой девочки - автора данного материала. будем материал оценивать по фотке автора ;)
eton65
08.11.2023 11:26+1Статья от представителя профессии-паразита сквозит именно этим подходом - "вы все равно прогнетесь под нас!".
SpiderEkb
08.11.2023 11:26+3Мой опыт взаимодействия с рекрутерами.
HR не занимается собеседованием. Совсем. Только первичный отбор резюме и отправка их в команду. Команда уже решает кого собеседовать и отправляет выбранное HR. Тот организует встречу (время, место...), но сам не участвует. Собеседование проходит с командой - там уже сразу видно кто как дышит, нравится не нравится. Если команда решила брать - HR получает резюме кандидата и уже занимается всеми формальностями оформления (вплоть до "привести за ручку на рабочее место)".
И никаких вопросом по поводу "да HR вообще не понял какой я хороший кандидат потому что ничего в теме не понимает" не возникает. Каждый занимается делами в рамках своей компетенции. И HR не нужно думать - "а понравится ли команде как этот кандидат дышит". Это команда сама решит.
dkuzminov
08.11.2023 11:26+1Софт скилы, на мой взгляд, сильно переоценены. Например, вспомните университетские годы, когда человек приходил на экзамен неподготовленным, и начинал с уверенным видом жонглировать терминами, в которых ничего не понимал. Зачастую даже успешно сдавал экзамен. Чем не софт скил? Очень нужный доя торговцев и юристов; технарям мог бы пригодиться на конференции, когда вопросом из зала ставят в тупик. Но вот беда, я обнаружил, что почти весь чужой код, с которым мне приходится работать, грешит тем же: его писали люди, не до конца разобравшиеся в задаче, и плохо владеющие нюансами технологии. Зато код написан так, что с первого взгляда кажется, что там написано что-то умное.
Так вот, рекрутеров легко проходят именно булшиттеры, которые понахватали с миру по нитке, но ни в чем серьезно не разбирающиеся. Глубоким же спецам часто хочется прекратить собеседование, когда кто-то начинает их щекотать за пятки для проверки софтскилов.
gatoazul
08.11.2023 11:26+3Знал одного такого. Программист он был крайне посредственным, если не сказать больше. По факту - очень плохой джун. Зато в разрезе софт-скиллов мог запросто влезть куда угодно без мыла.
Он давно в Германии и там сменил уже пару фирм.
saboteur_kiev
08.11.2023 11:26+9Лонгрид
Мне искренне жаль, если кто-то сталкивается с некомпетентными специалистами.
Как так получается?
Примем за факт, что HR не способен проводить техническое интервью. Даже на джуниора, так как там надо оценить потенциал и понять в какие сроки и что кандидат уже успел сделать за короткий период. Мидла и сеньора уже проще оценить по опыту.
Итого, кандидат в любом случае будет проходить техническое интервью с техническим специалистом.
Что остается для HR? Сверка резюме по базовым параметрам, политикам компании и определенным ключевым словам. Какая квалификация для этого нужна кроме банальной логики и умения читать? Ну аккуратность. Ну немного проактивности. Но это те софт-скиллы, в которых считается, что HR обязан разбираться, еще и коучить.Итого, квалификация HR специалиста изначально предполагается ниже. Ведь компания не планирует повышать свои расходы на найм, а наоборот сокращать.
Из-за этого все и происходит. Далеко не каждая компания готова профессионально заняться наймом. Это дорого, это возможно в крупных компаниях. И для этого нужен профессионализм и желание выстроить крутой рекрутинг в руководстве, который должен чем-то покрываться. Чтобы искать лучших из лучших, компания должна предлагать нечто лучшее.
А если нет, то....Много мы видим рекрутеров хотя бы 30+ ? КРАЙНЕ редко. Мало. В таком возрасте это либо недавно из декрета, без опыта работы, зачастую с забытыми знаниями из образования, и забитым мозгом из области ухода за детьми (а это огромный труд, который на несколько лет забивает все). Либо это уже старший специалист, начальник отдела, который лично интервью не проводит и резюме не перебирает.
Да, я хочу извиниться за резкие слова, я допускаю огромное количество исключений, но буду настаивать, что это по большей части исключения из большого правила.
Итого, в своем подавляющем большинстве HR специалист - это позиция на которую не предполагается брать высококвалифицированный персонал, который может и способен расти в технической части. Запомним это.
Многие руководители считают, что молодые и привлекательные девочки на рецепшене должны продолжаться и в рекрутинге, это же "лицо компании". Но это также приводит к тому, что квалификация страдает, а мотивация часто подменяется амбициями. Молодость также дает тот момент, что человек у которого не только не было семьи и детей, но и вдобавок длительных отношений (еще же только карьеру строить), имеет довольно своеобразные взгляды на жизненные ценности.
Итого софт-скиллы тут используются по методичке, а не на жизненном опыте.И добью еще одним.
Какие полномочия есть у HR специалистов?
Они могут предложить немного другую позицию? Нет. А технический специалист и тимлид на собеседовании могут увидеть и спланировать немного другие обязанности, подходящие человеку на ходу.Они могут предложить другую вилку ЗП или какие-то бонусы? Нет. Это делает менеджер проекта. Частично тимлид может поднять грейд специалиста и сказать менеджеру что этого человека нельзя упускать, давайте поднимем.
Они могут что-либо поменять в политике компании или проигнорировать требования сверху (например пришла разнарядка брать только с корочкой высшего образования)? Нет. Хотя менеджер проекта вполне может иметь такие полномочия и игнорировать общую политику компании в разовых случаях.
Зато они могут проигнорировать резюме, или продвинуть резюме знакомых. Или попросить кандидата переоформить. И в принципе все. Хороший специалист конечно может задать дополнительные вопросы, как в примере статьи заподозрить, что в резюме указано далеко не все. Но к найму это не привело =)
Итого, по разным объективным причинам, довольно сложно найти компанию, где рекрутинг поставлен на хорошую систему, и в рамках этой системы действительно нанимаются хорошие рекрутеры, которые затем ведут хорошую рекрутинговую деятельность.
А дополнительный прикол в том, что эта деятельность в своем большинстве не нужна на высоком уровне. Линкедин и другие подобные штуки вполне себе представляют удобный инструмент и для стандартизации шаблона CV и поиск по нему, чтобы пользоваться подобными ресурсами можно было без лишней квалификации, поэтому и вкладываться в рекрутинг, если это не ваша основная деятельность, или вы не компания с 10+ тысяч сотрудников, нет особого смысла.Поэтому да. В среднем - HR специалист - весьма посредственный специалист, от которого зависит мало. А то, что среди них встречаются личности о которых возникают истории в инете - ну так про хорошие случаи мало кто пишет.
P.S. В своей жизни у меня не было интервью прямо таки с ужасным HR, но было интервью, когда недооценили, переоценили и отклонили по техническим вопросам. И если первый случай я по молодости лет так и оставил, то во втором случае, понаглел, поуточнял что не так и прошел дальше (и устроился на приятную позицию). Второй случай - это было мое достоинство софт-скиллов? Не думаю. Считаю, что это была недоработка HR специалиста.
AntoineLarine
08.11.2023 11:26+3Мой опыт общения с рекрутёрами на 95% положительный. Всегда получал информация о вакансии, о компании, о процессе собеседования и т. п. Если вакансия описана очень, требования невнятные, то тоже на этапе разговора с HR все детали прояснялись. Cиндрома вахтёра не наблюдал ни разу. Зато дальше мог начаться тупняк в стиле, тимлид не пришёл, техлид что-то недопонял и т. п. Но тоже, по большому счёту, придраться не к чему.
К чему я веду. Вежливое и спокойное общение творит чудеса. Да, всегда есть шанс нарваться на неадекватного собеседника, но он не делает погоды.
elobachev
08.11.2023 11:26-1Интересно узнать про ваш опыт взаимодействия с рекрутерами.
ИТ ведь не только разработка, не так ли?
Взаимодействуя с рекрутерами как кандидат, за 20 лет я ни разу не был на личном собеседовании с рекрутером.. так что шутка про "рубашка не понравилась" - мимо. Рекрутер читал мое резюме и договаривался ( по телефону или почте) о встрече (личной, а затем и в форме телеконференции) с представителем подразделения, осуществлявшего поиск кандидата.
Взаимодействуя с рекрутером с другой стороны, я формирую четкие критерии, что точно должно быть в резюме и чего там точно быть не должно. Рекрутер направляет мне найденные резюме, редко их бывает более десятка в неделю. Я выбираю заинтересовавшие меня и рекрутер организует нам встречу.
В одном и другом случае ни разу не сталкивался с какими то явно выраженными проблемами именно в работе рекрутера, видимо потому что я не ожидаю от них чудес.
hlogeon
08.11.2023 11:26+13Я один не понимаю, почему HR'ы почти каждый день приходят на Хабру оправдываться и говорить что "не все HR плохие"? Как какие-то астрологи. Вон тот астролог шарлотан, а я нормальный
voldemar_d
08.11.2023 11:26А еще довольно часто такие статьи публикуют. Может, потому, что и те, и другие стабильно собирают много просмотров и комментариев?
alelam
08.11.2023 11:26+4С программистом из Костромы какая-то сказочная история. Для оытного эйчара я думаю дело 5 минут было бы выяснить при созвоне достаточно ли релевантен его опыт, чтобы хватать и на собес затаскивать. Кандидатов таких на рынке не так чтобы избыток, а оценить хардскиллы разработчика с 5+ годами опыта хотя бы на уровне "на миддла не тянет" неразработчик все равно адекватно не сможет. Зачем было человеку в душу влезать настолько, что он побежал резюме переписывать и рынок мониторить не очень понятно, хотя и выглядит очень благородно:)
ValCanada
08.11.2023 11:26+8Чтобы понимать масштабы: наши IT-рекрутеры берут в работу по 500-800 CV в неделю каждый.
А также рекрутеры/HRы говорят что им надо такое резюме, чтение которого занимает максимум 5 секунд, и чтобы сразу зацепило... Допустим, у вас 1000 резюме, тогда работа по оценке займет 5000 секунд или 1 час 25 минут ... в неделю :)
...некоторые кандидаты описывают свой опыт одной строчкой.
Так вам 5 секунд или ехать?
Krouler7
08.11.2023 11:26+1Так вам 5 секунд или ехать?
Не важно, главное чтобы было как обосновать субъективный отсев якобы объективной причиной.
ussrisback
08.11.2023 11:26+1HR не должен проводить оценку квалификации кандидата. работа HR определить базовую совместимость и пригодность. т.е. владение языком, умение общаться, ожидаемое вознаграждение, мотивация, переезд и т.п. Дальше кандидат отправляется к Hiring Manager, который либо сам либо через опытных сотрудников принимает решение. Сегодня HR системы типа Workday дают возможность Hiring Manager-у непосредственно мониторить пул кандидатов, как только они нажмут кнопочку "Apply" для позиции.
kasiopei
08.11.2023 11:26+1Задача кадровика оценить адекватность и оформить сотрудника. Выбирать резюме и оценивать компетентность должен специалист. Не понимаю почему делегируют обязанности с которыми не справятся.
nronnie
08.11.2023 11:26+1"Кадровик", "HR", и "рекрутер" - это, по сути, три разные роли, которые конкретный сотрудник конторы может совмещать (а может и не совмещать) в любой комбинации.
Efimov_pr
08.11.2023 11:26+1Хороших эйчаров реально мало и тут дело даже не в понимании отдельных отраслевых скиллов и в частности в ИТ.
Нанимающие менеджеры часто не шарят в том, что они делают.
У компаний почти всегда нет профиля должности или вакансии.
Если руководитель уделяет мало внимания найму, никакой эйчар не вытащит свою работу.
У большинства компаний много мусора в голове или нелепых требований.
Найм - это сложный навык, который низвели до рутины с первым контактом на некомпетентном стажёре или вообще программе для скоринга резюме.
Толку от всех этих статей никакого, потому что приходят новые люди и повторяют всё те же прошлые ошибки.
AnimeSlave
08.11.2023 11:26+2О чём вообще статья понять не могу. Прохождение собеседований это лотерея - иногда цирк с конями, иногда невероятно адекватное общение, что даже самому кажется, что я не туда пришёл. То есть, знать о том, как оно будет практически не возможно. И статья не объясняет проблем, и не приводит примеров решения этих проблем. Покекать с HR можно просто сходив на собеседование
nivorbud
08.11.2023 11:26+5Что-то какая то фигня вырисовывается, не могу понять смысл подобного найма специалистов. Как может неспециалист (HR) оценивать специалиста? По формальным критериям? Но это же будет бить мимо цели.
В итоге, вижу, на первое место выходит натасканность на ответы собеседований. Т.е. получается формализм против формализма. Клин клином вышибают, как говорится.
ЗЫ:
Сына готовлю к ОГЭ по информатике, затрагиваем и задачи из ЕГЭ. Вчера увидел в тесте ФИПИ задачку №18. Там дано поле N x N, где N <= 30. Во всех клетках лежат монеты, также есть произвольные стены. Робот выполняет команды: вниз и вправо. При посещении клеток монеты он собирает и накапливает. Вопрос: какое наибольшее/наименьшее количество денег может собрать робот, двигаясь из левой верхней клетки до тупика?
Задачка (если не знать решения) не такая уж и простая - лобовые школьные решения полным перебором не подходят (для максимального поля 30x30 - там факториальная сложность получается). В общем лобовой перебор путей отпал, рекурсия (красивая из пяти строк) тоже отпала. Дальше решил вместо путей отталкиваться от накопленных сумм, выбирая очередной ход, основываясь на наибольшей (или наименьшей) сумме в клетках предыдущего шага... и тогда решение было найденно.
Мои мысли: подобную задачку не всякий спец смог бы сделать с нуля (заранее не зная подходящего способа) за очень ограниченное время в стрессовой ситуации - ведь на экзамене еще 20+ заданий надо решить. А вот если человека натаскали на решении именно этого задания, то любой натасканный школьник решит ее на питоне за 10-15 минут. Алгоритм то простой, но его еще надо найти, либо просто знать.
Прихожу к выводу, что все эти тесты/экзамены ориентированы исключительно на натасканность, на знание определенного набора решений. А умение анализировать и искать решения эти тесты не проверяют.
nronnie
08.11.2023 11:26Дальше решил вместо путей отталкиваться от накопленных сумм, выбирая очередной ход, основываясь на наибольшей (или наименьшей) сумме в клетках предыдущего шага... и тогда решение было найдено.
То, что задача на "динамическое программирование" очевидно с самого начала, остается только придумать как этот метод применить. Сейчас пока сигарету на кухне курил как раз придумал :))
rg_software
08.11.2023 11:26+1Справедливости ради, этот метод называется "динамическое программирование", и в моей картине мира это всё-таки ещё подходит под определение общей computer science эрудиции. Да, это уже ступень за быстрой сортировкой или там двоичным поиском, но всё-таки не специализированный алгоритм, который не зазорно не знать.
nivorbud
08.11.2023 11:26Да, это уже ступень за быстрой сортировкой или там двоичным поиском, но всё-таки не специализированный алгоритм, который не зазорно не знать.
Это всё понятно. Но я о том, что школьник, впервые увидевший эту задачу, не знающий заранее этот способ, наверняка не осилит эту задачу, особенно в рамках экзамена. Т.е. на первом месте стоит натасканность.
rg_software
08.11.2023 11:26В моём понимании исходный смысл ЕГЭ был в том, чтобы обычный нормальный школьник не получал 100 баллов. То есть не натасканный и не должен решать эту задачу. Максимальный балл должны получать буквально доли процента по стране, а дальше уже вниз. То есть затея в том, чтобы суметь отранжировать всю публику, а не так что "освоил программу, получи 100 баллов", т.к. в этом случае будет непонятно, чем эти школьники отличаются друг от друга, хотя на практике один может знать в десять раз больше другого.
nivorbud
08.11.2023 11:26Ну так в текущих реалиях на 100 баллов скорее сдаст натасканный, чем умный.
Кстати, в этой задаче реально работающее решение нетривиальное. Да, его можно легко формально понять и применять. Школьнику это доступно. Но по хорошему счету, это решение еще надо доказать. Доказать, что перебираются абсолютно все возможные пути. А это уже сложнее. Но не требуется. Достаточно знать шаблон решения.
rg_software
08.11.2023 11:26Согласен, но не вижу в этом проблемы. Это же не iq тест. Грубо говоря, можно давать набор любых задач - на мышление, на натасканность и т.д. Главное - чтобы на выходе получалось нормальное распределение баллов с очень тонким хвостом в самом конце.
dprotopopov
08.11.2023 11:26Кстати, при приёме на работу, демонстрация излишней квалификации и знаний тоже весьма вредна - не всякий начальник хочет иметь работника, который умнее, компетентен и более образован чем он ...
MiraclePtr
08.11.2023 11:26+2Почти везде где я работал это было ровно наоборот: "Ты в этом инструменте/предмете/etc. разбираешься лучше меня, твоя экспертиза в этом вопросе нужна проекту, поэтому мы тебя и наняли".
vvbob
08.11.2023 11:26+4Такое обычно бывает либо на госпредприятии, либо в каких-то крупных корпорациях, которые по стилю управления становятся такими-же как и гос (бывает что и похуже).
nivorbud
08.11.2023 11:26-2Еще есть хороший простой вопрос: "Что вокруг чего вращается - Солнце вокруг Земли или Земля вокруг Солнца?".
Если человек сходу без сомений отвечает: "Земля вокруг Солнца", то значит, человек мыслит штампами. Если нужен человек на шаблонную рутинную работу - это наверно будет подходящая кандидатура.
Если же человек сразу задает уточняющий вопрос: "Что принять за точку отсчета?" или "Что именно рассчитываем?". То это возможно хорошая кандидатура для разработки чего-то новенького или нетривиального.
gatoazul
08.11.2023 11:26-1Вообще-то и Земля, и Солнце вращаются вокруг общего центра масс.
nivorbud
08.11.2023 11:26+1За начало координат мы можем произвольно взять любую точку. И необязательно рассматривать декартову систему. Это вопрос удобства и вопрос - что именно мы рассчитываем. Например, если я делаю солнечные часы, я за центр координат возьму точку на земле, куда воткну палку...
saboteur_kiev
08.11.2023 11:26Вообще-то и Земля, и Солнце вращаются вокруг общего центра масс.
Зануда моде он.
* Вообще-то они еще и летят куда-то.
* Если брать терминологию "орбита", то Земля вращается вокруг солнца.
* Еще считается, что вращение вокруг общего центра масс это если этот центр масс не находится внутри одного из объектов. А то если задаваться деталями, то центр масс сам по себе может еще вращаться внутри объекта.
geher
08.11.2023 11:26В системе отсчета, зафиксированной относительно Земли, таки Солнце вращается вокруг Земли.
vvbob
08.11.2023 11:26А еще можно разработчика попросить пожонглировать. Если у него получилось - значит ловкость рук у него высокая, и ему можно давать задачи связанные с вводом больших количеств текста, если не справится - значит будет работать с аналитическими задачами!
У меня, если что, еще много идей такого-же плана, как у того раввина! Даёшь нескучные собесы!
tas
08.11.2023 11:26+1А есть еще вариант с overskill.
Когда на одном из собеседований по контрольному примеру я привел результат, отличный от ожидаемого, мне указали, что я решил его неверно. Я проверил решение и не нашел ошибки, после чего мы вместе со спецом компании проверили "эталонное" решение от работодателя и нашли ошибку в нем.
В результате - отказ. Написал просьбу прислать комментарий и к моему удивлению получил ответ, в нем было написано как раз что-то вроде такого: overskill - мы считаем, что вы быстро уволитесь от нас так как квалификация выше, чем требуется...
saboteur_kiev
08.11.2023 11:26тоже сталкивался с таким. Не знаю, почему нельзя пообщаться и уточнить что человек может быть наоборот хочет отдохнуть от высококвалицифированной работы. Мало ли.
sentimentaltrooper
08.11.2023 11:26Испытываю противоречивые чувства, с одной стороны меня атакуют рекрутеры который хотят мне продать свои услуги по найму специалистов (а стоят они не мало, около 20% от годовой зарплаты искомого сотрудника). С другой стороны мне самому периодически пишут в LinkedIn с предложениями работы. И вот из-за вторых у меня совсем нет уверенности в первых (какой-то просто базовый отрыв от реальности и даже логики). В итоге только личные связи, рекомменадции, набор стажеров и взращивание собственных кадров (долго и мучительно, но хоть как-то). Десяток студентов-стажеров на лето - как раз как те 20% рекрутеру, а эффективность выше - парочка останется и славно.
Mike-M
08.11.2023 11:26+4Понятно, что тимлиды не будут вчитываться в каждое резюме: это не их работа.
Разве?
northrop
08.11.2023 11:26Так зачем замкнутому специалисту притворяться экстравертом, если в итоге работать не в комфорте
Не то, чтобы такое было каждый день, но например, затем, что он может быть на H1B в NYC, а вокруг сентябрь 2008 года. А пассаж "зачем терпеть, если можно не терпеть" выглядит как-то близко к словам Марии-Антуанетты про нет хлеба и пирожные.
Ledich
08.11.2023 11:26Если читать статти рекрутеровто на словах они все Лев Толстой, а в реальной жизни оказывается...???? немного по другому????
PrisonerOfDarkMatter
08.11.2023 11:26Мой "любимый" случай - когда в вакансии указывают, что ищут интерна без опыта работы, я откликаюсь, и мне приходит отказ с формулировкой "мы изучили Ваше резюме, и к сожалению у нас нет подходящей Вашему опыту позиции" (опыт не очень связан с IT - 1С-ник). Неужели эйчары думают, что я в свои 30 лет читать не умею и откликаюсь на всё подряд? Смысл смотреть на предыдущий опыт, если вы ищете мать его интерна?
senglory
08.11.2023 11:26А почему вы решили, что вакансия - это вакансия, а не "вакансия" для ибд или еще какого корпоративного рукоблудия?
wnder
08.11.2023 11:26Ужас-ужас это когда на техническом собеседовании в одну крупную компанию минут через двадцать беседы начали спрашивать что-то в стиле "а помните команду top? а что за параметр там во третьей строке сверху четвертый слева?" (подглядывать низя! :
LightAir
08.11.2023 11:26+2Наверно самое частое, это когда тебе написал эйчар, рассказал что ты тот самый кандидат которого они искали всю жизнь, уговорил прийти на собеседование. А потом резко всё меняется, как будто эйчару настройки сбросили, и он такой "Почему выбрали нашу компанию?"
А ещё раздражают те, которые говорят что, "мы прочитали ваше резюме и вы нам полностью подходите", при этом предлагаю скажем работу не Go разработчика а Java. Ну т.е. резюме вообще не читали, как и не читали зарплатные ожидания или позицию
KACATKA
08.11.2023 11:26В начале этого 2023 года мониторил вакансии администраторов Domino. Дык, встретилась вакансия. где необходимо было ОБЯЗАТЕЛЬНО иметь сертификаты по Domino от самой IBM.
Пришлось в обязательном отклике на вакансию написать, что все сертификаты от IBM уже не имеют силы, так как индусы из HCL купили Domino ещё в конце 2018 года. Даже приложил ссылку на официальный ресурс где темным по светлому написано, что все сертификаты по IBM Domino утратили силу.
Тут ни HR, ни сами IT-шники, которые составляли требования, просто "не в теме". А прошло уже более 4 лет...
Fid0
08.11.2023 11:26+199% IT-HR не знают, чем отличается c++ backend разработчик и c++ desktop разработчик.
M2ximus
08.11.2023 11:26+1С чем сталкивался лично я:
На одном из прошлым мест работы понадобился админ, я составил и передал HR-у перечень требований к соискателю. HR начал присылать мне любые резюме, в которых хоть как-то упоминается работа с компьютером, никакого предварительного отсева не делалось. Несколько раз служба найма умудрилась пригласить на техническое собеседование соискателей с "нулевыми" знаниями и навыками. На мой вопрос, зачем они это делают - был простой ответ "бери любого, они все равно потом все увольняются". Конторе > 15 лет, численность ~250 человек, ежемесячно увольняется 7-10-15 человек (не из моего IT-направления), идет постоянный набор, служба персонала получает %% к премии за каждого принятого нового сотрудника, что будет с ним дальше - их абсолютно не волнует, даже если он уволится через 4 часа (это реальные случаи).
Когда сам искал работу, прошел первое собеседование с HR, по ее словам - все отлично, передам вас дальше, на техническое собеседование. И все, тишина. Кое-как, недели через две, удалось связаться с HR, ответ, мягко говоря, расстроил "технический специалист сказал, что вы нам не подходите, у вас нет нужных нам компетенций", как выяснилось в дальнейшем разговоре, что эти "нужные компетенции" отсутствовали в вакансии, их просто забыли добавить.
Вакансия висит месяцами, отправил отклик и никакой реакции (Outlines Technologies тоже "грешит" подобным).
EllisonHR Автор
08.11.2023 11:26Мы стараемся как можно скорее давать обратную связь по откликам. Я как руководитель отслеживаю такие моменты. Спасибо, что подсветили. Буду смотреть за командой ещё тщательнее.
Viceroyalty
08.11.2023 11:26Почему просто не нанять на должность рекрутера человек который понимает что нужно делать?
olartamonov
Случай из жизни, один из многих: эйчар отбрасывала все резюме, в которых не было 100-% совпадения аббревиатур с перечисленными в описании вакансии.
Так, в корзину полетело резюме человека с сертификатами всяких Cisco и многолетним опытом в телекоме, потому что в нём не было аббревиатуры «TCP/IP».
К несчастью эйчара, это был тот случай, который в розничной торговле называется «тайный покупатель».
EllisonHR Автор
Интересный кейс)
А каких кандидатов взамен предлагала эйчар? Там были крутые специалисты?
olartamonov
Никаких. Отсутствие кандидатов и заставило заказчика задуматься о том, в кандидатах ли проблема.
С точки же зрения эйчара — они все не подходили.
mikelavr
При этом писать в резюме "знаю TCP/IP" для админа - это примерно как "умею писать ручкой на бумаге".
olartamonov
Недавно присылали вакансию, в которой требовалось знание dmesg. Жаль, не спросил, как он там оказался и зачем.
P.S. А в том случае был не админ, а менеджер довольно высокого уровня, но тем более.
veryboringman
При этом реально знают TCP/IP единицы. Чуть проблема с MTU - все, беда.
Про ipv6 я вообще молчу..
Femistoklov
Так и ручкой на бумаге реально мало кто умеет писать. Чуть надо связное сочинение - всё, беда. Про грамматику я вообще молчу.
urvanov
Ну так они обычно по ключевым словам и просматривают резюме. А после совпадения звонят и оценивают общую адекватность человека. Откуда им знать, что означают все эти термины?
DaneSoul
Если человек даже не знает что означают ключевые термины по которым ведет подбор, то может ему лучше чем-то другим заниматься?
donlocura
у этих странных букавак, которые в резюме пишут люди в графе навыки, есть определенные значения, которые иногда могут включать в себя значения тех странных букавак, которые хочет работодатель, но при этом это разные букавки. прекрасным хуман ресоурсез специалисткам совершенно неоткуда знать значения этих смешных слов, ведь они никогда не работали на настоящей работе. а держат их в компаниях для украшения интерьера ^^)
Earthsea
В данном случае тот, кто поставил задачу, не установил исполнителю порог в 80% совпадения резюме и описания вакансии.
wmlab
Мне однажды отказали после собеседования, потому что у меня были MCP и MSCE, но не было CompTIA A+, а он был в списке рекомендованных сертификатов. HR просто выбирает кандидатов со 100% совпадением. Серьезно, я после этого пошел и сдал этот A+ - там два экзамена с элементарными вопросами. Чтобы просто было.
vanxant
Сертификация именно так и работает. Человеку, который ничего не понимает - обычно менеджеру или, как в данном случае, хрюше - нужна бумажка, которая перекладывает ответственность на кого-то ещё. Она и называется "сертификат".
MiraclePtr
правда нередко эта бумажка просто покупается за $, и все возвращается на круги своя, только с большими затратами для участников процесса.
vanxant
Да и сам процесс сертификации часто напоминает "покупку за $ с некоторыми телодвижениями". Ну типа в конце процесса надо пройти онлайн-тест(ы), ответы на который лежат на каждом углу, ага. Сертифицируется в итоге умение пользоваться Ctrl-F на время.
SpiderEkb
Это много где так. Рейтинговые агентства (даже пресловутый Томсон-Рейтерс) так работают. Это бизнес такой - вы нам деньги и что-нибудь изобразите (не важно что), мы вам бумажку (которая мало что значит)
StanleyOwsleys
Я вам написал в личных сообщениях. Если не сложно, ответьте, пожалуйста.
usv_usv
этого HRa просто неверно проинструктировали.. нужно понять и простить)
dimanhursky
так зачем было писать в вакансии TCP/IP? оно не входит в какие-то другие пункты?
да и как-то много делегировали эйчару без тех знаний.
nlog
Может быть проблема была в том, что эйчар выполнял работу, которую должен выполнять рекрутер?
ssj100
Как понял здесь это совмещенная позиция.
dsh2dsh
По своему опыту я вижу, что рекрутёры ничего не отличаются. Может конечно - это не настоящие рекрутёры, но других я не встречал. Я встречаю только тех, которые мне в linkedin пишут.