Comments 943
Вы всё правильно говорите. Я где-то с годик назад писал на ту же тему со стороны соискателя, а сейчас не только не поменял мнение, но и углубил уверенность в тех тезисах.
Что на рынке существует огромный пласт соискателей, полностью отделённых от земли несколькими слоями абстракции в виде виртуализации, контейнеризации, оркестрации, SCM... Происходящее под капотом считается ненужными мелочами, которыми пусть низшая каста каких-нибудь сетевиков и инфраструктурных админов занимается.
Хотя уж Ансибл-то, кажется, если не тупо копипастить роли из Галакси - работает на довольно низком уровне, и чтобы понимать, что происходит - нужно хоть общее представление о потрохах иметь.
ну это как требовать от механикa предварительно освоить литейное производство a потом удивляться почему он не хочет работать кузнецом - практика собеседования показывает что в описаниях вакансий да в резюме нет ничего про использование костылей и hr тоже про них не вкурсе а когда начинается собеседование одни загадки про их использование на что ты говоришь что так нельзя да не для этого создавалось но тебе в ответ что с костылями можно/нужно поэтому hr говорят что кандидат не подходит ... дальше пишут пост что пипл не хочет знать что у них там творится
Не очень понял, про какие вы костыли.
Аналогия мне видится не совсем удачной, мне на ум приходит скорее такая - "токарь приходит на собеседование без знаний материаловедения".
Вы подобрали неверную аналогию. Тут скорее автодиагносты, которые умеют только с помощью кабеля ошибки с двигателя читать, но не хотят вникать в нюансы его работы.
Бывает обратный пример, пригонят корыто, где раз 20 в проводке поковырялись все кому не лень, блоки залили, и думают исходя из стоимости самого корыта, что диагност электрик им быстро все за 1000р. починит. Дороже не выгодно исходя из стоимости корыта. Всегда бывают разные ситуации...
вообщето есть набор от bosh который устанавливается на авто без электроники чтобы в его bigdata узнать точную проблему (отклонения от норм/идеала) - если работодатель не может себе помочь/позволить $10k чтобы механик точно знал что ему починить почему работник должен читать в инструкциях производителя: если у вас достаточно тонкие и ловкие руки что вы можете залезть под приборную панель для смены деталей то можно еë не разбирать
В посте не совсем понятно какой грейд. Если действительно требуется какой то специалист, который и в инструменты и в железо - то наверняка и грейд большой. Тут даже как то обговаривать такого соискателя - время в пустую. Такой человек просто обязан знать.
Другое дело если грейд рассматривался небольшой. Но в таком случае зачем так много просить от небольшого грейда?
Второй момент, уровень абстракции - тема вечного холивара, схожий со сравнением Python и C++. Можно знать очень хорошо инструменты, но быть не очень сильным в железе. От этого ты не станешь менее специалистом и будешь делать задачи быстрее, чем человек который может многое понимать в железе, но не так силен в инструментах.
Ну и третий момент с ненулевой вероятностью - была попытка найти хорошего и дешевого специалиста.
Мы обсуждаем незнакомых людей, так что может это и моя фантазия, поэтому не судите строго. Я из вышенаписанной статьи понял, что речь идет не просто о том, что человек не знает, а о том, что он и не хочет разбираться.
Если честно, такие специалисты побудили меня пару лет назад из админов пойти в devops/sre =). Не давало покоя, что люди, которые перекладывают ямлики, а в случае проблем у них лапки, получают в 2-3 раза больше меня, у которого не лапки =).
Не каждый мидл мечтает стать сеньором
То что описано в статье мидлом назвать язык не поворачивается. Хотя все бывает в нашем мире, конечно.
это всеголишь объясняет то что миддл — понятие очень и очень растяжимое и зависит от того кто оценивает
по мне, миддл — это джун с опытом который не пытается непойми что изобрести и сделать (потому что опыт не дает), а не тот кто все на свете знает
а вот описанный вами миддл который знает такую теорию, это уже сеньор без опыта ;)
Бывает ещё сильный мидл, который всё знает и умеет, но не хочет руководить людьми.
Больше денег хотят все. Даже на том же грейде. Даже просто так. Инфляция однако, вокруг все подорожало в пару раз за последние 2 года, а с крымнаша - так вообще в 5 раз. То есть 60-70тр в 2013, то есть чуть ли не джун во всем - это эквивалент 300тр сейчас. За те же знания и уровень! Те у кого было 200к, соответственно должны иметь миллион, чтобы быть на том же уровне, что и тогда. Без роста знаний и умений, просто на том же уровне, чтобы соответствовать инфляции.
Это что у вас в 5 раз подорожало? В 2-3 раза согласен, в среднем в 2.5 можно сказать. Да и то далеко не всё. Например, квартиры в моём городе с тех пор на 70-80% подорожали.
То есть 60-70тр в 2013, то есть чуть ли не джун во всем
Ну, это вы тоже утрируете. В 2013 году я сеньоров на вилку 100-150 т.р. нанимал, опытных и хороших. Джунов и на 30-40 т.р. можно было пачками брать, при желании.
P.S. А в целом, с посылом, что зарплаты надо индексировать я полностью согласен.
Я сейчас делаю то же самое....
Из админа в девопс изучаю эти ваши дженкинсы, гиты, докеры, кубернетисы.
Так я еще о чем, есть у меня в родственниках молодой девопс за много денег работающий.... и он не может поднять впн на микроте..... потому что у него лапки....
А я еще и в паяльник могу, только зп моя /2
Вывод: хороший админ с руками и знаниями недооплачивается)
И это прекрасно. Миру нужны хорошие специалисты =).
Дженкинсы, докеры, кубернетисы проще понять и принять, если начать ими пользоваться. А для этого неплохо бы куда-то устроиться джуниором и через практику впитать и организационные особенности работы в разработке и паттерны использования тех или иных инструментов.
и он не может поднять впн на микроте… потому что у него лапки....
а потому что впн-ом сетевики занимаются, а не девопсы ;)
а вам стоит двигаться дальше по карьере учитывая ваши знания с этим проблем не должно быть
Знание основ работы памяти, сети и HTTP - это явно не про литейное производство. Это откровенно необходимая база для любого веб-программиста или веб-инжененра.
опять токар[-электрик] и механик[-кузнец] а ещё бы бригадир.стрпощиков-крановщик[ов]-электрик тк только он может просчитать ресурсы с нагрузками да составить последовательность действий наиболее выгодной работодателю загрузки - водители отдельно a будулай отдельно да не обызан паять рессору за перетонаж тк так и механик станет обязан знать правила дорожного движения потому-что на кольце netsukuku или литейщик очередность закупа/поставoк сырья
Ну нет. Не может быть. Память? Cеть? HTTP? Где это нужно? Какая-такая база? Эндпоинты в django писать?
Действительно, зачем веб-программисту разбираться, почему скрипт жрёт память как не в себя, зачем разбираться в протоколах, которые он использует при работе с фронтом, зачем уметь диагностировать различные сетевые проблемы, которые иногда возникают при связи фронта с бэком, у него же это никогда не возникнет. А если возникнет - ну позовёт на помощь кого-то с более высокой зарплатой, который не считает простые, но фундаментальные знания в смежных областях чем-то лишним.
Извините, напомнило
Всё так. Но, нужно помнить, что:
1) Проблемные ситуации это точно меньшая часть работы. Я даже представить не могу фирму где проблем больше чем имплементаций новых фич. Кол центр возможно? Но это не к программистам.
2) Быть знатоком всей тех. вертикали не получится. А тем более если еще и в стороны углубляться. Если вы с чем-то не работаете постоянно то вы эти знания потеряете (use it or lose it), либо они устареют.
3) Самое важное. Вы платите не за знания, а за мыслительный процесс.
Вы когда-нибудь пробовали делать дизайн страницы? Получалось? Информации куча на эту тему, туториалов, курсов. И вот сколько не смотришь, не учишься - не получается. Потому что вы не Дизайнер. А дизайнер может и не знать инструмента с которым придется работать. Зачем? Он же дизайнер. Он красиво и газету сможет оформить с карандашом и линейкой.
То же с врачами. Информация о анатомии человека в изобилии. Но вряд ли вы решитесь определить родинку как меланому самостоятельно посылаясь на книги.
И теперь назад к инженеру. Он же инженер. Он любит ковырять технику и решать проблемы. Задача "знать решения всех проблем" не стоит. Ожидается что если проблема возникнет, то он обладая определенными качествами, не имея предыдущего опыта найдет причину проблемы и устранит.
Лучше спрашивайте своих кандидатов какие шаги они бы приняли в случае ситуации X. А то вы придумали себе проблему - решили её, а потом ожидаете что кандидат угадает какое решение вы применили.
У меня на этот счёт точка зрения очень простая: понимание, как работают смежные технологии хотя бы на понятийном уровне (не зазубривая, например, структуру хендшейка TCP или там заголовка, но понимая что такое TTL, DNS, NAT, фильтр IP и т.д., и умея трассануть маршрут до своего же сервера или там подменить IP-адрес хоста), это просто, это не рокетсайенс, это уровень продвинутого пользователя компьютера. И не существует вообще никаких причин и оправданий для веб-программиста, который не джун, их не знать, кроме банальной лени и узости мышления. А зачем вам узколобый ленивый человек в команде? Да, вы правы, для 95% задач, может, даже 99% задач ему это не понадобится. Но у него гарантированно, не сегодня, так через полгода случится задача из того 1%, которая положит его трепыхаться лапками кверху и звать мамочку набрать одну-две строчки на его компьютере.
3) Самое важное. Вы платите не за знания, а за мыслительный процесс.
Я плачу и за то, и за другое. Если бы меня интересовали только мысли, а не готовые знания, я бы работал в школе, а не в продактовой ИТ-компании :)
Если бы меня интересовали только мысли
Мыслительный процесс. Не мысли.
Согласен что опыт нужен. Хотя бы чтобы ограничить "дерево" поиска. Но специализация "инженер" этот опыт подразумевает.
Наши с вами разногласия базируются на глубине и ширине этого дерева. Тут можно долго спорить, а правда, возможно, такова что всё зависит от контекста.
Я думаю, что, каковой бы не была правда, собрать команду дополняя слабые стороны команды легче, чем искать людей без слабых сторон (или с их минимальным количеством). И потерять не так больно.
А зачем вам узколобый ленивый человек в команде? Да, вы правы, для 95% задач, может, даже 99% задач ему это не понадобится. Но у него гарантированно, не сегодня, так через полгода случится задача из того 1%, которая положит его трепыхаться лапками кверху и звать мамочку набрать одну-две строчки на его компьютере.
Потому что проще и дешевле, но есть страшный минус такого подхода необходим нормальный менеджмент - чтоб человек умеющий решать 95% задач, решал именно эти задачи. Еще можно быть Гуглом, Эплом итп. и иметь деньги и имидж, чтоб набирать 110% специалистов даже в дворники. Еще можно хотеть как Амазон, но быть ИП Вася Пупкин и страдать, что кандидаты ничего не умеют...
Вот ты все знаешь и умеешь, а по факту у тебя нет прав набрать ту саму строчку и нужно звать мамочку
И не существует вообще никаких причин и оправданий для веб-программиста, который не джун
К сожалению, в настоящее время "джун" надо сменить на "стажер". Джун теперь тоже обязан знать все это.
TTL, DNS, NAT, фильтр IP и т.д., и умея трассануть маршрут до своего же сервера или там подменить IP-адрес хоста
Часть вещей знаю, с остальным бы разобрался. Но ни одного раза с тех пор, как перестал работать с самодельными железками (там даже tcp стек свой был), ничем этим не пользовался. Вообще. Когда пробовал пингать свой сервер, девопс объяснил, что оно так не работает и вроде там всё сложно.
Веб программисту надо совершенно другие вещи - код хороший писать, понимать про БД, транзакции, многопоточность, как разделять нагрузку между нодами и как добиваться консенсуса (и как это всё масштабируется) и кучу ещё всего. В сетях сколько всего изменилось за посредник лет 10? Наш девопс вот настраивает докер-в-докере, мне и это надо знать? Оно поважнее, чем пинг будет уж точно (потому что вот прямо сейчас используется, а не только на лабах в универе).
Если всех слушать, что там каждый обязан знать, работать некогда будет.
Веб программисту надо совершенно другие вещи — код хороший писать, понимать про БД, транзакции, многопоточность, как разделять нагрузку между нодами и как добиваться консенсуса (и как это всё масштабируется) и кучу ещё всего
Это до тех пор пока вы например с фрагментацией пакетов не столкнетесь или с ограничениями MTU, когда у вас код локльно работает — а на проде нет… а ведь админ-девопс не знает чё у вас там понаписано чтобы понять что это с сетью чтото не так
p.s. я очень скорблю что разработчики, особенно веб-разработчики, не знают основ того что они вообще программируют
Лучше быть хорошим и богатым, чем бедным и больным. Конечно, лучше знать все, от количества бит в поле ID IP-пакета и до годов жизни Аменхотепа.
У Воннегута, кажется, была мысль, что последний человек, который знал "более-менее все" - это был Аристотель. После него все знают только кусками. В мои 20 лет мне казалось, что я знаю в IT все (кроме вот еще несколько тем, о которых я знаю очень обще, и их бы выучить). И дело не только в даннинге-крюгере, а с тех пор еще и IT сильно выросло, я понял, что я даже HTML (пример супер-простой технологии, даже не ЯП) не так уж и знаю - он стал каким-то большим и сложным, но при этом с историческим "наследством", и полное знание HTML'я подразумевает знание, как он работает во всех (включая редкие и старые) браузерах.
Специалист по базам данных должен не просто уметь всякие там джойн-слева, джойн-справа, джойн двумя ногами в прыжке делать, но и знать все разные (в том числе экзотические) типы баз данных, включая странные, и знать, как там у них со скоростью выполнения read, write, потреблением памяти, утечками памяти, кешированием, чтобы выбрать базу данных для нового проекта, а не просто придумать таблицы и индексы для MySQL/PostgreSQL. У меня вот есть вопрос на toster'е про утечку памяти в MySQL. Представляете - у всех работает (да и у меня везде работает), а вот на паре серверов - почему-то утекает память. И хороший эксперт по узенькой теме СУБД должен быть в курсе подобных проблем.
Я веду к тому, что если вы требуете определенных узко-глубоких знаний в определенных точках (которые вам известны и вы сами-то соответствуете), то может быть и сотрудника такого вы найдете. Но у всего есть цена. Он будет вашим "близнецом", он тоже потратил годы жизни на то чтобы хорошо-плотно-глубоко выучить и попрактиковаться именно вокруг этих вот точек. Но он заплатил эту цену за этот товар, и у него нет другого. Его знания с вашими сильно пересекаются (вряд ли он знает почти все, что вы, плюс еще по столько же в трех разных других сферах). А часто важнее найти человека, который бы знал то, что вы не знаете.
Работа с сетью для 99% прикладных программистов - ограничивается принять/отправить JSON.
Как глубоко нужно знать основы для них? OSI, TCP, RIP, IEEE 802.3, кодирование сигналов, теорему Котельникова, закон Ома?
Многие вполне себе живут, не зная HTTP методов (кроме GET и POST), пишут формочки и успешно зарабатывают деньги бизнесу.
Проблемы с фрагментацией пакетов - решаются не каждый день и даже не в каждой жизни рядового программиста (да хоть и сеньора).
(както кучей ответил на два последних коммента)
ну так в том то и дело, что я тоже не знаю подробно как это всё устроено, в бытность меня админом я реально не потянул сетевые премудрости
я просто знаю что существует TCP/UDP/IP и что ARP это не IP протокол, или то чо наличие/отсутствие ICMP-шного пинга еще не означает что нет связи по TCP (забавно что это приводит в замешательство зачастую даже опытных сеньоров и многих миддлов-админов), примерно как происходит маршрутизация, это например дает понимание как протоколы друг в друга инкапсулировать можно (тыжпрограммист, а если будет задачка на коленке прокси написать для проброса https через какойнить левый протокол… если утрированно то RFC 1149 например надо мочь реализовать, то что сеньор сразу "ой всё, я только на джанге формочки писать умею, наймите другого человека"?
Я вот просто знаю базовые принципы как оно там устроено, если будет какаято сетевая задача я просто погуглю подробности
программист сетевых премудростей (которые возникают в рамках вебсервисов) это не отдельный вид программиста (отдельный вид это системщики низкоуровневые, но мы не про них сейчас)
Многие вполне себе живут, не зная HTTP методов (кроме GET и POST), пишут формочки и успешно зарабатывают деньги бизнесу.
только если у них грейд — Сеньор — то это как минимум несоответствие грейду
Проблемы с фрагментацией пакетов — решаются не каждый день и даже не в каждой жизни рядового программиста (да хоть и сеньора).
конечно, "это же проблемы девопсов (двигаем задачку в reject даже не думая), у нас лапки, этоже сеть глючит, а не пример из гугла по сетевой передачи данных это не учитывает и в книжечке не написано"
я тоже не знаю подробно как это всё устроено
"В наше время этим не гордились!" (c)
наличие/отсутствие ICMP-шного пинга еще не означает что нет связи по TCP
Собственно, это достаточно очевидная вещь практически для любого админа. На любом участке по дороге любой пакет может быть отфильтрованным без ответа передающей стороне. http так вообще может слушать несколько hostname на одном порте и это применяется практически повсеместно. Но, опять же, правилом хорошего тона считается разрешать icmp на конечных хостах а в случае блокировки "в дороге" отправлять пользователю причину.
Собственно, это достаточно очевидная вещь практически для любого админа
ох еслибы… для сетевика — да. а вот для любого админа, отнюдь
Но, опять же, правилом хорошего тона считается разрешать icmp на конечных хостах
Ну если только где-то внутре, а так это еще один вектор атак. Пусть лучше торчит только один порт/протокол который необходим. Все остальное нещадно резать.
Это не только веб-разработки касается, к сожалению.
И не только софта. и даже не только ИТ.
Но ведь если мой код не работает на проде из-за ограничений MTU — это и правда проблема вообще не программиста?
Или программист должен ещё и сеть на серверах настраивать? Нет, я-то могу и настроить, но это точно моя работа?
программист как минимум должен понимать что проблема точно не на его стороне
потому что зачастую всё выглядит как 7 дней перекидывания друг другу таски с ошибкой в стиле "'это не моё"
Админы видят код 500, 400 и т.п. и сразу реджектят заявку — типа это ваши проблемы, а программист "пули от нас уходят" и тоже её реджектит
… тут обычно нужен сеньор который вообще в курсе что может быть и возьмется свести оба полюса чтобы всё побороть
это же классический сценарий, админам всегда проще спихнуть все на программистов (у нас всё работает, пинги ходят), а программистов на админов (тесты проходят, джейсончики генерятся, это у вас чтото)
а вот заставить админов решать такую задачку невозможно просто потому что у них нет ни компетенций ни исходников ни вообще понимания как сервис работает (кроме движения пакетов между ендпоинтами)
я вот однажды видел такое что целый спринт мусолили задачку таким образом, просто потому что ктото особо умный пытался через get заслать данных больше чем в ограничения url пролезает… кто в этом виноват? инструментарий программиста может и мегабайт данных там заслать таким образом, а кто его там уже обрежет, браузер или прокси промежуточный или вообще кеширование промежуточное (неужели get от post не только способом отправки payload отличается?) еще ктото… это как звезды встанут, и кто будет исследовать такое? программисты которым не нужно знать основ http они и так таски по ресту закрывают? или админы?
==
сразу скажу я не требую на собесах такие знания даже от сеньора, я просто скорблю что люди считают нормой это не знать, особенно на высоких грейдах
Правильно, потому что надо админам не код HTTP в заявке кидать, а описание того что именно произошло. Например, обрыв TCP соединения, или там ошибка подключения к СУБД, или что-то ещё подобное. Это то что должен сделать программист.
А дальше уже админ обязан понять какого хрена соединение рвётся. Диагностика проблемы до уровня "некорректный MTU" — это совершенно точно его задача, только у админа (в нормальном рабочем процессе) есть инструменты диагностики сетевого уровня.
Кстати, читаю ваше описание и поражаюсь — какого хрена заявка вообще отклоняется вместо перенаправления?
Диагностика проблемы до уровня "некорректный MTU" — это совершенно точно его задача,
Я утрировал конечно, это уже конечная причина проблемы. но в случае с MTU есть явные признаки с размерами пакетов, когда всё работает, а чтото большое застревает. и это потенциально ведет к зацикливанию проблемы в стиле "пингуется — значит работает"
есть инструменты диагностики сетевого уровня.
для этого админу надо показать что проблема у него, а не потому что программист запятую не там поставил
Кстати, читаю ваше описание и поражаюсь — какого хрена заявка вообще отклоняется вместо перенаправления?
каких только чудес не бывает в мире, есть очень принципиальные люди, которые "решаю только свои проблемы, нечего мне непроверенный бред слать"
кто в этом виноват?
Кто стандарт нарушил — тот и виноват.
инструментарий программиста может и мегабайт данных там заслать таким образом,
Вот он и нарушил.
Но ведь если мой код не работает на проде из-за ограничений MTU — это и правда проблема вообще не программиста?
Похожий вопрос хорошо раскрылся в "Ловушка для простаков" Азимова.
Можно сказать что идея DevOps культуры это что-то из представителей мнемонической службы - везде по чуть-чуть + автоматизация, чтобы свести узких специалистов вместе.
Но реализация вылилась в виде DevOps инженеров, которые в своем большинстве предположительно сисадмины с навыками автоматизации билдов, разворачивания инфраструктуры и релизов.
А если этот "узколобый и ленивый" формошлёп будет получать значительно меньше денег, а "трудолюбивый и широколобый хорошооплачиваемый", один на 20 лентяев будет решать возникающие проблемы? И часть экономия ФОТа будет бизнесом отдана вам, как руководителю этой бандгруппы, и высокооплачиваемому спецу?
Про 1% эт хорошо, но простой вопрос, за этот процент, что понадобится раз в год, доплачивается?)
А то у нас как - все ленивые работать некому, а на деле зп 30тыщ.
Я поглядываю предложения - требования регулярно как будто денег сразу миллион и рук у тебя 8, даже стыдно резюму слать.
Проблемные ситуации это точно меньшая часть работы.
Во-первых, это не значит, что этой работы нет. Во-вторых, у более зрелых продуктов всё смещается с прикручивания фич в сторону поддержки. В-третьих, всё вышеперечисленное нужно знать как раз для того, чтобы проблем не было.
Причём, даже не столько, "нужно знать", сколько маркер того, что человек действительно занимался тем, что написано в резюме. Если веб-разработчик не в курсе как работает HTTP - чем он вообще занимался все N лет опыта? Если linux-инженер не в курсе про существование оверкоммита - чем он занимался?
Задача "знать решения всех проблем" не стоит.
Но знать куда нужно копать - нужно. Нужно знать основные принципы и лучшие практики. Если мне нужен будет человек на должность оператора гугла - я так и напишу в вакансии.
Я даже представить не могу фирму где проблем больше чем имплементаций новых фич
Почти любой достаточно большой и старый продукт. Даже если он не ломается сам по себе (а обычно ломается), то добавление фич точно ломает (по моему опыту). У нас продукты сильно зависят от инфраструктуры, и сломаться может что угодно когда угодно. "Мигнула" сеть - кранты. Отвалился DNS - кранты. Перестал отвечать один из нескольких сотен эндпоинтов 15 смежных продуктов - кранты. Линукс-инженеры обновили дистро (поменяв минорную версию, если повезло, а если не повезло, оставив номер минорной версии таким же как и был) - кранты... NTP где-то поехало - кранты.
Каждый раз это бег по минному полю и задача найти где рвануло -- и быстро.
Согласен. Я почти 15 лет за рулем, безаварийная езда (тьфу-тьфу). Но я вряд ли с наскока сдам экзамен по вождению и пдд. На работе если вылезает проблема, то вряд ли я сразу отвечу на все вопросы, но спустя какое-то время проблему решу и задача будет выполнена.
Согласна с Вами. Был опыт собеседований, когда я хорошо проходила по всем вопросам интервьюера, уже сделала выводы исходя направления вопросов, на чем построен проект и как там работают, с чем придется столкнуться. А на деле не получилось никакой аналогии. Конечно, у меня тоже вопрос, а что если бы я была не энтузиастом, которому по приколу искать хорошие решения любых задач, а просто зубрилкой с мантрой "лишь бы взяли", но без грамма творческого подхода к проблемам? Загнулася б...
Иное дело если бы спрашивали хотяб частично про способы решения аналогичных ситуаций, которые возникают на проекте. Вы ведь на конкретный проект берете работягу. Думаю тогда больше шансов найти искомое (разработчика) и добыть кусочек счастья (умельца на проект)
Автору спасибо за интересную живую актуальную тему
Я могу сказать следующее, да, изучив анатомию вы врачом не станете, но обращаться к врачу который не знает элементарной анатомии вы врядли захотите, тем не менее DevOps с точки зрения врача это терапевт, который должен знать симптоматику большинства болезней и в случае подозрения отправлять пациента к профильному специалисту. Поэтому хорошему DevOps специалисту нужно знать сетевой стек, как работает ОС, как работают уровни виртуализации, дабы быстро определить причины сбоя и пойти к нужному спецу, который отвечает за данный участок. Знаний присущих к профильному специалисту конечно не нужно, но в опыте я встречал массу кейсов в которых мне это пригождалось. Сейчас я нахожусь в позиции соискателя и поддержу автора статьи, единственное мое личное место критики автору, все зависит от того, кто нужен? Если вам нужен писатель ямлов, то подойдет соискатель который не обладает фундаментальными знаниями, если вам нужен ресерч, или архитектор, который писателям раздает параметры и занимается их ревью и дебагом, то тогда без перечисленных в статье знаний не обойтись.
Это не рационально с точки зрения бизнеса, у вас в команде должны быть специалисты разного профиля и уровня. Один делает типовые вещи, другой посложнее. Для этого и существует деление на джунов, мидов и сеньоров.
Ну вообще среднея приложение на реакте у вас без минимальных знаний HTTP может даже не запуститься. Или в нём не будут проставляться куки. Или отвалятся кроссдоменные запросы за картинками в CDN. Или загрузка на мобиле в 3.5G вместо 4G будет занимать вечность.
Другой вопрос, как определить тот минимум, который ожидается от начинающего инженера без опыта либо с минимумом опыта. А без опыта починки начинающий инженер много теории не усвоит.
Но при этом тот же самый web-инженер может ничего не знать про эти ваши TCP, UDP, mac-адреса, про то как работают локальные сети, маршрутизаторы, сокеты и т.д..
И наоборот, человек ковыряющий ардуино может ничего не знать про эти ваши CORS-ы, Keep-Alive-ы, server-push-ы, CNAME в NS и т.д.
А такая петрушка во всём. Плюсовику нужно знать чем отличается переменная на стеке и в куче. Скалисту куда важнее знать как не допустить мёртвых ссылок, дабы GC не подавился.
Что не возьми у всех свой subset необходимых знаний, который определяется реальными задачами и инструментами. И все эти споры про "настоящий инженер должен знать Х" крайне беспредметны.
Вот мне как web-разработчику понимание адресной арифметики страниц памяти, или, скажем, суть L1+ кешей - никак не помогают в работе... В которой нужно ковырять развалившийся в ангуляре DI или какой-нибудь сломанный кеш.
я программист.
наши dev-ops вот буквально неделю назад перенесли часть серверов на виртуалки.
На одном из серверов крутятся одновременно cpu-bound и disk-bound задачи.
Прямо сейчас (час назад) вижу, что disk-bound задача просела в тысячи раз. Сидят, разбираются. Краткое краткое резюме в момент описания задачи - сделали всё по инструкции "вписать название технологии" испортится ничего не могло.
Всё бы хорошо, но боюсь заказчикам такое объяснение не подойдёт (разумеется ребята толковые, всё починят - но вот этот подход "мы знаем инструменты" иногда подбешивает).
работы памяти, сети
необходимая база для любого веб-программиста
Ага. Именно поэтому все современный сайты тормозят даже на топовых ПК, грузятся по полчаса и вот это вот все.
Давно уже нет. Сейчас в моде «железо мощное, вытянет».
Я не говорю, что это правильно. Сам когда-то начинал с ассемблера и сишечки под МК, где у тебя есть 100Кб, и туда надо затолкать управление лазерным комплексом...
На жс можно тоже писать по-разному.
Есть VSCode который относительно всяких Eclipse вполне юзабелен.
А есть всякие другие поделки, где погромисты не зная основ наделали O(n^3) циклов и утечек/фрагментации памяти
Удивительно да. VSCode глоток свежего воздуха после JetBrains. Вначале очень непривычно, но потом очень удобно. Даже удивительно.
А ещё можно писать в блокноте, там вообще "пущка гонка" на 10кб будет. Ведь именно иде определяет качество кода )))))
Ага. Именно поэтому все современный сайты тормозят даже на топовых ПК, грузятся по полчаса и вот это вот все.
А это от забивания микроскопов гвоздями и расжирания сайтов вплоть до уровня толстых клиентов. Тут проблема концептуальная.
Сейчас в моде «железо мощное, вытянет».
Фразе "Software is a gas" больше 25 лет. Явление, что софт начинают оптимизировать только, когда железо не тянет, существовало примерно всегда.
Ну, вы не обобщайте. "Кандидаты отделены от отделенной земли несколькими слоями абстракции в виде виртуализации, контейнеризации, оркестрации, SCM" и "пока эта земля не встретится им в их профессии". Она встречается с ними довольно часто, когда человек попадает на место, которое он искал, и там слои нужно снимать один за другим, чтобы достичь необходимых бизнесу результатов. Это естественный процесс: сначала изучаются инструменты, а затем уже исследуется, почему они не работают.
А вот готов ли он встретиться со своей, не квалифицированностью, спустя N лет работы, другой вопрос.Вот на этот вопрос, и должен ответить соискатель на собеседовании.
Я не считаю, что девопс-инженер должен работать в режиме "я знаю инструменты, а вот когда произойдёт дизастер - я полезу смотреть, что там унутре". Никто не будет ждать, пока сотрудник пролезет через слои абстракции и кучу гуглежа, чтобы, как где-то ниже написал товарищ с 15 годами опыта и кучей сертификатов, осознать совершенно тривиальную причину неполадки или написать однострочник, грепающий логи.
Ну так не надо жмотиться на отказоустойчивую архитектуру, чтобы у инженеров было время на нормальную диагностику и поиск решения проблемы. Я бы не доверял экспертному эксперту который с закрытыми глазами по расположению звезд уже за полчаса до инцидента знает причину его возникновения. Анализ должен быть полным и подробным
До маразма дошло: Yaml писать не камильфо, а в баше я не силен. Если в визарде не получается, то не судьба.
Вы просто идете вместе с нарастающим трендом:
не важно кто ты в ИТ мире - ты должен знать свою область на 200%, а все что смежное хотя бы на 100%
Рынок становится таким... Много соискателей, конкуренция нарастает...
Лет через 5 сможете выбирать лучшего из толпы горящих глазами, для кого ИТ - это его жизнь... Остальных медленно выдавит с рынка эта проактивная ит масса.
Ой не знаю. От поиска коллег в этом году плакать хочется (бэкендера ищу). Ноль любопытства, тестовое делать не буду, кода чтобы показать нет, потому что негоже работать после работы, хочу 400к. На собеседовании основная фраза «я точно не помню».
Эта проблема касается практически всех профессий. Найти не рукожопа от сантехника до врача - тот ещё квест. Привет от Айн Рэнд.
Кстати, да. Я иногда задумываюсь, в каком изумительно-восхитительном мире мы бы жили, если бы каждый человек просто стремился качественно выполнять свою работу.
Если не ошибаюсь, идеи Рэнд реализованы в Биошоке. Затрудняюсь назвать тамошний мир изумительно-восхитительным(
Ну Биошок это вполне себе иллюстрация превосходства недостатков человека. Так что это скорее не "идеи Рэнд реализованы", а "в очередной раз продемонстрировано, что идеи Рэнд нереализуемы" =)
А что такое Биошок? Гугл только какую-то игру-шутер находит
Ну так это ведь игра, шутер с закрученным сюжетом. Он был сделан, чтобы интересно было играть, или вы бы предпочли, чтобы в Биошок протагонист попадал в утопичный, успешный мир и просто ежедневно ходил на работу?
Я иногда задумываюсь, в каком изумительно-восхитительном мире мы бы жили, если бы каждый человек просто стремился качественно выполнять свою работу.
Это точка зрения владельца компании:) Как было бы хорошо, если бы все сотрудники думали о нуждах компании, а не о своей выгоде.
Если выгода заключается в деньгах, плюшках или повышении - о ней думать надо. А вот о выгоде как бы схалтурить, не напрягаться и не осваивать нового действительно можно думать по-меньше. Это видно и когда нанимаешь кого-то в частном порядке. Кто-то думает о выгоде в виде оплаты за хорошую работу, а кто-то - и так сойдёт, сделать бы хоть как-нибудь. Тут выгода работника только в том, что бы меньше напрячься.
А вот о выгоде как бы не напрягаться действительно можно думать по-меньше.
Не раньше чем владелец компании начнет думать не о максимизации прибыли компании, а о максимизации зарплат.
Ну какой ещё владелец, если я сантехника на дом вызвал? Он говорит - 5 тысяч. Я говорю - окей. И что, ему можно (с моральной точки зрения) сделать мне халтуру только потому, что я не подумал о максимизации его дохода? Может я смог бы ему 20 заплатить или даже кредит для него взять - только после этого он начнет думать, как бы сделать хорошо? И то не факт?
Хорошо, что такой подход не всегда встречается. Знать бы заранее у кого он такой, как у вас, что бы не работать с ними.
ему можно (с моральной точки зрения) сделать мне халтуру
Поставленная задача бывает либо выполнена по заданным стандартам, либо не выполнена. "Халтура" это термин выдуманный заказчиками, которым очень не хочется платить, но объективно докопаться не до чего.
Может я смог бы ему 20 заплатить
Но наняли-то на 5к. На 5к и получили.
Это всё равно что разместить вакансию с оплатой 60к, нанять прогера на эту зарплату, а потом предъявлять ему претензии за "халтуру", потому что он выдает качество не на 200к, которые Вы возможно могли бы ему заплатить.
Лично мое мнение что делать некачественно - непрофессионально, не важно за какие деньги, т.к. ты же за них согласился работать. Если деньги тебя не устраивают - не соглашаешься, если согласился - делаешь насколько можешь хорошо
Лично мое мнение что делать некачественно - непрофессионально
"Сделать некачественно" это оксиморон. Если работа не соответствует заданному стандарту качества, то она не сделана и оплате не подлежит.
От чего же? Сделать некачественно - это типичная обыденность. Как пример - нужно отремонтировать станок. То есть ТЗ простое: оно не работает, должно заработать. По нормам нужен болт классом 9.9, но такого нет, идти за ним лень, есть болт класса эдак 5. В результате ставится этот болт, станок починен, заработает и проработает какое-то время. ТЗ выполнено? Выполнено. Качественно? Нет.
По нормам нужен болт классом 9.9, , есть болт класса эдак 5. ТЗ выполнено? Выполнено.
Нет, не выполнено. И нам сейчас реально страшно, если Вы нас не троллите, а говорите это на полном серьезе.
Попробуем нагляднее. Завтра Вас попросят починить холодильник, Вы сделаете так что бы в морозилке было +3 градуса и сочтете это выполненной работой? Сославшись на то, что мол "ну работает же". Вы, блин, серьезно?!
Попробуем нагляднее. Завтра Вас попросят починить холодильник, Вы сделаете так что бы в морозилке было +3 градуса
А если он сделает так, что в морозилке будут положенные -20 градусов, но через полгода плохо запаянная трубка опять треснет? Стандарт качества - штука совершенно условная. Она оговаривает какие-то частные условия, оставляя "за бортом" массу других, которые можно выполнять совершенно по-разному.
Так вы же сами всю ответственность на клиента скинули.
Напомню, что в этом треде вы спорите с тезисом, что было бы хорошо, если бы "каждый человек просто стремился качественно выполнять свою работу".
Т.е. с одной стороны вы считаете это плохим стремлением, а с другой удивляетесь почему вам плохо починили холодильник. Ну работало же. А то что на следующий день там снова +3, так это вы сами виноваты, с прорабом не посоветовались)
Почему вам страшно? Или вы мое заявление так интересно экстраполировали на, собственно, меня?
А по делу - почему, там будут те самые -10. Морозилка работает. Просто вместо качественной трубки для хладагента мастер взял самую дешёвую. Оно работает? Работает. Задание сделано? Сделано. Долго проработает - нет. Это, собственно, один из критериев качества. Или вот: ставите себе в машину не оригинальную запчасть, а аналог (или мастер ставит). Она свою функцию выполняет? Да. Работает? Да. Качественный ли это ремонт? Ну, вряд ли. Сколько проработает - никто не знает.
вместо качественной трубки для хладагента мастер взял самую дешёвую
Ну вот смотрите. Вы утверждаете "хочу самую качественную трубку для хладагента, самую дорогую какая есть на планете". И при этом платите ремонтнику 5000. А теперь подойдите к своему отцу например, и спросите, какую бы он хотел трубку в холодильник на замену. Скорее всего он скажет "Самую дорогую? Ты че, сдурел? Давай самую дешевую, какая разница". И как в итоге ремонтнику угадать, что вы хотите? Мысли читать?
И как в итоге ремонтнику угадать, что вы хотите? Мысли читать?
Бинго, в сегменте b2c самый главный навык - уметь нравиться неквалифицированному и некомпетентному заказчику с сильно ограниченным бюджетом и еще более ограниченным желанием просвещаться. И не перегружать его голову вопросами про кафльную плитку, как в том анекдоте про покупку туалетной бумаги.
Ок Починил, температура в норме. Но трубка была запаена тяп-ляп и через полгода накрылась. Работа выполнена? Или надо было паять лучше, чтобы труба жила 20 лет? Но через 10 лет накроется компрессор! Надо значит при запайке поменять и компрессор! Тогда прослужит дольше, правда еще запайка трубы вам встанет по стоимости в половину нового холодильника. Итак, что такое стандарт качества? Может все же не высасывать из пальца примеры не регламентированных определений которые выкручиваются всеми участниками под себя?
Вы уже начинаете откровенный троллинг из области жонглирования определениями.
Выше по ветке:
[…] 60к, нанять прогера на эту зарплату, а потом […] выдает качество не на 200к
У вас:
оплатили, скажем, месяц работы — […], оплатили 10 лет
Для того, чтобы люди не измеряли качество в трудоднях, в почасовых тарифах и прочих попугаях — существуют нормы и стандарты. Но ГОСТ и ОТК нынче не в моде, поэтому начинаются абсолютно неуместные конкретно в данном вопросе разговоры про моральную ответственность и прочую софтскильность.
Если вам просто оплатили месяц работы, без дополнительных условий мелким шрифтом, — абсолютно уместно лечь на диван и тридцать раз пересмотреть норвежский фильм «Горящий камин».
В случае же первого комментария, который я вообще не знаю, зачем сюда приплел, — абсолютно уместно потребовать эталон «качества на 200».
Нет, конечно.
Точнее, да.
Но вот беда, они все будут относительными, а потому на роль норм и стандартов из парижской палаты — годятся слабо.
Заказчик (наниматель) — сродни человеку, живущему в городке с одним продуктовым магазином (постарался выбрать самую близкую метафору :)). Если сегодня в этот магазин не завезли молоко — вынужден жарить блины на воде. Альтернатива — съездить в райцентр за молоком — хоть и вариант, но редко подходящий.
Так и тут: рынок доступных прямщас разработчиков конечен, определен объективными критериями, и в рамках каждого конкретного рынка можно навести непротиворечивую систему стандартов. Новый код валит продакшн не чаще раза в год, снимаем деньги со счета не того клиента — не чаще раза в два года, нет басфактора (написанное понятно другому члену команды), небольшие изменения ТЗ не приводят к пулл-реквестам на тысячу строк, увеличение нагрузки вдвое — вызывает алерт в метриках, а не отказ системы, понятно, что делать с увеличением нагрузки в 10 раз, и так далее.
А дальше уже по обстоятельствам: есть пул разработчиков, есть пул задач, есть какая-то шкала навыков и умений каждого… Надо решить штатную задачу — выбираем из пула Васю и ждем, что он справится за примерно предсказуемое время. Надо свой чатжпт натренировать — бьемся головой о стену.
А объективный стандарт только один: разработчику до́лжно стараться в меру своих сил и умений, которые обязан смочь оценить хоть кто-то в коллективе. Это не так-то сложно, если разработчик вышел на работу не вчера.
И компромиссная вилка: могу за месяц, но без секретарш, или за 10 лет с нейросетью, обыгрывающей гендиректора в шахматы. Но эта вилка должна быть озвучена на берегу, а не решаться внутри программиста в зависимости от его настроения.
Мне неизвестны случаи, когда люди бы на самом деле подписывались под такими требованиями […]
Это не отменяет существование таких требований :)
Мой любимый пример из моей же практики […]
В медиане-то можно. Выбросы будут, кто спорит. Но они не должны быть каждый раз, только и всего.
Отвечая на вопрос: очень сильно зависит от плотности записи; если перезапись значения частая — задача не слишком простая, если нет — тривиальная. Но я могу и ошибаться, триста лет на плюсах не писал.
на берегу неизвестно, какие проблемы вылезут
Конечно не известно. Зато мне примерно понятно какой глубины будет кажда проблема, и я об этом тоже никогда не стесняюсь рассказать на берегу.
Для того, чтобы люди не измеряли качество в трудоднях, в почасовых тарифах и прочих попугаях — существуют нормы и стандарты.
Это работает только в случае работ, где есть объективная характеристика готового продукта. Сварное соединение должно выдерживать давление в сосуде не менее 200 атм. Налили воду, надавили. Диаметр изготовленной детали должен быть в диапазоне от 20,00 до 20,04 мм. Взяли микрометр или два калибра, измерили.
А вот, например, задача инженеру - спроектировать кронштейн нагрузку 200 кг с креплением к стене таким-то. Казалось бы, объективный критерий - изготовить и подвесить груз, но нет. Материал, способ изготовления, необходимое оборудование, финальная цена изделия варьируются в весьма широких пределах, и чтобы установить все ограничения - вам по сути надо спроектировать "идеальный" кронштейн самому, а потом установить критерии по нему, но тогда вам уже и не нужна работа - вы всё сделали сами. Можно установить предельные условия - масса, стоимость материалов, трудоемкость. Но вы никогда не будете уверены, что массу относительно заданной можно снизить вдвое - или наоборот, вписаться в текущие ограничения объективно невозможно. А может быть, можно повысить трудоемкость на 5%, снизив стоимость материалов в полтора раза.
И так будет с любой сколь-нибудь творческой деятельностью.
обещали-то 5к, так кто виноват?
Нет, цену выставлял он, я же прямо написал.
выполнена по заданным стандартам
А вы пользовались услугами работников? Я ведь вообще не знаю, какие там стандарты могут быть. И я не собираюсь требовать скидку из-за косяков. Я просто хочу, что бы сделали хорошо и без проблем готов заплатить за это запрошенную цену. Но сейчас начнется нытье на тему "что такое хорошо". Кто профессионал-то в своей работе он или я?
Мне вот к врачу, например, который не помог, тоже не получится докопаться. Я просто не знаю, то ли проблема очень сложная, то ли он просто не знает. Может он сделал максимум, а может спустя рукава учился, а теперь пользуется тезисом "услуга оказана согласно стандартам". И не узнаешь из-за этого, идти к другому врачу или я уже получил максимум. Но отмазка знатная, убедительная, согласен.
вакансию с оплатой 60к, нанять прогера на эту зарплату
Нет, если он в принципе туповат или неопытен, никаких вопросов нет, бывает. Но если он на самом деле может выдать качество на 200к за тот же рабочий день (без переработок), но при этом пришел на вакансию в 60к и даже не обмолвился, что может делать лучше (не быстрее, а просто меньше багов, например) - это уж совсем странно. Он что, специально баги будет добавлять в код, что бы низкую зарплату оправдать?
Нет, цену выставлял он, я же прямо написал. Я ведь вообще не знаю, какие там стандарты могут быть.
Вы не знаете стандарты выполнения задачи, но ставите задачу исполнителю. Вы знаете свой бюджет, но не задаете его исполнителю. Исполнитель же называет бюджет на реализацию поставленной задачи. Вы думаете проблема на стороне исполнителя?
А вы пользовались услугами работников? Кто профессионал-то в своей работе он или я?
Поскольку Вы не профи, то в Вашем сценарии Вам надо было не ставить задачу сантехнику (ака программисту), а обратиться к прорабу (ака менеджеру) с просьбой описать варианты и назвать свой бюджет на работу.
После этого, выбрав нужное Вам соотношение цена/качество (5к попроще или 20к получше) взять ТЗ и с ним уже идти выбирать сантехников.
Но если он на самом деле может выдать качество на 200к за тот же рабочий день (без переработок), но при этом пришел на вакансию в 60к и даже не обмолвился, что может делать лучше (не быстрее, а просто меньше багов, например)
Скорость напрямую связана с количеством багов, затратив +Х времени можено уменьшить количество багов на -Y.
Вопрос изначально в другом - если Вы можете платить 200к, то почему Вы не обмолвились что можете платить 200к? К Вам приходит соискатель на 60к, он честно отрабатывает эти 60к, а Вы ему такой "ты гонишь халтуру так как не работаешь на 200к которые я мог бы платить"?
Ну да, я не знаю ГОСТы и СНИПы. И готов заплатить тому, кто знает и не обманет. Это неправильно, по вашему? Если исполнитель сделал хорошо, то проблемы нет. Если трубы потекли через месяц - то да, проблема с исполнителем. Он плохо сделал. Будете вешать лапшу, что я сам виноват?
обратиться к прорабу (ака менеджеру) с просьбой описать варианты
Да не вопрос, а прораба-то как выбирать? Если он скажет, что его бюджет на проработку ТЗ на установку смесителя - 5 тысяч, как понять, это он нормальную цену назвал или он плохое ТЗ сделает, ошибочное, потому что денег мало, а я должен был думать о максимизации его дохода и не соглашаться сразу на его цену?
Скорость напрямую связана с количеством багов,
Но ведь речь была о другом. О том, может ли конкретно этот человек при такой же (не меньшей) скорости разработки делать меньше багов, если ему платить 200 вместо 60-и. Если не может, то никаких претензий. Он не гонит халтуру, просто делает как может. Особенно если честно предупреждает, что его уровень низкий.
Если ты специально делаешь на 60, если можешь на 200, то наверное можно об этом сказать? Т.к. это очень необычная ситуация и к рассматриваемой проблеме никак не относится.
Халтура - это если у тебя в резюме 200, можешь работать на 200, тебе платят 200, а ты работаешь на 60 только потому, что работодатель не профи и ты всегда можешь отмазаться. А если ты честно отрабатываешь 60 и прямо говоришь о косяках - никаких претензий.
Ну да, я не знаю ГОСТы и СНИПы.… Если исполнитель сделал хорошо, то проблемы нет. Если трубы потекли через месяц — то да, проблема с исполнителем. Он плохо сделал. Будете вешать лапшу, что я сам виноват?
С одной стороны вы не знаете ГОСТы и СНИПы, с другой берётесь оценивать труд работника. Как получился вывод: трубы потекли через месяц — виноват сантехник?
Могу предположить, что:
- проблема не в том, где был ремонт, а в чем-то смежном. Сантехник видел, мог предупредить о возможной угрозе, но не стал по разным причинам (работал только в рамках ТЗ)
- проблема возникла по причине никак не связанной с сантехником
- как вы и предположили низкокачественная работа сантехника
т.е. не разбираясь в предмете вы пытаетесь делать выводы на неполной информации и пытаетесь переложить ответственность на наемного рабочего, который может быть невиновным в происшедшем.
мог предупредить о возможной угрозе, но не стал по разным причинам (работал только в рамках ТЗ)
Спасибо ему за это. Хороший сантехник, в следующий раз обязательно обращусь к нему.
проблема возникла по причине никак не связанной с сантехником
Тогда вопросов нет. Напомню, я не разбираюсь, для меня главное, что бы человек ответственно сделал свой участок работы. А если не может или не хочет (потому что денег мало, например) - честно об этом сказал.
Вы не знаете стандарты выполнения задачи, но ставите задачу исполнителю. Вы знаете свой бюджет, но не задаете его исполнителю. Исполнитель же называет бюджет на реализацию поставленной задачи. Вы думаете проблема на стороне исполнителя?
А вы, когда приходите, например, к стоматологу, знаете составы пломб, какие буры и с какой скоростью применять, как удалять повреждённые ткани и т.д., и сколько всё это стоит? Не знаете, верно? И если стоматолог сделал некачественно - проблема тогда будет на его стороне, или на вашей?
А вы, когда приходите, например, к стоматологу, знаете составы пломб, какие буры и с какой скоростью применять, как удалять повреждённые ткани
Мой стоматолог обычно тихо прифуевает, когда я, сидя в кресле, допрашиваю его, вида "а какое обезболивающее сейчас использовать будете? А почему X, а не Y? А Z не пробовали?"
Если, например, мне начать задавать такие вопросы, когда я уже приступил к выполнению задачи с инструментом в руках — вытолкаю такого клиента взашей, даже если он платит по десятикратной ставке.
Друзьям иногда доводилось получать половником по лбу за советы или даже вопросы в процессе того, как я что-то там у плиты делаю.
Думаешь, что умеешь лучше — вот тебе бормашина, режь себе свой аппендикс сам. Пришел ко мне? — Заткнись и жди, когда тебе скажут: «Готово».
Невозможно же быть специалистом во всех областях деятельности.
Странно, что он прифуевает на вопрос про обезбаливающие. Он не знает, что существует аллергия? Отличный стоматолог
Он не знает, что существует аллергия?
Нет, он, наоборот, знает, что у меня ни на одно из них аллергий нет. Мы ещё из того поколения, которое в порядке развлечения пускало кораблики в прорванной канализации, а в качестве пластыря использовало подорожник. Какие аллергии, о чём Вы?..
Тоесть это один и тот же стоматолог? И вы ему каждый раз одни и теже вопросы задаете?
в порядке развлечения пускало кораблики в прорванной канализации, а в качестве пластыря использовало подорожник. Какие аллергии, о чём Вы?
Как это связано?
Я до сих пор пускаю кораблики в прорванной канализации, а царапины вообще сами заживают.
Аллергии это никак не помешало дважды чуть не отправить меня к праотцам.
Не знаете, верно?
Да, хороший пример. Не знаю. И очень хорошо, если стоматолог подходит к делу ответственно. Если же он подумает, что владелец стоматологии ему мало платит и он может на этом основании делать кое-как - это проблема. Я ведь даже не знаю, какую долю владелец отдает стоматологу.
На чьей стороне проблема? С точки зрения закона, если получится доказать и есть время и силы - на стороне стоматолога. Он должен будет переделать. А с точки зрения здравого смысла проблема моя и лучше бы сразу выбрать стоматолога, у которого таких "замечательных" убеждений нет в голове и который старается сделать свою работу хорошо.
Вы не знаете стандарты выполнения задачи, но ставите задачу исполнителю. Вы знаете свой бюджет, но не задаете его исполнителю. Исполнитель же называет бюджет на реализацию поставленной задачи. Вы думаете проблема на стороне исполнителя?
Естественно. Самый простой пример: покупка хлеба в магазине.
Я не знаю, как пекут хлеб. Магазин не видел машину, на которой я приехал, и не знает, что мой бюджет позволяет купить магазин целиком. Исполнитель называет свой бюджет (в данном случае — цену). Я в лучшем случае могу пальчиком потрогать степень свежести.
И — охренеть, правда? — если в хлебе я найду использованный воздушный шарик, виноват будет магазин.
Вы можете прочитать состав хлеба на упаковке и убедиться, что в нем не должно быть никаких воздушных шариков, даже в индивидуальной гипоаллергенной упаковке.
Вы можете посмотреть срок годности хлеба и не только отказаться от его покупки, если срок превышен, но и требовать убрать его с прилавка, но не смотря на вашу возможность купить магазин целиком качество хлеба должно лишь отвечать требованиям стандартов качества, а не вашим пожеланиям к булочным изделиям.
Конечно, вы можете попросить, чтобы вам лично испекли хлеб на основе ваших пожеланий за любую договорную сумму, но в первую очередь изготовленный хлеб по индивидуальному заказу должен отвечать общепринятым стандартам качества.
Но если он на самом деле может выдать качество на 200к за тот же рабочий день (без переработок), но при этом пришел на вакансию в 60к и даже не обмолвился, что может делать лучше (не быстрее, а просто меньше багов, например) - это уж совсем странно.
Орлов в "Записках автоматизатора" писал:
Если качество или производительность труда программиста можно повысить с помощью материального стимулирования, то этого программиста следует уволить.
Поставленная задача бывает либо выполнена по заданным стандартам, либо не выполнена.
Вы в адеквате? По каким заданным стандартам? Вы всерьёз считаете, что на все виды работ есть ГОСТы, СНИПы и т.д.
И абсолютно все люди их наизусть помнят и в состоянии проверить качество выполненной работы по ним?
В 99% случаев халтура и даже откровенное мошенничество сходит с рук, как раз потому что вы как заказчик некомпетентны в том, что заказываете. Вот посмотрите как это происходит на примере ремонта компьютеров. А то косите под дурачка, как-будто вчера родились.
Причём тут владелец компании и вообще выгода? Вы видимо не читали Рэнд.
Речь идёт об этом:
В жизни имеет значение лишь одно – насколько хорошо ты делаешь свое дело. Больше ничего. Только это. А всё остальное приложится. Это единственное мерило ценности человека. Все те моральные кодексы, которые тебе навязывают, подобны бумажным деньгам, которыми расплачиваются мошенники, скупая у людей нравственность. Кодекс компетентности – единственная мораль, отвечающая золотому стандарту.
Ты либо компетентно подходишь к выполнению своей работы, либо нет. Это вообще никак не зависит от выгоды.
Это точка зрения потребителя, которому не совсем пофигу. Если вы подумаете немного, вы легко найдёте десятки случаев, когда вам может быть критично, чтобы товар или услуга были только надлежащего качества. Ну или вам нравится не слезать с унитаза, поев шаурмы, приготовленной грязными руками, или обивать пороги гос.учреждений, пытаясь исправить ошибку в документах. Про забытый у вас в брюшной полости при операции ватный тампон или вырванный не тот зуб я и не говорю даже.
Но да, это же никому кроме жадных капиталистов не нужно.
Я иногда задумываюсь, в каком изумительно-восхитительном мире мы бы жили
Как вариант, вы бы остались без работы, без жилья, без средств к существованию на дне общества ))
Появилось бы очень много конкурентов, что всё делают быстрее, точнее, дешевле. Не пишут комменты на Хабре, а всё свободное время посвящают работе. В перерывах от работы медитируют и занимаются спортом, чтобы выполнить следующий заказ еще качественней, будучи полностью в форме.
Да нет, кол-во конкурентов не изменилось бы никак. И хуже бы никто не жил, потому что экономика росла бы как на дрожжах. А спортивный азарт в достойной конкуренции - это даже хорошо.
Экономика бы росла, а те кто не вписался в экономику выпали бы из общества, не в силах бороться за ресурсы.
Как у вас получается эквивалентность между индивидуальным стремлением к качеству (и, возможно, производительности) и беспощадной борьбой за ресурсы? Повышение качества (и даже производительности самой по себе) не означают интенсификацию потребления и расхода ресурсов. Наоборот, легко возможны сценарии, когда продукт, например, служит дольше, а потому расход ресурсов на изготовление большего числа экземпляров (менее долговечного) продукта не происходит. Так что ваше утверждение - натянуто и однобоко.
Как у вас получается эквивалентность
Это не эквивалентность, это последствия. Не мгновенные, отложенные по времени, но неизбежные. Неужели вы на себе не ощущали конкуренцию на рынке труда? Когда вакансии с высокой зарплатой недоступны из-за наличия конкурентов. И на своем месте даже, несколько сбоев в работе и работодатель найдет замену. Вот я вижу что есть коллеги, которые работают лучше и быстрее, но они ушли в другие компании на более высокие зарплаты. Вот именно такие как я описал, работают не отвлекаясь на Хабр и прочее )
возможны сценарии, когда продукт, например, служит дольше, а потому расход ресурсов на изготовление большего числа экземпляров (менее долговечного) продукта не происходит.
Да, поэтому предыдущего разработчика увольняют. Его продукт служит меньше и требует больше ресурсов. И сам разработчик может заболеть, прокрастинировать, ошибаться, искать свое призвание, отвлекаться на Хабр. А тут ему в замен приходит идеальный сотрудник, который готов демпинговать на рынке труда. Уволенный разработчик пробует устроиться например разнорабочим, сейчас это без проблем. Но если и разнорабочие будут стремиться к совершенству (бросят пить, курить, займутся поверлифтингом, общефищической подготовкой), то и туда не возьмут. Я вижу как даже сейчас мотивированные разнорабочие работают, кладут уличную плитку пли +40 под палящим солнцем и быстро, поднимают грузы под 100 кг (у меня только от вида такого спина ныть начинает).
Сценарий фантастический, может после того как сценарий из фильма Гаттака реализуется, не в единичных случаях, а массово. Тогда мы можем выпасть на дно, как на картинке, экономика и наука скачут вперед, но без нас. Ресурсов в экономике становится больше, но они идут на изучение дальнего космоса например.
Еще есть сценарий из фильма "Области тьмы", там тоже сразу начинается конкуренция и главный герой стянул на себя ресурсы, благо он "добрый", а его антогонист направил сверхспособности на разрушение сразу (бандиты тоже могут стремиться к "совершенству" работая на мафию например). Позитивный сценарий есть в фильме Превосходство, но там всё зависит от личности главного героя и то что он решил всем помогать, а не уничтожать только его решение. С такими ИИ тоже конкурировать не выйдет, только исполнять его команды и его сценарии...
В обратную сторону если баланс смещается, как в фильме Идиократия, тоже плохо. Возможно то, что есть сейчас и близко к оптимуму (для нас).
Я тоже за то, чтобы все стали более мотивированным и умными, просто описал теоретические побочные эффекты при реализации такого фантастического сценария. Это интересно, но уровень жизни может и упасть...
Ну, во-первых, стремление качественно делать свою работу не даёт вам совершенство и идеальность. Оно просто повышает вовлечённость и несколько повышает уровень качества работ. Т.е. не надо утрировать до того, что люди резко супергероями станут.
А во-вторых, почему вы вдруг останетесь за бортом, если вы так же будете стремиться качественно делать свою работу (как минимум, в этом воображаемом мире)? Или вы про то, что если все начнут качественно работать, то вся работа в мире быстро закончится и людям будет нечего делать?
А во-вторых, почему вы вдруг останетесь за бортом, если вы так же будете стремиться качественно делать свою работу (как минимум, в этом воображаемом мире)? Или вы про то, что если все начнут качественно работать, то вся работа в мире быстро закончится и людям будет нечего делать?
Другие, которые сейчас делают работу не качественно начнут конкурировать с нами, делающими работу достаточно качественно или на пределе возможностей, чтобы не скатится в выгорание например. Так как людей на планете 8 миллиардов, это повлечет за собой огромную конкуренцию и дефицит ресурсов для нас.
Если не утрировать то ничего не изменится конечно, статистически на 1% изменятся какие-то параметры экономические и всё.
Ну, вы видите это в формате конкуренции типа "кто самый продуктивный". Я имел в виду несколько другое - когда сотруднику не наплевать на его работу и он выполняет её не формально, а чуть более проактивно и с акцентом на приятную коммуникацию и результат.
Как результат мне видится переход к 6-часовому рабочему дню или 4-х дневной рабочей неделе при сохранении оплаты и объёма работ (просто за счёт вовлечённости она будет выполняться быстрее). Плюс более качественный сервис и более приятные в среднем эмоции от взаимодействия между людьми. Плюс отсутствие всяких жёстких факапов, когда начальству докладывают то, что оно хочет услышать, а не то, что есть на самом деле. Что может приводить к ужасным последствиям, как например то, что мы сейчас в геополитике наблюдаем.
Такое не получится у вахтовиков. Там обратный эффект. Так как делать нечего, развлечений вокруг нет, начинают работать по 12 часов без выходных. Коллектив маленький, обманывать коллег и руководство не получится. Плюс заранее пролечиваются зубы и хронические болезни, поэтому работают даже без больничных.
У вахтовиков полярников еще кислородное голодание добавляется, весьма сильное, работоспособность в разы падает.
к ужасным последствиям
Возможно и наоборот, там многоходовочка просчитанная на годы вперед. А карты не раскрываются до последнего, как в покере.
Такое не получится у вахтовиков. Там обратный эффект. Так как делать нечего, развлечений вокруг нет
Ну, я не знаком с этой спецификой. Сейчас вроде половина развлечений в интернете. Хотя, возможно, речь про вахты в таких условиях, где и интернета тоже нет.
Я тоже не знаком, просто пример трудовых отношений специфических. Описаний жизни в таких условиях много и они достаточно интересные, например жизнь на грузовом контейнеровозе, вполне комфортная. В контексте нашего обсуждения тут интересно что подход обратный, ни какого сокращенного рабочего дня и рабочей недели, всё продленное. Но зато длинный отпуск, например месяц работы и месяц дома.
Вы не ответили на мой вопрос. Потому что я, конечно, ощущал конкуренцию и так далее, только это никак не связано со стремлением к совершенству тех, кто со мной конкурировал (потому что они, в большинстве случаев, не стремились к этому в той же степени, в какой стремился я - могу довольно ответственно судить об этом по нескольким внутренним вакансиям, на которые я не попал или попал далеко не сразу, лично зная своих конкурентов).
Вы почему-то полностью упускаете из вида существование локальных максимумов и оптимумов. Впрочем, если ваши рассуждения, судя по вашим иллюстрациям, основаны на впечатлениях от фильмов - это не странно, потому что процесс генерации гипотез у вас отсутствует, вы сразу переходите к примерке наиболее впечатляющих готовых (вовсе не обязательно реалистичных или вообще связанных с исходной вводной) примеров. Это конкретно-предметное мышление, простите.
Впрочем, если ваши рассуждения, судя по вашим иллюстрациям, основаны на впечатлениях от фильмов - это не странно, потому что процесс генерации гипотез у вас отсутствует,
Это простой способ донести какие-то идеи. На 100 листов тут нецелесообразно расписывать идеи или моделировать что-то. Или будут обрывочные мысли непонятные собеседнику, так как для их развертывания нужно слишком много текста написать, как ваши например:
Вы почему-то полностью упускаете из вида существование локальных максимумов и оптимумов.
?
Если речь об обществе, их нет, слишком динамично всё. На фоне исчерпания ресурсов быстрого ничего не статично.
Так они и сейчас выпадают. Бомжи, например. Но в целом услуги и вещи не станут дороже, они станут немного дешевле. И если вы не собираетесь халтурить, то никуда выпадать не будете (но возможно место в обществе изменится).
А чем это отличается от ситуации сейчас? Тот кто работает на энтузиазме, тот работает на энтузиазме, кто не работает на энтузиазме, тот не работает на энтузиазме. Откуда возьмется больше посвященных делу людей, если не вырастет конкуренция на посвященных и непосвященные не стали бы жить хуже?
Когда я ещё мыслил трудоустройством куда то, у меня в резюме было написано такое:
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: Я - айтишник и я ХОЧУ знать всё ))
If you invite me, but then decline my candidature without technical interview, this is direct way to my personal permanent ban.
И как, это работает? Для меня это примерно как пытаться пугать ежа голой задницей. Я не эйчар, я технарь, и провожу технические интервью, но я в упор не понимаю, что вы пытаетесь выторговать? Содержания только лишь вашего резюме мне недостаточно для того, чтобы с вами общаться, я хочу ещё первичный фильтр в виде эйчара, который отсеивает слишком уж сложных личностей по другим критериям. Если в обмен на срабатывание этого фильтра я какого-либо незнакомого мне кандидата больше никогда в жизни не увижу, хм, ну и что? Это сделка с нулевой стоимостью.
Так он не хочет идти в компании, в которых решение о найме на работу принимает hr. Общается, выясняет, не слишком ли человек сложный и отказывает самостоятельно.
Так что в данном случае он пытается выторговать время, которое потратит на общение с вашим hr. Он этого не хочет и считает бесполезным. И если hr не штатный, а из какой-то крупной конторы по найму, это может иметь некоторый смысл (штатных всех не перебанишь)
Это понятно, что не хочет. У меня был вопрос другого плана - с чего вдруг компании должны это его требование удовлетворять? Когда я был молодой и наивный, я тоже считал, что главное - быть хорошим спецом. Но спустя более чем четверть века в ИТ, я прекрасно понимаю, что главное - чтобы человек был хорошим (^_^)
Если без шуток, то речь о проверке характера соискателя. Если он психически неустойчив, токсичен и т.д., то уже неважно, что он там умеет как специалист. Вообще не важно. Один токсик нанесёт команде ущерба больше, чем взвод косоруких неучей. Да, я посмотрю CV, конечно же, и звать буду тех, чьё CV подходит. Но в любом случае, первое интервью маст хэв у эйчара. И только если эйчар согласовал, тогда будем приглашать на второе, техническое. И так делают все более-менее опытные компании, которые уже хоть раз на подобном обжигались. Поэтому подобные гарантии вряд ли кто-то будет давать. Если первую проверку прошёл - будет и желанное техническое интервью. Если не прошёл - ок, технического интервью не будет, баньте на здоровье, молодой человек. Тем более что людей с настолько "сложным характером", чтобы не дойти до технического интервью, попадается не так уж много, к счастью.
Один токсик нанесёт команде ущерба больше, чем взвод косоруких неучей.
Практика показывает, что «токсики» вообще существуют только в командах, в которых не банят за одно употребление слова «токсик».
Люди разные, если в команде половина — снежинки, а вторая половина — токсики, то в такую команду ни один нормальный человек не сунется. А если в команде нормальная атмосфера, то и «сложный характер» — не помеха, да и быстро выясняется, что не такой и сложный, просто немного другой.
Токсик — это просто удобный разговорный шорткат, обозначающий людей с "синдромом Д'Артаньяна" (в смысле тех, кто считает окружающих п#!@расами).
У нас был в компании случай, когда пришедший с улицы безусловно талантливый специалист, реальный сеньор, просто всех достал постоянными "Вы все говно!". Ну раз мы говно — пришлось предложить ему искать компанию получше.
Прошу прощения, но вы заблуждаетесь. Дартаньян не= токсик.
3.14дары, называющие всех вокруг другими дарасами, просто 3,14дары и никто больше. А токсичность бывает и позитивно-прикольная.
Именно!
Токсичность позитивно-прикольной никогда не бывает. Токсик - это тот, работа с которым вызывает раздражение, агрессию, обиды и т.д. Подколки с чёрным юмором, это как раз не токсичность, а нормальные позитивные отношения. Я как раз имею в виду персонажей, которые обладают чудесной суперспособностью переругаться со всеми вокруг, и при этом искренне считать, что проблема не в них самих.
Изначально этот термин означал вообще человека, который способен не переругаться со всеми, а "отравить" обстановку так, что и все остальные начнут ругаться между собой, друг другу завидовать и т.п. А уже потом модное новое слово стали употреблять по любому поводу.
И изначально, и изконечно, — этот термин обозначает химическое соединение, опасное или вредное для жизнедеятельности человека.
Побуду уж занудой, сорри нот сорри...
Бывают ещё такие случаи, когда слово само по себе означает одно, а в связке с другим - другое.
Так и тут: токсичный - это одно, а токсичный человек - другое.
Токсичный человек — это совершенно другое, тут согласен. Это маркер человека, плохо владеющего родным языком, и разговаривающего на суржике.
маркер человека, плохо владеющего родным языком, и разговаривающего на суржике.
Слово "принтер" Вы, я так понимаю, тоже не используете — только "алфавитно-цифровое печатающее устройство", только хардкор?
В словосочетании "алфавитно-цифровое печатающее устройство" половина слов тоже заимствованые, так что ситуация вообще патовая.
А причем тут заимствование вообще? Как будто «toxic» в этом смысле в английском употребляют не только лишь соевые дегенераты.
А какие дегенераты употребляют оборот "не только лишь"?
Справедливо :)
Но мне можно, я в целом с русским языком — на ты.
По принципу "могу, просто не очень хочу"?
Но мне можно, я в целом с русским языком — на ты
Дефис лишний (т.к. акцентирование тут не работает) и отсутствуют кавычки вокруг местоимения "ты" :Р
Если без сарказма, то "токсичный" - слово многозначное. И как совокупность негативных черт характера человека, это пусть и пока ещё неологизм, но уже полноценное слово русского языка. Так что почему вы к нему так относителсь, непонятно. Живой язык впитывает в себя новые слова, это нормальный естественный процесс.
Это не полноценное слово русского языка, а типичный представитель арго некоторой группы людей, принадлежность которой в тех кругах, в которых доводится общаться мне, принято не выпячивать.
В принципе, не существует никаких причин избегать фени (которая, по сути, точно такой же арго, только другой группы лиц) на собеседовании, или при знакомстве с дамой в театре. Но я лично избегаю, хотя и не только понимаю, но и владею в некоторой степени.
Это не полноценное слово русского языка, а типичный представитель арго некоторой группы людей
Это как раз полноценное слово. Абсолютно любые заимствованные слова в языке проходят через стадию, когда их использует какая-то ограниченная группа людей, прежде чем стать общеупотребляемыми. Слово "токсичный" в данном значении не имеет в русском языке нативного эквивалента, в то же время есть потребность в подобном обозначении, поэтому оно успешно закрепляется. И в отличии от фени, с которой вы зачем-то его сравниваете, не несёт в себе ни грамма обсценной лексики или отождествления с криминальными слоями.
Еще раз: заимствование тут ни при чем. В английском это тоже арго. И навсегда таковым останется.
Простите, но "токсичный" не является арго ни в русском, ни в английском языке. Арго - это "мама" и "клава" у компьютерщиков, это "дупло" и "опердень" у банкиров и т.д. - все слова, для которых вы можете выделить достаточно узкую группу лиц, которая их использует в своей среде. А слабо вам выделить группу, использующую слово "токсичный"? Это слово используют все и повсеместно, по крайней мере, кто имеет доступ к современной среде общения. Поэтому нет, это не арго ни разу. Это общеупотребительный неологизм, который уже достаточно прочно закрепился в языке, но некоторым ретроградам не нравится, как и любые другие неологизмы.
А какие дегенераты употребляют оборот "не только лишь"?
Не только лишь все!
Сразу видно, что на английском вы не общаетесь и контент не поглощаете, toxic behavior и toxic person - крайне расхожие выражения в очень разных кругах, социальных слоях и при любых политических взглядах.
Видно пока только то, что вы свой опыт общения с соевыми дегенератами облыжно экстраполируете на другие круги, социальные слои и политические взгляды.
соевыми дегенератами
Теперь я понимаю, почему вы не любите слово "токсичный". Вас, очевидно, часто так обозначают :)
Не, не угадали. :)
А термин toxic leader, который, пожалуй, первым пошёл в обиход из всех вот этих конструкций, если что, вошёл в употребление в 1996 году, и его автор вроде б не имела явных политических ассоциаций (да и вообще умерла в 1999, что явно несколько раньше, чем весь этот вой про "соевых" поднялся).
20 лет ежедневно общаюсь на английском и поглощаю контент, года примерно до 2018 слово toxic вполне себе означало "ядовитый" (toxic plant — ядовитое растение, toxic waste — ядовитые отходы).
Спасибо, кэп, никто этого не знал.
Понимаю, отчасти Вы конечно правы, однако тут надо учесть ещё один нюанс - человеку, у которого в резюме описан подробно опыт в 20+ лет в IT, зачастую поиск работы сводится к размещению на паре площадок, типа HH, GeekBrains, Angel.co, WWR и начать получать 100500 инвайтов в секунду, что само по себе создаёт весьма богатый выбор и он зачастую довольно не прост, так как хочется угадать с реально стоящим одним вариантом, который включает и интересный проект, и достойную оплату, и желательно equity, и все те плюшки с побрякушками, которые тоже весьма приятное дополнение, хоть и далеко не основная мотивация в выборе. Это своего рода фильтр, который отсеивает, да, может быть и некоторые стоящие предложения, но те, что остаются, в основном присланы более осознанно.
Ну и разумеется, самостоятельный поиск работы тоже остаётся и если находится реально такая позиция, что сам "офигеть - хочу туда", то тут понятно откликаешься сам и понятно что другой версией резюме, в которой нет этого фильтра )
Адский английский.
Сомнительный посыл дисклеймера. Я конечно не HR, но мое заключение после прочтения — "Самонадеянный, капризный, английский уровня B1". Так только рекрутёров распугивать. А подать мысль можно бы и лаконичнее, в стиле "Ищу интересные проекты, стремлюсь к достижениям, собеседования только при условии развернутого фидбэка независимо от решения".
Если Вы такой вот увлеченный спец, мой Вам совет, запускайте свой стартап, или ищите интересный opensource проект - шансов не попасть на путь выгорания и сохранить мечту и увлеченность, так гораздо больше.
Я был и мейнтейнером крупного OpenSource-продукта и стартап свой запускал. Там есть свои нюансы. Особенно в стартапах, там важнее умение продавать - что совсем другой навык. В общем, и то и то опыт безусловно интересный и полезный, но я бы не сказал, что это серебряная пуля.
Более того, если у индивидуума при взгляде на многие популярные продукты возникает чувство глубокого недоумения, кто в своем уме может их хотеть, организация стартапа из той же области, вероятнее всего - дохлый номер, потому что ощущение потребительской аудитории у него, скорее всего, отсутствует наглухо.
Дефицит ощущения аудитории можно компенсировать навыками объективных замеров востребованности - на чистом визионерстве уже давно не выехать, от рутинной продуктовой работы никуда не деться.
Но отчасти соглашусь: если такой опыт есть, то глубокое недоумение долго не живёт, и уж точно в возмущение не перерождается.
Факторы новизны и уникальности, тем не менее, играют большую роль, потому что делать что-то "такое же, но с перламутровыми пуговицами", конечно, можно (и примеров этому достаточно, у меня вот под носом - новое и очень популярное кафе-мороженое, несмотря на существующий в 300 метров от него Baskin-Robbins), но это нужно очень хорошо просчитать избыточный спрос, чтобы убедить инвестора/кредитора, что вы сможете привлечь потребителя.
Если честно, я каждый раз поражаюсь, что все еще существуют люди, которые идут в опенсорс не по зову души (простите), а ради бабла или еще каких плюшек.
Читайте внимательнее, часть про умение продавать была про стартапы. Или вы думаете, что их тоже из любви к искусству делают?
У OpenSource другие нюансы, например, фрустрация от недовольства пользователей. Если у вас хоть сколько-нибудь объёмный и популярный проект, то примерно 9 человек из 10 будут писать, что вы обязаны выполнить asap их хотелку. И только 1 из 10 напишет какие-то слова благодарности.
Это любопытно, что вы противопоставили благодарность и ощущение, что разработчик обязан пользователям, но абсолютно проигнорировали конструктивные сообщения об ошибках и объективных недостатках продукта. Потому что те, кто делают opensource исключительно ради удовольствия от процесса, к сожалению, систематически принимают конструктивную обратную связь за наезд (привет отсутствию социализации) и начинают поливать пользователей дерьмом заранее.
А сообщения об ошибках и объективных недостатках разделяются примерно в той же пропорции в зависимости от тона, в котором они присланы.
Да, это правда, хотя большей проблемой мне видится неумение объяснить проблему. Но даже при условии этого, вам не кажется, что это было бы глупо - принимать близко к сердцу тон и, например, игнорировать ошибку из-за того?
А где я писал, что надо игнорировать ошибку?
Я писал, что работа над OpenSource может оказаться фрустрирующей для многих, поэтому я не советую её в качестве серебряной пули от выгорания. Только это.
А в целом я очень даже за OpenSource и до сих пор PR-ы закидываю в либы, которые использую.
Вы не писали, это я привел пример (и я не говорил что вы говорили).
Речь о том, что то, что я описал - основная проблема сейчас.
Ну, это человеческий фактор. Когда человек что-то делает безвозмездно, он всё равно подсознательно рассчитывает, что его будут хвалить, благодарить и т.п.
Когда подсознательные ожидания расходятся с реальностью, люди могут по-разному реагировать. И это в целом нормально. Стабильный OpenSource в основном всё равно компаниями финансируется. На голом энтузиазме это так сильно не развилось бы.
Выборочно поправил
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.
Всё ещё чудовищно.
Жду твою версию?
Жду твою версию?
То, что вы ждёте - это утверждение. Зачем вопросительный знак в конце? Да, и на брудершафт мы точно не пили.
Что ваш, что оригинальный вариант - грубый подстрочник канцелярского русского (вводное 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.
Могу объяснить подробнее, если любопытно.
Какие мы нежные. То есть оставлять комментарий оценочный комментарий без конкретики - это верх вежливости.
Ты уверен. Ты уверен? Оба утверждения, вопросительный знак в конце ничего не значит.
Не вижу ошибки в использовании by -
https://www.merriam-webster.com/dictionary/by reason of
В остальном согласен, более удачно.
Вы свои ощущения проецируете, говоря "какие мы нежные"? Я просто вам указываю на то, что вы ведете себя, как шпана, потому что вам сказали, что ваш перевод - дрянной (и это - факт).
С русским языком у вас тоже тяжело, потому что "ты уверен" - утверждение о чьей-то уверенности, "ты уверен?" - вопрос о чьей-то уверенности, а "жду твою версию?" - бессмыслица, потому что вы говорите о себе ("жду" - первое лицо), то есть вам должно быть известно, ждете вы мою версию или не ждете.
Смотр - восстанавливаю ход событий:
- anarchomeritocrat приводит отрывок из своего резюме,
- ты критикуешь - "адский английский"
- я, добрый самаритянин, делаю попытку исправить явные ошибки. Вдруг человек чему-то научится.
Перестраивать предложение с нуля я не стал, плясал от того что есть.
- ты вешаешь ярлык - "все еще чудовищно", уже на мою версию. Это как на код-ревью просто поставить - плохо, отклоняю, без комментариев. То есть бесполезный оценочный комментарий, который не позволит улучшить результат. Можно и не оставлять, т к выводов сделать нельзя.
То есть нетто нашей коммуникации на данный момент - ты бросаешься негативными оценками, ценности не добавляешь.
Далее, я делаю утверждение "жду твоего версию", куда, наверное, совершенно случайно затесался вопросительный знак.
Ты решил в ответ на это снова насыпать обесценивающей лексики - придрался к форме общения, напомнил что к тебе нужно обращаться на ВЫ. И нашел ошибку в использовании "by", который нет.
С версией перевода согласен - вариант лучше.
Далее, снова даешь оценку в том что я веду себя как шпана и даже по-русски не ведаю что говорю.
А выводы каждый сделает свои
Жду твою версию? — нормальный вопрос: ударение на жду, и переводится как "мне следует ожидать твоей версии перевода?"
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 ;)
Если честно, меня бы очень смутило количество апломба и внимания к своей персоне в комбинации с довольно посредственным английским, и я бы прошёл мимо. Я не эйчар, я программист, который уважает хороших программистов.
Ну, это далеко не всё резюме, вообще, в целом в резюме у меня 15 страниц, большинство из которых описание опыта работы, и помимо прочего, там есть и раздел "About me", в котором я в общих чертах, лаконично, описываю свои навыки и увлечения, у него понятно, более человеческое лицо. В этом же разделе я специально изложил свою позицию нарочито жестко и вызывающе, не ради апломба, а просто что бы как раз как то отфильтровать инвайты из внушительного потока входящих, среди которых попадались, на первый взгляд интересные, но по факту просто тратящие бесцельно моё время, так, например, компанию Luxoft, трижды приглашала меня на собеседование и впоследствии отклоняла кандидатуру по причине "Overqualified", что и послужило причиной добавления упоминания об этом в данный пункт - он сформирован не из воздуха, а потому что одно время просто устал быть тупо мальчиком для неоплачиваемых бесперспективных показов рекрутерам.
А что до Английского, то в пункте "знание языков", у меня там честно написано "В1", так что я и не претендую на fluent.
Да, но это что-то из разряда фантастики.
Собственно, рынок диктует спрос.
Если спрос на что либо превышает предложение - то довольно наивно ожидать, что делая предложение ниже рынка вами будут сильно заинтересованы соискатели.
Я не верю что на в 2 раза больше денег приходят люди "в 2 раза лучше" по навыкам и отношению к работе, скажем так. Материальная мотивация для профессионала почти всегда вторична. Она полезна, хороша, но вторична. Так что я не думаю, что стоит всё переводить в плоскость "рыночек порешал", на мой взгляд это чрезмерное упрощение.
а вы уверены, что продукт за который вы заплатили в два раза больше будет выполнять/соответсвовать в два раза лучше
Не могу понять причём тут это. Мне указали "мало платишь -- получаешь плохих специалистов". Я позволил себе не согласиться с обратным ("много платишь -- получаешь хороших специалистов").
Приходите вы с аналогией, эквивалентность которой обсуждаемым вещам только предстоит доказать и спрашиваете уверен ли я в вашем предложении. В вашей формулировке почти наверняка нет, но я не вижу какое отношение это имеет к обсуждаемой тематике. Или вы сторонник упрощения и ставите знак равенства между покупкой репы в "Пятёрочке" и найме бэкенд-разработчика?
Позволю себе побыть душнилой.
Тезис:
делая предложение ниже рынка вами будут сильно заинтересованы соискатели
Не означает: "Если я заплачу выше рынка, то получу более качественных спецов"
Да, но проблему стоит рассматривать в комплексе.
Многие (в том числе я) стал бы вообще делать тестовое задание только в случае особого интереса к вакансии. В противном случае, гораздо проще за это же время пройти 2-3 собеса где опрос устный или интерактивный.
Наше тестовое рассчитано на 2 часа (по моим оценкам). Собеседование вряд ли занимает меньше часа.
Многим (мне в том числе, кстати) — комфортнее выполнить тестовое, чем шляться по собесам с интервьюерами непредсказуемого кругозора и адекватности.
А мой опыт последних лет прям вопиет: хочешь хорошего коллегу? — Сразу в мусор тех, кто не соглашается на тестовое. Да, я в курсе, что часть вкусных чаинок утечет в раковину, но КПД — прямо восхитительно увеличивается.
Часто обжигался с этими тестовыми. Делаешь его несколько часов, стараешься все оформить хорошо, а в ответ - тишина, или что-то типа "не подходите". И думаешь после этого - да пошли они со своими тестовыми все нахрен! Мне не влом было несколько часов над задачей потеть, а тому на той стороне баррикады влом отписться что не так.
В последнее время стал на предложение тестового открыто отвечать, что-де принципиально не против, но не хочу сделав работу, отправить её в чёрный ящик и ждать оттуда бинарного ответа. Если уж трачу время на задание - то ожидаю, что потом его обсудим в диалоговом формате.
Разумеется, ничто не мешает пообещать обсуждение, а потом прикинуться шлангом, но проговаривание шанс всё ж уменьшает, плюс даёт некий имиджевый бонус.
Конечно нет, с чего вы ожидаете, что функция зарплата(навык) будет линейной? Это было бы так только если два инженера производили в два раза больше работы.
Это не совсем так работает. На "в два раза больше денег" приходят те, кто не приходят на вакансии ниже рынка. Они не обязательно будут "в два раза лучше", возможно, они вообще будут не лучше. Но иначе выбор сведется к тем, кто согласен работать у работодателя с лозунгом "материальная мотивация для профессионала почти всегда вторична". А это, как правило, будут люди которых не взяли в более оплачиваемое место.
То есть, если мы возьмем условное распределение:
5% - звезды
10% - топ
70% - средний уровень
15% - профнепригодные
То предложив ЗП ниже рынка вы никогда не увидите верхних 5%, из топ 10% может кто-то зайдет случайно (и скорее всего уйдет, тк работа обычная и нет ничего, что оправдало бы ЗП ниже). И вы будете выбирать из среднего уровня.
И да, авансом скажу, что вы сейчас наверное напишете что "это вы просто денег не хотите нормально платить", дальше прислав ссылку на glassdoor/levels.fyi и упомянув глобальность рынка. Да, могу платить только на локальном рынке, аргумент "в Долине за то что программист не размазывает сопли по клавиатуре платят $300К в год" мне никак не поможет, простите =)
По локальному же рынку, 400к (на руки) вполне приличная зарплата, насколько я представляю.
это два месяца в окопе или три месяца на вахте - какой уровень науков у тех чуваков что они заняты отсилы 1/3 времени
С одной стороны она приличная и материальная мотивация действительно вторична после какого-то уровня. Но дело в том, что спецов действительно мало. И люди, которые считают себя спецами не всегда ими являются. И к вам на собеседование спецы не идут. Может быть 800к привлекут кого-то, а может у вас продукт/компания/местоположение/голос hr не такие, как надо. Тогда повышать ставку действительно нет смысла, работайте с теми, кто есть.
Скоро им ИИ поможет и ситуация станет лучше (для работодателей). Но придется ещё немного подождать )
Забавно, но опыт найма за последние 10 лет показывает: если хочешь идеальную пропорцию качества работника к его зарплате — платить имеет смысл чуть ниже рынка (от входа).
Код можно посмотреть при онлайн кодинге при собесе. Обычно стиль кода в разных конторах разный. На основании отличающего стиля любят делать неправильные выводы. А ведь человек готов был подстроиться под правила вашей команды. На тестовое задание вы были готовы ответить тестовой зарплатой?
Эти же люди говорят "онлайн-кодинг это издевательство". У нас на собеседовании онлайн-кодинга нет, потому что я считаю что это ненужный стресс.
Тестовой зарплатой на тестовое задание? Да не вопрос, можно по почасовой ставке. Но если задание не соответствует требованиям и я опишу детально в чём недостатки, деньги возвращаются, плюс вы по моей ставке заплатите мне за ревью? Я обычно на ревью трачу минут 20, потому что детально расписываю что не так, ссылки даже бывает предлагаю где почитать про то, почему так не надо делать.
Кстати, а собеседование не нужно оплачивать кандидату? У нас полтора часа обычно идёт.
А если тестовая зарплата не соответствует требованиям, желаниям? Время соискателя вы оцениваете в 0? Нужно проще быть, на равных относится к соискателю, не самоутверждаться за его счет и не реализовать синдром вахтера, и люди потянутся.
Момент про онлайн-кодинг вы решили проигнорировать, видимо предполагаете что я должен просто поверить нанимаемому что он умеет писать код без какого-либо способа демонстрации его навыков.
Время соискателя я не оцениваю вообще, это не моя задача. Если соискатель готов выполнить тестовое задание только за деньги -- его задача об этом сообщить мне (у нас нет HR, все переговоры напрямую со мной) и договориться об условиях.
Пример, который я привёл лишь говорит о том, что вы чудесным образом соглашаетесь с тем, что время соискателя ценно, а моё -- нет.
У меня есть цель -- найти коллегу. Я трачу своё время на создание вакансии, просмотр откликов, первичную беседу (до решения тестового, по желанию кандидата, где отвечаю на все его вопросы и рассказываю про его потенциальное место работы) и подробное ревью тестового задания.
Соискатель хочет найти работу и тратит своё время на реализацию тестового задания. Если здесь есть диспаритет -- мы можем договориться. Нанимать писать код человека, который не написал ни строчки кода, которую я бы видел, я не буду ни при каких обстоятельствах.
Общие фразы, где вы с лёгким налётом издевательства утверждаете что я самоутверждаюсь за счёт соискателей и про "люди потянутся" я оставлю без комментариев =)
Не решил, просто обычно кто не любит тестовое, показывает кодинг в онлайн. Стресс однозначно стоит учитывать, и не делать поспешных выводов (как любят странные работодатели). :) Вообще не показывая код как можно устраиваться на работу разработчиком? :) С другой стороны если это не джун, то свой ЯП он наверняка знает. Или к примеру почему не показать код как принято писать в команде, и пусть соискатель оценит, одобрит, подскажет и т.п. Чем не метод?
На собеседовании у нас есть секция мини-ревью кода. Навык написания кода и его ревью это разные навыки. Мне обязателен первый и лишь желателен второй, не наоборот.
"Вообще не показывая код как можно устраиваться на работу разработчиком"
Вот это мне и непонятно.
Может, как вариант, исходя из официальной статистики использования времени: "разработчик 80% времени думает, и только 20% жмет клавиши", стоит проверить как он умеет думать, например на вашем коде?
Я выше написал, что у нас есть мини-ревью для собеседования, но я считаю что написание кода и его разбор это разные навыки. У них общая база, но навык всё-таки разный. Я встречал людей, которые пишут вполне неплохой код, но обнаруживать дефекты в чужом почти неспособны.
Как я понимаю, код отражает умение думать, а также правила конкретной команды. Соответственно проверяя умение думать, и способность взаимодействия с командой, будет понятно какой будет код. Конечно навык чтения чужого кода у всех плохой, а чужого плохого кода часто навык чтения отсутствует за интервалы времени на собес. Или умение думать не отражает умение писать код?
Не знаю, я все время нанимаю просто на основе беседы. Без лайвкодингов и тестовых заданий
А хирург на собеседовании должен провести тестовую операцию?
Карман Маркс слезами обливается читая ваш пост. вы нанимаете работника поскольку собирательности присваивать прибавочную стоимость- по просто у разницы между тем что вы берёте с клиента и платите работнику. Поэтому ваше время это инвестиция. Полюс у вас ассиметричная информации вы знаете сколько сможете заработать на работнике а он нет.
Я трачу своё время на создание вакансии, просмотр откликов, первичную беседу (до решения тестового, по желанию кандидата, где отвечаю на все его вопросы и рассказываю про его потенциальное место работы) и подробное ревью тестового задания.
Это время уже обычно оплачено работодателем, так как все это должно происходить в рабочее время собеседующего, в то время как соискатель вынужден делать тестовое в свое не рабочее (никем не оплачиваемое) время.
Это время уже обычно оплачено работодателем
Ну так и собеседуемого нанимает не эйчар или техспециалист, а собственно работодатель. Он платит реальные деньги из своего кармана за найм, а соискатель вынужден делать тестовое... в какое-то время, может быть, рабочее и неоплачиваемое, может быть, свободное, с нулевым рейтом, а может быть, вообще на предыдущей работе и за счёт другого работодателя. Нормирование времени программиста, это штука вообще безнадёжная.
Тестовой зарплатой на тестовое задание? Да не вопрос, можно по почасовой ставке.
А я вот не готов. Профессионал никогда не откажется потратить пару часов ради выяснения перспектив на ближайшие два года.
Сопляки с бесценным временем и непомерными ожиданиями — сразу идут мимо, это экономит кучу времени и сил.
В свое время потратила кучу времени на тестовые. И решила, что больше их делать не буду.
Отклик на 10 вакансий и делать 10 тестовых после работы, ну это жестко. А если откликов не 10, а больше? (Имею в вижу и вариант, когда HR сами пишут).
Вы не одни с вашей уникальной вакансией, вас таких куча. И чтобы делать тестовое, мне нужно ооочень хотеть к вам попасть. Но вы не MAAG, так что к вам я точно не буду очень сильно стремиться.
А что, кто-то еще в 2023 стремится в этот отстойник? Зачем?
Отклик на 10 вакансий и делать 10 тестовых после работы, ну это жестко. А если откликов не 10, а больше?
Есть хороший лайфхак от этой проблемы: не откликаться на десять вакансий. Откликайтесь на две-три вакансии, которые вам больше нравятся, и там уже делайте или не делайте тестовые задания, в зависимости от того, что требуется.
Раскидывать своё резюме ковровой бомбардировкой, это непродуктивно. Это разве что вы остались без работы, и вам уже все равно куда идти, лишь бы побыстрее взяли хоть куда. В нормальном процессе трудоустройства лучше сразу определиться, куда вы хотите, и туда и подаваться.
Попробуйте получить хоть один оффер соблюдая собственные советы. В реальности нужно отправить сотню откликов ради одного оффера. А если работаешь на дерьмовой работе, с которой хочешь свалить, то многочасовые тестовые приемлимы только первые пару попыток. (Заявления, что тестовое "на пару часов" следует читать как "на пару дней".)
Попробуйте получить хоть один оффер соблюдая собственные советы. В реальности нужно отправить сотню откликов ради одного оффера
Наверное, очень сильно зависит от вашей квалификации. Я в своей 25-летней карьере работу менял семь раз. Будущие рабочие места выбирал сознательно, те, в которые именно хотел попасть. Всего в жизни я был на восьми собеседованиях в качестве соискателя. Поэтому простите, я не знаю, что энтакое нужно делать на рынке труда, чтобы получать один оффер на сотню откликов.
(Заявления, что тестовое "на пару часов" следует читать как "на пару дней".)
Может быть, как раз в этом и дело - тестовое действительно было на пару часов :)
Ну знаете, когда трудовые были актуальны, у меня вкладыш был пришит из-за того, что страницы кончились. Хвастаться там нечем.
Поэтому простите, я не знаю, что энтакое нужно делать на рынке труда, чтобы получать один оффер на сотню откликов.
Вот попробуйте и узнаете.
А почему на C++ собеседовались? Там ведь слабая типизация
Не упомянул, я удаленку ищу, там на интервью сквозь горящее кольцо прыгать приходится. Из последнего, нужно было закрыть конкретный issue в общеиспользуемом приложении и чтоб владелец принял пуш реквест. Какой-то самописанный hackerrank с тестом на 8 часов, последний тест нечитаемый из-за текста с шириной в 1 символ, после указания на это hr больше не отвечала. Не смог правильно ответить как хэш таблица внутри обрабатывает коллизии. Предложение подписать договор с материальной ответственностью за ущерб от работы приложения. И т.д. Короче, записал себе в блокнот что плюсы теперь только для хобби.
Ну знаете, когда трудовые были актуальны, у меня вкладыш был пришит из-за того, что страницы кончились. Хвастаться там нечем.
Ну так тем более. Столь частые смены работы, это же не признак опыта в трудоустройстве, а признак или его полного отсутствия, или в лучшем случае, хронического невезения.
Поэтому простите, я не знаю, что энтакое нужно делать на рынке труда, чтобы получать один оффер на сотню откликов.
Элементарно - оказаться весной 2008 года в NYC на H1B. Когда увольнения идут этажами, то HR как-то пофиг становится на ваш опыт, если он не совпадает буква в букву с нужным набором баззвордов как минимум.
Предположу что 25 лет назад всё было иначе т.к. индустрия разработки ПО в её сегодняшем виде только зарождалась. Сейчас крайне сложно получить первую работу, дальше уже проще.
Кстати, а собеседование не нужно оплачивать кандидату? У нас полтора часа обычно идёт.
Почему именно кандидату? Он точно так же свои личные полтора часа тратит.
и чтобы за такси заплатили
Как вы думаете, если интерес обоюден и у соискателя, и у работодателя, потенциальный работодатель в офисе, а соискатель к нему едет, тратя свое время и свои ресурсы на проезд, это по-честному? Или исходя из выше представленной логики, один соискатель заинтересован в рабочем месте, а работодателю это какбы не нужно? Откуда тогда очередной "плачь Ярославны" про "нетути специалистов"? Сами работодатели не знают что хотят...
На тестовое задание вы были готовы ответить тестовой зарплатой?
Тестовые задания - они, как и йогурты, не одинаково полезны. Если ожидаемая длительность задания измеряется в сутках (с учётом того, что кандидат знает, как его делать), то логично его оплатить, конечно же. А ещё логичнее его не давать. Если в часах и тем более, минутах, то платить там в общем-то и не за что, это просто продолжение собеседования. Собеседующий тоже будет тратить время и на ревью, и на написание отзыва.
Собеседующий тоже будет тратить время и на ревью, и на написание отзыва.
Но обычно решает не тратить - смысл, если всё равно отказ и больше этого человека не увидит?
Подробной развёрнутой рецензии может и не будет, но всё-таки какие-то комментарии после ревью технического задания рецензент практически всегда даёт. Так, чтобы посмотреть задание и сказать "нет", не объяснив "почему" - это скорее редкое исключение. Другой вопрос, что эйчар не всегда их транслирует дальше до собеседуемого, но это уже претензия к иной инстанции.
Я пишу напрямую кандидату, в виде кодревью в пулреквест.
Какой еще нафиг эйчар?
Спасибо, что держите в курсе, но мы же не вас тут обсуждали :)
Я просто положил первый камень в репрезентативную выборку.
А как вы относитесь к компаниям, которые не хотят замусоривать пуллреквестами совершенно одноразового кода свой гитхаб, а смотрят его каким-то другим способом?
Я не очень понял вопрос. Мы просим тестовое задание оформить пулл-реквестом в свой пустой репозиторий и дать ревьюерам права на CR, где оно и происходит.
Компания может даже скриншотом просить прислать код, если ей насрать на кандидата, и адекватный фидбек, удобный для просмотра, обсуждения и защиты, предоставлять кандидату она не собирается.
Но мы не такие. Кандидат имеет право на обоснование своих решений, в процессе обсуждения, вдруг интервьюер — лох и сам ошибся?
Мы просим тестовое задание оформить пулл-реквестом в свой пустой репозиторий и дать ревьюерам права на CR, где оно и происходит.
А, ну т.е. вы делаете это ещё и не в своей репе, а в репе соискателя, дать вам там права и там будете комментить, при этом вам все равно надо стянуть себе код, чтобы собрать и посмотреть, как он работает. А потом это же сообщать эйчару, который с сотрудником коммуницирует (потому что программисты вопросами найма не занимаются в компаниях крупнее двух-трёх человек, у них своя работа есть). Как по мне, это вообще совершенно лишний ритуальный танец.
Мне не нужно что-то собирать, чтобы узнать, как оно работает, извините.
И ничего сообщать эйчару, кроме да/нет мне тоже не нужно.
Лишний ритуальный танец? — Ну так просто не танцуйте, соискателю ведь вообще фидбек не нужен, вон любого спросите, а у вас небось еще и серьезная компания, крупнее трех человек.
Мне не нужно что-то собирать, чтобы узнать, как оно работает, извините.
Не существует программистов, которые проверяют задания в уме. Есть программисты, которые не проверяют задания, а просто смотрят на качество оформления, есть программисты, которые собирают и смотрят, но иногда в споре преувеличивают свои способности. Все равно никто обратное не проверит :)
"основная фраза «я точно не помню»" - что в этом такого в нашем деле, не зря же живёт СтекОверфлоу.
Зачем помнить наизусть какие именно символы печатать, если ты знаешь что есть такая возможность и когда её стоит применить
А что за условия, какое тестовое?
Про условия требуется более конкретный вопрос, а тестовое ниже.
Реализовать IDictionary<,> таким образом, чтобы перечисление его элементов сохраняло порядок, соответствующий порядку вставки, при этом не изменяя алгоритмическую сложность операций относительно обычного Dictionary<,>.
не изменяя алгоритмическую сложность операций
Включая само перечисление?
Это очень хороший вопрос, и да, включая само перечисление.
А ссылка на коммит в корку руби, где они это прикрутили, — пойдет?
Ну мне на C# надо всё-таки =)
Фу, ну там же после идеи — на пять минут клавиши потыркать. И это на шарпе, на котором я вообще никогда не писал.
Да и чатжпт с си на шарп переведет на ура.
Скорее всего я не приму такое тестовое задание. Не потому что оно написано при помощи ChatGPT, а потому что оно, скорее всего, будет реализовано неэффективно и недостаточно читаемо.
Большинство идей, с которыми приходят люди при реализации задания, нарушают базовые требования, описанные в задании =)
Кроме того, мне нужен программист, для которого C# это основной язык.
И ChatGPT 4 эту задачу кстати нормально не решает, без получасового втолковывания ему что нужно =)
Это решение возможное, но не самое эффективное, особенно в том месте где будет попытка обеспечить синхронизацию реорганизации вложенного словаря и выкапывание могилок.
Кроме того сработает для value-типов TKey, потому что для них значение по умолчанию -- 0.
Не умеет говорить, да.
Я хотел написать "не сработает", думаю из постановки предложения понятно =)
Есть Nullable<>, но это ещё оверхед и получится что просто так generic-версию не сделать уже, которая будет работать и для reference и для value-типов.
Специализаций в C# просто нет.
Хотя если очень надо — можно проверить в рантайме метаинформацию типа-параметра и принять на её основе решение. Некоторые такие проверки JIT даже умеет сводить до булевых констант, однако это не отменяет необходимости иметь возможность компиляции каждой из веток.
Проще считать что специализаций нет =)
Ну то есть существует нетривиальная механика с специализацией на основе value-типов и сравнением с, собственно, конкретными типами, но это не то чтобы мейнстрим.
Вы не учли что стандартный словарь вам не скажет когда он пересобирается. Тут разве что сравнивать Capacity до и после добавления элемента.
И ещё вы не учли что словарь не пересобирается при уменьшении размера, а потому в некоторых сценариях ваш массив будет состоять из одних только tombstone, и никакой амортизации не выйдет.
Ну и вообще всё как-то сложно, хотя задача удаления элемента из последовательности за O(1) отродясь решалась двусвязными списками. Можно же и тут ими воспользоваться.
Берём Dictionary<K, LinkedListNode<KeyValuePair<K, V>>>, а рядом держим этот самый LinkedList<KeyValuePair<K, V>>. Не самый оптимальный по памяти вариант (ибо много дублирования и лишних объектов), но простой и рабочий без привязки к перебалансировкам словаря.
Если нужно оптимальнее — надо брать реализацию Dictionary, брать реализацию LinkedList, и комбинировать их не полагаясь на средства языка.
Ну, наличие LinkedListNode или аналога — это то что отличает полезный двусвязный список от сделанного для галочки.
Учитывая, что C# делался практиками, было бы странно ожидать второго варианта.
Вот в Java, к примеру, стандартные коллекции делались теоретиками, поэтому там красивая иерархия но сохранить ссылку на ноду нельзя.
В общем это хорошее тестовое задание =)
Показывает кто как разрабатывает, кто на что обращает внимание, и у кого какие критерии "хорошо" и "плохо".
сегодня не выспался
И сразу придумал LinkedHashMap :)
ЗЫ: крутым программистам на 400 тыр тоже задают алгоритмы..... Тоска-пичаль ;(
Я как раз бекендер, и я не очень понимаю какое отношение эта задача имеет к бекенду. 10 лет назад я был готов решать такие задачи хоть проснувшись среди ночи, а сейчас не хочется даже возвращаться к велосипедостроению.
Может, вам лучше попробовать давать тестовое задание кандидатам в бекендеры, которое требует сделать что-нибудь, ну, бекендерское? Хотя это уже не на два часа будет, да.
Эта задача замечательным образом показывает, насколько человек разбирается в структурах данных, умеет читать задание и задавать вопросы (при необходимости), внимателен при реализации, знает устройство целевой платформы и много других вещей.
Я не прошу реализовать на бумаге алгоритм Кнута-Мориса-Пратта или хотя бы нарисовать определение Theta(n) применительно к нашей области. Я прошу знать что такое хэш-таблица и как ей правильно пользоваться. Что такое типы и как ими правильно пользоваться. Как организовать код хотя бы в рамках одного файла. И т.д.
А про "велосипедостроение" -- у этой задачи есть вполне конкретный практический смысл, она лежит в основе эффективного кэша с вытеснением на основе, допустим LRU.
Смотреть на очередную реализацию Hello World WeatherForecastController я не хочу, мне не нужен человек, который умеет успешно копипастить бойлерплейт. Мне нужен программист, досконально разбирающийся в том, что он делает.
Научить программиста КРУД-ить обычно не проблема. Обратное требует существенно больше усилий.
А вам хоть раз в реальном проекте ставилась такая задача?
А про "велосипедостроение" -- у этой задачи есть вполне конкретный практический смысл, она лежит в основе эффективного кэша с вытеснением на основе, допустим LRU.
Самая, что ни на есть, реальная задача из нашего проекта. Это задание выросло именно из решения такой задачи внутри компании.
О отлично. А можете подсказать, сколько времени у вас разраб на это затрекал.
Я не в курсе шарпов, неужели нет решения из коробки? Выше писали, что даже в Руби есть, а он не так популярен кажется.
Был реальный результат от этого кеша? Я понимаю синтетичесские плюсы, но вот в реальном проекте, реальный кеш на словаре, внутри языка я не встречал пользы.
В яндекс ходил. Сейчас просто отказываюсь от них, в том числе и по этой причине.
я код то пишу раз в квартал теперь, какие алгоритмы. Да и зачем когда рядом куча предложений без этих этапов, и чаще всего за более вкусные деньги
Описать принцип хештаблицы, можно в двух словах. Реализовывать библиотечный функции для меня странно
Сорри, что ответил в одном сообщений на обе ветки. У меня ограничение на количество сообщений в час.
я код то пишу раз в квартал теперь, какие алгоритмы
Так если вы не программист больше, о чем речь? Это задание для программистов.
Тот же яндекс не делит тимлида и разработчика, просто добавляет секцию. Как и многие другие компании. У меня все зреет статья о минусах работы тимлидом, л которых я не встречал что бы говорили в открытую. Может и доберусь
Что касается тестового выше, я действительно не понимаю почему нельзя использовать встроенный
https://learn.microsoft.com/en-us/dotnet/api/adaptiveexpressions.lrucache-2?view=botbuilder-dotnet-stable
И в каких кейсах свое решение будет лучше.
"Встроенный" это из малоизвестной библиотеки, в которой реализация кэша примерно через 12 лет после того как мы делали LRUCache? Действительно, почему мы не отправились в будущее?
О, там ещё и LinkedList<T> внутри. И метрик никаких нет. И блокировка через общий монитор. Просто шик, действительно, почему бы его не использовать?
Либо давайте обратно в программисты с нормальным анализом своих предложений, либо оставайтесь в "тимлидах" =)
Ну так и говорите, что ваше тестовое устарело на 12 лет.
Какие то новые требования появились)) Может это еще должно быть развернуто отдельным сервисом) А ну да написать, свой редис тоже вариант.
И это все в рамках тестового)) где вы вообще кого то находите, кто согласится на такую дичь.
А учитывая, что вы писали, что зп у вас не европейские, то видимо это джуны\мидлы- которых никуда больше не берут.
Читаете вы быстро, но только часть комментария.
Реализация LRUCache, которую вы предлагаете, под требования не подходит (и я описал основные претензии), так что можно считать что её нет. Так что 12 лет этой реализации можно сказать не существует.
Про "новые требования" -- никаких новых требований, писать качественный код нужно всегда. Если человек в лоб реализует то что ему предложено -- его уровень это либо слабый middle, либо крепкий junior. Если я буду к каждому заданию писать "нужно учитывать как данные располагаются в памяти", "не нужно выбрасывать исключения, там где это не нужно" и прочие тривиальные вещи, то мне такой разработчик ни к чему. Знание языка и BCL необходимо, но недостаточно, для того чтобы считать себя квалифицированным разработчиком. Понимание устройства структур данных, принципов управления памятью и базовых алгоритмов обязательно. Типовые шаблоны решения задач, правила оформления кода, проектирования API, именования -- тоже обязательны.
Про сервис, кэш и Redis вы придумали сами только что, задача описана как реализация контейнера, не кэша, не сервиса и не Redis.
Можете продолжать петь гимн "айтишнику думать ни к чему, пусть архитектор думает", надеюсь таких просто заменят ChatGPT и они пойдут носить ящики с подгнившими грушами в "Пятёрочке".
Тут нюанс, что я на шарпе писал один проект в жизни, и то баги правил, и взял первый попавшийся. Уверен, что найти решение лучше получится пусть не за 2 минуты, а за 10. Но это не проблема.
Наличие мониторинга и метрик точно должно быть отдельным требованием. Может конечно в шарпе это по другому. Исключение базис тут соглашусь. Вообще странное понимание типовой задачи.
Впрочем зачем я считаю, чужое время и деньги. Это ваше дело.
Я себе такое не могу позволить, ни по своему времени, ни тем более по качеству разработчиков которые мне нужны. Выставлю тестовое останусь без 99% рынка сеньеров, а платить по 500+ что бы сеньер соглашался на тестовое я не могу
В тестовом задании нет ожиданий про метрики. Вы пойдите почитайте тестовое задание, ок? Как прочтёте, так и сразу можете приходить обратно, раньше не надо.
Напомню -- там нужно было реализовать IDictionary<,> с некоторыми особенностями. Кэш не нужно реализовать. Только IDictionary<,>. Вы поняли, я понятно объясняю? Реализовать IDictionary<,>, никакого кэша. Кэш был упомянут в ответ на вопрос о применимости такой структуры данных в реальных задачах, не более того Мы не ожидаем от разработчика реализации кэша. Метрик тоже не надо. Не надо метрик. Мониторинг не требуется, и не ожидается. Нам не нужен IDictionary<,> с метриками и мониторингом.
В предпоследнем вашем сообщении метрики появились.
Эта ветка давно шла, о смысле тестового. Вы сказали смысл в кеше. Дальше пошел разговор про кеш.
я понял, что вы даете алгоритм, просто потому что хочется окей.
Кэш, метрики и мониторинг к тестовому никак не относятся, но вы с этим отказываетесь соглашаться на 100%.
Смысл в том, чтобы посмотреть как человек, которого я нанимаю писать код пишет код, причём в комфортных ему условиях.
Это не алгоритмическая задача, она не требует никаких специфических навыков про проектирование алгоритмов. Никаких пар указателей, деревьев Меркле, поисков чего-то в графе или заполнения "водой" колонок на картинке, динамического программирования, вероятностных структур данных и прочего. Это уровень junior, не более того.
То что человек, который этого не умеет, вешает на себя ярлык "middle" или "senior" говорит о том, что дефицит кадров-таки привёл к чудовищному падению квалификации, и, как следствие, самооправданию толпой неквалифицированных кадров =)
О, там ещё и LinkedList<T> внутри. И метрик никаких нет. И блокировка через общий монитор. Просто шик, действительно, почему бы его не использовать?Что-то мне даже интересно стало, как вообще можно сделать нормальный LRU кеш без связного списка, и как этот связный список можно защитить иначе чем общим монитором...
Связный список можно реализовать не только при помощи ссылок, которые дополнительно расходуют память и нагружают GC.
Гибрид хэш-таблицы и связного списка можно, при условии качественных хэш-функций, разделить хотя бы на несколько регионов, для каждого из которых будет свой монитор. Кроме-того ARC и некоторые другие реализации кэша вообще даже предпочитают несколько LRU-списков внутри одного кэша.
В хеш-таблице с цепочками можно хоть на каждый бакет свой монитор сделать, это понятно. Что делать со связным списком?
Несколько LRU-списков это понятное решение, но его можно "навесить" сверху любой реализации, включая раскритикованную вами выше.
Я думаю что с вопросом про связный список вам стоит что-то прочитать про lock-free структуры данных. Таблично заданный связный список при помощи CAS поддерживать вероятно сложнее, но скорее всего можно. Там многое упирается в вопрос того, какие операции нужны для самого списка. Если это аналог priority queue и нужна только операция TryRemoveMax(), то думаю что там вообще проблем будет немного. Мы обходимся простым сегментированием.
"Навесить" поверх указанной реализации можно, но с учётом того, что она недостаточно эффективна и без учёта блокировки, смысла в этом я не вижу. Я не верю в то что найти плохую чужую реализацию чего-то простого и наворачивать поверх костыли полезнее и эффективнее, чем реализовать это самому. Если бы это было что-то из машинного обучения, даже если кривое, действительно проще взять готовое и его пытаться отлаживать/улучшать. А иначе и до leftpad недалеко...
Вообще если очень хочется про действительно эффективные кэши почитать, и про организацию конкурентного доступа именно к ним, рекомендую взглянуть на очереди записи в Caffeine.
А чем встроенный OrderedDictionary не угодил?
Он не реализует IDictionary<,>.
У майкрософт конечно есть несколько реализаций на с поддержкой генериков, как простая обёртка над уже существующим OrderedDictionary (с очевидным боксингом/анбоксингом), так и на основе Dictionary<,>, но конечно странно, почему нет в API, тикет соответствующий уже 5 лет висит.
Я, конечно же, знаю про их существование. Но тестовое задание всё-таки имеет смысл даже в текущих реалиях. Особенно с учётом того, что некоторые реализации нарушают правило тестового задания с точки зрения сохранения алгоритмической сложности.
OrderedDictionary<,> прямо клялись завезти в .NET 6.0, но так и не завезли.
Он не реализует IDictionary<,>.
public class OrderedDictionary :
System.Collections.IDictionary, Я не туда смотрю?..
Кстати, вы в Яндекс на собеседование не ходили? Думаю вы будете удивлены как часто приходится, по их мнению, искать перевёрнутую часть в массиве =)
В нашем собеседовании есть только реальный код для решения конкретных задач. Иногда упрощённый для простоты понимания и сокращения контекста. Никакой синтетики.
Но, допустим что это была бы синтетическая задача. Считаете ли вы, что программист-"сеньор" может не знать принципов (не деталей) устройства хэш-таблицы или не уметь считать оверхед из-за неоптимальной организации структуры данных?
Устройство хэш-таблицы и алгоритмическую сложность может не уметь максимум стажер. Уже джун — обязан.
Как часто вам в работе пригождается знание того, как именно в хеш-таблице решаются коллизии? Зачем среднему разрабу знать что там внутри, open addressing или что-то еще, может достаточно знать алгоритмическую сложность операций с основными структурами данных в average case?
Это нужно знать постоянно, чтобы не делать int GetHashCode() => 1337;
Для того чтобы не делать int GetHashCode() => 1337 — нет необходимости знать разницу между открытой адресацией и методом цепочек.
Согласен, мой ответ был скорее к части "зачем среднему разрабу знать что там внутри". Если знание только про "open addressing против separate chaining, etc." то оно может быть и не нужно.
Тем не менее для реализации нашего тестового задания качественно скорее всего придётся узнать =)
Мне интересно, неужели "среднему разрабу" настолько неинтересно что и как происходит внутри? Культ антиинтеллектуализма как результат избыточного количества "свежей крови" в IT?
Да нет, просто разных вещей в которых можно покопаться — огромное количество, и хеш-таблицы в этом множестве — самые бесполезные.
Даже ваше тестовое задание можно решить просто скомбинировав стандартные коллекции, пусть это и не будет самое оптимальное решение — всё же оно будет оптимальным с точностью до константы.
Про интересность ничего не могу сказать, это очень субъективно.
Про стандартные коллекции -- конечно можно, но я такое решение не принимаю, потому что все известные мне варианты нагружают сборщик мусора сверх меры (потому что создают как минимум по одному reference-объекту на каждую пару ключ-значение).
Мы всё-таки работаем в реальном мире, а не сидим на курсе товарища Рафгардена, поэтому если мне кто-то говорит что "вставка и удаление за O(1)", но я вижу что таблица для 100к объектов создаёт не 4 объекта в куче, а 100004, то нам с таким разработчиком не по пути.
Смотрю на Хабре, судя по плюсам, процветает торжество посредственности. То что считается базовыми вещами (алгоритмы, структуры данных) презирается "средними разрабами", и находит существенное коллективное одобрение.
А реализация требуется с нуля или возможен вариант, когда реализация собеседываемого внутри себя содержит Dictionary<,> и, например, List<> ссылок на элементы?
List не пойдет: вы либо remove просадите по алгоритмической сложности, либо он у вас после года аптайма всю память выжрет.
Тов.@cupraerниже уже ответил.
перечисление его элементов сохраняло порядок, соответствующий порядку вставки
Т.е. foreach(var v in dict.Values) должен выдавать порядок, соответствующий порядку вставки ?
Всё так, только почему всего 400?)
От поиска коллег в этом году плакать хочется (бэкендера ищу). Ноль любопытства, тестовое делать не буду, кода чтобы показать нет, потому что негоже работать после работы, хочу 400к. На собеседовании основная фраза «я точно не помню».
В этом году условно-активно ищем работу, где-то с марта.
Любопытства уже нет - все конторы одинаковые после первых 9, после 15 сделанных тестовых - нет и желания снова писать код который скорее всего даже не посмотрят, в вакансиях с заявленными 120-240к - с порога говорят что на испытательном 15к + 45к премией если все понравится и потом 30к+60к премией если "горите энтузиазмом и готовы делать для фирмы все что надо даже овертайм"©, а "вот через год или если вы нас поразите и сможете взять на себя работу которую выполняет весь отдел"....
На собесах у нас много ответов "я точно не помню", т.к. много вопросов которые при реальной разработке (а не на бумажке) автоматом всплывут в подсказках или и так будут ясны или редки и могут быть уточнены при необходимости (имя папки с ресурсами, горячие клавиши для отладки, порядок аргументов, количество байт на сектор в фат32 по дефолту и т.д.).
много вопросов которые при реальной разработке (а не на бумажке) автоматом всплывут
Это верно. Но если при одинаковых прочих условиях, если один ничего не помнит, а другой помнит вообще всё, лучше выбрать второго. Помнить всё очень полезный навык, а плохая память может создать проблем на ровном месте и себе и заказчику.
Тесла обладал «фотографической памятью» и редко пользовался необходимостью записывать что-либо. Говорят, что в 1885 году, когда сгорела его лаборатория, он был в состоянии по памяти восстановить многие из своих изобретений. ... ...
Мы говорили именно о тех вещах, которые при реальной разработке помнить не нужно в принципе. Функцию помнить надо, а вот порядок аргументов к ней в любом ИДЕ автоматом всплывет.
Шерлок Холмс: Но я-то не каждый, Ватсон, поймите: человеческий мозг — это пустой чердак, куда можно набить всё, что угодно. Дурак так и делает: тащит туда нужное и ненужное. И наконец наступает момент, когда самую необходимую вещь туда уже не запихнёшь. Или она запрятана так далеко, что ее не достанешь. Я же делаю всё по-другому. В моём чердаке только необходимые мне инструменты. Их много, но они в идеальном порядке и всегда под рукой.
В моём чердаке только необходимые мне инструменты. Их много, но они в идеальном порядке и всегда под рукой.
А далее чего не процитировали, там как-раз о феноменальной памяти:
Шерлок Холмс: А Вы, Ватсон, можете отличить грязь на Ридженс-стрит от грязи на Пиккадилли? Или пепел гаванской сигары от пепла манильской? Или можете мне сказать, что написано в третьем параграфе «Уложения о наказаниях Британской империи»? Можете?
Я как-раз помню этот диалог ))
Вот только память работает не так, как описывал Конан Дойль, хотя рациональное звено у него есть. Но он больше упирал на энциклопедичность знаний, что сейчас не требуется с наличием электронных справочников и распознавателей.
А вы сами Тесла?
Может вы как-то отбираете однотипные конторы? Суммы уж больно странные.
У нас тестовый период оплачивается на 100%, справочных знаний не требуем на интервью, весь присланный код я смотрю и пишу отзыв, обычно на несколько абзацев.
А про тестовое указано в вакансии?
Так она и будет основной фразой на собеседовании -- все привыкли всё гуглить, информации сейчас слишком много чтобы всё помнить.
Не поверите, лет 10 в моей жизни занимало PHP программирование, но потом перешел строго в математику, и сейчас спустя 20 лет спроси меня про GET/POST отвечу именно «я точно не помню». При том, что с новыми инструментами приходится разбираться за два три часа и вполне удается их освоить. А вот это вот ваше все из разряда "ой да ты ничего не знаешь", оно вообще для кого? Сейчас тенденции, выучил-использовал-забыл. В одном могу согласиться - люди воротят нос от работы руками и головой. Но вот это вот нытье по поводу "кандидат не кандидат" тоже под стать.
Также мне не совсем понятны ваши претензии, если в половине фирм, к которым я обращался последние два года, тесты (видимо на какую-то психологическую совместимость) с вопросами из разряда "на кого вы переложите ответственность, если ничего не делали на работе?".
Но самое главное это то, что ноги у всего этого растут из того, что на хабре разбиралось лет 10 назад. Никто банально не готовит себе кандидатов, и не устраивает испытательные сроки, всем подавай готовых 20-летних с 40-летним опытом работы.
Как бывающий регулярно с обоих сторон… люди, принимающие решения, часто сами не знают чего хотят. Вот потому так и выходит.
То начальство хочет с горящими глазами, дообучим, но отвергает хороших кандидатов, и в результате заканчивается да хоть кого-нибудь. Кто-нибудь, разумеется, работает как-нибудь.
То собеседующие требуют присобленность к их стеку и их костылям — WAT? — и хорошо если не доскональное знание грабель, на которые они уже наступили. Разумеется, самое высокое матожидание тут будет у я точно не помню. Могу уточнить — да. Но, почему-то, это считается совсем табу и черная метка.
Вот так и получается что есть.
негоже работать после работы
А что в этом плохого-то? :) А если речь про пет-проекты, то это не работа...
Так пусть пет-проекты и показывают, у нас переработок никаких нет.
Ну а тут уже другой момент вступает в силу. Мне вот часто хочется что-то свое доделать/допилить, хотелок много, интересно и так далее... Но после работы уже просто становится лень. И если в студенческие годы я мог сидеть после учебы по ночам с красными глазами, то сейчас после такого скорее всего уже на следующуй день будет не особо хорошо :)
Это я к чему... Не обязательно соискатель, который не может показать пет-проект, не хочет его писать. А показать рабочий код NDA не позволяет.
На собеседовании основная фраза «я точно не помню».
Прекрасная фраза, кстати, если человек после неё достаточно достоверно описывает суть того, о чём говорит. Специфику всегда проще проверить в доке, зная, какие слова вбивать в гугл, чтобы ссылку на доку получить.
кода чтобы показать нет, потому что негоже работать после работы
Совершенно здоровая позиция! Я вот люблю программировать, но люблю ещё много других вещей, потому его хватает на работе.
хочу 400к
Зарплата нормального миддла, что не так?
тестовое делать не буду
Потому что в другой конторе 400к дадут без тестового, всё правильно :)
Ноль любопытства
Вот это единственный реально грустный звоночек, но тут вопрос ещё в том, как именно вы к такому выводу пришли.
Фраза прекрасная, если она не повторяется примерно 50 раз за час.
Я про локальный рынок если что.
Человека, который на глобальном рынке ищет работу мне привлечь нечем и я про это писал ниже :) В России 400 миддлам вроде как не платят.
«Тестовое делать не буду, код не покажу, лайвкодинг это стресс, возьмите меня так, я хороший :)
А, и алгоритмы это заумь ненужная, и детали спрашивать нельзя, я всё в Гугле гляну или книжку с кабаном ещё раз прочту, а то забылась что-то.»
К выводу о нелюбопытности пришёл просто, любое отступление от привычной модели разработки в обсуждении вызывает ступор, а просьба предложить несколько вариантов — ужас.
В России 400 миддлам вроде как не платят.
Ну, год назад платили (опыт разных проверенных людей, включая мой личный, но не ограничиваясь им). Вроде пока не перестали тем, кто не уехал.
«Тестовое делать не буду, код не покажу, лайвкодинг это стресс, возьмите меня так, я хороший :)
Ну вот все три разом это проблема, да :)
Делать тестовое это действительно моветон для меня. Чаще всего оно ничем не заканчивается, никакой обратной связи, кроме как вы нам не подходите, мы решили пойти за ручку с кем-то другим. Делаю если это не занимает много времени (сделать код ревью, решить задачку на литкоде), полезно (посмотреть на новый фреймворк, реализовать что-то интересное). В остальном это похоже на работу без денег и перспектив.
Работать после работы это кому как. Я предпочитаю работать на реальной работе, а свободное время тратить на чтение или обучение. Мой код в репозиторий это чаще всего код для каких-то курсов с практикой. Или те же тестовые задания.
Про деньги скажу что инфляция влияет на требования по ЗП. Хоть и в моем регионе не такой большой потолок, но цены растут постоянно, абсолютно на всё. Местные работодатели не могут конкурировать с предложениями на удалёнке, при этом мне действительно хочется помогать компаниям в моём регионе. И тут возникает недопонимание как мне кажется. Работник сравнивает предложения на уровне всего мира, а работодатель на уровне региона.
И насчёт последнего, тут зависит от вопросов. Как-то меня спросили про уровни оси, которые я только в универе помнил, а в реальной жизни со всеми уровнями работать не приходится, да и не нужно, это компетенция разных специалистов. Конкретные вещи помнить сложно, да и зачем, когда всё это гуглится. Вот и получается, что работодатель спрашивает формальные знания, а кандидат считает это необязательным. Как говорится вам шашечки или ехать надо. Кто-то может выучить фреймворк идеально, но в реальной жизни пишет такой лапшекод, что потом никто не разгребет. А формально он хороший кандидат, всё знает на зубок.
Как кандидата, меня напрягает конкретика на собеседованиях. Но скорее рынок такой. Большое количество соискателей вынуждает работодателей оптимизировать процесс найма и формализовать требования.
Лет через 5 сможете выбирать лучшего из толпы горящих глазами, для кого ИТ - это его жизнь...
Ох уж эти влажные фантазии. Так было лет 15 назад и раньше. Но вряд ли такое повторится в ближайшем будущем. Отрасль слишком сильно разрослась, людей с горящих глазами тупо не хватает, чтобы покрыть хотя бы 20% спроса.
С программистами то же самое. Раньше мы разбирались как всё работает на уровне ассемблера, как компилятор проводит оптимизации, как работают виртуальные машины и сборщики мусора. Сейчас же такие вопросы на собеседовании де-факто под запретом, потому что с такими вопросами вы вообще никого не наймёте. Сейчас люди на серьёзных щах начинают изучать программирование с Python и JavaScript 🤦🏻♂️
> Сейчас же такие вопросы на собеседовании де-факто под запретом, потому что с такими вопросами вы вообще никого не наймёте.
вероятно объективное явление, требования снижаются min с середины 90х, это если в среднем по больнице, причина проста - sw все больше становится ширпотребом, а его производство приближается к конвейерному у форда, где не требуется знать физики и даже конструкции двигателя, но четко уметь крутить гайки своим интрументом с большой скоростью, снова в среднем по больнице, конечно есть интересные проекты и хорошие фирмы, но относительно мало, это про обстановку вне россии - человеку со средними способностями в ИТ будет все труднее, статус не очень, перспектив меньше, делайте свои выводы, про россию все еще сложнее, поэтому не берусь
Проблема в том, что в IT постоянно срабатывает закон протекающих абстракций. Поэтому конвейерный подход пока слабо работает.
человеку со средними способностями в ИТ будет все труднее
Вы как-то сами себе противоречите. Ведь при конвейерном подходе как раз понадобится куча людей со средними способностями
> при конвейерном подходе как раз понадобится куча людей со средними способностями
со средними способностями, но возможно дешевле, со статусом примерно офисной мебели, заменяемой по мере износа, противоречия нет, такова "c’est la vie"
Чем больше будет людей со средними способностями будет нанято, тем больше будут востребованы те кто сможет сказать какие именно гайки надо крутить.
А, вы в смысле, что их труд будет цениться меньше, чем сейчас. С этим я согласен. Осталось только понять, сможем ли мы выстроить конвейерное производство ПО в этом столетии. Конвейер хорош там, где надо массово изготавливать одинаковые изделия. Но в IT для таких случаев изначально Copy-Paste есть. Вот только пока кол-во уникальных изделий всё ещё растёт в геометрической прогрессии.
> больше будут востребованы те кто сможет сказать какие именно гайки надо крутить
конечно, однако девальвация вероятно вверх по цепочке распространяется, ширпотреб как правило low margin имеет, значит бухгалтера на всех экономить должны, кроме самых-самых,
> сможем ли мы выстроить конвейерное производство ...
конвейер это прежде всего разделение труда на простые операции, в современной интерпретации это frameworks, + max переиспользование кода, когда требуется главным образом интеграция, адаптация, настройка, и пр.
адаптация, настройка, и пр.
По-моему вы не очень представляете конвейерное производство. Там уж точно нет места таким явлениям, как адаптация и настройка.
До запуска линии возможны такие этапы, да. Но как только конвейер запущен, уже никаких адаптаций.
ну и ладно, скорее Вы меня не понимаете,
важно следущее - "конвейер это прежде всего разделение труда на простые операции", типа простой и понятный пример технологии, конечно у форда на конвейере адаптаций нет (в теории), но для sw это такой же этап сборки, как и закручивание гаек у форда, хотя это не значит что при сборке sw системы буквально используются болты и гайки, просто max используются готовые компоненты, даже если с точки зрения качества изделия это компромисс :)
Сейчас люди на серьёзных щах начинают изучать программирование с Python и JavaScript 🤦🏻♂️
а что не так с питоном для вхождения ? Мне кажется, уж лучше чем ассемблер/бейсик/с/с++, который нам давали в школе/универе
а что не так с питоном для вхождения ?
Да всё с ним не так.
Во-первых, это дикий винегрет из парадигм, ни одна из которых не реализована нормально.
Во-вторых, непоследовательность стандартной библиотеки (почему str.lower(), но str[::-1], а не str.reverse()? и т.д. и т.п.)
В-третьих, форматирование определяет логику выполнения (т.е. на самом базом уровне нарушена концептуальная чистота)
В-четвёртых, GIL.
И, мне кажется, что этот список можно продолжать очень-очень долго. Это объективно так себе ЯП. Путанный, сложный, непоследовательный. На мой взгляд, один из худших вариантов для знакомства с программированием.
Да, он в целом был хорош как замена Perl для простеньких скриптов автоматизации (потому что к Perl вопросов было не меньше). Но мы свернули явно куда-то не туда, когда расширили его область применения.
и все равно в качестве первого языка лучше чем C, С++, BASIC, Perl, PHP и список можно продолжать долго )
Согласен. Список не особо подходящих для обучения программированию языков можно большой составить. Хотя C с натяжкой я могу представить в этой роли даже сейчас. Ну и VB.NET, пожалуй, тоже получше для этих целей будет, чем Python. Про оригинальный Basic я уже очень давно не слышал. Он ещё существует?
А Go пойдёт как первый?
Я пишу на Go уже три года, но моим изначальным ЯП был PHP.
Считаю что Си-подобные языки с динамической типизаций подходят для обучения лучше всего.
Объясню почему.
Многие начинающие, которых реально прёт программирование, сосредотачиваются на реализации и решении какой-то конкретной проблемы. Соответственно все особенности в виде строгой типизации, сборки, запуска, деплоя и т.п. сильно стопорят прогресс и во многих случаях могут отбить желание развиваться дальше.
Чем легче реализовать задумку и запустить её, тем лучше технология подойдёт для обучения.
Остальное уже освоится со временем в процессе чтения и углубления.
Я бы не советовал. Там авторы языка как-будто специально сделали его запутанным, несмотря на позиционирование, как простого языка. Есть хорошая статья на эту тему.
В ГО по факту очень сложно дается начальный дебаг.
Учится по го — плохая идея. Потом получаются люди, которые не умеют дебажить и не понимают где проблемы в коде.
Лучше всего имхо было по паскалю, но его сейчас никто не использует.
Потому, имхо, питон реально лучшая альтернатива, он хотя бы читаем новичком.
И, мне кажется, что этот список можно продолжать очень-очень долго. Это объективно так себе ЯП. Путанный, сложный, непоследовательный. На мой взгляд, один из худших вариантов для знакомства с программированием.
а с++ прямой, простой и последовательный ?
Нет, C++ тоже не особо подходит на роль первого языка.
Я вот тут перечислял из какого списка языков, на мой взгляд, стоит выбирать для начала.
C лучше. Серьёзно, C очень прост. Потом Java или C#. Или наоборот. Python хорош только для обучения неразрабочиков: статическая типизация и куча странностей в стандартной библиотеке. Бонусом - иллюзия потокобезопасности (Python непотокобезопасен в общем случае!)
Каждый раз, как за С - ощущение как будто на механику пересел после автомата, еще и лошадей там где-то под капотом периодически подстегивать надо.
Так для начала обучения самое то. Сложных концепций нет, только чистый код. Легко перелезать на C# или Java.
В С есть арифметика указателей, ручное управление памятью, макросы, отсутствует нормальное управление зависимостями, сообщения об ошибках малоинформативны. Лучше сразу начинать с чего-то, что более-менее широко сейчас используется, чем тратить время на архаичный С.
Для начала обучения? O_o
При том, что для обычной hello-world-программы надо бы объяснить (а не сказать "'это мы изучим позже") 5-6 вещей, которые во многих других языках объяснять не надо (они там тоже могут быть, но позже, когда реально понадобятся).
В С сложных концепций нет
#include <stdio.h>
int main() {
printf("%d\n", 5);
return 0;
} Хм интересно вы за 1 академическую пару успеете объяснить полному новичку в программировании что и почему делается так в этой программе?
Чего тут целую пару то объяснять? Или полный новичок в программировании заодно и как юзер компьютера тоже новичок и не знает даже, что программы код возврата имеют? Ну ok, можно этой теме 5 минут уделить.
#include <stdio.h>
Добавляет в код возможность вызова стандартных (std) процедур для работы с IO. В детали заголовочных файлов можно не вдаваться, пока не понадобится свой собственный написать.
printf("%d\n", 5)
Выводит в STDOUT форматированную строку, %d применяется для подстановки в строку целых чисел в десятичной системе. Про "\n" тоже надо рассказывать? У нас настолько нулёвый нуб, что ни одного урока информатики в школе не посещал?
main()
Главная функция, которая является точкой входа для начала выполнения скомпилированной программы
Так вот тут и проблема - если человек не новичок в программировании, понимает как примерно все работает в простых языках типа Паскаля, что такое переменные, одно-двумерные массивы, оператор присваивания, циклы, условия, функции, передача параметров по значению и ссылке, и может как-то это минимально на практике применить, то дальше идти куда-то гораздо проще, хоть в ассемблер, хоть повышать абстракции - ООП, ФП и т.п.
Если же всей этой базы нет, а все с нуля, то вот тут и проблема. Просто все уже забыли как начинали. Я вот вспомнил, как я в матшколе в 9-м классе Алгол изучал. Я вообще ничего не понимал, хотя вроде и не дурак был. Где-то за первое полугодие более менее в голове уложилось.
А иначе будет куча какой-то магии везде.
Пока ваш ученик "прилежная маша-отличница" делает записи в тетрадку и когда нужно что-то делать повторяет по бумажке - всё ок.
Как только вы получите живого и любознательного ученика которому надо понять прежде чем делать вам придётся объяснять "почему". А при объяснении почему вы столкнётесь с тем, что в С почти всё кишками наружу (нет уровня абстракции между представлением в языке и поддержкой в ОС).
#include
А зачем там стоит знак "#" почему бы не написать просто include?
(почему мы пишем имя файла, а не подуля - от более продвинутого польозателя).
Кажется тут вам надо начать рассказывать про препроцессор и линкер.
Выводит в STDOUT форматированную строку, %d применяется для подстановки в строку целых чисел в десятичной системе.
Ох зря вы про stdout начали - кажется это отдельная лекция про устройстов ОС на пол-пары минимум.
Ну это мягко говоря не совсем так. Целых (в смысле int) знаковых. А для long \ short - свои спецификаторы. А почему это работает и именно так? Кажется вам придётся рассказать про ABI вызовов языка Си (как вы увлекательно при вызове кладёте аргументы на стек, а потом достаёте их и как вы в процессе парсинга строки с этими аргументами работаете).
Вот в Паскале вы можете сказать "компиляторная магия" (компилятор знает тип числа и генерирует для вас код) на Python - всё есть объект, имплементирующий специальный метод __str_, в Rust - специальный трэйт Debug \ Show...
int main()
...
return 0
Для "совсем 0" вам придётся рассказать, как программа взаимодействует с ОС. И подозреваю, что обычный выпускник 11 класса может этого не знать.
Для "не совсем 0" - тоже будет пара сюрпризов с упоминанием ф-ии __start_ и стандартной библиотеки (почему возвращаемый main тип не совпадает с $? в баше?).
некоторые вещи при первичном обучении вполне допустимо давать в виде "магии". Да, "в начале нужно записать #инклуд, и название функции мэйн(). почему так — мы будем разбирать чуть позже, а пока давйте состредоточимся на содержимом этой функции".
Хорошее правило написания документации - не пишите "что" пишите "почему".
Преподавать "что без почему" для #include и main() - не смертельно но плохо (нас не научили C, а это был второй язык - отчасти поэтому).
А вот для printf("") - это же epic fail. Это же реально магия.
Везде надо передавать либо точноый тип, либо приводимый, либо (void *).
А тут вы прямо передаёте произвольный тип в функцию, функция "понимает". Как это вообще сделано? Где границы применимости? Как это использовать?....
Вы сами в детали закапываетесь и почему-то утверждаете, что это необходимая часть вводных лекций. Я читал книги по десяткам языков программирования. И знаете, везде есть пример аля "Hello World" в начале, но нигде нет главы про устройство ОС, хотя всё это везде печатается в STDOUT.
И форматирование строки через модификаторы - тоже почти везде есть. И всем хватает таблички с перечислением самых популярных. Никто не отвлекается на отдельную главу про то, как они работают.
Я не говорю, что плохо интересоваться этими вопросами, но в целом для обучения программированию можно обойтись и без ответов на них. И ничего ужасного от этого не случится.
Плохая документация объясняет "что", хорошая "почему".
Вы предлагаете писать учебник, как плохую документацию.
Из личного опыта - в 10 классе я не понял С, как второй ЯП (первым был Pascal) ИМХО ровно потому, что нам объясняли "что" без "зачем" (в целом я думаю что вся наша компьютерная подгруппа не поняла - во всяком случае никто им не стал пользоваться как ходовым инструментом). Потом пришло время - и понял.
При этом есть места, где это будет "умеренно плохо" (define \ main) а есть места где очень плохо (printf); include - где-то на границе.
Т.е. с define \ main можно поступить на первых порах как с "отрезанием сосисочных жёпок" (запомните и делайте так, потом объясним). Хотя делать как обезьянака потому, что так принято - это прям супер не по программистски.
А вот с printf - вы просто создаёте у ученика диссонанс и противоречие.
Вот вы объяснили типы, аргументы и параметры ф-ии, приведение типов.
И тут делаете printf, которая просто противоречит всему сказанному. Человек хочет разобраться - просто потому, что у него хорошее программистское мышление а ему "опа не твоего ума дело или это займёт пару лекций".
У нас настолько нулёвый нуб, что ни одного урока информатики в школе не посещал?
(1) Разве речь шла не о том, с чего начинать обучение программированию?
(2) Кое-где в школах на уроках информатики только ворд-эксель изучали, а про код возврата и преподаватели не слышали.
(Ну, у меня первым относительно доступным компьютером был калькулятор МК-61, но рекомендовать подобное можно только для сравнения: "вот так делать неудобно, а вот более понятный способ".
Для калькулятора надо было программу сначала более понятным способом писать (блок-схемы, язык Ершова, да тот же Паскаль в конце концов (для которого не было компьютера)).)
Разве речь шла не о том, с чего начинать обучение программированию?
Ну, как бы знание основ информатики - это пререквизит к началу обучения программированию. Т.е. знать про кодировки символов, двоичную и шестнадцатеричную системы счисления, про процессы ОС, про стандартный ввод/вывод и т.п. вполне можно до начала обучения программированию.
И, строго говоря, все эти темы не являются частью программирования, они просто используются во время программирования, ну как английский алфавит. Мы ж не говорим, что надо с изучения алфавита обучение программированию начинать?
Ровно все эти концепции есть в других языках, разве что в скриптовых их можно объяснять не на первой, а на второй паре.
Они бесспорно есть. Вот только вопрос не в том, на какой паре их можно объяснить, а в том, сколько можно без них обходиться.
Новичку в первую очередь надо дать понимание последовательного выполнения операторов, затем - ветвлений и циклов. И до этого момента можно даже без понятия функции обойтись.
В Паскале аналогичная программа не в пример проще:begin writeln(5) end.
Ровно все эти концепции есть в других языках,
Очень не так. Там они спрятаны за абстракцией объекта \ модуля. А в Си - машинерия наружу.
И да я посмотрю как вы побъясните C call ABI (почему работает printf("%d %lu", int_var, long_u_var)) в на второй паре.
(ответил чуть продробнее выше)
https://habr.com/ru/articles/739452/comments/#comment_25649448
Ну это уже абсурд пошёл с выдумыванием абстрактных и нереалистичных ситуаций.
А зачем там стоит знак "#" почему бы не написать просто include?
А чем отличаются str и byte отличаются в python? А что такое юникод? А зачем мы всё оборачиваем в class в java? А зачем нужно всё оборачивать в скобки и ставить точки с запятыми? А что такое 1.2e-9? А почему нельзя складывать "1" с 1? А почему переменная не изменяется, если передать её в функцию? Вопросы, вопросы, вопросы.
Ладно, это ещё смешнее:
Кажется вам придётся рассказать про ABI вызовов языка Си
Чтобы рассказать про форматирование в Си нужно рассказать знать про ABI, ага. Нужно ли знать про кишки VM .NET для объяснения форматирования в C#?
Это бы всё работало, если бы я не видел как люди учатся программировать на C и C++ с нуля: вполне нормально.
Ну что, раз вы понимаете как рассказывать про форматирование без С-ABI, то объясните почему оно так работает, почему мне надо писать те или иные значки и как "компилятор" понимает что и как подставить в код:
почему работает printf("%d %lu", int_var, long_u_var))
ПС
Ну и прикол с Python в том, что в принципе за первую половину пары можно рассказать почти всё про утиную типизацию:
- программа в Python выполняется построчно интерпретатором.
- любая переменная в Python это объект
- интерпретатор понимает (знает в runtime) какие функции есть у объекта.
- когда вы делаете что угодно с объектом, это почти всегда значит, что интерпретатор берёт у объекта соответствующую функцию и выполняет её (или обрабатывает ситуацию отсутствия функции - почти всегда это исклюение).
> Нужно ли знать про кишки VM .NET для объяснения форматирования в C#?
Зачем вы задаёте этот вопрос, если я уже объяснял в чём разница в этом месте между C и условными Python и Rust?
Для С# - надо понимать как VM смотрит на наличие метода у объекта и дёргает его, а для C - аналогичные объяснения потребуют солидную такую часть курса "архитектура ЭВМ" прочитать. Что в рамках изучения первого языка малореально.
ПС
И да если кто-то смог выучиться в тяжёлых и неподходящих условиях не непонятном уровне (а вот вся наша компьютерная подгруппа не смогла нормально выучить С как второй язык в 10 классе - ровно потому, что мы не получали нормальный объяснений "как" и "почему") - это не значит, и всех надо мучить преподавая в таких же неподходящих условиях.
программа в Python выполняется построчно интерпретатором
Т.е. вызов метода не может идти раньше его определения?
любая переменная в Python это объект
А что такое объект? Кажется, вы попали на 2-3 лекции про ООП
интерпретатор понимает (знает в runtime) какие функции есть у объекта.
Как он это понимает? А где хранится список функций объекта? А он может поменяться?
когда вы делаете что угодно с объектом, это почти всегда значит, что интерпретатор берёт у объекта соответствующую функцию и выполняет её (или обрабатывает ситуацию отсутствия функции - почти всегда это исклюение).
А почему "почти всегда", а не всегда? Кажется, я тут что-то написал и не вижу как интерпретатор берёт у моего объекта функцию. Как это почувствовать?)
P.S. Как все эти пункты связаны с утиной типизацией?
Вот вы действительно не понимаете того, что вы пишите? Почему в С надо объяснять дольше и неудобнее одни и те же концепции?
Всё просто: в ООП-языке вы попали на 2-3 первых лекции по ООП. Дальше ваши студенты знают что такое ООП и вы говорите (ну это так устроен объект в нашем ООП языке). И есть куча способов изучать ЯП и ООП параллельно без проблем.
А в случае С вы попадаете на середину курса "архитектуры ЭВМ". И какого-то хорошего способа изучения С, без отвлечения на посторонние темы (или оставления студентов без объяснения) я не вижу.
P.S. Как все эти пункты связаны с утиной типизацией?
Э.. а я точно с квалифицированным программистом разговариваю?
Для более традиционных систем типизации объяснения будут "(почти всегда) тип удовлетворяет ограничениям на аргумент функции", в то время как для утиной типизации "у объекта есть функция с именем".
Несколько разные объясниня, не находите?
Я просто зеркалю ваши вопросы по C. Поверьте, с вашим подходом доебаться до Python гораздо проще, потому что принципы его работы на порядок сложнее C.
Всё просто: в ООП-языке вы попали на 2-3 первых лекции по ООП.
Python не является ОО-языком.
Несколько разные объясниня, не находите?
Я нахожу странной манеру ставить двоеточие и потом перечислять пункты никак не связанные с определением того, что было до двоеточия)
Я просто зеркалю ваши вопросы по C.
При этом совершенно игнорируя суть вопроса (если мы хотим донести до людей "почему"):
- для обучения С вам надо ссылать на то, чего студенты ещё не знают (потому, что это середина курса "архитектура ЭВМ"
- для обучения Python это ссылка на только что пройденное начало "курса ООП".
Python не является ОО-языком (а Волга впадает в Каспийское море).
Ну и что? На объяснение разницы уйдёт пара минут. И оно будет относится к уже понятным вещам (в то время как при объяснении С вам постоянно придётся ссылаться на непонятные вещи).
ПС
> это я просто косплею ваши...
Косплеите неконструктивно.
В Си например из одного #define можно квиз устроить - но разумный человек найдёт компромис, что для обучения достаточно самых простых объяснений, с чем я и согласился. Вы же пытаетесь быть максимально неудобным в каждом вопросе - в итоге вместо "сильной позиции" вы показываете себя "неудобным собеседником".
Если у вас действительно есть хорошие контраргументы - вопросы, задайте пожалуйста их. А "брутфорс банальзыми вопросами" ещё у Хаджи Насреддина высмеивался как форма демагогии.
Ну и что? На объяснение разницы уйдёт пара минут.
Да, блин, оно уйдёт пара минут, когда у вас Python 5-й ЯП.
А если брать такого же околонулёвого новичка и задаваться целью, чтобы он понял почему Python такой какой он есть, тут минимум год понадобится и то вряд ли мы добьёмся этой цели в общем случае. Другое дело, что это для программирования вовсе необязательно это всё понимать, что в случае с Python, что в случае с C. В этом и есть суть вопроса.
Вы же пытаетесь быть максимально неудобным в каждом вопросе
Я ж говорю, отзеркалил вашу манеру 1-в-1. Не очень приятно, да?
А то у вас двойные стандарты какие-то. Как только речь не о С, так сразу все "почему" сразу закончились. Хотя по факту их за пределами С становится ещё в 100 раз больше.
А в Си - машинерия наружу.
Напомнило
А с Go начать можно?
ещë в первом классе
Мне кажется что начинать изучать программирование с Python -- не проблема.
Я, если что, начинал изучать программирование с машинных кодов на отечественном недо-клоне PDP-11 по очень низкокачественно отксерокопированному "руководству системного программиста", но не думаю что стоит испытывать такой явный снобизм в отношении разработчиков, чей путь обошёлся без изучения схем косвенной адресации в не слишком ныне популярных системах =)
Да дело не в машкодах и не в снобизме. А в том, что на кривом фундаменте потом тяжело будет переучиваться. Я ж не говорю, что все с ассемблера или с С должны начинать. Просто стоит взять язык, который внутренне не противоречив, и нормально реализует ООП или ФП, кому что ближе. Изучить сначала его, а потом уже можно за любой язык браться. Так хотя бы каши в голове не будет.
"Внутренне не противоречив" -- а такие не-академические есть вообще в природе?
"Внутренне не противоречив" -- а такие не-академические есть вообще в природе?
Ну, C в известном смысле таков: вот пистолет, ногу свою приносить, велкам!
Ну, ничто не идеально, конечно. Но есть масса вполне последовательных в своих идеях языков: C#, F#, Elixir, Haskell, Kotlin, Rocket, Ruby, Rust.
Любой из них для обучения программированию будет на порядок лучше, чем Python или JavaScript.
На самом деле JavaScript вполне последователен (почти как Lisp), просто это не бросается в глаза. Там совсем немного концепций (объекты-хэши, замыкания, наследование от прототипа), на которые наверчено всётальное.
Проблема JavaScript в слабой типизации, для новичков это очень плохо. Я бы на самом деле советовал начинать с языков с сильной статической типизацией. Потом переходить к языкам с сильной динамической. А слабую оставить на последнюю очередь, когда уже личный профессиональный фундамент сформируется.
В остальном вы правы, но совсем немного концепций там было 15 лет назад. А сейчас чего только поверх них ни накрутили. Да и event-loop далеко не самая лучшая концепция для языка общего назначения. Он был классным решением, чтобы снежинки поверх страницы рисовать, но не сейчас.
Ну, кто-то может и остановиться. А у кого-то профессиональное любопытство продолжится. Ведь для разных задач разные языки лучше подходят. Нет одного универсального.
Ну, например, для backend разработки сильная динамическая типизация с опциональными type-аннотациями гораздо лучше подходит. Time-to-market от этого значительно улучшается.
Значительно это на сколько?
Что такое нетипизированные языки? Мы как-то резко перешли на обсуждение ассемблера или что?
Я просто стараюсь следить за чистотой используемых терминов. Типы — это то, что можно проверить статически
А разве типы когда-либо подобным свойством обладали? О_о
У вас какие-то свои термины, тип данных всегда был множеством возможных значений и применимых к ним операций. Нет никаких концептуальных проблем проверять его динамически, как и вообще не проверять.
Да легко: проверяем что значение (не терм, термы у нас в исходнике) — функция, после чего приводим её к типу Int → Int путём добавления отложенных проверок на аргумент и возвращаемое значение.
А вообще, динамическая система типов не обязана иметь тип Int → Int. К примеру, в том же JavaScript официально всего 8 типов данных.
А при чём тут вообще сайд-эффекты?
Для всего этого существуют практики защитного программирования, а также здравый смысл.
Тот самый, который говорит что запись в БД нужно проводить в транзакции, а сообщение пользователю отсылать уже после коммита.
если вы в БД положили вместо суммы двух чисел их конкатенацию как строк?
При сильной (пусть и динамической) типизации такое не прокатит.
Вот едете вы на машине или летите на самолёте, а там вдруг сработала динамическая проверка, что в одном месте случайно футы, а в другом — метры.
Подобная проверка при нормальных практиках программирования должна была упасть ещё на испытательном полёте, а то и вовсе в симуляции.
Как мы с бекенда переместились в бортовой компьютер? Я вас теперь как мастера переобувания запомню))
Впрочем, ваш пример пока не критичный, раз уж единицы измерения известны, то мы просто конвертнули в общую СИ и едем дальше.
Это у вас ваш рантайм-чекер должен знать про ваши единицы измерения
В чём проблема, раз уж мы по бизнес-требованием знаем, что они бывают разные?
Это всё, конечно, куда проще и TTMнее, чем просто, блин, использовать типы.
Когда требования постоянно меняются, то да проще и ТТМнее. Опять же, хочется верить, что требования к бортовым компьютерам более стабильны, чем к веб-сервисам.
И вместо простого сложения чисел (одна инструкция) вы получаете кучу проверок, которые, тем более, надо не забыть везде расставить. Как вы будете проверять, что вы их везде расставили? Опять тесты писать?
Вас увлечение типами к какому-то ужасному дизайну толкает.
Раз уж у нас на входе могут быть единицы в разных системах исчисления, значит и юниты придут в пейлоаде. Там на входе мы их конвертнём в единую СИ и дальше никаких проверок на эту тему не понадобится.
Как мы с бекенда переместились в бортовой компьютер?
Кто скажет, что бортовой компьютер — это фронтенд, пусть первый бросит в меня камень (согласен даже на 386).
Какая транзакция вам поможет, если вы в БД положили вместо суммы двух чисел их конкатенацию как строк?
Во-первых, сильная типизация на стороне СУБД поможет. Во-вторых, тут поможет тестирование: подобного рода ошибки, как правило, хорошо воспроизводимы, а потому вылезают на первом же запуске.
Очерёдность чего вы случайно не учли, потому что человеческий attention span куда мельче, чем таковой у тайпчекера.
Проверка очерёдности операций куда проще проверки типов.
Кстати, расскажите пожалуйста как конкретно в этой задаче вам поможет типизация, а то я вижу исключительно сценарии в который она не помогает.
Вот самый простой: расхождение между схемой данных в вашей программе и фактической схемой данных в СУБД. У вас в программе статически доказано, что запись в БД будет успешной, а потому можно отправить сообщение на почту — а запись внезапно провалилась.
Не стоит статически доказывать то, что неверно. […]
…и всё что вы написали дальше никак принципиально не отличается от сильной динамической типизации. Всё те же проверки типов, которые могут вернуть ошибку.
Стадии работы фронтенда вы успешно замените на стадии работы с пользовательскими данными, я не сомневаюсь.
Увы, но это работает не так хорошо как вы утверждаете.
Вот у вас написано: defunctionalize :: Xform '[EtaExpanded, Monomorphized] '[Defunctionalized] Program. А теперь вспоминаем про ваш "любимый" attension span, и допускаем ошибку: defunctionalize :: Xform '[Monomorphized] '[Defunctionalized] Program. Всё, теперь ваши типы никак не мешают собрать некорректную последовательность действий, ведь тэги не связаны с данными, а просто навешены сверху.
Вот и с регистрацией пользователя такая же ситуация.
Пока мы окончательно не скатились в какие-то детали, хотелось бы высказать общее утверждение.
Типы в программе же образуют некоторую мета-программу, верно же? Вот если сложность этой мета-программы превосходит сложность исходной — то у вас уже не типы проверяют корректность реализации, а реализация проверяет корректность типов.
В таком случае статические типы больше не являются ультимативным доказательством корректности программы, а просто являются аналогом модульного теста — чем-то, что с некоторой вероятностью может поймать ошибку, а может и не поймать.
Блин, вы всё время упускаете ключевую разницу. Эти проверки случаются в рантайме
Вот именно, ваши проверки случаются в рантайме.
Только в этом случае мне нужно, чтобы attention span'а хватило на сигнатуры, а это куда меньше, чем весь код.
Так ведь и в динамически типизированном варианте это прекрасно работает!
Вот пишем:
async function registerUserHandler(req) {
const user = mapRequestToUser(req);
await createUser(user);
await sendRegistrationEmail(user);
}Тут всего три строчки (6 если считать заголовок и пустые). На столько строчек attention span у нормального программиста хватает гарантированно.
Но вы почему-то упорно утверждаете, что нет, функцию registerUserHandler никак невозможно проверить взглядом, а вот ваши сигнатуры, наверняка раскиданные по нескольким файлам — они-то, конечно же, проверяются надёжнее. Но нет, этот так не работает.
Но вам из этой программы нужно только несколько ключевых утверждений
Тут соглашусь. Однако, часто и в основной программе достаточно только ключевые утверждения проверить. Тут надо подумать в чём вообще измерять сложность...
На практике только функции подлиннее, увы.
Так ведь и attension span на практике подлиннее.
Ну серьёзно: я видел много раз в чужом коде отправку уведомления до сохранения в БД потому что "а в чём проблема?", но ни разу не видел отправку уведомления до сохранения в БД потому что программист не смог поставить две строчки в правильном порядке.
Вот так мы от time to market перешли к срачу об определениях. Поэтому в условных Хаскелях и Идрисах time to market и страдает, что акцент не на том. Бизнесу вообще параллельно на чистоту ваших типов. И даже то, что вы не допустите ошибки, которые в программе на динамическом языке в 0.001% случаев выдадут юзеру 500-ку, бизнес не убедит, что это стоит лишней недели разработки.
Не угадали. Я Elixir предпочитаю.
Вообще-то пойнт о том, что TTM страдает от типов был начальным. И вы по сути согласились с этим, сославшись лишь на то, что без типов вам не спокойно за то, что вы выкатили в прод. Дальше уже чисто оффтопик пошёл.
Без типов в том, что выкатывается в прод, ошибок находится больше, чаще и серьёзнее, чем в том, что обложено типами.
О, ну хорошо хоть вы не стали утверждать, что со статическими типами ошибок совсем не будет, скомпилировалось же)
Ну а так да, это компромиссный вариант. Edge-кейсы возможны и их риски бизнес принимает ради скорости выкатки. Я б может был не против тоже на Haskell что-нибудь написать, но в 99% случаев бизнес за Haskell платить не готов. Почему так, не знаете?
у хаскеля на самом деле есть проблема, но это проблема не с типами, а с коммьюнити
Ой, да ладно, как будто говноедов вне теоркатчиков мало. Это можно пережить, вы же там сами где-то написали: «Игнорируете, и сон снова как у младенца».
Если серьезно — то проблем я вижу две. Одна, косвенно связанная с тем, что вы говорите про коммьюнити, — очень ярко проявляется именно в вас. Думаю, что на работе это не так, но в социальной среде вы со своими типами — как тот чувак с молотком: везде видите гвозди. Несомненно, есть области, где типы очень помогают (я, правда, вижу ценность в завтипах, а не в голых адт). Тем не менее, фигачить круды, когда цена ошибки — пользователю показали 404, — проще и быстрее без них. Сложили пять и табурет? — Ну, транзакция упала, пользователя жалко, но мир жесток.
Типы не панацея и не серебряная пуля, как все инструменты, они тут помогут, тут навредят, а тут пофиг. Но средний типодроч влезет со своими типами просто повсюду, и это немного раздражает.
Вторая проблема — prelude и три четверти стандартной библиотеки, сделанная на отъеойди-не-мешай. У нормального языка не может быть такой нечеловеческий порог входа на чтение для тех, кто с ним не работает ежедневно по 12 часов и потому волей-неволей выучил все эти триста квадриллионов трехбуквенных функций, зачастую делающих одно и то же.
Что касается типов — всегда есть компромисс. Тривиальные для меня архитектурно задачи — я решаю в лоб, хоть на перле, хоть на си — и пишу для них property-based тест. Нетривиальные — доказываю на идрисе и перевожу на эрланг. Я знаю, что доказательство теряется, но во-первых, я — неплохой переводчик, а во-вторых, в этот момент, когда доказательство свершилось, задача стала обратно тривиальной архитектурно. Для меня такой смешанный подход — оптимален по КПД. У других может быть иначе.
Я там, где учить, имел в виду для «комфортно читать», и даже написал про это.
Но как? — но так же :) это прототип, можно подождать, что делать?
переписать всё на агде
Я знаю. Но, к сожалению, мне почему-то агда эстетически не нравится (что, кстати, очень странно в принципе, но — как есть).
А я лучше буду работать с неудобными инструментами, но которые мне прям нравятся, чем с удобными, но «какое-то оно немного комиксансное». Это иррациональное.
Так я спорю, что ли?
Вообще-то, именно этим вы и заняты.
Хм, а что там с Type : Type?
А за Elixir, кстати, готов?
Ага. Elixir, кстати, весьма сбалансированная технология. Сочетает удобство и скорость разработки с производительностью и отказоустойчивостью. На мой взгляд, наиболее ориентированный на нужды бизнеса язык.
сильная динамическая типизация с опциональными type-аннотациями
Вот именно тут можно пойти дальше и взять язык со статической типизацией. Динамика была явно быстрее в сравнении Java vs Python образца 2003 года. Но в 2023 всё как-то стало по-другому.
Накручено именно что поверх. Тот самый event loop – он ведь даже не часть языка.
Но соглашусь, не подходит. Чистого языка нет в природе :-), и вместо алгоритмов и структур данных окунёшься во фреймворки и библиотеки.
Я до сих пор не понимаю почему все так ругают слабую типизацию. Ты просто не складывай строки и с числами, и тебя не будут бить табуреткой.
Проблема слабой типизации — в том, что она до последнего прячет ошибку. Зачастую потом ошибка всё равно всплывает, но откуда она взялась приходится искать.
А корректной программе да, не важно какая в языке типизация.
Вы, видимо, слишком простые программы пишете, если складываете только литералы. С переменными за этим следить гораздо сложнее, особенно когда они пробрасываются глубоко по стеку вызовов.
Ну так получается ругают за слабую типизацию какая-то определённая группа разработчиков, но кричат об этом больше всех. Браво.
Эта группа разработчиков кричит больше всех, потому, что она наиболее многочисленная. Все логично )
Вот есть у вас допустим переменная "month", которая приходит с поля ввода пользователем через несколько классов, и попробуй пойми по быстрому строка это или число? А если "String month" или "int month", то сразу понятно.
забавно что в крупном проекте на питоне всегда всё рано или поздно до этого доходит, сразу всплывают и интерфейсы и сериалайзеры и аннотации типов и все что буквально вчера было "никомунинужно лишнаяяписанина" сразу становится норм и везде так делаем и разрабы массово переобуваются с "нинужно" на — обязательно
не складывай строки и с числами
"Складывать"-то иногда можно и даже нужно:
int n = 14;
...........
System.out.println("Пункт № " + n);вполне валидный код. Тут наверно проблема в синтаксисе: символ "+" означает операцию конкатенации, а выглядит как сложение и ряд ошибок компилятор не выкупит :)
В остальном, статическая типизация весьма полезна, компилятор не допустит много ошибок, в современных IDE работать удобно т.к. они выполняют компиляцию в фоне и сразу подсвечивают ошибки и дают подсказки.
Даже переход с JS на TS это очень хорошо: IDE сразу начинает работать как надо :)
"Складывать"-то иногда можно и даже нужно:
(давно не брал я в руки шашку)
а разве не нужно юзать чёнить типа String.format ?
делать "Пункт № " + n
… это такое
Таки можно, но "сложение" - самый синтаксически "прозрачный" вариант. Остальные читать сложнее.
дело не в синтаксисе, а в неоднозначности с приведением типов
как вы представляете себе такую конструкцию?
a=1
b=2
c="1"
d="4"+5
System.out.println("Пункт № " + a + b + c + d);
в лучших традициях ужасов JS
В данном случае никакой неоднозначности нет, всё будет приведено к строкам и сконкантенировано (о_О).
Я же выше и говорил что такую конструкцию компилятор проглотит. И не покажет логической ошибки если она есть. Т.е. тут типизация не поможет (а в других случаях поможет).
Можно писать через String.format(), но визуально это будет сложнее. Можно через StringBuilder, но будет очень многабукаф.
В данном случае никакой неоднозначности нет, всё будет приведено к строкам и сконкантенировано (о_О).
ваш пример просто частный случай, я его чуть расширил
автоматическое неявное приведение типов это зло, что я и показал — какой будет ответ в итоге? я давно не трогал яву и мне не явно что такая конструкция приведет всё к строке
вы стремитесь к красивому коду или чтобы программа работала с однозначной и понятной логикой?
неявное приведение типов
Я на всякий случай проверил :)
Всё нормально, ошибки нет (есличо, я var не использую, здесь просто для демонстрации приведения типов).
В случае с Java приведение как раз понятное. Аргумент метода System.out.println() всегда приводится к строке: для объектов вызывается .toString(), для примитивов что-то вроде String.valueOf(); . Если же попытаться эту херабору присвоить переменной, то придётся указать её тип (String, без вариантов) и далее всё будет как выше.
В Java эту механику знают все новички, поэтому это можно считать явным приведением. В Java есть много чего "по умолчанию": конструктор по умолчанию, можно не писать this. в очевидных случаях, а в Record - целая куча кода по умолчанию. Так что да, явное :)
А пишу я так как понятнее, мне в первую очередь. Если на работе скажут использовать какую-то конкретную технику - буду использовать.
Самая синтаксически прозрачная — интерполяция строк:
Console.WriteLine($"Пункт №{n}");Но да, она появилась к тому времени когда уже во всех языках устоялась конкатенация.
А в каких языках кроме Idris/Agda/Coq нужны IDE и зачем? Если для автокомплита — дык гнать в шею надо людей, которым нужен автокомплит.
И бить линейкой по пальцам за ошибки. И профилактически пороть после воскресной службы. Ничо не упустил? :)
Нет, за ошибки бить не нужно. А за автокомплит — нужно, иначе из джуна вырастет чатжпт.
из джуна вырастет чатжпт
Я формальный джун и я использую IDE. И автодополнение, и автоматическое создание типовых классов, и встроенную документацию, и интеграцию с тестами и готом. По мере роста задач начну использовать интеграцию с докером, CI/CD и прочие плюшки. Да, я наверно не напишу полноценный класс в блокноте т.к. тупо не помню откуда что импортировать. Но мне каждый день и так есть что учить, лучше я оставлю в голове место для этого.
Когда я только начинал учиться, я сразу взялся изучать IDE, хотя это сложнее чем решать задачи в web-интерфейсе задачника. Просто я хорошо помню как я когда-то пытался чертить "потому что так проще". в итоге всё равно пришлось изучить профессиональные программы, а всё что делалось раньше выкинуть и переделать. Повторять эту ошибку не буду! Профессиональной работе профессиональные инструменты.
И сразу отвечу на вопрос: "А если тебе на сервере придётся через SSH и Nano....". Ребята, я не смог бы взять с собой на объект СМ1420, но ноутбук могу, и даже беру. А вот когда придётся.... ну тогда и придётся, медленно и печально :)
Руки прочь от автокомплита!
Это единственное что удерживает имена классов и методов хоть немного понятными, без автокомплита люди начнут сокращать всё что только можно.
Начинал с Ассемблера как первый язык. Мне что-то не очень помогло... Я бы не сказал что это дало мне фору перед ребятами начавшими с Visual Basic, Java и т.д, т.к. Ассемблер не язык новичка и всё что там было написано очень тяжело давалось. Тем более при самостоятельном изучении. Написал пару учебных приложений из книжки и плюнул. Только спустя долгое время снова начал с JS, а потом и бэк, и C под ардуино. Лучше действительно начать с чего-то лёгкого, а там уже тяга сама появится.
Ассемблер как первый язык - жёстко, только для реальных фанатов. Но его всё равно надо хоть чуть-чуть изучить. Потому что только с его помощью ты реально напрямую управляешь процессором, понимаешь, что скрыто под пятью капотами и как оно в реальности работает "в железе". И осознаёшь, что никакой магии нет, и все высокоуровневые абстракции в итоге сводятся к чётко описанному набору команд конкретного процессора.
Ну когда не было выбора — что ж делать то.
Просто были времена, когда доступ был к конкретному ОДНОМУ компу и то по расписанию.
У меня тоже первая пара была Ассемблер-Бейсик. А третьим стековый Форт.
У нас "стековым" был язык программирования какой-то "Искры", там обратная польская запись, и работа со стеком. И пытались рассказывать про ЯСК (Язык Символического Кодирования), это такой "русский ассемблер" для минск-32. Но преподша и сама толком его не знала, поэтому что-то было показано-рассказано, и на этом всё затихло. В голове осталась ровно одна команда: СФ (Сложить числа с Фиксированной точкой).
Я считаю, что программирование нужно начинать преподавать с ассемблера с рассказами о машинных кодах. Ну то есть почему эта инструкция такая и почему у неё такой код, как это соотносится вообще с архитектурой процессора и т.д. Хотя бы в ознакомительном режиме, для понимания как оно на самом низком уровне работает. А то мне тут один соискатель не смог двоичное число в десятичное на бумаге перевести, при этом человек пришел из разработки. Сказал - нам в институте объясняли, но я не помню. Про битовые маски впервые слышит, а у нас как раз работа с оборудованием, биты вычленять и т.д. Никакого снобизма.
Я двоичные числа в десятичные последний раз в универе на 1 курсе переводил и забыл ровно через 2 недели после сдачи, больше никогда не пригождалось в работе. Так что надо все-таки какую-то более общую для всех базу брать, кому захочется спуститься на уровень ниже - и сам найдет способ это сделать.
программирование нужно начинать преподавать с ассемблера
Такое ещё можно было бы провернуть на примере процессоров из 70-х или МК из 90-х. Современные процессоры и даже МК слишком сложны чтобы с них начинать. Всё таки обучение начинают чтобы вызвать у человека интерес, а не отвращение :)
Мне битовые операции зашли легко т.к. я немного занимался электроникой и у меня "перед глазами" стоял "физический аналог". А если людям объяснять это как чистую абстракцию, то да, заходит тяжело.
Скажем так – учить схемы косвенной адресации всё равно придётся, но можно не начинать с этого)
Раньше мы разбирались как всё работает на уровне ассемблера, как компилятор проводит оптимизации, как работают виртуальные машины и сборщики мусора.
И сейчас этим тоже интересуются. И раньше не все интересовались. Для работы с Delphi и Basic это не требовалось.
Сейчас же такие вопросы на собеседовании де-факто под запретом, потому что с такими вопросами вы вообще никого не наймёте.
А у меня спрашивали. Вопрос в том, куда устраиваться. Можно попробовать попроходить собеседования в HFT и понять кто тут на самом деле неуч, который ничем не интересуется.
Для работы с Delphi и Basic это не требовалось.
Ну, почему же. В Delphi были ассемблерные вставки)
Но в целом вы правы, всегда были и те, кто интересуется, и те, кому параллельно. Просто по субъективным ощущениям процент интересующихся снижается.
Просто по субъективным ощущениям процент интересующихся снижается.
Это следствие массовости и востребованности. Как следствие: процент снижается, а вот абсолютное количество только растёт. Бонусная причина: сама область сильно выросла. Раньше человек мог быть хорошим специалистом и по железу, и по работе с железом, и по ос, и по хранению данных, и по разработке. Ну потому что лет 20 назад всё было гораздо проще. Требования ниже, железо - прямолинейнее, протоколы - примитивнее, кода - меньше, безопасность - это что? Сейчас такой набор - признак либо особо исключительного специалиста, либо, что более вероятно, дилетанта широкого профиля.
Я учу жену и одного знакомого программировать - и да, жену учу с JavaScript - на фронта, а знакомого - с Python - на бекендера и инженера данных.
К чему такой снобизм?
Сейчас куча людей свалила из России из-за спятившего деда - и надо как-то устраиваться.
Если выучить Python за пол года - да, как программист человек будет первый год-два очень плохо кодить, с точки зрения снобов. Но на задачи автоматизации тестирования, инженерии данных - да и бекенд писать вполне подойдёт - в чём проблема?
Сейчас, в 2023 году у людей нет времени сначала 2 года учить программирование в школе, а потом ещё 6 лет в ВУЗе - да и уметь написать компилятор или знать как работает ассемблер - тоже задачи нет. Есть цель - закрывать простые задачи лучше индусов - и получать за это денег достаточно, чтобы выжить за границей.
Так вы учите их не программировать. Вы учите их кое-как закрывать простые задачи лучше(?) индусов. Это принципиально разные цели. Называйте вещи своими именами и никакого противоречия между нашими высказываниями не возникнет.
Если выучить Python за пол года
Что в вашем понимании означает "выучить Python"?
Что плохого в Python или JS? Начинающего прежде всего надо заинтересовать.
Кому надо? Продавцам курсов?
Если человеку самому неинтересно, то зачем его заинтересовывать? Что за насилие над личностью?
Что плохого в Python или JS?
На этот вопрос уже выше ответы есть.
Любую деятельность надо рекламировать. Для этого нужно создавать положительный климат, а ваша позиция понятна - вам не нужно, никому не нужно.
Любую деятельность надо рекламировать.
Весьма спорный тезис. Вы вот дышите, едите, спите, ходите, вам точно всё это рекламировали?
P.S. Если речь про детей, то я согласен, что им надо показывать разные виды деятельности и возможно даже умеренно заинтересовывать. А у взрослых должен сначала собственный интерес просыпаться.
ты должен знать свою область на 200%, а все что смежное хотя бы на 100%
Это не так. Как стать лучшим в мире в какой-то нише.
Никого ничего не выдавит, как не выдавил аналогичных из других специальностей за тысячи лет цивилизации
Не знаю, с программерами беда: соискателей много, а нанять некого, и не видно, чтобы была проактивная масса, которая кого-то выдавливает.
Если эта толпа будет, потому что искать работу в ИТ без опыта - это капец. Прекрасно помню своё начало, сменил работу переводчика в свои 40, всю теорию выдрочил, да хоть бы кто позвонил. Как раз попал на тот момент, когда к нам Казахстан поехали россияне и украинцы, в общем всё одно к одному. В итоге помогли связи, сейчас знаю немного RHEL, VMware, Netapp, ну и сервис оборудования Фуджитсу.
27 ноя 2020 здесь на Хабре появилась статья - Инженерное нелюбопытство
https://habr.com/ru/articles/530300/
...интеллектуальную и технологическую элиту страны, для которой <неочевидна> сама идея заглянуть внутрь...
Вот и делайте поправку на неинженерное мышление современных "инженеров".
В нас пропал дух хакерства.
Чтоб нанять много знающего специалиста, как мне кажется нужно много платить. Тогда у других будет мотивация становится такими специалистами. Первый вопрос к вакансии: "Платить пробовали?"
По нашим оценкам, имеем медианные вилки.
На медианные вилки приходят медианные разработчики.
Ох, как бы этого хотелось, но нет(
Если на медианные вилки приходят разработчики хуже медианных, то, очевидно, чтоб приходили хотя бы медианные разработчики, нужно платить выше медианных вилок. Оригинальный посыл остаётся в силе, как видите.
После того как началось засилье трехмесячных айтишных курсов, медиана сильно просела, к сожалению.
Тогда будет медианный уровень знаний. В данный момент он такой, и будет снижаться, так как требования растут, а технологии меняются и добавляются. Раньше нужно было знать Linux, потом Linux и Docker, теперь Linux, Docker, k8s.
Кстати, тут есть эффект потолка. Например, я могу программировать в 10 раз круче условного миддла с з/п 150 т.р./мес, но при этом мне никто не будет платить 1.5 млн.р. в месяц (во всяком случае в 2023 году). Так что денежной мотивации развиваться по сути то и нет.
Особенно это чувствуется после того, как в начале карьеры твоя з/п постоянно растёт и в какой-то момент просто упирается в определенный уровень и дальше чисто на официальную инфляцию индексируется, при том что ты продолжаешь развиваться и накапливать годы ценного опыта.
А потом вступает в действие принцип Питера, тот самый про то, что "каждый растёт до уровня собственной некомпетентности". Т.к. единственный способ дальше поддержать ценного сотрудника материально, когда он уже достиг старшего экспертного уровня, - продвинуть его на менеджерскую позицию. А менеджер из него, весьма вероятно, будет плохой. В итоге система превращает лучших экспертов в плохих менеджеров. Таковы суровые корпоративные реалии :) (впрочем, в своём бизнесе похожая картинка будет)
В гуглах и ко обратная ситуация сейчас - менеджеров разжалуют в разработчики. А кто не хочет - на выход.
достиг старшего экспертного уровня
У вас баг в определении старшего экспертного уровня. Или задачи простенькие, и такого удержать будет невозможно.
Ни один менеджер не получает суммы, сопоставимые с principal engineer и выше.
А вот и 10x-разработчик в треде =) Зависимость логарифмическая, придётся терпеть =)
Народ вроде взрослый собрался, а все в 10x разработчика верят... :)
Я тоже раньше не верил, когда в книжке про это читал 16 лет назад))
На деле всё ещё сложнее. Есть класс задач, где это соотношение растёт ещё больше. Т.е. один программист и за месяц и за два не сделает, то что другой может сделать за несколько дней.
А вообще – сделает?
Может, надо мерить не скоростью восхождения на гору, а высотой, на которую может подняться?
Кто-то, может, и вообще не сделает, или сделает, но оно будет работать в 100 раз медленнее. От этого ценность выполнения задачи разве снизится?
Например, у меня был опыт, когда я 3 недели переделывал проект, который до этого почти год пилила команда из 4 программистов. В итоге, ключевой сценарий использования всего этого проекта стал работать в 300 раз быстрее и в нём появились хотя бы end-to-end тесты.
Ну т.е. да, сколько бы им времени ни дали, нормально они бы всё равно не сделали.
Ну я, собственно, к тому, что "в 10 раз производительнее" – маловероятно, а вот если у вас сложные задачи – проблема, выбор кандидатов резко сужается, и цены, соответственно, растут.
Например, у меня был опыт, когда я 3 недели переделывал проект, который до этого почти год пилила команда из 4 программистов.
Если там год требования устаканивались, то вполне закономерно.
Ну и ещё один анекдот вспомнился:
- Папа, папа, я сегодня выиграл свой первый суд! И знаешь, папа, это то самое дело которое ты вел все прошлые 10 лет и не мог выиграть, а я его выиграл за один день!
- Вы только посмотрите на этого идиота! Он сегодня за один день закончил дело которое кормило нашу семью почти 10 лет!
3 недели переделывал проект, который до этого почти год пилиа команда
Я раньше работал системным интегратором: мы из разных железок собирали проекты. И вот как-то к нам пришёл вьюнош с рекламой супер-пупер чертёжной программы и спрашивает:
– Ну сколько вы обычно делаете проект?
– Ну, месяц....
– П-фффф! Я такой за три дня делаю!
Хорошо что тогда наше начальство на это не повелось и закупать продукт не бросилось. А то можно было бы поставить эксперимент: вот тебе протокол первого разговора с заказчиком - и давай, делай за три дня.
Я к тому что проектирование не то же самое что черчение. Хотя специализированная программа, которая знает о предметной области, и позволит сократить некоторую рутину, но общая экономия по проекту утонет как капля в чинарике :)
И я что-то думаю что твои 3 недели сравнивать с их годом неправильно. Ты вряд ли сделал этот проект с нуля сильно быстрее их, верно? Поэтому ты просто поучаствовал в проекте именно в тот момент когда требовались твои узкоспециальные знания: архитектура-шметектура, кэш-шмэш, асинхроннось-шмесенхронность.... Ать-два, буст в 300 раз! Кто молодец? Я молодец! А в предметную область ты лазил? Или нет? :)
Архитектура для вас это узкоспециальные знания, которые нужны, только когда клиент уже зверски недоволен из-за того, что всё тормозит, а отчёты генерируются часами?
Ясно-понятно.
А в предметную область ты лазил?
Разумеется, как без этого вообще можно хоть что-то путное сделать.
Архитектура высоконагруженных и высокоотзывчивых систем это безусловно специальные знания.
Но основное что я хотел сказать: неправильно говорить "я за 3 недели сделал проект, который четверо не смогли за год". Тут я вступаю на тонкий лёд предложений, но... :
ребята за год напилили MVP, который хоть как-то работает;
это что-то наконец-то, путём долгих итераций стало соответствовать тому что надо клиентам (всё хотят здравое ТЗ, но не все его имеют);
у них не хватило квалификации довести систему до устойчивой работы под реальными нагрузками и поэтому позвали консультанта, который это умеет;
то что в кратчайший срок удалось ситуацию кардинально исправить говорит что их архитектура была не так уж плоха: то что плохо во всём быстро исправить не получилось бы;
в итоге каждый отработал на своём месте и за год и три недели общими усилиями удалось построить систему, которая нужна клиентам и работает достаточно быстро чтобы никого не бесить :)
Ну, разумеется, вы промахнулись почти со всеми додумываниями.
Там не было хайлоада.
Про soft-realtime тоже речи не шло (речь о величинах 4.5 часа vs 50 секунд).
Изначальная архитектура была плоха, и её переделка в менее критичных местах легла в техдолг.
Ну и даже в критически важных юзкейсах не удалось её полностью на адекватную переделать за эти сроки. Даже остался потенциал ускорения ещё раза в 2.
MVP или не MVP, я в любом случае за то, чтобы в начале разработки продумывать архитектуру и понимать что с ней будет при получении реального кол-ва данных, и с запасом x5.
Есть задачи, к примеру, сложные оптимизации процессов, которые многие люди просто не сделают
Не раз переделывал ядра проектов, которые пилили 5+ человек годами, но в результате оно в принципе в реалтайм не работало с нужной нагрузкой. И да, у них были эксперты в базах данных, в многопоточной обработке!!!(отдельный, ага) и так далее.
А с простыми задачами люди с высоким уровнем справляются не 10х, а скорее 0.2х.
В зависимости от того что взять за базис можно и 100х разработчика получить.
А что такого невероятного?
В России? Или мы резко начали сравнивать с американскими зарплатами?
А причём тут Россия? Рынок IT вроде бы международный, как и аудитория хабра..
Не, вы неправильно уловили посыл. Меня моя зарплата устраивает. Но я отвечал на комментарий:
Чтоб нанять много знающего специалиста, как мне кажется нужно много платить. Тогда у других будет мотивация становится такими специалистами.
И пойнт тут в том, что ни одна компания не может создавать такую мотивацию. В том же Google миддлы ведь не $25k/год получают, а гораздо больше. Поэтому заплата растёт, как тут уже кто-то писал, как логарифм от квалификации, а не линейно.
Например, я могу программировать в 10 раз круче условного миддла с з/п 150 т.р./мес, но при этом мне никто не будет платить 1.5 млн.р. в месяц (во всяком случае в 2023 году).
...но вы можете взять несколько проектов на аутсорс, если вы такой уж продуктивный.
Вы имеете в виду уйти во фриланс?
Да ладно уж, если вы работаете хотябы за 10 обычных девелоперов - ну вот устройтесь в три компании, делайте за 2 часа то же, что остальные за 6, и получайте х3 зарплату в сумме, для начала... Там, глядишь, и до своих х5-х10 подниметесь..
Я знаю несколько примеровгде люди сочетают несколько работ, более того, один из них прямо говорит компаниям - "мне не пойдёт ограничение, так как я хочу участвовать ещё тут и тут", и ничего, его с его продуктивностью и знаниями готовы брать, считать его консультантом и т.д.
Спасибо, x3 можно и без подобного геморроя получать. А параллельно работать над 10 проектами - это свихнуться можно от постоянного переключения контекста. Тем более, что один из секретов высокой эффективности в потоковом состоянии, а его невозможно поддерживать при постоянных переключениях :-(
Ну над шестью (на трех разных языках) — вот я прямо сейчас работаю за обычную зарплату. И еще примерно 10 OSS-библиотек поддерживаю.
И как ощущения? Пока нравится?
А почему нет-то? Я библиотеки в рабочее время поддерживаю, разумеется, я не идиот — по ночам с зеленой лампой сидеть.
Я от переключающегося контекста устаю гораздо меньше, чем от рутинных задач на три дня.
Ну, всё может быть, люди разные. А может просто не так давно этим занимаетесь.
Вот мы и пришли, что ваше 10х не постоянно, а только в определенных сценариях. А ЗП вы хотите 10х постоянно )
Я уже чуть выше пояснил в чём тут суть.
Не плавали! Не плавали вы на наших галерах!!
Я не знаю, как назвать, например, ИП, которое работает на нескольких постоянных клиентов. Это не фриланс и не трудоустройство. Это просто бизнес. Плюс, масштабируемый - если ваша нагрузка по проектам будет расти, вы можете ещё кого-то уже на себя нанять.
Почему-то вспомнилось. Давно это было. На конвейере Ваза два рабочих. Первый закручивает гайки качественно, в темпе движения конвейера. Второй быстро бежит вдоль конвейера и закручивает гайки в два раза быстрее, чем первый. Потом садится на скамейку и курит минут пять. Начальник отдела контроля качества жалуется: "Никак не может молодых приучить работать по технологии."
Много платить не достаточно. Ещё должна быть работа интересная. Потому что знающие специалисты, скорее всего, уже неплохо зарабатывают и менять интересную работу на скучную ради просто денег не все будут. При условии, что денег достаточно уже сейчас, естественно.
По моему вполне себе вопросы на девопс инженера.. я их тоже задаю. Равно как и тестовое/ или открытые репы с примерами.
Я как-то давно прочитал/услышал может быть и тут на Хабре - не бывает джуниор девопсов, слишком много надо знать. Я как-то вот согласен с этим. И сети и *nix и инструменты автоматизации от ансибла до дженкинса и аргосд, терраформы и террагранты и контейнеризация/виртуализация и базы и кластера и отказоустойчивость и безопасность. Плюс софт - коммуникация с командами, умение найти че болит у разработки или тестировщиков, иногда и решение/дизайн обсудить/подсказать или наоборот аргументированно отговорить, и т.д. и т.п. можно очень долго продолжать.
ТРЕБОВАНИЯ К ВАКАНСИИ ВОДИТЕЛЯ, ЕСЛИ БЫ ОН БЫЛ ПРОГРАММИСТОМ.
Обратил внимание, что последнее время, лет так 10-15, требования к программистам уже вошли в некий своеобразный СВ стандарт. Нужен программист-ниндзя и всё тут.
Складывается ощущение, что все программисты просто пираты сорви голова в море компьютерных технологий.Кто-то заметил это, чуть раньше чем я и прописал вакансию водителя, так же, как её написал бы работодатель к вакансии программиста. Добавляю эту вакансию водителя со своими некоторыми комментариями. Давайте посмотрим что получилось.
ТРЕБУЕТСЯ ОБЫЧНЫЙ ЧЕЛОВЕК НА ВАКАНСИЮ ВОДИТЕЛЯ.
Вакансия: водитель.
Требования: профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулера, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими и средними танками, находящимися на вооружении стран СНГ и НАТО.
Навыки раллийного и экстремального вождения обязательны! Опыт управления болидами «Формулы-1» — приветствуется. Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих поизводителей — обязательны.
Опыт проведения кузовных и окрасочных работ — приветствуется. Претенденты должны иметь сертификаты Mercedes, BMW, а также справки об участии в крупных международных ралли не более чем двухлетней давности.
Зарплата: 3500-6999 рублей, определяется по результатам собеседования.
Обращаясь при себе иметь: паспорт, полис, пенсионое, ИНН, справка НДФЛ-2, свидетельства о рождении, дипломы, знаки отличия, рекомендации, справки и прочие документы, необходимые для подтверждения своего водительского класса.
А в качестве собеседования тестовое задание: сгоняй за пивом боссу в соседний город за свой счет. При этом на машине спущены колеса, бензобак пустой, аккумулятор разряжен, инструментов нет, машина без номеров. Посмотрим как водитель решает проблемы и примем решение о найме )
А после выхода на работу водишь старую говновозку с барахлящим насосом и порванным шлангом, получая расписание на две недели вперед, после чего каждое утро, отчитавшись диспетчеру за вчерашний день, узнаешь, что где-то неожиданно прорвало и поэтому помимо плановых выездов, нужно еще откачать там. К концу двухнедельного плана отмываешь с тачки самые стрёмные разводы и демонстрируешь, что инструмент в рабочем состоянии и называются эти демонстрации - дермо показы. [/joke]
Джуниор-девопс это тот, кто еще не освоился с организационной составляющей =)
Приведенные примеры подчеркивают нежелание большого количества нынешних специалистов погружаться в вопрос и разбираться в теме, что не может радовать.
Потому что в вакансиях, где в требованиях указано K8S, Cloud, Helm, Ansible, Gitlab CI, Teamcity или Jenkins, платят в разы больше денег, чем в вакансиях с "правильное определение потребления памяти", методы GET и POST, ping и traceroute. :)
Рыночек порешал, а кандидаты лишь к нему подстроились. Так что всё логично и закономерно.
А вот вам несколько историй с другой стороны. Я 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 на четыре подсети? И напиши мне адреса сети, маску и широковещательный адрес для каждой из них вот тут на салфетке?
Знаешь сети? А раздели мне сеть класса 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.255
Согласен. Вопрос с подсетями несложный. Даже если ответ не знаешь, за вечер можно разобраться и потом будешь нарезать сети в любом размере. Они все по отдельности несложные.
Но вопросы бывают из разных областей. Ответил по сетям - завалил Kubernetes. Подтянул Kubernetes - завалил кодинг интервью.
А в добавок техническое интервью - это только один из раундов. Вероятно, самый простой.
Я забил считать маски в уме
Ipcalc есть в любом линуксе в пакетах в в brew для мака. За одно и вайлдкард, если собеседник вспомнит кому это нужно
Извините, "15 лет опыта DevOps инженера", и вы не знаете как работает TLS handshake, за полчаса не можете посчитать топ IP-адреса в логах? Умеете настраивать Linux и сети, но не можете разделить сеть класса C на 4 подсети?
Я согласен что на SRE нужно много смежных знаний, всякие куберы, прометеусы, jaeger-ы, golden signals, BPF и другие слова. Но то что вон там выше написано, это же базовые навыки системного администратора Linux, нет?
Не знал, потому что не пользовался этим.
После неудачных интервью посидел вечер и разобрался. Теперь могу нарезать сети хоть на 4, хоть на 128 сегментов. Перед сном каждый день читаю RFC 8446.
Просто на работе я выполняю задачи которые нужны бизнесу, а они, обычно, про другое.
Если честно, то я считаю, что каждый инженер должен знать как устроен компьютер. Как работает операционная система. Понимать процесс загрузки начиная с bios/UEFI и до Login Prompt. Основы сетей. Не знать TCP header size это непростительно.
Я учу все это заново, каждые 4-5 лет, когда приходится менять работу. А потом забываю. Как забыл размер ключа, которым откручивал свечи автомобиля Москвич 2141 чтобы их просушить. Их вечно заливало карбюратором.
Не знать TCP header size это непростительно.
Если честно, то я считаю, что каждый инженер должен знать как устроен компьютер. Как работает операционная система. Понимать процесс загрузки начиная с bios/UEFI и до Login Prompt.
для общего развития - да, но в облаках, а очень много devops работает с ними, это вам не поможет никак, причем от слова совсем
Не знать TCP header size это непростительно.
и как оно помогает в решение ежедневных задач ? Это все равно, что программиста заставить учить на память параметры методов и точное написание имен самих методов/параметров, привет универ
Кстати, а какое за короткий срок адекватное решение по подсчету топ ip адресов в логах?
В голову пришло заговнокодить на питоне поиск всех ip через regex и запихивать в словарь с строковым ключом IP и значением — количество вхождений.
update: буду читать коменты ниже...
Не смог за полчаса распарсить лог веб сервера Apache и найти топ самых часто встречаемых IP адресов.
Ну вообще, если задание описано верно, то не имея ни одной сертификации да и вообще будучи гуманитарием, для которого IT - ни разу не специальность, я за 3 минуты и 2 подглядывания в man написал примерно это:
cat /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -bgr | head -n10
То ли в задании были какие-то дополнительные усложняющие вводные, то ли я соглашусь с тем работодателем... сорри, не воспринимайте за личную нападку.
Ну почему? Почему в 99.9% ситуаций, когда я вижу использование awk, это непременно стереотипный awk '{print $1}' ? =) Ну такая классная утилита же, мощнейшая как трактор. Можно вообще всё задание в единый вызов gawk запихать и потом лихо лопатить логи апача со скоростью пулемёта так, что интервьюер кофе поперхнётся)
Тоже no offence, просто грустно за утилитку.
Это современный DevOps:) к этому нужно привыкать.
Запустил grep и проверяем что обнаружилось. Потом опять этот же grep и парсим через awk {print $1}... Сейчас это почти норма...:(
Ну почему? Почему в 99.9% ситуаций, когда я вижу использование awk, это непременно стереотипный awk '{print $1}' ? =)
$ cat test.txt | grep keyword | wc -lиз этой же оперы, а ведь можно же просто
$ grep -c keyword test.txtP.S.
помню парсил как то большие логи - 100-200 гб и вот такие моменты там очень были заметны в контексте скорости выполнения. Иногда разница доходила до 15-20 минут
Кстати, я нашел ответ на вопрос «а почему лично я делаю cat | grep”. Ответ простой: можно потом ^W удалить поисковый запрос и попробовать другой. А потом, когда найдется нужное, можно сразу не меняя команду приписать wc-l.
Потому, что реальная работа - это не сделать красиво и не сделать правильно. Это сделать быстро и эффективно.
Можно еще и упихивать весь выхлоп в sql в том же единственном вызове awk, а то некоторые особо одаренные по отдельной команде на каждое поле шарашат и удивляются, чего это всего пара тысяч строк 20 минут парсятся
Потому, что они не знают про наличие утилиты cut и кто-то когда-то на StackOverflow написал вот такой пример.
Технологии которые мы заслужили, че.
А зачем? Если это скрипт, постоянно работающий с большими файлами - может, и имеет смысл. Но если это разовая задача, то на написание кода на awk будет потрачено больше времени, чем не отрывая рук набить пайп из простых как молоток grep - cut - sed s///g - sort - head.
Потому, что это возможно! =)
Не, на самом деле для разовой операции и правда быстрее набить неоптимальную портянку с кучей пайпов. Но если нужно такое делать регулярно, то чистый awk мне в ряде случаев давал натурально стократный прирост в скорости. Только вот я даже в таких ситуациях чаще всего вижу скриптик, в котором написали портянку с пайпами.
А зачем вам cat?
у вас нет парсинга айпи адресов, тупо сортировка строк, и учитывая что лог начинается с даты, у вас все строки уникальные. Какой тут вообще результат предполагается?
Ожидалось хотя бы выкусить айпи адреса из строки, и уже их сортировать.
cat порой нужен для файлов которые в текущий момент времени открыты в приложении, так как позволяют зафиксировать их содержимое.
Так следующий grep/sort или еще что-то, сделает тоже самое - прочитает и зафиксирует содержимое. Под капотом и греп и cat/tac читают построчно
cat порой быстрее grep, что важно в случае большого потока логов и возможности ротации файлов прям из под ног grep. Кейс редкий, но привык уже сначала вывод файла в stdout, потом манипуляции над ним.
хм. вы уверены, что cat считывает весь файл в память, перед тем как передать его в пайп?
Я вот сомневаюсь, там какой-то буфер есть, но cat точно не будет гигабайтный файл грузить в память, перед тем как переслать его дальше.
А если так, то cat file | grep и grep file будут почти одинаковы. Минус пару миллисекунд на лишний процесс
TL;DR: пайп позволяет визуально отделить вход от выхода и совершать меньше действий в процессе правки команды
В своём рассуждении, вы ловко выкинули из примеров команд pattern:
grep pattern file
cat file | grep patternА ведь чаще всего вы будете нажимать стрелку вверх и менять именно паттерн (или даже весь grep) при том, что имя файла будет оставаться фиксированным. Но каждый раз, нажимая стрелку вверх, ваш курсор будет оказываться в конце строки, т.е. рядом с file, и вам каждый раз нужно будет перепрыгивать его, чтобы добраться до паттерна, который будет за сессию работы меняться куда чаще. Лично мне лишние прыжки через имя файла удовольствия не доставляют, поэтому я сознательно использую cat. Вы, конечно, можете опротестовать и предложить мне более эффективную (с точки зрения машины) альтернативу:
< file grep patternНо. Стрелку легко перепутать, уничтожив файл. Во-первых, стрелки рядом на клавиатуре; во-вторых, даже будь они далеко — перепутать их всё ещё можно. Ещё здесь нет явного и заметного разделителя, который было бы удобно искать глазами — имя файла миксуется с командой; в случае с cat такой разделитель есть — пайп. Да и просто же выглядит довольно уродливо
Ну я могу предложить другую альтернативу
^oldfile^newfile^
или если у вас так часто используется эта конкретная команда, заюзайте там имя переменной вместо имени файла
Никто не мешает вам пользоваться вашим любимым способом.
У меня основная претензия была к "cat порой нужен для файлов которые в текущий момент времени открыты в приложении, так как позволяют зафиксировать их содержимое." - вот с этим я не согласен
За 'cat' я бы сразу посылал в пешее эротическое. Гуманитарию простительно, конечно...
cat x | grep y
удобнее использовать, если надо погрепать много разных y: Up,^W - и можно писать новый y. А в виде grep y x надо ещё каждый раз позиционировать курсор, прежде чем стирать y.
Можно так:
echo x | xargs grep yНе совсем понял что имеется ввиду?
Я отвечал на комментарий, что cat простителен только гумманитариям. Видимо, хардкорные технари должны испытывать нечеловеческие мучения, глядя, как cat f | grep x теряет немного производительности и создаёт лишние процессы по сравнению с grep x f.
ИМХО для разовой задачи это вообще не имеет значения, да и для периодической разница будет малозначительна, всё равно оно в чтение с диска упирается, а не в перекидывание строк внутри оперативной памяти.
Производительности он не теряет. Но меня пытаются убедить, что cat быстро считывает текущий файл, а греп читает его долго. И в случае, когда в этот файл кто-то еще пишет, может быть разница. Ситуацию хотелось бы прояснить, я в такое неверю. Не смотрел исходники cat, но все стандартные гну тулс читают файл построчно и память под весь файл аллоцируют разве что всякие сорт, которым это необходимо.
Немного теряет, как минимум на переключения контекста: положить данные в пайп - сикол из одного процесса, вынуть данные из пайпа - сискол другого процесса. Но на современном железе это будет на уровне погрешности, упрётся в чтение с диска.
В остальном вы правы: 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.
не имея ни одной сертификации да и вообще будучи гуманитарием, для
которого IT - ни разу не специальность, я за 3 минуты и 2 подглядывания в
man написал примерно это:cat /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -bgr | head -n10
верим, верим
Не смог за полчаса распарсить лог веб сервера Apache и найти топ самых часто встречаемых IP адресов.
Блин, ну полчаса на такую задачу это же перебор.
Я считаю, что девоп инженер (автоматизатор же), должен неплохо знать хотя бы один скриптовый язык, которые работает с текстом. Эта штука даже в awk по идее решается за полчаса, хотя там синтаксис не всем нравится.
Не хочу принижать опыт, верю, что он есть. Но я в поддержку набирал людей, которые должны ответить на эти вопросы за 10 минут освежив знания в гугле. Потому что это базовый уровень, который я получил в колледже 20 лет назад. Банально, если человек приходил на занятия и выполнял лабораторки, то ничего сложного в задачах не вижу.
А ситуацию с долгим поиском работы надо воспринимать спокойно — это просто показатель того, что вы не подошли собеседующему.
Have you worked with a difficult client? How did you handle it?
Способы хэндлить сложного клиента? Мне одному приходит в голову плохое? :)
Хм... задумался. Я начинал свою карьеру в IT четверть века назад (в том, что сейчас называют Ops, а тогда это было администрирование). За это время я успел освоить Windows Server 2003 (включая развертывание своего леса, миграции контроллеров итп). Потом сменив работу освоил Фрю и Циску (не как эксперт, но понять что не так и подправить роутера конфиг мог). Дальше были ПО для обмена сообщениями и сервера приложений (а параллельно немного БД, немного Unix). Системы автоматизации и контейнеры. Сейчас вот облака...
При этом информация про технологию CSMA/CD используемую в Ethernet, про которую мне рассказывали в универе мне пригодилась один раз - и то на собеседовании. Если в начале карьеры, когда инет был диалапный, знания "в голове" были необходимы потому, что по другому их не получишь. То сейчас мне хватает понимания, что это примерно делается так, а дальше за точной командой я просто открою гугл.
Помню, для одного заказчика пришлось писать скрипт по поиску и удалению старых файлов, которые ежедневно генерировались в огромных количествах. Первый раз я потратил пару дней (с учётом других задач) прежде чем с помощью гугла нашёл набор подходящих ключей для команды find. Пару лет спустя, на другом проекте, когда возникла аналогичная задача - я восстановил тот же скрипт опять используя гугл, просто потому, что нет никакого смысла помнить все ключи этой команды все эти годы. Но да, мне потребовалось всего пара часов, так как я "в общем" помнил направление в котором надо идти.
Не скажу за стартапы, где команда состоит из 10-20-30 человек, но на проектах, где я обычно участвую, только IT отдел состоит из нескольких сотен человек. И человек отвечающий за автоматизацию отдельного проекта никогда не будет настраивать сам доступ в интернет, устанавливать и конфигурировать БД, создавать пользователей, или отвечать за железо (физическое или виртуальное). Для всего этого есть свои отделы, и от тебя требуется запомнить, как они называются, и кого в каком случае надо дёргать.
Поэтому конечно команды traceroute / tracert, ping, ifconfig / ipconfig я знаю. Но если они показывают что-то не то, то дальше это вопрос к сетевому инженеру, которому я передам обнаруженное. Аналогично я пользуюсь иногда командами ps -fu / ps -a |grep, но опять же не лезу в особенности вывода. Если потребуется - я через гугл найду какие параметры нужно ему задать, чтобы узнать, что мне нужно.
С этой точки зрения, я скорее всего не пройду собеседование, если попросят написать "на бумажке" скрипт или объяснить какие-то параметры в выводе, которыми я не пользовался в последние дни. Но наработанный опыт даёт определённое понимание, что происходит под капотом, так что при необходимости разобраться я сумею.
Впрочем, я уже безусловно не отношусь к числу "энтузиастов ИТ", а скорее к числу "работников в ИТ". Но опять же судя по отзывам "бизнеса" их это вполне устраивает, когда продукт выполняет заданные функции, а не реализует всё новый и новый функционал, но не слишком стабильно. Наверное это не самая лучшая стратегия для стартапа, но для крупных контор - это гораздо практичнее.
Самое печальное, что devops это не сети, не операционка как пишет автор, и уж тем более не кубер… вообще devops != инструмент. И уж тем более печально, когда заправляют devops , смазкой в виде sre. Все хотят специалиста «эксперта 6в1», но как посмотришь на зарплату которую готовы платить такому специалисту, хочется плакать, толи со смеху, толи от абсурда. Да безусловно плохо когда кандидат много чего не знает, и для него сфера только приток денег (без удовольствия). Таких видно из далека. Но как тошнит от таких «душнил» на собеседовании, дотошно спрашивая порой то что действительно ты не увидишь, не то что в своей деятельности, но и непосредственно в работе, ввиду ряда ограничений компании (имея другой специализированный отдел), даже ты можешь быть готовым работать с базами в каком нибудь банке, но тебе не дадут так как есть отдел DBA и.т.д.
О девопсе как-то вообще принято писать как о чисто техническом наборе большого количества (современных и стремительно устаревающих) технологий. Хотя у тех же Дебуа-Хамбла чётко написано, что ДевОпс это не только и не столько технологии, сколько организация рабочего процесса в (действительно сложной) системе. Это прежде всего построение процессов. В том числе и на самом верху, в области непререкаемого авторитета высшего менеджмента.
И вот высший менеджмент выкатил и начал претворять в жизнь бизнес-план, который не соответствует действительности. "Мы наймём девопсов!". Там за забором очередь, да? Где их обучают? Приедут ли они оттуда к вам? Сколько времени они обучаются? Не устаревают ли за время обучения технологии? "Это устаревший подход! Нам нужны с горящими глазами!". Как вы посчитали их количество, что решили, что найдёте достаточно? откуда берутся эти горящие? как на них влияет общая картина происходящего? Есть ли вообще шанс у такого горящего жить полноценной жизнью, и как долго он проработает в нужном вам качестве при таких условиях?
Но проблема, конечно, в уровне кандидатов. Как всегда.
> Так вот, если сейчас меня спросить про тот самый сервер и тонкости работы с XMPP - Я НЕ ПОМНЮ
это нормально, если бы проводил с Вами интервью вероятно 10 мин хватило бы в основном понять что именно знаете, скажу откровенно из своего резюме примерно 90% вообще с трудом припоминаю, причем забыл сознательно что не просто, чтобы голову не забивать, иначе работать невозможно, если все помнить, столько накопилось
Ладно там "20 лет назад". Я всё время имею дело с микроконтроллерами вообще и с клонами STM32 в частности прямо сейчас. Иногда делаешь что-нибудь типа приёма и передачи через USART с помощью DMA. А через три дня вообще не помнишь как там это DMA настраивать для другой задачи на МК другой серии. Но это и не нужно помнить в точности. Главное знать принципы работы и куда посмотреть чтоб вспомнить подробности. Тем более, что от серии к серии немного меняются настройки регистров и всё равно приходится открывать мануал и смотреть что там конкретно для этой серии.
И уж тем более мне не придёт в голову требовать знание всей этой кухни в подробностях. Можно даже вообще не иметь дело с железом и не знать про всякие там I2C, SPI и DMA. Главное уметь прочитать инфу и понять её.
Специально просматривал все ответы, чтобы найти этот, который отражает и мою реакцию. Тимлид это уже менеджер, а это совершенно другой набор скилов, и суждений которые надо развивать. Частая ошибка молодых тимлидов спрашивать экциклопедические вопросы и потом удивляться, что никого на рынке нет, зато самими себя чувствовать от этого "хорошо".
Чтобы задавать, как Вы их назвали, "real-life задачи", и нанимать тех, кто уже знает как такие задачи решаются, нужна уверенность, что ничего кроме перечисленных во время собеса задач данному кандидату за время работы в нашей компании решать не придётся. Такое, конечно, тоже встречается, особенно в компаниях с громадным штатом, которым нужна пара сотен миддлов однотипно перекладывать JSON в сотне типовых микросервисов, к примеру, но…
Очень часто от кандидата требуется не умение решать ограниченный набор заранее известных задач, а умение находить решение неизвестных ему заранее задач. Не потому что мы такие вредные и жаждем показать кандидату его полную несостоятельность, а потому, что требования бизнеса постоянно меняются, инструменты развиваются и заменяются, окружающая среда регулярно подкидывает новые неожиданные особенности, etc. - и в результате мы просто не имеем гарантированного и достаточного количества однообразных задач, которыми можно было бы загрузить сотрудника на full time на ближайший год. И вот тут понимание базовых вещей вроде упомянутых в статье становится критично важным.
Более того, на мой взгляд здесь проходит принципиальная граница между миддлом и сениором: если у миддла ещё иногда бывает такое, что он годами сидит на потоке привычных ему задач не требующих особо часто включать голову, то сениор по определению должен быть готов сделать любую задачу, включая совершенно ему незнакомые.
При этом сейчас стало много "войтивайти", которые прошли курсы/стажировку, поработали пол года в одной компании, и решили, что на этом напряг из-за необходимости изучать что-то закончился, что они уже стали состоявшимися специалистами, которым достаточно просто продолжать делать то, чему они научились (ведь на текущей работе этого хватает!), и сменив работу 2-3 раза за следующие 3-4 года они автоматически дорастут до "достойной их" зарплаты и лычки "сениор". А статьи вроде текущей - это просто следствие:
Интервьювер недоумевает, почему указанные в резюме технологии кандидат знает исключительно на уровне механического решения нескольких заранее известных кандидату задач;
Кандидат недоумевает, почему у него спрашивают какие-то "оторванные от реальности" базовые знания, вместо того чтобы убедиться, что кандидат отлично умеет справляться с несколькими знакомыми ему "real-life" задачами, чего ему вполне хватало на прошлой работе.
Очень часто от кандидата требуется не умение решать ограниченный набор заранее известных задач, а умение находить решение неизвестных ему заранее задач. Не потому что мы такие вредные и жаждем показать кандидату его полную несостоятельность, а потому, что требования бизнеса постоянно меняются, инструменты развиваются и заменяются, окружающая среда регулярно подкидывает новые неожиданные особенности, etc. - и в результате мы просто не имеем гарантированного и достаточного количества однообразных задач, которыми можно было бы загрузить сотрудника на full time на ближайший год. И вот тут понимание базовых вещей вроде упомянутых в статье становится критично важным.
а потом получаем как в гугл/яндексе - тебя мурыжат 5-7 собеседований, ты рисуешь им архитектуры и рассказываешь о системном дизайне. Ты уже вот вот шатл в космос будешь запускать. Выходишь на работу и по факту на проекте перекладываешь json'ы, а не вот это вот все )))
Я — айтишник, я не хочу много знать
Я вот не хочу знать много. Я хочу знать ВСЁ!
@jumper_xf-666,привет коллега.
Провел сотни интервью на позиции девопс и л3 саппорт инженер.
Все именно так.
В резюме кандидат сворачивает горы, знает кучу технологий. На деле - был отдел инженеров, за технологии отвечал кто-то еще, сам кандидат хорошо если подправлял уже существующее.
Глобальное, просто повсеместное незнание базовых вещей, базовых терминов.
Люди не знают чем гит отличается от гитлаб.
Не знают чем терминал отличается от шелла.
Сеньерные кандидаты не способны правильно пояснить банальные POSIX права доступа, путаются кто такой юзер в этих правах (зачастую это те, кто пришел в девопсы не из сисадминов а из девелоперов/саппорта/QA)
И так далее, так далее, так далее.
Ставят прометей, потому что там готовая связка штатных экспортеров и дашборов в графане для кубера, при этом смысла в этом мониторинге не очень много, потому что метрики самих приложений он не вытягивает, только самого куберкластера, и сделать что-то кастомное, например просто вытянуть из джавы данные по актуатору или jmx, если джава крутится внутри контейнера - даже не представляют как..
В резюме кандидат сворачивает горы, знает кучу технологий.
Так ведь индустрия сама приучила писать все эти горы. И не научилась писать описания вакансий.
Таких, что "Вам нужно знать и уметь то-то и тот-то до такого-то уровня. Иначе не возьмем." И потом действительно не брать, потому что все что указано в вакансии - действительно нужно. А если знает (или успел выучить по указанным требованиям) то, наоборот, гарантированно брать.
Ну вот так взаимно друг другу голову и морочим.
Окей, примеры с моих интервью:
В резюме кандидат администрирует сотни вирутальных машин с разными линуксами, мониторит их.
На интервью не может распарсить -rwsr-xr-x вообще, не знает чем в топе USR отличается от SYS на загрузке процессора.
В резюме пишет что пишет много скриптов на баш.
Спрашиваю как почистить старые логи в директории - отвечает что ну напишу скрипт, в котором выполню команду ls, потом отсортирую по дате и удалю. Я показываю вывод ls, где формат даты совершенно неудобный для сортировки, начинается бекание мекание. Процентов 15 знает про find.
И так по всем темам.
И очень нравится, когда в ответах идет "это было давно, 3 года назад, я уже не помню что там было".
Я не знаю, я суть технологий с которыми работал 20 лет назад еще помню. Я могу детальный синтаксис не вспомнить, но понимать что и зачем делалось, а люди 2-3 года назад и вообще не помнят что там делалось...
Если человек работал с базами данных, у меня один из любимых вопросов - сколько времени занимал бэкап или какого примерно размера была самая большая база. Это как показатель, человек осознанно этим занимался или нет. И многие просто не знают/не помнят. Видимо никогда не делали тестовый рековер из бэкапа, чтобы знать сколько он займет и вообще работает или нет.
Тут проблема, что используемое 'работал', 'имел опыт работы' - вообще мало о чем говорят. Прошел начальный курс по соответствующему ключевому слову - это 'работал' или еще нет? Стандартных используемых словесных конструкций не хватает. С точки зрения кандидата - он действительно как-то слегка работал. Так и написал. А вы его, внезапно, 'валите'.
Почему вообще есть инициатива заталкивать в резюме подобные строчки по тому, где наизусть справочник по технологии не помнишь?
Как по вакансии отличать таких как вы от тех, кому того уровня умений, что имеешь, будет достаточно? И что писать в резюме, чтобы те, кому надо больше, чем умеешь, не приглашали?
С другой стороны, я почти уверен, что многие из таких кандидатов без проблем смогут задать вам вопрос, ответ на который для них очевиден и это знание считается базовым, а вы на него не сможете сходу ответить.
Неготовность сходу отвечать на вопросы зачастую говорит не о низком уровне соискателя, а о том, что его "быстрые знания" слабо пересекаются с вашими потребностями.
То есть исходя из моих примеров, девопс на мидл-сеньор позицию, который не знает как удалять старые файлы (логи) логи это нормально?
Так ведь логами обычно что-нибудь специализированное занимается, там надо не скрипты с сортировкой по дате писать, а указать в конфиге сколько логов хранить...
Вот-вот, вы тоже не прошли.
Какие нафиг скрипты с сортировкой, если есть find / logrotate, а некоторые приложения действительно сами умеют этим заниматься. Но не все.
Что-то я не понял сути претензии. Хотите сказать, что logrotate не является специализированным приложением для управления логами?
Хочу сказать, что кандидаты, которые подаются на мидл и сеньор позицию не знают этих инструментов, и вопрос удаления старых логов или ротация логов ставит их в тупик, хотя это достаточно штатная задача.
Возможно это засилье людей, которые не видели софт без контейнеров, но для меня это выглядит как отсутствие базовых навыков.
если есть find / logrotate
А кто-то скажет, что logrotate древняя древность, в большинстве дистрибутивов у нас systemd и ротацию логов нужно настраивать в journald.conf да и вообще, логи нужно хранить в каком-нибудь GrayLog или ELK
Ну вот уже неплохо, будет понятно как человек решал подобные задачи.
Ну вот и имеем ситуацию, что для одного базовые навыки - это logrotate с которым он познакомился в начале своей карьеры, тыкая LAMP на первой работе в нулевые, а для другого базовые навыки - это ELK, с которым он познакомился в начале своей карьеры, тыкая k8s на первой работе в двадцатые.
И при этом второй без проблем, почитав доку, настроит logrotate, просто он с ним не работал ранее. И find-ом он пользуется от случая к случаю, поэтому чтобы составить на нем патч Бармина, ему нужна дока. Плохой ли он специалист из-за этого?
Базовые навыки - это изначально был вопрос как удалять старые файлы. И логротейт к этому имеет опосредственное отношение.
В случае с ЕЛК тоже неплохо бы понимать как логи попадают в этот ЕЛК - может быть там обычные файловые логи, которые читают файлбитом/флюентД и их все равно нужно потом чистить.
А если это файловые логи, то неплохо бы подобрать оптимальную fs стораджа и потюнить ее, потом можно дойти до уровня железа и т.д. А с другой стороны, если у нас ELK, то неплохо бы напилить по логам доп. метрик, ETL пайплайн и выгрузку в корпоративный datalake. По этой вертикали абстракций можно туда-сюда в очень большом диапазоне ездить. Я к тому, что если ваша позиция требует получше знать одну область этой вертикали, а соискатель лучше ориентируется в другой, то это еще не означает, что он плохой спец, он просто вам не подходит. Зато может подойти кому-то, у кого тюнингом и наведением порядка в оси занимаются отдельные люди, а от девопса требуется умение общаться с бизнесом. Он и вам может в итоге подойти, если обучаем и у вас есть ресурсы на его обучение.
Я не знаю, я суть технологий с которыми работал 20 лет назад еще помню. Я могу детальный синтаксис не вспомнить, но понимать что и зачем делалось, а люди 2-3 года назад и вообще не помнят что там делалось...
Ну таки люди все разные. Я вот года 4 назад работал с ElasticSearch (не очень глубоко но работал, строил индексы, решал проблемы синхронизации). Если сейчас меня по нему начать спрашивать - я не отвечу ничего. Use it or loose it.
У меня вопрос по эластику был бы таким
как данные попадали в эластик, какого объема, был ли ретеншн, по какому принципу именовали индексы, как раскидывали индексы по нодам.
Ничего глубоко технического, именно прикладное, чтобы было понятно что человек эластик настраивал для того, чтобы получить пользу и решал проблемы, которые чаще всего встречаются при больших объемах.
Время восстановления из бекапа для современных серверов не сильно зависит от размера базы, но сильно зависит от ее структуры.
И да, данные о эре — pre-NVME вообще неактуальны теперь.
Я бы на этот вопрос на собеседовании вообще отказался отвечать без уточнения.\
Про logrotate из вашего вопроса я бы не вспомнил просто так он у вас составлен. Хотя я про него знаю. Вы же не спросили какими это утилитами решается в системе, вы спросили как велосипед написать.
У меня почему-то сразу вопрос возник: сколько (и в какой локации) ваша организация платит людям, которые всё это знают? Прямо с применением чисел, а не грейдов и «it depends».
Ну и Вы сами ответили на свою статью внизу: Вы ищете таких же энтузиастов, каким являетесь сам, а их относительно мало, и действительно много где людям сходят с рук чудовищные (для энтузиаста) вещи. Так что Вам нужно делать выбор - нанимать уже готовых «битых» и страдать от выхода в доли процента, либо нанимать обучаемых и учить, либо самому учиться пасти обыкновенных.
На мой взгляд процесс найма/поиска работы в IT в принципе сломан. Потому, что есть множество областей знаний, которые обозначены формально (Linux/Unix, TCP/IP, CI/CD, Configuration management), а спрашивают по ним конкретно.
Возьмём, к примеру, получение прав на вождение машины. Есть правила дорожного движения - книжечка которую можно купить. Есть экзаменационные вопросы. Примеры экзаменов. Теоретический экзамен. Практический экзамен. Понятно, что от тебя ждут и как к этому подготовиться.
Теперь вернемся в IT. У меня несколько Linux сертификатов. (Готовился, покупал курсы, книги, сдавал экзамены). На работе - Linux. На домашнем компе - Linux. Все деплойменты в продакшен только через Ansible.
Можно ли утверждать, что я знаю Linux?
Где та линейка, которой можно померять знания?
В случае с водительскими правами это гос экзамен.
В случае Linux спрашивать могут что угодно.
IT - очень большая и сложная предметная область. Очевидно, что точно описать чьи-то знания даже в отдельной её части односложно - малореально.
Соответственно имеет смысл принимать не по знаниям, а по IQ, если IQ>140 таких 1 на 10 000 населения, бесценный сотрудник. Если ниже 110 то в ИТ ловить нечего. Потолок развития сисадмин аникейщик.
Потому, что есть множество областей знаний, которые обозначены формально (Linux/Unix, TCP/IP, CI/CD, Configuration management), а спрашивают по ним конкретно.
Это так в любой более-менее сложной дисциплине, в них всегда приобретается некоторая узкая специализация. Если я закончил физфак, можно ли сказать, что я знаю физику? Если я окончил машиностроительный, значит ли это что я смогу спроектировать эффективную турбину? Так же и тут. Да и права, это просто показатель того, что вы владеете неким заранее установленным минимумом навыков, который считается достаточным, чтобы допустить вас к управлению ТС на дорогах общего пользования. Это даже не означает, что вы хороший водитель и понимаете все нюансы управления автомобилем – отправь вас на кольцевые гонки, или ралли и вы с огромной вероятностью либо придете последним, либо перевернетесь, так что и это не "линейка".
Примерно поэтому в IT платят больше, чем водителям. Формализовать требования просто для доступных широким массам областей, но чем выше порог входа и объём знаний в области, тем шире требования.
Если есть сомнения, то вот пример. В айти высококвалифицированный спец может решить сложную задачу в сто раз быстрее и лучше, чем низковалифицированный. И вообще решить, а не сломаться. А в вождении грузовых авто высококвалифицированный водитель может доставить груз быстрее и с меньшими рисками, чем низкоквалифицированный, но разница по скорости и рискам будет в лучшем случае в десятки процентов, но не в десять тысяч процентов.
Я просто оставлю здесь вот это...
Захотелось отправить вам резюме
Почини утюг, тыж програмистр)
Ощущается прилив радости, и появляется настрой на интересный продуктивный для обеих сторон разговор.
Так охладите траханье или воспользуйтесь предназначенными для этих целей развлекательными сервисами в интернете. Обычно люди на собеседование идут не для интересных разговоров, а чтобы устроиться на работу, понять со стороны работодателя какими навыками обладает кандидат, а со стороны работника, какие обязанности и условия работы его ждут.
"Креативь" то, сам не знаю что - едва ли кому-то может понравиться в собеседование, тем более в самой работе
Резюме не имеет ничего общего с реальными знаниями и навыками соискателяКак и описания вакансий. 1:1, побеждает дружба.
Очередной автор с завышенными требованиями. Как сам и написал - должны глаза гореть, только у уже повзрослевших ИТ-шников - семьи и куча другой суеты, и для них работа - это просто работа, если надо они разберутся в чём то новом, а автор продолжает жить в розовом мире 00-ых, когда ИТ-шников было мало и у них реально горели глаза, потому что для них это было больше хобби.
Другим ярчайшим и популярным примером про неразрывность инструментов и методологий, как мне кажется, является разговор про CI/CD. Зачастую, CI/CD - это Gitlab CI, Teamcity или Jenkins, а не методологии, решающие конкретный список проблем/задач в процессах разработки
Это конечно методологии, но существует ряд мейнстримовых инструментов, используемых для их реализации, и люди на рынке в массе своей владеют именно мейнстримовыми инструментами. Не их вина, что вы написали свои велосипеды. В конце концов, операционная система тоже не одна на рынке, но вы же требуете от людей знаний конкретных реализаций (Linux) а не только лишь понимания общей концепции. Если вы не пользуетесь мейнстримом, то и выбор кандидатов для вас сокращается естественным образом, сетовать на это как-то странно.
Пока я читал пост и комментарии, родилась мысль, которой мне хочется поделиться. А что, если не соискатель будет ходить на собеседования, а наоборот – эйчар, представитель генерального и сеньёр будут ходить на ярмарку вакансий, очно. «Здравствуйте. Из какой вы организации ? Почему я должен работать у вас ?» и далее по смыслу ?
по опыту работы в us, все это давно существует, проводится регулярно, типа снимается зал где-нибудь в гостинице на один день, дается объявление, приезжают представители компаний, обычно несколько десятков, приходят люди и разговаривают в довольно свободной обстановке, компании собирают резюме, дальше звонят как обычно, приходилось бывать конечно, но самый правильный путь к новой работе это networking, т.е. просто дать знать бывшим коллегам которые работают в разных компаниях, что типа свободен, более того в действительно интересные проекты в основном так людей и набирают
Ходят, только за специалистами более высокого уровня с зарплатами потенциальными в миллионы $, это научные сотрудники молодые с высоким потенциалом, золотомедалисты уже проявившие себя в научной среде. Вот тут интересная статья, как на таких выходят, что предлагают: https://www.nanonewsnet.ru/blog/nikst/filipp-io-vorovstvo-prekrasnaya-strategiya
...Филипп Йо с удовольствием рассказал нам, зачем страна тратит миллиарды долларов на развитие инновационной экономики и почему главным направлением его текущей работы стала широкомасштабная программа по стимулированию притока лучших мозгов. ...
это научные сотрудники молодые с высоким потенциалом
За потенциалом не ходят. Ходят за подтвержденным опытом.
именно, просто минимизация рисков, но в us особенно ни за кем не ходят, а если и ходят, то недолго, рынок большой, так навскидку 40% инженеров us занимаются sw, кандидатов из других стран тоже достаточно
За мной постоянно ходят именно из us, был бы согласен переехать в помойку — озолотился бы.
возможно уникальный опыт, просто интересно, может намекнете типа чем занимаетесь, свой уровень, и какую примерно помойку Вам предлагают?
если конечно Вы имеете в виду компании, а не headhunters, что в общем не слишком серьезно
ps
коротко посмотрел Ваши статьи, но таки ничего не заметил, что могло бы вызвать повышенный интерес и прочие перспективы, QA конечно востребован, но там озолотиться вряд ли получится
чем занимаетесь, свой уровень
Высокая нагрузка, распределенные вычисления, масштабируемость без потери консенсуса.
имеете в виду компании, а не headhunters
Я имею в виде компании, но headhunters — это более, чем серьезно (не нужно путать с эйчарами).
какую примерно помойку
Дык в основном Долину, конечно, но есть и Бостон, НЙ, Финикс. Не существует зарплаты, ради которой я бы согласился жить в США.
Дык в основном Долину, конечно, но есть и Бостон, НЙ, Финикс.
а можно поподробнее как это выглядит? к вам случится представитель компании из США и предлагает релокацию в штаты прям в лоб? а как они вас находят? линкедин? какойто доступный профиль?
точечное приглашение с оффером и релоком в США это довольно эксклюзивная история (хотябы по бюрократически-миграционным причинам)
офферы из штатовских компаний но с офисом в ЕС — такое бывает, да. но про США прям интересно
предлагает релокацию в штаты прям в лоб?
Предлагает работу, я говорю, что я не в США и не поеду, прощаемся. Я снес линкедин лет пять назад, спам один же.
Предлагает работу, я говорю, что я не в США и не поеду, прощаемся.
ой ну в самом то деле
у меня почта завалена такими предложениями работы, индусы из штатовских хантерских контор постоянно забывают дописать GC/Work permit required и никогда не смотрят на слово I have NOT GС/Work permit в резюме
я пару раз даже собеседование проходил, напрямую говоря что у меня нет разрешения и мне нужна релокация...ok ok… а потом глаза квадратные что ой… оказывается вы не в штатах? (удивильно да, я 5 раз и в резюме и текстом вам это написал, и сейчас словами говорю)
а предложение по работе они рассылают ковровыми бомбардировками, также как и наши Россиянские HR-ы
так что не льстите себе, никто за вами из штатов не бегает, и не зовет туда
а чтобы вас перестали туда звать уточните откуда они ваши данные берут, я в их списки рассылки попал когда в начале 10х пытался на h1b подаваться
не льстите себе
Хорошо, хорошо, не буду, не волнуйтесь так только. Вы несомненно правы, а я все выдумываю.
> а я все выдумываю ..
все бывает, однако утверждения типа "headhunters — это более, чем серьезно (не нужно путать с эйчарами)" вызывают сомнения, про "помойку" тоже непонятно к чему,
надеюсь Вы понимаете что "headhunters" кормятся с проданной головы, поэтому хотят иметь как можно больше резюме, причем комиссионные у них приличные, поэтому многие компание лучше сотрудникам платят за рекомендации друзей, вместо того чтобы бездельников кормить, с теми "headhunters" что email spam рассылают вообще связываться не стоит, без разницы что обещают, с другой стороны HR это типа отдел кадров компании, говорят и делают что им велено, через них проходят все бумаги при приеме, и дальше они хранят Ваш файл
> я в их списки рассылки попал когда в начале 10х пытался на h1b подаваться ...
большинство "headhunters" подторговывает информацией, часть вероятно прямо из индии
ну ладно ладно ;)
вы просто описали ситуацию как у меня, но я попытался пройти дальше, а не пафосно отказываться от помойки на первом же письме
релок в штаты это сложная и затратная операция, и если на вас целенаправленно выходит HR компании (а не агент или хедхантер) то он это делает по прямой рекомендации и с пониманием что вы не переедете в штаты в течении года точно и вообще не факт что переедете туда если вам обычную визу делать)… но вас надо устроить на работу уже сейчас… причем НЕ в США, по этому целевой хантинг это редкость
, но вы описываете это так что за вами прямо бегают… хотя вы можете(скорее всего должны) переехать в другую страну (не штаты) при самом лучшем стечении обстоятельств… но вы упор сделали в отказе именно от локации — США, в чем нет никакого смысла… вы туда всеравно не попадаете прям сразу (а компания если прям вас так хочет может и оставить вас в Германии или Португалии или Ирландии)… что опятьже подсказывает что вы просто считаете приглашения агентов как настоящие офферы оттуда
Я гражданин ЕС.
вы упор сделали в отказе именно от локации — США, в чем нет никакого смысла
Обалдеть, конечно, вы мастер определения смысла. Причин не хотеть переезжать в США может быть триллион.
Моя супруга, например, так просто на бигкорп в NY работает, ей труднее следующие грейды получать из-за того, что она тут, но, простите, жить в США ради бо́льшей зарплаты — это нужно быть каким-то совершенным Плюшкиным.
Вы еще Китай бы предложили (оттуда тоже предложения есть, если что).
Обалдеть, конечно, вы мастер определения смысла. Причин не хотеть переезжать в США может быть триллион.
нет, вы не поняли, релокация в США обычно занимает 1 год и подразумевает что у работодателя есть офис за пределами… где сотрудник будет работать на время процессинга и работать явно можно там. а не в штатах, но вы отклоняете предложение только по территориальному признаку
p.s. по поводу гражданства ЕС, там вроде есть какието дополнительные визовые варианты… тут по срокам могу плавать
В большой пятерке я работать точно не желаю, по этическим соображениям, а вне оной офис за границей — роскошь, зачем?
Большинство — стартапы, откуда там европейские офисы?
ЕС разный очень, во-первых. А во-вторых — ну вот для меня США не вариант, а ЕС — вполне (за исключением Германии, Франции и Нидерландов).
За сотрудником предпенсионного возраста скорее всего герой статьи не пойдет, там речь о молодых, перспективных, мобильных, недооцененных.
ЖЗЛ про всяких Джобсов и Ньювеллов обычно полно такими "гениальными решениями".
Заметил что чем больше решаю бизнес и архитектурные задачи, тем больше забываю про низкоуровневые тонкости (не базу, а именно тонкости). За спиной больше десяти лет разработки...
Почему все эти статьи ни кто не начинает от проблемы, зачем вам вообще понадобился новый сотрудник и какие задачи он будет решать, откуда эти задачи появились и что с текущими сотрудниками. Исходя из задач, которые он будет решать, строить интервью, все эти статьи больше напоминают найм в какие то галеры, где каждый день новый вызов.
Не знаю, как по мне, так уж лучше пусть такие вопросы задают, чем поверхностное интервью для галочки.
Прошёл я собеседование однажды: попросили только тесты пройти и начертить схему VPC
В итоге, спихнули на меня всё легаси что у них было. Всё рабочее время уходило на чтение криво написанной документации, выслушивание полубреда замучанных сотрудников второй линии поддержки и презентации в PowerPoint. Ещё два года безвозвратно потерянного времени.
За свою карьеру всегда был узкоспециализированным инженером, сперва сетевиком, сисадмином, а потом в девопс ушёл, так как платят лучше)
Есть (точнее уже протухли) сертификаты CCNP, RHCSA, CKA. Проходил много собеседований за всё время.
Так вот - на девопс сложнее всего и проще всего одновременно. Очень широкий спектр возможных вопросов и подготовиться невозможно, ты или знаешь эту область или нет. У меня есть сферы, которые я не знаю и НЕ ХОЧУ туда лезть, потому что не интересно и не моё. Это всякие базы данных например. Не, Я конечно могу поднять любой сервер, но с документацией. Я всегда говорю чтобы кто-то другой этим занимался. И всегда был кто-то другой, а я там в сетях поковыряюсь. Потому что невозможно глубоко знать всё! Я когда был начинающим сетевиком и только CCNA получил - я поражался насколько опытные сисадмины плохо сети понимают, если чуть-чуть отойти от айпишников и масок, а программисты вообще не понимают.
Так вот - если мне задают вопросы на которые я знаю ответы, то легко прохожу, а если не повезёт, то не прохожу)
По мне, идеально было бы если перед собеседованием мне написали - вот такая тема и такая, может быть такой инструмент - или вспомни, или ознакомься, вот на собеседовании и узнаем на сколько человек может быстро и хорошо освоить что-то, ведь суть айти постоянно что-то новое узнавать?)
Очень широкий спектр возможных вопросов и подготовиться невозможно, ты или знаешь эту область или нет.
Это в принципе типично для IT, у каждой компании свой стек и задачи, и некоторые из них начинают почему-то считать, что именно их специфика это и есть "база", которую должны знать все, и пишут потом статьи про то, что вокруг одни тупицы, которые не знают основ. Хотя я не вижу больших проблем просто составить тесты по тем темам которые нужны именно вам и рассылать кандидатам для отсева неподходящих.
Мне тоже нравится идея тестов. Возможно от работодателя или независимых third party.
Проблема в том, что большинство требований в вакансиях выглядит примерно одинаково (к примеру Linux, Python, сети). Описание вакансии в случайную компанию XYZ могут совпадать с описанием на аналогичную должность в FAANG.
Если формально указано, что нужно знать сети. Это в каком объеме? Ping, traceroute, dig или глубже?
Если есть CCNA сертификат, то вопросы по сетям можно пропустить?
В теории, неплохо было бы если компания собрала группу соискателей в одной аудитории. Прочитала им курс лекций в объеме который им необходим. А на следующий день устроила экзамен и взяла на работу тех , кто лучше справился. Но это так, мои мысли в слух.
Если формально указано, что нужно знать сети. Это в каком объеме?
Мне кажется именно тесты как раз хорошо подходят для решения этой проблемы. Если компании нужно чтобы человек знал только самые основы сетей, то и вопросы по сетям там могут быть самые простые. Кроме того, компания легко может сама решить какие вопросы для нее принципиальны, а какие нет, присвоив вопросам соответствующие веса. Для меня, как потенциального соискателя, это тоже был бы только плюс — не нужно ехать на собеседование и тратить кучу времени, чтобы понять, что конкретно скрывается за общими формулировка и вакансии и подхожу ли им я.
Озвучьте, пожалуйста, оклад. На какую зарплату вы искали кандидатов? А то об этом вы скромно умалчиваете, зато требований как на доктора наук.
И зачем вам сотрудники, если вы сами всё знаете и можете настроить так, чтобы никого не нанимать. Или всё же нет?
Многих интересуют только зарплаты, без реального увлечения технологиями.
Удивительно, насколько это для вас неочевидно. Не настолько много айтишников поднялось по пирамиде Маслоу, чтобы иметь возможность увлекаться технологиями.
Не слишком ли широкий спектр обязанностей падает на каждого инженера в нашей команде, может быть нужно делиться по профилям?
По описанию - малёх многовато для одного. Если он и сетевик и DBA и ещё и ямлы куберам изобретать - всё и сразу будет стоить либо довольно дорого. либо всё это будет неглубоко, т.к. многие предпочитают всё же углублять знания, а не расширять. Правда я с программисткой колокольни говорю.
Как раз с программистской точки зрения, пару раз углубил — и вот оно само и расширилось.
Достаточно углубиться в пару-тройку языков с разными парадигмами (хороший набор: джава, раст, хаскель) — и вот уже вы способны создавать хороший код на питоне, тайпскрипте, шарпе, и куче других языков).
Програмист и девопс это все же про маленько разные вещи. И чем ближе к ОС, тем больший не связанного с непосредственно программированием всплывает. Кому cargo build, а кому приходится нюансы шеллов на зоопарке операционок учитывать, всякие стандартные либы нестандартные подсовывать. Тут nix pkg, там bsd приключился, тут ядро без приключений собрано, тут сесурити аудит выглядывает из-за угла и ручкой манит, тут пеп не сошёлся, там абстракции протекли, тут контейнер в море упал и чуть не потопил шард с кубером. И на каждом таком маленьком этапе просто миллион нюансов, которые соло разгребать не сказать чтобы достаточно разумное решение, хотя может и достаточно дешёвое для кампании, если просадок по выполнению тасков не случается.
Не настолько много айтишников поднялось по пирамиде Маслоу
Упал с пирамиды Маслоу :(
А Вы не учитываете, что может Ваш HR слишком сильно ищут такие "супер-пупер" резюме, в которых описаны крутые соискатели. А в действительности есть люди, которые во многом разбираются, но не пишут таких резюме. Конечно можно сказать, что сами соискатели виноваты, что не могут написать резюме, но часто же именно HR отклоняют вполне нормальные резюме, разыскивая чуть ли работников-богов.
Удивительно! Вчера был диалог примерно на эту тему с коллегой: узкий специалист имеет высшую степень квалификации в профессиональной деятельности, но самообразовываться в смежных технологиях неспособен зачастую в силу привычек, вытекающих из особенностей нашего образования. Сущность ЕГЭ - отнюдь не понимание; именно начальная школа закладывает основы того, что любопытство - лишнее, желание экспериментировать - лишнее, учиться на собственных ошибках - вообще глупость, - задача школьника отработать рефлексию для сдачи ЕГЭ. Всё это формирует клиповое, фрагментарное мышление и как самую большую проблему - непонимание причинно-следственных связей в своей профессиональной области - вот и происходит замыкание на узкой специализации, так привычней, стало быть проще. С автором статьи согласен, вопросы верные и в то же время не все однозначно, особенно согласен и с точкой зрения автора комментария с ником "aanovik42". Однозначно, что постоянно нужен диалог, формулировка вопросов, поиск компромиссов.
ЕГЭ-то тут при чём? Чем оно отличается от пяти выпускных и трёх вступительных экзаменов, которые многие сдавали, например в конце 90-х? Формат чуть другой, и явно честнее стало.
А в исходном вопросе у топикстартера очевидно высокие требования к кандидатам (судит по себе, имеет полное право). Только отчего-то жалуется, что всего лишь 10% подходят под такие требования. Очередной плач Ярославны "ИТ-шники уже не те".
"ЕГЭ-то тут при чём?" - я уже взыскал точку зрения о том, что навык не системного мышления формируется в начальной школе. ЕГЭ - цель, закрепляющий этот навык. Дальше - фрагментарное мышление как способ взаимодействия с информационными потоками, в результате - узкая специализация. Про "плач Ярославны": верно, но эти грабли обоюдные, у одних требования как к докторам наук во всех отраслях и дисциплинах, у других навык к фрагментарному мышлению. Проблема тупиковая при её замалчивании. Про "другой формат" экзаменов: ТОТ способ экзаменации и ЕГЭ - это принципиально разные инструменты, определяющие степень компентенций. "...И явно честнее стало" - ваш идеализированное представление об этом выходит за границы солнечной системы.
ЕГЭ - это формат проведения выпускных экзаменов. Формальный контроль знаний, коими были раньше обычные выпускные и вступительные экзамены.
А школьные программы никогда не были ориентированы на "системное мышление" (да и насчёт многих ВУЗов я бы не обольщался). Я сам неплохо помню свои учебники (хотя уже столько лет прошло). Никакого специального обучения системному мышлению там и в помине не было. Очень модно сейчас говорить за это самое СМ, но по факту получается, что есть дети, у которых что-то включается в голове, и они начинают учиться лучше остальных, самостоятельно осваивать программу и что-то сверх неё, интересоваться смежными вопросами и т. п. А у остальных этот тумблер не щёлкает, интерес к познанию как к таковому у них не просыпается, и они тупо заучивают материал, чтобы сдать экзамен и забыть всё в тот же день.
Не вижу принципиальных отличий того, что было раньше от того, что есть сейчас. Да, где-то в идеальном мире вступные екзамены (особенно в свободном формате аля совбеседование) лучше, но в реальном разбиваются об коррупцию. А зубрить в школе сейчас приходится так же как и раньше, разве что объёмы информации увеличились.
Проблема не в формате экзамена. Проблема возникает, если процесс обучения сводится к натаскиванию на сдачу экзамена (не важно какого формата).
навык не системного мышления формируется в начальной школе. ЕГЭ — цель, закрепляющий этот навык
подготовка к экзаменам во вполне советской школе принципиально закрепляла этот навык еще сильнее. Например, тем, что "билеты" были заранее известны, и "подготовка к экзамену" в большинстве случаев сводилась к тупому "зазубриванию билетов". Ну ти как отдельный выдающийся пример — я уже рассказывал, как "англичанка" заставляла "учить тексты к экзамену" начиная с 6 класса. Ну и могу добавить, что медалист у нас переписывал "начисто" сочинение, а на экзамене по алгебре пользовался моими подсказками. Сейчас и узнать заранее, и повлиять на результат оценивания — гораздо сложнее. Т.е. ЕГЭ явно честнее (да, я в курсе 100-балльников по русскому без знания русского языка из нацреспублик, но во-первых, там и без этого было ровно то же, а во-вторых, с этим борятся, и достаточно успешно)
ЕГЭ принципиально лучше тем, что заранее
задача школьника отработать рефлексию для сдачи ЕГЭ
Это если цель 30-50 балов набрать не вникая в предмет, потратив 10-20 часов на обучение, остальное на развлечения. А если цель 100 балов, там нужны знания за пределами школьной программы, лучше по смежным предметам и ясное понимание сути предмета. На Ютубе есть ролики с разбором самых сложных задач, там достаточно интересный подход. У нас в школе до ЕГЭ всё проще было, сравнимая сложность была только на олимпиадах.
честно говоря, не видел, где бы требовались знания за пределами школьной программы. Да и это было бы странно, ибо ЕГЭ — по определению — оценка знаний именно школьной программы, и 100 баллов — это 100% усвоение именно школьной.
Учителя могут не следить за изменениями в ЕГЭ например и не дать навыков в нужной части.
Задачи все равно интересные достаточно, можно просто не понять в некоторых случаях, как применять школьную программу
Или тут
Учителя могут не следить за изменениями в ЕГЭ например и не дать навыков в нужной части.
Я не помню, чтоб были ощутимые изменения в школьной программе. Поэтому школьный учитель должен учить школьной программе, а школьный ЕГЭ контролировать владение школьной программой. Ничего специального, кроме правил оформления, для ЕГЭ, по моему мнению, не нужно....
"не понять" — это немного другое. Я, например, не понимал очень многие задания по информатике. Смешно, но именно так. Мы всем отделом как-то спорили "о смыслах", и "что они в этом задании хотят".
Сейчас такого, вроде бы, уже нет — но вот поначалу та же часть "А" проверяла не столько школьную программу, сколько способность заполнять бланк ответов. А в части "С" были свои неочевидные подводные камни, которые требовали специального изучения чтобы их избежать.
К примеру, вы в курсе, что цикл с условием посередине нарушает теорему Дейкстры и потому (был?) запрещён на ЕГЭ? Он разрешён в школьной программе, он широко используется в практическом программировании, но на ЕГЭ за него снизят оценку.
Ещё скажите, мама виновата. Я провожу собеседования в Дублине, где ЕГЭ сдают c 1924-го года. В следующем году юбилей. Если следовать этой логике, кандидаты должны быть не просто с отбитым любопытством, но с наследственно отбитым любопытством. Однако же, нет, приходят замечательные молодые люди заинтересованные в технологиях и жадные до знаний. Не очень часто, но приходят.
Почитайте статью М. М. Постникова "Школа с уклоном в будущее"
Когда прочитал статью, так и хотелось воскликнуть: "СПАСИБО!" Как в этой гифке:
Сериал Офис
Я, пока что, мало знаю про DevOps (настоящий, а не маркетинговый), но тот бред, что я вижу в обучалках в интернете сводится к тому, что надо уметь раскатывать тыщи инстансов где-то в AWS, а что там под капотом, всем насрать.
Как системного администратора меня это просто бесит! Ведь Ops должен понять, почему что-то отвалилось, если он выставил не тот флаг, а не раскатывать всё заново с нуля по мануалу, как это делал бы я. Ведь нафиг такой devops тогда нужен! Потому что именно devops должен тонко настраивать окружение, чтобы потом не прилетали счета на много-много долларов. Таких случаев полно
По роду работы часто приходится выполнять задачи, связанные с менеджментом проектов. И когда ты аутсорсеру пытаешься на пальцах объяснить что-то элементарное (те же tcp сессии, или хотя бы доступ к субд (а он мне отвечает про доступ к конкретной базе), то хочется прям через трубку вылезти дать в лоб!
Автору,
Шаг 1. Проведите самотестирование своей команды в режиме мы можем без Гугла и прочих помощников сделать вот это. Получаете "чистые" знания.
Шаг 2. Оцениваете, что в вашей компании "чистые" знания стоят столько-то.
Шаг 3. Формируете прайс для спеца, которого ищете. В формате базовый список требований - зп, доп. требования +(сумма) к зп.
Шаг 4. Осознаете, что в мире капитализма базовый фильтр - деньги, если спец по вашему прайсу стоит 300к, а он готов работать за 100к, у меня для вас плохие новости.
Шаг 5. Осознайте, что идейность за деньги не покупается, если вам нужен спец идейный, то это деньги+ реализация потребностей этого спеца, а это уже штучный товар.
Шаг 4. Осознаете, что в мире капитализма базовый фильтр - деньги, если спец по вашему прайсу стоит 300к, а он готов работать за 100к, у меня для вас плохие новости.
Распишите пожалуйста по подробнее.
Может я чего-то не понимаю, но мне казалось что если внутри компании прайс специалиста должного уровня 300к, а новый член команды того же уровня согласен на 100к, то это означает легкое пополнение штата. Подскажите - что здесь плохого?
Шаг 1. Проведите самотестирование своей команды в режиме мы можем без
Гугла и прочих помощников сделать вот это. Получаете "чистые" знания.
даже на CKA экзамене можно пользоваться офф документацией ))) Иначе это была бы шиза - запомни 100500 манифестов и все их параметры (удачи)
Иначе это была бы шиза - запомни 100500 манифестов и все их параметры (удачи)
В этом месте врачи всего мира смотрят на Вас с улыбкой )
Это извечный вопрос по полноте знаний кандидатов на вакансию. Кто-то бьёт себя в грудь и яростно заявляет, что инженер должен знать все! Кто-то говорит, что если кандидат способен решать поставленные задачи за обозначенную сумму, то кошмарить его другими вопросами - идиотизм. И эти два лагеря никогда не придут к единому мнению. В первом случае бизнес не понимает, почему вакансия не закрывается месяцами, а то и годами, а во-втором присутствует негодование по проводу качества результатов работы.
Хотелось бы увидеть описание вакансии, в том виде как оно было опубликовано.
Вот смотрите, я уже лет пять не работал с памятью в Линуксе, за пять лет много чего случилось, и простите, я забыл все эти фундаментальные вещи. Они у меня вытеснились другими знаниями. Но если мне понадобится я найду и освежу их очень быстро. Если ваш мозг устроен так, что вы в состоянии держать в голове информацию, с которой не работаете, мне лично остается только позавидовать.
Завидовать на самом деле мало чему тут. Человек выносит из той или иной сферы именно знания - некий алгоритм: как, куда и для чего. А вот какие то данные, например - термины, наименования и прочее забываются очень легко. Знания используются человеком в разных сферах из-за знакомой схожести в некоторых аспектах сферы деятельности, оттого и запоминаются надолго.
Сами данные - значения со слишком узкой областью применения, которые очень сложно как то сопоставить из сферы к сфере. Держать их в голове означает быть не готовым к получению новых знаний, поскольку не будет места для новых данных. Это сильно урезает способность к адаптации.
Все очень относительно. С одной стороны, 99% выполняемых ежедневно задач DevOps-а не требуют глубинных знаний по IP-адресации. Ему дали вводные, инженер вбил инфу в конфиг и все заработало. Реально он может 20 лет отработать без знания как порезать сетку /8 или /16 на подсети /29 и другие, как работает протоколы OSPF/BGP, чем отличаются POST от GET. С другой стороны, DevOps - это не про деплой, методологию, а про постоянное расширение своих знаний вглубь вширь, про ежедневную учебу.
Совет автору: вам нужно выполнять стандартные DevOps-задачи? Тогда нанимайте людей, которые показали хорошие знания и навыки в вашем DevOps-стеке. И раз в квартал проводите переаттестацию. Планируйте ему трек развития знаний, требуйте (финансовая мотивация) от него непрерывного роста НУЖНЫХ ВАМ дополнительных знаний из базы. Если сразу определитесь, что вам нужны не гении (а готовы им соответственно платить???), а просто качественные работники, то количество собеседований сократится в разы или на порядок. Я сам провел сотни собеседований, сам прошел десятки собеседований и понял одно: нужен усредненный набор знаний и опыта, все что недоучил - доучит в ходе работы. Сделайте сетку из 20-30 навыков от минимального джуна до эксперта/сеньора и разбейте зарплату на маленькие части. По результатам переаттестации и повышайте зарплату на нужное количество ступенек. Не показывает движения 2-3 раза - значит человек не растет, повышать не за что. Если за один квартал/полугодие закрыл несколько пробелов знаний, то повышайте соответственно на эту же сумму. Все должно быть прозрачно и каждый должен понимать, сколько, за что и когда он будет получать в з.п.
Эти же соискатели не согласны с тем, что DevOps инженер это: основы операционных систем, основы баз данных, основы сетей, основы распределенных систем, любые другие основы, не связанные с верхнеуровневым инструментарием и перекладыванием конфигов, для получения очередной абстракции.
DevOps инженер - это сильно размытое понятие с разными требованиями в разных компаниях. Так что они по-своему правы. Во всяком случае, повода для удивления абсолютно нет. Не каждый хочет быть Шивой многоруким, для работника как раз удобнее иметь четко формализованный и ограниченный список умений/обязанностей.
p.s. отдельный вопрос, что на практике частенько на DevOps скидывают всю "мусорную" работу, которой не хочется заниматься программистам. Это тоже, кстати, можно считать нормой, если 1) человека при найме честно предупреждают что в компании процесс построен именно так 2) он за работу будет получать хорошие деньги.
Я думаю, что проблема скорее в финансовом плане. ИТ развивается во все стороны — в нем столько знаний, что нужны существенные затраты времени каждый день на поддержание большого кругозора.
Вопрос: работодатели, а сколько вас готовых оплачивать 8ч рабочего времени, из которого 4 будет потрачено на вашу непосредственно работу, а 4 — работник будет тратить на свое самообучение? Думаю, что это исчезающе малая величина.
По сути каждый из вас ждет, что либо предыдущий работодатель вложится дополнительно в обучение, либо сотрудник будет работать после работы на то же самое. А заниматься этой благотворительностью желающих особо нет. Поэтому большой кругозор сужается до необходимого прямо в текущий момент, а остальное можно довыяснить по мануалам.
либо сотрудник будет работать после работы на то же самое
Ключевой момент.
Из статьи складывается впечатление, что автор лучше тех людей, которые не смогли пройти его собеседование, но если отбросить работу и технические знания, а посмотреть на него и тех кого он собесил как на простых людей в жизни, будет ли автор выглядеть лучше их?
Мне 37 лет, 15 лет в веб-разработке, кучу личного времени трачу на программирование. Как итог - ни семьи, ни детей, ни здоровья (сидеть всю неделю за компом, а потом пару раз в неделю ходить надрываться в качалку - убивает здоровье на ура). Рекомендовал бы я кому-то равняться на себя - определенно нет.
Просто у вас команда мастеров на все руки. У меня такая же, но программистов. В такой приятно работать, но трудно пополнять. А масштабировать вообще не возможно. Большая часть бизнесов устроена не так. Там в команде есть один ведущий, который умеет всякое и сколько-то обычных скучных людей (такие знаете, у которых есть хобби, семья и вообще жизнь помимо работы). Ведущий специалист нарезает задачи для остальных и решает самые сложные проблемы. Соответственно, кандидаты, которые вам встречаются как раз нацелены на такие команды.
Вам наверное нужны девопсы с фундаментом? я честно говоря уже года 3 не видел вывода команды top, потому что образы мне поставляет специальный отдел УСИ и не даёт прав на кастомизацию.
Сети - это максимум нынче маску уазать, IP и сделать заявку опять в отдельный отдел на изменение сетевых сегментов.
Get и Post - нужно знать, что есть постман и какой-нибудь soap ui что есть два метода, которые по разному отправляют данные(P.S. Сам хочу в рест вкатиться через самописные приложения на котлин)
Так вот встречный вопрос, а нужны ли нынешним девопс инженерам эти основы?
Сейчас крупные компании и правда нанимают людей ради хельма\ансибла и ямлики бесконечные, причём проще накинуть подов лишний раз, чем кастомизировать джаву неделю и выиграть пару мегайбайт.
Я вот считаю, что не везде это надо, в хайлоад системе - надо, в малобюджетированном проекте не понятно, в стандартно текущем проекте с хорошим запасом бюджета и нагруженностью в 20% всей арендованной системы, думаю нет.
У меня как программиста часто бывает необходимость решить что-то, что уже решал, но не могу вспомнить подробностей как это было. В таких случаях обычно смотрю свой старый код/проект или иду в гугл. И обычно достаточно беглого взгляда на свое старое решение или мануал/туториал, чтобы все вспомнить и понять, что нужно делать.
Если на собесе спросят что-то подобное, то не уверен, что смогу нормально ответить.
Люди хотят мышкой клацать в гуй, получать зарплату и жить в свое удовольствие, а не погружаться все глубже в профессию. Не один холивар уже был на тему образования, знания алгоритмов, структур данных и прочей базы для тех же программистов. Есть куча людей уверенных, что нужно миллион узкоспециализированных "специалистов" без фундаментальных знаний и навыков. В конечном счете, призывать коллег к совести бесполезно, все решает рынок труда. Когда-нибудь дефицит кадров закончится и всех пассажиров высадят с этого автобуса.
Я думаю, что в основном понятно, о каких специалистах я говорю.
Каждый из этих акронимов приходится гуглить и долго вникать. По моему, это излишний новояз.
Если бы люди договорились о значении слов, не было бы большинства сегодняшних проблем.
Конечно, нужно знать основы. Или хотя бы разбираться в абстракциях как минимум на три уровня ниже. Иначе будет происходить кумулятивное накопление ошибок. За ошибки так или иначе придется заплатить. (цитата из одного журнала, будет здорово, если вы его тоже читаете)
Нежелание погружаться было всегда и никуда оно не денется, но меня немного напряг наезд про то что CI/CD это какие-то там инструменты.
Не в том плане что не нужно разбираться какую задачу они решают и как, сколько о том сколько этих инструментов существуют и насколько по разному решают проблемы.
Я сам не DevOps, а фронт, но за свои 10 лет работы фронтом я очень много раз занимался DevOps делами, потому что DevOps-ов всегда меньше чем нужно или вовсе нет.
И каждый раз приходя на новую работу я вижу новую балалайку. То там TeamCity со своим Kotlin, то Jenkins со своим Groovey, то Gitlab CI с Shell, то Bamboo. И ладно бы просто разные платформы, но одна суть, но нет. Каждый раз ты приходишь на проект и видишь очередное решение той же задачи только новым способом.
И в этом плане я больше буду рад если DevOps внедрит готовый, понятный инструмент, использует готовый подход и решение, даже если оно чуть-чуть менее эффективно.
Зато поддержка этого будет простой, я как фронт легко туда залезу и все подправлю, и не буду вынужден знать всех тонкостей этого DevOps мира
Потому что сегодня вы все настроили, оно собирается, а завтра оно взорвалось и копать это будет либо другой DevOps, а скорее всего кто-то из разрабов и там все должно быть тупо и легко гуглиться.
Респект за статью. Наконец то кто-то начинает прозревать как РЕАЛЬНО дела обстоят с айти. Это к сожалению то, к чему мы пришли за 10-20 лет. Не уверен есть это хорошо или плохо, так же не уверен что будет через даже пару лет. Будет ли айти вообще существовать.
Но в статье абсолютно правильно захайлайчены проблемы: сам HR, сам хайринг и отсутствие компетенции у хедов и хайринг менеджеров (не обязательно из-за отсутствия компетенции а просто иногда закрывают глаза на бред из-за проплаченного капитала) привело естественным образом к тому, что единственная успешная бизнес модель соискателя выглядит примерно так: 1. Выучил теорию, типа курса или книжки по какому-то узкому стэку, 2. Произвёл впечатление на интервью, ведь конечно после книжки ты знаешь очень много специфических мелочей. 3. Получил оффер и через несколько месяцев джоб хопнул. 4. Технология сама за это время или умерла или изменилась до неузнаваемости, что на эти прошлые знания в принципе похрен. Да на них было сразу похрен после прохождения интервью и получения оффера.
В итоге что мы имеем: частое выгорание (из-за изучения ненужных краткосрочных знаний вместо фундаментальных) и растущие в небеса зарплаты и требования работодателей из-за джоб хоппинга постоянного.
Смотрите AWS сейчас делает то же самое предоставляя их множество "managed" решений, типа баз данных, лоад балансера. При этом по сути разница в себестоимости раза в два (если бы я сам их ставил не managed на своём vps). Это игра с дьяволом, в один конец: в итоге когда все научатся кликать этот AWS (что само по себе не очень легко если честно выкурить его все сеттинги и 100500 сервисов) и разучатся строить системы - амазон поднимет цены раза в 3. А на вопрос бизнеса о том, что "как же так, нам нужно дешевле " - они ответят "не проблема, мы просто напечатаем вам больше денег".
В общем к сожалению мы пришли к тому к чему пришли. Я вообще не верю что айти будет существовать через несколько лет. Сейчас это уже пузырь. Фейк на фейке, скам на скаме. Он будет существовать ровно столько сколько подписывается этими скамерами
что реакт это скам, что докер, если присмотреться, да, оно решает большую часть проблем, в основном с унификацией и reusability, но оно так же подсаживает очень сильно как наркотик. И это приводит к повышенному детерминизму, сложности систем, отсутствию креатива, долгому онбордингу. В итоге просто рано или поздно всех стошнит. Даже в последних c++ версиях начали бадяжить с высокоуровневыми async/await. Спрашивается нахрена? Просто увеличили онбординг и всё. Под капотом там всё равно тот же ассемблер как и было сто лет назад.
Ps. Я инженер разработчик 15 лет. 35 лет. Да, я ОЧЕНЬ старый для айти, закидайте меня помидорами.
на сайты-булочные ездим поездами
Потому что какой же это сайт без свистоперделок?
Вот прямо сейчас лично ковыряюсь. У некой компании есть некий вебсайт для партнёров — туда отдаёшь некий ID, получаешь по нему некие данные. Мы написали скрейпер (не надо мне тут: цель этого скрейпера — не "просканировать все-все данные по 100 раз на дню", а облегить работу нашему мужику, который раз в месяц на этот сайт заходил, вводил ID, получал данные и вбивал их в эксель). Раньше у компании была элементарная страничка на условном ASP, которая из их базы данных по ID получала данные и возвращала из в виде статической HTML-странички. Не так давно "Микрософт" продал им какой-то фреймворк, и теперь эта же страничка обязательно требует браузер с поддержкой жабаскрипта, его обнюхивает, а потом (тадам!) возвращает ровно те же данные, что и до этого. То есть глубокий сермяжный смысл этого фреймворка совершенно непонятен — с точки зрения юзера, ничего не поменялось!
повышенному детерминизму, ..., отсутствию креатива
Эх, понапридумывали свои докеры. Не то что раньше - написал сервис, локально все прекрасно, а потом на сервер ручками/скриптами заливаешь и три дня проблемы решаешь - то зависимость не качается, то не собирается, то нужна Либа v1.07, а на сервере уже стоит Либа v1.03 и они конфликтуют. Красота-то какая была)
А сейчас что - docker build, docker push, docker pull, docker run и никакого креатива и приключений, грустно как-то даже...
Ага, вот буквально сегодня никаких приключений не было.
На сервере запущено 50 контейнеров, но при этом docker ps пуст, и остановить контейнеры нельзя — при попытке остановки docker жалуется что у него не хватает прав. Запустить новые тоже нельзя — порты заняты.
Прошлый раз такое было потому что на сервере оказалось два докера (поверх докера из apt неизвестный поставил докер из snap), в этот раз разгадать загадку так и не получилось.
И сколько раз, допустим, в месяц у вас подобные приключения с докером случаются?
У меня - даже сложно вспомнить, но не чаще 1-2 раза в год. И в любом случае лучше я буду решать проблемы с одним докером, чем ловить проблемы с каждым вариантом комбинации ЯП, фреймворка, версий либ и системы, как было до докера.
А что, докер магическим образом решит проблему конфликта библиотек (конечно нет) ?
А если в Dockerfile стоит что то вроде
RUN apt-get update && apt-get install ...то рано или поздно будет ситуация - а у меня локально работает/не работает, но виноват при этом докер ))
Эх, понапридумывали свои докеры. Не то что раньше - написал сервис, локально все прекрасно, а потом на сервер ручками/скриптами заливаешь и три дня проблемы решаешь - то зависимость не качается, то не собирается, то нужна Либа v1.07, а на сервере уже стоит Либа v1.03 и они конфликтуют. Красота-то какая была)
А сейчас что - docker build, docker push, docker pull, docker run и никакого креатива и приключений, грустно как-то даже...
Да не, я согласен. Я же там выше и писал, что у меня нет сильного мнения на этот счёт. И плюсы тоже захайлатил. Но мне кажется всё же за последние пару лет конкретно перебор. Да и при текущих технологиях инженеры должны оплачиваться раз в 5 больше, чем 10 лет назад, а не в 2 раза меньше. ))))
“Наша молодёжь растлена до глубины души, она никогда не будет похожа на молодёжь былых времён. Молодое поколение сегодняшнего дня не сможет сохранить нашу культуру.” Гесиод ~700 лет до н.э.
Столетия идут, а предвещаемый закат всё не наступает
Непонятно: если не будет ИТ, то что будет? Один сплошной AWS? Так и его тоже штуцерить кто-то должен, как изнутри, так и снаружи. Да и альтернативные площадки имеются.
И со сложностью я так же не понял. Если AWS можно "натыкать" вместо красноглазенья над командной строкой на собственном кластере, то в чём усложнение? Тут можно сравнить с устройствами на рассыпухе и микроконтроллере. На МК (AWS) устройство получается не только функциональнее, гибче и часто дешевле, но и проще, меньше деталек. Нет, если сравнивать по числу логических элементов, то сложнее, но вся эта сложность убрана внутрь МК, сделана очень профессиональными людьми и раз и навсегда. Далее разработчики устройств самой разной квалификации просто берут и пользуются. И никто их не критикует за незнание схемотехники АЛУ. И небо не падает на землю, по-прежнему живут разные парадигмы: рассыпуха, МК, СОК, ПЛИС и пр., разные архитектуры, ядра, производители. Всё нормально, индустрия живёт и разваливаться через несколько лет не собирается. Не?
Всё правильно, но вы забыли ещё учести две системы координат: экономическую (по факту себестоимость, стоимость человека) и "временнУю" (человекочасы).
Смотрите, есть ассемблер допустим x86, что нужно выучить чтобы научиться на нём писать? Всего максимум 20 инструкций и ты царь и бог можешь делать что хочешь. Остальное только - это твой креатив и что ты сам можешь себе вообразить. Сколько занял онбординг? Максимум несколько дней.
Следующая стадия, язык C - это тот же ассемблер, т.е. ты его по-прежнему должен знать иначе не поймёшь что такое локальная переменная например или вызов функции, да и вообще вся практически термионология языка перекликается с устройством архитектуры CPU. НО, ещё придётся узнать posix например и как ещё crt под капотом работает, всякие аллоки и прочее в добавку к ассемблеру. Онбординг кост увеличился.
Следующий C++, это уже ООП, без книжки по паттернам на 300 страниц уже не обойдёшься. А в c++14-17-20 вообще всякого ещё накрутили + темплейты буста.
Понимаете к чему я клоню? во-первых, спрашивают, ещё как спрашивают и это ещё как нужно, тот же самый реакт - супер классная штука для реюзанья компонентов и реактивного лейаута - но блин, попробуй что-нибудь сделай без html+css (которые все те же самые что и 30 лет назад). Так же как и в AWS - ещё как нужно уметь строить самому сети и менеджить VPS (всмысле ДО AWS), иначе просто не сможешь просто эффективно принимать решения по самому AWS. И так далее, так везде.
Итого что мы видим: себестоимость инженеров экспоненциально растёт (онбординг большой, это по факту человеческая жертва), ИЛИ если человек не хочет идти на эту жертву (что как раз и наиболее частный и правомерный случай) - то он становится просто бессовестным копипастером, anykey-щиком (что мы видели в прошлом году нашествие джуниоров в проекты после курсов программирования). ПРИ ЭТОМ, на фоне повышения реальной себестоимости человеческих ресурсов - для компаний и корпораций и капиталлистов - как раз наоборот выгодно понижать стоимость, и тут докеры и AWS им помогают. Но это происходит в ущерб людей и за счёт людей, за счёт их жизней.
Понимаете разницу? 30 и 20 лет назад в программирование приходили люди во-первых просто "с изюминкой" (просто из-за непопулярности), а во-вторых со специфическим майндсетом "мечтателя", "создателя миров", что-то типа такого, а сейчас это просто капиталлистическая бизнес машина, фабрика, где дюди выгорают каждый месяц и их меняют как лампочки. Да и оплата этого труда всё меньше и меньше (потому что по факту это война и конкуренция с монополией, которая выгодна только им, там невозможно выиграть) Понимаете про что я? Если уж мы создаём что-то в этом мире и проявляем своё творчество как люди, а не как роботы - то наверное это должно как-то делать жизнь людей лучше, а не наоборот превращать всё в концлагерь. AWS это концлагерь, ни больше не меньше. И я говорю о чисто социальном факторе. Мне кажется уже пора цивилизации рассматривать любые сделки, явления, проекты, не только с точки зрения экономической выгоды, но и с точки зрения социума. Типичный ближайший пример: вместо того, чтобы корпорациям и работодателям взять на себя вынужднные по факту пожертвование траты на выращивание своих детей-джуниоров - они сделали что? сначала курсы программирования, на***бав по сути много этих джуниоров, а потом продали их бизнесу как рабов, на***бав ещё и бизнес потому что такая модель не работает. В итоге экономически выгодно? да. бабла срубили? да. Только что осталось после этого? Выжженное поле обиженных и испуганных бизнесов, которые в жизни больше не хотят сталкиваться с айти, и толпа довольно неплохих,интеллектуальных потенциально людей-джунов, но при этом совсем разочаровавшихся в жизни и программировании.
Я это и имею ввиду когда говорю про социальные факторы.
Слишком много наколотил, оформил заметкой :)
С другой стороны, как говорится, не было счастья, да несчастье помогло — яркий выход на публичную сцену большой языковой модели делает легитимными разговоры программистов не только на бодрые темы "наш паровоз вперед летит...", пожалуй, уже можно осторожно спрашивать друг друга "а где остановка-то..."
Насчёт остановки, очень всё просто, без внешней дополнительной энетропии на инпут (а они сейчас её остановили поуволняв всех нахрен) эти языковые модели придут почти к максимальному, абсолютному детерминизму и предсказуемости, знаете как фрактал (посмотрите анимацию треугольника серпинского или типа того) - оно рано или поздно задрочится ровно во всех точках согласно аттрактору. А ИИ - это ж блин просто большая многомерная матрица и ничего больше, и момент когда они его задрочат во всех точках уже близок. Так вот, они смогут сами общаться друг с другом, "война ботов". Только потом человек на это со стороны посмотрит и получится как в анекдоте "Это что мы бесплатно говна друг друга наелись" (про двух мужиков которые на спор ели друг друга какахи). Потому что по факту со стороны эти два ИИ друг с другом просто прожигают CPU и никакой пользы вообще человеку не приносят. В общем я про что хочу сказать: мы потому и люди, потому что "жизнь" и "быть человеком" далеко за гранью "как бы быстро закодить и сдать". В том числе программирование как подмножество жизни - это тоже человеческая вещь, она не про кодирование, не про архитектуру, а про креатив, про создание, про мозг человеческий прежде всего, про коммуникацию, про коллаборацию.
Идеальная вакансия — вы берете уже первого кандидата на работу. Если это не так, то начните с этого шага.
Я однажды собеседовался в компанию, где тим-лид (!) спорил со мной, доказывая, что GET используется не только для получения данных, но и для отправки (его не смущало, что GET в переводе означает "получить" и что так называемая "отправка" - по сути, побочный эффект, к тому же весьма ограниченный максимальным размером url). Я тогда на джуна шел (и не прошел).
Вы о чём-то странном вообще спорили. Основная особенность GET в том, что такие запросы не должны менять состояние сервера. И, как следствие, они идемпотентны из коробки. Во всяком случае, если программисты не нарушили протокол при реализации серверной части.
А насчёт отправки и получения данных неплохо было бы об определениях сначала договориться. Потому что по протоколу абсолютно любой HTTP-запрос - это отправка запроса (данных) и получение ответа (опять таки данных)
не должны менять состояние сервера.
Ключевое слово — "не должны".
Но, к сожалению, "я видел такое, во что вы, люди, просто не сможете поверить".
Этсамое.... А то что на один и тот же запрос сервер даёт разные ответы в зависимости от прав пользователя - нарушает идемпотентнос? Или токены/куки тоже считаются частью запроса?
Никто не запрещает использовать GET для отправки данных. Ну, кроме здравого смысла. Но если здравый смысл успешно устранить, то получится VK API — для всех методов можно юзать как GET, так и POST. Точно работает ещё PUT, но это недокументировано. Да, у ВК можно запросить данные POST-ом, и изменить GET-ом)
Собственно, цитата из их документации
Чтобы обратиться к методу API ВКонтакте, нужно выполнить либо
POST-, либоGET-запрос (запрос с каким HTTP-глаголом вы отправите, не имеет значения)
Впрочем, API вконтакта это особая атмосфера цирка с конями...
Я знаю ответы на половину этих вопросов, но я не devops а ML специалист, просто приходилось иногда все понимать. Поэтому могу сказать мне эти знания пригодились лишь когда заказчик тупо экономил. Все знать даже близко не реально
Пара профессоров обсуждают как они принимали экзамен у своих студентов.
Первый: я задаю ему вопрос - он отвечает, задаю другой - он отвечает, задаю третий - он опять отвечает. Ну я вкатил ему трояк - наука большая - чего то он точно не знает.
Второй: я задаю вопрос - он не знает ответ, задаю другой - опять не знает ответ, задаю третий - он молчит. Ну я поставил ему пять - наука большая - что нибудь да знает.
ИМХО, если ваш собеседник, у которого стаж 100500 лет не может ответить на ваши вопросы на собеседовании, то скорее всего что-то не так с вами.
если ваш собеседник, у которого стаж 100500 лет не может ответить на ваши вопросы на собеседовании, то скорее всего что-то не так с вами
Это очень сильно зависит от позиции. Подразумевая, что со стажем 100500 лет люди обычно претендуют на что-то весомее джуна, может быть по-всякому. Можно за 100500 лет спокойно дослужиться до кита, плавая только в мелкой воде.
Самый простой пример: через мои собеседования прошло довольно много рубистов, претендующих на звание синьёр; 90% из них — языка в принципе не знают, умеют исключительно во фреймворки типа рельсов, и в любой непонятной ситуации — вместо reduce используют each с внешним аккумулятором.
Такой код работает, и не режет глаз остальным 90% синьёров в компаниях, где эти набирали свой стаж.
Насколько "вместо reduce используют each с внешним аккумулятором" влияет на дистанции на продукт/систему?
Есть ли реальная разница?
Да. Потеря скоупа и изменение внешних переменных изнутри цикла — очень подвержено ошибкам при рефакторинге.
Кроме того, что демонстрирует отсутствие понимания тривиальных концепций.
"демонстрирует отсутствие понимания тривиальных концепций"
Вы же понимаете что условному разработчику С/Go конструкция с reduce будет незнакома/непривычна. Страдают ли от этого системы? Вряд ли.
За собой замечаю что такие мелкие детали, которые переписываются в одну или в другую сторону с закрытыми глазами меня все меньше беспокоят
Ну в js есть сейчас reduce. В других языках c, c++, c#, pascal, pl/1, fortran, go и тд - через библы - в самом языке таких конструкций нет.
От большого количества сахара может случиться и диабет :)
А есть ли хоть один язык, в котором итератор each или типа того — есть, а reduce — нет? Я для друга спрашиваю. Даже ладно, шут с ним, с редьюсом этим: map можно использовать, или это тоже синтаксический сахар? А главное, что засахарено-то, неужто goto (пусть jmp), который в сущности лежит в основе всех циклов for и им подобных?
Очень долгое время таких языков было полным-полно. Сейчас вроде уже во всех современных reduce появился.
Однако, частенько бывают ситуации когда итерация попросту работает быстрее. Или просто более читаема.
Наверное, раз их было так много, можно хотя бы один и по имени назвать?
Java (1998-2014), C# (2003-2007)
Подтвержу насчёт Java. Пробегал я как-то мимо литкода и дай, думаю, решу задачку попроще. Там был перебор и я написал его через Stream API. Задача решилась, но показала низкое быстродействие, где-то на середине диапазона решений, хотя большинство было сосредоточено в первой четверти. Так как решение было очень простым, оптимизировать было особо нечего. Ладно, переписал на цикл в варианте foreach. Получилось гораздо быстрее, уже попало в "горб", но где то с краю. Переписал на обычный for и попал в горб, в серединку.
Эта история порвала у меня сразу два шаблона. Во-первых, мне тщательно втирали что стримы настолько оптимизированы, что "старые" способы просто ни о чём. Оказалось, в данном случае стрим оказался весьма тормозным. И во-вторых, я был уверен что foreach это просто компактный синтаксис, который разворачивается в обычный for. Оказалось, нет.
Это что теперь получается, каждый метод, который лопатит некоторый объём данных, надо не только на алгоритм думать, но и на способ записи?!
Узко мыслите, товарищ. Процедура с несколькоми точками входа - слабо? Языки высокого уровня просто не поддерживают такие конструкции, но asm есть бог
— Но я-то не каждый! Ватсон, поймите: человеческий мозг — это пустой чердак, куда можно набить все, что угодно. Дурак так и делает: тащит туда нужное и ненужное. И наконец наступает момент, когда самую необходимую вещь туда уже не запихнешь. Или она запрятана так далеко, что ее не достанешь. Я делаю по-другому. В моем чердаке только необходимые мне инструменты. Их много, но они в идеальном порядке и всегда под рукой. А лишнего хлама мне не нужно.
— Учение Коперника, по-вашему, хлам?!
— Хорошо. Допустим, Земля вращается вокруг Солнца.
— То есть... то есть... КАК — допустим?
— Земля вращается вокруг Солнца. Но мне в моем деле это не пригодится!
Бизнесу нужна была скорость выполнения задач.
Инженеры начали вводить высокоуровневые абстракции, чтобы управлять сложностью и не погружаться в детали каждый раз, потому что это сильно тормозит выполнение бизнесовых задач.
Инженеры начали этими абстракциями пользоваться и быстрее решать бизнесовые задачи.
Потом инженеры стали обвинять других инженеров что они не знают что там под низом, ах как же так.
Вы шизофреники.
только кажется в момент появления абстракций их пользователи перестали быть инженерами
как водитель грузовика не является инженером-механиком или инженером-электриком
называй себя хоть сюзанной, если тебя от этого прёт (с)
"мы инженеры и все знаем а вы - не инженеры потому что дальше тулзы не видите" - это жиденькая позиция.
процессоры на сервере шуршат, и врядли вы знаете детали и тонкости его внутреннего устройства. вы скажете "а мне и не надо", и ровно то же отвечают те люди, о которых написан пост.
каждое поколение таких "инженеров" изобретает тулзы, и обвиняет следующие за "незнание основ". и каждый такой инженер почему-то за "основу" берет то, что знает и выучил сам.
весьма произвольно, не находите? почему не на уровень ниже? почему не на уровень выше?
"я инженер, а ты всего лишь жалкий пользователь, ниче не знаешь ниче не умеешь" - это игрушки в самоутверждение стареющего спеца.
"вот в наааше-то время..."
хатьфу
справедливости ради, "в наше время" очень многие знали "снизу доверху".
Но лишь потому, что все это "снизу доверху" было очень малО. А "время" — изменилось, и отрасль сильно разрослась. теперь всё знать просто невозможно. И возникает закономерный вопрос — до какого уровня нужно знать "в глубину", и какой объем "в ширину". И однозначного ответа на это нет.
я как инженер САПР знаю на 2 уровня ниже САПР
- как разрабатывается софт
- как работают сети и компьютер
в деталях работы конкретных процессоров и сетевых устройств прям текущего года необходимости разбираться очевидно нет, потому что эти знания просто не нужны (в частности, я специализируюсь скорее на САПР ИС и бизнес-приложений, чем 3D и проч)
также я знаю на 2 уровня ниже, как работает механика, физика и химия, но для работы инженером АС типа САПР это уже не критично
если вам нужен действительно DevOps-инженер, т.е. человек, который ПРОЕКТИРУЕТ специализированную АСУ ТП, то он тоже должен знать на 2 уровня ниже
если вам нужен инженер по проектированию высокопроизводительных систем, то ему возможно нужно и в деталях работы процессоров и сетевых устройств текущего года разбираться, зависит от класса системы
просто если не нужны именно инженеры, а достаточно техников по эксплуатации, то нефиг с обеих сторон называть их именно инженерами и создавать завышенные ожидания
я как инженер САПР знаю ...
нефиг с обеих сторон называть их именно инженерами и создавать завышенные ожидания
аа, так вам за гордое звание инженера обидно, все понятно :)
если вам нужен действительно DevOps-инженер, т.е. человек, который
ПРОЕКТИРУЕТ специализированную АСУ ТП, то он тоже должен знать на 2 уровня ниже
2 уровня ниже - откуда считаем? почему 2 а не 3? почему должен? из вашей головы?
также я знаю на 2 уровня ниже, как работает механика, физика и химия
ну да, теперь понятно откуда.
devops знаток химии это очень уважаемо, респект вам :)
Руководитель онлайн-школы Systems.Education
надеюсь, как руководитель школы вы и образовательный процесс на 2 уровня ниже знаете, иначе как-то непрофессионально получается. или не должен? почему нет?
впрочем, с вашей претензией на "знаю химию, физику и как разрабатывается софт" разговаривать больше не о чем.
хорошего вам дня!
мне не обидно, я даже по специальности не работаю
считаем исходя из системной холархии. должен исходя из сути деятельности, что для сборки объекта уровня X нужно знать свойства уровня X-1 как минимум. но это только для сборки. для проектирования нужно знать на уровень глубже, т.к. в ходе проектирования может возникать запрос на новую разработку компонентов уже этого уровня
вы какую-то ерунду вычитываете всё время и фантазируете — обидно, ехидно, какие-то судороги, передёргивания, попукивания
так что и вам
если вам нужен действительно DevOps-инженер, т.е. человек, который ПРОЕКТИРУЕТ специализированную АСУ ТП, то он тоже должен знать на 2 уровня ниже
Инженеры АСУТП как правило не знают всего в деталях, работа всегда идет совместно с технологами, именно технологи знают процесс в деталях и формируют требования, например по точности поддерживаемых параметров, скорости их достижения, допустимом перерегулировании, заостряют внимание на критичных местах и т.п.
Увы, действительно много людей, которые нахватались buzzwords по верхам. (Кстати, недавно видел объявление о поиске преподавателя для курсов - искали человека с одним (!!!) годом опыта)
Хотя много и талантливой молодежи, грех жаловаться.
Кстати, вначале показалось, что пост написал человек за 40 или даже 50 (мне 59) - но потом посмотрел в био и увидел что ошибся.
Правда в том, что знание всех всех деталей реализации каждой тулзы/слоя абстракции невозможно. Ну невозможно всё знать.
Есть крошечный шанс найти человека, который уже знает достаточно таких деталей для повседневной работы конкретно у вас.
Есть большое количество людей не знающих таких деталей.
С точки зрения рабочего процесса вам скорее всего нужна ВОЗМОЖНОСТЬ при необходимости залеть в эти низкоуровневые детали и что то поправить.
С точки зрения найма, вы можете ловить единорога, который знает то что вам нужно и на таком уровне как вам нужно, либо брать тех кто есть, и научиться их эффективно закапывать в низкоуровневые детали при необходимости.
Правда в том, что скорее всего вы упираетесь в каприз спеца, который весь из себя такой умный, и ему надоело работать с окружающим его ничего не понимающим дурачьем (ну, как он эти видит).
Его каприз может быть оправдан, если в организации нагорожено велосипедов, которые кроме как низкоуровневым ковырянием не держатся, и поэтому ему нужны такие люди здесь и сейчас.
Это признак больной инфрастуктуры, которая не соответствует сегодняшним индустриальным стандартам. "Поздравляем, вы легасизировались!".
Кризисная точка, и из нее надо выходить.
Правильный путь - стандартизировать и приводить инфраструктуру в соответствие с теми технологиями/инструментами, которыми умеют пользоваться сегодняшие соискатели.
Тогда необходимость в поиске единорога пропадает.
Задачи, требующие особого погружения в низкоуровневые детали выполняются в обычном порядке: берутся спец/команда, и погружаются. Больно, тяжело, но надо.
Правильный путь - стандартизировать и приводить инфраструктуру в
соответствие с теми технологиями/инструментами, которыми умеют
пользоваться сегодняшие соискатели.Тогда необходимость в поиске единорога пропадает.
Приведёте пример такой связки технологий, у которой под капотом не будет линкуса, контейнеров, TCP/UDP, дисковых массивов?
о том и речь что они будут под капотом, где-то там, а не тут, типа баш скриптами вы все это дерьмо собирать и склеивать будете
И когда это "там" поломается - какие-то другие люди будут чинить, или как это будет происходить? Когда проблема не будет решаться через инструменты, относящиеся к верхним слоя абстракции - а в том, что ниже, "сегодняшние соискатели" ни в зуб ногой.
Город засыпает, просыпается служба поддержки AWS.
к более опытным коллегам, которые подскажут где искать, помогут и передадут опыт.
или самостоятельно, разбираться погружаясь в дебри, точно так же как и вы делаете когда сталкиваетесь с неведомой хренью
Мы всё ещё про сотрудников эксплуатации говорим? А то, знаете, в некоторых компаниях простой сервиса в две минуты - это шестизначные потери прибыли и повод для разбирательства на уровне топ-менеджмента. Лично я бы не хотел в таких условиях "погружаться в дебри" или ждать ответа от поддержки облачного провайдера.
Такие компании, наверное, в облака не ходят. Иначе потери обеспечены, так как полного контроля за облаком вы всё равно не имеете, и в случае чего всё равно придётся ждать ответа от облачного провайдера
Так я о чём и говорю - в шарашках, где всё может прилечь на пару суток, пока сегодняшние соискатели (с) будут гуглить, как диагностировать причину остановки сервиса, рестарта контейнера/ОС, низкой производительности i/o, наверное, действительно избыточны фундаментальные знания. Но это вырожденный случай и равняться на него, имхо, не стоит. Таких, надеюсь, в ближайшие годы заменит ИИ - как и массу других товарищей с квадратно-гнездовым мышлением.
Коротко: если большинство кандидатов не способны работать у вас, есть вероятность, что это у вас что-то не так, а не с кандидатами.
"У вас" - это в стеке, инфрастуктуре, в рабочих процессах, в процессе найма, в сотрудниках.
<irony>
Давайте девопс будет знать весь стек , который сопровождает - от embedded до верстки , ну автор же хочет.
Следующим шагом будет поставить его вместо команды - ну он же знает все.
</irony>
Когда учить "Фундаментальные, нетленные знания" если вместо личной жизни и выходных девопс разбираеться в ченжлоге airflow и различии 1.25 и 1.27 k8s , потому что в рабочее завален тасками и инцидентами.
Может если вам нужны такие узкие спецы нужно вырастить их ?
Ну нет , развивайтесь в свободное время , сон для слабаков , заучивайте Таненбаума , если нам понравится ваша форма черепа и будете просить меньше рынка - так уж и быть , возьмем на SRE - будете proc грепать , потому как мониторинг для слабаков и это ваши хипстерские штуки.
Девопс объеденяет работу разработчиков , тестировщик , безопасников , сетевиков и опсов , но не должен знать делали лучше них
Думаете иначе - пожалуйста , вдохновляете их изучать , проводите мастер-классы , учите, наполняете огнем их глаза , раз на от ваших инженеров требуются уникальные навыки , которых нет на рынке.
Тут же пассивная критика - они неправильные , как жаль что нельзя воскресить и клонировать Криса Касперского и накатить клонам софтскиллов.
У рабочего муравья есть свой круг задач. У муравья солдата - свой. И только королева муравейника решает, куда движется проект.
Королева муравейника ничего не решает. Просто у неё свой круг задач, гораздо более узкий кстати, чем у рабочих муравьёв. И делает она его по той же заложенной биологической программе без шага влево/вправо.
Вот как раз в реальных муравейниках охлократия в терминальной стадии.
Часть муравьёв толкает проект в одну сторону, часть — в другую, каких оказалось больше — туда проект и движется.
Провожу огромное количество собеседований разработчиков. Поймал себя на схожих выводах. Недавно общался с товарищем из большой е-коммерц компании - у него та же проблема.
Сошлись на мнении, что мы, пожалуй, старомодны, но фундаментальные понятия и определения знать нужно. Нужно понимать, как работает приложение и уметь работать на низком уровне, а не только на высоких уровнях абстракции.
Требования к кандидатам менять не буду. Конверсия невысокая, но итог хороший. Отсутствие увольнений в команде с 2019 года, команда выросла за это время в три раза.
p.s. компании немецкие, команды интернациональные
Я думаю индустрия сама себя загнала в эти условия, переименовав сисадминов в DevOps-инженеров.
У сисадмина не было обязательности инженерного образования.
Если в 70% случаев от специалиста нужна квалификация ремесленника, техника, как это например обстоит с разработчиками, а не инженера, то это совершенно нормальная ситуация.
Если брать аналогию с традиционной инженерией, то можно считать, что организация конвейера разработки ПО — это частный случай построения АСУТП.
Так вот человек, который строит такой конвейер в большой компании видимо должен иметь квалификацию именно инженера.
А человеку, который такой конвейер поддерживает, сопровождает, достаточно квалификации техника.
Если брать аналогию с традиционной инженерией, то можно считать, что организация конвейера разработки ПО — это частный случай построения АСУТП.
Совсем уж частный, все таки реальные АСУТП это в первую очередь модели, и главный инструмент АСУТПшника, это какой-нибудь MATLAB. В работе типичного DevOps ближе всего к этому – мониторинг. В идеале было бы круто конечно, если бы DevOps-инженер, имея АСУТПшное образование занимался анализом метрик, искал узкие места и потом вместе с архитектором они решали что с этим делать, моделировали, тестировали и перестраивали систему. Но для 90% DevOps вакансий это скорее оверквалифайд и, если проект крупный, ему архитектор напишет, какие метрики снимать и анализировать их будет тоже архитектор.
У меня скорее обратная ситуация - фундаментальные знания присутствуют (tcp/ip, linux, БД, скриптописательство, много еще чего и даже куча сертификатов), сам системный инженер, но вот думаю попробовать себя в DevOps, есть опыт администрирования k8s/docker. Но без опыта написания собственных манифестов и внедрения своих пайплайн цепочек.
Нужны такие?
Вывод неверный. Правильный вывод - вы тратите много времени на неподходящих кандидатов, надо чтобы HR ещё на первоначальном созвоне спросил(а) это и по ответу было ясно, есть ли смысл звать кандидата на собеседование.
Ну что ж, дорогой автор, Вам тут накидали на тему глубины познания в DevOps. Делайте выводы, пожалуйта. Присоединяюсь к лагерю неодобряющих такой подход.
Вообще, все эти вопросы такая вкусовщина, в 2019 году на собесах спрашивали от "Load average" в TOPе линукса до просьб написать какую-то программу на питоне по натуральным числам на позицию DevOps инженера. Я слова "натуральные числа" последний раз слышал на 1 курсе универа (очень давно).
Очевидно, знать что там под капотом очень полезно. И знать основы Computer Science очень полезно. И знать подробности HTTP протокола тоже очень полезно. И Ассемблер знать полезно.
Но добавь чуть-чуть языков программирования и алгоритмов - и ты уже собеседуешься на разработчика.
Добавь сюда методики проектирования - собес превращается в "Архитектурный".
Поэтому я забил на DevOps и постепенно перекатываюсь в разработчики. ИМХО более перспективная история.
А что не так с load average?
Это сложная и неочевидная штука из разряда интересных фактов.
Не припоминаю, чтобы на интервью спрашивали именно детальный анализ работы алгоритма.
Достаточно знать, что для оценки load average нужно знать количество ядер, и что это не показатель нагрузки на сам CPU, а относится к очереди процессов в ожидании исполнения.
Таким образом примерно понимание что такое load average также означает, что человек в принципе понимает как работает многозадачная ОС, и имеет представление что существует некий process scheduler.
Если вы смотрите в TOP и в строчке нагрузки на CPU видите как процент распределен между USR / SYS / NI / IDLE вы же тоже можете оценить что это означает?
А обе эти вещи связаны, ибо они зависят от архитектуры ОС.
"Я считаю себя энтузиастом в ИТ, для меня это не только работа, но и одно из увлечений," - ну здорово. А есть альтернативная концепция: человек работает на работе, а дома отдыхает, общается с семьёй, занимается хобби. Хорошо, если хобби совпало с работой, а если нет? Бросишь хобби, пойдёшь по ночам книжки читать - выгоришь. Бросишь семью, пойдёшь книжки читать - сбежит семья. Будешь дома отдыхать, а на работе работать - на собесе расскажут, что "ты немотивированный, не знаешь сети, просишь денег..." что там у вас ещё было в списке претензий?
В общем... Это конечно очень здорово, хотеть от сотрудников, чтобы они были лучшие и посвящали всё свободное время саморазвитию. Но сотрудники, внезапно, хотят жить нормальной жизнью, и, о ужас, получать за свою работу деньги.
Даёшь нормальный work life balance!
Смотря что желает работодатель ? Дешево и качественно ! Ну-ну Вообще когда у нас в начале 2000-x тормозил Сановый сервак и мы разбирались в чем дело , пришел исполнительный директор и спросил в чем проблема - памяти не хватает Он и говорит вот вам 1000$ идите и купите планку памяти !!!!!! Потом выяснилось Обаповец запрос хреновый написал и база дохла ...... дали по рукам и переписал запрос
Понимаю "боль" автора. Но вот взгляд соискателя, который пытается прийти на роль джуна в DevOps. Может быть полезно почитать обеим сторонам:
Теория основы работы Linux и командной строки (поверхностно, без рассмотрения параметров и вариантов использования команд) - 2 учебника мелким шрифтом - почти 1000 страниц. И все важны, всё могут спросить. При этом не встречал единого стандарта что знать надо, чтобы это всех устроило. В процессе собеседования ответил на вопросы, но понял что надо что-то подтянуть. К следующему собеседованию сделал работу над ошибками, повторил, спрашивают другое и т.д. И это только объемы основ; Git, GitLab, Ansible, Bash - отдельно.
Мнение соискателя: Увидели что где-то провал. Поговорите с соискателем, что вам важно , чтобы его сотрудники обязательно знали это , это и вот это. Ок? Ок. Позже всегда успеете сделать срез знаний и понять, что человеку пофиг.
Пускают пыль в глаза в резюме? К сожалению, огромная проблема попасть на собеседование с честным резюме. В своем ничего не приукрашивал и HR его просто заворачивают, так как полно красиво расписанных резюме рядом. И это еще один пункт ,который видится системной проблемой. Можно еще больше ужесточить требования, чтобы те, кто не умеют красиво говорить, но хотят учиться и понимают важность базы вообще не попали.
Мнение соискателя: Настройте "таблицы маршрутизации" у HR. Больше опыт + много строчек в резюме != лучший кандидат. Берите какой-то процент соискателей, которые на первый взгляд в чем-то проигрывают. Давайте шансы.
Нужны идейные мидлы и синьоры с сильной базой? Когда в любой команде есть идейные да еще и с опытом - это классно. Не поспоришь. Но кто-то сначала должен взять идейных на позиции джунов, сделав поблажки на старте . А все делают вид, что это не их проблема.
Я — айтишник, я не хочу много знать