Проблемы найма DevOps

пришлось учить cpu throttling

и сколько на это ушло времени?

Низкоуровневые вещи - это прикольно, и закопаться в них иногда можно, но ставить их во главу угла давно нет смысла.

Понимаешь, какое дело: ты либо знаешь, что такое шедулер, и где про него читать, либо ты ямл-девелопер, для которого ядро линукса это некая абстракция. Возможно, тебе просто не доводилось пересекаться с людьми, которые не знают, что такое LA, но у меня 9/10 собеседований именно такие.

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

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

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

надо научиться решать простую задачу, а потом уже приступать к сложной

Это работает только если простая задача является подзадачей сложной задачи. В данном случае это не так.

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

Умение запускать tomcat совершенно паралелльно вопросу является ли человек толковым devops.

Толковый devops должен объяснить тебе почему ты должен перестать пытаться запускать tomcat.

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

И в целом ты решаешь не ту задачу.

Ты пытаешься вести собеседование с позиции «я могу проверить только знание того что знаю сам, поэтому чтобы нормально проводить собеседование, мне надо выучить всё что должен знать человек которого я нанимаю». Это глобально неработоспособный подход. Так можно нанимать только джуниоров на подхвате.

Поэтому чтобы уйти от «пока» в данном случае надо не саму тему изучить, а менять подходы.

Ты пытаешься вести собеседование с позиции «я могу проверить только знание того что знаю сам, поэтому чтобы нормально проводить собеседование, мне надо выучить всё что должен знать человек которого я нанимаю». Это глобально неработоспособный подход. Так можно нанимать только джуниоров на подхвате.

Неверно. Чтобы провести собеседование, тебе не нужно быть сеньором-по-всему. Тебе достаточно знать несколько вариаций верных ответов на задаваемые вопросы. Вопросы можно подобрать исходя из сосбственного опыта, если он есть, но если его нет - не беда, всегда можно использовать опыт коллег. А уже умение оценить реакцию и ответы (а не только их суть) позволяет легко отделить красиво трындящего джуна от нормального сеньора.

мощный слой как раз фундаментальных знаний

Только, например, мои фундаментальные знания - это не системные вызовы ядра, а пять лет мехмата и диссер по специальности Геометрия и Топология. Ни один интервьюер с формальными вопросами по модели OSI не сможет отследить эффекта, который даёт такой фундамент на иженерную деятельность.

Поэтому товарищи с вопросами про чтение манов сначала проходят мимо, а потом громко и горько плачут, когда нанятый ими человек, обладающий «фундаментальными знаниями по чтению вывода vmstat» при попытке описать инфру как код создает нечитаемую лапшу из 30000 строк. Но во всём виноват конечно yaml и хипстеры, а не то, что кто-то не умеет оценивать навыки работы с чуть более высокоуровневыми абстракциями чем «железка здесь» и «порт там».

Только, например, мои фундаментальные знания - это не системные вызовы ядра, а пять лет мехмата и диссер по специальности Геометрия и Топология. Ни один интервьюер с формальными вопросами по модели OSI не сможет отследить эффекта, который даёт такой фундамент на иженерную деятельность.

Естественно. Поэтому любое интервью без практической части, которую интервьюер в состоянии на лету оценить, и изменить - фикция. Если интервьюируемый не умеет применять заявленные скиллы, у него их нет. Точка.

Поэтому товарищи с вопросами про чтение манов сначала проходят мимо

На йух они сразу проходят, эти товарищи. Под «фундаментальными знаниями» я понимаю понимание того, как работает то, с чем приходится иметь дело, либо способность быстро разобраться. Если человек понятия не имеет даже про порядок загрузки х86 серверов, а у него в CV напейсано «10 лет опыта работы с линуксами на серверах», он врет. Ну или просто дурак. В общем, такой проходит туда же, куда любители грепанья вывода чего угодно.

Только, например, мои фундаментальные знания - это не системные вызовы ядра, а пять лет мехмата и диссер по специальности Геометрия и Топология.

И почему только человек с такими фундаментальнейшими знаниями ворочает контейнеры и континуос интегрейшены, вместо того, чтобы по специальности работать, задачи тысячелетия решать там, теоремы разные доказывать :P

Тебе достаточно знать несколько вариаций верных ответов на задаваемые вопросы

Всё так, только слово «верных» надо убрать. Заменить на «осмысленных», например. Потому что если ты нанимаешь сеньора, одна из его задач - найти ошибки в том, что ты или твои коллеги считаете верным.

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

Потому что Continuous^W Quantum Integration - это одна из задач этого тысячелетия.

гугол по этой фразе выдаёт какую-то конторку, занимающуюся IoT

Quantum Integration

Такого баззворда еще не слышал, видать, из свеженького.

Это просто мой личный баззворд.

https://quantum-integration.org/posts/what-is-ci.html

Я пока набираю материал для его продвижения

гугол по этой фразе выдаёт какую-то конторку, занимающуюся IoT

Ну так тысячелетие - оно долгое, а я пока только начала.

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

социальную защиту и обеспечивает лично

Гыгы. Обычно он обеспечивает защиту собственных интересов, куда жена как работающий it инженер обычно не входит.

Да никакой.

Боюсь, не ломать API - это более простой путь, чем CI, но не такой интересный.

Всё так, только слово «верных» надо убрать. Заменить на «осмысленных», например. Потому что если ты нанимаешь сеньора, одна из его задач - найти ошибки в том, что ты или твои коллеги считаете верным.

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

не ломать API - это более простой путь

Осталось определиться, путь куда именно.

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

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

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

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

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

Да, не спорю, бывает и такое. У меня был как-то случай когда человека собеседовали про девопс, а оказывается надо было сначала про базовый bash спрашивать. Пришлось по итогам испытательного срока выгонять, и это безусловно неприятный опыт.

опускаться совсем до детских вопросов не хочется

Ага. Но спрашивать про, например, syscalls, когда достаточно знания основ bash-скриптов в такой ситуации тоже не выход.

Ну и я, к слову, сейчас без stackoverflow или мана строчку для sudoers не напишу, тем более на собеседовании. Но два дня будет многовато конечно :)

Для middle можно давать скрипты на ревью. То есть задача не написать скрипт самому прямо тут вот, а посмотреть готовый, найти косяки и написать, например, changelog к патчу.

Но проверять не синтаксис опять же, а всякие забавные вещи типа:

if verbose:
    logger.info(message)
else:
    logger.debug(message)

Ага. Но спрашивать про, например, syscalls, когда достаточно знания основ bash-скриптов в такой ситуации тоже не выход.

Ну и я, к слову, сейчас без stackoverflow или мана строчку для sudoers не напишу, тем более на собеседовании. Но два дня будет многовато конечно :)

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

Для middle можно давать скрипты на ревью. То есть задача не написать скрипт самому прямо тут вот, а посмотреть готовый, найти косяки и написать, например, changelog к патчу.

Во, спасибо, неплохой вариант. У нас правда обычно формат собеседования больше разговорный, надо попробовать изменить немного.

заваливают годных инженеров вопросами «как бороться с патриархатом и восстановить гендерное равенство среди IT-инженеров».

Ну, кстати, сам вопрос-то более чем годный для инженера. Инженер, подумав, ответит что-то типа «нужно чтобы условия по зарплате и загрузке IT-инженера были выгоднее чем потенциальный результат сбычи типовой мечты типовой девушки о женитьбе на типовом миллионере. Тогда девки предпочтут IT и перестанут заниматься хернёй на говноработах в надежде захомутать миллионера». Другое дело, что HR-сектантов этот правильный ответ категорически не устроит.

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

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

Мне тебе показать толпу людей, которые «в отличие от него» учились писать программы, а в реальности десять рабочих строк кода не могут написать? Я у одного такого HR-а УЧИЛСЯ сам, и я с ужасом осознаю, что этот человек, вполне вероятно, прямо сейчас занимается тем, что набирает электромонтеров, давая им задачки на засыпку, вроде «переплыть реку на лодке, в которой одновременно умещается только два животных — ты и твоя мать».

95% HR-ов — это полнейшие кретины, это факт, и то, что они раз в год находят достойного специалиста — это чудо чудес, тупо счастливый случай, «если долго мучаться — что-нибудь получится». Но ты же не попытаешься оценить, сколько на самом деле достойных претендентов они не заметили?

Хороший, годный тред.

Из своего опыта того же самого:

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

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

3. Поспрашивай об организации ci/cd (от его видения деплоя в разных условиях, до организации хранения продуктов его же жизнедеятельности (плейбуки/код, артефакты, docker, документация)).

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