За последнее время мне довелось провести немало технических собеседований на позицию DevOps инженера, в связи с чем появилась идея формализовать полученные выводы в этой статье. Хочу поделиться своими наблюдениями, субъективным мнением, и задать самому себе вопросы, ответы на которые, возможно, мне помогут получить читатели данной статьи.
Я понимаю, что под определение так называемого DevOps инженера от компании к компании подпадает очень разный набор навыков, следовательно, требования также будут заметно варьироваться. Поэтому попробую описать что такое DevOps инженер, или SRE (как мне привычнее) для меня в рамках нынешней организации: специалист, поддерживающий инфраструктуру проекта на всех уровнях, реализующий автоматизацию инфраструктуры, процессов разработки и тестирования, в некоторой степени DBA, конечно SRE и евангелист DevOps культуры. Так как цель статьи в другом, то не хотелось бы тут размышлять на тему того, кто такой DevOps инженер, существует ли он, маркетинговый ли это термин и вот это вот всё, оставим этот холивар. Я думаю, что в основном понятно, о каких специалистах я говорю.
Я являюсь тимлидом команды именно таких инженеров. Мы не профилируемся внутри команды по направлениям, каждый занимается бóльшей частью из перечисленного.
Пару слов о кандидатах
Встречают по одежке. Одежкой в нашем случае является резюме соискателя.
Просматривая резюме, полученные от HR, которые прошли первичные фильтры и соответствуют корпоративным нормам, глаз радуется, представляется, если не полностью, то очень сильно удовлетворяющий ожиданиям кандидат. Ощущается прилив радости, и появляется настрой на интересный продуктивный для обеих сторон разговор.
Как правило, кандидаты - это люди разных возрастов и из разных стран, имеющих опыт работы в компаниях разного размера и рода деятельности, иногда с немалым опытом администрирования различных nix систем, с опытом автоматизации инфраструктуры и процессов разработки/тестирования, взаимодействия с базами данных, кластерными системами, и, конечно же, с серьезными ожиданиями по заработной плате (серьёзность запросов по ЗП относительна, имеются в виду мощные запросы в рамках условного грейда). Многие не хотят участвовать в мелком предварительном тестировании, обосновывая это неприемлемой тратой времени.
Немного о первичном отборе. Он представляет из себя традиционное вводное знакомство с HR. HR не проводит предварительного технического интервью, а лишь субъективно оценивает опыт кандидата, стремясь удовлетворить пожеланиям команды, находящейся в процессе поиска.
В рамках технического интервью, проводимых для поиска новых специалистов, я общаюсь с кандидатами, разделяя разговор на два больших блока: фундаментальные темы (операционные системы, сети, базы данных, методологии, точечно прочие компьютерные науки) и инструментарий (здесь может быть всё что угодно, Ansible, Terraform, Helm, Kubernetes, контейнеры, скриптинг, реализация конкретной небольшой задачи в определенных условиях и так далее). В среднем, общаемся в районе полутора часов, за которые я прихожу всё чаще к тем выводам, о которых буду рассказывать далее, и которые подчеркивают тему данной статьи.
Ниже приведу несколько вопросов и частые ответы кандидатов. Замечу, что среди отвечающих были преподаватели онлайн школ и сертифицированные специалисты по разным технологиям/облакам/методологиям.
Зачем мне что-то знать про память, всё же в кубере
Это та мысль, которую в разных формулировках я слышу очень часто от соискателей. Приходим мы к этому умозаключению после того, как я задаю свой первый вопрос про то, сколько памяти занимает процесс с указанным PID (кандидату демонстрируется скриншот или экран с выводом top). 80% соискателей с опытом администрирования nix систем не знают ответ, теряются или говорят очень странные вещи, 10% без объяснения выбора способны указать на колонку RES, и оставшиеся с разным успехом могут поговорить и порассуждать про виртуальное адресное пространство, разделяемую память, OOM, оверкоммиты, стэки, кучи и так далее.
Приведенный вопрос, как и любой другой в рамках собеседования, может получить множественное развитие как в глубину, так и в ширину, но происходит это крайне редко. Не совсем понятно, каким образом такой инженер выставляет адекватные реквесты/лимиты приложению в кубере, каким образом задаёт max-old-space-size для V8 (и делает ли это вообще). Может быть вопрос действительно лишний (пусть не всё, но большинство приложений же в кубере) и морально устарел?
Сети... Это всегда было не моё, а в облаках оно вообще не актуально
Следующая частая формулировка, которая появляется после вопросов про понимание, например, маски подсети или TCP-сессии. То есть инженер работает с кластерными системами, с кубером, наливает ансиблом большие группы узлов, а сети, получается, это что-то лишнее, недосягаемое? Видимо, во всем многообразии "сетевых" процессов вряд ли что-то может пойти не так, а в случае чего, лучше, наверное, нанять отдельного специалиста, который умеет запускать ping, traceroute и dig, да ещё и понимать их выхлоп.
Вряд ли же придётся заниматься дебагом NAT в облаках при множественных подключениях изнутри (при наличии единственного IP адреса на облачном маршрутизаторе), вряд ли нужно будет разбираться, почему пакетики из одного региона страны не доходят в облако до приложения, вряд ли понадобится VPN до API облачного кубера. И ведь действительно, вопросы сетевого взаимодействия в 2023-ем уже могли изжить себя?
HTTP GET используется только для получения информации
Это 90% ответов на просьбу сравнить GET и POST методы. Мы говорим тут про GET и POST как таковые, не привязываясь, например, к CRUD для REST. Возможно, понимать суть и отличие данных методов сегодня действительно не нужно, ведь всегда есть документация к API, а разработчик никогда не реализует метод против стандартов?
Почему у вас нет Argo CD?
Встречный вопрос, который я получаю в контексте беседы про GitOps как в нашей реализации, так и в целом. То есть для многих соискателей есть прямая и неразрывная связь между GitOps подходом и инструментом, реализующим его, при этом беседа про абстрактный GitOps, не привязанный к инструментам, вызывает бурю негодований и странное предвзятое отношение.
Другим ярчайшим и популярным примером про неразрывность инструментов и методологий, как мне кажется, является разговор про CI/CD. Зачастую, CI/CD - это Gitlab CI, Teamcity или Jenkins, а не методологии, решающие конкретный список проблем/задач в процессах разработки, для удобной реализации которых есть готовые, ранее перечисленные инструменты. Кажется, пришло время внедрять Argo CD, мы же GitOps делаем?
Приведенные примеры подчеркивают нежелание большого количества нынешних специалистов погружаться в вопрос и разбираться в теме, что не может радовать. Бывали случаи, когда кандидаты не просто показывали незнание по тому или иному вопросу, а вступали в конфликт о том, что не должно быть таких, как мы задаём, глубоких вопросов на собеседовании DevOps инженеров, не должно быть бóльшей части затронутых тем. И всё бы ничего, но расстраивает факт отстранения работников интеллектуального труда от своей непосредственной деятельности, не желая о ней думать. Такое происходит конечно же не только в рамках DevOps инженеров, а распространяется и на другие направления, что я могу наблюдать, общаясь с соискателями на позиции бэкенд разработчиков и тестировщиков.
По описанным выше вопросам становится понятно, что ничего из ряда вон мы не требуем, нормальные инженерные вопросы, которые с разных сторон пытаются раскрыть кандидата. Мы не гоняем по алгоритмам, не просим спроектировать нагруженный онлайн видео сервис в масштабах планеты (хотя, системный дизайн был бы классным модулем), да и не просим тонко под задачу затюнить СУБД, но как ни крути, только лишь опыт использования облачного K8s вместе с Ansible на несколько узлов и деплой всего через Gitlab CI, не является для нас достаточным, как уже должно быть понятно из описания в начале статьи.
Я понимаю, что далеко не везде желаемые мной запросы к кандидатам. На рынке немало мест, на которых поверхностное понимание инструментария является достаточным, а какие-то более глубокие проблемы решают местные гуру. Может ли это говорить о том, что ИТ как сфера приходит к более четкому квалификационному разделению? Может ли это говорить о том, что насыщения рынка соискателями, владеющих лишь инструментарием, станет со временем трендом и стоит ли переживать на этот счет? И да, ни в коем случае не хочу сказать, что я тут один тут стою в пальто белом, я всего лишь рассуждаю “вслух” о сложившейся вокруг меня ситуации.
Выводы
Резюме не имеет ничего общего с реальными знаниями и навыками соискателя.
Многих интересуют только зарплаты, без реального увлечения технологиями.
Фундаментальные, нетленные знания пугают соискателей, всерьёз не воспринимаются как необходимые, иногда вызывают улыбки.
Большинство соискателей видят роль DevOps инженера следующим образом: YAML, какая-нибудь технология контейнеризации (на уровне пользователя), какая-нибудь система оркестрации (на уровне пользователя), Terraform, Ansible.
Эти же соискатели не согласны с тем, что DevOps инженер это: основы операционных систем, основы баз данных, основы сетей, основы распределенных систем, любые другие основы, не связанные с верхнеуровневым инструментарием и перекладыванием конфигов, для получения очередной абстракции.
В чем я могу ошибаться
Я считаю себя энтузиастом в ИТ, для меня это не только работа, но и одно из увлечений, в связи с чем могут проявляться завышенные ожидания к соискателям.
Субъективное ощущение реальности и рынка, выстраивают неверный набор запросов и уровень ожидаемых ответов. Мой личный и сторонний (коллеги, статьи и т. п.) опыт собеседований в крупные и небольшие ИТ компании, склоняет меня в сторону тех примеров, в которых присутствовал более жесткий отбор с более высокими требованиями.
Наличие слишком малой, нерепрезентативной выборки, приводящей к ошибочным умозаключениям о соискателях.
Вопросы без ответа
Не слишком ли широкий спектр обязанностей падает на каждого инженера в нашей команде, может быть нужно делиться по профилям?
Может быть я неправильно (или крайне неудачно) подобрал блоки вопросов для собеседования?
Что мы можем улучшить, как ужесточить фильтр на этапе отбора резюме и первичного общения с HR для обеспечения наиболее продуктивного общения на всех последующих этапах, но при этом не отпугнуть кандидата?
Комментарии (772)
stackjava
12.06.2023 16:23+3Вы просто идете вместе с нарастающим трендом:
не важно кто ты в ИТ мире - ты должен знать свою область на 200%, а все что смежное хотя бы на 100%
Рынок становится таким... Много соискателей, конкуренция нарастает...
Лет через 5 сможете выбирать лучшего из толпы горящих глазами, для кого ИТ - это его жизнь... Остальных медленно выдавит с рынка эта проактивная ит масса.
onyxmaster
12.06.2023 16:23+31Ой не знаю. От поиска коллег в этом году плакать хочется (бэкендера ищу). Ноль любопытства, тестовое делать не буду, кода чтобы показать нет, потому что негоже работать после работы, хочу 400к. На собеседовании основная фраза «я точно не помню».
vvf1973
12.06.2023 16:23+30Эта проблема касается практически всех профессий. Найти не рукожопа от сантехника до врача - тот ещё квест. Привет от Айн Рэнд.
Source
12.06.2023 16:23+15Кстати, да. Я иногда задумываюсь, в каком изумительно-восхитительном мире мы бы жили, если бы каждый человек просто стремился качественно выполнять свою работу.
MonteDegro
12.06.2023 16:23+6Если не ошибаюсь, идеи Рэнд реализованы в Биошоке. Затрудняюсь назвать тамошний мир изумительно-восхитительным(
onyxmaster
12.06.2023 16:23+3Ну Биошок это вполне себе иллюстрация превосходства недостатков человека. Так что это скорее не "идеи Рэнд реализованы", а "в очередной раз продемонстрировано, что идеи Рэнд нереализуемы" =)
0xd34df00d
12.06.2023 16:23+10В Биошоке реализован авторский ответ на авторское же понимание идей Рэнд, которые в свою очередь являются художественным (в этом случае — от слова «худо») изложением некоей другой системы воззрений.
Я бы не стал делать по Биошоку какие-то далеко идущие выводы. Это не то что Вася напел Beatles, это Вася сделал ремикс на перепев Пети.
atomikf
12.06.2023 16:23+2Ну так это ведь игра, шутер с закрученным сюжетом. Он был сделан, чтобы интересно было играть, или вы бы предпочли, чтобы в Биошок протагонист попадал в утопичный, успешный мир и просто ежедневно ходил на работу?
Format-X22
12.06.2023 16:23+2Вроде как Postal 2 можно было так пройти, ведь купить молоко и попросить подписи для петиций можно и вежливо.
edogs
12.06.2023 16:23+6Я иногда задумываюсь, в каком изумительно-восхитительном мире мы бы жили, если бы каждый человек просто стремился качественно выполнять свою работу.
Это точка зрения владельца компании:) Как было бы хорошо, если бы все сотрудники думали о нуждах компании, а не о своей выгоде.
Hardcoin
12.06.2023 16:23Если выгода заключается в деньгах, плюшках или повышении - о ней думать надо. А вот о выгоде как бы схалтурить, не напрягаться и не осваивать нового действительно можно думать по-меньше. Это видно и когда нанимаешь кого-то в частном порядке. Кто-то думает о выгоде в виде оплаты за хорошую работу, а кто-то - и так сойдёт, сделать бы хоть как-нибудь. Тут выгода работника только в том, что бы меньше напрячься.
edogs
12.06.2023 16:23+11А вот о выгоде как бы не напрягаться действительно можно думать по-меньше.
Не раньше чем владелец компании начнет думать не о максимизации прибыли компании, а о максимизации зарплат.
Hardcoin
12.06.2023 16:23+2Ну какой ещё владелец, если я сантехника на дом вызвал? Он говорит - 5 тысяч. Я говорю - окей. И что, ему можно (с моральной точки зрения) сделать мне халтуру только потому, что я не подумал о максимизации его дохода? Может я смог бы ему 20 заплатить или даже кредит для него взять - только после этого он начнет думать, как бы сделать хорошо? И то не факт?
Хорошо, что такой подход не всегда встречается. Знать бы заранее у кого он такой, как у вас, что бы не работать с ними.
edogs
12.06.2023 16:23-1ему можно (с моральной точки зрения) сделать мне халтуру
Поставленная задача бывает либо выполнена по заданным стандартам, либо не выполнена. "Халтура" это термин выдуманный заказчиками, которым очень не хочется платить, но объективно докопаться не до чего.
Может я смог бы ему 20 заплатить
Но наняли-то на 5к. На 5к и получили.
Это всё равно что разместить вакансию с оплатой 60к, нанять прогера на эту зарплату, а потом предъявлять ему претензии за "халтуру", потому что он выдает качество не на 200к, которые Вы возможно могли бы ему заплатить.
GerrAlt
12.06.2023 16:23+19Лично мое мнение что делать некачественно - непрофессионально, не важно за какие деньги, т.к. ты же за них согласился работать. Если деньги тебя не устраивают - не соглашаешься, если согласился - делаешь насколько можешь хорошо
edogs
12.06.2023 16:23-1Лично мое мнение что делать некачественно - непрофессионально
"Сделать некачественно" это оксиморон. Если работа не соответствует заданному стандарту качества, то она не сделана и оплате не подлежит.
venanen
12.06.2023 16:23+7От чего же? Сделать некачественно - это типичная обыденность. Как пример - нужно отремонтировать станок. То есть ТЗ простое: оно не работает, должно заработать. По нормам нужен болт классом 9.9, но такого нет, идти за ним лень, есть болт класса эдак 5. В результате ставится этот болт, станок починен, заработает и проработает какое-то время. ТЗ выполнено? Выполнено. Качественно? Нет.
edogs
12.06.2023 16:23+1По нормам нужен болт классом 9.9, , есть болт класса эдак 5. ТЗ выполнено? Выполнено.
Нет, не выполнено. И нам сейчас реально страшно, если Вы нас не троллите, а говорите это на полном серьезе.
Попробуем нагляднее. Завтра Вас попросят починить холодильник, Вы сделаете так что бы в морозилке было +3 градуса и сочтете это выполненной работой? Сославшись на то, что мол "ну работает же". Вы, блин, серьезно?!
PuerteMuerte
12.06.2023 16:23+11Попробуем нагляднее. Завтра Вас попросят починить холодильник, Вы сделаете так что бы в морозилке было +3 градуса
А если он сделает так, что в морозилке будут положенные -20 градусов, но через полгода плохо запаянная трубка опять треснет? Стандарт качества - штука совершенно условная. Она оговаривает какие-то частные условия, оставляя "за бортом" массу других, которые можно выполнять совершенно по-разному.
Source
12.06.2023 16:23+3Так вы же сами всю ответственность на клиента скинули.
Напомню, что в этом треде вы спорите с тезисом, что было бы хорошо, если бы "каждый человек просто стремился качественно выполнять свою работу".Т.е. с одной стороны вы считаете это плохим стремлением, а с другой удивляетесь почему вам плохо починили холодильник. Ну работало же. А то что на следующий день там снова +3, так это вы сами виноваты, с прорабом не посоветовались)
venanen
12.06.2023 16:23+1Почему вам страшно? Или вы мое заявление так интересно экстраполировали на, собственно, меня?
А по делу - почему, там будут те самые -10. Морозилка работает. Просто вместо качественной трубки для хладагента мастер взял самую дешёвую. Оно работает? Работает. Задание сделано? Сделано. Долго проработает - нет. Это, собственно, один из критериев качества. Или вот: ставите себе в машину не оригинальную запчасть, а аналог (или мастер ставит). Она свою функцию выполняет? Да. Работает? Да. Качественный ли это ремонт? Ну, вряд ли. Сколько проработает - никто не знает.
sv_911
12.06.2023 16:23-1вместо качественной трубки для хладагента мастер взял самую дешёвую
Ну вот смотрите. Вы утверждаете "хочу самую качественную трубку для хладагента, самую дорогую какая есть на планете". И при этом платите ремонтнику 5000. А теперь подойдите к своему отцу например, и спросите, какую бы он хотел трубку в холодильник на замену. Скорее всего он скажет "Самую дорогую? Ты че, сдурел? Давай самую дешевую, какая разница". И как в итоге ремонтнику угадать, что вы хотите? Мысли читать?
selkwind
12.06.2023 16:23И как в итоге ремонтнику угадать, что вы хотите? Мысли читать?
Бинго, в сегменте b2c самый главный навык - уметь нравиться неквалифицированному и некомпетентному заказчику с сильно ограниченным бюджетом и еще более ограниченным желанием просвещаться. И не перегружать его голову вопросами про кафльную плитку, как в том анекдоте про покупку туалетной бумаги.
chaynick
12.06.2023 16:23-1Ок Починил, температура в норме. Но трубка была запаена тяп-ляп и через полгода накрылась. Работа выполнена? Или надо было паять лучше, чтобы труба жила 20 лет? Но через 10 лет накроется компрессор! Надо значит при запайке поменять и компрессор! Тогда прослужит дольше, правда еще запайка трубы вам встанет по стоимости в половину нового холодильника. Итак, что такое стандарт качества? Может все же не высасывать из пальца примеры не регламентированных определений которые выкручиваются всеми участниками под себя?
Wesha
12.06.2023 16:23Работа выполнена?
Вы заказывали — "починить" и заплатили за это X деньгов, заказанная работа выполнена. "Починить так, чтобы потом Y лет проработало" Вы не заказывали (да и стоило бы это XXX деньгов).
Moskus
12.06.2023 16:23+2Вы уже начинаете откровенный троллинг из области жонглирования определениями.
0xd34df00d
12.06.2023 16:23+1Должен ли я формально доказывать корректность написанного мной кода (что я могу и даже люблю делать) за любые деньги? Или оплатили, скажем, месяц работы — делаю за месяц без всяких доказательств, оплатили 10 лет — хоть строю всю нужную теорию с нуля?
cupraer
12.06.2023 16:23+1Выше по ветке:
[…] 60к, нанять прогера на эту зарплату, а потом […] выдает качество не на 200к
У вас:
оплатили, скажем, месяц работы — […], оплатили 10 лет
Для того, чтобы люди не измеряли качество в трудоднях, в почасовых тарифах и прочих попугаях — существуют нормы и стандарты. Но ГОСТ и ОТК нынче не в моде, поэтому начинаются абсолютно неуместные конкретно в данном вопросе разговоры про моральную ответственность и прочую софтскильность.
Если вам просто оплатили месяц работы, без дополнительных условий мелким шрифтом, — абсолютно уместно лечь на диван и тридцать раз пересмотреть норвежский фильм «Горящий камин».
В случае же первого комментария, который я вообще не знаю, зачем сюда приплел, — абсолютно уместно потребовать эталон «качества на 200».
0xd34df00d
12.06.2023 16:23+2Можно хоть какие-то нормы и стандарты для программистов, применимые не только сферически и в вакууме?
cupraer
12.06.2023 16:23+1Нет, конечно.
Точнее, да.
Но вот беда, они все будут относительными, а потому на роль норм и стандартов из парижской палаты — годятся слабо.
Заказчик (наниматель) — сродни человеку, живущему в городке с одним продуктовым магазином (постарался выбрать самую близкую метафору :)). Если сегодня в этот магазин не завезли молоко — вынужден жарить блины на воде. Альтернатива — съездить в райцентр за молоком — хоть и вариант, но редко подходящий.
Так и тут: рынок доступных прямщас разработчиков конечен, определен объективными критериями, и в рамках каждого конкретного рынка можно навести непротиворечивую систему стандартов. Новый код валит продакшн не чаще раза в год, снимаем деньги со счета не того клиента — не чаще раза в два года, нет басфактора (написанное понятно другому члену команды), небольшие изменения ТЗ не приводят к пулл-реквестам на тысячу строк, увеличение нагрузки вдвое — вызывает алерт в метриках, а не отказ системы, понятно, что делать с увеличением нагрузки в 10 раз, и так далее.
А дальше уже по обстоятельствам: есть пул разработчиков, есть пул задач, есть какая-то шкала навыков и умений каждого… Надо решить штатную задачу — выбираем из пула Васю и ждем, что он справится за примерно предсказуемое время. Надо свой чатжпт натренировать — бьемся головой о стену.
А объективный стандарт только один: разработчику до́лжно стараться в меру своих сил и умений, которые обязан смочь оценить хоть кто-то в коллективе. Это не так-то сложно, если разработчик вышел на работу не вчера.
И компромиссная вилка: могу за месяц, но без секретарш, или за 10 лет с нейросетью, обыгрывающей гендиректора в шахматы. Но эта вилка должна быть озвучена на берегу, а не решаться внутри программиста в зависимости от его настроения.
0xd34df00d
12.06.2023 16:23Новый код валит продакшн не чаще раза в год, снимаем деньги со счета не того клиента — не чаще раза в два года
Мне неизвестны случаи, когда люди бы на самом деле подписывались под такими требованиями, и требовали этого от других с какими-то санкциями. Да, очень хочется, чтобы прод не падал, деньги не переводились куда-нибудь не туда, но это всё равно происходит, и с теми людьми, по чьей вине это происходит, почти всегда ничего не случается.
А иногда они вообще растут по карьерной лестнице, потому что у них же всё время пожары, они всё время бегают в мыле, работа кипит, движ идёт. А у вас всё скучно, никаких новостей, и, значит, у вас никаких проблем. Зачем вас повышать, зачем вам давать помощников и тем самым расти вас по карьерной лестнице? Но, впрочем, я отклоняюсь.
А объективный стандарт только один: разработчику до́лжно стараться в меру своих сил и умений, которые обязан смочь оценить хоть кто-то в коллективе. Это не так-то сложно, если разработчик вышел на работу не вчера.
Сделать такие оценки, чтобы по ним можно было делать хоть какие-то выводы, сложно.
Мой любимый пример из моей же практики: надо было сделать небольшой класс на C++, который в себе инкапсулирует один
int, аллоцированный выделенной черезmmapпамяти (чтобы при краше приложения значение инта всё равно в итоге сохранялось на диск). Даже о копировании объектов этого класса, их перемещении, и так далее, думать не нужно. Мои коллеги (хорошие программисты на C++) считают меня хорошим программистом на C++. Сколько времени это должно занять без всяких тестов?И компромиссная вилка: могу за месяц, но без секретарш, или за 10 лет с нейросетью, обыгрывающей гендиректора в шахматы. Но эта вилка должна быть озвучена на берегу
И это тоже сложно, если вы делаете задачи хоть с какой-то вариабельностью. Вам на берегу неизвестно, какие проблемы вылезут, даже если вы ничего не доказываете, а просто пытаетесь интегрировать разные библиотеки и инструменты в одно приложение (но не так, как вы делали раньше).
а не решаться внутри программиста в зависимости от его настроения.
Strawman, не делайте так.
cupraer
12.06.2023 16:23Мне неизвестны случаи, когда люди бы на самом деле подписывались под такими требованиями […]
Это не отменяет существование таких требований :)
Мой любимый пример из моей же практики […]
В медиане-то можно. Выбросы будут, кто спорит. Но они не должны быть каждый раз, только и всего.
Отвечая на вопрос: очень сильно зависит от плотности записи; если перезапись значения частая — задача не слишком простая, если нет — тривиальная. Но я могу и ошибаться, триста лет на плюсах не писал.
на берегу неизвестно, какие проблемы вылезут
Конечно не известно. Зато мне примерно понятно какой глубины будет кажда проблема, и я об этом тоже никогда не стесняюсь рассказать на берегу.
0xd34df00d
12.06.2023 16:23Это не отменяет существование таких требований :)
Требовать можно что угодно, но неплохо бы, чтобы требования реализовывались на практике.
В медиане-то можно. Выбросы будут, кто спорит. Но они не должны быть каждый раз, только и всего.
Для этого нужно оценить ту же медиану, а с этим проблемы.
Отвечая на вопрос: очень сильно зависит от плотности записи; если перезапись значения частая — задача не слишком простая, если нет — тривиальная.
У вас каркас вроде
class PersistentInt { ... public: explicit PersistentInt(const std::string& filename); int& getInt(); };так что от перезаписи оно не сильно зависит — ОС разберётся, как и когда скидывать изменённую страницу на диск. Тут дьявол в несколько других деталях.
Зато мне примерно понятно какой глубины будет кажда проблема, и я об этом тоже никогда не стесняюсь рассказать на берегу.
И в итоге у значимой части работодателей выиграет чувак, который не парит этим всем мозги и просто сразу называет сроки. А что они неточные окажутся — ну что ж, бывает.
konst90
12.06.2023 16:23+11Для того, чтобы люди не измеряли качество в трудоднях, в почасовых тарифах и прочих попугаях — существуют нормы и стандарты.
Это работает только в случае работ, где есть объективная характеристика готового продукта. Сварное соединение должно выдерживать давление в сосуде не менее 200 атм. Налили воду, надавили. Диаметр изготовленной детали должен быть в диапазоне от 20,00 до 20,04 мм. Взяли микрометр или два калибра, измерили.
А вот, например, задача инженеру - спроектировать кронштейн нагрузку 200 кг с креплением к стене таким-то. Казалось бы, объективный критерий - изготовить и подвесить груз, но нет. Материал, способ изготовления, необходимое оборудование, финальная цена изделия варьируются в весьма широких пределах, и чтобы установить все ограничения - вам по сути надо спроектировать "идеальный" кронштейн самому, а потом установить критерии по нему, но тогда вам уже и не нужна работа - вы всё сделали сами. Можно установить предельные условия - масса, стоимость материалов, трудоемкость. Но вы никогда не будете уверены, что массу относительно заданной можно снизить вдвое - или наоборот, вписаться в текущие ограничения объективно невозможно. А может быть, можно повысить трудоемкость на 5%, снизив стоимость материалов в полтора раза.
И так будет с любой сколь-нибудь творческой деятельностью.
Hardcoin
12.06.2023 16:23+1обещали-то 5к, так кто виноват?
Нет, цену выставлял он, я же прямо написал.
выполнена по заданным стандартам
А вы пользовались услугами работников? Я ведь вообще не знаю, какие там стандарты могут быть. И я не собираюсь требовать скидку из-за косяков. Я просто хочу, что бы сделали хорошо и без проблем готов заплатить за это запрошенную цену. Но сейчас начнется нытье на тему "что такое хорошо". Кто профессионал-то в своей работе он или я?
Мне вот к врачу, например, который не помог, тоже не получится докопаться. Я просто не знаю, то ли проблема очень сложная, то ли он просто не знает. Может он сделал максимум, а может спустя рукава учился, а теперь пользуется тезисом "услуга оказана согласно стандартам". И не узнаешь из-за этого, идти к другому врачу или я уже получил максимум. Но отмазка знатная, убедительная, согласен.
вакансию с оплатой 60к, нанять прогера на эту зарплату
Нет, если он в принципе туповат или неопытен, никаких вопросов нет, бывает. Но если он на самом деле может выдать качество на 200к за тот же рабочий день (без переработок), но при этом пришел на вакансию в 60к и даже не обмолвился, что может делать лучше (не быстрее, а просто меньше багов, например) - это уж совсем странно. Он что, специально баги будет добавлять в код, что бы низкую зарплату оправдать?
edogs
12.06.2023 16:23+2Нет, цену выставлял он, я же прямо написал. Я ведь вообще не знаю, какие там стандарты могут быть.
Вы не знаете стандарты выполнения задачи, но ставите задачу исполнителю. Вы знаете свой бюджет, но не задаете его исполнителю. Исполнитель же называет бюджет на реализацию поставленной задачи. Вы думаете проблема на стороне исполнителя?
А вы пользовались услугами работников? Кто профессионал-то в своей работе он или я?
Поскольку Вы не профи, то в Вашем сценарии Вам надо было не ставить задачу сантехнику (ака программисту), а обратиться к прорабу (ака менеджеру) с просьбой описать варианты и назвать свой бюджет на работу.
После этого, выбрав нужное Вам соотношение цена/качество (5к попроще или 20к получше) взять ТЗ и с ним уже идти выбирать сантехников.Но если он на самом деле может выдать качество на 200к за тот же рабочий день (без переработок), но при этом пришел на вакансию в 60к и даже не обмолвился, что может делать лучше (не быстрее, а просто меньше багов, например)
Скорость напрямую связана с количеством багов, затратив +Х времени можено уменьшить количество багов на -Y.
Вопрос изначально в другом - если Вы можете платить 200к, то почему Вы не обмолвились что можете платить 200к? К Вам приходит соискатель на 60к, он честно отрабатывает эти 60к, а Вы ему такой "ты гонишь халтуру так как не работаешь на 200к которые я мог бы платить"?
Hardcoin
12.06.2023 16:23+5Ну да, я не знаю ГОСТы и СНИПы. И готов заплатить тому, кто знает и не обманет. Это неправильно, по вашему? Если исполнитель сделал хорошо, то проблемы нет. Если трубы потекли через месяц - то да, проблема с исполнителем. Он плохо сделал. Будете вешать лапшу, что я сам виноват?
обратиться к прорабу (ака менеджеру) с просьбой описать варианты
Да не вопрос, а прораба-то как выбирать? Если он скажет, что его бюджет на проработку ТЗ на установку смесителя - 5 тысяч, как понять, это он нормальную цену назвал или он плохое ТЗ сделает, ошибочное, потому что денег мало, а я должен был думать о максимизации его дохода и не соглашаться сразу на его цену?
Скорость напрямую связана с количеством багов,
Но ведь речь была о другом. О том, может ли конкретно этот человек при такой же (не меньшей) скорости разработки делать меньше багов, если ему платить 200 вместо 60-и. Если не может, то никаких претензий. Он не гонит халтуру, просто делает как может. Особенно если честно предупреждает, что его уровень низкий.
Если ты специально делаешь на 60, если можешь на 200, то наверное можно об этом сказать? Т.к. это очень необычная ситуация и к рассматриваемой проблеме никак не относится.
Халтура - это если у тебя в резюме 200, можешь работать на 200, тебе платят 200, а ты работаешь на 60 только потому, что работодатель не профи и ты всегда можешь отмазаться. А если ты честно отрабатываешь 60 и прямо говоришь о косяках - никаких претензий.
Cast_iron
12.06.2023 16:23Ну да, я не знаю ГОСТы и СНИПы.… Если исполнитель сделал хорошо, то проблемы нет. Если трубы потекли через месяц — то да, проблема с исполнителем. Он плохо сделал. Будете вешать лапшу, что я сам виноват?
С одной стороны вы не знаете ГОСТы и СНИПы, с другой берётесь оценивать труд работника. Как получился вывод: трубы потекли через месяц — виноват сантехник?
Могу предположить, что:- проблема не в том, где был ремонт, а в чем-то смежном. Сантехник видел, мог предупредить о возможной угрозе, но не стал по разным причинам (работал только в рамках ТЗ)
- проблема возникла по причине никак не связанной с сантехником
- как вы и предположили низкокачественная работа сантехника
т.е. не разбираясь в предмете вы пытаетесь делать выводы на неполной информации и пытаетесь переложить ответственность на наемного рабочего, который может быть невиновным в происшедшем.
Hardcoin
12.06.2023 16:23мог предупредить о возможной угрозе, но не стал по разным причинам (работал только в рамках ТЗ)
Спасибо ему за это. Хороший сантехник, в следующий раз обязательно обращусь к нему.
проблема возникла по причине никак не связанной с сантехником
Тогда вопросов нет. Напомню, я не разбираюсь, для меня главное, что бы человек ответственно сделал свой участок работы. А если не может или не хочет (потому что денег мало, например) - честно об этом сказал.
PuerteMuerte
12.06.2023 16:23+5Вы не знаете стандарты выполнения задачи, но ставите задачу исполнителю. Вы знаете свой бюджет, но не задаете его исполнителю. Исполнитель же называет бюджет на реализацию поставленной задачи. Вы думаете проблема на стороне исполнителя?
А вы, когда приходите, например, к стоматологу, знаете составы пломб, какие буры и с какой скоростью применять, как удалять повреждённые ткани и т.д., и сколько всё это стоит? Не знаете, верно? И если стоматолог сделал некачественно - проблема тогда будет на его стороне, или на вашей?
Wesha
12.06.2023 16:23-3А вы, когда приходите, например, к стоматологу, знаете составы пломб, какие буры и с какой скоростью применять, как удалять повреждённые ткани
Мой стоматолог обычно тихо прифуевает, когда я, сидя в кресле, допрашиваю его, вида "а какое обезболивающее сейчас использовать будете? А почему X, а не Y? А Z не пробовали?"
cupraer
12.06.2023 16:23+5Если, например, мне начать задавать такие вопросы, когда я уже приступил к выполнению задачи с инструментом в руках — вытолкаю такого клиента взашей, даже если он платит по десятикратной ставке.
Друзьям иногда доводилось получать половником по лбу за советы или даже вопросы в процессе того, как я что-то там у плиты делаю.
Думаешь, что умеешь лучше — вот тебе бормашина, режь себе свой аппендикс сам. Пришел ко мне? — Заткнись и жди, когда тебе скажут: «Готово».
cupraer
12.06.2023 16:23Если внимательно перечитать мой комментарий, можно увидеть
как мой комментарий внимательно перечитает тебя, что я ждал этого уточнения и парировал его сразу, прямо во втором абзаце :)
Wesha
12.06.2023 16:23Невозможно же быть специалистом во всех областях деятельности.
Ну Вы же знаете — "всю водку не выпить, всех баб не перепортить — но это не повод к этому не стремиться!"
sv_911
12.06.2023 16:23Странно, что он прифуевает на вопрос про обезбаливающие. Он не знает, что существует аллергия? Отличный стоматолог
Wesha
12.06.2023 16:23-3Он не знает, что существует аллергия?
Нет, он, наоборот, знает, что у меня ни на одно из них аллергий нет. Мы ещё из того поколения, которое в порядке развлечения пускало кораблики в прорванной канализации, а в качестве пластыря использовало подорожник. Какие аллергии, о чём Вы?..
sv_911
12.06.2023 16:23+1Тоесть это один и тот же стоматолог? И вы ему каждый раз одни и теже вопросы задаете?
в порядке развлечения пускало кораблики в прорванной канализации, а в качестве пластыря использовало подорожник. Какие аллергии, о чём Вы?
Как это связано?
cupraer
12.06.2023 16:23+3Я до сих пор пускаю кораблики в прорванной канализации, а царапины вообще сами заживают.
Аллергии это никак не помешало дважды чуть не отправить меня к праотцам.
Hardcoin
12.06.2023 16:23Не знаете, верно?
Да, хороший пример. Не знаю. И очень хорошо, если стоматолог подходит к делу ответственно. Если же он подумает, что владелец стоматологии ему мало платит и он может на этом основании делать кое-как - это проблема. Я ведь даже не знаю, какую долю владелец отдает стоматологу.
На чьей стороне проблема? С точки зрения закона, если получится доказать и есть время и силы - на стороне стоматолога. Он должен будет переделать. А с точки зрения здравого смысла проблема моя и лучше бы сразу выбрать стоматолога, у которого таких "замечательных" убеждений нет в голове и который старается сделать свою работу хорошо.
cupraer
12.06.2023 16:23+1Вы не знаете стандарты выполнения задачи, но ставите задачу исполнителю. Вы знаете свой бюджет, но не задаете его исполнителю. Исполнитель же называет бюджет на реализацию поставленной задачи. Вы думаете проблема на стороне исполнителя?
Естественно. Самый простой пример: покупка хлеба в магазине.
Я не знаю, как пекут хлеб. Магазин не видел машину, на которой я приехал, и не знает, что мой бюджет позволяет купить магазин целиком. Исполнитель называет свой бюджет (в данном случае — цену). Я в лучшем случае могу пальчиком потрогать степень свежести.
И — охренеть, правда? — если в хлебе я найду использованный воздушный шарик, виноват будет магазин.
Cast_iron
12.06.2023 16:23Вы можете прочитать состав хлеба на упаковке и убедиться, что в нем не должно быть никаких воздушных шариков, даже в индивидуальной гипоаллергенной упаковке.
Вы можете посмотреть срок годности хлеба и не только отказаться от его покупки, если срок превышен, но и требовать убрать его с прилавка, но не смотря на вашу возможность купить магазин целиком качество хлеба должно лишь отвечать требованиям стандартов качества, а не вашим пожеланиям к булочным изделиям.
Конечно, вы можете попросить, чтобы вам лично испекли хлеб на основе ваших пожеланий за любую договорную сумму, но в первую очередь изготовленный хлеб по индивидуальному заказу должен отвечать общепринятым стандартам качества.
konst90
12.06.2023 16:23+1Но если он на самом деле может выдать качество на 200к за тот же рабочий день (без переработок), но при этом пришел на вакансию в 60к и даже не обмолвился, что может делать лучше (не быстрее, а просто меньше багов, например) - это уж совсем странно.
Орлов в "Записках автоматизатора" писал:
Если качество или производительность труда программиста можно повысить с помощью материального стимулирования, то этого программиста следует уволить.
blind_oracle
12.06.2023 16:23Это не универсально.
Я, например, узнав что коллеги получают сильно больше денег при схожих компетенциях просто буду демотивирован работать эффективнее.
Материальное стимулирование поможет мне поднять производительность.
Source
12.06.2023 16:23+9Поставленная задача бывает либо выполнена по заданным стандартам, либо не выполнена.
Вы в адеквате? По каким заданным стандартам? Вы всерьёз считаете, что на все виды работ есть ГОСТы, СНИПы и т.д.
И абсолютно все люди их наизусть помнят и в состоянии проверить качество выполненной работы по ним?В 99% случаев халтура и даже откровенное мошенничество сходит с рук, как раз потому что вы как заказчик некомпетентны в том, что заказываете. Вот посмотрите как это происходит на примере ремонта компьютеров. А то косите под дурачка, как-будто вчера родились.
Source
12.06.2023 16:23+2Причём тут владелец компании и вообще выгода? Вы видимо не читали Рэнд.
Речь идёт об этом:
В жизни имеет значение лишь одно – насколько хорошо ты делаешь свое дело. Больше ничего. Только это. А всё остальное приложится. Это единственное мерило ценности человека. Все те моральные кодексы, которые тебе навязывают, подобны бумажным деньгам, которыми расплачиваются мошенники, скупая у людей нравственность. Кодекс компетентности – единственная мораль, отвечающая золотому стандарту.
Ты либо компетентно подходишь к выполнению своей работы, либо нет. Это вообще никак не зависит от выгоды.
Tempelfeld
12.06.2023 16:23+1Я тоже думаю что это очень важно. В контексте профессиональной деятельности. Но она явно перегибает палку говоря о единственном в жизни. Хотя, я её тоже не читал, возможно, это Вы "дело" (её слово) свели к "работе" (Ваше слово). Дело ведь не обязательно работа. Таксисту может быть плевать на свою работу, дома он с душой выращивает гладиолусы или считает пятна на Солнце. Можно, конечно, сказать что таксисту нужно идти работать садовником или астрономом, но наши желания на него мало влияют. Да и указывать другому человеку это - ну, такое.
Source
12.06.2023 16:23Ну, в контексте "Атлант расправил плечи" у неё под делом скорее подразумевался бизнес/основное занятие.
Moskus
12.06.2023 16:23Это точка зрения потребителя, которому не совсем пофигу. Если вы подумаете немного, вы легко найдёте десятки случаев, когда вам может быть критично, чтобы товар или услуга были только надлежащего качества. Ну или вам нравится не слезать с унитаза, поев шаурмы, приготовленной грязными руками, или обивать пороги гос.учреждений, пытаясь исправить ошибку в документах. Про забытый у вас в брюшной полости при операции ватный тампон или вырванный не тот зуб я и не говорю даже.
Но да, это же никому кроме жадных капиталистов не нужно.
sim31r
12.06.2023 16:23+1Я иногда задумываюсь, в каком изумительно-восхитительном мире мы бы жили
Как вариант, вы бы остались без работы, без жилья, без средств к существованию на дне общества ))
Появилось бы очень много конкурентов, что всё делают быстрее, точнее, дешевле. Не пишут комменты на Хабре, а всё свободное время посвящают работе. В перерывах от работы медитируют и занимаются спортом, чтобы выполнить следующий заказ еще качественней, будучи полностью в форме.
Source
12.06.2023 16:23Да нет, кол-во конкурентов не изменилось бы никак. И хуже бы никто не жил, потому что экономика росла бы как на дрожжах. А спортивный азарт в достойной конкуренции - это даже хорошо.
sim31r
12.06.2023 16:23Экономика бы росла, а те кто не вписался в экономику выпали бы из общества, не в силах бороться за ресурсы.
Moskus
12.06.2023 16:23+3Как у вас получается эквивалентность между индивидуальным стремлением к качеству (и, возможно, производительности) и беспощадной борьбой за ресурсы? Повышение качества (и даже производительности самой по себе) не означают интенсификацию потребления и расхода ресурсов. Наоборот, легко возможны сценарии, когда продукт, например, служит дольше, а потому расход ресурсов на изготовление большего числа экземпляров (менее долговечного) продукта не происходит. Так что ваше утверждение - натянуто и однобоко.
sim31r
12.06.2023 16:23Как у вас получается эквивалентность
Это не эквивалентность, это последствия. Не мгновенные, отложенные по времени, но неизбежные. Неужели вы на себе не ощущали конкуренцию на рынке труда? Когда вакансии с высокой зарплатой недоступны из-за наличия конкурентов. И на своем месте даже, несколько сбоев в работе и работодатель найдет замену. Вот я вижу что есть коллеги, которые работают лучше и быстрее, но они ушли в другие компании на более высокие зарплаты. Вот именно такие как я описал, работают не отвлекаясь на Хабр и прочее )
возможны сценарии, когда продукт, например, служит дольше, а потому расход ресурсов на изготовление большего числа экземпляров (менее долговечного) продукта не происходит.
Да, поэтому предыдущего разработчика увольняют. Его продукт служит меньше и требует больше ресурсов. И сам разработчик может заболеть, прокрастинировать, ошибаться, искать свое призвание, отвлекаться на Хабр. А тут ему в замен приходит идеальный сотрудник, который готов демпинговать на рынке труда. Уволенный разработчик пробует устроиться например разнорабочим, сейчас это без проблем. Но если и разнорабочие будут стремиться к совершенству (бросят пить, курить, займутся поверлифтингом, общефищической подготовкой), то и туда не возьмут. Я вижу как даже сейчас мотивированные разнорабочие работают, кладут уличную плитку пли +40 под палящим солнцем и быстро, поднимают грузы под 100 кг (у меня только от вида такого спина ныть начинает).
Сценарий фантастический, может после того как сценарий из фильма Гаттака реализуется, не в единичных случаях, а массово. Тогда мы можем выпасть на дно, как на картинке, экономика и наука скачут вперед, но без нас. Ресурсов в экономике становится больше, но они идут на изучение дальнего космоса например.
Еще есть сценарий из фильма "Области тьмы", там тоже сразу начинается конкуренция и главный герой стянул на себя ресурсы, благо он "добрый", а его антогонист направил сверхспособности на разрушение сразу (бандиты тоже могут стремиться к "совершенству" работая на мафию например). Позитивный сценарий есть в фильме Превосходство, но там всё зависит от личности главного героя и то что он решил всем помогать, а не уничтожать только его решение. С такими ИИ тоже конкурировать не выйдет, только исполнять его команды и его сценарии...
В обратную сторону если баланс смещается, как в фильме Идиократия, тоже плохо. Возможно то, что есть сейчас и близко к оптимуму (для нас).
Я тоже за то, чтобы все стали более мотивированным и умными, просто описал теоретические побочные эффекты при реализации такого фантастического сценария. Это интересно, но уровень жизни может и упасть...
Source
12.06.2023 16:23+1Ну, во-первых, стремление качественно делать свою работу не даёт вам совершенство и идеальность. Оно просто повышает вовлечённость и несколько повышает уровень качества работ. Т.е. не надо утрировать до того, что люди резко супергероями станут.
А во-вторых, почему вы вдруг останетесь за бортом, если вы так же будете стремиться качественно делать свою работу (как минимум, в этом воображаемом мире)? Или вы про то, что если все начнут качественно работать, то вся работа в мире быстро закончится и людям будет нечего делать?
sim31r
12.06.2023 16:23А во-вторых, почему вы вдруг останетесь за бортом, если вы так же будете стремиться качественно делать свою работу (как минимум, в этом воображаемом мире)? Или вы про то, что если все начнут качественно работать, то вся работа в мире быстро закончится и людям будет нечего делать?
Другие, которые сейчас делают работу не качественно начнут конкурировать с нами, делающими работу достаточно качественно или на пределе возможностей, чтобы не скатится в выгорание например. Так как людей на планете 8 миллиардов, это повлечет за собой огромную конкуренцию и дефицит ресурсов для нас.
Если не утрировать то ничего не изменится конечно, статистически на 1% изменятся какие-то параметры экономические и всё.
Source
12.06.2023 16:23Ну, вы видите это в формате конкуренции типа "кто самый продуктивный". Я имел в виду несколько другое - когда сотруднику не наплевать на его работу и он выполняет её не формально, а чуть более проактивно и с акцентом на приятную коммуникацию и результат.
Как результат мне видится переход к 6-часовому рабочему дню или 4-х дневной рабочей неделе при сохранении оплаты и объёма работ (просто за счёт вовлечённости она будет выполняться быстрее). Плюс более качественный сервис и более приятные в среднем эмоции от взаимодействия между людьми. Плюс отсутствие всяких жёстких факапов, когда начальству докладывают то, что оно хочет услышать, а не то, что есть на самом деле. Что может приводить к ужасным последствиям, как например то, что мы сейчас в геополитике наблюдаем.
sim31r
12.06.2023 16:23Такое не получится у вахтовиков. Там обратный эффект. Так как делать нечего, развлечений вокруг нет, начинают работать по 12 часов без выходных. Коллектив маленький, обманывать коллег и руководство не получится. Плюс заранее пролечиваются зубы и хронические болезни, поэтому работают даже без больничных.
У вахтовиков полярников еще кислородное голодание добавляется, весьма сильное, работоспособность в разы падает.
к ужасным последствиям
Возможно и наоборот, там многоходовочка просчитанная на годы вперед. А карты не раскрываются до последнего, как в покере.
Source
12.06.2023 16:23Такое не получится у вахтовиков. Там обратный эффект. Так как делать нечего, развлечений вокруг нет
Ну, я не знаком с этой спецификой. Сейчас вроде половина развлечений в интернете. Хотя, возможно, речь про вахты в таких условиях, где и интернета тоже нет.
sim31r
12.06.2023 16:23Я тоже не знаком, просто пример трудовых отношений специфических. Описаний жизни в таких условиях много и они достаточно интересные, например жизнь на грузовом контейнеровозе, вполне комфортная. В контексте нашего обсуждения тут интересно что подход обратный, ни какого сокращенного рабочего дня и рабочей недели, всё продленное. Но зато длинный отпуск, например месяц работы и месяц дома.
Moskus
12.06.2023 16:23+2Вы не ответили на мой вопрос. Потому что я, конечно, ощущал конкуренцию и так далее, только это никак не связано со стремлением к совершенству тех, кто со мной конкурировал (потому что они, в большинстве случаев, не стремились к этому в той же степени, в какой стремился я - могу довольно ответственно судить об этом по нескольким внутренним вакансиям, на которые я не попал или попал далеко не сразу, лично зная своих конкурентов).
Вы почему-то полностью упускаете из вида существование локальных максимумов и оптимумов. Впрочем, если ваши рассуждения, судя по вашим иллюстрациям, основаны на впечатлениях от фильмов - это не странно, потому что процесс генерации гипотез у вас отсутствует, вы сразу переходите к примерке наиболее впечатляющих готовых (вовсе не обязательно реалистичных или вообще связанных с исходной вводной) примеров. Это конкретно-предметное мышление, простите.
sim31r
12.06.2023 16:23Впрочем, если ваши рассуждения, судя по вашим иллюстрациям, основаны на впечатлениях от фильмов - это не странно, потому что процесс генерации гипотез у вас отсутствует,
Это простой способ донести какие-то идеи. На 100 листов тут нецелесообразно расписывать идеи или моделировать что-то. Или будут обрывочные мысли непонятные собеседнику, так как для их развертывания нужно слишком много текста написать, как ваши например:
Вы почему-то полностью упускаете из вида существование локальных максимумов и оптимумов.
?
Если речь об обществе, их нет, слишком динамично всё. На фоне исчерпания ресурсов быстрого ничего не статично.
Hardcoin
12.06.2023 16:23+1Так они и сейчас выпадают. Бомжи, например. Но в целом услуги и вещи не станут дороже, они станут немного дешевле. И если вы не собираетесь халтурить, то никуда выпадать не будете (но возможно место в обществе изменится).
sv_911
12.06.2023 16:23А чем это отличается от ситуации сейчас? Тот кто работает на энтузиазме, тот работает на энтузиазме, кто не работает на энтузиазме, тот не работает на энтузиазме. Откуда возьмется больше посвященных делу людей, если не вырастет конкуренция на посвященных и непосвященные не стали бы жить хуже?
anarchomeritocrat
12.06.2023 16:23+6Когда я ещё мыслил трудоустройством куда то, у меня в резюме было написано такое:
Special note for HR's:
If you invite me, but then decline my candidature without technical interview, this is direct way to my personal permanent ban. Please, take a feedback about my CV from you dev team, BEFORE sending me you proposition and invite me only if technical interview 100% guaranteed. Also, if company, for wich you promote me, have a practice to decline candidates by reason "overqualified", even do not try to invite me to such organization.
At the same time, you can conduct a cross-disciplinary interview for me, on the topics of full-stack development, devops, security, blockchain technologies, databases, cryptography, agile project management, mathematics, etc., by consilium of you best experts in their disciplines, ask the most advanced and in-depth questions, you can try your best to fail me, it will only be more interesting for me to pass such a challenge, but point you attention, that I prefer to work in a narrow specialization ;)Мне пришлось это добавить, так как есть и кардинально противоположная проблема - Вот скажите, как человеку, который по настоящему увлечен своим делом, найти достойную его знаний компанию? В подавляющем большинстве случаев, вы попадёте в машину по заработку бабла кому то и будете, да, не спорю, за "достойную" компенсацию, горбатиться на этой галере в роли затычки во все дыры на должности многорукого Шивы на пути к гарантированному выгоранию, от которого, как затем обнаружится, не помогут ни флэт структура компании, ни отсутствие бюрократии, ни ДМС со спортзалами, ни даже печеньки с кикером.
Что бы познать глубину глубин, требуется время, потому что не достаточно в этом всём разобраться теоретически, надо руку набить на практике, поломать голову над уникальными багами, которые даже на steckoverflow не сыщешь, поразбирать замшелый легаси с костылями, который уже даже не помнят кто напилил, но без которого всё умрёт, да и погорбатиться желательно далеко не на одной галере, для расширения кругозора.
Шарящий углублённо, в нюансах, в разных областях спец не берётся из ниоткуда - он закаляется в боях c проблемами и нестандартными задачами.
По настоящему интересных проектов не так то и много, а об интересных задачах только совсем ленивые HR в вакансиях не пишут, даже если основной продукт тупо маркетплейс на вордпрессе. Вакансий с узкой специализацией вагон и тележка, а если нужен универсальный боец, то скорее всего точно сэкономить хотят на штате.
А ещё, может я скажу банальность, но это всё потому что деньги - зло, конкретно в этом контексте. Это минусы капитализма, при котором в роадмэп достижения любых целей вклинивается цель заработать денег и зачастую становится основным устремлением, либо заменяя собой мечту, родившуюся из увлечения, либо просто как приманка человека в денежную сферу, к которой интереса нет изначально.
Тут скорее надо другой вопрос задать: при каком общественном устройстве человек был бы мотивирован к развитию интересных ему навыков, без необходимости стремиться к некой универсальной цели, а-ля заработать побольше... З/П?
В идеале это конечно коммунизм, тот, который теоретический, в версии К. Маркса, который пока и сам лишь мечта )
А если реально, то раз мы не можем обойтись без мотивации деньгами, то хороший способ дать человеку почувствовать себя не IT наёмником и начать жить проектом - это наверное equity и проект должен быть реально интересным, но это не всегда совместимо с задачами бизнеса, который зачастую в основе своей уже закладывает в планы издержки на текучку кадров.
В общем это не проблема отсутствия норм спецов, или норм компаний - это дилемма, причем боюсь разрешимая только большой удачей типа "нашли друг друга" и ни как иначе.
P.S. Если Вы такой вот увлеченный спец, мой Вам совет, запускайте свой стартап, или ищите интересный opensource проект - шансов не попасть на путь выгорания и сохранить мечту и увлеченность, так гораздо больше.
UPD: Я - айтишник и я ХОЧУ знать всё ))
PuerteMuerte
12.06.2023 16:23+15If you invite me, but then decline my candidature without technical interview, this is direct way to my personal permanent ban.
И как, это работает? Для меня это примерно как пытаться пугать ежа голой задницей. Я не эйчар, я технарь, и провожу технические интервью, но я в упор не понимаю, что вы пытаетесь выторговать? Содержания только лишь вашего резюме мне недостаточно для того, чтобы с вами общаться, я хочу ещё первичный фильтр в виде эйчара, который отсеивает слишком уж сложных личностей по другим критериям. Если в обмен на срабатывание этого фильтра я какого-либо незнакомого мне кандидата больше никогда в жизни не увижу, хм, ну и что? Это сделка с нулевой стоимостью.
Hardcoin
12.06.2023 16:23+1Так он не хочет идти в компании, в которых решение о найме на работу принимает hr. Общается, выясняет, не слишком ли человек сложный и отказывает самостоятельно.
Так что в данном случае он пытается выторговать время, которое потратит на общение с вашим hr. Он этого не хочет и считает бесполезным. И если hr не штатный, а из какой-то крупной конторы по найму, это может иметь некоторый смысл (штатных всех не перебанишь)
PuerteMuerte
12.06.2023 16:23+3Это понятно, что не хочет. У меня был вопрос другого плана - с чего вдруг компании должны это его требование удовлетворять? Когда я был молодой и наивный, я тоже считал, что главное - быть хорошим спецом. Но спустя более чем четверть века в ИТ, я прекрасно понимаю, что главное - чтобы человек был хорошим (^_^)
Если без шуток, то речь о проверке характера соискателя. Если он психически неустойчив, токсичен и т.д., то уже неважно, что он там умеет как специалист. Вообще не важно. Один токсик нанесёт команде ущерба больше, чем взвод косоруких неучей. Да, я посмотрю CV, конечно же, и звать буду тех, чьё CV подходит. Но в любом случае, первое интервью маст хэв у эйчара. И только если эйчар согласовал, тогда будем приглашать на второе, техническое. И так делают все более-менее опытные компании, которые уже хоть раз на подобном обжигались. Поэтому подобные гарантии вряд ли кто-то будет давать. Если первую проверку прошёл - будет и желанное техническое интервью. Если не прошёл - ок, технического интервью не будет, баньте на здоровье, молодой человек. Тем более что людей с настолько "сложным характером", чтобы не дойти до технического интервью, попадается не так уж много, к счастью.
cupraer
12.06.2023 16:23+1Один токсик нанесёт команде ущерба больше, чем взвод косоруких неучей.
Практика показывает, что «токсики» вообще существуют только в командах, в которых не банят за одно употребление слова «токсик».
Люди разные, если в команде половина — снежинки, а вторая половина — токсики, то в такую команду ни один нормальный человек не сунется. А если в команде нормальная атмосфера, то и «сложный характер» — не помеха, да и быстро выясняется, что не такой и сложный, просто немного другой.
tommyangelo27
12.06.2023 16:23+1Токсик — это просто удобный разговорный шорткат, обозначающий людей с "синдромом Д'Артаньяна" (в смысле тех, кто считает окружающих п#!@расами).
У нас был в компании случай, когда пришедший с улицы безусловно талантливый специалист, реальный сеньор, просто всех достал постоянными "Вы все говно!". Ну раз мы говно — пришлось предложить ему искать компанию получше.
rak_track
12.06.2023 16:23+4Прошу прощения, но вы заблуждаетесь. Дартаньян не= токсик.
3.14дары, называющие всех вокруг другими дарасами, просто 3,14дары и никто больше. А токсичность бывает и позитивно-прикольная.
PuerteMuerte
12.06.2023 16:23+5Токсичность позитивно-прикольной никогда не бывает. Токсик - это тот, работа с которым вызывает раздражение, агрессию, обиды и т.д. Подколки с чёрным юмором, это как раз не токсичность, а нормальные позитивные отношения. Я как раз имею в виду персонажей, которые обладают чудесной суперспособностью переругаться со всеми вокруг, и при этом искренне считать, что проблема не в них самих.
Moskus
12.06.2023 16:23+2Изначально этот термин означал вообще человека, который способен не переругаться со всеми, а "отравить" обстановку так, что и все остальные начнут ругаться между собой, друг другу завидовать и т.п. А уже потом модное новое слово стали употреблять по любому поводу.
cupraer
12.06.2023 16:23И изначально, и изконечно, — этот термин обозначает химическое соединение, опасное или вредное для жизнедеятельности человека.
K0styan
12.06.2023 16:23-1Побуду уж занудой, сорри нот сорри...
Бывают ещё такие случаи, когда слово само по себе означает одно, а в связке с другим - другое.
Так и тут: токсичный - это одно, а токсичный человек - другое.
cupraer
12.06.2023 16:23-3Токсичный человек — это совершенно другое, тут согласен. Это маркер человека, плохо владеющего родным языком, и разговаривающего на суржике.
Wesha
12.06.2023 16:23маркер человека, плохо владеющего родным языком, и разговаривающего на суржике.
Слово "принтер" Вы, я так понимаю, тоже не используете — только "алфавитно-цифровое печатающее устройство", только хардкор?
PuerteMuerte
12.06.2023 16:23+1В словосочетании "алфавитно-цифровое печатающее устройство" половина слов тоже заимствованые, так что ситуация вообще патовая.
cupraer
12.06.2023 16:23А причем тут заимствование вообще? Как будто «toxic» в этом смысле в английском употребляют не только лишь соевые дегенераты.
PuerteMuerte
12.06.2023 16:23+1Но мне можно, я в целом с русским языком — на ты
Дефис лишний (т.к. акцентирование тут не работает) и отсутствуют кавычки вокруг местоимения "ты" :Р
Если без сарказма, то "токсичный" - слово многозначное. И как совокупность негативных черт характера человека, это пусть и пока ещё неологизм, но уже полноценное слово русского языка. Так что почему вы к нему так относителсь, непонятно. Живой язык впитывает в себя новые слова, это нормальный естественный процесс.
cupraer
12.06.2023 16:23+1Это не полноценное слово русского языка, а типичный представитель арго некоторой группы людей, принадлежность которой в тех кругах, в которых доводится общаться мне, принято не выпячивать.
В принципе, не существует никаких причин избегать фени (которая, по сути, точно такой же арго, только другой группы лиц) на собеседовании, или при знакомстве с дамой в театре. Но я лично избегаю, хотя и не только понимаю, но и владею в некоторой степени.
PuerteMuerte
12.06.2023 16:23Это не полноценное слово русского языка, а типичный представитель арго некоторой группы людей
Это как раз полноценное слово. Абсолютно любые заимствованные слова в языке проходят через стадию, когда их использует какая-то ограниченная группа людей, прежде чем стать общеупотребляемыми. Слово "токсичный" в данном значении не имеет в русском языке нативного эквивалента, в то же время есть потребность в подобном обозначении, поэтому оно успешно закрепляется. И в отличии от фени, с которой вы зачем-то его сравниваете, не несёт в себе ни грамма обсценной лексики или отождествления с криминальными слоями.
cupraer
12.06.2023 16:23Еще раз: заимствование тут ни при чем. В английском это тоже арго. И навсегда таковым останется.
PuerteMuerte
12.06.2023 16:23+5Простите, но "токсичный" не является арго ни в русском, ни в английском языке. Арго - это "мама" и "клава" у компьютерщиков, это "дупло" и "опердень" у банкиров и т.д. - все слова, для которых вы можете выделить достаточно узкую группу лиц, которая их использует в своей среде. А слабо вам выделить группу, использующую слово "токсичный"? Это слово используют все и повсеместно, по крайней мере, кто имеет доступ к современной среде общения. Поэтому нет, это не арго ни разу. Это общеупотребительный неологизм, который уже достаточно прочно закрепился в языке, но некоторым ретроградам не нравится, как и любые другие неологизмы.
siziyman
12.06.2023 16:23+1Сразу видно, что на английском вы не общаетесь и контент не поглощаете, toxic behavior и toxic person - крайне расхожие выражения в очень разных кругах, социальных слоях и при любых политических взглядах.
cupraer
12.06.2023 16:23-2Видно пока только то, что вы свой опыт общения с соевыми дегенератами облыжно экстраполируете на другие круги, социальные слои и политические взгляды.
PuerteMuerte
12.06.2023 16:23+3соевыми дегенератами
Теперь я понимаю, почему вы не любите слово "токсичный". Вас, очевидно, часто так обозначают :)
siziyman
12.06.2023 16:23Не, не угадали. :)
А термин toxic leader, который, пожалуй, первым пошёл в обиход из всех вот этих конструкций, если что, вошёл в употребление в 1996 году, и его автор вроде б не имела явных политических ассоциаций (да и вообще умерла в 1999, что явно несколько раньше, чем весь этот вой про "соевых" поднялся).
Wesha
12.06.2023 16:2320 лет ежедневно общаюсь на английском и поглощаю контент, года примерно до 2018 слово toxic вполне себе означало "ядовитый" (toxic plant — ядовитое растение, toxic waste — ядовитые отходы).
anarchomeritocrat
12.06.2023 16:23Понимаю, отчасти Вы конечно правы, однако тут надо учесть ещё один нюанс - человеку, у которого в резюме описан подробно опыт в 20+ лет в IT, зачастую поиск работы сводится к размещению на паре площадок, типа HH, GeekBrains, Angel.co, WWR и начать получать 100500 инвайтов в секунду, что само по себе создаёт весьма богатый выбор и он зачастую довольно не прост, так как хочется угадать с реально стоящим одним вариантом, который включает и интересный проект, и достойную оплату, и желательно equity, и все те плюшки с побрякушками, которые тоже весьма приятное дополнение, хоть и далеко не основная мотивация в выборе. Это своего рода фильтр, который отсеивает, да, может быть и некоторые стоящие предложения, но те, что остаются, в основном присланы более осознанно.
Ну и разумеется, самостоятельный поиск работы тоже остаётся и если находится реально такая позиция, что сам "офигеть - хочу туда", то тут понятно откликаешься сам и понятно что другой версией резюме, в которой нет этого фильтра )
drath
12.06.2023 16:23+14Сомнительный посыл дисклеймера. Я конечно не HR, но мое заключение после прочтения — "Самонадеянный, капризный, английский уровня B1". Так только рекрутёров распугивать. А подать мысль можно бы и лаконичнее, в стиле "Ищу интересные проекты, стремлюсь к достижениям, собеседования только при условии развернутого фидбэка независимо от решения".
0xd34df00d
12.06.2023 16:23+3Зашёл оставить ровно этот комментарий.
Интересно, какая конверсия у этого CV. Почти все «зарубежные» hr'ы выкинут резюме с такими словами независимо от того, как у них в компании устроены процессы.
Source
12.06.2023 16:23+1Если Вы такой вот увлеченный спец, мой Вам совет, запускайте свой стартап, или ищите интересный opensource проект - шансов не попасть на путь выгорания и сохранить мечту и увлеченность, так гораздо больше.
Я был и мейнтейнером крупного OpenSource-продукта и стартап свой запускал. Там есть свои нюансы. Особенно в стартапах, там важнее умение продавать - что совсем другой навык. В общем, и то и то опыт безусловно интересный и полезный, но я бы не сказал, что это серебряная пуля.
Moskus
12.06.2023 16:23+1Более того, если у индивидуума при взгляде на многие популярные продукты возникает чувство глубокого недоумения, кто в своем уме может их хотеть, организация стартапа из той же области, вероятнее всего - дохлый номер, потому что ощущение потребительской аудитории у него, скорее всего, отсутствует наглухо.
K0styan
12.06.2023 16:23Дефицит ощущения аудитории можно компенсировать навыками объективных замеров востребованности - на чистом визионерстве уже давно не выехать, от рутинной продуктовой работы никуда не деться.
Но отчасти соглашусь: если такой опыт есть, то глубокое недоумение долго не живёт, и уж точно в возмущение не перерождается.
Moskus
12.06.2023 16:23Факторы новизны и уникальности, тем не менее, играют большую роль, потому что делать что-то "такое же, но с перламутровыми пуговицами", конечно, можно (и примеров этому достаточно, у меня вот под носом - новое и очень популярное кафе-мороженое, несмотря на существующий в 300 метров от него Baskin-Robbins), но это нужно очень хорошо просчитать избыточный спрос, чтобы убедить инвестора/кредитора, что вы сможете привлечь потребителя.
0xd34df00d
12.06.2023 16:23+1Так опенсорсом надо заниматься не ради популярности или будущей конвертации его в какой-то продающий проект, а из любви к искусству.
cupraer
12.06.2023 16:23+1Если честно, я каждый раз поражаюсь, что все еще существуют люди, которые идут в опенсорс не по зову души (простите), а ради бабла или еще каких плюшек.
Source
12.06.2023 16:23Читайте внимательнее, часть про умение продавать была про стартапы. Или вы думаете, что их тоже из любви к искусству делают?
У OpenSource другие нюансы, например, фрустрация от недовольства пользователей. Если у вас хоть сколько-нибудь объёмный и популярный проект, то примерно 9 человек из 10 будут писать, что вы обязаны выполнить asap их хотелку. И только 1 из 10 напишет какие-то слова благодарности.
Moskus
12.06.2023 16:23Это любопытно, что вы противопоставили благодарность и ощущение, что разработчик обязан пользователям, но абсолютно проигнорировали конструктивные сообщения об ошибках и объективных недостатках продукта. Потому что те, кто делают opensource исключительно ради удовольствия от процесса, к сожалению, систематически принимают конструктивную обратную связь за наезд (привет отсутствию социализации) и начинают поливать пользователей дерьмом заранее.
Source
12.06.2023 16:23А сообщения об ошибках и объективных недостатках разделяются примерно в той же пропорции в зависимости от тона, в котором они присланы.
Moskus
12.06.2023 16:23+1Да, это правда, хотя большей проблемой мне видится неумение объяснить проблему. Но даже при условии этого, вам не кажется, что это было бы глупо - принимать близко к сердцу тон и, например, игнорировать ошибку из-за того?
Source
12.06.2023 16:23А где я писал, что надо игнорировать ошибку?
Я писал, что работа над OpenSource может оказаться фрустрирующей для многих, поэтому я не советую её в качестве серебряной пули от выгорания. Только это.
А в целом я очень даже за OpenSource и до сих пор PR-ы закидываю в либы, которые использую.
Moskus
12.06.2023 16:23Вы не писали, это я привел пример (и я не говорил что вы говорили).
Речь о том, что то, что я описал - основная проблема сейчас.
Source
12.06.2023 16:23+1Ну, это человеческий фактор. Когда человек что-то делает безвозмездно, он всё равно подсознательно рассчитывает, что его будут хвалить, благодарить и т.п.
Когда подсознательные ожидания расходятся с реальностью, люди могут по-разному реагировать. И это в целом нормально. Стабильный OpenSource в основном всё равно компаниями финансируется. На голом энтузиазме это так сильно не развилось бы.
0xd34df00d
12.06.2023 16:23+1Если у вас хоть сколько-нибудь объёмный и популярный проект, то примерно 9 человек из 10 будут писать, что вы обязаны выполнить asap их хотелку.
Ну и пусть пишут. Вы просто кладёте с прибором на то, что они там пишут, и ваши волосы снова гладкие и шелковистые.
Murtagy
12.06.2023 16:23Выборочно поправил
Also, if company, for wich you promote me, have a practice to decline candidates by reason "overqualified", even do not try to invite me to such organization.
->
Also, in case the company for which you hire me has a practice of declining candidates by reason of being “overqualified”, do not even try to invite me to such an organisation.Moskus
12.06.2023 16:23Всё ещё чудовищно.
Murtagy
12.06.2023 16:23-1Жду твою версию?
Moskus
12.06.2023 16:23+2Жду твою версию?
То, что вы ждёте - это утверждение. Зачем вопросительный знак в конце? Да, и на брудершафт мы точно не пили.
Что ваш, что оригинальный вариант - грубый подстрочник канцелярского русского (вводное also, organization, such a) по структуре и неверны грамматически (например, у вас by вместо for).
If a company you represent has a practice of rejecting applicants for a reason of supposedly being overqualified, please don't contact me.
Могу объяснить подробнее, если любопытно.
Murtagy
12.06.2023 16:23Какие мы нежные. То есть оставлять комментарий оценочный комментарий без конкретики - это верх вежливости.
Ты уверен. Ты уверен? Оба утверждения, вопросительный знак в конце ничего не значит.
Не вижу ошибки в использовании by -
https://www.merriam-webster.com/dictionary/by reason of
В остальном согласен, более удачно.Moskus
12.06.2023 16:23+1Вы свои ощущения проецируете, говоря "какие мы нежные"? Я просто вам указываю на то, что вы ведете себя, как шпана, потому что вам сказали, что ваш перевод - дрянной (и это - факт).
С русским языком у вас тоже тяжело, потому что "ты уверен" - утверждение о чьей-то уверенности, "ты уверен?" - вопрос о чьей-то уверенности, а "жду твою версию?" - бессмыслица, потому что вы говорите о себе ("жду" - первое лицо), то есть вам должно быть известно, ждете вы мою версию или не ждете.
Murtagy
12.06.2023 16:23Смотр - восстанавливаю ход событий:
- anarchomeritocrat приводит отрывок из своего резюме,
- ты критикуешь - "адский английский"
- я, добрый самаритянин, делаю попытку исправить явные ошибки. Вдруг человек чему-то научится.
Перестраивать предложение с нуля я не стал, плясал от того что есть.
- ты вешаешь ярлык - "все еще чудовищно", уже на мою версию. Это как на код-ревью просто поставить - плохо, отклоняю, без комментариев. То есть бесполезный оценочный комментарий, который не позволит улучшить результат. Можно и не оставлять, т к выводов сделать нельзя.
То есть нетто нашей коммуникации на данный момент - ты бросаешься негативными оценками, ценности не добавляешь.
Далее, я делаю утверждение "жду твоего версию", куда, наверное, совершенно случайно затесался вопросительный знак.
Ты решил в ответ на это снова насыпать обесценивающей лексики - придрался к форме общения, напомнил что к тебе нужно обращаться на ВЫ. И нашел ошибку в использовании "by", который нет.
С версией перевода согласен - вариант лучше.
Далее, снова даешь оценку в том что я веду себя как шпана и даже по-русски не ведаю что говорю.
А выводы каждый сделает свои
siziyman
12.06.2023 16:23+7Special note for HR's:
If you invite me, but then decline my candidature without technical interview, this is direct way to my personal permanent ban. Please, take a feedback about my CV from you dev team, BEFORE sending me you proposition and invite me only if technical interview 100% guaranteed. Also, if company, for wich you promote me, have a practice to decline candidates by reason "overqualified", even do not try to invite me to such organization.At the same time, you can conduct a cross-disciplinary interview for me, on the topics of full-stack development, devops, security, blockchain technologies, databases, cryptography, agile project management, mathematics, etc., by consilium of you best experts in their disciplines, ask the most advanced and in-depth questions, you can try your best to fail me, it will only be more interesting for me to pass such a challenge, but point you attention, that I prefer to work in a narrow specialization ;)
Если честно, меня бы очень смутило количество апломба и внимания к своей персоне в комбинации с довольно посредственным английским, и я бы прошёл мимо. Я не эйчар, я программист, который уважает хороших программистов.
anarchomeritocrat
12.06.2023 16:23Ну, это далеко не всё резюме, вообще, в целом в резюме у меня 15 страниц, большинство из которых описание опыта работы, и помимо прочего, там есть и раздел "About me", в котором я в общих чертах, лаконично, описываю свои навыки и увлечения, у него понятно, более человеческое лицо. В этом же разделе я специально изложил свою позицию нарочито жестко и вызывающе, не ради апломба, а просто что бы как раз как то отфильтровать инвайты из внушительного потока входящих, среди которых попадались, на первый взгляд интересные, но по факту просто тратящие бесцельно моё время, так, например, компанию Luxoft, трижды приглашала меня на собеседование и впоследствии отклоняла кандидатуру по причине "Overqualified", что и послужило причиной добавления упоминания об этом в данный пункт - он сформирован не из воздуха, а потому что одно время просто устал быть тупо мальчиком для неоплачиваемых бесперспективных показов рекрутерам.
А что до Английского, то в пункте "знание языков", у меня там честно написано "В1", так что я и не претендую на fluent.
dimaaannn
12.06.2023 16:23Собственно, рынок диктует спрос.
Если спрос на что либо превышает предложение - то довольно наивно ожидать, что делая предложение ниже рынка вами будут сильно заинтересованы соискатели.
onyxmaster
12.06.2023 16:23+3Я не верю что на в 2 раза больше денег приходят люди "в 2 раза лучше" по навыкам и отношению к работе, скажем так. Материальная мотивация для профессионала почти всегда вторична. Она полезна, хороша, но вторична. Так что я не думаю, что стоит всё переводить в плоскость "рыночек порешал", на мой взгляд это чрезмерное упрощение.
LINOLEUMfilm
12.06.2023 16:23-4а вы уверены, что продукт за который вы заплатили в два раза больше будет выполнять/соответсвовать в два раза лучше
onyxmaster
12.06.2023 16:23+1Не могу понять причём тут это. Мне указали "мало платишь -- получаешь плохих специалистов". Я позволил себе не согласиться с обратным ("много платишь -- получаешь хороших специалистов").
Приходите вы с аналогией, эквивалентность которой обсуждаемым вещам только предстоит доказать и спрашиваете уверен ли я в вашем предложении. В вашей формулировке почти наверняка нет, но я не вижу какое отношение это имеет к обсуждаемой тематике. Или вы сторонник упрощения и ставите знак равенства между покупкой репы в "Пятёрочке" и найме бэкенд-разработчика?
indestructable
12.06.2023 16:23Мало платишь - не имеешь возможности получить хороших готовых специалистов (только случайно либо брать перспективных и обучать)
Много платишь - имеешь возможность получить хороших специалистов (но не факт, что получишь). Иначе ты их просто не увидишь.
cupraer
12.06.2023 16:23Начиная с определенного уровня уже не ищешь выше рынка, потому что и так неплохо, и важнее совсем иное, а выше рынка всегда вызывает не совсем уж беспочвенный вопрос, зачем бы им платить выше рынка?
kitchip
12.06.2023 16:23+2Позволю себе побыть душнилой.
Тезис:
делая предложение ниже рынка вами будут сильно заинтересованы соискатели
Не означает: "Если я заплачу выше рынка, то получу более качественных спецов"
onyxmaster
12.06.2023 16:23-3kitchip
12.06.2023 16:23Нет, не опоздал.
В исходном утверждение не было и слово об "обратном". Следовательно, нет никакого смысла его "отрицать". Это не имеет никакого отношения к трэду
onyxmaster
12.06.2023 16:23Вы опоздали с констатацией того, что я признал самостоятельно =)
Тема может обсуждаться не только реактивно, но и с расширением и сужением обсуждаемых нюансов. Прямо как сейчас =)
dimaaannn
12.06.2023 16:23+5Да, но проблему стоит рассматривать в комплексе.
Многие (в том числе я) стал бы вообще делать тестовое задание только в случае особого интереса к вакансии. В противном случае, гораздо проще за это же время пройти 2-3 собеса где опрос устный или интерактивный.
onyxmaster
12.06.2023 16:23Наше тестовое рассчитано на 2 часа (по моим оценкам). Собеседование вряд ли занимает меньше часа.
cupraer
12.06.2023 16:23+2Многим (мне в том числе, кстати) — комфортнее выполнить тестовое, чем шляться по собесам с интервьюерами непредсказуемого кругозора и адекватности.
А мой опыт последних лет прям вопиет: хочешь хорошего коллегу? — Сразу в мусор тех, кто не соглашается на тестовое. Да, я в курсе, что часть вкусных чаинок утечет в раковину, но КПД — прямо восхитительно увеличивается.
vvbob
12.06.2023 16:23+7Часто обжигался с этими тестовыми. Делаешь его несколько часов, стараешься все оформить хорошо, а в ответ - тишина, или что-то типа "не подходите". И думаешь после этого - да пошли они со своими тестовыми все нахрен! Мне не влом было несколько часов над задачей потеть, а тому на той стороне баррикады влом отписться что не так.
K0styan
12.06.2023 16:23+3В последнее время стал на предложение тестового открыто отвечать, что-де принципиально не против, но не хочу сделав работу, отправить её в чёрный ящик и ждать оттуда бинарного ответа. Если уж трачу время на задание - то ожидаю, что потом его обсудим в диалоговом формате.
Разумеется, ничто не мешает пообещать обсуждение, а потом прикинуться шлангом, но проговаривание шанс всё ж уменьшает, плюс даёт некий имиджевый бонус.
cupraer
12.06.2023 16:23+2Не давать полноценный код-ревью на тестовое — жлобство, давайте еще обсудим, стоит ли красть в гостях серебряные ложечки.
Norgorn
12.06.2023 16:23+1Ну большинство, таки, не даёт - потому что могут себе позволить, ведь абсолютно ничего не теряют. Из опыта помню только один случай, когда тестовое подробно обсуждали. Даже когда были офферы, всё равно не было (почти) никакого фидбэка.
Теперь тестовое делаю только в крайнем случае.
leok
12.06.2023 16:23Конечно нет, с чего вы ожидаете, что функция зарплата(навык) будет линейной? Это было бы так только если два инженера производили в два раза больше работы.
indestructable
12.06.2023 16:23+2Это не совсем так работает. На "в два раза больше денег" приходят те, кто не приходят на вакансии ниже рынка. Они не обязательно будут "в два раза лучше", возможно, они вообще будут не лучше. Но иначе выбор сведется к тем, кто согласен работать у работодателя с лозунгом "материальная мотивация для профессионала почти всегда вторична". А это, как правило, будут люди которых не взяли в более оплачиваемое место.
То есть, если мы возьмем условное распределение:
5% - звезды
10% - топ
70% - средний уровень
15% - профнепригодные
То предложив ЗП ниже рынка вы никогда не увидите верхних 5%, из топ 10% может кто-то зайдет случайно (и скорее всего уйдет, тк работа обычная и нет ничего, что оправдало бы ЗП ниже). И вы будете выбирать из среднего уровня.
onyxmaster
12.06.2023 16:23+2И да, авансом скажу, что вы сейчас наверное напишете что "это вы просто денег не хотите нормально платить", дальше прислав ссылку на glassdoor/levels.fyi и упомянув глобальность рынка. Да, могу платить только на локальном рынке, аргумент "в Долине за то что программист не размазывает сопли по клавиатуре платят $300К в год" мне никак не поможет, простите =)
По локальному же рынку, 400к (на руки) вполне приличная зарплата, насколько я представляю.LINOLEUMfilm
12.06.2023 16:23+1это два месяца в окопе или три месяца на вахте - какой уровень науков у тех чуваков что они заняты отсилы 1/3 времени
aamonster
12.06.2023 16:23+1Знаете, окоп не очень привлекателен. Там и убить могут. Так что зарплата в два раза больше, чем за окоп – казалось бы, не так мало.
Hardcoin
12.06.2023 16:23+1С одной стороны она приличная и материальная мотивация действительно вторична после какого-то уровня. Но дело в том, что спецов действительно мало. И люди, которые считают себя спецами не всегда ими являются. И к вам на собеседование спецы не идут. Может быть 800к привлекут кого-то, а может у вас продукт/компания/местоположение/голос hr не такие, как надо. Тогда повышать ставку действительно нет смысла, работайте с теми, кто есть.
Скоро им ИИ поможет и ситуация станет лучше (для работодателей). Но придется ещё немного подождать )
onyxmaster
12.06.2023 16:23Да, я склонен согласиться что лично моя основная проблема это продукт/компания/местоположение. Думаю однако же что пытаться компенсировать это переплатой бессмысленно. Если и клюнет кто-то на деньги, то хорошим это в итоге ничем не закончится.
cupraer
12.06.2023 16:23-1Забавно, но опыт найма за последние 10 лет показывает: если хочешь идеальную пропорцию качества работника к его зарплате — платить имеет смысл чуть ниже рынка (от входа).
micbal
12.06.2023 16:23+5Код можно посмотреть при онлайн кодинге при собесе. Обычно стиль кода в разных конторах разный. На основании отличающего стиля любят делать неправильные выводы. А ведь человек готов был подстроиться под правила вашей команды. На тестовое задание вы были готовы ответить тестовой зарплатой?
onyxmaster
12.06.2023 16:23+1Эти же люди говорят "онлайн-кодинг это издевательство". У нас на собеседовании онлайн-кодинга нет, потому что я считаю что это ненужный стресс.
Тестовой зарплатой на тестовое задание? Да не вопрос, можно по почасовой ставке. Но если задание не соответствует требованиям и я опишу детально в чём недостатки, деньги возвращаются, плюс вы по моей ставке заплатите мне за ревью? Я обычно на ревью трачу минут 20, потому что детально расписываю что не так, ссылки даже бывает предлагаю где почитать про то, почему так не надо делать.
Кстати, а собеседование не нужно оплачивать кандидату? У нас полтора часа обычно идёт.
micbal
12.06.2023 16:23+11А если тестовая зарплата не соответствует требованиям, желаниям? Время соискателя вы оцениваете в 0? Нужно проще быть, на равных относится к соискателю, не самоутверждаться за его счет и не реализовать синдром вахтера, и люди потянутся.
onyxmaster
12.06.2023 16:23Момент про онлайн-кодинг вы решили проигнорировать, видимо предполагаете что я должен просто поверить нанимаемому что он умеет писать код без какого-либо способа демонстрации его навыков.
Время соискателя я не оцениваю вообще, это не моя задача. Если соискатель готов выполнить тестовое задание только за деньги -- его задача об этом сообщить мне (у нас нет HR, все переговоры напрямую со мной) и договориться об условиях.
Пример, который я привёл лишь говорит о том, что вы чудесным образом соглашаетесь с тем, что время соискателя ценно, а моё -- нет.
У меня есть цель -- найти коллегу. Я трачу своё время на создание вакансии, просмотр откликов, первичную беседу (до решения тестового, по желанию кандидата, где отвечаю на все его вопросы и рассказываю про его потенциальное место работы) и подробное ревью тестового задания.
Соискатель хочет найти работу и тратит своё время на реализацию тестового задания. Если здесь есть диспаритет -- мы можем договориться. Нанимать писать код человека, который не написал ни строчки кода, которую я бы видел, я не буду ни при каких обстоятельствах.
Общие фразы, где вы с лёгким налётом издевательства утверждаете что я самоутверждаюсь за счёт соискателей и про "люди потянутся" я оставлю без комментариев =)
micbal
12.06.2023 16:23+4Не решил, просто обычно кто не любит тестовое, показывает кодинг в онлайн. Стресс однозначно стоит учитывать, и не делать поспешных выводов (как любят странные работодатели). :) Вообще не показывая код как можно устраиваться на работу разработчиком? :) С другой стороны если это не джун, то свой ЯП он наверняка знает. Или к примеру почему не показать код как принято писать в команде, и пусть соискатель оценит, одобрит, подскажет и т.п. Чем не метод?
onyxmaster
12.06.2023 16:23На собеседовании у нас есть секция мини-ревью кода. Навык написания кода и его ревью это разные навыки. Мне обязателен первый и лишь желателен второй, не наоборот.
onyxmaster
12.06.2023 16:23"Вообще не показывая код как можно устраиваться на работу разработчиком"
Вот это мне и непонятно.
micbal
12.06.2023 16:23Может, как вариант, исходя из официальной статистики использования времени: "разработчик 80% времени думает, и только 20% жмет клавиши", стоит проверить как он умеет думать, например на вашем коде?
onyxmaster
12.06.2023 16:23+1Я выше написал, что у нас есть мини-ревью для собеседования, но я считаю что написание кода и его разбор это разные навыки. У них общая база, но навык всё-таки разный. Я встречал людей, которые пишут вполне неплохой код, но обнаруживать дефекты в чужом почти неспособны.
micbal
12.06.2023 16:23Как я понимаю, код отражает умение думать, а также правила конкретной команды. Соответственно проверяя умение думать, и способность взаимодействия с командой, будет понятно какой будет код. Конечно навык чтения чужого кода у всех плохой, а чужого плохого кода часто навык чтения отсутствует за интервалы времени на собес. Или умение думать не отражает умение писать код?
Naglec
12.06.2023 16:23+1Не знаю, я все время нанимаю просто на основе беседы. Без лайвкодингов и тестовых заданий
onyxmaster
12.06.2023 16:23-1Я так готов нанимать только по рекомендации. Ну и с другой стороны я нанимаю где-то раз в 3 года, так что могу и потерпеть =)
siziyman
12.06.2023 16:23Ну и с другой стороны я нанимаю где-то раз в 3 года
Это очень многое объясняет: теперь представьте, что нанимать надо постоянно, и людей надо много. И участвует в этом по итогу много людей с обеих сторон баррикад. Отношение к процессу формируется совсем иное, кмк.
micbal
12.06.2023 16:23Логичный подход, спасибо! Как еще кроме беседы понять каким способом способен думать человек. Но обычно просто "цирк с конями..." :)
Kahelman
12.06.2023 16:23А хирург на собеседовании должен провести тестовую операцию?
onyxmaster
12.06.2023 16:23+3У хирурга опыт работы обычно хорошо показывает квалификацию. У программиста — нет, особенно в крупной компании.
Аналогии в дискуссии считаются аргументом, только если доказана эквивалентность аналогии :)
cupraer
12.06.2023 16:23+7Зашел сказать, что удивительно приятно читать ваши комментарии: взвешенные, логичные, точные.
Тут нет никакого сарказма, я просто давно взял за правило всегда говорить вслух людям, что они производят очень приятное впечатление.
Спасибо.
Kahelman
12.06.2023 16:23-5Карман Маркс слезами обливается читая ваш пост. вы нанимаете работника поскольку собирательности присваивать прибавочную стоимость- по просто у разницы между тем что вы берёте с клиента и платите работнику. Поэтому ваше время это инвестиция. Полюс у вас ассиметричная информации вы знаете сколько сможете заработать на работнике а он нет.
nameless323
12.06.2023 16:23Я трачу своё время на создание вакансии, просмотр откликов, первичную беседу (до решения тестового, по желанию кандидата, где отвечаю на все его вопросы и рассказываю про его потенциальное место работы) и подробное ревью тестового задания.
Это время уже обычно оплачено работодателем, так как все это должно происходить в рабочее время собеседующего, в то время как соискатель вынужден делать тестовое в свое не рабочее (никем не оплачиваемое) время.
PuerteMuerte
12.06.2023 16:23Это время уже обычно оплачено работодателем
Ну так и собеседуемого нанимает не эйчар или техспециалист, а собственно работодатель. Он платит реальные деньги из своего кармана за найм, а соискатель вынужден делать тестовое... в какое-то время, может быть, рабочее и неоплачиваемое, может быть, свободное, с нулевым рейтом, а может быть, вообще на предыдущей работе и за счёт другого работодателя. Нормирование времени программиста, это штука вообще безнадёжная.
cupraer
12.06.2023 16:23-1Тестовой зарплатой на тестовое задание? Да не вопрос, можно по почасовой ставке.
А я вот не готов. Профессионал никогда не откажется потратить пару часов ради выяснения перспектив на ближайшие два года.
Сопляки с бесценным временем и непомерными ожиданиями — сразу идут мимо, это экономит кучу времени и сил.
kimisa
12.06.2023 16:23+4В свое время потратила кучу времени на тестовые. И решила, что больше их делать не буду.
Отклик на 10 вакансий и делать 10 тестовых после работы, ну это жестко. А если откликов не 10, а больше? (Имею в вижу и вариант, когда HR сами пишут).
Вы не одни с вашей уникальной вакансией, вас таких куча. И чтобы делать тестовое, мне нужно ооочень хотеть к вам попасть. Но вы не MAAG, так что к вам я точно не буду очень сильно стремиться.
PuerteMuerte
12.06.2023 16:23+3Отклик на 10 вакансий и делать 10 тестовых после работы, ну это жестко. А если откликов не 10, а больше?
Есть хороший лайфхак от этой проблемы: не откликаться на десять вакансий. Откликайтесь на две-три вакансии, которые вам больше нравятся, и там уже делайте или не делайте тестовые задания, в зависимости от того, что требуется.
Раскидывать своё резюме ковровой бомбардировкой, это непродуктивно. Это разве что вы остались без работы, и вам уже все равно куда идти, лишь бы побыстрее взяли хоть куда. В нормальном процессе трудоустройства лучше сразу определиться, куда вы хотите, и туда и подаваться.
tandzan
12.06.2023 16:23Попробуйте получить хоть один оффер соблюдая собственные советы. В реальности нужно отправить сотню откликов ради одного оффера. А если работаешь на дерьмовой работе, с которой хочешь свалить, то многочасовые тестовые приемлимы только первые пару попыток. (Заявления, что тестовое "на пару часов" следует читать как "на пару дней".)
PuerteMuerte
12.06.2023 16:23+2Попробуйте получить хоть один оффер соблюдая собственные советы. В реальности нужно отправить сотню откликов ради одного оффера
Наверное, очень сильно зависит от вашей квалификации. Я в своей 25-летней карьере работу менял семь раз. Будущие рабочие места выбирал сознательно, те, в которые именно хотел попасть. Всего в жизни я был на восьми собеседованиях в качестве соискателя. Поэтому простите, я не знаю, что энтакое нужно делать на рынке труда, чтобы получать один оффер на сотню откликов.
(Заявления, что тестовое "на пару часов" следует читать как "на пару дней".)
Может быть, как раз в этом и дело - тестовое действительно было на пару часов :)
tandzan
12.06.2023 16:23Ну знаете, когда трудовые были актуальны, у меня вкладыш был пришит из-за того, что страницы кончились. Хвастаться там нечем.
Поэтому простите, я не знаю, что энтакое нужно делать на рынке труда, чтобы получать один оффер на сотню откликов.
Вот попробуйте и узнаете.
0xd34df00d
12.06.2023 16:23+2За последние полгода ради лулзов и оценки рынка пособеседовался в семь мест. Из пяти получил оффер, в одном потребовали в качестве одного из этапов proctored-тестовое через тимвьювер в какую-то удалённую машину и я отказался (не против тестовых, но со своими тимвьюверами и их инпут-лагом вместе с невозможностью нормально писать код под привычную музыку, потому что проктореру это не понравится, идите нафиг), и ещё в одном интервьюверу не понравилось, что я сказал, что inline в C++ не требует от компилятора инлайнить функцию, а имеет немного другую семантику, и что свёл задачу оценки сложности некоей стратегии вытеснения страниц виртуальной памяти на диск к сортировке сравнениями, показав, что она не может быть быстрее O(n logn).
По-моему, норм конверсия.
0xd34df00d
12.06.2023 16:23+1Зато в HFT спокойно можно оффер на 500к получить, а уметь их получать полезно. Жизнь длинная.
0xd34df00d
12.06.2023 16:23Идрис к продакшену не готов ещё, но за хаскель мне успешно платят деньги последние несколько лет, и, если повезёт, в скором времени будут платить ещё и за Coq.
tandzan
12.06.2023 16:23Не упомянул, я удаленку ищу, там на интервью сквозь горящее кольцо прыгать приходится. Из последнего, нужно было закрыть конкретный issue в общеиспользуемом приложении и чтоб владелец принял пуш реквест. Какой-то самописанный hackerrank с тестом на 8 часов, последний тест нечитаемый из-за текста с шириной в 1 символ, после указания на это hr больше не отвечала. Не смог правильно ответить как хэш таблица внутри обрабатывает коллизии. Предложение подписать договор с материальной ответственностью за ущерб от работы приложения. И т.д. Короче, записал себе в блокнот что плюсы теперь только для хобби.
0xd34df00d
12.06.2023 16:23Не упомянул, я удаленку ищу
Я тоже не-удалёнками даже не интересуюсь. Шесть из семи позиций выше — удалённые (максимум уровня «два раза в год приехать на неделю в головной офис поболтать со стейкхолдерами»), одна — ездить в офис раз в неделю.
Из последнего, нужно было закрыть конкретный issue в общеиспользуемом приложении и чтоб владелец принял пуш реквест.
Это какой-то трэш и скорее выглядит как попытка делегировать вам немного работы.
PuerteMuerte
12.06.2023 16:23+2Ну знаете, когда трудовые были актуальны, у меня вкладыш был пришит из-за того, что страницы кончились. Хвастаться там нечем.
Ну так тем более. Столь частые смены работы, это же не признак опыта в трудоустройстве, а признак или его полного отсутствия, или в лучшем случае, хронического невезения.
selkwind
12.06.2023 16:23Поэтому простите, я не знаю, что энтакое нужно делать на рынке труда, чтобы получать один оффер на сотню откликов.
Элементарно - оказаться весной 2008 года в NYC на H1B. Когда увольнения идут этажами, то HR как-то пофиг становится на ваш опыт, если он не совпадает буква в букву с нужным набором баззвордов как минимум.
PuerteMuerte
12.06.2023 16:23Элементарно - оказаться весной 2008 года в NYC на H1B.
Действительно, куда уж элементарнее - оказаться весной 2008 года в NYC на H1B :)
Wan-Derer
12.06.2023 16:23Предположу что 25 лет назад всё было иначе т.к. индустрия разработки ПО в её сегодняшем виде только зарождалась. Сейчас крайне сложно получить первую работу, дальше уже проще.
alexdevyatov
12.06.2023 16:23Кстати, а собеседование не нужно оплачивать кандидату? У нас полтора часа обычно идёт.
Почему именно кандидату? Он точно так же свои личные полтора часа тратит.
LINOLEUMfilm
12.06.2023 16:23-4и чтобы за такси заплатили
micbal
12.06.2023 16:23+6Как вы думаете, если интерес обоюден и у соискателя, и у работодателя, потенциальный работодатель в офисе, а соискатель к нему едет, тратя свое время и свои ресурсы на проезд, это по-честному? Или исходя из выше представленной логики, один соискатель заинтересован в рабочем месте, а работодателю это какбы не нужно? Откуда тогда очередной "плачь Ярославны" про "нетути специалистов"? Сами работодатели не знают что хотят...
LINOLEUMfilm
12.06.2023 16:23-4знают и иногда даже говорят: ты сначала мне деньги заработай а потом я решу сколько тебе дать
micbal
12.06.2023 16:23+2А зачем такая лотерея соискателю? Лучше к адекватному устроится. А этот пусть вайтишниками довольствуется с соответствующим уровнем... :)
LINOLEUMfilm
12.06.2023 16:23-5ещë разрешается самому под ряд оформлять и выставлять доп услуги клиентам организации тк уже известна доля исполнителя ... короче как на автомойке: у вас салон чем-то пахнет - может сделаем туман пока моется кузов / в итогe сумма 2x к полной помойке
PuerteMuerte
12.06.2023 16:23+3На тестовое задание вы были готовы ответить тестовой зарплатой?
Тестовые задания - они, как и йогурты, не одинаково полезны. Если ожидаемая длительность задания измеряется в сутках (с учётом того, что кандидат знает, как его делать), то логично его оплатить, конечно же. А ещё логичнее его не давать. Если в часах и тем более, минутах, то платить там в общем-то и не за что, это просто продолжение собеседования. Собеседующий тоже будет тратить время и на ревью, и на написание отзыва.
Norgorn
12.06.2023 16:23+1Собеседующий тоже будет тратить время и на ревью, и на написание отзыва.
Но обычно решает не тратить - смысл, если всё равно отказ и больше этого человека не увидит?
Getequ
12.06.2023 16:23+10"основная фраза «я точно не помню»" - что в этом такого в нашем деле, не зря же живёт СтекОверфлоу.
Зачем помнить наизусть какие именно символы печатать, если ты знаешь что есть такая возможность и когда её стоит применитьonyxmaster
12.06.2023 16:23+3Это если знаешь что она есть. Я не спрашиваю на собеседовании как называется класс или метод.
Ryav
12.06.2023 16:23А что за условия, какое тестовое?
onyxmaster
12.06.2023 16:23Про условия требуется более конкретный вопрос, а тестовое ниже.
Реализовать IDictionary<,> таким образом, чтобы перечисление его элементов сохраняло порядок, соответствующий порядку вставки, при этом не изменяя алгоритмическую сложность операций относительно обычного Dictionary<,>.
cupraer
12.06.2023 16:23+1не изменяя алгоритмическую сложность операций
Включая само перечисление?
onyxmaster
12.06.2023 16:23+1Это очень хороший вопрос, и да, включая само перечисление.
cupraer
12.06.2023 16:23А ссылка на коммит в корку руби, где они это прикрутили, — пойдет?
onyxmaster
12.06.2023 16:23+1Ну мне на C# надо всё-таки =)
cupraer
12.06.2023 16:23Фу, ну там же после идеи — на пять минут клавиши потыркать. И это на шарпе, на котором я вообще никогда не писал.
Да и чатжпт с си на шарп переведет на ура.
onyxmaster
12.06.2023 16:23Скорее всего я не приму такое тестовое задание. Не потому что оно написано при помощи ChatGPT, а потому что оно, скорее всего, будет реализовано неэффективно и недостаточно читаемо.
onyxmaster
12.06.2023 16:23Большинство идей, с которыми приходят люди при реализации задания, нарушают базовые требования, описанные в задании =)
Кроме того, мне нужен программист, для которого C# это основной язык.
И ChatGPT 4 эту задачу кстати нормально не решает, без получасового втолковывания ему что нужно =)cupraer
12.06.2023 16:23-1Ну нельзя же так всерьез ко всему относиться.
Там эффективных решений вагон, а то, которое оптимально по памяти — как раз довольно нечитаемое.
Так что требования оказались не только не полными, но и противоречивыми.
Про чатжпт не знаю, сказал наобум, сам ни разу не пробовал.
mayorovp
12.06.2023 16:23+1Нет никаких фундаментальных проблем сделать оптимальное по памяти решение читаемым.
0xd34df00d
12.06.2023 16:23Я C# не знаю, если честно, и вообще сегодня не выспался, но за пару минут размышлений под завтрак я бы делал так: просто рядом со словарём держал бы массив из ключей, а вместо словаря
IDictionary<K, V>держал быIDictionary<K, Pair<V, Int>>, где второй элемент — позиция в этом массиве.Вставка: вставляем ключ-значение-текущий размер-массива в
IDictionaryи дописываем ключ в массив (amortized O(1), сложность не меняется независимо от сложности вставки вIDictionary). Есть вопрос о том, что делать, когда элемент в словаре уже есть, но оба разумных варианта (переносить в конец перечисления и оставлять как раньше) реализуются очевидным образом.
Лукап: как обычно, только из пары вытащить первый элемент. Сложность как раньше.
Удаление: удаляем изIDictionary, и кладём в массив по индексу из пары какой-нибудь tombstone (у вас же в C# естьnull?). Лишние операции все O(1), сложность как раньше.
Обход: проходим по массиву прямо по порядку, игнорируя все tombstone. Сложность как раньше, но есть нюанс: надо вовремя удалять tombstone (хотя даже этого нюанса может не быть, если базовая реализация словаря что-нибудь такое тоже хранит).Если удалять tombstone тогда же, когда перебалансируется/перехешируется/етц реализация
IDictionary, то сложность останется та же.O(n)лишней памяти (конкретно, размер указателя на количество вставленных элементов), но асимптотически потребление памяти такое же, как и раньше (и у меня есть некоторое чувство, что без лишней памяти не обойдёшься, что бы ты ни делал — информацию о порядке надо где-то хранить, магии не бывает).Что я не учёл?
onyxmaster
12.06.2023 16:23Это решение возможное, но не самое эффективное, особенно в том месте где будет попытка обеспечить синхронизацию реорганизации вложенного словаря и выкапывание могилок.
Кроме того сработает для value-типов TKey, потому что для них значение по умолчанию -- 0.0xd34df00d
12.06.2023 16:23-1Это решение возможное, но не самое эффективное, особенно в том месте где будет попытка обеспечить синхронизацию реорганизации вложенного словаря и выкапывание могилок.
Если словарь не умеет говорить, когда он выкапывает могилки, то можно самому навернуть что-нибудь амортизированно константное, но это уже надо садиться с ручкой и бумажкой и считать там всякие потенциалы-банкиры. Или я не так понял тонкость?
Кроме того сработает для value-типов TKey, потому что для них значение по умолчанию — 0.
ХЗ, хорошая ли идея абьюзить вполне себе валидное значение ключа для могилы (то есть, мне очевидно, что нехорошая, но если я типа на интервью, то говорю об этом мягко, и если интервьюверу такое норм в продакшен-коде, то мы ему перезвоним). На плюсах я бы завернулся в
std::optional(или хранил бы битовую маску где-нибудь с доступными элементами), скажем.Ну или я тут тоже вас не так понял, потому что не знаю C# :]
onyxmaster
12.06.2023 16:23Не умеет говорить, да.
Я хотел написать "не сработает", думаю из постановки предложения понятно =)
Есть Nullable<>, но это ещё оверхед и получится что просто так generic-версию не сделать уже, которая будет работать и для reference и для value-типов.
0xd34df00d
12.06.2023 16:23Есть Nullable<>, но это ещё оверхед и получится что просто так generic-версию не сделать уже, которая будет работать и для reference и для value-типов.
А насколько легко у вас там в сишарпе делать специализации, вычислять на типах и так далее?
mayorovp
12.06.2023 16:23Специализаций в C# просто нет.
Хотя если очень надо — можно проверить в рантайме метаинформацию типа-параметра и принять на её основе решение. Некоторые такие проверки JIT даже умеет сводить до булевых констант, однако это не отменяет необходимости иметь возможность компиляции каждой из веток.
onyxmaster
12.06.2023 16:23Проще считать что специализаций нет =)
Ну то есть существует нетривиальная механика с специализацией на основе value-типов и сравнением с, собственно, конкретными типами, но это не то чтобы мейнстрим.
mayorovp
12.06.2023 16:23Вы не учли что стандартный словарь вам не скажет когда он пересобирается. Тут разве что сравнивать Capacity до и после добавления элемента.
И ещё вы не учли что словарь не пересобирается при уменьшении размера, а потому в некоторых сценариях ваш массив будет состоять из одних только tombstone, и никакой амортизации не выйдет.
Ну и вообще всё как-то сложно, хотя задача удаления элемента из последовательности за O(1) отродясь решалась двусвязными списками. Можно же и тут ими воспользоваться.
Берём
Dictionary<K, LinkedListNode<KeyValuePair<K, V>>>, а рядом держим этот самыйLinkedList<KeyValuePair<K, V>>. Не самый оптимальный по памяти вариант (ибо много дублирования и лишних объектов), но простой и рабочий без привязки к перебалансировкам словаря.Если нужно оптимальнее — надо брать реализацию Dictionary, брать реализацию LinkedList, и комбинировать их не полагаясь на средства языка.
0xd34df00d
12.06.2023 16:23Ну и вообще всё как-то сложно, хотя задача удаления элемента из последовательности за O(1) отродясь решалась двусвязными списками.
Если у вас есть ссылка на неё. Я недостаточно хорошо знаю C#, чтобы знать про
LinkedListNode, например. В плюсах-то да, можно было бы и итератор наstd::listхранить, например.mayorovp
12.06.2023 16:23+1Ну, наличие LinkedListNode или аналога — это то что отличает полезный двусвязный список от сделанного для галочки.
Учитывая, что C# делался практиками, было бы странно ожидать второго варианта.
Вот в Java, к примеру, стандартные коллекции делались теоретиками, поэтому там красивая иерархия но сохранить ссылку на ноду нельзя.
onyxmaster
12.06.2023 16:23В общем это хорошее тестовое задание =)
Показывает кто как разрабатывает, кто на что обращает внимание, и у кого какие критерии "хорошо" и "плохо".
Wan-Derer
12.06.2023 16:23сегодня не выспался
И сразу придумал LinkedHashMap :)
ЗЫ: крутым программистам на 400 тыр тоже задают алгоритмы..... Тоска-пичаль ;(
mayorovp
12.06.2023 16:23+5Я как раз бекендер, и я не очень понимаю какое отношение эта задача имеет к бекенду. 10 лет назад я был готов решать такие задачи хоть проснувшись среди ночи, а сейчас не хочется даже возвращаться к велосипедостроению.
Может, вам лучше попробовать давать тестовое задание кандидатам в бекендеры, которое требует сделать что-нибудь, ну, бекендерское? Хотя это уже не на два часа будет, да.
onyxmaster
12.06.2023 16:23Эта задача замечательным образом показывает, насколько человек разбирается в структурах данных, умеет читать задание и задавать вопросы (при необходимости), внимателен при реализации, знает устройство целевой платформы и много других вещей.
Я не прошу реализовать на бумаге алгоритм Кнута-Мориса-Пратта или хотя бы нарисовать определение Theta(n) применительно к нашей области. Я прошу знать что такое хэш-таблица и как ей правильно пользоваться. Что такое типы и как ими правильно пользоваться. Как организовать код хотя бы в рамках одного файла. И т.д.
А про "велосипедостроение" -- у этой задачи есть вполне конкретный практический смысл, она лежит в основе эффективного кэша с вытеснением на основе, допустим LRU.
Смотреть на очередную реализацию
Hello WorldWeatherForecastController я не хочу, мне не нужен человек, который умеет успешно копипастить бойлерплейт. Мне нужен программист, досконально разбирающийся в том, что он делает.Научить программиста КРУД-ить обычно не проблема. Обратное требует существенно больше усилий.
karon
12.06.2023 16:23+4А вам хоть раз в реальном проекте ставилась такая задача?
onyxmaster
12.06.2023 16:23А про "велосипедостроение" -- у этой задачи есть вполне конкретный практический смысл, она лежит в основе эффективного кэша с вытеснением на основе, допустим LRU.
Самая, что ни на есть, реальная задача из нашего проекта. Это задание выросло именно из решения такой задачи внутри компании.
karon
12.06.2023 16:23О отлично. А можете подсказать, сколько времени у вас разраб на это затрекал.
Я не в курсе шарпов, неужели нет решения из коробки? Выше писали, что даже в Руби есть, а он не так популярен кажется.
Был реальный результат от этого кеша? Я понимаю синтетичесские плюсы, но вот в реальном проекте, реальный кеш на словаре, внутри языка я не встречал пользы.В яндекс ходил. Сейчас просто отказываюсь от них, в том числе и по этой причине.
я код то пишу раз в квартал теперь, какие алгоритмы. Да и зачем когда рядом куча предложений без этих этапов, и чаще всего за более вкусные деньгиОписать принцип хештаблицы, можно в двух словах. Реализовывать библиотечный функции для меня странно
Сорри, что ответил в одном сообщений на обе ветки. У меня ограничение на количество сообщений в час.Hardcoin
12.06.2023 16:23+1я код то пишу раз в квартал теперь, какие алгоритмы
Так если вы не программист больше, о чем речь? Это задание для программистов.
karon
12.06.2023 16:23+2Тот же яндекс не делит тимлида и разработчика, просто добавляет секцию. Как и многие другие компании. У меня все зреет статья о минусах работы тимлидом, л которых я не встречал что бы говорили в открытую. Может и доберусь
Что касается тестового выше, я действительно не понимаю почему нельзя использовать встроенный
https://learn.microsoft.com/en-us/dotnet/api/adaptiveexpressions.lrucache-2?view=botbuilder-dotnet-stable
И в каких кейсах свое решение будет лучше.
Stawros
12.06.2023 16:23+1А чем встроенный OrderedDictionary не угодил?
onyxmaster
12.06.2023 16:23Он не реализует IDictionary<,>.
Stawros
12.06.2023 16:23У майкрософт конечно есть несколько реализаций на с поддержкой генериков, как простая обёртка над уже существующим OrderedDictionary (с очевидным боксингом/анбоксингом), так и на основе Dictionary<,>, но конечно странно, почему нет в API, тикет соответствующий уже 5 лет висит.
onyxmaster
12.06.2023 16:23Я, конечно же, знаю про их существование. Но тестовое задание всё-таки имеет смысл даже в текущих реалиях. Особенно с учётом того, что некоторые реализации нарушают правило тестового задания с точки зрения сохранения алгоритмической сложности.
OrderedDictionary<,> прямо клялись завезти в .NET 6.0, но так и не завезли.
onyxmaster
12.06.2023 16:23Кстати, вы в Яндекс на собеседование не ходили? Думаю вы будете удивлены как часто приходится, по их мнению, искать перевёрнутую часть в массиве =)
В нашем собеседовании есть только реальный код для решения конкретных задач. Иногда упрощённый для простоты понимания и сокращения контекста. Никакой синтетики.
Но, допустим что это была бы синтетическая задача. Считаете ли вы, что программист-"сеньор" может не знать принципов (не деталей) устройства хэш-таблицы или не уметь считать оверхед из-за неоптимальной организации структуры данных?
cupraer
12.06.2023 16:23+3Устройство хэш-таблицы и алгоритмическую сложность может не уметь максимум стажер. Уже джун — обязан.
int03e
12.06.2023 16:23+4Как часто вам в работе пригождается знание того, как именно в хеш-таблице решаются коллизии? Зачем среднему разрабу знать что там внутри, open addressing или что-то еще, может достаточно знать алгоритмическую сложность операций с основными структурами данных в average case?
Boilerplate
12.06.2023 16:23А реализация требуется с нуля или возможен вариант, когда реализация собеседываемого внутри себя содержит Dictionary<,> и, например, List<> ссылок на элементы?
cupraer
12.06.2023 16:23Listне пойдет: вы либоremoveпросадите по алгоритмической сложности, либо он у вас после года аптайма всю память выжрет.
edogs
12.06.2023 16:23+9От поиска коллег в этом году плакать хочется (бэкендера ищу). Ноль любопытства, тестовое делать не буду, кода чтобы показать нет, потому что негоже работать после работы, хочу 400к. На собеседовании основная фраза «я точно не помню».
В этом году условно-активно ищем работу, где-то с марта.
Любопытства уже нет - все конторы одинаковые после первых 9, после 15 сделанных тестовых - нет и желания снова писать код который скорее всего даже не посмотрят, в вакансиях с заявленными 120-240к - с порога говорят что на испытательном 15к + 45к премией если все понравится и потом 30к+60к премией если "горите энтузиазмом и готовы делать для фирмы все что надо даже овертайм"©, а "вот через год или если вы нас поразите и сможете взять на себя работу которую выполняет весь отдел"....
На собесах у нас много ответов "я точно не помню", т.к. много вопросов которые при реальной разработке (а не на бумажке) автоматом всплывут в подсказках или и так будут ясны или редки и могут быть уточнены при необходимости (имя папки с ресурсами, горячие клавиши для отладки, порядок аргументов, количество байт на сектор в фат32 по дефолту и т.д.).sim31r
12.06.2023 16:23-3много вопросов которые при реальной разработке (а не на бумажке) автоматом всплывут
Это верно. Но если при одинаковых прочих условиях, если один ничего не помнит, а другой помнит вообще всё, лучше выбрать второго. Помнить всё очень полезный навык, а плохая память может создать проблем на ровном месте и себе и заказчику.
Тесла обладал «фотографической памятью» и редко пользовался необходимостью записывать что-либо. Говорят, что в 1885 году, когда сгорела его лаборатория, он был в состоянии по памяти восстановить многие из своих изобретений. ... ...
edogs
12.06.2023 16:23+8Мы говорили именно о тех вещах, которые при реальной разработке помнить не нужно в принципе. Функцию помнить надо, а вот порядок аргументов к ней в любом ИДЕ автоматом всплывет.
Шерлок Холмс: Но я-то не каждый, Ватсон, поймите: человеческий мозг — это пустой чердак, куда можно набить всё, что угодно. Дурак так и делает: тащит туда нужное и ненужное. И наконец наступает момент, когда самую необходимую вещь туда уже не запихнёшь. Или она запрятана так далеко, что ее не достанешь. Я же делаю всё по-другому. В моём чердаке только необходимые мне инструменты. Их много, но они в идеальном порядке и всегда под рукой.
sim31r
12.06.2023 16:23+2В моём чердаке только необходимые мне инструменты. Их много, но они в идеальном порядке и всегда под рукой.
А далее чего не процитировали, там как-раз о феноменальной памяти:
Шерлок Холмс: А Вы, Ватсон, можете отличить грязь на Ридженс-стрит от грязи на Пиккадилли? Или пепел гаванской сигары от пепла манильской? Или можете мне сказать, что написано в третьем параграфе «Уложения о наказаниях Британской империи»? Можете?
Я как-раз помню этот диалог ))
saboteur_kiev
12.06.2023 16:23+3Вот только память работает не так, как описывал Конан Дойль, хотя рациональное звено у него есть. Но он больше упирал на энциклопедичность знаний, что сейчас не требуется с наличием электронных справочников и распознавателей.
MountainGoat
12.06.2023 16:23+2Требуется. Ты можешь не помнить точно коэффициент утруски укропа. Но если ты про него не читал, то даже не знаешь, что он существует, и не догадаешься посмотреть значение в справочнике и применить его. Вместо этого будешь свято уверен, что грузчики у тебя укропу усвистели.
saboteur_kiev
12.06.2023 16:23Так это и есть не энциклопедическая память. Под энциклопедической подразумевается что ты все коеффициенты знаешь наизусть, еще и с излишней точностью.
А знать что и как оно работает фундаментально, примерно помнить какие опции бывают, но не помнить 100% синтаксис - это нормально.
onyxmaster
12.06.2023 16:23У нас тестовый период оплачивается на 100%, справочных знаний не требуем на интервью, весь присланный код я смотрю и пишу отзыв, обычно на несколько абзацев.
FrozenTwilight
12.06.2023 16:23+3Так она и будет основной фразой на собеседовании -- все привыкли всё гуглить, информации сейчас слишком много чтобы всё помнить.
cat_chi
12.06.2023 16:23Скоро придём к тому, что все небольшие и средние компании будут только через нетворкинг людей набирать :)
panteleymonov
12.06.2023 16:23+13Не поверите, лет 10 в моей жизни занимало PHP программирование, но потом перешел строго в математику, и сейчас спустя 20 лет спроси меня про GET/POST отвечу именно «я точно не помню». При том, что с новыми инструментами приходится разбираться за два три часа и вполне удается их освоить. А вот это вот ваше все из разряда "ой да ты ничего не знаешь", оно вообще для кого? Сейчас тенденции, выучил-использовал-забыл. В одном могу согласиться - люди воротят нос от работы руками и головой. Но вот это вот нытье по поводу "кандидат не кандидат" тоже под стать.
Также мне не совсем понятны ваши претензии, если в половине фирм, к которым я обращался последние два года, тесты (видимо на какую-то психологическую совместимость) с вопросами из разряда "на кого вы переложите ответственность, если ничего не делали на работе?".
Но самое главное это то, что ноги у всего этого растут из того, что на хабре разбиралось лет 10 назад. Никто банально не готовит себе кандидатов, и не устраивает испытательные сроки, всем подавай готовых 20-летних с 40-летним опытом работы.
khajiit
12.06.2023 16:23+5Как бывающий регулярно с обоих сторон… люди, принимающие решения, часто сами не знают чего хотят. Вот потому так и выходит.
То начальство хочет с горящими глазами, дообучим, но отвергает хороших кандидатов, и в результате заканчивается да хоть кого-нибудь. Кто-нибудь, разумеется, работает как-нибудь.
То собеседующие требуют присобленность к их стеку и их костылям — WAT? — и хорошо если не доскональное знание грабель, на которые они уже наступили. Разумеется, самое высокое матожидание тут будет у я точно не помню. Могу уточнить — да. Но, почему-то, это считается совсем табу и черная метка.Вот так и получается что есть.
Zhbert
12.06.2023 16:23+1негоже работать после работы
А что в этом плохого-то? :) А если речь про пет-проекты, то это не работа...
onyxmaster
12.06.2023 16:23Так пусть пет-проекты и показывают, у нас переработок никаких нет.
Zhbert
12.06.2023 16:23+1Ну а тут уже другой момент вступает в силу. Мне вот часто хочется что-то свое доделать/допилить, хотелок много, интересно и так далее... Но после работы уже просто становится лень. И если в студенческие годы я мог сидеть после учебы по ночам с красными глазами, то сейчас после такого скорее всего уже на следующуй день будет не особо хорошо :)
Это я к чему... Не обязательно соискатель, который не может показать пет-проект, не хочет его писать. А показать рабочий код NDA не позволяет.
cupraer
12.06.2023 16:23Не обязательно человек, который вырезает вам аппендикс, не хотел походить в ординатуру.
Просто обстоятельства, уставал сильно за рулем, да и времени мало...
siziyman
12.06.2023 16:23+2На собеседовании основная фраза «я точно не помню».
Прекрасная фраза, кстати, если человек после неё достаточно достоверно описывает суть того, о чём говорит. Специфику всегда проще проверить в доке, зная, какие слова вбивать в гугл, чтобы ссылку на доку получить.
кода чтобы показать нет, потому что негоже работать после работы
Совершенно здоровая позиция! Я вот люблю программировать, но люблю ещё много других вещей, потому его хватает на работе.
хочу 400к
Зарплата нормального миддла, что не так?
тестовое делать не буду
Потому что в другой конторе 400к дадут без тестового, всё правильно :)
Ноль любопытства
Вот это единственный реально грустный звоночек, но тут вопрос ещё в том, как именно вы к такому выводу пришли.
onyxmaster
12.06.2023 16:23+1Фраза прекрасная, если она не повторяется примерно 50 раз за час.
Я про локальный рынок если что.
Человека, который на глобальном рынке ищет работу мне привлечь нечем и я про это писал ниже :) В России 400 миддлам вроде как не платят.
«Тестовое делать не буду, код не покажу, лайвкодинг это стресс, возьмите меня так, я хороший :)
А, и алгоритмы это заумь ненужная, и детали спрашивать нельзя, я всё в Гугле гляну или книжку с кабаном ещё раз прочту, а то забылась что-то.»
К выводу о нелюбопытности пришёл просто, любое отступление от привычной модели разработки в обсуждении вызывает ступор, а просьба предложить несколько вариантов — ужас.
siziyman
12.06.2023 16:23В России 400 миддлам вроде как не платят.
Ну, год назад платили (опыт разных проверенных людей, включая мой личный, но не ограничиваясь им). Вроде пока не перестали тем, кто не уехал.
«Тестовое делать не буду, код не покажу, лайвкодинг это стресс, возьмите меня так, я хороший :)
Ну вот все три разом это проблема, да :)
Source
12.06.2023 16:23+28Лет через 5 сможете выбирать лучшего из толпы горящих глазами, для кого ИТ - это его жизнь...
Ох уж эти влажные фантазии. Так было лет 15 назад и раньше. Но вряд ли такое повторится в ближайшем будущем. Отрасль слишком сильно разрослась, людей с горящих глазами тупо не хватает, чтобы покрыть хотя бы 20% спроса.
С программистами то же самое. Раньше мы разбирались как всё работает на уровне ассемблера, как компилятор проводит оптимизации, как работают виртуальные машины и сборщики мусора. Сейчас же такие вопросы на собеседовании де-факто под запретом, потому что с такими вопросами вы вообще никого не наймёте. Сейчас люди на серьёзных щах начинают изучать программирование с Python и JavaScript ????????♂️
victor_1212
12.06.2023 16:23> Сейчас же такие вопросы на собеседовании де-факто под запретом, потому что с такими вопросами вы вообще никого не наймёте.
вероятно объективное явление, требования снижаются min с середины 90х, это если в среднем по больнице, причина проста - sw все больше становится ширпотребом, а его производство приближается к конвейерному у форда, где не требуется знать физики и даже конструкции двигателя, но четко уметь крутить гайки своим интрументом с большой скоростью, снова в среднем по больнице, конечно есть интересные проекты и хорошие фирмы, но относительно мало, это про обстановку вне россии - человеку со средними способностями в ИТ будет все труднее, статус не очень, перспектив меньше, делайте свои выводы, про россию все еще сложнее, поэтому не берусь
Source
12.06.2023 16:23+2Проблема в том, что в IT постоянно срабатывает закон протекающих абстракций. Поэтому конвейерный подход пока слабо работает.
человеку со средними способностями в ИТ будет все труднее
Вы как-то сами себе противоречите. Ведь при конвейерном подходе как раз понадобится куча людей со средними способностями
victor_1212
12.06.2023 16:23> при конвейерном подходе как раз понадобится куча людей со средними способностями
со средними способностями, но возможно дешевле, со статусом примерно офисной мебели, заменяемой по мере износа, противоречия нет, такова "c’est la vie"
dimaaannn
12.06.2023 16:23Чем больше будет людей со средними способностями будет нанято, тем больше будут востребованы те кто сможет сказать какие именно гайки надо крутить.
Source
12.06.2023 16:23+1А, вы в смысле, что их труд будет цениться меньше, чем сейчас. С этим я согласен. Осталось только понять, сможем ли мы выстроить конвейерное производство ПО в этом столетии. Конвейер хорош там, где надо массово изготавливать одинаковые изделия. Но в IT для таких случаев изначально Copy-Paste есть. Вот только пока кол-во уникальных изделий всё ещё растёт в геометрической прогрессии.
victor_1212
12.06.2023 16:23> больше будут востребованы те кто сможет сказать какие именно гайки надо крутить
конечно, однако девальвация вероятно вверх по цепочке распространяется, ширпотреб как правило low margin имеет, значит бухгалтера на всех экономить должны, кроме самых-самых,
> сможем ли мы выстроить конвейерное производство ...
конвейер это прежде всего разделение труда на простые операции, в современной интерпретации это frameworks, + max переиспользование кода, когда требуется главным образом интеграция, адаптация, настройка, и пр.
Source
12.06.2023 16:23+1адаптация, настройка, и пр.
По-моему вы не очень представляете конвейерное производство. Там уж точно нет места таким явлениям, как адаптация и настройка.
До запуска линии возможны такие этапы, да. Но как только конвейер запущен, уже никаких адаптаций.
victor_1212
12.06.2023 16:23ну и ладно, скорее Вы меня не понимаете,
важно следущее - "конвейер это прежде всего разделение труда на простые операции", типа простой и понятный пример технологии, конечно у форда на конвейере адаптаций нет (в теории), но для sw это такой же этап сборки, как и закручивание гаек у форда, хотя это не значит что при сборке sw системы буквально используются болты и гайки, просто max используются готовые компоненты, даже если с точки зрения качества изделия это компромисс :)
ALexhha
12.06.2023 16:23+9Сейчас люди на серьёзных щах начинают изучать программирование с Python и JavaScript ????????♂️
а что не так с питоном для вхождения ? Мне кажется, уж лучше чем ассемблер/бейсик/с/с++, который нам давали в школе/универе
Source
12.06.2023 16:23+17а что не так с питоном для вхождения ?
Да всё с ним не так.
Во-первых, это дикий винегрет из парадигм, ни одна из которых не реализована нормально.
Во-вторых, непоследовательность стандартной библиотеки (почему str.lower(), но str[::-1], а не str.reverse()? и т.д. и т.п.)
В-третьих, форматирование определяет логику выполнения (т.е. на самом базом уровне нарушена концептуальная чистота)
В-четвёртых, GIL.И, мне кажется, что этот список можно продолжать очень-очень долго. Это объективно так себе ЯП. Путанный, сложный, непоследовательный. На мой взгляд, один из худших вариантов для знакомства с программированием.
Да, он в целом был хорош как замена Perl для простеньких скриптов автоматизации (потому что к Perl вопросов было не меньше). Но мы свернули явно куда-то не туда, когда расширили его область применения.
cdriper
12.06.2023 16:23и все равно в качестве первого языка лучше чем C, С++, BASIC, Perl, PHP и список можно продолжать долго )
Source
12.06.2023 16:23Согласен. Список не особо подходящих для обучения программированию языков можно большой составить. Хотя C с натяжкой я могу представить в этой роли даже сейчас. Ну и VB.NET, пожалуй, тоже получше для этих целей будет, чем Python. Про оригинальный Basic я уже очень давно не слышал. Он ещё существует?
cdriper
12.06.2023 16:23с удивлением узнал, что до сих пор есть даже какие-то обновляемые коммерческие реализации типа этой
Source
12.06.2023 16:23Ух-ты, они его даже продают по 79 евро за юзера. Ну, надо сказать, что Basic был весьма популярен в США, как у нас Delphi. Видимо, отголоски былой популярности.
0Bannon
12.06.2023 16:23А Go пойдёт как первый?
micronull
12.06.2023 16:23Я пишу на Go уже три года, но моим изначальным ЯП был PHP.
Считаю что Си-подобные языки с динамической типизаций подходят для обучения лучше всего.
Объясню почему.
Многие начинающие, которых реально прёт программирование, сосредотачиваются на реализации и решении какой-то конкретной проблемы. Соответственно все особенности в виде строгой типизации, сборки, запуска, деплоя и т.п. сильно стопорят прогресс и во многих случаях могут отбить желание развиваться дальше.
Чем легче реализовать задумку и запустить её, тем лучше технология подойдёт для обучения.
Остальное уже освоится со временем в процессе чтения и углубления.
RH215
12.06.2023 16:23+4C лучше. Серьёзно, C очень прост. Потом Java или C#. Или наоборот. Python хорош только для обучения неразрабочиков: статическая типизация и куча странностей в стандартной библиотеке. Бонусом - иллюзия потокобезопасности (Python непотокобезопасен в общем случае!)
nightlord189
12.06.2023 16:23+3Каждый раз, как за С - ощущение как будто на механику пересел после автомата, еще и лошадей там где-то под капотом периодически подстегивать надо.
RH215
12.06.2023 16:23+2Так для начала обучения самое то. Сложных концепций нет, только чистый код. Легко перелезать на C# или Java.
nightlord189
12.06.2023 16:23+4В С есть арифметика указателей, ручное управление памятью, макросы, отсутствует нормальное управление зависимостями, сообщения об ошибках малоинформативны. Лучше сразу начинать с чего-то, что более-менее широко сейчас используется, чем тратить время на архаичный С.
RH215
12.06.2023 16:23арифметика указателей, ручное управление памятью, макросы
Вот только на первых порах это всё не нужно, кроме управления памятью, но это и не сложно. Но это всё гораздо проще, чем громоздкие концепции в других языках.
ainoneko
12.06.2023 16:23-1Для начала обучения? O_o
При том, что для обычной hello-world-программы надо бы объяснить (а не сказать "'это мы изучим позже") 5-6 вещей, которые во многих других языках объяснять не надо (они там тоже могут быть, но позже, когда реально понадобятся).
WASD1
12.06.2023 16:23В С сложных концепций нет
#include <stdio.h> int main() { printf("%d\n", 5); return 0; }Хм интересно вы за 1 академическую пару успеете объяснить полному новичку в программировании что и почему делается так в этой программе?
Source
12.06.2023 16:23Чего тут целую пару то объяснять? Или полный новичок в программировании заодно и как юзер компьютера тоже новичок и не знает даже, что программы код возврата имеют? Ну ok, можно этой теме 5 минут уделить.
#include <stdio.h>Добавляет в код возможность вызова стандартных (std) процедур для работы с IO. В детали заголовочных файлов можно не вдаваться, пока не понадобится свой собственный написать.
printf("%d\n", 5)Выводит в STDOUT форматированную строку, %d применяется для подстановки в строку целых чисел в десятичной системе. Про "\n" тоже надо рассказывать? У нас настолько нулёвый нуб, что ни одного урока информатики в школе не посещал?
main()Главная функция, которая является точкой входа для начала выполнения скомпилированной программы
Writer4
12.06.2023 16:23+1Так вот тут и проблема - если человек не новичок в программировании, понимает как примерно все работает в простых языках типа Паскаля, что такое переменные, одно-двумерные массивы, оператор присваивания, циклы, условия, функции, передача параметров по значению и ссылке, и может как-то это минимально на практике применить, то дальше идти куда-то гораздо проще, хоть в ассемблер, хоть повышать абстракции - ООП, ФП и т.п.
Если же всей этой базы нет, а все с нуля, то вот тут и проблема. Просто все уже забыли как начинали. Я вот вспомнил, как я в матшколе в 9-м классе Алгол изучал. Я вообще ничего не понимал, хотя вроде и не дурак был. Где-то за первое полугодие более менее в голове уложилось.
А иначе будет куча какой-то магии везде.
WASD1
12.06.2023 16:23Пока ваш ученик "прилежная маша-отличница" делает записи в тетрадку и когда нужно что-то делать повторяет по бумажке - всё ок.
Как только вы получите живого и любознательного ученика которому надо понять прежде чем делать вам придётся объяснять "почему". А при объяснении почему вы столкнётесь с тем, что в С почти всё кишками наружу (нет уровня абстракции между представлением в языке и поддержкой в ОС).#include
А зачем там стоит знак "#" почему бы не написать просто include?
(почему мы пишем имя файла, а не подуля - от более продвинутого польозателя).
Кажется тут вам надо начать рассказывать про препроцессор и линкер.Выводит в STDOUT форматированную строку, %d применяется для подстановки в строку целых чисел в десятичной системе.
Ох зря вы про stdout начали - кажется это отдельная лекция про устройстов ОС на пол-пары минимум.
Ну это мягко говоря не совсем так. Целых (в смысле int) знаковых. А для long \ short - свои спецификаторы. А почему это работает и именно так? Кажется вам придётся рассказать про ABI вызовов языка Си (как вы увлекательно при вызове кладёте аргументы на стек, а потом достаёте их и как вы в процессе парсинга строки с этими аргументами работаете).
Вот в Паскале вы можете сказать "компиляторная магия" (компилятор знает тип числа и генерирует для вас код) на Python - всё есть объект, имплементирующий специальный метод __str_, в Rust - специальный трэйт Debug \ Show...int main()
...
return 0
Для "совсем 0" вам придётся рассказать, как программа взаимодействует с ОС. И подозреваю, что обычный выпускник 11 класса может этого не знать.
Для "не совсем 0" - тоже будет пара сюрпризов с упоминанием ф-ии __start_ и стандартной библиотеки (почему возвращаемый main тип не совпадает с $? в баше?).DvoiNic
12.06.2023 16:23+2некоторые вещи при первичном обучении вполне допустимо давать в виде "магии". Да, "в начале нужно записать #инклуд, и название функции мэйн(). почему так — мы будем разбирать чуть позже, а пока давйте состредоточимся на содержимом этой функции".
WASD1
12.06.2023 16:23Хорошее правило написания документации - не пишите "что" пишите "почему".
Преподавать "что без почему" для #include и main() - не смертельно но плохо (нас не научили C, а это был второй язык - отчасти поэтому).
А вот для printf("") - это же epic fail. Это же реально магия.
Везде надо передавать либо точноый тип, либо приводимый, либо (void *).
А тут вы прямо передаёте произвольный тип в функцию, функция "понимает". Как это вообще сделано? Где границы применимости? Как это использовать?....
Source
12.06.2023 16:23+1Вы сами в детали закапываетесь и почему-то утверждаете, что это необходимая часть вводных лекций. Я читал книги по десяткам языков программирования. И знаете, везде есть пример аля "Hello World" в начале, но нигде нет главы про устройство ОС, хотя всё это везде печатается в STDOUT.
И форматирование строки через модификаторы - тоже почти везде есть. И всем хватает таблички с перечислением самых популярных. Никто не отвлекается на отдельную главу про то, как они работают.
Я не говорю, что плохо интересоваться этими вопросами, но в целом для обучения программированию можно обойтись и без ответов на них. И ничего ужасного от этого не случится.
WASD1
12.06.2023 16:23-1Плохая документация объясняет "что", хорошая "почему".
Вы предлагаете писать учебник, как плохую документацию.
Из личного опыта - в 10 классе я не понял С, как второй ЯП (первым был Pascal) ИМХО ровно потому, что нам объясняли "что" без "зачем" (в целом я думаю что вся наша компьютерная подгруппа не поняла - во всяком случае никто им не стал пользоваться как ходовым инструментом). Потом пришло время - и понял.
При этом есть места, где это будет "умеренно плохо" (define \ main) а есть места где очень плохо (printf); include - где-то на границе.
Т.е. с define \ main можно поступить на первых порах как с "отрезанием сосисочных жёпок" (запомните и делайте так, потом объясним). Хотя делать как обезьянака потому, что так принято - это прям супер не по программистски.
А вот с printf - вы просто создаёте у ученика диссонанс и противоречие.
Вот вы объяснили типы, аргументы и параметры ф-ии, приведение типов.
И тут делаете printf, которая просто противоречит всему сказанному. Человек хочет разобраться - просто потому, что у него хорошее программистское мышление а ему "опа не твоего ума дело или это займёт пару лекций".
RH215
12.06.2023 16:23-1Ровно все эти концепции есть в других языках, разве что в скриптовых их можно объяснять не на первой, а на второй паре.
K0styan
12.06.2023 16:23Они бесспорно есть. Вот только вопрос не в том, на какой паре их можно объяснить, а в том, сколько можно без них обходиться.
Новичку в первую очередь надо дать понимание последовательного выполнения операторов, затем - ветвлений и циклов. И до этого момента можно даже без понятия функции обойтись.
WASD1
12.06.2023 16:23Ровно все эти концепции есть в других языках,
Очень не так. Там они спрятаны за абстракцией объекта \ модуля. А в Си - машинерия наружу.
И да я посмотрю как вы побъясните C call ABI (почему работает printf("%d %lu", int_var, long_u_var)) в на второй паре.
(ответил чуть продробнее выше)
https://habr.com/ru/articles/739452/comments/#comment_25649448RH215
12.06.2023 16:23+1Ну это уже абсурд пошёл с выдумыванием абстрактных и нереалистичных ситуаций.
А зачем там стоит знак "#" почему бы не написать просто include?
А чем отличаются str и byte отличаются в python? А что такое юникод? А зачем мы всё оборачиваем в class в java? А зачем нужно всё оборачивать в скобки и ставить точки с запятыми? А что такое 1.2e-9? А почему нельзя складывать "1" с 1? А почему переменная не изменяется, если передать её в функцию? Вопросы, вопросы, вопросы.
Ладно, это ещё смешнее:
Кажется вам придётся рассказать про ABI вызовов языка Си
Чтобы рассказать про форматирование в Си нужно рассказать знать про ABI, ага. Нужно ли знать про кишки VM .NET для объяснения форматирования в C#?
Это бы всё работало, если бы я не видел как люди учатся программировать на C и C++ с нуля: вполне нормально.
WASD1
12.06.2023 16:23Ну что, раз вы понимаете как рассказывать про форматирование без С-ABI, то объясните почему оно так работает, почему мне надо писать те или иные значки и как "компилятор" понимает что и как подставить в код:
почему работает printf("%d %lu", int_var, long_u_var))
ПС
Ну и прикол с Python в том, что в принципе за первую половину пары можно рассказать почти всё про утиную типизацию:
- программа в Python выполняется построчно интерпретатором.
- любая переменная в Python это объект
- интерпретатор понимает (знает в runtime) какие функции есть у объекта.
- когда вы делаете что угодно с объектом, это почти всегда значит, что интерпретатор берёт у объекта соответствующую функцию и выполняет её (или обрабатывает ситуацию отсутствия функции - почти всегда это исклюение).
> Нужно ли знать про кишки VM .NET для объяснения форматирования в C#?
Зачем вы задаёте этот вопрос, если я уже объяснял в чём разница в этом месте между C и условными Python и Rust?
Для С# - надо понимать как VM смотрит на наличие метода у объекта и дёргает его, а для C - аналогичные объяснения потребуют солидную такую часть курса "архитектура ЭВМ" прочитать. Что в рамках изучения первого языка малореально.
ПС
И да если кто-то смог выучиться в тяжёлых и неподходящих условиях не непонятном уровне (а вот вся наша компьютерная подгруппа не смогла нормально выучить С как второй язык в 10 классе - ровно потому, что мы не получали нормальный объяснений "как" и "почему") - это не значит, и всех надо мучить преподавая в таких же неподходящих условиях.
Source
12.06.2023 16:23программа в Python выполняется построчно интерпретатором
Т.е. вызов метода не может идти раньше его определения?
любая переменная в Python это объект
А что такое объект? Кажется, вы попали на 2-3 лекции про ООП
интерпретатор понимает (знает в runtime) какие функции есть у объекта.
Как он это понимает? А где хранится список функций объекта? А он может поменяться?
когда вы делаете что угодно с объектом, это почти всегда значит, что интерпретатор берёт у объекта соответствующую функцию и выполняет её (или обрабатывает ситуацию отсутствия функции - почти всегда это исклюение).
А почему "почти всегда", а не всегда? Кажется, я тут что-то написал и не вижу как интерпретатор берёт у моего объекта функцию. Как это почувствовать?)
P.S. Как все эти пункты связаны с утиной типизацией?
WASD1
12.06.2023 16:23Вот вы действительно не понимаете того, что вы пишите? Почему в С надо объяснять дольше и неудобнее одни и те же концепции?
Всё просто: в ООП-языке вы попали на 2-3 первых лекции по ООП. Дальше ваши студенты знают что такое ООП и вы говорите (ну это так устроен объект в нашем ООП языке). И есть куча способов изучать ЯП и ООП параллельно без проблем.
А в случае С вы попадаете на середину курса "архитектуры ЭВМ". И какого-то хорошего способа изучения С, без отвлечения на посторонние темы (или оставления студентов без объяснения) я не вижу.
P.S. Как все эти пункты связаны с утиной типизацией?
Э.. а я точно с квалифицированным программистом разговариваю?
Для более традиционных систем типизации объяснения будут "(почти всегда) тип удовлетворяет ограничениям на аргумент функции", в то время как для утиной типизации "у объекта есть функция с именем".
Несколько разные объясниня, не находите?
Source
12.06.2023 16:23-1Я просто зеркалю ваши вопросы по C. Поверьте, с вашим подходом доебаться до Python гораздо проще, потому что принципы его работы на порядок сложнее C.
Всё просто: в ООП-языке вы попали на 2-3 первых лекции по ООП.
Python не является ОО-языком.
Несколько разные объясниня, не находите?
Я нахожу странной манеру ставить двоеточие и потом перечислять пункты никак не связанные с определением того, что было до двоеточия)
WASD1
12.06.2023 16:23Я просто зеркалю ваши вопросы по C.
При этом совершенно игнорируя суть вопроса (если мы хотим донести до людей "почему"):
- для обучения С вам надо ссылать на то, чего студенты ещё не знают (потому, что это середина курса "архитектура ЭВМ"
- для обучения Python это ссылка на только что пройденное начало "курса ООП".Python не является ОО-языком (а Волга впадает в Каспийское море).
Ну и что? На объяснение разницы уйдёт пара минут. И оно будет относится к уже понятным вещам (в то время как при объяснении С вам постоянно придётся ссылаться на непонятные вещи).
ПС
> это я просто косплею ваши...Косплеите неконструктивно.
В Си например из одного #define можно квиз устроить - но разумный человек найдёт компромис, что для обучения достаточно самых простых объяснений, с чем я и согласился. Вы же пытаетесь быть максимально неудобным в каждом вопросе - в итоге вместо "сильной позиции" вы показываете себя "неудобным собеседником".
Если у вас действительно есть хорошие контраргументы - вопросы, задайте пожалуйста их. А "брутфорс банальзыми вопросами" ещё у Хаджи Насреддина высмеивался как форма демагогии.
Source
12.06.2023 16:23Ну и что? На объяснение разницы уйдёт пара минут.
Да, блин, оно уйдёт пара минут, когда у вас Python 5-й ЯП.
А если брать такого же околонулёвого новичка и задаваться целью, чтобы он понял почему Python такой какой он есть, тут минимум год понадобится и то вряд ли мы добьёмся этой цели в общем случае. Другое дело, что это для программирования вовсе необязательно это всё понимать, что в случае с Python, что в случае с C. В этом и есть суть вопроса.
Вы же пытаетесь быть максимально неудобным в каждом вопросе
Я ж говорю, отзеркалил вашу манеру 1-в-1. Не очень приятно, да?
А то у вас двойные стандарты какие-то. Как только речь не о С, так сразу все "почему" сразу закончились. Хотя по факту их за пределами С становится ещё в 100 раз больше.
0Bannon
12.06.2023 16:23А с Go начать можно?
spaceatmoon
12.06.2023 16:23+2Лучше начинать с универсальных языков, которые позволяют добиться желаемого за короткие сроки и трудозатраты. Go это узкоспециализированный язык программирования для сетевых программ. Что вы хотите писать и для какой платформы?
nightlord189
12.06.2023 16:23+1Отличный выбор как по мне, это С здорового человека.
WASD1
12.06.2023 16:23отличный выбор, как по мне
Согласен.
Это С здорового человека
Мне кажется вообще не стоит бросаться такими фразами.
Начиная с того, что Go - конкурент С++ и в каком месте он конкурирует за нишу С вообще не понятно. Продолжая... (хотя зачем продолжать если Go не конкурент за нишу С совсем).
onyxmaster
12.06.2023 16:23+9Мне кажется что начинать изучать программирование с Python -- не проблема.
Я, если что, начинал изучать программирование с машинных кодов на отечественном недо-клоне PDP-11 по очень низкокачественно отксерокопированному "руководству системного программиста", но не думаю что стоит испытывать такой явный снобизм в отношении разработчиков, чей путь обошёлся без изучения схем косвенной адресации в не слишком ныне популярных системах =)
Source
12.06.2023 16:23+2Да дело не в машкодах и не в снобизме. А в том, что на кривом фундаменте потом тяжело будет переучиваться. Я ж не говорю, что все с ассемблера или с С должны начинать. Просто стоит взять язык, который внутренне не противоречив, и нормально реализует ООП или ФП, кому что ближе. Изучить сначала его, а потом уже можно за любой язык браться. Так хотя бы каши в голове не будет.
onyxmaster
12.06.2023 16:23+6"Внутренне не противоречив" -- а такие не-академические есть вообще в природе?
mortadella372
12.06.2023 16:23+2"Внутренне не противоречив" -- а такие не-академические есть вообще в природе?
Ну, C в известном смысле таков: вот пистолет, ногу свою приносить, велкам!
Source
12.06.2023 16:23+7В C есть UB, это его основная сложность. Так что любителям классики я бы всё-таки Pascal/Delphi советовал.
Source
12.06.2023 16:23+5Ну, ничто не идеально, конечно. Но есть масса вполне последовательных в своих идеях языков: C#, F#, Elixir, Haskell, Kotlin, Rocket, Ruby, Rust.
Любой из них для обучения программированию будет на порядок лучше, чем Python или JavaScript.
aamonster
12.06.2023 16:23+2На самом деле JavaScript вполне последователен (почти как Lisp), просто это не бросается в глаза. Там совсем немного концепций (объекты-хэши, замыкания, наследование от прототипа), на которые наверчено всётальное.
Source
12.06.2023 16:23Проблема JavaScript в слабой типизации, для новичков это очень плохо. Я бы на самом деле советовал начинать с языков с сильной статической типизацией. Потом переходить к языкам с сильной динамической. А слабую оставить на последнюю очередь, когда уже личный профессиональный фундамент сформируется.
В остальном вы правы, но совсем немного концепций там было 15 лет назад. А сейчас чего только поверх них ни накрутили. Да и event-loop далеко не самая лучшая концепция для языка общего назначения. Он был классным решением, чтобы снежинки поверх страницы рисовать, но не сейчас.
0xd34df00d
12.06.2023 16:23Потом переходить к языкам с сильной динамической.
Зачем? На предыдущем шаге можно остановиться и вполне себе отлично жить.
Скрытый текстВ конце концов, с QTT можно сделать полностью статически типобезопасный язык с «динамической типизацией», ведь «динамический тип» — это просто зависимая пара из рантайм-релевантного типа и значения этого типа aka
(ty : Type ** ty).Source
12.06.2023 16:23Ну, кто-то может и остановиться. А у кого-то профессиональное любопытство продолжится. Ведь для разных задач разные языки лучше подходят. Нет одного универсального.
0xd34df00d
12.06.2023 16:23Есть много других способов удовлетворять профессиональное любопытство. Не обязательно учить алгол-60, чтобы понимать, что он не очень подходит.
Ведь для разных задач разные языки лучше подходят.
Где лучше отсутствие типизации, кроме каких-нибудь шелл-скриптов (где изучать особо нечего)?
Source
12.06.2023 16:23-3Ну, например, для backend разработки сильная динамическая типизация с опциональными type-аннотациями гораздо лучше подходит. Time-to-market от этого значительно улучшается.
Source
12.06.2023 16:23It depends.. У кого-то на 20%, а у кого-то и в 2 раза.
Иногда ещё практикуется такая схема, что делается продукт на динамическом языке и когда он захватывает рынок и устаканивается, тогда его начинают потихоньку переписывать на статическом.
0xd34df00d
12.06.2023 16:23А если при этом для нетипизированных языков и тесты не писать, то time to market будет ещё лучше!
Писал на хаскеле даже достаточно тупые и не очень богатые на логику (которую надо бы тайпчекать) сервисы — выразительная типизация всё равно помогает. Да, время до чего-то, что можно выкатить в продакшен, побольше, но времени до уверенности в том, что выкатил, куда меньше.
Source
12.06.2023 16:23Что такое нетипизированные языки? Мы как-то резко перешли на обсуждение ассемблера или что?
0xd34df00d
12.06.2023 16:23-2Я просто стараюсь следить за чистотой используемых терминов. Типы — это то, что можно проверить статически, без запуска программы, поэтому «динамическая типизация» — оксюморон, и этим термином я стараюсь не пользоваться.
PuerteMuerte
12.06.2023 16:23Я просто стараюсь следить за чистотой используемых терминов. Типы — это то, что можно проверить статически
А разве типы когда-либо подобным свойством обладали? О_о
PuerteMuerte
12.06.2023 16:23Конкретные реализации системы типов - да. Но это ведь не свойство самих типов.
mayorovp
12.06.2023 16:23У вас какие-то свои термины, тип данных всегда был множеством возможных значений и применимых к ним операций. Нет никаких концептуальных проблем проверять его динамически, как и вообще не проверять.
0xd34df00d
12.06.2023 16:23У вас какие-то свои термины, тип данных всегда был множеством возможных значений и применимых к ним операций.
Раз мы апеллируем к этому, то отсылка к Пирсу вас устроит в качестве аргумента, что это далеко не только мои термины?
Нет никаких концептуальных проблем проверять его динамически, как и вообще не проверять.
Проверьте динамически в языке общего назначения, что данный терм на самом деле имеет тип
Int → Int. Когда закончите — дайте знать ;]Плюс, динамически проверять уже поздно. Вы уже запустили программу, и в момент нахождения ошибки типов она уже могла иметь какие-то сайд-эффекты, которые уже не отменишь.
mayorovp
12.06.2023 16:23-1Да легко: проверяем что значение (не терм, термы у нас в исходнике) — функция, после чего приводим её к типу Int → Int путём добавления отложенных проверок на аргумент и возвращаемое значение.
А вообще, динамическая система типов не обязана иметь тип Int → Int. К примеру, в том же JavaScript официально всего 8 типов данных.
0xd34df00d
12.06.2023 16:23Как это всё поможет с последним абзацем в моём комментарии (который, впрочем, я дописал при редактировании, так что вы могли и не увидеть)?
0xd34df00d
12.06.2023 16:23Потому что вы не можете просто взять, исправить ошибку и перезапустить программу. Она могла уже записать что-то кривое в базу, отправить емейл пользователю об успешной регистрации (которая оказалась неуспешной) или запустить пресловутые ракеты.
mayorovp
12.06.2023 16:23-1Для всего этого существуют практики защитного программирования, а также здравый смысл.
Тот самый, который говорит что запись в БД нужно проводить в транзакции, а сообщение пользователю отсылать уже после коммита.
0xd34df00d
12.06.2023 16:23Классическое «чтобы у вас в коде не было багов, просто не пишите код с багами».
Тот самый, который говорит что запись в БД нужно проводить в транзакции
Какая транзакция вам поможет, если вы в БД положили вместо суммы двух чисел их конкатенацию как строк?
а сообщение пользователю отсылать уже после коммита.
Очерёдность чего вы случайно не учли, потому что человеческий attention span куда мельче, чем таковой у тайпчекера.
Source
12.06.2023 16:23если вы в БД положили вместо суммы двух чисел их конкатенацию как строк?
При сильной (пусть и динамической) типизации такое не прокатит.
0xd34df00d
12.06.2023 16:23Можно сконструировать пример с БД, когда не помогут ни транзакции, ни прочее (например, с поточной обработкой данных, когда восстанавливаться тяжело, но разные события в потоке просто логически принадлежат разным транзакциям), но можно и проще.
Вот едете вы на машине или летите на самолёте, а там вдруг сработала динамическая проверка, что в одном месте случайно футы, а в другом — метры. Бортовой компьютер показал ошибку и сказал «не могу продолжать, сорьк». Ваши действия?
mayorovp
12.06.2023 16:23Вот едете вы на машине или летите на самолёте, а там вдруг сработала динамическая проверка, что в одном месте случайно футы, а в другом — метры.
Подобная проверка при нормальных практиках программирования должна была упасть ещё на испытательном полёте, а то и вовсе в симуляции.
Source
12.06.2023 16:23Как мы с бекенда переместились в бортовой компьютер? Я вас теперь как мастера переобувания запомню))
Впрочем, ваш пример пока не критичный, раз уж единицы измерения известны, то мы просто конвертнули в общую СИ и едем дальше.
0xd34df00d
12.06.2023 16:23Как проверить, что не забыли конвертнуть? Это у вас ваш рантайм-чекер должен знать про ваши единицы измерения, либо вы должны явно обрабатывать все возможные подобные ошибки. Это всё, конечно, куда проще и TTMнее, чем просто, блин, использовать типы.
Source
12.06.2023 16:23Это у вас ваш рантайм-чекер должен знать про ваши единицы измерения
В чём проблема, раз уж мы по бизнес-требованием знаем, что они бывают разные?
Это всё, конечно, куда проще и TTMнее, чем просто, блин, использовать типы.
Когда требования постоянно меняются, то да проще и ТТМнее. Опять же, хочется верить, что требования к бортовым компьютерам более стабильны, чем к веб-сервисам.
0xd34df00d
12.06.2023 16:23В чём проблема, раз уж мы по бизнес-требованием знаем, что они бывают разные?
Проблема в том, что тогда вам нужно юниты выносить в рантайм тоже и всё время их проверять. И вместо простого сложения чисел (одна инструкция) вы получаете кучу проверок, которые, тем более, надо не забыть везде расставить. Как вы будете проверять, что вы их везде расставили? Опять тесты писать?
Когда требования постоянно меняются, то да проще и ТТМнее.
А вот и нет. Проще, когда тайпчекер сразу показывает, что изменилось и что надо обновить.
Wesha
12.06.2023 16:23-1Как мы с бекенда переместились в бортовой компьютер?
Кто скажет, что бортовой компьютер — это фронтенд, пусть первый бросит в меня камень (согласен даже на 386).
Source
12.06.2023 16:23+1Очевидно же, что выше web backend обсуждался, не?
Хочется верить, что к разработке бортовых компьютеров другие методологии применяются)
mayorovp
12.06.2023 16:23Какая транзакция вам поможет, если вы в БД положили вместо суммы двух чисел их конкатенацию как строк?
Во-первых, сильная типизация на стороне СУБД поможет. Во-вторых, тут поможет тестирование: подобного рода ошибки, как правило, хорошо воспроизводимы, а потому вылезают на первом же запуске.
Очерёдность чего вы случайно не учли, потому что человеческий attention span куда мельче, чем таковой у тайпчекера.
Проверка очерёдности операций куда проще проверки типов.
Кстати, расскажите пожалуйста как конкретно в этой задаче вам поможет типизация, а то я вижу исключительно сценарии в который она не помогает.
Вот самый простой: расхождение между схемой данных в вашей программе и фактической схемой данных в СУБД. У вас в программе статически доказано, что запись в БД будет успешной, а потому можно отправить сообщение на почту — а запись внезапно провалилась.
0xd34df00d
12.06.2023 16:23Во-первых, сильная типизация на стороне СУБД поможет.
У меня sqlite, точно поможет?
Во-вторых, тут поможет тестирование: подобного рода ошибки, как правило, хорошо воспроизводимы, а потому вылезают на первом же запуске.
Подобного рода ошибки иногда на практике вылезают через несколько месяцев работы и записи иногда паршивых данных (потому что код вполне может иметь ветвления и писать в одну таблицу из разных мест, например).
Но да, заметьте, что вы предлагаете заменить типы тестированием и верой в то, что вы всё протестировали.
Кстати, расскажите пожалуйста как конкретно в этой задаче вам поможет типизация, а то я вижу исключительно сценарии в который она не помогает.
Ура, могу сослаться на пост за собственным авторством не в своём блоге! Тыц.
Стадии работы фронтенда вы успешно замените на стадии работы с пользовательскими данными, я не сомневаюсь.
У вас в программе статически доказано, что запись в БД будет успешной, а потому можно отправить сообщение на почту — а запись внезапно провалилась.
Не стоит статически доказывать то, что неверно.
Я как раз сейчас потихоньку пописываю типобезопасные постгрес-байндинги для идриса — там любая операция может либо завершиться успехом, конечно, либо среди прочих ошибок может вылезти ошибка несоответствия схемы ожидаемой (и аналогично при чтении). С сабтайпингом (а-ля этакий row polymorphism плюс вещи вроде возможности читать из not null-колонки в Maybe-поле, и писать из не-Maybe-поля в допускающую null колонку) и всё такое.
mayorovp
12.06.2023 16:23-1Не стоит статически доказывать то, что неверно. […]
…и всё что вы написали дальше никак принципиально не отличается от сильной динамической типизации. Всё те же проверки типов, которые могут вернуть ошибку.
Стадии работы фронтенда вы успешно замените на стадии работы с пользовательскими данными, я не сомневаюсь.
Увы, но это работает не так хорошо как вы утверждаете.
Вот у вас написано:
defunctionalize :: Xform '[EtaExpanded, Monomorphized] '[Defunctionalized] Program. А теперь вспоминаем про ваш "любимый" attension span, и допускаем ошибку:defunctionalize :: Xform '[Monomorphized] '[Defunctionalized] Program. Всё, теперь ваши типы никак не мешают собрать некорректную последовательность действий, ведь тэги не связаны с данными, а просто навешены сверху.Вот и с регистрацией пользователя такая же ситуация.
Пока мы окончательно не скатились в какие-то детали, хотелось бы высказать общее утверждение.
Типы в программе же образуют некоторую мета-программу, верно же? Вот если сложность этой мета-программы превосходит сложность исходной — то у вас уже не типы проверяют корректность реализации, а реализация проверяет корректность типов.
В таком случае статические типы больше не являются ультимативным доказательством корректности программы, а просто являются аналогом модульного теста — чем-то, что с некоторой вероятностью может поймать ошибку, а может и не поймать.
0xd34df00d
12.06.2023 16:23…и всё что вы написали дальше никак принципиально не отличается от сильной динамической типизации. Всё те же проверки типов, которые могут вернуть ошибку.
Блин, вы всё время упускаете ключевую разницу. Эти проверки случаются в рантайме, когда программа уже запущена, и когда исправить эту ошибку малой кровью уже нельзя. Даже если это внутренняя ошибка в логике программы (а не на границе с внешним миром, когда у вас внезапно сменилась схема), даже если запускать программу для её поимки не обязательно.
А теперь вспоминаем про ваш "любимый" attension span, и допускаем ошибку
Только в этом случае мне нужно, чтобы attention span'а хватило на сигнатуры, а это куда меньше, чем весь код. И рефакторить это проще, и на код-ревью изменения лучше видно, и сигнатуры при некотором минимальном тренинге прочитает даже бизнес-аналитик (на чём строится domain-driven design, кстати, книгу domain-driven design made functional рекомендую).
Ну и да, я там про это пишу, кстати, в «Lack of checks inside the transformations»:
In the above, if we omit any of the requirements in, say
defunctionalize [...]then its body still compiles. GHC does not check it to see whether all the assumptions are really expressed in the type. Unfortunately, this is only truly achievable with full dependent types [...]Так что ответ на это — больше типов, а не меньше.
Типы в программе же образуют некоторую мета-программу, верно же? Вот если сложность этой мета-программы превосходит сложность исходной — то у вас уже не типы проверяют корректность реализации, а реализация проверяет корректность типов.
Но вам из этой программы нужно только несколько ключевых утверждений, остальное — детали реализации, которые проверяет машина, а не человек.
Мы не так давно делали аудит доказательств свойств некоторой хреновины на Isabelle, и, по большому счёту, из нескольких тысяч строк кода можно было ограничиться примерно сотней строк определений типов данных и ещё парой десятков типов корневых функций (aka формулировок ключевых теорем). Всё.
КогдаЕсли я допишу свой недопапир на агде, то для его проверки будет достаточно прочитать где-то 200 строк определений типов, определяющих математические объекты, с которыми я работаю, и тоже несколько десятков строк утверждений главных теорем. Остальное — машине. Всё.
mayorovp
12.06.2023 16:23Блин, вы всё время упускаете ключевую разницу. Эти проверки случаются в рантайме
Вот именно, ваши проверки случаются в рантайме.
Только в этом случае мне нужно, чтобы attention span'а хватило на сигнатуры, а это куда меньше, чем весь код.
Так ведь и в динамически типизированном варианте это прекрасно работает!
Вот пишем:
async function registerUserHandler(req) { const user = mapRequestToUser(req); await createUser(user); await sendRegistrationEmail(user); }Тут всего три строчки (6 если считать заголовок и пустые). На столько строчек attention span у нормального программиста хватает гарантированно.
Но вы почему-то упорно утверждаете, что нет, функцию registerUserHandler никак невозможно проверить взглядом, а вот ваши сигнатуры, наверняка раскиданные по нескольким файлам — они-то, конечно же, проверяются надёжнее. Но нет, этот так не работает.
Но вам из этой программы нужно только несколько ключевых утверждений
Тут соглашусь. Однако, часто и в основной программе достаточно только ключевые утверждения проверить. Тут надо подумать в чём вообще измерять сложность...
Source
12.06.2023 16:23-1Вот так мы от time to market перешли к срачу об определениях. Поэтому в условных Хаскелях и Идрисах time to market и страдает, что акцент не на том. Бизнесу вообще параллельно на чистоту ваших типов. И даже то, что вы не допустите ошибки, которые в программе на динамическом языке в 0.001% случаев выдадут юзеру 500-ку, бизнес не убедит, что это стоит лишней недели разработки.
0xd34df00d
12.06.2023 16:23-2Естественно, когда я пишу код, то я не срусь о том, что такое тип, как и вы не спорите постоянно о том, каким конкретно линтером пользоваться для питона/жс/етц (наверное).
0xd34df00d
12.06.2023 16:23Это детали. Важно, что «ну вот мы тут спорим о типах, поэтому TTM хреновый» — это такая припудренная форма «ой всё».
Source
12.06.2023 16:23Вообще-то пойнт о том, что TTM страдает от типов был начальным. И вы по сути согласились с этим, сославшись лишь на то, что без типов вам не спокойно за то, что вы выкатили в прод. Дальше уже чисто оффтопик пошёл.
0xd34df00d
12.06.2023 16:23Мне не просто «не спокойно». Без типов в том, что выкатывается в прод, ошибок находится больше, чаще и серьёзнее, чем в том, что обложено типами.
Хотя первая выкатка да, быстрее. Потом, конечно, таски про «undefined is not a function», спринты, сторипоинты. Борда крутится, лавэха мутится.
Source
12.06.2023 16:23Без типов в том, что выкатывается в прод, ошибок находится больше, чаще и серьёзнее, чем в том, что обложено типами.
О, ну хорошо хоть вы не стали утверждать, что со статическими типами ошибок совсем не будет, скомпилировалось же)
Ну а так да, это компромиссный вариант. Edge-кейсы возможны и их риски бизнес принимает ради скорости выкатки. Я б может был не против тоже на Haskell что-нибудь написать, но в 99% случаев бизнес за Haskell платить не готов. Почему так, не знаете?
0xd34df00d
12.06.2023 16:23О, ну хорошо хоть вы не стали утверждать, что со статическими типами ошибок совсем не будет, скомпилировалось же)
Ну я ж на хаскеле пишу в основном, а не на коке-идрисе-агде.
Ну и ещё нельзя отрицать то, что вам бизнес-аналитик мог принести кривую задачу, неправильно поняв потребности рынка и что-нибудь такое. Тоже надо чинить ошибку, просто это ошибка несколько другого класса.
Я б может был не против тоже на Haskell что-нибудь написать, но в 99% случаев бизнес за Haskell платить не готов.
Так он и за адекватное тестовое покрытие в 99% случаев платить не готов, и за рефакторинг не готов, и за своевременное устранение легаси не готов, и так далее. Что это говорит?
А за Elixir, кстати, готов?
Почему так, не знаете?
Выбираете таких работодателей? Могу только сказать, что УМВР.
Олсо, у хаскеля на самом деле есть проблема, но это проблема не с типами, а с коммьюнити. Куча людей использует его не как средство написания кода, а как средство для повышения ЧСВ, рассказывая всем, что без теорката и умения рисовать коммутативные диаграммы в хаскеле жизни нет. Это создаёт несколько плохую славу и является ИМХО единственной причиной, почему немалое количество архитекторов выбирает другие языки.
Хотя язык на самом деле простой и дубовый как пробка.
cupraer
12.06.2023 16:23+1у хаскеля на самом деле есть проблема, но это проблема не с типами, а с коммьюнити
Ой, да ладно, как будто говноедов вне теоркатчиков мало. Это можно пережить, вы же там сами где-то написали: «Игнорируете, и сон снова как у младенца».
Если серьезно — то проблем я вижу две. Одна, косвенно связанная с тем, что вы говорите про коммьюнити, — очень ярко проявляется именно в вас. Думаю, что на работе это не так, но в социальной среде вы со своими типами — как тот чувак с молотком: везде видите гвозди. Несомненно, есть области, где типы очень помогают (я, правда, вижу ценность в завтипах, а не в голых адт). Тем не менее, фигачить круды, когда цена ошибки — пользователю показали 404, — проще и быстрее без них. Сложили пять и табурет? — Ну, транзакция упала, пользователя жалко, но мир жесток.
Типы не панацея и не серебряная пуля, как все инструменты, они тут помогут, тут навредят, а тут пофиг. Но средний типодроч влезет со своими типами просто повсюду, и это немного раздражает.
Вторая проблема — prelude и три четверти стандартной библиотеки, сделанная на отъеойди-не-мешай. У нормального языка не может быть такой нечеловеческий порог входа на чтение для тех, кто с ним не работает ежедневно по 12 часов и потому волей-неволей выучил все эти триста квадриллионов трехбуквенных функций, зачастую делающих одно и то же.
Что касается типов — всегда есть компромисс. Тривиальные для меня архитектурно задачи — я решаю в лоб, хоть на перле, хоть на си — и пишу для них property-based тест. Нетривиальные — доказываю на идрисе и перевожу на эрланг. Я знаю, что доказательство теряется, но во-первых, я — неплохой переводчик, а во-вторых, в этот момент, когда доказательство свершилось, задача стала обратно тривиальной архитектурно. Для меня такой смешанный подход — оптимален по КПД. У других может быть иначе.
0xd34df00d
12.06.2023 16:23Это можно пережить, вы же там сами где-то написали: «Игнорируете, и сон снова как у младенца».
Я-то что угодно переживу, а вот выбирающий технологию менеджер может насторожиться.
Тем не менее, фигачить круды, когда цена ошибки — пользователю показали 404, — проще и быстрее без них.
Так я спорю, что ли? Я ж не настолько типофашист. Ну, да, лично мне даже круды удобнее делать на хаскеле (чего там, взял сервант, а потом оно всё само). Когда надо было делать аналоги крудов, и обстановка к хаскелю не располагала, я и тестами пренебрегал (нафиг они нужны), и архитектурой, когда понимал, что бизнес за это не платит и бизнесу это не нужно. TTM наше всё, так ведь?
Вторая проблема — prelude
Ну вы прямо с козырей зашли.
Prelude отвратительна, да. Это одна из моих основных претензий к хаскелю. Впрочем, ему ж лет как C++, и 30 лет назад было как-то неочевидно, что в продакшен-языке делать нетотальные всякие там
head— очень плохая идея. Хорошо хотьHasCallStackотносительно недавно завезли, теперь хоть понятно, где код падает, если падает.и потому волей-неволей выучил все эти триста квадриллионов трехбуквенных функций, зачастую делающих одно и то же.
А вот тут — вы таки мимо. Квадриллионы трёхбуквенных функций учить не нужно.
Нетривиальные — доказываю на идрисе
Но как? Идрис 1 тормозит как не в себя (мне довольно легко удавалось получать времена тайпчекинга в ЕМНИП 5-10 минут для модулей на полсотни строк, а всего-то немного поигрался с имплиситами). Идрис 2 не готов, там есть проблемы с termination checker'ом,
Type : Typeи всё такое.
cupraer
12.06.2023 16:23Я там, где учить, имел в виду для «комфортно читать», и даже написал про это.
Но как? — но так же :) это прототип, можно подождать, что делать?
0xd34df00d
12.06.2023 16:23А, ну и да, совсем забыл про эти ваши TTM'ы. В практически произвольную кодовую базу на хаскеле я могу заныривать и продуктивно туда контрибьютить уже через час, даже если я проект вижу впервые в жизни. С каким-нибудь питоном такое не прокатывает почти никогда, с плюсами — если очень сильно повезёт, и исходная команда разрабов была очень дисциплинированная. Окамль (которого я не знаю) был на практике где-то между хаскелем и плюсами.
RH215
12.06.2023 16:23-1сильная динамическая типизация с опциональными type-аннотациями
Вот именно тут можно пойти дальше и взять язык со статической типизацией. Динамика была явно быстрее в сравнении Java vs Python образца 2003 года. Но в 2023 всё как-то стало по-другому.
Source
12.06.2023 16:23-1Но в 2023 всё как-то стало по-другому.
И что же интересно поменялось? Входящие данные в вебе как были произвольного формата, так и остались.
0xd34df00d
12.06.2023 16:23-1И что вы собрались делать с данными произвольного формата, кроме как прочитать их из одного сокета и записать в другой?
0xd34df00d
12.06.2023 16:23То есть, вы уже знаете, что формат там не совсем произвольный, а, например, жсон. Это хорошо.
Что вы собрались обрабатывать «в дальнейшем», даже если вы знаете, что данное поле распарсилось как строка, но вы ничего не знаете о семантике этого поля?
Source
12.06.2023 16:23Семантика этого поля зависит от бизнес-требований, которые постоянно меняются. Поэтому фиксировать её в типах неразумно дорого.
И даже JSON может однажды поменяться на какой-нибудь Avro и ничто не помешает поддерживать оба формата параллельно.
0xd34df00d
12.06.2023 16:23+1Семантика этого поля зависит от бизнес-требований, которые постоянно меняются.
И что вы с полем можете сделать, если вам его семантика неизвестна?
А если семантика таки известна, просто меняется часто, то вы просто берёте и меняете тип, а дальше тайпчекер вам сам говорит, что и где поменялось. Неразумно дорого — обкладывать всё это тестами вместо этого.
И даже JSON может однажды поменяться на какой-нибудь Avro и ничто не помешает поддерживать оба формата параллельно.
А с типами кто мешает?
aamonster
12.06.2023 16:23+1Накручено именно что поверх. Тот самый event loop – он ведь даже не часть языка.
Но соглашусь, не подходит. Чистого языка нет в природе :-), и вместо алгоритмов и структур данных окунёшься во фреймворки и библиотеки.
spaceatmoon
12.06.2023 16:23-1Я до сих пор не понимаю почему все так ругают слабую типизацию. Ты просто не складывай строки и с числами, и тебя не будут бить табуреткой.
0xd34df00d
12.06.2023 16:23+3Я до сих пор не понимаю почему все так требуют тесты. Ты просто не пиши ерунду и бажный и код и аккуратно рефакторь, и тебя не будут бить табуреткой.
mayorovp
12.06.2023 16:23+4Проблема слабой типизации — в том, что она до последнего прячет ошибку. Зачастую потом ошибка всё равно всплывает, но откуда она взялась приходится искать.
А корректной программе да, не важно какая в языке типизация.
Source
12.06.2023 16:23Вы, видимо, слишком простые программы пишете, если складываете только литералы. С переменными за этим следить гораздо сложнее, особенно когда они пробрасываются глубоко по стеку вызовов.
spaceatmoon
12.06.2023 16:23Ну так получается ругают за слабую типизацию какая-то определённая группа разработчиков, но кричат об этом больше всех. Браво.
javalin
12.06.2023 16:23Эта группа разработчиков кричит больше всех, потому, что она наиболее многочисленная. Все логично )
Вот есть у вас допустим переменная "month", которая приходит с поля ввода пользователем через несколько классов, и попробуй пойми по быстрому строка это или число? А если "String month" или "int month", то сразу понятно.
DMGarikk
12.06.2023 16:23+5забавно что в крупном проекте на питоне всегда всё рано или поздно до этого доходит, сразу всплывают и интерфейсы и сериалайзеры и аннотации типов и все что буквально вчера было "никомунинужно лишнаяяписанина" сразу становится норм и везде так делаем и разрабы массово переобуваются с "нинужно" на — обязательно
0xd34df00d
12.06.2023 16:23А если "String month" или "int month", то сразу понятно.
Что понятно? А в строке там "Dec", "December" или "Январь"? А в числе там нумерация с нуля ил с единицы, и что мне делать с -1-м или 14-м месяцем?
Не,
Stringилиintлучше, чем ничего, но очень, очень слабо.
spaceatmoon
12.06.2023 16:23Начинал с Ассемблера как первый язык. Мне что-то не очень помогло... Я бы не сказал что это дало мне фору перед ребятами начавшими с Visual Basic, Java и т.д, т.к. Ассемблер не язык новичка и всё что там было написано очень тяжело давалось. Тем более при самостоятельном изучении. Написал пару учебных приложений из книжки и плюнул. Только спустя долгое время снова начал с JS, а потом и бэк, и C под ардуино. Лучше действительно начать с чего-то лёгкого, а там уже тяга сама появится.
AntoineLarine
12.06.2023 16:23Ассемблер как первый язык - жёстко, только для реальных фанатов. Но его всё равно надо хоть чуть-чуть изучить. Потому что только с его помощью ты реально напрямую управляешь процессором, понимаешь, что скрыто под пятью капотами и как оно в реальности работает "в железе". И осознаёшь, что никакой магии нет, и все высокоуровневые абстракции в итоге сводятся к чётко описанному набору команд конкретного процессора.
Satyricon
12.06.2023 16:23-1Я считаю, что программирование нужно начинать преподавать с ассемблера с рассказами о машинных кодах. Ну то есть почему эта инструкция такая и почему у неё такой код, как это соотносится вообще с архитектурой процессора и т.д. Хотя бы в ознакомительном режиме, для понимания как оно на самом низком уровне работает. А то мне тут один соискатель не смог двоичное число в десятичное на бумаге перевести, при этом человек пришел из разработки. Сказал - нам в институте объясняли, но я не помню. Про битовые маски впервые слышит, а у нас как раз работа с оборудованием, биты вычленять и т.д. Никакого снобизма.
0xd34df00d
12.06.2023 16:23+5Я считаю, что программирование нужно начинать преподавать с лямбда-исчисления и систем типов, потому что…
А то мне тут один соискатель не смог двоичное число в десятичное на бумаге перевести, при этом человек пришел из разработки. Сказал — нам в институте объясняли, но я не помню. Про битовые маски впервые слышит, а у нас как раз работа с оборудованием, биты вычленять и т.д.
…у нас работа с логикой, свои тайпчекеры пишем и т.д., а тут один человек пришёл и не может даже описать правила типизации для классического STLC.
nightlord189
12.06.2023 16:23-3Я двоичные числа в десятичные последний раз в универе на 1 курсе переводил и забыл ровно через 2 недели после сдачи, больше никогда не пригождалось в работе. Так что надо все-таки какую-то более общую для всех базу брать, кому захочется спуститься на уровень ниже - и сам найдет способ это сделать.
aamonster
12.06.2023 16:23Скажем так – учить схемы косвенной адресации всё равно придётся, но можно не начинать с этого)
RH215
12.06.2023 16:23+2Раньше мы разбирались как всё работает на уровне ассемблера, как компилятор проводит оптимизации, как работают виртуальные машины и сборщики мусора.
И сейчас этим тоже интересуются. И раньше не все интересовались. Для работы с Delphi и Basic это не требовалось.
Сейчас же такие вопросы на собеседовании де-факто под запретом, потому что с такими вопросами вы вообще никого не наймёте.
А у меня спрашивали. Вопрос в том, куда устраиваться. Можно попробовать попроходить собеседования в HFT и понять кто тут на самом деле неуч, который ничем не интересуется.
Source
12.06.2023 16:23+1Для работы с Delphi и Basic это не требовалось.
Ну, почему же. В Delphi были ассемблерные вставки)
Но в целом вы правы, всегда были и те, кто интересуется, и те, кому параллельно. Просто по субъективным ощущениям процент интересующихся снижается.
RH215
12.06.2023 16:23+3Просто по субъективным ощущениям процент интересующихся снижается.
Это следствие массовости и востребованности. Как следствие: процент снижается, а вот абсолютное количество только растёт. Бонусная причина: сама область сильно выросла. Раньше человек мог быть хорошим специалистом и по железу, и по работе с железом, и по ос, и по хранению данных, и по разработке. Ну потому что лет 20 назад всё было гораздо проще. Требования ниже, железо - прямолинейнее, протоколы - примитивнее, кода - меньше, безопасность - это что? Сейчас такой набор - признак либо особо исключительного специалиста, либо, что более вероятно, дилетанта широкого профиля.
Areso
12.06.2023 16:23+2Сейчас такой набор - признак либо особо исключительного специалиста, либо, что более вероятно, дилетанта широкого профиля.
Осталось разобраться, кого из этих двух категорий ищет автор.
BerdBerd
12.06.2023 16:23+8Я учу жену и одного знакомого программировать - и да, жену учу с JavaScript - на фронта, а знакомого - с Python - на бекендера и инженера данных.
К чему такой снобизм?
Сейчас куча людей свалила из России из-за спятившего деда - и надо как-то устраиваться.
Если выучить Python за пол года - да, как программист человек будет первый год-два очень плохо кодить, с точки зрения снобов. Но на задачи автоматизации тестирования, инженерии данных - да и бекенд писать вполне подойдёт - в чём проблема?
Сейчас, в 2023 году у людей нет времени сначала 2 года учить программирование в школе, а потом ещё 6 лет в ВУЗе - да и уметь написать компилятор или знать как работает ассемблер - тоже задачи нет. Есть цель - закрывать простые задачи лучше индусов - и получать за это денег достаточно, чтобы выжить за границей.
Source
12.06.2023 16:23Так вы учите их не программировать. Вы учите их кое-как закрывать простые задачи лучше(?) индусов. Это принципиально разные цели. Называйте вещи своими именами и никакого противоречия между нашими высказываниями не возникнет.
Если выучить Python за пол года
Что в вашем понимании означает "выучить Python"?
spaceatmoon
12.06.2023 16:23Что плохого в Python или JS? Начинающего прежде всего надо заинтересовать.
Source
12.06.2023 16:23+1Кому надо? Продавцам курсов?
Если человеку самому неинтересно, то зачем его заинтересовывать? Что за насилие над личностью?Что плохого в Python или JS?
На этот вопрос уже выше ответы есть.
spaceatmoon
12.06.2023 16:23Любую деятельность надо рекламировать. Для этого нужно создавать положительный климат, а ваша позиция понятна - вам не нужно, никому не нужно.
Source
12.06.2023 16:23Любую деятельность надо рекламировать.
Весьма спорный тезис. Вы вот дышите, едите, спите, ходите, вам точно всё это рекламировали?
P.S. Если речь про детей, то я согласен, что им надо показывать разные виды деятельности и возможно даже умеренно заинтересовывать. А у взрослых должен сначала собственный интерес просыпаться.
TimsTims
12.06.2023 16:23+2ты должен знать свою область на 200%, а все что смежное хотя бы на 100%
Это не так. Как стать лучшим в мире в какой-то нише.
dyadyaSerezha
12.06.2023 16:23Никого ничего не выдавит, как не выдавил аналогичных из других специальностей за тысячи лет цивилизации
aamonster
12.06.2023 16:23Не знаю, с программерами беда: соискателей много, а нанять некого, и не видно, чтобы была проактивная масса, которая кого-то выдавливает.
surge82
12.06.2023 16:23Если эта толпа будет, потому что искать работу в ИТ без опыта - это капец. Прекрасно помню своё начало, сменил работу переводчика в свои 40, всю теорию выдрочил, да хоть бы кто позвонил. Как раз попал на тот момент, когда к нам Казахстан поехали россияне и украинцы, в общем всё одно к одному. В итоге помогли связи, сейчас знаю немного RHEL, VMware, Netapp, ну и сервис оборудования Фуджитсу.
sartorius9
12.06.2023 16:23+427 ноя 2020 здесь на Хабре появилась статья - Инженерное нелюбопытство
https://habr.com/ru/articles/530300/
...интеллектуальную и технологическую элиту страны, для которой <неочевидна> сама идея заглянуть внутрь...
Вот и делайте поправку на неинженерное мышление современных "инженеров".
micbal
12.06.2023 16:23+10Чтоб нанять много знающего специалиста, как мне кажется нужно много платить. Тогда у других будет мотивация становится такими специалистами. Первый вопрос к вакансии: "Платить пробовали?"
jumper_xf-666 Автор
12.06.2023 16:23По нашим оценкам, имеем медианные вилки.
lorc
12.06.2023 16:23+36На медианные вилки приходят медианные разработчики.
jumper_xf-666 Автор
12.06.2023 16:23Ох, как бы этого хотелось, но нет(
germn
12.06.2023 16:23+32Если на медианные вилки приходят разработчики хуже медианных, то, очевидно, чтоб приходили хотя бы медианные разработчики, нужно платить выше медианных вилок. Оригинальный посыл остаётся в силе, как видите.
lorc
12.06.2023 16:23+3После того как началось засилье трехмесячных айтишных курсов, медиана сильно просела, к сожалению.
micbal
12.06.2023 16:23+6Тогда будет медианный уровень знаний. В данный момент он такой, и будет снижаться, так как требования растут, а технологии меняются и добавляются. Раньше нужно было знать Linux, потом Linux и Docker, теперь Linux, Docker, k8s.
blind_oracle
12.06.2023 16:23+1Только вот многие довольствуются знаниями k8s/Docker и всё что под - их не интересует. Поэтому это вроде как эдакое "плавающее окно" знаний получается и оно смещается вправо по оси абстракций :)
Source
12.06.2023 16:23+8Кстати, тут есть эффект потолка. Например, я могу программировать в 10 раз круче условного миддла с з/п 150 т.р./мес, но при этом мне никто не будет платить 1.5 млн.р. в месяц (во всяком случае в 2023 году). Так что денежной мотивации развиваться по сути то и нет.
Особенно это чувствуется после того, как в начале карьеры твоя з/п постоянно растёт и в какой-то момент просто упирается в определенный уровень и дальше чисто на официальную инфляцию индексируется, при том что ты продолжаешь развиваться и накапливать годы ценного опыта.
aborouhin
12.06.2023 16:23+13А потом вступает в действие принцип Питера, тот самый про то, что "каждый растёт до уровня собственной некомпетентности". Т.к. единственный способ дальше поддержать ценного сотрудника материально, когда он уже достиг старшего экспертного уровня, - продвинуть его на менеджерскую позицию. А менеджер из него, весьма вероятно, будет плохой. В итоге система превращает лучших экспертов в плохих менеджеров. Таковы суровые корпоративные реалии :) (впрочем, в своём бизнесе похожая картинка будет)
blind_oracle
12.06.2023 16:23+1В гуглах и ко обратная ситуация сейчас - менеджеров разжалуют в разработчики. А кто не хочет - на выход.
cupraer
12.06.2023 16:23достиг старшего экспертного уровня
У вас баг в определении старшего экспертного уровня. Или задачи простенькие, и такого удержать будет невозможно.
Ни один менеджер не получает суммы, сопоставимые с principal engineer и выше.
onyxmaster
12.06.2023 16:23+4А вот и 10x-разработчик в треде =) Зависимость логарифмическая, придётся терпеть =)
micbal
12.06.2023 16:23+2Народ вроде взрослый собрался, а все в 10x разработчика верят... :)
Source
12.06.2023 16:23+6Я тоже раньше не верил, когда в книжке про это читал 16 лет назад))
На деле всё ещё сложнее. Есть класс задач, где это соотношение растёт ещё больше. Т.е. один программист и за месяц и за два не сделает, то что другой может сделать за несколько дней.
aamonster
12.06.2023 16:23А вообще – сделает?
Может, надо мерить не скоростью восхождения на гору, а высотой, на которую может подняться?
Source
12.06.2023 16:23+5Кто-то, может, и вообще не сделает, или сделает, но оно будет работать в 100 раз медленнее. От этого ценность выполнения задачи разве снизится?
Например, у меня был опыт, когда я 3 недели переделывал проект, который до этого почти год пилила команда из 4 программистов. В итоге, ключевой сценарий использования всего этого проекта стал работать в 300 раз быстрее и в нём появились хотя бы end-to-end тесты.
Ну т.е. да, сколько бы им времени ни дали, нормально они бы всё равно не сделали.aamonster
12.06.2023 16:23Ну я, собственно, к тому, что "в 10 раз производительнее" – маловероятно, а вот если у вас сложные задачи – проблема, выбор кандидатов резко сужается, и цены, соответственно, растут.
Source
12.06.2023 16:23Ну, это довольно очевидно, что на простых задачах кратной разницы не будет, если за базовый уровень брать миддлов, а не стажеров.
ris58h
12.06.2023 16:23+2Например, у меня был опыт, когда я 3 недели переделывал проект, который до этого почти год пилила команда из 4 программистов.
Если там год требования устаканивались, то вполне закономерно.
Ну и ещё один анекдот вспомнился:
- Папа, папа, я сегодня выиграл свой первый суд! И знаешь, папа, это то самое дело которое ты вел все прошлые 10 лет и не мог выиграть, а я его выиграл за один день!
- Вы только посмотрите на этого идиота! Он сегодня за один день закончил дело которое кормило нашу семью почти 10 лет!
Source
12.06.2023 16:23+1Если там год требования устаканивались, то вполне закономерно.
Проблема была совсем не в этом)
Он сегодня за один день закончил дело которое кормило нашу семью почти 10 лет!
Не, ну если в таком ключе относиться к заказчикам, то да. Можно было бы ещё на год растянуть и понемножко ускорять.
Lazhu
12.06.2023 16:23+1Вспоминаются нулевые, повременная оплата и умники, переводящие харды из udma в pio. Было время...
Tsimur_S
12.06.2023 16:23+5В зависимости от того что взять за базис можно и 100х разработчика получить.
cat_chi
12.06.2023 16:23+1но при этом мне никто не будет платить 1.5 млн.р. в месяц
Ну, это уровень какого-то L4 в Google. В чём проблема? :)
Source
12.06.2023 16:23+1В России? Или мы резко начали сравнивать с американскими зарплатами?
cat_chi
12.06.2023 16:23+1А какая разница где? Профессия разработчика международная, а уж x10-разработчика – и подавно. Изначальный ваш посыл был – "я x10-разработчик, но никто не будет платить мне x10-зарплату". Я привёл пример, что вообще-то вполне могут, вы вводите дополнительные рамки... Ну так можно долго играть. Сначала уточняем, что "только в России", потом "только в Барнауле и непременно в офисе", так понемногу и дойдём до того, что разработчики с зарплатой выше 30к рублей – это фантастика
Source
12.06.2023 16:23+1Не, вы неправильно уловили посыл. Меня моя зарплата устраивает. Но я отвечал на комментарий:
Чтоб нанять много знающего специалиста, как мне кажется нужно много платить. Тогда у других будет мотивация становится такими специалистами.
И пойнт тут в том, что ни одна компания не может создавать такую мотивацию. В том же Google миддлы ведь не $25k/год получают, а гораздо больше. Поэтому заплата растёт, как тут уже кто-то писал, как логарифм от квалификации, а не линейно.
cat_chi
12.06.2023 16:23Справедливо, согласен. Надо будет как-нибудь посчитать статистику, как высчитывается зарплата специалиста относительно уровня, может получиться что-то интересное :)
PuerteMuerte
12.06.2023 16:23+3Например, я могу программировать в 10 раз круче условного миддла с з/п 150 т.р./мес, но при этом мне никто не будет платить 1.5 млн.р. в месяц (во всяком случае в 2023 году).
...но вы можете взять несколько проектов на аутсорс, если вы такой уж продуктивный.
Source
12.06.2023 16:23Вы имеете в виду уйти во фриланс?
Germanets
12.06.2023 16:23Да ладно уж, если вы работаете хотябы за 10 обычных девелоперов - ну вот устройтесь в три компании, делайте за 2 часа то же, что остальные за 6, и получайте х3 зарплату в сумме, для начала... Там, глядишь, и до своих х5-х10 подниметесь..
Я знаю несколько примеровгде люди сочетают несколько работ, более того, один из них прямо говорит компаниям - "мне не пойдёт ограничение, так как я хочу участвовать ещё тут и тут", и ничего, его с его продуктивностью и знаниями готовы брать, считать его консультантом и т.д.Source
12.06.2023 16:23+6Спасибо, x3 можно и без подобного геморроя получать. А параллельно работать над 10 проектами - это свихнуться можно от постоянного переключения контекста. Тем более, что один из секретов высокой эффективности в потоковом состоянии, а его невозможно поддерживать при постоянных переключениях :-(
cupraer
12.06.2023 16:23+1Ну над шестью (на трех разных языках) — вот я прямо сейчас работаю за обычную зарплату. И еще примерно 10 OSS-библиотек поддерживаю.
Source
12.06.2023 16:23И как ощущения? Пока нравится?
cupraer
12.06.2023 16:23А почему нет-то? Я библиотеки в рабочее время поддерживаю, разумеется, я не идиот — по ночам с зеленой лампой сидеть.
Я от переключающегося контекста устаю гораздо меньше, чем от рутинных задач на три дня.
Source
12.06.2023 16:23Ну, всё может быть, люди разные. А может просто не так давно этим занимаетесь.
cupraer
12.06.2023 16:2330 лет профессионально, а так-то больше.
Кстати, я там про Elixir в соседнем треде подсмотрел… Так вот, например, многострочные пайпы в
iexдля копипаста — это мои идея и код. Ну и по мелочи еще, да. И на стековерфло вы, скорее всего, моими ответами часто пользовались.И ничего, не устаю, не выгораю.
Source
12.06.2023 16:23Круто! В Elixir я тоже контрибьютил по мелочи. Но меня частое переключение контекста выматывает.
PuerteMuerte
12.06.2023 16:23Я не знаю, как назвать, например, ИП, которое работает на нескольких постоянных клиентов. Это не фриланс и не трудоустройство. Это просто бизнес. Плюс, масштабируемый - если ваша нагрузка по проектам будет расти, вы можете ещё кого-то уже на себя нанять.
nikolz
12.06.2023 16:23Почему-то вспомнилось. Давно это было. На конвейере Ваза два рабочих. Первый закручивает гайки качественно, в темпе движения конвейера. Второй быстро бежит вдоль конвейера и закручивает гайки в два раза быстрее, чем первый. Потом садится на скамейку и курит минут пять. Начальник отдела контроля качества жалуется: "Никак не может молодых приучить работать по технологии."
event1
12.06.2023 16:23Много платить не достаточно. Ещё должна быть работа интересная. Потому что знающие специалисты, скорее всего, уже неплохо зарабатывают и менять интересную работу на скучную ради просто денег не все будут. При условии, что денег достаточно уже сейчас, естественно.
Oll123
12.06.2023 16:23+9По моему вполне себе вопросы на девопс инженера.. я их тоже задаю. Равно как и тестовое/ или открытые репы с примерами.
Я как-то давно прочитал/услышал может быть и тут на Хабре - не бывает джуниор девопсов, слишком много надо знать. Я как-то вот согласен с этим. И сети и *nix и инструменты автоматизации от ансибла до дженкинса и аргосд, терраформы и террагранты и контейнеризация/виртуализация и базы и кластера и отказоустойчивость и безопасность. Плюс софт - коммуникация с командами, умение найти че болит у разработки или тестировщиков, иногда и решение/дизайн обсудить/подсказать или наоборот аргументированно отговорить, и т.д. и т.п. можно очень долго продолжать.
LINOLEUMfilm
12.06.2023 16:23+26ТРЕБОВАНИЯ К ВАКАНСИИ ВОДИТЕЛЯ, ЕСЛИ БЫ ОН БЫЛ ПРОГРАММИСТОМ.
Обратил внимание, что последнее время, лет так 10-15, требования к программистам уже вошли в некий своеобразный СВ стандарт. Нужен программист-ниндзя и всё тут.
Складывается ощущение, что все программисты просто пираты сорви голова в море компьютерных технологий.Кто-то заметил это, чуть раньше чем я и прописал вакансию водителя, так же, как её написал бы работодатель к вакансии программиста. Добавляю эту вакансию водителя со своими некоторыми комментариями. Давайте посмотрим что получилось.
ТРЕБУЕТСЯ ОБЫЧНЫЙ ЧЕЛОВЕК НА ВАКАНСИЮ ВОДИТЕЛЯ.
Вакансия: водитель.
Требования: профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулера, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими и средними танками, находящимися на вооружении стран СНГ и НАТО.
Навыки раллийного и экстремального вождения обязательны! Опыт управления болидами «Формулы-1» — приветствуется. Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих поизводителей — обязательны.
Опыт проведения кузовных и окрасочных работ — приветствуется. Претенденты должны иметь сертификаты Mercedes, BMW, а также справки об участии в крупных международных ралли не более чем двухлетней давности.
Зарплата: 3500-6999 рублей, определяется по результатам собеседования.
Обращаясь при себе иметь: паспорт, полис, пенсионое, ИНН, справка НДФЛ-2, свидетельства о рождении, дипломы, знаки отличия, рекомендации, справки и прочие документы, необходимые для подтверждения своего водительского класса.sim31r
12.06.2023 16:23+13А в качестве собеседования тестовое задание: сгоняй за пивом боссу в соседний город за свой счет. При этом на машине спущены колеса, бензобак пустой, аккумулятор разряжен, инструментов нет, машина без номеров. Посмотрим как водитель решает проблемы и примем решение о найме )
denis-isaev
12.06.2023 16:23+9А после выхода на работу водишь старую говновозку с барахлящим насосом и порванным шлангом, получая расписание на две недели вперед, после чего каждое утро, отчитавшись диспетчеру за вчерашний день, узнаешь, что где-то неожиданно прорвало и поэтому помимо плановых выездов, нужно еще откачать там. К концу двухнедельного плана отмываешь с тачки самые стрёмные разводы и демонстрируешь, что инструмент в рабочем состоянии и называются эти демонстрации - де
рмо показы. [/joke]
Thomas_Hanniball
12.06.2023 16:23+6Приведенные примеры подчеркивают нежелание большого количества нынешних специалистов погружаться в вопрос и разбираться в теме, что не может радовать.
Потому что в вакансиях, где в требованиях указано K8S, Cloud, Helm, Ansible, Gitlab CI, Teamcity или Jenkins, платят в разы больше денег, чем в вакансиях с "правильное определение потребления памяти", методы GET и POST, ping и traceroute. :)
Рыночек порешал, а кандидаты лишь к нему подстроились. Так что всё логично и закономерно.
init3
12.06.2023 16:23+15А вот вам несколько историй с другой стороны. Я DevOps инженер с опытом более 15 лет. Когда-то давно начинал как системный администратор. Умею настраивать Linux и сети. Есть несколько сертификатов. Например Red Hat Certified Engineer (RHCE), Red Hat Certified Systems Administrator (RHCSA), AWS Certified Solutions Architect - Associate (SAA). Это для контекста. Можете погуглить RHCE Exam objectives, что бы понять объём области знаний.
Так вот, последние полгода прохожу интервью и пока ни одного оффера.
Собеседовался в один банк - завалил кодинг интервью. Не смог за полчаса распарсить лог веб сервера Apache и найти топ самых часто встречаемых IP адресов.
Ну да, не хватает практики. Зарегистрировался на leetcode и hackerrank. Начал решать задачки регулярно. Подтянул Python.
Собеседовался в другой банк прошел кодинг и техническое интервью , но завалил поведенческое интервью. Не смог красиво и убедительно ответить на вопросы в стиле:
- Have you worked with a difficult client? How did you handle it?- Tell us about a time you had to resolve a conflict in a team.
Начал тренироваться в поведенческих интервью.
Собеседовался в третье место - опять прошел все технические, но завалил поведенческое интервью.
В четвертом месте уже не смог пройти техническое интервью. Не сумел решить гипотетическую проблему, что не устанавливается ssl соединение. Сервис запущен. Порт открыт. Оказывается дело было в том, что сертификат истек.
Ну да, признаю. Такого я не еще не дебажил. Последние годы я в основном перекладываю json на Python. Пришлось потратить вечер и разобраться как происходит ssl handshake.
Это я все к чему?
У DevOps и Site Reliability Engineer требования просто огромны. Одним нужен опыт программирования на Python или Java. Другим - в добавок опыт Kubernetes или OpenShift. А еще Public Cloud и Performance optimization и мониторинг.
Даже если ты все это умеешь, всегда найдется, что-то в чем ты не достаточно хорош.
Знаешь сети? А раздели мне сеть класса C на четыре подсети? И напиши мне адреса сети, маску и широковещательный адрес для каждой из них вот тут на салфетке?
mayorovp
12.06.2023 16:23+10Знаешь сети? А раздели мне сеть класса C на четыре подсети? И напиши мне адреса сети, маску и широковещательный адрес для каждой из них вот тут на салфетке?
Э-э-э, а чего тут вообще сложного? Разве что вспомнить как 128 и 64 в уме складываются...
Ответ, на всякий случай192.168.1.0, 255.255.255.192, 192.168.1.63
192.168.1.64, 255.255.255.192, 192.168.1.127
192.168.1.128, 255.255.255.192, 192.168.1.191
192.168.1.192, 255.255.255.192, 192.168.1.255init3
12.06.2023 16:23+4Согласен. Вопрос с подсетями несложный. Даже если ответ не знаешь, за вечер можно разобраться и потом будешь нарезать сети в любом размере. Они все по отдельности несложные.
Но вопросы бывают из разных областей. Ответил по сетям - завалил Kubernetes. Подтянул Kubernetes - завалил кодинг интервью.
А в добавок техническое интервью - это только один из раундов. Вероятно, самый простой.
mayorovp
12.06.2023 16:23+1Если требуется вечер разбираться в этом, то не стоило утверждать про знание сетей.
init3
12.06.2023 16:23+3А какой критерий знания сетей? Cisco сертификация? TCP/IP? ARP/DNS/DHCP/SNMP? Протоколы передачи в сотовых сетях? Где провести черту для базовых знаний? TCP window size - это базовые знания или уже advanced?
mayorovp
12.06.2023 16:23+5А фиг его знает, я не сетевик, я только 1 курс в универе прослушал.
Но обсуждаемая задача — это такие азы, что должна попасть в любое разумное определение знания сетей.
sirmax123
12.06.2023 16:23+1Я забил считать маски в уме
Ipcalc есть в любом линуксе в пакетах в в brew для мака. За одно и вайлдкард, если собеседник вспомнит кому это нужно
onyxmaster
12.06.2023 16:23+13Извините, "15 лет опыта DevOps инженера", и вы не знаете как работает TLS handshake, за полчаса не можете посчитать топ IP-адреса в логах? Умеете настраивать Linux и сети, но не можете разделить сеть класса C на 4 подсети?
Я согласен что на SRE нужно много смежных знаний, всякие куберы, прометеусы, jaeger-ы, golden signals, BPF и другие слова. Но то что вон там выше написано, это же базовые навыки системного администратора Linux, нет?
init3
12.06.2023 16:23+12Не знал, потому что не пользовался этим.
После неудачных интервью посидел вечер и разобрался. Теперь могу нарезать сети хоть на 4, хоть на 128 сегментов. Перед сном каждый день читаю RFC 8446.
Просто на работе я выполняю задачи которые нужны бизнесу, а они, обычно, про другое.
Если честно, то я считаю, что каждый инженер должен знать как устроен компьютер. Как работает операционная система. Понимать процесс загрузки начиная с bios/UEFI и до Login Prompt. Основы сетей. Не знать TCP header size это непростительно.
Я учу все это заново, каждые 4-5 лет, когда приходится менять работу. А потом забываю. Как забыл размер ключа, которым откручивал свечи автомобиля Москвич 2141 чтобы их просушить. Их вечно заливало карбюратором.
ALexhha
12.06.2023 16:23+4Если честно, то я считаю, что каждый инженер должен знать как устроен компьютер. Как работает операционная система. Понимать процесс загрузки начиная с bios/UEFI и до Login Prompt.
для общего развития - да, но в облаках, а очень много devops работает с ними, это вам не поможет никак, причем от слова совсем
Не знать TCP header size это непростительно.
и как оно помогает в решение ежедневных задач ? Это все равно, что программиста заставить учить на память параметры методов и точное написание имен самих методов/параметров, привет универ
aborouhin
12.06.2023 16:23+14Не смог за полчаса распарсить лог веб сервера Apache и найти топ самых часто встречаемых IP адресов.
Ну вообще, если задание описано верно, то не имея ни одной сертификации да и вообще будучи гуманитарием, для которого IT - ни разу не специальность, я за 3 минуты и 2 подглядывания в man написал примерно это:
cat /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -bgr | head -n10
То ли в задании были какие-то дополнительные усложняющие вводные, то ли я соглашусь с тем работодателем... сорри, не воспринимайте за личную нападку.
hogstaberg
12.06.2023 16:23+5Ну почему? Почему в 99.9% ситуаций, когда я вижу использование awk, это непременно стереотипный awk '{print $1}' ? =) Ну такая классная утилита же, мощнейшая как трактор. Можно вообще всё задание в единый вызов gawk запихать и потом лихо лопатить логи апача со скоростью пулемёта так, что интервьюер кофе поперхнётся)
Тоже no offence, просто грустно за утилитку.
mc2
12.06.2023 16:23+1Это современный DevOps:) к этому нужно привыкать.
Запустил grep и проверяем что обнаружилось. Потом опять этот же grep и парсим через awk {print $1}... Сейчас это почти норма...:(
0xd34df00d
12.06.2023 16:23+6Ну такая классная утилита же, мощнейшая как трактор. Можно вообще всё задание в единый вызов gawk запихать и потом лихо лопатить логи апача со скоростью пулемёта так, что интервьюер кофе поперхнётся)
Не юниксвейно!
ALexhha
12.06.2023 16:23+1Ну почему? Почему в 99.9% ситуаций, когда я вижу использование awk, это непременно стереотипный awk '{print $1}' ? =)
$ cat test.txt | grep keyword | wc -lиз этой же оперы, а ведь можно же просто
$ grep -c keyword test.txtP.S.
помню парсил как то большие логи - 100-200 гб и вот такие моменты там очень были заметны в контексте скорости выполнения. Иногда разница доходила до 15-20 минут
FlashHaos
12.06.2023 16:23+6Кстати, я нашел ответ на вопрос «а почему лично я делаю cat | grep”. Ответ простой: можно потом ^W удалить поисковый запрос и попробовать другой. А потом, когда найдется нужное, можно сразу не меняя команду приписать wc-l.
Потому, что реальная работа - это не сделать красиво и не сделать правильно. Это сделать быстро и эффективно.
sirmax123
12.06.2023 16:23+1Без размера файла в задаче писать оптимально это пожирать время. Я полностью согласен с тем что да лучше сразу идеально без лишних форков но жизнь говорит что надо писать быстро, а оптимизировать если работает медленно.
Lazhu
12.06.2023 16:23+1Можно еще и упихивать весь выхлоп в sql в том же единственном вызове awk, а то некоторые особо одаренные по отдельной команде на каждое поле шарашат и удивляются, чего это всего пара тысяч строк 20 минут парсятся
selivanov_pavel
12.06.2023 16:23+12А зачем? Если это скрипт, постоянно работающий с большими файлами - может, и имеет смысл. Но если это разовая задача, то на написание кода на awk будет потрачено больше времени, чем не отрывая рук набить пайп из простых как молоток grep - cut - sed s///g - sort - head.
hogstaberg
12.06.2023 16:23Потому, что это возможно! =)
Не, на самом деле для разовой операции и правда быстрее набить неоптимальную портянку с кучей пайпов. Но если нужно такое делать регулярно, то чистый awk мне в ряде случаев давал натурально стократный прирост в скорости. Только вот я даже в таких ситуациях чаще всего вижу скриптик, в котором написали портянку с пайпами.
saboteur_kiev
12.06.2023 16:23А зачем вам cat?
у вас нет парсинга айпи адресов, тупо сортировка строк, и учитывая что лог начинается с даты, у вас все строки уникальные. Какой тут вообще результат предполагается?
Ожидалось хотя бы выкусить айпи адреса из строки, и уже их сортировать.EngineTech
12.06.2023 16:23cat порой нужен для файлов которые в текущий момент времени открыты в приложении, так как позволяют зафиксировать их содержимое.
saboteur_kiev
12.06.2023 16:23Так следующий grep/sort или еще что-то, сделает тоже самое - прочитает и зафиксирует содержимое. Под капотом и греп и cat/tac читают построчно
EngineTech
12.06.2023 16:23cat порой быстрее grep, что важно в случае большого потока логов и возможности ротации файлов прям из под ног grep. Кейс редкий, но привык уже сначала вывод файла в stdout, потом манипуляции над ним.
saboteur_kiev
12.06.2023 16:23+2хм. вы уверены, что cat считывает весь файл в память, перед тем как передать его в пайп?
Я вот сомневаюсь, там какой-то буфер есть, но cat точно не будет гигабайтный файл грузить в память, перед тем как переслать его дальше.
А если так, то cat file | grep и grep file будут почти одинаковы. Минус пару миллисекунд на лишний процесс
oficsu
12.06.2023 16:23+1TL;DR: пайп позволяет визуально отделить вход от выхода и совершать меньше действий в процессе правки команды
В своём рассуждении, вы ловко выкинули из примеров команд
pattern:grep pattern file cat file | grep patternА ведь чаще всего вы будете нажимать стрелку вверх и менять именно паттерн (или даже весь
grep) при том, что имя файла будет оставаться фиксированным. Но каждый раз, нажимая стрелку вверх, ваш курсор будет оказываться в конце строки, т.е. рядом сfile, и вам каждый раз нужно будет перепрыгивать его, чтобы добраться до паттерна, который будет за сессию работы меняться куда чаще. Лично мне лишние прыжки через имя файла удовольствия не доставляют, поэтому я сознательно используюcat. Вы, конечно, можете опротестовать и предложить мне более эффективную (с точки зрения машины) альтернативу:< file grep patternНо. Стрелку легко перепутать, уничтожив файл. Во-первых, стрелки рядом на клавиатуре; во-вторых, даже будь они далеко — перепутать их всё ещё можно. Ещё здесь нет явного и заметного разделителя, который было бы удобно искать глазами — имя файла миксуется с командой; в случае с
catтакой разделитель есть — пайп. Да и просто же выглядит довольно уродливоsaboteur_kiev
12.06.2023 16:23Ну я могу предложить другую альтернативу
^oldfile^newfile^
или если у вас так часто используется эта конкретная команда, заюзайте там имя переменной вместо имени файла
Никто не мешает вам пользоваться вашим любимым способом.
У меня основная претензия была к "cat порой нужен для файлов которые в текущий момент времени открыты в приложении, так как позволяют зафиксировать их содержимое." - вот с этим я не согласен
Lazhu
12.06.2023 16:23-7За 'cat' я бы сразу посылал в пешее эротическое. Гуманитарию простительно, конечно...
selivanov_pavel
12.06.2023 16:23+2cat x | grep y
удобнее использовать, если надо погрепать много разных y: Up,^W - и можно писать новый y. А в виде grep y x надо ещё каждый раз позиционировать курсор, прежде чем стирать y.
saboteur_kiev
12.06.2023 16:23Не совсем понял что имеется ввиду?
selivanov_pavel
12.06.2023 16:23+1Я отвечал на комментарий, что cat простителен только гумманитариям. Видимо, хардкорные технари должны испытывать нечеловеческие мучения, глядя, как
cat f | grep xтеряет немного производительности и создаёт лишние процессы по сравнению сgrep x f.ИМХО для разовой задачи это вообще не имеет значения, да и для периодической разница будет малозначительна, всё равно оно в чтение с диска упирается, а не в перекидывание строк внутри оперативной памяти.
saboteur_kiev
12.06.2023 16:23+1Производительности он не теряет. Но меня пытаются убедить, что cat быстро считывает текущий файл, а греп читает его долго. И в случае, когда в этот файл кто-то еще пишет, может быть разница. Ситуацию хотелось бы прояснить, я в такое неверю. Не смотрел исходники cat, но все стандартные гну тулс читают файл построчно и память под весь файл аллоцируют разве что всякие сорт, которым это необходимо.
selivanov_pavel
12.06.2023 16:23Немного теряет, как минимум на переключения контекста: положить данные в пайп - сикол из одного процесса, вынуть данные из пайпа - сискол другого процесса. Но на современном железе это будет на уровне погрешности, упрётся в чтение с диска.
В остальном вы правы: cat пишет в пайп, пока буфер не заполнится, и не может писать дальше, пока данные оттуда не заберут. man 7 pipe говорит, что размер этого буфера небольшой:
In Linux versions before 2.6.11, the capacity of a pipe was the same as the system page size (e.g., 4096 bytes on i386). Since Linux 2.6.11, the pipe capacity is 16 pages (i.e., 65,536 bytes in a system with a page size of 4096 bytes). Since Linux 2.6.35, the default pipe capacity is 16 pages, but the capacity can be queried and set using the fcntl(2) F_GETPIPE_SZ and F_SETPIPE_SZ operations.
laatoo
12.06.2023 16:23-1не имея ни одной сертификации да и вообще будучи гуманитарием, для
которого IT - ни разу не специальность, я за 3 минуты и 2 подглядывания в
man написал примерно это:cat /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -bgr | head -n10
верим, верим
saboteur_kiev
12.06.2023 16:23+5Не смог за полчаса распарсить лог веб сервера Apache и найти топ самых часто встречаемых IP адресов.
Блин, ну полчаса на такую задачу это же перебор.
Я считаю, что девоп инженер (автоматизатор же), должен неплохо знать хотя бы один скриптовый язык, которые работает с текстом. Эта штука даже в awk по идее решается за полчаса, хотя там синтаксис не всем нравится.
navion
12.06.2023 16:23Мне кажется это троллинг, похожий вопрос с пайпами точно был в EX200 и даже если его задали в секции кодирования, то человек каждый день пишуший код легко выдаст решение.
0mogol0
12.06.2023 16:23+7Хм... задумался. Я начинал свою карьеру в IT четверть века назад (в том, что сейчас называют Ops, а тогда это было администрирование). За это время я успел освоить Windows Server 2003 (включая развертывание своего леса, миграции контроллеров итп). Потом сменив работу освоил Фрю и Циску (не как эксперт, но понять что не так и подправить роутера конфиг мог). Дальше были ПО для обмена сообщениями и сервера приложений (а параллельно немного БД, немного Unix). Системы автоматизации и контейнеры. Сейчас вот облака...
При этом информация про технологию CSMA/CD используемую в Ethernet, про которую мне рассказывали в универе мне пригодилась один раз - и то на собеседовании. Если в начале карьеры, когда инет был диалапный, знания "в голове" были необходимы потому, что по другому их не получишь. То сейчас мне хватает понимания, что это примерно делается так, а дальше за точной командой я просто открою гугл.
Помню, для одного заказчика пришлось писать скрипт по поиску и удалению старых файлов, которые ежедневно генерировались в огромных количествах. Первый раз я потратил пару дней (с учётом других задач) прежде чем с помощью гугла нашёл набор подходящих ключей для команды find. Пару лет спустя, на другом проекте, когда возникла аналогичная задача - я восстановил тот же скрипт опять используя гугл, просто потому, что нет никакого смысла помнить все ключи этой команды все эти годы. Но да, мне потребовалось всего пара часов, так как я "в общем" помнил направление в котором надо идти.
Не скажу за стартапы, где команда состоит из 10-20-30 человек, но на проектах, где я обычно участвую, только IT отдел состоит из нескольких сотен человек. И человек отвечающий за автоматизацию отдельного проекта никогда не будет настраивать сам доступ в интернет, устанавливать и конфигурировать БД, создавать пользователей, или отвечать за железо (физическое или виртуальное). Для всего этого есть свои отделы, и от тебя требуется запомнить, как они называются, и кого в каком случае надо дёргать.
Поэтому конечно команды traceroute / tracert, ping, ifconfig / ipconfig я знаю. Но если они показывают что-то не то, то дальше это вопрос к сетевому инженеру, которому я передам обнаруженное. Аналогично я пользуюсь иногда командами ps -fu / ps -a |grep, но опять же не лезу в особенности вывода. Если потребуется - я через гугл найду какие параметры нужно ему задать, чтобы узнать, что мне нужно.
С этой точки зрения, я скорее всего не пройду собеседование, если попросят написать "на бумажке" скрипт или объяснить какие-то параметры в выводе, которыми я не пользовался в последние дни. Но наработанный опыт даёт определённое понимание, что происходит под капотом, так что при необходимости разобраться я сумею.
Впрочем, я уже безусловно не отношусь к числу "энтузиастов ИТ", а скорее к числу "работников в ИТ". Но опять же судя по отзывам "бизнеса" их это вполне устраивает, когда продукт выполняет заданные функции, а не реализует всё новый и новый функционал, но не слишком стабильно. Наверное это не самая лучшая стратегия для стартапа, но для крупных контор - это гораздо практичнее.
aanovik42
12.06.2023 16:23+9Что мы можем улучшить
Я не знаю, что вы как организация можете улучшить, потому что проблема видится более общей. Требования к соискателям в IT выделяются сразу четырьмя особенностями:
Разрыв между теорией (объяснение работы TCP, нюансы работы сборщиков мусора) и практикой (условное крудошлёпство и кубернетисы). При этом теория изредка всё-таки очень помогает, так что её активно спрашивают на собеседованиях, и это вроде как правильный подход.
Крайне широкий спектр задач и технологий.
Крайне конкретные требования к этим знаниям. То есть вы не можете "придумать из головы" ответы на собеседовании, что отлично работает (и поощряется) в каком-нибудь маркетинге или продажах. Вы должны знать ответы на широкий спектр вопросов. Где-то вы можете порассуждать, особенно на задачах, но в теоретической секции от вас ждут абсолютно конкретных ответов. Если вы внимательно посмотрите вокруг, то увидите, что столь конкретные вопросы на собеседованиях далеко не в каждой профессии задают (а если задают, то обычно это довольно статичные знания из областей вроде математики или химии).
Целые пласты знаний просто устаревают и отваливаются либо из-за смены технологий, либо при переходе из одной компании в другую.
Теперь спросите себя: а почему ситуация должна отличаться от той, которую мы наблюдаем на рынке? Причём, я не хочу всё свести к банальному "требования завышены", вовсе нет. Просто вот вы написали:
80% соискателей с опытом администрирования nix систем не знают ответ, теряются или говорят очень странные вещи, 10% без объяснения выбора способны указать на колонку RES, и оставшиеся с разным успехом могут поговорить и порассуждать про виртуальное адресное пространство, разделяемую память, OOM, оверкоммиты, стэки, кучи и так далее.
Я рискну применить очень грубую экстраполяцию и сделать вывод, что 10% соискателей хотя бы примерно соответствуют вашим требованиям. Причём, это вовсе не означает, что те же соискатели не завалят собеседование в другой компании, у которой другие подходы, другой стэк, и вообще всё другое. 10% — очень неплохая цифра посреди этого цифрового хаоса, так что я не совсем понимаю, почему вы не счастливы со своими десятью процентами)
wufam
12.06.2023 16:23+7Самое печальное, что devops это не сети, не операционка как пишет автор, и уж тем более не кубер… вообще devops != инструмент. И уж тем более печально, когда заправляют devops , смазкой в виде sre. Все хотят специалиста «эксперта 6в1», но как посмотришь на зарплату которую готовы платить такому специалисту, хочется плакать, толи со смеху, толи от абсурда. Да безусловно плохо когда кандидат много чего не знает, и для него сфера только приток денег (без удовольствия). Таких видно из далека. Но как тошнит от таких «душнил» на собеседовании, дотошно спрашивая порой то что действительно ты не увидишь, не то что в своей деятельности, но и непосредственно в работе, ввиду ряда ограничений компании (имея другой специализированный отдел), даже ты можешь быть готовым работать с базами в каком нибудь банке, но тебе не дадут так как есть отдел DBA и.т.д.
IsKaropki
12.06.2023 16:23+320 лет назад, создавал специализированный сервер, в качестве протокола передачи был выбран XMPP, всё получилось, сервер используется, функционал расширяется (я слышал) и т.д. После этого я много и плотно занимался другими интересными вещами. Так вот, если сейчас меня спросить про тот самый сервер и тонкости работы с XMPP - Я НЕ ПОМНЮ. Да, я гарантированно разберусь в случае критической ситуации, но собеседование, скорее всего, завалю.
victor_1212
12.06.2023 16:23> Так вот, если сейчас меня спросить про тот самый сервер и тонкости работы с XMPP - Я НЕ ПОМНЮ
это нормально, если бы проводил с Вами интервью вероятно 10 мин хватило бы в основном понять что именно знаете, скажу откровенно из своего резюме примерно 90% вообще с трудом припоминаю, причем забыл сознательно что не просто, чтобы голову не забивать, иначе работать невозможно, если все помнить, столько накопилось
TalesFromApocalypse
12.06.2023 16:23надо резюме так и писать: тут помню - тут не помню
victor_1212
12.06.2023 16:23спасибо, когда у Вас будет типа 50+ лет в программировании, так и делайте :)
DrGluck07
12.06.2023 16:23+1Ладно там "20 лет назад". Я всё время имею дело с микроконтроллерами вообще и с клонами STM32 в частности прямо сейчас. Иногда делаешь что-нибудь типа приёма и передачи через USART с помощью DMA. А через три дня вообще не помнишь как там это DMA настраивать для другой задачи на МК другой серии. Но это и не нужно помнить в точности. Главное знать принципы работы и куда посмотреть чтоб вспомнить подробности. Тем более, что от серии к серии немного меняются настройки регистров и всё равно приходится открывать мануал и смотреть что там конкретно для этой серии.
И уж тем более мне не придёт в голову требовать знание всей этой кухни в подробностях. Можно даже вообще не иметь дело с железом и не знать про всякие там I2C, SPI и DMA. Главное уметь прочитать инфу и понять её.
MVS366
12.06.2023 16:23+24Старая песня о главном - я умный и хороший, а все вокруг идиоты и плохие.
80% соискателей с опытом администрирования nix систем не знают ответ
Если 80% соискателей не могут ответить на поставленные вопросы, это значит вы задаёте им не real-life задачи. Это утверждение применимо ко всем сферам ИТ.
Вы можете что угодно спрашивать, просто люди, которые умеют решать задачи к таким как вы не придут работать, вот и всё.
Навыки прохождения собеседований и навыки решать задачи - совершенно разные вещи.
Hledacek
12.06.2023 16:23+1Специально просматривал все ответы, чтобы найти этот, который отражает и мою реакцию. Тимлид это уже менеджер, а это совершенно другой набор скилов, и суждений которые надо развивать. Частая ошибка молодых тимлидов спрашивать экциклопедические вопросы и потом удивляться, что никого на рынке нет, зато самими себя чувствовать от этого "хорошо".
powerman
12.06.2023 16:23+1Чтобы задавать, как Вы их назвали, "real-life задачи", и нанимать тех, кто уже знает как такие задачи решаются, нужна уверенность, что ничего кроме перечисленных во время собеса задач данному кандидату за время работы в нашей компании решать не придётся. Такое, конечно, тоже встречается, особенно в компаниях с громадным штатом, которым нужна пара сотен миддлов однотипно перекладывать JSON в сотне типовых микросервисов, к примеру, но…
Очень часто от кандидата требуется не умение решать ограниченный набор заранее известных задач, а умение находить решение неизвестных ему заранее задач. Не потому что мы такие вредные и жаждем показать кандидату его полную несостоятельность, а потому, что требования бизнеса постоянно меняются, инструменты развиваются и заменяются, окружающая среда регулярно подкидывает новые неожиданные особенности, etc. - и в результате мы просто не имеем гарантированного и достаточного количества однообразных задач, которыми можно было бы загрузить сотрудника на full time на ближайший год. И вот тут понимание базовых вещей вроде упомянутых в статье становится критично важным.
Более того, на мой взгляд здесь проходит принципиальная граница между миддлом и сениором: если у миддла ещё иногда бывает такое, что он годами сидит на потоке привычных ему задач не требующих особо часто включать голову, то сениор по определению должен быть готов сделать любую задачу, включая совершенно ему незнакомые.
При этом сейчас стало много "войтивайти", которые прошли курсы/стажировку, поработали пол года в одной компании, и решили, что на этом напряг из-за необходимости изучать что-то закончился, что они уже стали состоявшимися специалистами, которым достаточно просто продолжать делать то, чему они научились (ведь на текущей работе этого хватает!), и сменив работу 2-3 раза за следующие 3-4 года они автоматически дорастут до "достойной их" зарплаты и лычки "сениор". А статьи вроде текущей - это просто следствие:
Интервьювер недоумевает, почему указанные в резюме технологии кандидат знает исключительно на уровне механического решения нескольких заранее известных кандидату задач;
Кандидат недоумевает, почему у него спрашивают какие-то "оторванные от реальности" базовые знания, вместо того чтобы убедиться, что кандидат отлично умеет справляться с несколькими знакомыми ему "real-life" задачами, чего ему вполне хватало на прошлой работе.
ALexhha
12.06.2023 16:23Очень часто от кандидата требуется не умение решать ограниченный набор заранее известных задач, а умение находить решение неизвестных ему заранее задач. Не потому что мы такие вредные и жаждем показать кандидату его полную несостоятельность, а потому, что требования бизнеса постоянно меняются, инструменты развиваются и заменяются, окружающая среда регулярно подкидывает новые неожиданные особенности, etc. - и в результате мы просто не имеем гарантированного и достаточного количества однообразных задач, которыми можно было бы загрузить сотрудника на full time на ближайший год. И вот тут понимание базовых вещей вроде упомянутых в статье становится критично важным.
а потом получаем как в гугл/яндексе - тебя мурыжат 5-7 собеседований, ты рисуешь им архитектуры и рассказываешь о системном дизайне. Ты уже вот вот шатл в космос будешь запускать. Выходишь на работу и по факту на проекте перекладываешь json'ы, а не вот это вот все )))
powerman
12.06.2023 16:23+1Да, конечно, такое тоже встречается. И я согласен, что это безобразие. Но это не отменяет всего сказанного ранее.
Wesha
12.06.2023 16:23+5Я — айтишник, я не хочу много знать
Я вот не хочу знать много. Я хочу знать ВСЁ!
saboteur_kiev
12.06.2023 16:23+5@jumper_xf-666,привет коллега.
Провел сотни интервью на позиции девопс и л3 саппорт инженер.
Все именно так.
В резюме кандидат сворачивает горы, знает кучу технологий. На деле - был отдел инженеров, за технологии отвечал кто-то еще, сам кандидат хорошо если подправлял уже существующее.
Глобальное, просто повсеместное незнание базовых вещей, базовых терминов.
Люди не знают чем гит отличается от гитлаб.
Не знают чем терминал отличается от шелла.
Сеньерные кандидаты не способны правильно пояснить банальные POSIX права доступа, путаются кто такой юзер в этих правах (зачастую это те, кто пришел в девопсы не из сисадминов а из девелоперов/саппорта/QA)
И так далее, так далее, так далее.
Ставят прометей, потому что там готовая связка штатных экспортеров и дашборов в графане для кубера, при этом смысла в этом мониторинге не очень много, потому что метрики самих приложений он не вытягивает, только самого куберкластера, и сделать что-то кастомное, например просто вытянуть из джавы данные по актуатору или jmx, если джава крутится внутри контейнера - даже не представляют как..
inkelyad
12.06.2023 16:23+7В резюме кандидат сворачивает горы, знает кучу технологий.
Так ведь индустрия сама приучила писать все эти горы. И не научилась писать описания вакансий.
Таких, что "Вам нужно знать и уметь то-то и тот-то до такого-то уровня. Иначе не возьмем." И потом действительно не брать, потому что все что указано в вакансии - действительно нужно. А если знает (или успел выучить по указанным требованиям) то, наоборот, гарантированно брать.
Ну вот так взаимно друг другу голову и морочим.
saboteur_kiev
12.06.2023 16:23+1Окей, примеры с моих интервью:
В резюме кандидат администрирует сотни вирутальных машин с разными линуксами, мониторит их.
На интервью не может распарсить -rwsr-xr-x вообще, не знает чем в топе USR отличается от SYS на загрузке процессора.
В резюме пишет что пишет много скриптов на баш.
Спрашиваю как почистить старые логи в директории - отвечает что ну напишу скрипт, в котором выполню команду ls, потом отсортирую по дате и удалю. Я показываю вывод ls, где формат даты совершенно неудобный для сортировки, начинается бекание мекание. Процентов 15 знает про find.
И так по всем темам.
И очень нравится, когда в ответах идет "это было давно, 3 года назад, я уже не помню что там было".
Я не знаю, я суть технологий с которыми работал 20 лет назад еще помню. Я могу детальный синтаксис не вспомнить, но понимать что и зачем делалось, а люди 2-3 года назад и вообще не помнят что там делалось...
Если человек работал с базами данных, у меня один из любимых вопросов - сколько времени занимал бэкап или какого примерно размера была самая большая база. Это как показатель, человек осознанно этим занимался или нет. И многие просто не знают/не помнят. Видимо никогда не делали тестовый рековер из бэкапа, чтобы знать сколько он займет и вообще работает или нет.inkelyad
12.06.2023 16:23+1Тут проблема, что используемое 'работал', 'имел опыт работы' - вообще мало о чем говорят. Прошел начальный курс по соответствующему ключевому слову - это 'работал' или еще нет? Стандартных используемых словесных конструкций не хватает. С точки зрения кандидата - он действительно как-то слегка работал. Так и написал. А вы его, внезапно, 'валите'.
Почему вообще есть инициатива заталкивать в резюме подобные строчки по тому, где наизусть справочник по технологии не помнишь?
Как по вакансии отличать таких как вы от тех, кому того уровня умений, что имеешь, будет достаточно? И что писать в резюме, чтобы те, кому надо больше, чем умеешь, не приглашали?
denis-isaev
12.06.2023 16:23С другой стороны, я почти уверен, что многие из таких кандидатов без проблем смогут задать вам вопрос, ответ на который для них очевиден и это знание считается базовым, а вы на него не сможете сходу ответить.
Неготовность сходу отвечать на вопросы зачастую говорит не о низком уровне соискателя, а о том, что его "быстрые знания" слабо пересекаются с вашими потребностями.saboteur_kiev
12.06.2023 16:23+1То есть исходя из моих примеров, девопс на мидл-сеньор позицию, который не знает как удалять старые файлы (логи) логи это нормально?
mayorovp
12.06.2023 16:23Так ведь логами обычно что-нибудь специализированное занимается, там надо не скрипты с сортировкой по дате писать, а указать в конфиге сколько логов хранить...
saboteur_kiev
12.06.2023 16:23Вот-вот, вы тоже не прошли.
Какие нафиг скрипты с сортировкой, если есть find / logrotate, а некоторые приложения действительно сами умеют этим заниматься. Но не все.mayorovp
12.06.2023 16:23Что-то я не понял сути претензии. Хотите сказать, что logrotate не является специализированным приложением для управления логами?
saboteur_kiev
12.06.2023 16:23Хочу сказать, что кандидаты, которые подаются на мидл и сеньор позицию не знают этих инструментов, и вопрос удаления старых логов или ротация логов ставит их в тупик, хотя это достаточно штатная задача.
Возможно это засилье людей, которые не видели софт без контейнеров, но для меня это выглядит как отсутствие базовых навыков.
M_AJ
12.06.2023 16:23+1если есть find / logrotate
А кто-то скажет, что logrotate древняя древность, в большинстве дистрибутивов у нас systemd и ротацию логов нужно настраивать в journald.conf да и вообще, логи нужно хранить в каком-нибудь GrayLog или ELK
saboteur_kiev
12.06.2023 16:23+1Ну вот уже неплохо, будет понятно как человек решал подобные задачи.
denis-isaev
12.06.2023 16:23+1Ну вот и имеем ситуацию, что для одного базовые навыки - это logrotate с которым он познакомился в начале своей карьеры, тыкая LAMP на первой работе в нулевые, а для другого базовые навыки - это ELK, с которым он познакомился в начале своей карьеры, тыкая k8s на первой работе в двадцатые.
И при этом второй без проблем, почитав доку, настроит logrotate, просто он с ним не работал ранее. И find-ом он пользуется от случая к случаю, поэтому чтобы составить на нем патч Бармина, ему нужна дока. Плохой ли он специалист из-за этого?
int03e
12.06.2023 16:23+3Я не знаю, я суть технологий с которыми работал 20 лет назад еще помню. Я могу детальный синтаксис не вспомнить, но понимать что и зачем делалось, а люди 2-3 года назад и вообще не помнят что там делалось...
Ну таки люди все разные. Я вот года 4 назад работал с ElasticSearch (не очень глубоко но работал, строил индексы, решал проблемы синхронизации). Если сейчас меня по нему начать спрашивать - я не отвечу ничего. Use it or loose it.
saboteur_kiev
12.06.2023 16:23У меня вопрос по эластику был бы таким
как данные попадали в эластик, какого объема, был ли ретеншн, по какому принципу именовали индексы, как раскидывали индексы по нодам.
Ничего глубоко технического, именно прикладное, чтобы было понятно что человек эластик настраивал для того, чтобы получить пользу и решал проблемы, которые чаще всего встречаются при больших объемах.
rzerda
12.06.2023 16:23+9У меня почему-то сразу вопрос возник: сколько (и в какой локации) ваша организация платит людям, которые всё это знают? Прямо с применением чисел, а не грейдов и «it depends».
Ну и Вы сами ответили на свою статью внизу: Вы ищете таких же энтузиастов, каким являетесь сам, а их относительно мало, и действительно много где людям сходят с рук чудовищные (для энтузиаста) вещи. Так что Вам нужно делать выбор - нанимать уже готовых «битых» и страдать от выхода в доли процента, либо нанимать обучаемых и учить, либо самому учиться пасти обыкновенных.
init3
12.06.2023 16:23+5На мой взгляд процесс найма/поиска работы в IT в принципе сломан. Потому, что есть множество областей знаний, которые обозначены формально (Linux/Unix, TCP/IP, CI/CD, Configuration management), а спрашивают по ним конкретно.
Возьмём, к примеру, получение прав на вождение машины. Есть правила дорожного движения - книжечка которую можно купить. Есть экзаменационные вопросы. Примеры экзаменов. Теоретический экзамен. Практический экзамен. Понятно, что от тебя ждут и как к этому подготовиться.
Теперь вернемся в IT. У меня несколько Linux сертификатов. (Готовился, покупал курсы, книги, сдавал экзамены). На работе - Linux. На домашнем компе - Linux. Все деплойменты в продакшен только через Ansible.
Можно ли утверждать, что я знаю Linux?
Где та линейка, которой можно померять знания?
В случае с водительскими правами это гос экзамен.
В случае Linux спрашивать могут что угодно.Moskus
12.06.2023 16:23+1IT - очень большая и сложная предметная область. Очевидно, что точно описать чьи-то знания даже в отдельной её части односложно - малореально.
sim31r
12.06.2023 16:23-1Соответственно имеет смысл принимать не по знаниям, а по IQ, если IQ>140 таких 1 на 10 000 населения, бесценный сотрудник. Если ниже 110 то в ИТ ловить нечего. Потолок развития сисадмин аникейщик.
M_AJ
12.06.2023 16:23+2Потому, что есть множество областей знаний, которые обозначены формально (Linux/Unix, TCP/IP, CI/CD, Configuration management), а спрашивают по ним конкретно.
Это так в любой более-менее сложной дисциплине, в них всегда приобретается некоторая узкая специализация. Если я закончил физфак, можно ли сказать, что я знаю физику? Если я окончил машиностроительный, значит ли это что я смогу спроектировать эффективную турбину? Так же и тут. Да и права, это просто показатель того, что вы владеете неким заранее установленным минимумом навыков, который считается достаточным, чтобы допустить вас к управлению ТС на дорогах общего пользования. Это даже не означает, что вы хороший водитель и понимаете все нюансы управления автомобилем – отправь вас на кольцевые гонки, или ралли и вы с огромной вероятностью либо придете последним, либо перевернетесь, так что и это не "линейка".
happyproff
12.06.2023 16:23Примерно поэтому в IT платят больше, чем водителям. Формализовать требования просто для доступных широким массам областей, но чем выше порог входа и объём знаний в области, тем шире требования.
happyproff
12.06.2023 16:23Если есть сомнения, то вот пример. В айти высококвалифицированный спец может решить сложную задачу в сто раз быстрее и лучше, чем низковалифицированный. И вообще решить, а не сломаться. А в вождении грузовых авто высококвалифицированный водитель может доставить груз быстрее и с меньшими рисками, чем низкоквалифицированный, но разница по скорости и рискам будет в лучшем случае в десятки процентов, но не в десять тысяч процентов.
bmzgjl
12.06.2023 16:23+8Ощущается прилив радости, и появляется настрой на интересный продуктивный для обеих сторон разговор.
Так охладите траханье или воспользуйтесь предназначенными для этих целей развлекательными сервисами в интернете. Обычно люди на собеседование идут не для интересных разговоров, а чтобы устроиться на работу, понять со стороны работодателя какими навыками обладает кандидат, а со стороны работника, какие обязанности и условия работы его ждут.
"Креативь" то, сам не знаю что - едва ли кому-то может понравиться в собеседование, тем более в самой работе
Boris3000
12.06.2023 16:23+10Резюме не имеет ничего общего с реальными знаниями и навыками соискателя
Как и описания вакансий. 1:1, побеждает дружба.
maiden666
12.06.2023 16:23+14Очередной автор с завышенными требованиями. Как сам и написал - должны глаза гореть, только у уже повзрослевших ИТ-шников - семьи и куча другой суеты, и для них работа - это просто работа, если надо они разберутся в чём то новом, а автор продолжает жить в розовом мире 00-ых, когда ИТ-шников было мало и у них реально горели глаза, потому что для них это было больше хобби.
M_AJ
12.06.2023 16:23-1Другим ярчайшим и популярным примером про неразрывность инструментов и методологий, как мне кажется, является разговор про CI/CD. Зачастую, CI/CD - это Gitlab CI, Teamcity или Jenkins, а не методологии, решающие конкретный список проблем/задач в процессах разработки
Это конечно методологии, но существует ряд мейнстримовых инструментов, используемых для их реализации, и люди на рынке в массе своей владеют именно мейнстримовыми инструментами. Не их вина, что вы написали свои велосипеды. В конце концов, операционная система тоже не одна на рынке, но вы же требуете от людей знаний конкретных реализаций (Linux) а не только лишь понимания общей концепции. Если вы не пользуетесь мейнстримом, то и выбор кандидатов для вас сокращается естественным образом, сетовать на это как-то странно.
stanislavskijvlad
12.06.2023 16:23+2Пока я читал пост и комментарии, родилась мысль, которой мне хочется поделиться. А что, если не соискатель будет ходить на собеседования, а наоборот – эйчар, представитель генерального и сеньёр будут ходить на ярмарку вакансий, очно. «Здравствуйте. Из какой вы организации ? Почему я должен работать у вас ?» и далее по смыслу ?
victor_1212
12.06.2023 16:23+1по опыту работы в us, все это давно существует, проводится регулярно, типа снимается зал где-нибудь в гостинице на один день, дается объявление, приезжают представители компаний, обычно несколько десятков, приходят люди и разговаривают в довольно свободной обстановке, компании собирают резюме, дальше звонят как обычно, приходилось бывать конечно, но самый правильный путь к новой работе это networking, т.е. просто дать знать бывшим коллегам которые работают в разных компаниях, что типа свободен, более того в действительно интересные проекты в основном так людей и набирают
sim31r
12.06.2023 16:23Ходят, только за специалистами более высокого уровня с зарплатами потенциальными в миллионы $, это научные сотрудники молодые с высоким потенциалом, золотомедалисты уже проявившие себя в научной среде. Вот тут интересная статья, как на таких выходят, что предлагают: https://www.nanonewsnet.ru/blog/nikst/filipp-io-vorovstvo-prekrasnaya-strategiya
...Филипп Йо с удовольствием рассказал нам, зачем страна тратит миллиарды долларов на развитие инновационной экономики и почему главным направлением его текущей работы стала широкомасштабная программа по стимулированию притока лучших мозгов. ...
cupraer
12.06.2023 16:23это научные сотрудники молодые с высоким потенциалом
За потенциалом не ходят. Ходят за подтвержденным опытом.
victor_1212
12.06.2023 16:23именно, просто минимизация рисков, но в us особенно ни за кем не ходят, а если и ходят, то недолго, рынок большой, так навскидку 40% инженеров us занимаются sw, кандидатов из других стран тоже достаточно
cupraer
12.06.2023 16:23За мной постоянно ходят именно из us, был бы согласен переехать в помойку — озолотился бы.
victor_1212
12.06.2023 16:23возможно уникальный опыт, просто интересно, может намекнете типа чем занимаетесь, свой уровень, и какую примерно помойку Вам предлагают?
если конечно Вы имеете в виду компании, а не headhunters, что в общем не слишком серьезно
ps
коротко посмотрел Ваши статьи, но таки ничего не заметил, что могло бы вызвать повышенный интерес и прочие перспективы, QA конечно востребован, но там озолотиться вряд ли получится
cupraer
12.06.2023 16:23+1чем занимаетесь, свой уровень
Высокая нагрузка, распределенные вычисления, масштабируемость без потери консенсуса.
имеете в виду компании, а не headhunters
Я имею в виде компании, но headhunters — это более, чем серьезно (не нужно путать с эйчарами).
какую примерно помойку
Дык в основном Долину, конечно, но есть и Бостон, НЙ, Финикс. Не существует зарплаты, ради которой я бы согласился жить в США.
DMGarikk
12.06.2023 16:23Дык в основном Долину, конечно, но есть и Бостон, НЙ, Финикс.
а можно поподробнее как это выглядит? к вам случится представитель компании из США и предлагает релокацию в штаты прям в лоб? а как они вас находят? линкедин? какойто доступный профиль?
точечное приглашение с оффером и релоком в США это довольно эксклюзивная история (хотябы по бюрократически-миграционным причинам)
офферы из штатовских компаний но с офисом в ЕС — такое бывает, да. но про США прям интересноcupraer
12.06.2023 16:23предлагает релокацию в штаты прям в лоб?
Предлагает работу, я говорю, что я не в США и не поеду, прощаемся. Я снес линкедин лет пять назад, спам один же.
DMGarikk
12.06.2023 16:23+4Предлагает работу, я говорю, что я не в США и не поеду, прощаемся.
ой ну в самом то деле
у меня почта завалена такими предложениями работы, индусы из штатовских хантерских контор постоянно забывают дописать GC/Work permit required и никогда не смотрят на слово I have NOT GС/Work permit в резюме
я пару раз даже собеседование проходил, напрямую говоря что у меня нет разрешения и мне нужна релокация...ok ok… а потом глаза квадратные что ой… оказывается вы не в штатах? (удивильно да, я 5 раз и в резюме и текстом вам это написал, и сейчас словами говорю)а предложение по работе они рассылают ковровыми бомбардировками, также как и наши Россиянские HR-ы
так что не льстите себе, никто за вами из штатов не бегает, и не зовет тудаа чтобы вас перестали туда звать уточните откуда они ваши данные берут, я в их списки рассылки попал когда в начале 10х пытался на h1b подаваться
cupraer
12.06.2023 16:23не льстите себе
Хорошо, хорошо, не буду, не волнуйтесь так только. Вы несомненно правы, а я все выдумываю.
victor_1212
12.06.2023 16:23> а я все выдумываю ..
все бывает, однако утверждения типа "headhunters — это более, чем серьезно (не нужно путать с эйчарами)" вызывают сомнения, про "помойку" тоже непонятно к чему,
надеюсь Вы понимаете что "headhunters" кормятся с проданной головы, поэтому хотят иметь как можно больше резюме, причем комиссионные у них приличные, поэтому многие компание лучше сотрудникам платят за рекомендации друзей, вместо того чтобы бездельников кормить, с теми "headhunters" что email spam рассылают вообще связываться не стоит, без разницы что обещают, с другой стороны HR это типа отдел кадров компании, говорят и делают что им велено, через них проходят все бумаги при приеме, и дальше они хранят Ваш файл
> я в их списки рассылки попал когда в начале 10х пытался на h1b подаваться ...
большинство "headhunters" подторговывает информацией, часть вероятно прямо из индии
DMGarikk
12.06.2023 16:23ну ладно ладно ;)
вы просто описали ситуацию как у меня, но я попытался пройти дальше, а не пафосно отказываться от помойки на первом же письмерелок в штаты это сложная и затратная операция, и если на вас целенаправленно выходит HR компании (а не агент или хедхантер) то он это делает по прямой рекомендации и с пониманием что вы не переедете в штаты в течении года точно и вообще не факт что переедете туда если вам обычную визу делать)… но вас надо устроить на работу уже сейчас… причем НЕ в США, по этому целевой хантинг это редкость
, но вы описываете это так что за вами прямо бегают… хотя вы можете(скорее всего должны) переехать в другую страну (не штаты) при самом лучшем стечении обстоятельств… но вы упор сделали в отказе именно от локации — США, в чем нет никакого смысла… вы туда всеравно не попадаете прям сразу (а компания если прям вас так хочет может и оставить вас в Германии или Португалии или Ирландии)… что опятьже подсказывает что вы просто считаете приглашения агентов как настоящие офферы оттуда
cupraer
12.06.2023 16:23Я гражданин ЕС.
вы упор сделали в отказе именно от локации — США, в чем нет никакого смысла
Обалдеть, конечно, вы мастер определения смысла. Причин не хотеть переезжать в США может быть триллион.
Моя супруга, например, так просто на бигкорп в NY работает, ей труднее следующие грейды получать из-за того, что она тут, но, простите, жить в США ради бо́льшей зарплаты — это нужно быть каким-то совершенным Плюшкиным.
Вы еще Китай бы предложили (оттуда тоже предложения есть, если что).
DMGarikk
12.06.2023 16:23Обалдеть, конечно, вы мастер определения смысла. Причин не хотеть переезжать в США может быть триллион.
нет, вы не поняли, релокация в США обычно занимает 1 год и подразумевает что у работодателя есть офис за пределами… где сотрудник будет работать на время процессинга и работать явно можно там. а не в штатах, но вы отклоняете предложение только по территориальному признаку
p.s. по поводу гражданства ЕС, там вроде есть какието дополнительные визовые варианты… тут по срокам могу плавать
cupraer
12.06.2023 16:23В большой пятерке я работать точно не желаю, по этическим соображениям, а вне оной офис за границей — роскошь, зачем?
Большинство — стартапы, откуда там европейские офисы?
DMGarikk
12.06.2023 16:23ну я работал в штатовском стартапе-единороге, у него были офисы в Польше, Португалии и в США
почему нет?p.s. я там через галеру работал из РФ-Грузии, но в штате компании коллеги были со всего мира и все в разных офисах были
cupraer
12.06.2023 16:23Зависит от мейнстримовости языков и задач, наверное. В области моей экспертизы не набрать разработчиков по всему миру по щелчку пальцев.
0xd34df00d
12.06.2023 16:23жить в США ради бо́льшей зарплаты — это нужно быть каким-то совершенным Плюшкиным.
Ради большей зарплаты и прочих ништяков.
У всех свои цели и критерии, конечно, но я чутка пожил в ЕС как трамплин для L-1, имею несколько хороших знакомых, живущих в ЕС, и жить там не готов, по факту, ни за какие разумные ништяки.
cupraer
12.06.2023 16:23ЕС разный очень, во-первых. А во-вторых — ну вот для меня США не вариант, а ЕС — вполне (за исключением Германии, Франции и Нидерландов).
0xd34df00d
12.06.2023 16:23Ну так Штаты тоже большие. Есть Флорида-Техас, есть Калифорния-Нью-Йорк, а есть вообще какой-нибудь никому не нужный Нью-Хемпшир.
selkwind
12.06.2023 16:23+1(за исключением Германии, Франции и Нидерландов
Странный выбор :) Если из ЕС выкинуть его экономическую флагманскую группу, то что останется? PIGS, прости господи?
cupraer
12.06.2023 16:23Я не фабрика Siemens, я выбираю места, пригодные для жизни, — не по принадлежности экономической флагмановости.
Впрочем, если вам уж так интересно, что останется вне PIGS — в Европе есть еще Скандинавия. Я бы туда тоже жить не поехал, но уж всяко лучше, чем в Берлине.
sim31r
12.06.2023 16:23За сотрудником предпенсионного возраста скорее всего герой статьи не пойдет, там речь о молодых, перспективных, мобильных, недооцененных.
crystallize
12.06.2023 16:23ЖЗЛ про всяких Джобсов и Ньювеллов обычно полно такими "гениальными решениями".
micronull
12.06.2023 16:23+2Заметил что чем больше решаю бизнес и архитектурные задачи, тем больше забываю про низкоуровневые тонкости (не базу, а именно тонкости). За спиной больше десяти лет разработки...
D1abloRUS
12.06.2023 16:23+3Почему все эти статьи ни кто не начинает от проблемы, зачем вам вообще понадобился новый сотрудник и какие задачи он будет решать, откуда эти задачи появились и что с текущими сотрудниками. Исходя из задач, которые он будет решать, строить интервью, все эти статьи больше напоминают найм в какие то галеры, где каждый день новый вызов.
turbotankist
12.06.2023 16:23+1За свою карьеру всегда был узкоспециализированным инженером, сперва сетевиком, сисадмином, а потом в девопс ушёл, так как платят лучше)
Есть (точнее уже протухли) сертификаты CCNP, RHCSA, CKA. Проходил много собеседований за всё время.
Так вот - на девопс сложнее всего и проще всего одновременно. Очень широкий спектр возможных вопросов и подготовиться невозможно, ты или знаешь эту область или нет. У меня есть сферы, которые я не знаю и НЕ ХОЧУ туда лезть, потому что не интересно и не моё. Это всякие базы данных например. Не, Я конечно могу поднять любой сервер, но с документацией. Я всегда говорю чтобы кто-то другой этим занимался. И всегда был кто-то другой, а я там в сетях поковыряюсь. Потому что невозможно глубоко знать всё! Я когда был начинающим сетевиком и только CCNA получил - я поражался насколько опытные сисадмины плохо сети понимают, если чуть-чуть отойти от айпишников и масок, а программисты вообще не понимают.
Так вот - если мне задают вопросы на которые я знаю ответы, то легко прохожу, а если не повезёт, то не прохожу)
По мне, идеально было бы если перед собеседованием мне написали - вот такая тема и такая, может быть такой инструмент - или вспомни, или ознакомься, вот на собеседовании и узнаем на сколько человек может быстро и хорошо освоить что-то, ведь суть айти постоянно что-то новое узнавать?)
M_AJ
12.06.2023 16:23-1Очень широкий спектр возможных вопросов и подготовиться невозможно, ты или знаешь эту область или нет.
Это в принципе типично для IT, у каждой компании свой стек и задачи, и некоторые из них начинают почему-то считать, что именно их специфика это и есть "база", которую должны знать все, и пишут потом статьи про то, что вокруг одни тупицы, которые не знают основ. Хотя я не вижу больших проблем просто составить тесты по тем темам которые нужны именно вам и рассылать кандидатам для отсева неподходящих.
init3
12.06.2023 16:23Мне тоже нравится идея тестов. Возможно от работодателя или независимых third party.
Проблема в том, что большинство требований в вакансиях выглядит примерно одинаково (к примеру Linux, Python, сети). Описание вакансии в случайную компанию XYZ могут совпадать с описанием на аналогичную должность в FAANG.
Если формально указано, что нужно знать сети. Это в каком объеме? Ping, traceroute, dig или глубже?
Если есть CCNA сертификат, то вопросы по сетям можно пропустить?
В теории, неплохо было бы если компания собрала группу соискателей в одной аудитории. Прочитала им курс лекций в объеме который им необходим. А на следующий день устроила экзамен и взяла на работу тех , кто лучше справился. Но это так, мои мысли в слух.
M_AJ
12.06.2023 16:23Если формально указано, что нужно знать сети. Это в каком объеме?
Мне кажется именно тесты как раз хорошо подходят для решения этой проблемы. Если компании нужно чтобы человек знал только самые основы сетей, то и вопросы по сетям там могут быть самые простые. Кроме того, компания легко может сама решить какие вопросы для нее принципиальны, а какие нет, присвоив вопросам соответствующие веса. Для меня, как потенциального соискателя, это тоже был бы только плюс — не нужно ехать на собеседование и тратить кучу времени, чтобы понять, что конкретно скрывается за общими формулировка и вакансии и подхожу ли им я.
bestann
12.06.2023 16:23+2Озвучьте, пожалуйста, оклад. На какую зарплату вы искали кандидатов? А то об этом вы скромно умалчиваете, зато требований как на доктора наук.
И зачем вам сотрудники, если вы сами всё знаете и можете настроить так, чтобы никого не нанимать. Или всё же нет?
Sunrise357
12.06.2023 16:23-1По моему опыту, в регионах таких кандидатов ищут где-то на 35000-45000 рублей.
plotnikoff
12.06.2023 16:23-3Искал тимлида на 450к в спб. Когда в нск мидлов искал на 45к, кандидаты шли более грамотные.
domix32
12.06.2023 16:23+4Многих интересуют только зарплаты, без реального увлечения технологиями.
Удивительно, насколько это для вас неочевидно. Не настолько много айтишников поднялось по пирамиде Маслоу, чтобы иметь возможность увлекаться технологиями.
Не слишком ли широкий спектр обязанностей падает на каждого инженера в нашей команде, может быть нужно делиться по профилям?
По описанию - малёх многовато для одного. Если он и сетевик и DBA и ещё и ямлы куберам изобретать - всё и сразу будет стоить либо довольно дорого. либо всё это будет неглубоко, т.к. многие предпочитают всё же углублять знания, а не расширять. Правда я с программисткой колокольни говорю.
cupraer
12.06.2023 16:23+1Как раз с программистской точки зрения, пару раз углубил — и вот оно само и расширилось.
Достаточно углубиться в пару-тройку языков с разными парадигмами (хороший набор: джава, раст, хаскель) — и вот уже вы способны создавать хороший код на питоне, тайпскрипте, шарпе, и куче других языков).
domix32
12.06.2023 16:23Програмист и девопс это все же про маленько разные вещи. И чем ближе к ОС, тем больший не связанного с непосредственно программированием всплывает. Кому cargo build, а кому приходится нюансы шеллов на зоопарке операционок учитывать, всякие стандартные либы нестандартные подсовывать. Тут nix pkg, там bsd приключился, тут ядро без приключений собрано, тут сесурити аудит выглядывает из-за угла и ручкой манит, тут пеп не сошёлся, там абстракции протекли, тут контейнер в море упал и чуть не потопил шард с кубером. И на каждом таком маленьком этапе просто миллион нюансов, которые соло разгребать не сказать чтобы достаточно разумное решение, хотя может и достаточно дешёвое для кампании, если просадок по выполнению тасков не случается.
Femistoklov
12.06.2023 16:23+1Не настолько много айтишников поднялось по пирамиде Маслоу
Упал с пирамиды Маслоу :(
lainbh
12.06.2023 16:23+3А Вы не учитываете, что может Ваш HR слишком сильно ищут такие "супер-пупер" резюме, в которых описаны крутые соискатели. А в действительности есть люди, которые во многом разбираются, но не пишут таких резюме. Конечно можно сказать, что сами соискатели виноваты, что не могут написать резюме, но часто же именно HR отклоняют вполне нормальные резюме, разыскивая чуть ли работников-богов.
robopipiska
12.06.2023 16:23-3Удивительно! Вчера был диалог примерно на эту тему с коллегой: узкий специалист имеет высшую степень квалификации в профессиональной деятельности, но самообразовываться в смежных технологиях неспособен зачастую в силу привычек, вытекающих из особенностей нашего образования. Сущность ЕГЭ - отнюдь не понимание; именно начальная школа закладывает основы того, что любопытство - лишнее, желание экспериментировать - лишнее, учиться на собственных ошибках - вообще глупость, - задача школьника отработать рефлексию для сдачи ЕГЭ. Всё это формирует клиповое, фрагментарное мышление и как самую большую проблему - непонимание причинно-следственных связей в своей профессиональной области - вот и происходит замыкание на узкой специализации, так привычней, стало быть проще. С автором статьи согласен, вопросы верные и в то же время не все однозначно, особенно согласен и с точкой зрения автора комментария с ником "aanovik42". Однозначно, что постоянно нужен диалог, формулировка вопросов, поиск компромиссов.
AntoineLarine
12.06.2023 16:23+1ЕГЭ-то тут при чём? Чем оно отличается от пяти выпускных и трёх вступительных экзаменов, которые многие сдавали, например в конце 90-х? Формат чуть другой, и явно честнее стало.
А в исходном вопросе у топикстартера очевидно высокие требования к кандидатам (судит по себе, имеет полное право). Только отчего-то жалуется, что всего лишь 10% подходят под такие требования. Очередной плач Ярославны "ИТ-шники уже не те".
robopipiska
12.06.2023 16:23"ЕГЭ-то тут при чём?" - я уже взыскал точку зрения о том, что навык не системного мышления формируется в начальной школе. ЕГЭ - цель, закрепляющий этот навык. Дальше - фрагментарное мышление как способ взаимодействия с информационными потоками, в результате - узкая специализация. Про "плач Ярославны": верно, но эти грабли обоюдные, у одних требования как к докторам наук во всех отраслях и дисциплинах, у других навык к фрагментарному мышлению. Проблема тупиковая при её замалчивании. Про "другой формат" экзаменов: ТОТ способ экзаменации и ЕГЭ - это принципиально разные инструменты, определяющие степень компентенций. "...И явно честнее стало" - ваш идеализированное представление об этом выходит за границы солнечной системы.
AntoineLarine
12.06.2023 16:23+3ЕГЭ - это формат проведения выпускных экзаменов. Формальный контроль знаний, коими были раньше обычные выпускные и вступительные экзамены.
А школьные программы никогда не были ориентированы на "системное мышление" (да и насчёт многих ВУЗов я бы не обольщался). Я сам неплохо помню свои учебники (хотя уже столько лет прошло). Никакого специального обучения системному мышлению там и в помине не было. Очень модно сейчас говорить за это самое СМ, но по факту получается, что есть дети, у которых что-то включается в голове, и они начинают учиться лучше остальных, самостоятельно осваивать программу и что-то сверх неё, интересоваться смежными вопросами и т. п. А у остальных этот тумблер не щёлкает, интерес к познанию как к таковому у них не просыпается, и они тупо заучивают материал, чтобы сдать экзамен и забыть всё в тот же день.
sim31r
12.06.2023 16:23+1задача школьника отработать рефлексию для сдачи ЕГЭ
Это если цель 30-50 балов набрать не вникая в предмет, потратив 10-20 часов на обучение, остальное на развлечения. А если цель 100 балов, там нужны знания за пределами школьной программы, лучше по смежным предметам и ясное понимание сути предмета. На Ютубе есть ролики с разбором самых сложных задач, там достаточно интересный подход. У нас в школе до ЕГЭ всё проще было, сравнимая сложность была только на олимпиадах.
event1
12.06.2023 16:23+2Ещё скажите, мама виновата. Я провожу собеседования в Дублине, где ЕГЭ сдают c 1924-го года. В следующем году юбилей. Если следовать этой логике, кандидаты должны быть не просто с отбитым любопытством, но с наследственно отбитым любопытством. Однако же, нет, приходят замечательные молодые люди заинтересованные в технологиях и жадные до знаний. Не очень часто, но приходят.
Lev3250
12.06.2023 16:23Когда прочитал статью, так и хотелось воскликнуть: "СПАСИБО!" Как в этой гифке:
Сериал Офис
Я, пока что, мало знаю про DevOps (настоящий, а не маркетинговый), но тот бред, что я вижу в обучалках в интернете сводится к тому, что надо уметь раскатывать тыщи инстансов где-то в AWS, а что там под капотом, всем насрать.
Как системного администратора меня это просто бесит! Ведь Ops должен понять, почему что-то отвалилось, если он выставил не тот флаг, а не раскатывать всё заново с нуля по мануалу, как это делал бы я. Ведь нафиг такой devops тогда нужен! Потому что именно devops должен тонко настраивать окружение, чтобы потом не прилетали счета на много-много долларов. Таких случаев полно
По роду работы часто приходится выполнять задачи, связанные с менеджментом проектов. И когда ты аутсорсеру пытаешься на пальцах объяснить что-то элементарное (те же tcp сессии, или хотя бы доступ к субд (а он мне отвечает про доступ к конкретной базе), то хочется прям через трубку вылезти дать в лоб!
denis-isaev
12.06.2023 16:23Так девопсер же и не должен заменять сисадмина. По крайней мере в больших компаниях это разные специальности. Поэтому и знания у них могут не сильно пересекаться.
Lev3250
12.06.2023 16:23+1Он не должен заменять, но понимать о чём речь, имхо, должен.
Это как нейрохирург, который впадает в ступор, когда его спрашивают, что такое группы крови. Это как бы вообще не его специальность и он не обязан в этом разбираться, но если он вообще не знает, что это такое, то возникает много вопросов
BeLord
12.06.2023 16:23+4Автору,
Шаг 1. Проведите самотестирование своей команды в режиме мы можем без Гугла и прочих помощников сделать вот это. Получаете "чистые" знания.
Шаг 2. Оцениваете, что в вашей компании "чистые" знания стоят столько-то.
Шаг 3. Формируете прайс для спеца, которого ищете. В формате базовый список требований - зп, доп. требования +(сумма) к зп.
Шаг 4. Осознаете, что в мире капитализма базовый фильтр - деньги, если спец по вашему прайсу стоит 300к, а он готов работать за 100к, у меня для вас плохие новости.
Шаг 5. Осознайте, что идейность за деньги не покупается, если вам нужен спец идейный, то это деньги+ реализация потребностей этого спеца, а это уже штучный товар.
Krouler7
12.06.2023 16:23+1Шаг 4. Осознаете, что в мире капитализма базовый фильтр - деньги, если спец по вашему прайсу стоит 300к, а он готов работать за 100к, у меня для вас плохие новости.
Распишите пожалуйста по подробнее.
Может я чего-то не понимаю, но мне казалось что если внутри компании прайс специалиста должного уровня 300к, а новый член команды того же уровня согласен на 100к, то это означает легкое пополнение штата. Подскажите - что здесь плохого?
aceofspades88
12.06.2023 16:23+2Вы позицию якобы закрыли, но есть нюанс) Тут либо он лапшички вам навешал и вы не смогли определить его актуальный уровень верно, либо он через полгодика проспится и убежит таки работать за 300
ALexhha
12.06.2023 16:23Шаг 1. Проведите самотестирование своей команды в режиме мы можем без
Гугла и прочих помощников сделать вот это. Получаете "чистые" знания.даже на CKA экзамене можно пользоваться офф документацией ))) Иначе это была бы шиза - запомни 100500 манифестов и все их параметры (удачи)
selkwind
12.06.2023 16:23+2Иначе это была бы шиза - запомни 100500 манифестов и все их параметры (удачи)
В этом месте врачи всего мира смотрят на Вас с улыбкой )
D1abloRUS
12.06.2023 16:23Проблема в том, что они бесконечно меняются, в отличии от костей, мышц и тд
morijndael
12.06.2023 16:23Кости и мышцы может и не [так быстро] меняются, а вот методы диагностирования и лечения — очень даже
ALexhha
12.06.2023 16:23+3В этом месте врачи всего мира смотрят на Вас с улыбкой )
Речь шла об IT в целом и о devops в частности, поэтому странно приводить в пример врачей, предлагаю пойти еще дальше и сравнить с космонавтами )))
opv88
12.06.2023 16:23+2Это извечный вопрос по полноте знаний кандидатов на вакансию. Кто-то бьёт себя в грудь и яростно заявляет, что инженер должен знать все! Кто-то говорит, что если кандидат способен решать поставленные задачи за обозначенную сумму, то кошмарить его другими вопросами - идиотизм. И эти два лагеря никогда не придут к единому мнению. В первом случае бизнес не понимает, почему вакансия не закрывается месяцами, а то и годами, а во-втором присутствует негодование по проводу качества результатов работы.
Farongy
12.06.2023 16:23+3кандидат способен решать поставленные задачи
негодование по проводу качества результатов работы
Как то нелогично)
AntoineLarine
12.06.2023 16:23Хотелось бы увидеть описание вакансии, в том виде как оно было опубликовано.
flintdemon
12.06.2023 16:23+2Вот смотрите, я уже лет пять не работал с памятью в Линуксе, за пять лет много чего случилось, и простите, я забыл все эти фундаментальные вещи. Они у меня вытеснились другими знаниями. Но если мне понадобится я найду и освежу их очень быстро. Если ваш мозг устроен так, что вы в состоянии держать в голове информацию, с которой не работаете, мне лично остается только позавидовать.
Krouler7
12.06.2023 16:23+1Завидовать на самом деле мало чему тут. Человек выносит из той или иной сферы именно знания - некий алгоритм: как, куда и для чего. А вот какие то данные, например - термины, наименования и прочее забываются очень легко. Знания используются человеком в разных сферах из-за знакомой схожести в некоторых аспектах сферы деятельности, оттого и запоминаются надолго.
Сами данные - значения со слишком узкой областью применения, которые очень сложно как то сопоставить из сферы к сфере. Держать их в голове означает быть не готовым к получению новых знаний, поскольку не будет места для новых данных. Это сильно урезает способность к адаптации.
sergey_privacy
12.06.2023 16:23+3Все очень относительно. С одной стороны, 99% выполняемых ежедневно задач DevOps-а не требуют глубинных знаний по IP-адресации. Ему дали вводные, инженер вбил инфу в конфиг и все заработало. Реально он может 20 лет отработать без знания как порезать сетку /8 или /16 на подсети /29 и другие, как работает протоколы OSPF/BGP, чем отличаются POST от GET. С другой стороны, DevOps - это не про деплой, методологию, а про постоянное расширение своих знаний вглубь вширь, про ежедневную учебу.
Совет автору: вам нужно выполнять стандартные DevOps-задачи? Тогда нанимайте людей, которые показали хорошие знания и навыки в вашем DevOps-стеке. И раз в квартал проводите переаттестацию. Планируйте ему трек развития знаний, требуйте (финансовая мотивация) от него непрерывного роста НУЖНЫХ ВАМ дополнительных знаний из базы. Если сразу определитесь, что вам нужны не гении (а готовы им соответственно платить???), а просто качественные работники, то количество собеседований сократится в разы или на порядок. Я сам провел сотни собеседований, сам прошел десятки собеседований и понял одно: нужен усредненный набор знаний и опыта, все что недоучил - доучит в ходе работы. Сделайте сетку из 20-30 навыков от минимального джуна до эксперта/сеньора и разбейте зарплату на маленькие части. По результатам переаттестации и повышайте зарплату на нужное количество ступенек. Не показывает движения 2-3 раза - значит человек не растет, повышать не за что. Если за один квартал/полугодие закрыл несколько пробелов знаний, то повышайте соответственно на эту же сумму. Все должно быть прозрачно и каждый должен понимать, сколько, за что и когда он будет получать в з.п.
sky-walker
12.06.2023 16:23+1Эти же соискатели не согласны с тем, что DevOps инженер это: основы операционных систем, основы баз данных, основы сетей, основы распределенных систем, любые другие основы, не связанные с верхнеуровневым инструментарием и перекладыванием конфигов, для получения очередной абстракции.
DevOps инженер - это сильно размытое понятие с разными требованиями в разных компаниях. Так что они по-своему правы. Во всяком случае, повода для удивления абсолютно нет. Не каждый хочет быть Шивой многоруким, для работника как раз удобнее иметь четко формализованный и ограниченный список умений/обязанностей.
p.s. отдельный вопрос, что на практике частенько на DevOps скидывают всю "мусорную" работу, которой не хочется заниматься программистам. Это тоже, кстати, можно считать нормой, если 1) человека при найме честно предупреждают что в компании процесс построен именно так 2) он за работу будет получать хорошие деньги.
mixsture
12.06.2023 16:23+5Я думаю, что проблема скорее в финансовом плане. ИТ развивается во все стороны — в нем столько знаний, что нужны существенные затраты времени каждый день на поддержание большого кругозора.
Вопрос: работодатели, а сколько вас готовых оплачивать 8ч рабочего времени, из которого 4 будет потрачено на вашу непосредственно работу, а 4 — работник будет тратить на свое самообучение? Думаю, что это исчезающе малая величина.
По сути каждый из вас ждет, что либо предыдущий работодатель вложится дополнительно в обучение, либо сотрудник будет работать после работы на то же самое. А заниматься этой благотворительностью желающих особо нет. Поэтому большой кругозор сужается до необходимого прямо в текущий момент, а остальное можно довыяснить по мануалам.
event1
12.06.2023 16:23+2Просто у вас команда мастеров на все руки. У меня такая же, но программистов. В такой приятно работать, но трудно пополнять. А масштабировать вообще не возможно. Большая часть бизнесов устроена не так. Там в команде есть один ведущий, который умеет всякое и сколько-то обычных скучных людей (такие знаете, у которых есть хобби, семья и вообще жизнь помимо работы). Ведущий специалист нарезает задачи для остальных и решает самые сложные проблемы. Соответственно, кандидаты, которые вам встречаются как раз нацелены на такие команды.
victor_1212
12.06.2023 16:23> Там в команде есть один ведущий, который ...
довольно правильное описание типа средней команды в компании без особых претензий, как говорится "каждому свое"
Keirichs
12.06.2023 16:23+1Вам наверное нужны девопсы с фундаментом? я честно говоря уже года 3 не видел вывода команды top, потому что образы мне поставляет специальный отдел УСИ и не даёт прав на кастомизацию.
Сети - это максимум нынче маску уазать, IP и сделать заявку опять в отдельный отдел на изменение сетевых сегментов.
Get и Post - нужно знать, что есть постман и какой-нибудь soap ui что есть два метода, которые по разному отправляют данные(P.S. Сам хочу в рест вкатиться через самописные приложения на котлин)Так вот встречный вопрос, а нужны ли нынешним девопс инженерам эти основы?
Сейчас крупные компании и правда нанимают людей ради хельма\ансибла и ямлики бесконечные, причём проще накинуть подов лишний раз, чем кастомизировать джаву неделю и выиграть пару мегайбайт.Я вот считаю, что не везде это надо, в хайлоад системе - надо, в малобюджетированном проекте не понятно, в стандартно текущем проекте с хорошим запасом бюджета и нагруженностью в 20% всей арендованной системы, думаю нет.
SergeyZerg
12.06.2023 16:23+2У меня как программиста часто бывает необходимость решить что-то, что уже решал, но не могу вспомнить подробностей как это было. В таких случаях обычно смотрю свой старый код/проект или иду в гугл. И обычно достаточно беглого взгляда на свое старое решение или мануал/туториал, чтобы все вспомнить и понять, что нужно делать.
Если на собесе спросят что-то подобное, то не уверен, что смогу нормально ответить.
logon42
12.06.2023 16:23Люди хотят мышкой клацать в гуй, получать зарплату и жить в свое удовольствие, а не погружаться все глубже в профессию. Не один холивар уже был на тему образования, знания алгоритмов, структур данных и прочей базы для тех же программистов. Есть куча людей уверенных, что нужно миллион узкоспециализированных "специалистов" без фундаментальных знаний и навыков. В конечном счете, призывать коллег к совести бесполезно, все решает рынок труда. Когда-нибудь дефицит кадров закончится и всех пассажиров высадят с этого автобуса.
nikhotmsk
12.06.2023 16:23+1Я думаю, что в основном понятно, о каких специалистах я говорю.
Каждый из этих акронимов приходится гуглить и долго вникать. По моему, это излишний новояз.
Если бы люди договорились о значении слов, не было бы большинства сегодняшних проблем.
Конечно, нужно знать основы. Или хотя бы разбираться в абстракциях как минимум на три уровня ниже. Иначе будет происходить кумулятивное накопление ошибок. За ошибки так или иначе придется заплатить. (цитата из одного журнала, будет здорово, если вы его тоже читаете)
Wesha
12.06.2023 16:23+2Если бы люди договорились о значении слов, не было бы большинства сегодняшних проблем.
Смею отметить, что относится к абсолютно любой области человеческой деятельности.
m1ndKiller
12.06.2023 16:23Нежелание погружаться было всегда и никуда оно не денется, но меня немного напряг наезд про то что CI/CD это какие-то там инструменты.
Не в том плане что не нужно разбираться какую задачу они решают и как, сколько о том сколько этих инструментов существуют и насколько по разному решают проблемы.
Я сам не DevOps, а фронт, но за свои 10 лет работы фронтом я очень много раз занимался DevOps делами, потому что DevOps-ов всегда меньше чем нужно или вовсе нет.
И каждый раз приходя на новую работу я вижу новую балалайку. То там TeamCity со своим Kotlin, то Jenkins со своим Groovey, то Gitlab CI с Shell, то Bamboo. И ладно бы просто разные платформы, но одна суть, но нет. Каждый раз ты приходишь на проект и видишь очередное решение той же задачи только новым способом.
И в этом плане я больше буду рад если DevOps внедрит готовый, понятный инструмент, использует готовый подход и решение, даже если оно чуть-чуть менее эффективно.
Зато поддержка этого будет простой, я как фронт легко туда залезу и все подправлю, и не буду вынужден знать всех тонкостей этого DevOps мира
Потому что сегодня вы все настроили, оно собирается, а завтра оно взорвалось и копать это будет либо другой DevOps, а скорее всего кто-то из разрабов и там все должно быть тупо и легко гуглиться.
Worky
12.06.2023 16:23Чот не пойму: то сначала разрабы отдали разворот и настройку админам и это назвали девупс. А теперь верните все назад и сделайте просто, чтобы разрабы сами все делали.
m1ndKiller
12.06.2023 16:23Ну DevOps как инженеры решают задачу, но к сожалению, специалистов не достаточно для того чтобы эти решения еще и поддерживать круглосуточно.
Поэтому основу закладываются DevOps-ы, а поддерживают все это безобразие когда-то они же, а когда-то и разрабы
IliaBuk
12.06.2023 16:23Респект за статью. Наконец то кто-то начинает прозревать как РЕАЛЬНО дела обстоят с айти. Это к сожалению то, к чему мы пришли за 10-20 лет. Не уверен есть это хорошо или плохо, так же не уверен что будет через даже пару лет. Будет ли айти вообще существовать.
Но в статье абсолютно правильно захайлайчены проблемы: сам HR, сам хайринг и отсутствие компетенции у хедов и хайринг менеджеров (не обязательно из-за отсутствия компетенции а просто иногда закрывают глаза на бред из-за проплаченного капитала) привело естественным образом к тому, что единственная успешная бизнес модель соискателя выглядит примерно так: 1. Выучил теорию, типа курса или книжки по какому-то узкому стэку, 2. Произвёл впечатление на интервью, ведь конечно после книжки ты знаешь очень много специфических мелочей. 3. Получил оффер и через несколько месяцев джоб хопнул. 4. Технология сама за это время или умерла или изменилась до неузнаваемости, что на эти прошлые знания в принципе похрен. Да на них было сразу похрен после прохождения интервью и получения оффера.
В итоге что мы имеем: частое выгорание (из-за изучения ненужных краткосрочных знаний вместо фундаментальных) и растущие в небеса зарплаты и требования работодателей из-за джоб хоппинга постоянного.
Смотрите AWS сейчас делает то же самое предоставляя их множество "managed" решений, типа баз данных, лоад балансера. При этом по сути разница в себестоимости раза в два (если бы я сам их ставил не managed на своём vps). Это игра с дьяволом, в один конец: в итоге когда все научатся кликать этот AWS (что само по себе не очень легко если честно выкурить его все сеттинги и 100500 сервисов) и разучатся строить системы - амазон поднимет цены раза в 3. А на вопрос бизнеса о том, что "как же так, нам нужно дешевле " - они ответят "не проблема, мы просто напечатаем вам больше денег".
В общем к сожалению мы пришли к тому к чему пришли. Я вообще не верю что айти будет существовать через несколько лет. Сейчас это уже пузырь. Фейк на фейке, скам на скаме. Он будет существовать ровно столько сколько подписывается этими скамерами
что реакт это скам, что докер, если присмотреться, да, оно решает большую часть проблем, в основном с унификацией и reusability, но оно так же подсаживает очень сильно как наркотик. И это приводит к повышенному детерминизму, сложности систем, отсутствию креатива, долгому онбордингу. В итоге просто рано или поздно всех стошнит. Даже в последних c++ версиях начали бадяжить с высокоуровневыми async/await. Спрашивается нахрена? Просто увеличили онбординг и всё. Под капотом там всё равно тот же ассемблер как и было сто лет назад.
Ps. Я инженер разработчик 15 лет. 35 лет. Да, я ОЧЕНЬ старый для айти, закидайте меня помидорами.
anonymous
12.06.2023 16:23НЛО прилетело и опубликовало эту надпись здесь
Wesha
12.06.2023 16:23на сайты-булочные ездим поездами
Потому что какой же это сайт без свистоперделок?
Вот прямо сейчас лично ковыряюсь. У некой компании есть некий вебсайт для партнёров — туда отдаёшь некий ID, получаешь по нему некие данные. Мы написали скрейпер (не надо мне тут: цель этого скрейпера — не "просканировать все-все данные по 100 раз на дню", а облегить работу нашему мужику, который раз в месяц на этот сайт заходил, вводил ID, получал данные и вбивал их в эксель). Раньше у компании была элементарная страничка на условном ASP, которая из их базы данных по ID получала данные и возвращала из в виде статической HTML-странички. Не так давно "Микрософт" продал им какой-то фреймворк, и теперь эта же страничка обязательно требует браузер с поддержкой жабаскрипта, его обнюхивает, а потом (тадам!) возвращает ровно те же данные, что и до этого. То есть глубокий сермяжный смысл этого фреймворка совершенно непонятен — с точки зрения юзера, ничего не поменялось!
nightlord189
12.06.2023 16:23+2повышенному детерминизму, ..., отсутствию креатива
Эх, понапридумывали свои докеры. Не то что раньше - написал сервис, локально все прекрасно, а потом на сервер ручками/скриптами заливаешь и три дня проблемы решаешь - то зависимость не качается, то не собирается, то нужна Либа v1.07, а на сервере уже стоит Либа v1.03 и они конфликтуют. Красота-то какая была)
А сейчас что - docker build, docker push, docker pull, docker run и никакого креатива и приключений, грустно как-то даже...mayorovp
12.06.2023 16:23Ага, вот буквально сегодня никаких приключений не было.
На сервере запущено 50 контейнеров, но при этом docker ps пуст, и остановить контейнеры нельзя — при попытке остановки docker жалуется что у него не хватает прав. Запустить новые тоже нельзя — порты заняты.
Прошлый раз такое было потому что на сервере оказалось два докера (поверх докера из apt неизвестный поставил докер из snap), в этот раз разгадать загадку так и не получилось.
nightlord189
12.06.2023 16:23+2И сколько раз, допустим, в месяц у вас подобные приключения с докером случаются?
У меня - даже сложно вспомнить, но не чаще 1-2 раза в год. И в любом случае лучше я буду решать проблемы с одним докером, чем ловить проблемы с каждым вариантом комбинации ЯП, фреймворка, версий либ и системы, как было до докера.
ALexhha
12.06.2023 16:23+2А что, докер магическим образом решит проблему конфликта библиотек (конечно нет) ?
А если в Dockerfile стоит что то вроде
RUN apt-get update && apt-get install ...то рано или поздно будет ситуация - а у меня локально работает/не работает, но виноват при этом докер ))
IliaBuk
12.06.2023 16:23Эх, понапридумывали свои докеры. Не то что раньше - написал сервис, локально все прекрасно, а потом на сервер ручками/скриптами заливаешь и три дня проблемы решаешь - то зависимость не качается, то не собирается, то нужна Либа v1.07, а на сервере уже стоит Либа v1.03 и они конфликтуют. Красота-то какая была)
А сейчас что - docker build, docker push, docker pull, docker run и никакого креатива и приключений, грустно как-то даже...
Да не, я согласен. Я же там выше и писал, что у меня нет сильного мнения на этот счёт. И плюсы тоже захайлатил. Но мне кажется всё же за последние пару лет конкретно перебор. Да и при текущих технологиях инженеры должны оплачиваться раз в 5 больше, чем 10 лет назад, а не в 2 раза меньше. ))))
AntoineLarine
12.06.2023 16:23+1“Наша молодёжь растлена до глубины души, она никогда не будет похожа на молодёжь былых времён. Молодое поколение сегодняшнего дня не сможет сохранить нашу культуру.” Гесиод ~700 лет до н.э.
Столетия идут, а предвещаемый закат всё не наступает
offline268
12.06.2023 16:23-1какой процент дворников действительно является энтузиастом своего дела? а какой среди стоматологов? водителей, сантехников?
Мне показалось автор негодует, что он весь такой интересующийся и у него хобби=работа, а у остальных - нет. Так это правда жизни - реально интересующихся специалистов в любой сфере всегда немного. Это не хорошо и не плохо - это просто факт. Мне даже кажется порой, что процентов 80% людей вообще бы ничего не делали и ничем не интересовались, если б еда и жильё были бесплатными.
Поэтому вопрос скорее надо ставить в иной плоскости - если вам удается набирать достаточное количество людей с текущим подходом к собеседованиям, то всё ок. Если же у вас жесткий недобор, из-за отклоненных соискателей, то либо надо снижать планку, либо предлагать больше (денег/плюшек/интересныхзадач/чеготоеще).
anonymous
12.06.2023 16:23НЛО прилетело и опубликовало эту надпись здесь
IliaBuk
12.06.2023 16:23С другой стороны, как говорится, не было счастья, да несчастье помогло — яркий выход на публичную сцену большой языковой модели делает легитимными разговоры программистов не только на бодрые темы "наш паровоз вперед летит...", пожалуй, уже можно осторожно спрашивать друг друга "а где остановка-то..."
Насчёт остановки, очень всё просто, без внешней дополнительной энетропии на инпут (а они сейчас её остановили поуволняв всех нахрен) эти языковые модели придут почти к максимальному, абсолютному детерминизму и предсказуемости, знаете как фрактал (посмотрите анимацию треугольника серпинского или типа того) - оно рано или поздно задрочится ровно во всех точках согласно аттрактору. А ИИ - это ж блин просто большая многомерная матрица и ничего больше, и момент когда они его задрочат во всех точках уже близок. Так вот, они смогут сами общаться друг с другом, "война ботов". Только потом человек на это со стороны посмотрит и получится как в анекдоте "Это что мы бесплатно говна друг друга наелись" (про двух мужиков которые на спор ели друг друга какахи). Потому что по факту со стороны эти два ИИ друг с другом просто прожигают CPU и никакой пользы вообще человеку не приносят. В общем я про что хочу сказать: мы потому и люди, потому что "жизнь" и "быть человеком" далеко за гранью "как бы быстро закодить и сдать". В том числе программирование как подмножество жизни - это тоже человеческая вещь, она не про кодирование, не про архитектуру, а про креатив, про создание, про мозг человеческий прежде всего, про коммуникацию, про коллаборацию.
eton65
12.06.2023 16:23Идеальная вакансия — вы берете уже первого кандидата на работу. Если это не так, то начните с этого шага.
ivanuzzo
12.06.2023 16:23+1Я однажды собеседовался в компанию, где тим-лид (!) спорил со мной, доказывая, что GET используется не только для получения данных, но и для отправки (его не смущало, что GET в переводе означает "получить" и что так называемая "отправка" - по сути, побочный эффект, к тому же весьма ограниченный максимальным размером url). Я тогда на джуна шел (и не прошел).
Source
12.06.2023 16:23+4Вы о чём-то странном вообще спорили. Основная особенность GET в том, что такие запросы не должны менять состояние сервера. И, как следствие, они идемпотентны из коробки. Во всяком случае, если программисты не нарушили протокол при реализации серверной части.
А насчёт отправки и получения данных неплохо было бы об определениях сначала договориться. Потому что по протоколу абсолютно любой HTTP-запрос - это отправка запроса (данных) и получение ответа (опять таки данных)
Wesha
12.06.2023 16:23+1не должны менять состояние сервера.
Ключевое слово — "не должны".
Но, к сожалению, "я видел такое, во что вы, люди, просто не сможете поверить".
Source
12.06.2023 16:23Я ж уточнил "Во всяком случае, если программисты не нарушили протокол при реализации серверной части."
Кто ж им запретит нарушить с одной стороны. А с другой - если в компании такое практикуется, то на этом собеседование можно и заканчивать)
morijndael
12.06.2023 16:23+3Никто не запрещает использовать GET для отправки данных. Ну, кроме здравого смысла. Но если здравый смысл успешно устранить, то получится VK API — для всех методов можно юзать как GET, так и POST. Точно работает ещё PUT, но это недокументировано. Да, у ВК можно запросить данные POST-ом, и изменить GET-ом)
Собственно, цитата из их документации
Чтобы обратиться к методу API ВКонтакте, нужно выполнить либо
POST-, либоGET-запрос (запрос с каким HTTP-глаголом вы отправите, не имеет значения)Впрочем, API вконтакта это особая атмосфера цирка с конями...
PuerteMuerte
12.06.2023 16:23Никто не запрещает использовать GET для отправки данных. Ну, кроме здравого смысла
Формально и параметры поиска или там заголовки запроса, например, это тоже своего рода данные. Зависит от того, на какую глубину абстракций нырнуть.
vladimircape
12.06.2023 16:23+1Я знаю ответы на половину этих вопросов, но я не devops а ML специалист, просто приходилось иногда все понимать. Поэтому могу сказать мне эти знания пригодились лишь когда заказчик тупо экономил. Все знать даже близко не реально
dprotopopov
12.06.2023 16:23+1Пара профессоров обсуждают как они принимали экзамен у своих студентов.
Первый: я задаю ему вопрос - он отвечает, задаю другой - он отвечает, задаю третий - он опять отвечает. Ну я вкатил ему трояк - наука большая - чего то он точно не знает.
Второй: я задаю вопрос - он не знает ответ, задаю другой - опять не знает ответ, задаю третий - он молчит. Ну я поставил ему пять - наука большая - что нибудь да знает.
ИМХО, если ваш собеседник, у которого стаж 100500 лет не может ответить на ваши вопросы на собеседовании, то скорее всего что-то не так с вами.
cupraer
12.06.2023 16:23+3если ваш собеседник, у которого стаж 100500 лет не может ответить на ваши вопросы на собеседовании, то скорее всего что-то не так с вами
Это очень сильно зависит от позиции. Подразумевая, что со стажем 100500 лет люди обычно претендуют на что-то весомее джуна, может быть по-всякому. Можно за 100500 лет спокойно дослужиться до кита, плавая только в мелкой воде.
Самый простой пример: через мои собеседования прошло довольно много рубистов, претендующих на звание синьёр; 90% из них — языка в принципе не знают, умеют исключительно во фреймворки типа рельсов, и в любой непонятной ситуации — вместо
reduceиспользуютeachс внешним аккумулятором.Такой код работает, и не режет глаз остальным 90% синьёров в компаниях, где эти набирали свой стаж.
Murtagy
12.06.2023 16:23Насколько "вместо
reduceиспользуютeachс внешним аккумулятором" влияет на дистанции на продукт/систему?
Есть ли реальная разница?cupraer
12.06.2023 16:23+1Да. Потеря скоупа и изменение внешних переменных изнутри цикла — очень подвержено ошибкам при рефакторинге.
Кроме того, что демонстрирует отсутствие понимания тривиальных концепций.
Murtagy
12.06.2023 16:23"демонстрирует отсутствие понимания тривиальных концепций"
Вы же понимаете что условному разработчику С/Go конструкция с reduce будет незнакома/непривычна. Страдают ли от этого системы? Вряд ли.
За собой замечаю что такие мелкие детали, которые переписываются в одну или в другую сторону с закрытыми глазами меня все меньше беспокоят
dprotopopov
12.06.2023 16:23Ну в js есть сейчас reduce. В других языках c, c++, c#, pascal, pl/1, fortran, go и тд - через библы - в самом языке таких конструкций нет.
От большого количества сахара может случиться и диабет :)
cupraer
12.06.2023 16:23А есть ли хоть один язык, в котором итератор
eachили типа того — есть, аreduce— нет? Я для друга спрашиваю. Даже ладно, шут с ним, с редьюсом этим:mapможно использовать, или это тоже синтаксический сахар? А главное, что засахарено-то, неужтоgoto(пустьjmp), который в сущности лежит в основе всех цикловforи им подобных?
laatoo
12.06.2023 16:23+4Бизнесу нужна была скорость выполнения задач.
Инженеры начали вводить высокоуровневые абстракции, чтобы управлять сложностью и не погружаться в детали каждый раз, потому что это сильно тормозит выполнение бизнесовых задач.
Инженеры начали этими абстракциями пользоваться и быстрее решать бизнесовые задачи.
Потом инженеры стали обвинять других инженеров что они не знают что там под низом, ах как же так.
Вы шизофреники.
beskov
12.06.2023 16:23только кажется в момент появления абстракций их пользователи перестали быть инженерами
как водитель грузовика не является инженером-механиком или инженером-электриком
laatoo
12.06.2023 16:23называй себя хоть сюзанной, если тебя от этого прёт (с)
"мы инженеры и все знаем а вы - не инженеры потому что дальше тулзы не видите" - это жиденькая позиция.
процессоры на сервере шуршат, и врядли вы знаете детали и тонкости его внутреннего устройства. вы скажете "а мне и не надо", и ровно то же отвечают те люди, о которых написан пост.
каждое поколение таких "инженеров" изобретает тулзы, и обвиняет следующие за "незнание основ". и каждый такой инженер почему-то за "основу" берет то, что знает и выучил сам.
весьма произвольно, не находите? почему не на уровень ниже? почему не на уровень выше?
"я инженер, а ты всего лишь жалкий пользователь, ниче не знаешь ниче не умеешь" - это игрушки в самоутверждение стареющего спеца.
"вот в наааше-то время..."
хатьфу
DvoiNic
12.06.2023 16:23справедливости ради, "в наше время" очень многие знали "снизу доверху".
Но лишь потому, что все это "снизу доверху" было очень малО. А "время" — изменилось, и отрасль сильно разрослась. теперь всё знать просто невозможно. И возникает закономерный вопрос — до какого уровня нужно знать "в глубину", и какой объем "в ширину". И однозначного ответа на это нет.
beskov
12.06.2023 16:23я как инженер САПР знаю на 2 уровня ниже САПР
- как разрабатывается софт
- как работают сети и компьютер
в деталях работы конкретных процессоров и сетевых устройств прям текущего года необходимости разбираться очевидно нет, потому что эти знания просто не нужны (в частности, я специализируюсь скорее на САПР ИС и бизнес-приложений, чем 3D и проч)
также я знаю на 2 уровня ниже, как работает механика, физика и химия, но для работы инженером АС типа САПР это уже не критично
если вам нужен действительно DevOps-инженер, т.е. человек, который ПРОЕКТИРУЕТ специализированную АСУ ТП, то он тоже должен знать на 2 уровня ниже
если вам нужен инженер по проектированию высокопроизводительных систем, то ему возможно нужно и в деталях работы процессоров и сетевых устройств текущего года разбираться, зависит от класса системы
просто если не нужны именно инженеры, а достаточно техников по эксплуатации, то нефиг с обеих сторон называть их именно инженерами и создавать завышенные ожиданияlaatoo
12.06.2023 16:23я как инженер САПР знаю ...
нефиг с обеих сторон называть их именно инженерами и создавать завышенные ожидания
аа, так вам за гордое звание инженера обидно, все понятно :)
если вам нужен действительно DevOps-инженер, т.е. человек, который
ПРОЕКТИРУЕТ специализированную АСУ ТП, то он тоже должен знать на 2 уровня ниже2 уровня ниже - откуда считаем? почему 2 а не 3? почему должен? из вашей головы?
также я знаю на 2 уровня ниже, как работает механика, физика и химия
ну да, теперь понятно откуда.
devops знаток химии это очень уважаемо, респект вам :)
Руководитель онлайн-школы Systems.Education
надеюсь, как руководитель школы вы и образовательный процесс на 2 уровня ниже знаете, иначе как-то непрофессионально получается. или не должен? почему нет?
впрочем, с вашей претензией на "знаю химию, физику и как разрабатывается софт" разговаривать больше не о чем.
хорошего вам дня!
beskov
12.06.2023 16:23мне не обидно, я даже по специальности не работаю
считаем исходя из системной холархии. должен исходя из сути деятельности, что для сборки объекта уровня X нужно знать свойства уровня X-1 как минимум. но это только для сборки. для проектирования нужно знать на уровень глубже, т.к. в ходе проектирования может возникать запрос на новую разработку компонентов уже этого уровнявы какую-то ерунду вычитываете всё время и фантазируете — обидно, ехидно, какие-то судороги, передёргивания, попукивания
так что и вам
M_AJ
12.06.2023 16:23+2если вам нужен действительно DevOps-инженер, т.е. человек, который ПРОЕКТИРУЕТ специализированную АСУ ТП, то он тоже должен знать на 2 уровня ниже
Инженеры АСУТП как правило не знают всего в деталях, работа всегда идет совместно с технологами, именно технологи знают процесс в деталях и формируют требования, например по точности поддерживаемых параметров, скорости их достижения, допустимом перерегулировании, заостряют внимание на критичных местах и т.п.
vitaly_il1
12.06.2023 16:23Увы, действительно много людей, которые нахватались buzzwords по верхам. (Кстати, недавно видел объявление о поиске преподавателя для курсов - искали человека с одним (!!!) годом опыта)
Хотя много и талантливой молодежи, грех жаловаться.Кстати, вначале показалось, что пост написал человек за 40 или даже 50 (мне 59) - но потом посмотрел в био и увидел что ошибся.
laatoo
12.06.2023 16:23Правда в том, что знание всех всех деталей реализации каждой тулзы/слоя абстракции невозможно. Ну невозможно всё знать.
Есть крошечный шанс найти человека, который уже знает достаточно таких деталей для повседневной работы конкретно у вас.
Есть большое количество людей не знающих таких деталей.
С точки зрения рабочего процесса вам скорее всего нужна ВОЗМОЖНОСТЬ при необходимости залеть в эти низкоуровневые детали и что то поправить.
С точки зрения найма, вы можете ловить единорога, который знает то что вам нужно и на таком уровне как вам нужно, либо брать тех кто есть, и научиться их эффективно закапывать в низкоуровневые детали при необходимости.
Правда в том, что скорее всего вы упираетесь в каприз спеца, который весь из себя такой умный, и ему надоело работать с окружающим его ничего не понимающим дурачьем (ну, как он эти видит).
Его каприз может быть оправдан, если в организации нагорожено велосипедов, которые кроме как низкоуровневым ковырянием не держатся, и поэтому ему нужны такие люди здесь и сейчас.
Это признак больной инфрастуктуры, которая не соответствует сегодняшним индустриальным стандартам. "Поздравляем, вы легасизировались!".
Кризисная точка, и из нее надо выходить.
Правильный путь - стандартизировать и приводить инфраструктуру в соответствие с теми технологиями/инструментами, которыми умеют пользоваться сегодняшие соискатели.
Тогда необходимость в поиске единорога пропадает.
Задачи, требующие особого погружения в низкоуровневые детали выполняются в обычном порядке: берутся спец/команда, и погружаются. Больно, тяжело, но надо.
ky0
12.06.2023 16:23Правильный путь - стандартизировать и приводить инфраструктуру в
соответствие с теми технологиями/инструментами, которыми умеют
пользоваться сегодняшие соискатели.Тогда необходимость в поиске единорога пропадает.
Приведёте пример такой связки технологий, у которой под капотом не будет линкуса, контейнеров, TCP/UDP, дисковых массивов?
laatoo
12.06.2023 16:23-1о том и речь что они будут под капотом, где-то там, а не тут, типа баш скриптами вы все это дерьмо собирать и склеивать будете
ky0
12.06.2023 16:23И когда это "там" поломается - какие-то другие люди будут чинить, или как это будет происходить? Когда проблема не будет решаться через инструменты, относящиеся к верхним слоя абстракции - а в том, что ниже, "сегодняшние соискатели" ни в зуб ногой.
laatoo
12.06.2023 16:23к более опытным коллегам, которые подскажут где искать, помогут и передадут опыт.
или самостоятельно, разбираться погружаясь в дебри, точно так же как и вы делаете когда сталкиваетесь с неведомой хренью
ky0
12.06.2023 16:23Мы всё ещё про сотрудников эксплуатации говорим? А то, знаете, в некоторых компаниях простой сервиса в две минуты - это шестизначные потери прибыли и повод для разбирательства на уровне топ-менеджмента. Лично я бы не хотел в таких условиях "погружаться в дебри" или ждать ответа от поддержки облачного провайдера.
AntoineLarine
12.06.2023 16:23Такие компании, наверное, в облака не ходят. Иначе потери обеспечены, так как полного контроля за облаком вы всё равно не имеете, и в случае чего всё равно придётся ждать ответа от облачного провайдера
ky0
12.06.2023 16:23Так я о чём и говорю - в шарашках, где всё может прилечь на пару суток, пока сегодняшние соискатели (с) будут гуглить, как диагностировать причину остановки сервиса, рестарта контейнера/ОС, низкой производительности i/o, наверное, действительно избыточны фундаментальные знания. Но это вырожденный случай и равняться на него, имхо, не стоит. Таких, надеюсь, в ближайшие годы заменит ИИ - как и массу других товарищей с квадратно-гнездовым мышлением.
laatoo
12.06.2023 16:23а как ведете себя вы, когда "упало", а почему - непонятно?
или вы просто настолько хороши, что вам всегда всё понятно?
laatoo
12.06.2023 16:23Коротко: если большинство кандидатов не способны работать у вас, есть вероятность, что это у вас что-то не так, а не с кандидатами.
"У вас" - это в стеке, инфрастуктуре, в рабочих процессах, в процессе найма, в сотрудниках.
pythoned195
12.06.2023 16:23+1<irony>
Давайте девопс будет знать весь стек , который сопровождает - от embedded до верстки , ну автор же хочет.
Следующим шагом будет поставить его вместо команды - ну он же знает все.
</irony>
Когда учить "Фундаментальные, нетленные знания" если вместо личной жизни и выходных девопс разбираеться в ченжлоге airflow и различии 1.25 и 1.27 k8s , потому что в рабочее завален тасками и инцидентами.
Может если вам нужны такие узкие спецы нужно вырастить их ?
Ну нет , развивайтесь в свободное время , сон для слабаков , заучивайте Таненбаума , если нам понравится ваша форма черепа и будете просить меньше рынка - так уж и быть , возьмем на SRE - будете proc грепать , потому как мониторинг для слабаков и это ваши хипстерские штуки.
Девопс объеденяет работу разработчиков , тестировщик , безопасников , сетевиков и опсов , но не должен знать делали лучше них
Думаете иначе - пожалуйста , вдохновляете их изучать , проводите мастер-классы , учите, наполняете огнем их глаза , раз на от ваших инженеров требуются уникальные навыки , которых нет на рынке.
Тут же пассивная критика - они неправильные , как жаль что нельзя воскресить и клонировать Криса Касперского и накатить клонам софтскиллов.ky0
12.06.2023 16:23+2Вы чот путаете. Автор как раз-таки сетует на недостаток широты кругозора соискателей (точнее - отсутствие фундаментальных для линукс-инженера знаний) - а вы ему предлагаете "узких спецов", доводя до абсурда. Получилось слишком толсто.
remendado
12.06.2023 16:23-2У рабочего муравья есть свой круг задач. У муравья солдата - свой. И только королева муравейника решает, куда движется проект.
AntoineLarine
12.06.2023 16:23Королева муравейника ничего не решает. Просто у неё свой круг задач, гораздо более узкий кстати, чем у рабочих муравьёв. И делает она его по той же заложенной биологической программе без шага влево/вправо.
mayorovp
12.06.2023 16:23Вот как раз в реальных муравейниках охлократия в терминальной стадии.
Часть муравьёв толкает проект в одну сторону, часть — в другую, каких оказалось больше — туда проект и движется.
wolandino
12.06.2023 16:23+1Провожу огромное количество собеседований разработчиков. Поймал себя на схожих выводах. Недавно общался с товарищем из большой е-коммерц компании - у него та же проблема.
Сошлись на мнении, что мы, пожалуй, старомодны, но фундаментальные понятия и определения знать нужно. Нужно понимать, как работает приложение и уметь работать на низком уровне, а не только на высоких уровнях абстракции.
Требования к кандидатам менять не буду. Конверсия невысокая, но итог хороший. Отсутствие увольнений в команде с 2019 года, команда выросла за это время в три раза.
p.s. компании немецкие, команды интернациональные
beskov
12.06.2023 16:23+1Я думаю индустрия сама себя загнала в эти условия, переименовав сисадминов в DevOps-инженеров.
У сисадмина не было обязательности инженерного образования.
Если в 70% случаев от специалиста нужна квалификация ремесленника, техника, как это например обстоит с разработчиками, а не инженера, то это совершенно нормальная ситуация.
Если брать аналогию с традиционной инженерией, то можно считать, что организация конвейера разработки ПО — это частный случай построения АСУТП.
Так вот человек, который строит такой конвейер в большой компании видимо должен иметь квалификацию именно инженера.
А человеку, который такой конвейер поддерживает, сопровождает, достаточно квалификации техника.
M_AJ
12.06.2023 16:23+1Если брать аналогию с традиционной инженерией, то можно считать, что организация конвейера разработки ПО — это частный случай построения АСУТП.
Совсем уж частный, все таки реальные АСУТП это в первую очередь модели, и главный инструмент АСУТПшника, это какой-нибудь MATLAB. В работе типичного DevOps ближе всего к этому – мониторинг. В идеале было бы круто конечно, если бы DevOps-инженер, имея АСУТПшное образование занимался анализом метрик, искал узкие места и потом вместе с архитектором они решали что с этим делать, моделировали, тестировали и перестраивали систему. Но для 90% DevOps вакансий это скорее оверквалифайд и, если проект крупный, ему архитектор напишет, какие метрики снимать и анализировать их будет тоже архитектор.
Tvinsen_NSK
12.06.2023 16:23-1Всё зависит от формулировки вакансии. Я никогда не стану далее общаться по вакансии, если вижу, что там хотят глубоких знаний, или же это видно по предлагаемой зарплате.
Кто-то другой попробует, и даже, может быть, сможет пройти. Риск должен вознаграждаться :)
DedZamkad
12.06.2023 16:23+1У меня скорее обратная ситуация - фундаментальные знания присутствуют (tcp/ip, linux, БД, скриптописательство, много еще чего и даже куча сертификатов), сам системный инженер, но вот думаю попробовать себя в DevOps, есть опыт администрирования k8s/docker. Но без опыта написания собственных манифестов и внедрения своих пайплайн цепочек.
Нужны такие?
ky0
Вы всё правильно говорите. Я где-то с годик назад писал на ту же тему со стороны соискателя, а сейчас не только не поменял мнение, но и углубил уверенность в тех тезисах.
Что на рынке существует огромный пласт соискателей, полностью отделённых от земли несколькими слоями абстракции в виде виртуализации, контейнеризации, оркестрации, SCM... Происходящее под капотом считается ненужными мелочами, которыми пусть низшая каста каких-нибудь сетевиков и инфраструктурных админов занимается.
Хотя уж Ансибл-то, кажется, если не тупо копипастить роли из Галакси - работает на довольно низком уровне, и чтобы понимать, что происходит - нужно хоть общее представление о потрохах иметь.
LINOLEUMfilm
ну это как требовать от механикa предварительно освоить литейное производство a потом удивляться почему он не хочет работать кузнецом - практика собеседования показывает что в описаниях вакансий да в резюме нет ничего про использование костылей и hr тоже про них не вкурсе а когда начинается собеседование одни загадки про их использование на что ты говоришь что так нельзя да не для этого создавалось но тебе в ответ что с костылями можно/нужно поэтому hr говорят что кандидат не подходит ... дальше пишут пост что пипл не хочет знать что у них там творится
ky0
Не очень понял, про какие вы костыли.
Аналогия мне видится не совсем удачной, мне на ум приходит скорее такая - "токарь приходит на собеседование без знаний материаловедения".
den1-55
Это не аналогия – это теперешняя действительность. Умеет читать чертежи – это уже плюс.
Во всех ± сферах сейчас такая беда.
Terimoun
Это не просто аналогия. Прямо анекдот
elve
Вы подобрали неверную аналогию. Тут скорее автодиагносты, которые умеют только с помощью кабеля ошибки с двигателя читать, но не хотят вникать в нюансы его работы.
micbal
Бывает обратный пример, пригонят корыто, где раз 20 в проводке поковырялись все кому не лень, блоки залили, и думают исходя из стоимости самого корыта, что диагност электрик им быстро все за 1000р. починит. Дороже не выгодно исходя из стоимости корыта. Всегда бывают разные ситуации...
LINOLEUMfilm
вообщето есть набор от bosh который устанавливается на авто без электроники чтобы в его bigdata узнать точную проблему (отклонения от норм/идеала) - если работодатель не может себе помочь/позволить $10k чтобы механик точно знал что ему починить почему работник должен читать в инструкциях производителя: если у вас достаточно тонкие и ловкие руки что вы можете залезть под приборную панель для смены деталей то можно еë не разбирать
Krouler7
В посте не совсем понятно какой грейд. Если действительно требуется какой то специалист, который и в инструменты и в железо - то наверняка и грейд большой. Тут даже как то обговаривать такого соискателя - время в пустую. Такой человек просто обязан знать.
Другое дело если грейд рассматривался небольшой. Но в таком случае зачем так много просить от небольшого грейда?
Второй момент, уровень абстракции - тема вечного холивара, схожий со сравнением Python и C++. Можно знать очень хорошо инструменты, но быть не очень сильным в железе. От этого ты не станешь менее специалистом и будешь делать задачи быстрее, чем человек который может многое понимать в железе, но не так силен в инструментах.
Ну и третий момент с ненулевой вероятностью - была попытка найти хорошего и дешевого специалиста.
elve
Мы обсуждаем незнакомых людей, так что может это и моя фантазия, поэтому не судите строго. Я из вышенаписанной статьи понял, что речь идет не просто о том, что человек не знает, а о том, что он и не хочет разбираться.
Если честно, такие специалисты побудили меня пару лет назад из админов пойти в devops/sre =). Не давало покоя, что люди, которые перекладывают ямлики, а в случае проблем у них лапки, получают в 2-3 раза больше меня, у которого не лапки =).
acsent1
Не каждый мидл мечтает стать сеньором
elve
То что описано в статье мидлом назвать язык не поворачивается. Хотя все бывает в нашем мире, конечно.
DMGarikk
это всеголишь объясняет то что миддл — понятие очень и очень растяжимое и зависит от того кто оценивает
по мне, миддл — это джун с опытом который не пытается непойми что изобрести и сделать (потому что опыт не дает), а не тот кто все на свете знает
а вот описанный вами миддл который знает такую теорию, это уже сеньор без опыта ;)
navion
Бывает ещё сильный мидл, который всё знает и умеет, но не хочет руководить людьми.
cupraer
Продраться через стену бессмысленного текста по ссылке мне не удалось, но все же спрошу: а что не так с карьерной лестницей синьёр → принципал → фелла?
Там тоже нигде никем руководить не нужно, а денег — ну уж не меньше, чем там где нужно, как минимум.
siziyman
Далеко не во всех компаниях, даже если там есть такая градация, на этих этапах никем не надо руководить.
navion
Обязанности другие, если звания тут не используют вместо грейдов или чтобы продавать 23-летних сеньоров заказчикам, как делают бадишопы.
myhambr
Больше денег хотят все. Даже на том же грейде. Даже просто так. Инфляция однако, вокруг все подорожало в пару раз за последние 2 года, а с крымнаша - так вообще в 5 раз. То есть 60-70тр в 2013, то есть чуть ли не джун во всем - это эквивалент 300тр сейчас. За те же знания и уровень! Те у кого было 200к, соответственно должны иметь миллион, чтобы быть на том же уровне, что и тогда. Без роста знаний и умений, просто на том же уровне, чтобы соответствовать инфляции.
Source
Это что у вас в 5 раз подорожало? В 2-3 раза согласен, в среднем в 2.5 можно сказать. Да и то далеко не всё. Например, квартиры в моём городе с тех пор на 70-80% подорожали.
Ну, это вы тоже утрируете. В 2013 году я сеньоров на вилку 100-150 т.р. нанимал, опытных и хороших. Джунов и на 30-40 т.р. можно было пачками брать, при желании.
P.S. А в целом, с посылом, что зарплаты надо индексировать я полностью согласен.
RH215
Знание основ работы памяти, сети и HTTP - это явно не про литейное производство. Это откровенно необходимая база для любого веб-программиста или веб-инжененра.
LINOLEUMfilm
опять токар[-электрик] и механик[-кузнец] а ещё бы бригадир.стрпощиков-крановщик[ов]-электрик тк только он может просчитать ресурсы с нагрузками да составить последовательность действий наиболее выгодной работодателю загрузки - водители отдельно a будулай отдельно да не обызан паять рессору за перетонаж тк так и механик станет обязан знать правила дорожного движения потому-что на кольце netsukuku или литейщик очередность закупа/поставoк сырья
Arvardan
Ну нет. Не может быть. Память? Cеть? HTTP? Где это нужно? Какая-такая база? Эндпоинты в django писать?
PuerteMuerte
Действительно, зачем веб-программисту разбираться, почему скрипт жрёт память как не в себя, зачем разбираться в протоколах, которые он использует при работе с фронтом, зачем уметь диагностировать различные сетевые проблемы, которые иногда возникают при связи фронта с бэком, у него же это никогда не возникнет. А если возникнет - ну позовёт на помощь кого-то с более высокой зарплатой, который не считает простые, но фундаментальные знания в смежных областях чем-то лишним.
Arvardan
Извините, напомнило
Всё так. Но, нужно помнить, что:
1) Проблемные ситуации это точно меньшая часть работы. Я даже представить не могу фирму где проблем больше чем имплементаций новых фич. Кол центр возможно? Но это не к программистам.
2) Быть знатоком всей тех. вертикали не получится. А тем более если еще и в стороны углубляться. Если вы с чем-то не работаете постоянно то вы эти знания потеряете (use it or lose it), либо они устареют.
3) Самое важное. Вы платите не за знания, а за мыслительный процесс.
Вы когда-нибудь пробовали делать дизайн страницы? Получалось? Информации куча на эту тему, туториалов, курсов. И вот сколько не смотришь, не учишься - не получается. Потому что вы не Дизайнер. А дизайнер может и не знать инструмента с которым придется работать. Зачем? Он же дизайнер. Он красиво и газету сможет оформить с карандашом и линейкой.
То же с врачами. Информация о анатомии человека в изобилии. Но вряд ли вы решитесь определить родинку как меланому самостоятельно посылаясь на книги.
И теперь назад к инженеру. Он же инженер. Он любит ковырять технику и решать проблемы. Задача "знать решения всех проблем" не стоит. Ожидается что если проблема возникнет, то он обладая определенными качествами, не имея предыдущего опыта найдет причину проблемы и устранит.
Лучше спрашивайте своих кандидатов какие шаги они бы приняли в случае ситуации X. А то вы придумали себе проблему - решили её, а потом ожидаете что кандидат угадает какое решение вы применили.
PuerteMuerte
У меня на этот счёт точка зрения очень простая: понимание, как работают смежные технологии хотя бы на понятийном уровне (не зазубривая, например, структуру хендшейка TCP или там заголовка, но понимая что такое TTL, DNS, NAT, фильтр IP и т.д., и умея трассануть маршрут до своего же сервера или там подменить IP-адрес хоста), это просто, это не рокетсайенс, это уровень продвинутого пользователя компьютера. И не существует вообще никаких причин и оправданий для веб-программиста, который не джун, их не знать, кроме банальной лени и узости мышления. А зачем вам узколобый ленивый человек в команде? Да, вы правы, для 95% задач, может, даже 99% задач ему это не понадобится. Но у него гарантированно, не сегодня, так через полгода случится задача из того 1%, которая положит его трепыхаться лапками кверху и звать мамочку набрать одну-две строчки на его компьютере.
Я плачу и за то, и за другое. Если бы меня интересовали только мысли, а не готовые знания, я бы работал в школе, а не в продактовой ИТ-компании :)
Arvardan
Мыслительный процесс. Не мысли.
Согласен что опыт нужен. Хотя бы чтобы ограничить "дерево" поиска. Но специализация "инженер" этот опыт подразумевает.
Наши с вами разногласия базируются на глубине и ширине этого дерева. Тут можно долго спорить, а правда, возможно, такова что всё зависит от контекста.
Я думаю, что, каковой бы не была правда, собрать команду дополняя слабые стороны команды легче, чем искать людей без слабых сторон (или с их минимальным количеством). И потерять не так больно.
Arhammon
Потому что проще и дешевле, но есть страшный минус такого подхода необходим нормальный менеджмент - чтоб человек умеющий решать 95% задач, решал именно эти задачи. Еще можно быть Гуглом, Эплом итп. и иметь деньги и имидж, чтоб набирать 110% специалистов даже в дворники. Еще можно хотеть как Амазон, но быть ИП Вася Пупкин и страдать, что кандидаты ничего не умеют...
acsent1
Вот ты все знаешь и умеешь, а по факту у тебя нет прав набрать ту саму строчку и нужно звать мамочку
Krouler7
К сожалению, в настоящее время "джун" надо сменить на "стажер". Джун теперь тоже обязан знать все это.
Norgorn
Часть вещей знаю, с остальным бы разобрался. Но ни одного раза с тех пор, как перестал работать с самодельными железками (там даже tcp стек свой был), ничем этим не пользовался. Вообще. Когда пробовал пингать свой сервер, девопс объяснил, что оно так не работает и вроде там всё сложно.
Веб программисту надо совершенно другие вещи - код хороший писать, понимать про БД, транзакции, многопоточность, как разделять нагрузку между нодами и как добиваться консенсуса (и как это всё масштабируется) и кучу ещё всего. В сетях сколько всего изменилось за посредник лет 10? Наш девопс вот настраивает докер-в-докере, мне и это надо знать? Оно поважнее, чем пинг будет уж точно (потому что вот прямо сейчас используется, а не только на лабах в универе).
Если всех слушать, что там каждый обязан знать, работать некогда будет.
DMGarikk
Это до тех пор пока вы например с фрагментацией пакетов не столкнетесь или с ограничениями MTU, когда у вас код локльно работает — а на проде нет… а ведь админ-девопс не знает чё у вас там понаписано чтобы понять что это с сетью чтото не так
p.s. я очень скорблю что разработчики, особенно веб-разработчики, не знают основ того что они вообще программируют
xenon
Лучше быть хорошим и богатым, чем бедным и больным. Конечно, лучше знать все, от количества бит в поле ID IP-пакета и до годов жизни Аменхотепа.
У Воннегута, кажется, была мысль, что последний человек, который знал "более-менее все" - это был Аристотель. После него все знают только кусками. В мои 20 лет мне казалось, что я знаю в IT все (кроме вот еще несколько тем, о которых я знаю очень обще, и их бы выучить). И дело не только в даннинге-крюгере, а с тех пор еще и IT сильно выросло, я понял, что я даже HTML (пример супер-простой технологии, даже не ЯП) не так уж и знаю - он стал каким-то большим и сложным, но при этом с историческим "наследством", и полное знание HTML'я подразумевает знание, как он работает во всех (включая редкие и старые) браузерах.
Специалист по базам данных должен не просто уметь всякие там джойн-слева, джойн-справа, джойн двумя ногами в прыжке делать, но и знать все разные (в том числе экзотические) типы баз данных, включая странные, и знать, как там у них со скоростью выполнения read, write, потреблением памяти, утечками памяти, кешированием, чтобы выбрать базу данных для нового проекта, а не просто придумать таблицы и индексы для MySQL/PostgreSQL. У меня вот есть вопрос на toster'е про утечку памяти в MySQL. Представляете - у всех работает (да и у меня везде работает), а вот на паре серверов - почему-то утекает память. И хороший эксперт по узенькой теме СУБД должен быть в курсе подобных проблем.
Я веду к тому, что если вы требуете определенных узко-глубоких знаний в определенных точках (которые вам известны и вы сами-то соответствуете), то может быть и сотрудника такого вы найдете. Но у всего есть цена. Он будет вашим "близнецом", он тоже потратил годы жизни на то чтобы хорошо-плотно-глубоко выучить и попрактиковаться именно вокруг этих вот точек. Но он заплатил эту цену за этот товар, и у него нет другого. Его знания с вашими сильно пересекаются (вряд ли он знает почти все, что вы, плюс еще по столько же в трех разных других сферах). А часто важнее найти человека, который бы знал то, что вы не знаете.
Viked
Работа с сетью для 99% прикладных программистов - ограничивается принять/отправить JSON.
Как глубоко нужно знать основы для них? OSI, TCP, RIP, IEEE 802.3, кодирование сигналов, теорему Котельникова, закон Ома?
Многие вполне себе живут, не зная HTTP методов (кроме GET и POST), пишут формочки и успешно зарабатывают деньги бизнесу.
Проблемы с фрагментацией пакетов - решаются не каждый день и даже не в каждой жизни рядового программиста (да хоть и сеньора).
DMGarikk
(както кучей ответил на два последних коммента)
ну так в том то и дело, что я тоже не знаю подробно как это всё устроено, в бытность меня админом я реально не потянул сетевые премудрости
я просто знаю что существует TCP/UDP/IP и что ARP это не IP протокол, или то чо наличие/отсутствие ICMP-шного пинга еще не означает что нет связи по TCP (забавно что это приводит в замешательство зачастую даже опытных сеньоров и многих миддлов-админов), примерно как происходит маршрутизация, это например дает понимание как протоколы друг в друга инкапсулировать можно (тыжпрограммист, а если будет задачка на коленке прокси написать для проброса https через какойнить левый протокол… если утрированно то RFC 1149 например надо мочь реализовать, то что сеньор сразу "ой всё, я только на джанге формочки писать умею, наймите другого человека"?
Я вот просто знаю базовые принципы как оно там устроено, если будет какаято сетевая задача я просто погуглю подробности
программист сетевых премудростей (которые возникают в рамках вебсервисов) это не отдельный вид программиста (отдельный вид это системщики низкоуровневые, но мы не про них сейчас)
только если у них грейд — Сеньор — то это как минимум несоответствие грейду
конечно, "это же проблемы девопсов (двигаем задачку в reject даже не думая), у нас лапки, этоже сеть глючит, а не пример из гугла по сетевой передачи данных это не учитывает и в книжечке не написано"
DvoiNic
Это не только веб-разработки касается, к сожалению.
И не только софта. и даже не только ИТ.
DvoiNic
А если этот "узколобый и ленивый" формошлёп будет получать значительно меньше денег, а "трудолюбивый и широколобый хорошооплачиваемый", один на 20 лентяев будет решать возникающие проблемы? И часть экономия ФОТа будет бизнесом отдана вам, как руководителю этой бандгруппы, и высокооплачиваемому спецу?
RH215
Во-первых, это не значит, что этой работы нет. Во-вторых, у более зрелых продуктов всё смещается с прикручивания фич в сторону поддержки. В-третьих, всё вышеперечисленное нужно знать как раз для того, чтобы проблем не было.
Причём, даже не столько, "нужно знать", сколько маркер того, что человек действительно занимался тем, что написано в резюме. Если веб-разработчик не в курсе как работает HTTP - чем он вообще занимался все N лет опыта? Если linux-инженер не в курсе про существование оверкоммита - чем он занимался?
Но знать куда нужно копать - нужно. Нужно знать основные принципы и лучшие практики. Если мне нужен будет человек на должность оператора гугла - я так и напишу в вакансии.
Areso
Почти любой достаточно большой и старый продукт. Даже если он не ломается сам по себе (а обычно ломается), то добавление фич точно ломает (по моему опыту). У нас продукты сильно зависят от инфраструктуры, и сломаться может что угодно когда угодно. "Мигнула" сеть - кранты. Отвалился DNS - кранты. Перестал отвечать один из нескольких сотен эндпоинтов 15 смежных продуктов - кранты. Линукс-инженеры обновили дистро (поменяв минорную версию, если повезло, а если не повезло, оставив номер минорной версии таким же как и был) - кранты... NTP где-то поехало - кранты.
Каждый раз это бег по минному полю и задача найти где рвануло -- и быстро.
SrantaClause
Согласен. Я почти 15 лет за рулем, безаварийная езда (тьфу-тьфу). Но я вряд ли с наскока сдам экзамен по вождению и пдд. На работе если вылезает проблема, то вряд ли я сразу отвечу на все вопросы, но спустя какое-то время проблему решу и задача будет выполнена.
IOlga1
Согласна с Вами. Был опыт собеседований, когда я хорошо проходила по всем вопросам интервьюера, уже сделала выводы исходя направления вопросов, на чем построен проект и как там работают, с чем придется столкнуться. А на деле не получилось никакой аналогии. Конечно, у меня тоже вопрос, а что если бы я была не энтузиастом, которому по приколу искать хорошие решения любых задач, а просто зубрилкой с мантрой "лишь бы взяли", но без грамма творческого подхода к проблемам? Загнулася б...
Иное дело если бы спрашивали хотяб частично про способы решения аналогичных ситуаций, которые возникают на проекте. Вы ведь на конкретный проект берете работягу. Думаю тогда больше шансов найти искомое (разработчика) и добыть кусочек счастья (умельца на проект)
Автору спасибо за интересную живую актуальную тему
iphizic
Я могу сказать следующее, да, изучив анатомию вы врачом не станете, но обращаться к врачу который не знает элементарной анатомии вы врядли захотите, тем не менее DevOps с точки зрения врача это терапевт, который должен знать симптоматику большинства болезней и в случае подозрения отправлять пациента к профильному специалисту. Поэтому хорошему DevOps специалисту нужно знать сетевой стек, как работает ОС, как работают уровни виртуализации, дабы быстро определить причины сбоя и пойти к нужному спецу, который отвечает за данный участок. Знаний присущих к профильному специалисту конечно не нужно, но в опыте я встречал массу кейсов в которых мне это пригождалось. Сейчас я нахожусь в позиции соискателя и поддержу автора статьи, единственное мое личное место критики автору, все зависит от того, кто нужен? Если вам нужен писатель ямлов, то подойдет соискатель который не обладает фундаментальными знаниями, если вам нужен ресерч, или архитектор, который писателям раздает параметры и занимается их ревью и дебагом, то тогда без перечисленных в статье знаний не обойтись.
Arvardan
Лично знаю врачей специалистов (кардиолог, гинеколог т.д), что не смогли дать ответ на то сколько костей в человеческом теле. Это считается? Поверьте, проблем с работой у них не возникает.
DMGarikk
1) сколько костей — это не нужное знание для таких специальностей
2) а вот гениколог который не знает основы эндокринологии и хирургии (а по сути он и есть узкопрофильный хирург) это уже страшно
DarthVictor
Ну вообще среднея приложение на реакте у вас без минимальных знаний HTTP может даже не запуститься. Или в нём не будут проставляться куки. Или отвалятся кроссдоменные запросы за картинками в CDN. Или загрузка на мобиле в 3.5G вместо 4G будет занимать вечность.
Другой вопрос, как определить тот минимум, который ожидается от начинающего инженера без опыта либо с минимумом опыта. А без опыта починки начинающий инженер много теории не усвоит.
faiwer
Но при этом тот же самый web-инженер может ничего не знать про эти ваши TCP, UDP, mac-адреса, про то как работают локальные сети, маршрутизаторы, сокеты и т.д..
И наоборот, человек ковыряющий ардуино может ничего не знать про эти ваши CORS-ы, Keep-Alive-ы, server-push-ы, CNAME в NS и т.д.
А такая петрушка во всём. Плюсовику нужно знать чем отличается переменная на стеке и в куче. Скалисту куда важнее знать как не допустить мёртвых ссылок, дабы GC не подавился.
Что не возьми у всех свой subset необходимых знаний, который определяется реальными задачами и инструментами. И все эти споры про "настоящий инженер должен знать Х" крайне беспредметны.
Вот мне как web-разработчику понимание адресной арифметики страниц памяти, или, скажем, суть L1+ кешей - никак не помогают в работе... В которой нужно ковырять развалившийся в ангуляре DI или какой-нибудь сломанный кеш.
WASD1
я программист.
наши dev-ops вот буквально неделю назад перенесли часть серверов на виртуалки.
На одном из серверов крутятся одновременно cpu-bound и disk-bound задачи.
Прямо сейчас (час назад) вижу, что disk-bound задача просела в тысячи раз. Сидят, разбираются. Краткое краткое резюме в момент описания задачи - сделали всё по инструкции "вписать название технологии" испортится ничего не могло.
Всё бы хорошо, но боюсь заказчикам такое объяснение не подойдёт (разумеется ребята толковые, всё починят - но вот этот подход "мы знаем инструменты" иногда подбешивает).
Zhbert
Ага. Именно поэтому все современный сайты тормозят даже на топовых ПК, грузятся по полчаса и вот это вот все.
Давно уже нет. Сейчас в моде «железо мощное, вытянет».
Я не говорю, что это правильно. Сам когда-то начинал с ассемблера и сишечки под МК, где у тебя есть 100Кб, и туда надо затолкать управление лазерным комплексом...
blind_oracle
На жс можно тоже писать по-разному.
Есть VSCode который относительно всяких Eclipse вполне юзабелен.
А есть всякие другие поделки, где погромисты не зная основ наделали O(n^3) циклов и утечек/фрагментации памяти
spaceatmoon
Удивительно да. VSCode глоток свежего воздуха после JetBrains. Вначале очень непривычно, но потом очень удобно. Даже удивительно.
RH215
А это от забивания микроскопов гвоздями и расжирания сайтов вплоть до уровня толстых клиентов. Тут проблема концептуальная.
Фразе "Software is a gas" больше 25 лет. Явление, что софт начинают оптимизировать только, когда железо не тянет, существовало примерно всегда.
shamash
Ну, вы не обобщайте. "Кандидаты отделены от отделенной земли несколькими слоями абстракции в виде виртуализации, контейнеризации, оркестрации, SCM" и "пока эта земля не встретится им в их профессии". Она встречается с ними довольно часто, когда человек попадает на место, которое он искал, и там слои нужно снимать один за другим, чтобы достичь необходимых бизнесу результатов. Это естественный процесс: сначала изучаются инструменты, а затем уже исследуется, почему они не работают.
А вот готов ли он встретиться со своей, не квалифицированностью, спустя N лет работы, другой вопрос.Вот на этот вопрос, и должен ответить соискатель на собеседовании.
ky0
Я не считаю, что девопс-инженер должен работать в режиме "я знаю инструменты, а вот когда произойдёт дизастер - я полезу смотреть, что там унутре". Никто не будет ждать, пока сотрудник пролезет через слои абстракции и кучу гуглежа, чтобы, как где-то ниже написал товарищ с 15 годами опыта и кучей сертификатов, осознать совершенно тривиальную причину неполадки или написать однострочник, грепающий логи.
vdshat
До маразма дошло: Yaml писать не камильфо, а в баше я не силен. Если в визарде не получается, то не судьба.