В приличных странах, хоть клиенту, может, и позволят это сделать
Скорее даже нет. Ждать одобрения-проведения перевода больше недели - прям вообще нормальная практика. Особенно если межбанковский.
Просто в нормальных системах у простого клиента перевод не может быть одновременно мгновенным, невозвратным и непонятно кому. Как говорится, выбирайте любые два.
Попасть джуном с первого раза в "нормальную компанию" - та ещё лотерея.
Но даже так, к сожалению, тимлид не скринит резюме и не принимает первичное решение об отсеве - этим занимается HR.
Дальше идут этапы собеседований с кучей других людей, которые тоже не тимлид, но решение принимают.
И даже после того, как тимлид принял своё решение, окончательное решение всё же не за ним, так как не он будет платить ЗП.
Так что я бы просто не советовал джунам надеяться "впечатлить коллегу-программиста своим гитхабом и на этом выехать". Викторинные вопросы по программированию, зубрение аббревиатур, умение с улыбкой ответить на "почему вы хотите работать в нашей компании" и прочая клоунада для гуманитариев так и остаётся основным критерием трудоустройства.
От джунов никто кулстори не ждет. Кусочек функционала сделай, баг известный исправь — и ты молодец.
90% людей, которые принимают решение о найме разработчика, не умеют читать код.
Вообще.
Паталогически.
Оставшиеся 10% слишком заняты, чтобы разбираться в каких-то там кандидатско-джуновских гитхабах и пытаться понять, что из этого он сам написал, а что - скопипастил; какая стояла задача и решил ли он её и т.д.
Так что для галочки может и сойдёт иметь что-то на гитхабе, но не более того.
Поговорим о видеоиграх, то есть играх на электронных устройствах (компьютерах, приставках, телефонах и других игровых платформах). Вы играете в видеоигры или нет?
Да, играю 22
Раньше играл, но сейчас не играю 21
Никогда не играл в видеоигры 57
Затрудняюсь ответить 0
И если ответить Да, то задают серию доп.вопросов. Так что в такой ситуации многие ответят "нет", просто потому что не хотят говорить о видеоиграх (или вообще нет времени говорить).
Пару раз после пандемии искал работу, и когда видел неуверенность и что собеседования могут растянуться на месяцы, по своей фрилансерской привычке сразу открыто предлагал "Так давайте я просто как самозанятый на вас месяц-другой поработаю, сами увидите, что всё честно и работаю я хорошо, а там и дороворимся". На что почти всегда получал "нет, у нас всё только по ТК, а что такое работать с самозанятыми мы вообще не знаем".
Давление через суд - неадекватное действие, я думаю Додо уже репутационных потерь набрали столько, что ещё вопрос, не потеряют ли они больше чем получат.
Чем это оно неадекватное действие и какие репутационные потери? Это вполне логичное и ожидаемое действие от вообще любой компании подобного масштаба. Наоборот, были бы репутационные потери, если бы они просто сели сложа руки и сказали "пускай кто угодно выдаёт себя за dodopizza, это не наше дело".
Вот если бы они на какой-нибудь Детский садик Doudou подали в суд, или заставляли бы сменить фамилию какого-нибудь Васю Додоева, то тут ещё понятно бы, неадекватность. Ну или как в случае с Apple и Nissan, когда и в самом деле неоднозначно (хотя даже у них как-то не наблюдается репутационных потерь от этого).
а в чем тут проблема? если люди готовы за товар заплатить в 10 раз больше, он и стоит в 10 раз больше, независимо от того, за сколько его продает производитель.
Ну, стоить (в смысле ценности для покупателя) оно может и в 1000 раз больше - зависит от его жизненной ситуации. Но если позволить менять цену как угодно, то получится ситуация, когда голодному уставшему клиенту накручивают цену в общепите, а тяжело больному - в аптеке. А это противоречит принципу публичной оферты, условно - "если ты сказал, что твой товар сколько-то стоит, то ты не можешь отказаться продавать его кому-то конкретному по этой цене, пока он у тебя в наличии".
ну и не понятно, зачем это сервису продажи билетов, получается он делится с перекупами своей прибылью зачем-то, мог бы просто поднять цены до рыночных
Перекупы тоже могут быть "своими". Но даже если нет, у сервиса есть договорные обязательства с устроителями концертов, они не могут просто сами назначать цены.
Вообще, конечно, это тот ещё вопрос, как справедливо распределить, например, 100 билетов среди 1000 желающих. Должна ли играть роль стоимость, или только кто первый нажал кнопку "купить".
Сами Live Nation вообще предлагают ввести закон, по которому устроитель концерта может назначать максимальную цену перепродажи билета, но тут тоже очень туманно, кто и как должен будет следить за его исполнением.
Не думаю, что могу полностью ответить на вопрос из заголовка, но возможно ПМы просто забивают, когда понимают, что в IT им хоть сколько-нибудь разобраться в этой жизни не светит, а без этого и результат выходит рандомный.
Например, ПМ, который просто не знает/не помнит адрес тестового сервера. Ну вот зачем он ему, он же не тестировщик. Зачем самому смотреть на реальное состояние тасков, когда можно просто раз в день дёрнуть разраба, спросить "как дела" и скопипастить ему недавнее сообщение от заказчика.
Но при этом, когда у него дома идёт ремонт, он и не просто спросит рабочих об используемых материалах, но и почитает-погуглит, разберётся и предложит конкретные альтернативы.
При том же я ни разу не видел, чтобы сроки требовали сразу же при постановке задачи.
Значит, вы ни разу не работали напрямую с заказчиком - мелким/средним бизнесом и частниками. Потому что срок идёт в прямой зависимости от стоимости проекта. А стоимость им нужна ещё до заключения договора. Той же кафешке за 5 т.р. автоматическая умная предлагалка соуса на сайте не помешает, а за 100 т.р. - не, дорого.
И нет, у вас не получится уломать их заплатить 10 т.р. "просто так", за то что разработчик денёк посмотрит, поковыряет их сайт и подумает. Им нужен ощутимый результат. Сделаешь за 5 т.р. - берись, нет - проваливай. Но говори сразу, вотпрямщас.
Одно из отличий профессионала от дилетанта - умение планировать свою работу, в том числе и по времени.
Как раз таки одно из отличий профессионала от дилетанта в том, что он осознаёт все потенциальные подводные камни и их влияние на сроки. И то, что срок - это не цифра, а вероятностная шкала.
Это у дилетанта - "будем считать, что одна кнопка это один час работы. 80 кнопок = 80 часов = 10 дней".
А в реальности не может быть у разработки фичи чёткого срока, например "10 дней". Потому что это всегда вероятности:
Сначала я попробую простой(наивный) подход и это займёт день.
Если он не сработает - тогда второй, более сложный, и это будет неделя.
Если и это не сработает, и вскроются подводные камни от легаси кода и того, что проект вообще на это не рассчитан - то тут вообще всё переписывать нужно будет.
И вот эти "если" будут известны только после того, как сделал и протестил, а не до. В среднем, с учётом вероятностей, это и получится "10 дней", но это уже совсем та самая "средняя температура по больнице" из анекдота.
Нет, конечно, можно себе вообразить программиста, у которого достаточно мозгов, чтобы помнить и в уме мгновенно компилировать сотни мегабайт кода и наперёд знать, что именно и как будет работать, а что - нет, но такой человек бы сейчас торговал акциями на Уолл Стрит, а не сайтики кафешкам бы делал.
Дык, сроки это вообще больная тема, особенно в разработке. Потому что спрашивающий ожидает чёткую цифру (чтобы потом тебя ей долбить), а там всё намного сложнее и каждый раз это объяснять новым людям очень надоедает.
Потому что это, блин, IT-разработка.
Настроить уже готовый функционал - минутное дело. И часто он уже есть в каком-то виде.
А если его нет или попробовал, но он не подходит? Тогда нужно посмотреть, что есть из готовых библиотек или подобного функционала. Это уже часы/дни.
А если нормальных готовых библиотек нет или попробовал и не подходят? Тогда нужно свой код писать, а это уже дни/недели/месяцы.
И как это всё обозначить одной цифрой ещё до начала работ? Да никак. Да и после начала, на любом этапе вплоть до завершения, никогда нет 100% гарантии что ты "уже почти сделал" и твой подход не тупиковый и всё не придётся переделывать с нуля. Поэтому на такие вопросы и не любят отвечать, ни разработчики менеджерам, ни одни менеджеры другим.
Какую зарплату ни ставь, а вайтишников в ответ на вакансию всегда будет больше, чем нужно компании, и даже больше, чем можно в реальные сроки отсеять. Особенно, если мы говорим про известную компанию и удалёнку. И, учитывая зарплату менторов, вайтишники поначалу будут убыточны, даже если работают за 0 рублей.
Зарплата тут определяется единственным фактором - желанием удержать тех, кто таки начнёт подавать надежды через пару месяцев. Противостоянием тому самому "давлению рынка", которое мы и хотим измерить.
Предлагаемая ЗП в компаниях РФ часто больше зависит от "послужного списка", чем от каких-то там грейдов, опыта и квалификаций.
Если в резюме есть легкопроверяемая строчка "работал в Сбердексе за 300к", то такого на 300к возьмут не глядя - в случае чего, у менеджера уже есть, чем прикрыть задницу. А если такой строчки нет, то даже в ООО "Рога и копыта" за 100к будут нос вертеть, будь у кандидата хоть 10 лет опыта и желание "вотпрямщас на реальном проекте его продемострировать".
А для поиска вышедшего на рынок кандидата с заветной строчкой и не нужны вакансии в открытом виде. Вопрос решается ботами и знанием того, кто где закрылся.
Поэтому единственным непредвзятым барометром зарплат в IT можно считать уровень зарплат на вакансиях типа entry-level job "приходи к нам после курсов, всё покажем-расскажем" и уже по нему смотреть повышение-понижение зарплат. А там сейчас, судя по рассказам, тот ещё треш творится.
По большей части согласен, разве что вот с этим абзацем не могу согласиться:
Веди репозиторий так, будто ты работаешь в команде. Помечай коммиты префиксами, старайся чаще коммитить, разделяй ветки на задачи. Всегда готовься быстро вносить / откатывать изменения. Это сэкономит тебе несколько десятков часов в будущем.
Написание кучи отчетов самому себе и полномасштабное ведение репозитория гарантированно потратит десятки часов сейчас, чтобы возможно сэкономить час-два в будущем (скорее всего нет). Обычно более чем достаточно просто время от времени сохранять промежуточные версии с датами.
Вспоминать и восстанавливать что-то, написанное год-два назад - всегда головная боль, даже с самыми подробными коммитами. И даже при работе в команде обычно всё сводится к тому, что "втопку всё, быстрее будет просто переписать эту фичу без оглядки на старый код, там уже слишком много всего поменялось". Но в команде-то репозиторий хоть имеет смысл использовать, но по другим причинам.
Чтобы быстро вносить/откатывать изменения, процесс внесения/отката изменений должен содержать минимальное количество телодвижений.
Например, поменял цифру в конфиге, ctrl+s, залил файл. Потестил.
Всё сломалось? Ctrl-z, ctrl-s, залил файл. Может, комментарий написал рядом, мол "тут не меняй, а то всё ломается". Занимает секунды.
Делать то же самое по всем регламентам через репозиторий - на порядки дольше.
Ну, то есть, вероятно, сначала они попробовали указать расу прямым текстом в резюме - сенсационной картины не получилось (иначе бы об этом написали).
Потом они попробовали указать оттенок цвета кожи - тоже сенсации не получилось.
Потом попробовали указывать только пол - тоже сенсации не получилось.
Потом попробовали указывать имена из определённых групп в связке с полом - и вот, монетка упала три раза орлом подряд, можно писать статью.
Журналисты также провели похожие опыты с более продвинутой GPT 4. По их словам, эта модель тоже демонстрирует явные предпочтения, хотя и не предоставили каких-либо результатов этого эксперимента.
Потом попробовали GPT4 и там ничего не получилось, но упомянуть всё равно можно.
То есть, отработав 8 часов программистом в офисе, он торопится домой, чтобы заняться тем, что ему нравится - программированием (любимым пет-проектом, захватывающей книгой, интересной задачей).
Ну, или тем, что не успел доделать за 8 часов, но лучше доделать сегодня, ибо завтра уже забудешь, на чём остановился.
Или вторым (третьим, четвертым) проектом по совместительству, который "очень просили посмотреть".
Или решением бесконечных проблем домочадцев с их компами / телефонами / умными холодильниками.
Так на интересности-хотелки уже и часов в сутках не останется.
И это, увы, массовая тенденция среди современных программистов: "моя задача - тикеты в джире закрывать, а зачем это надо - пусть ПМ думает". Разработчики вообще не представляют и не хотят представлять сути бизнес-процессов, которые они автоматизируют, в итоге деградируют до обычных кодеров.
Да разработчик может сколько угодно представлять и понимать, но если ему сказали весь день точить карандаши, то он будет весь день точить карандаши. Он не может сказать "не, не буду", может только высказать своё мнение о том, что это неэффективно. И в любом случае его скилл невозможно будет оценить по тому, сколько денег/пользы/репутации он принёс в этот день компании.
3 человека, понимаете? Не десяток, не сотня.
Ну мы вообще, порой, и на двоих все эти обязанности делили, если совсем мелкий проект, но даже это не даёт мне право хвастаться, что "я сделал очень полезный дэшборд". Когда говорили делать полезный - делал полезный. Когда говорили делать какую-то ерунду - говорил, что эти метрики неполные, неточные и будут отражать погоду на марсе, на что получал "а ты всё равно сделай, а мы посмотрим". И в итоге делал, и потом "ну да, и в самом деле ерунда какая-то получилась, ну ладно, для отчета сойдёт, а ты пока вынеси это на отдельную вкладку, с глаз долой".
Поэтому тут и смысл на собесе говорить, выполнял задачи или нет, а приписывать себе в заслуги всю работу команды и ещё и результат от неё - просто очевидное враньё.
«Создал дашборд со всеми метриками компании – «Зачем?» – чтобы руководители отслеживали эффективность каждого отдела»
Первое приведено в качестве плохого примера, а второе - в качестве хорошего, хотя по сути, это одно и то же. И по-моему, первый ответ даже более резонный.
Во-первых, у нормальных работников за N лет работы скапливается куча выполненных работ, одно только перечисление которых займёт больше 30 минут. И ограничиваться тут упоминанием одного дэшборда - враньё, только идущее себе во вред.
Во-вторых, не всегда на собесе есть время объяснять гуманитарию, что такое, например, рефакторинг легаси кода, для чего он выполняется и какую пользу он приносит.
В-третьих - если уж мы говорим о результате, то он как раз в том, чтобы выполнять поставленные задачи, а не в том, чтобы делать условный дэшборд (который, может, никто и не просил или он был не приоритетным). И тут если уж сказали "своевременность отчетов важнее своевременности работы", то, будь добр, пиши отчеты. А такое в самом деле порой говорят, и иногда это даже обоснованно.
Ну и напоследок, в реальности не бывает такого, когда работник просто взял и "создал дэшборд". Кто-то выбирал метрики, кто-то писал документацию и ТЗ, кто-то собирал данные, кто-то решал, где и как они будут храниться, кто-то прописывал алгоритмы их подсчета, кто-то дизайнил, кто-то кодил фронт, кто-то кодил бэк, кто-то проверял, кто-то руководил, кто-то допиливал и поддерживал. Иногда один работник может выполнять несколько из этих функций, но не все сразу. И это я говорю как разработчик, который несколько лет зарабатывал на хлеб исключительно "созданием дэшбордов".
Не, я как бы понимаю, что существует позиция HR в виде "я не хочу ни в чём разбираться, кандидат, просто скажи мне, что ты единолично принёс прошлой компании миллиард долларов, чтобы мне было чем прикрыть задницу, когда я вынесу положительное решение по интервью", но вполне очевидно, к каким последствиям для найма приводит такая позиция.
Я вижу пользователей проприетарного и открытого по разным.
Первые скорее всего не читают лицензию. Их не особо интересует кто и как создал это по. Люди, которые жмут далее далее далее. Не хочу никак оскорбить их. Я тоже частично такой. Но, я думаю, они в меньшей степени считают себя ответственными за установленное по. Для них вполне нормально винить автора в ошибках, будто он что-то им должен (особенно если они заплатили).
С другой стороны вторые - они сами берут на себя ответственность за устанавливаемое по. Они не считают, что автор им что-то должен. Даже если он написал, что это супер пупер крутая библиотека
Я вижу это скорее как ожидания от разных классов программ.
Проприетарное и даже платное ПО может быть ожидаемо плохим - инди игра на стиме может даже не иметь меню настроек. Но если программа позиционируется как серьёзный графический редактор, конкурент Photoshop, то тут уже предполагается что UI не просто есть, а ещё и проработанный. Может, не в таких мелочах как у автора изначального комментария, но в целом да, даже если это бесплатный опенсорс.
Тут либо серьёзное профессиональное ПО, на которое можно положиться, либо "а что ты хотел, скажи спасибо, что хоть какое-то".
Скорее даже нет. Ждать одобрения-проведения перевода больше недели - прям вообще нормальная практика. Особенно если межбанковский.
Просто в нормальных системах у простого клиента перевод не может быть одновременно мгновенным, невозвратным и непонятно кому. Как говорится, выбирайте любые два.
Хм, интересно. Рад, что где-то ещё бывают нормальные процессы найма.
Попасть джуном с первого раза в "нормальную компанию" - та ещё лотерея.
Но даже так, к сожалению, тимлид не скринит резюме и не принимает первичное решение об отсеве - этим занимается HR.
Дальше идут этапы собеседований с кучей других людей, которые тоже не тимлид, но решение принимают.
И даже после того, как тимлид принял своё решение, окончательное решение всё же не за ним, так как не он будет платить ЗП.
Так что я бы просто не советовал джунам надеяться "впечатлить коллегу-программиста своим гитхабом и на этом выехать". Викторинные вопросы по программированию, зубрение аббревиатур, умение с улыбкой ответить на "почему вы хотите работать в нашей компании" и прочая клоунада для гуманитариев так и остаётся основным критерием трудоустройства.
90% людей, которые принимают решение о найме разработчика, не умеют читать код.
Вообще.
Паталогически.
Оставшиеся 10% слишком заняты, чтобы разбираться в каких-то там кандидатско-джуновских гитхабах и пытаться понять, что из этого он сам написал, а что - скопипастил; какая стояла задача и решил ли он её и т.д.
Так что для галочки может и сойдёт иметь что-то на гитхабе, но не более того.
Там телефонный опрос, судя по первоисточнику.
И если ответить Да, то задают серию доп.вопросов. Так что в такой ситуации многие ответят "нет", просто потому что не хотят говорить о видеоиграх (или вообще нет времени говорить).
Наблюдал прямо противоположную ситуацию.
Пару раз после пандемии искал работу, и когда видел неуверенность и что собеседования могут растянуться на месяцы, по своей фрилансерской привычке сразу открыто предлагал "Так давайте я просто как самозанятый на вас месяц-другой поработаю, сами увидите, что всё честно и работаю я хорошо, а там и дороворимся". На что почти всегда получал "нет, у нас всё только по ТК, а что такое работать с самозанятыми мы вообще не знаем".
Чем это оно неадекватное действие и какие репутационные потери? Это вполне логичное и ожидаемое действие от вообще любой компании подобного масштаба. Наоборот, были бы репутационные потери, если бы они просто сели сложа руки и сказали "пускай кто угодно выдаёт себя за dodopizza, это не наше дело".
Вот если бы они на какой-нибудь Детский садик Doudou подали в суд, или заставляли бы сменить фамилию какого-нибудь Васю Додоева, то тут ещё понятно бы, неадекватность. Ну или как в случае с Apple и Nissan, когда и в самом деле неоднозначно (хотя даже у них как-то не наблюдается репутационных потерь от этого).
Ну, стоить (в смысле ценности для покупателя) оно может и в 1000 раз больше - зависит от его жизненной ситуации. Но если позволить менять цену как угодно, то получится ситуация, когда голодному уставшему клиенту накручивают цену в общепите, а тяжело больному - в аптеке. А это противоречит принципу публичной оферты, условно - "если ты сказал, что твой товар сколько-то стоит, то ты не можешь отказаться продавать его кому-то конкретному по этой цене, пока он у тебя в наличии".
Перекупы тоже могут быть "своими". Но даже если нет, у сервиса есть договорные обязательства с устроителями концертов, они не могут просто сами назначать цены.
Вообще, конечно, это тот ещё вопрос, как справедливо распределить, например, 100 билетов среди 1000 желающих. Должна ли играть роль стоимость, или только кто первый нажал кнопку "купить".
Сами Live Nation вообще предлагают ввести закон, по которому устроитель концерта может назначать максимальную цену перепродажи билета, но тут тоже очень туманно, кто и как должен будет следить за его исполнением.
Не думаю, что могу полностью ответить на вопрос из заголовка, но возможно ПМы просто забивают, когда понимают, что в IT им хоть сколько-нибудь разобраться в этой жизни не светит, а без этого и результат выходит рандомный.
Например, ПМ, который просто не знает/не помнит адрес тестового сервера. Ну вот зачем он ему, он же не тестировщик. Зачем самому смотреть на реальное состояние тасков, когда можно просто раз в день дёрнуть разраба, спросить "как дела" и скопипастить ему недавнее сообщение от заказчика.
Но при этом, когда у него дома идёт ремонт, он и не просто спросит рабочих об используемых материалах, но и почитает-погуглит, разберётся и предложит конкретные альтернативы.
Значит, вы ни разу не работали напрямую с заказчиком - мелким/средним бизнесом и частниками. Потому что срок идёт в прямой зависимости от стоимости проекта. А стоимость им нужна ещё до заключения договора. Той же кафешке за 5 т.р. автоматическая умная предлагалка соуса на сайте не помешает, а за 100 т.р. - не, дорого.
И нет, у вас не получится уломать их заплатить 10 т.р. "просто так", за то что разработчик денёк посмотрит, поковыряет их сайт и подумает. Им нужен ощутимый результат. Сделаешь за 5 т.р. - берись, нет - проваливай. Но говори сразу, вотпрямщас.
Как раз таки одно из отличий профессионала от дилетанта в том, что он осознаёт все потенциальные подводные камни и их влияние на сроки. И то, что срок - это не цифра, а вероятностная шкала.
Это у дилетанта - "будем считать, что одна кнопка это один час работы. 80 кнопок = 80 часов = 10 дней".
А в реальности не может быть у разработки фичи чёткого срока, например "10 дней". Потому что это всегда вероятности:
Сначала я попробую простой(наивный) подход и это займёт день.
Если он не сработает - тогда второй, более сложный, и это будет неделя.
Если и это не сработает, и вскроются подводные камни от легаси кода и того, что проект вообще на это не рассчитан - то тут вообще всё переписывать нужно будет.
И вот эти "если" будут известны только после того, как сделал и протестил, а не до. В среднем, с учётом вероятностей, это и получится "10 дней", но это уже совсем та самая "средняя температура по больнице" из анекдота.
Нет, конечно, можно себе вообразить программиста, у которого достаточно мозгов, чтобы помнить и в уме мгновенно компилировать сотни мегабайт кода и наперёд знать, что именно и как будет работать, а что - нет, но такой человек бы сейчас торговал акциями на Уолл Стрит, а не сайтики кафешкам бы делал.
Дык, сроки это вообще больная тема, особенно в разработке. Потому что спрашивающий ожидает чёткую цифру (чтобы потом тебя ей долбить), а там всё намного сложнее и каждый раз это объяснять новым людям очень надоедает.
Потому что это, блин, IT-разработка.
Настроить уже готовый функционал - минутное дело. И часто он уже есть в каком-то виде.
А если его нет или попробовал, но он не подходит? Тогда нужно посмотреть, что есть из готовых библиотек или подобного функционала. Это уже часы/дни.
А если нормальных готовых библиотек нет или попробовал и не подходят? Тогда нужно свой код писать, а это уже дни/недели/месяцы.
И как это всё обозначить одной цифрой ещё до начала работ? Да никак. Да и после начала, на любом этапе вплоть до завершения, никогда нет 100% гарантии что ты "уже почти сделал" и твой подход не тупиковый и всё не придётся переделывать с нуля. Поэтому на такие вопросы и не любят отвечать, ни разработчики менеджерам, ни одни менеджеры другим.
Нейросеть на присланных картинках тренировали *пожимает плечами*
Бум курсов никак не влияет на эту зарплату.
Какую зарплату ни ставь, а вайтишников в ответ на вакансию всегда будет больше, чем нужно компании, и даже больше, чем можно в реальные сроки отсеять. Особенно, если мы говорим про известную компанию и удалёнку. И, учитывая зарплату менторов, вайтишники поначалу будут убыточны, даже если работают за 0 рублей.
Зарплата тут определяется единственным фактором - желанием удержать тех, кто таки начнёт подавать надежды через пару месяцев. Противостоянием тому самому "давлению рынка", которое мы и хотим измерить.
Предлагаемая ЗП в компаниях РФ часто больше зависит от "послужного списка", чем от каких-то там грейдов, опыта и квалификаций.
Если в резюме есть легкопроверяемая строчка "работал в Сбердексе за 300к", то такого на 300к возьмут не глядя - в случае чего, у менеджера уже есть, чем прикрыть задницу. А если такой строчки нет, то даже в ООО "Рога и копыта" за 100к будут нос вертеть, будь у кандидата хоть 10 лет опыта и желание "вотпрямщас на реальном проекте его продемострировать".
А для поиска вышедшего на рынок кандидата с заветной строчкой и не нужны вакансии в открытом виде. Вопрос решается ботами и знанием того, кто где закрылся.
Поэтому единственным непредвзятым барометром зарплат в IT можно считать уровень зарплат на вакансиях типа entry-level job "приходи к нам после курсов, всё покажем-расскажем" и уже по нему смотреть повышение-понижение зарплат. А там сейчас, судя по рассказам, тот ещё треш творится.
По большей части согласен, разве что вот с этим абзацем не могу согласиться:
Написание кучи отчетов самому себе и полномасштабное ведение репозитория гарантированно потратит десятки часов сейчас, чтобы возможно сэкономить час-два в будущем (скорее всего нет). Обычно более чем достаточно просто время от времени сохранять промежуточные версии с датами.
Вспоминать и восстанавливать что-то, написанное год-два назад - всегда головная боль, даже с самыми подробными коммитами. И даже при работе в команде обычно всё сводится к тому, что "втопку всё, быстрее будет просто переписать эту фичу без оглядки на старый код, там уже слишком много всего поменялось". Но в команде-то репозиторий хоть имеет смысл использовать, но по другим причинам.
Чтобы быстро вносить/откатывать изменения, процесс внесения/отката изменений должен содержать минимальное количество телодвижений.
Например, поменял цифру в конфиге, ctrl+s, залил файл. Потестил.
Всё сломалось? Ctrl-z, ctrl-s, залил файл. Может, комментарий написал рядом, мол "тут не меняй, а то всё ломается". Занимает секунды.
Делать то же самое по всем регламентам через репозиторий - на порядки дольше.
Ну, то есть, вероятно, сначала они попробовали указать расу прямым текстом в резюме - сенсационной картины не получилось (иначе бы об этом написали).
Потом они попробовали указать оттенок цвета кожи - тоже сенсации не получилось.
Потом попробовали указывать только пол - тоже сенсации не получилось.
Потом попробовали указывать имена из определённых групп в связке с полом - и вот, монетка упала три раза орлом подряд, можно писать статью.
Потом попробовали GPT4 и там ничего не получилось, но упомянуть всё равно можно.
Ну, или тем, что не успел доделать за 8 часов, но лучше доделать сегодня, ибо завтра уже забудешь, на чём остановился.
Или вторым (третьим, четвертым) проектом по совместительству, который "очень просили посмотреть".
Или решением бесконечных проблем домочадцев с их компами / телефонами / умными холодильниками.
Так на интересности-хотелки уже и часов в сутках не останется.
Да разработчик может сколько угодно представлять и понимать, но если ему сказали весь день точить карандаши, то он будет весь день точить карандаши. Он не может сказать "не, не буду", может только высказать своё мнение о том, что это неэффективно. И в любом случае его скилл невозможно будет оценить по тому, сколько денег/пользы/репутации он принёс в этот день компании.
Ну мы вообще, порой, и на двоих все эти обязанности делили, если совсем мелкий проект, но даже это не даёт мне право хвастаться, что "я сделал очень полезный дэшборд". Когда говорили делать полезный - делал полезный. Когда говорили делать какую-то ерунду - говорил, что эти метрики неполные, неточные и будут отражать погоду на марсе, на что получал "а ты всё равно сделай, а мы посмотрим". И в итоге делал, и потом "ну да, и в самом деле ерунда какая-то получилась, ну ладно, для отчета сойдёт, а ты пока вынеси это на отдельную вкладку, с глаз долой".
Поэтому тут и смысл на собесе говорить, выполнял задачи или нет, а приписывать себе в заслуги всю работу команды и ещё и результат от неё - просто очевидное враньё.
Первое приведено в качестве плохого примера, а второе - в качестве хорошего, хотя по сути, это одно и то же. И по-моему, первый ответ даже более резонный.
Во-первых, у нормальных работников за N лет работы скапливается куча выполненных работ, одно только перечисление которых займёт больше 30 минут. И ограничиваться тут упоминанием одного дэшборда - враньё, только идущее себе во вред.
Во-вторых, не всегда на собесе есть время объяснять гуманитарию, что такое, например, рефакторинг легаси кода, для чего он выполняется и какую пользу он приносит.
В-третьих - если уж мы говорим о результате, то он как раз в том, чтобы выполнять поставленные задачи, а не в том, чтобы делать условный дэшборд (который, может, никто и не просил или он был не приоритетным). И тут если уж сказали "своевременность отчетов важнее своевременности работы", то, будь добр, пиши отчеты. А такое в самом деле порой говорят, и иногда это даже обоснованно.
Ну и напоследок, в реальности не бывает такого, когда работник просто взял и "создал дэшборд". Кто-то выбирал метрики, кто-то писал документацию и ТЗ, кто-то собирал данные, кто-то решал, где и как они будут храниться, кто-то прописывал алгоритмы их подсчета, кто-то дизайнил, кто-то кодил фронт, кто-то кодил бэк, кто-то проверял, кто-то руководил, кто-то допиливал и поддерживал. Иногда один работник может выполнять несколько из этих функций, но не все сразу. И это я говорю как разработчик, который несколько лет зарабатывал на хлеб исключительно "созданием дэшбордов".
Не, я как бы понимаю, что существует позиция HR в виде "я не хочу ни в чём разбираться, кандидат, просто скажи мне, что ты единолично принёс прошлой компании миллиард долларов, чтобы мне было чем прикрыть задницу, когда я вынесу положительное решение по интервью", но вполне очевидно, к каким последствиям для найма приводит такая позиция.
Я вижу это скорее как ожидания от разных классов программ.
Проприетарное и даже платное ПО может быть ожидаемо плохим - инди игра на стиме может даже не иметь меню настроек. Но если программа позиционируется как серьёзный графический редактор, конкурент Photoshop, то тут уже предполагается что UI не просто есть, а ещё и проработанный. Может, не в таких мелочах как у автора изначального комментария, но в целом да, даже если это бесплатный опенсорс.
Тут либо серьёзное профессиональное ПО, на которое можно положиться, либо "а что ты хотел, скажи спасибо, что хоть какое-то".