Комментарии 21
С фидбеком, конечно, пятая точка.
Причём, как в шаражкиных конторах, так и в крупнейших IT-гигантах страны.
Интересно, кстати, на Западе культура фидбека более развита? Чаще обосновывают отказ? Или так же молча кидают резюме в Корзину, а вакансию в Архив.
На западе с фидбеком очень плохо, особенно в больших конторах. Некоторые даже пишут об этом явно в начале рекрутинг процесса, мол в случае отказа деталей «почему» раскрывать не будем. Кажется Amazon AWS таким страдал.
В прошлом на собеседованию в одну фирму среднего размера на собеседовании с технарями я даже вежливо попросил дать фидбек в случае отказа, мол интересно знать свои слабые стороны с точки зрения внешнего наблюдателя. Их, как мне кажется, эта просьба положительно настроила. Но меня туда взяли и фидбек не понадобился.
Статья зачетная как и для рекрутеров так и для самих DevOps. Вот бы большинство рекрутеров следовало этому. А то в профайле написано что всегда работал только с AWS и Linux, а рекрутеры иногда присылают роль по Azure+Windows и говорят что я отлично подхожу на эту роль, трудно прочитать что-ли пару строчек и не тратить ни свое ни мое время.
В прошлом на собеседованию в одну фирму среднего размера на собеседовании с технарями я даже вежливо попросил дать фидбек в случае отказа, мол интересно знать свои слабые стороны с точки зрения внешнего наблюдателя. Их, как мне кажется, эта просьба положительно настроила. Но меня туда взяли и фидбек не понадобился.
Статья зачетная как и для рекрутеров так и для самих DevOps. Вот бы большинство рекрутеров следовало этому. А то в профайле написано что всегда работал только с AWS и Linux, а рекрутеры иногда присылают роль по Azure+Windows и говорят что я отлично подхожу на эту роль, трудно прочитать что-ли пару строчек и не тратить ни свое ни мое время.
Должно быть: GitLab, GitLab CI, Ansible, Docker, Terraform, Zabbix, KVM, MySQL and PostgreSQL, Prometheus, Grafana, ELK-стек, Jenkins, K8S/Kubernetes, AWS\Azure\GCP\Яндекс-облако\Mail Cloud.
Это — девопс.
Тут слишком много ни на чем не основанных обобщений: GitLab, GitLab CI — с какой бы стати, если бывают bitbucket и jenkins? Или вы девопс, а не HR, или вы не слишком ли много на себя берете, оценивая специалиста таким образом?
MySQL and PostgreSQL — это почему же только они? А где Oracle и MS SQL, а еще скажем терадата и greenplum (впрочем, у нас на эти занятия есть выделенные люди, и они девопсами не являются, строго говоря, а являются как и раньше, DBA)? И никаких этих ваших облаков от Яндекса, а вместо них что-то другое. Например OpenShift. А вообще см. п.1. — это вот все должна определять заявка на поиск, а не фантазия HR.
Иными словами — девопсы бывают сильно другие, с перечисленным могут пересекаются только сильно отчасти, а с такими методами вы так и будете оценивать резюме за 3-5 секунд, и лажать при этом по полной программе.
Хотя в целом да, советы скорее годные. Про вилку, ну и многое другое тоже.
Спасибо за комментарий!
Да, безусловно, есть и bitbucket и jenkins, и OpenShift и многое-многое другое!
В одной статье объять необъятное — нереально и моей целью было подсветить рекрутерам некоторые моменты в поиске и на что в первую очередь обращать внимание.
И что в первую очередь надо выяснять подробности по вакансии и читать то, что указано в резюме, а не только должность и зарплату )
Про 3-5 секунд — это правда, опытный рекрутер за 10 секунд читает первые 2-3 места работы. Да, лаги случаются, как и у всех.
Спасибо еще раз за комментарий, учту в следующих выпусках!
Да, безусловно, есть и bitbucket и jenkins, и OpenShift и многое-многое другое!
В одной статье объять необъятное — нереально и моей целью было подсветить рекрутерам некоторые моменты в поиске и на что в первую очередь обращать внимание.
И что в первую очередь надо выяснять подробности по вакансии и читать то, что указано в резюме, а не только должность и зарплату )
Про 3-5 секунд — это правда, опытный рекрутер за 10 секунд читает первые 2-3 места работы. Да, лаги случаются, как и у всех.
Спасибо еще раз за комментарий, учту в следующих выпусках!
>в первую очередь обращать внимание
На описание вакансии? :) Ну в общем, ничего страшного конечно, просто вот такая ошибка — она, к сожалению для рекрутеров весьма типична. Считать, что уже разбираешься в технологиях, и можешь принимать решения без команды.
На описание вакансии? :) Ну в общем, ничего страшного конечно, просто вот такая ошибка — она, к сожалению для рекрутеров весьма типична. Считать, что уже разбираешься в технологиях, и можешь принимать решения без команды.
В резюме — на стек и опыт, в описании вакансии — таки тоже на стек и задачи =)
Рекрутер без команды не может принимать решение о найме и я нигде этого не пишу.
Но отсев делать рекрутеру приходится, вот для первичного скрининга и есть эта статья =)
Рекрутер без команды не может принимать решение о найме и я нигде этого не пишу.
Но отсев делать рекрутеру приходится, вот для первичного скрининга и есть эта статья =)
>Рекрутер без команды не может принимать решение о найме и я нигде этого не пишу.
Явно не пишете, но впечатление такое складывается.
Собственно, комментарий ниже — где-то мои впечатления, только чуть более прямолинейно изложеные. Особенно про облака, потому что девопс в закрытом контуре… это девопс например банка. А это далеко не самые маленькие компании, и не самые простые задачи.
Явно не пишете, но впечатление такое складывается.
Собственно, комментарий ниже — где-то мои впечатления, только чуть более прямолинейно изложеные. Особенно про облака, потому что девопс в закрытом контуре… это девопс например банка. А это далеко не самые маленькие компании, и не самые простые задачи.
Относительно неплохое начало, но чем дальше читал — тем больше «скрежетал мозг».
Не знаю зачем это пишу, просто делюсь мнением, возможно будет интересен взгляд со стороны инженера.
Технические моменты:
Лингвистические:
Поведенческие:
Субъективное мнение о том, что выглядит иллюзорным:
Из того, что понравилось:
Искренне желаю успехов как в найме инженеров, так и в дальнейшем изучении нюансов IT индустрии.
Ваш senior system engineer.
Не знаю зачем это пишу, просто делюсь мнением, возможно будет интересен взгляд со стороны инженера.
Технические моменты:
- Не «CitHub Actoinс», а «GitHub Actions»
- Для контейнеризации не «OpenStack», а «OpenShift»
Лингвистические:
«Откуда есть быть пошли и пришли...»
АААА… кхм… иногда хочется чтобы KISS применялся не только в проектировании
Поведенческие:
-
«Девопс-инженеры… будем называть их так. Потому что деваться им некуда… Придется им смириться»
А с какого такого, простите, невероятного события «деваться им некуда» и «придется им смириться»?
Подход, в котором кто-либо решает за группу людей, к которой никакого отношения не имеет — вызывает только отторжение.
-
"… мы с вами не инженеры и углубляться не будем."
Не хотите разбираться в спцифике найма определённых специалистов — и не надо, дело ваше.
Такое ощущение создаётся что "углубляться" это тлен и он только для инженеров
Субъективное мнение о том, что выглядит иллюзорным:
«Первая и самая многочисленная группа: бывшие и действующие системные администраторы. Им проще всего: освоили доп. инструменты и готово.»
Освоили доп. инструменты и готово? Ну-ну.
Во первых инструментов сотни. Во вторых — каждый со своей спецификой. В третьих — сильно влияет глубина, на которую необходимо погружаться.
И самое важное тут — системные администраторы очень разные.
Кто-то админит десяток сервисов, кто-то тысячи. Кто-то на десятках серверов, а кто-то на сотнях и более. Кто-то умеет обеспечивать HighLoad, а кто-то даже не сталкивался с этим.
И это далеко не всё. И по каждому нужно принимать решение исходя из контекста конкретного проекта.
«Вторая группа: разработчики, которые решили уйти в девопс-практики. Их меньше, им нужно осваивать линукс и админство.»
Почти всем разрабам, кто запускает приложения в контейнерах и/или на linux-серверах приходится знать ряд нюансов работы Linux-систем. Так что момент спорный.
По поводу админства промолчу, т.к. не знаю какой смысл вложен в этот термин.
При этом, не раз встречал сильных системных инженеров, пришедших из разработки в SRE. С точки зрения глубины (в т.ч. Linux систем) познания часто лучше, чем у среднего админа (увы, с кругозором не всегда также хорошо).
«Третья группа: “я проснулся и понял, что это — мое” — ребята, прошедшие курсы “Девопс за 3 недели” или что-то более внятное.»
"… нет опыта и понимания ни в администрировании, ни в разработке"
и тут же«Есть фраза: учил на курсах… — это студент.»
Курсы в IT это уже часть посведневности. Даже senior инженеры и архитекторы их проходят.
Тут ключевой момент что на middle и senior позицию человека, без опыта, в принципе не рассматривают.
А человек прошедший «Linux за 3 недели, Сети за 3 недели, DevOps за 3 недели» (в идеале с кейсами и практикой)- интересный на рассмотрение джун, мотивированный развиваться.
- Блок «Джун-миддл-синьор» — крайне субъективный.
Пожалуй скажу что ожидание «может поставить все девопс-практики с 0» — слишком оптимистично.
Ставить (внедрять) организационную структуру это больше про Team Lead и в целом руководителей.
Задача senior специалистов (как я это привык видеть) — быть способным разобраться в любой задаче конкретного стека (а где-то даже и смежных) и решить её.
«Должно быть:
М… нет, это перечень инструментов и технологий, большая часть из них существует и используется без всякого DevOps.
GitLab, GitLabCI, Ansible, Docker, Terraform, Zabbix, KVM, MySQL and PostgreSQL, Prometheus, Grafana, ELK-стек, Jenkins, K8S/Kubernetes, AWS\Azure\GCP/Яндекс-облако/Mail Cloude.
Это — девопс.»
«Есть что-то из этого и слова Windows 7\8\10\Server 2012\Server 2016 и п.р. — бывший админ винды.»
почему бывший?
Винда до сих пор актуальна в ряде проектов. И даже больше скажу, если говорить о виндовом облаке — CI/CD там тоже есть (привет, Azure Pipelines!).
-
«Azure...GCP, AWS и пр. — это облака… С облаками работают не все.
Девопс, не работающий с облаками — это девопс, работающий в закрытом контуре, ЦОД, ДЦ и пр. Ему нужно развиваться =) За облачными технологиями — будущее.»
Что, правда? А кто будет тогда обслуживать эти самые облака изнутри? (тут вот можно написать про OpenStack)
Да и потом, не говоря о бэкенде облаков и внутренних облаках (о которых умалчивается), есть множество проектов, где облачные технологии вообще не нужны.
Облака, если грубо обобщать — сервис выделения мощностей оборудования пользователям.
Если компания не предоставляет услуги по использованию каких-либо мощностей (внутри компании или внешним клиентам) — облаков там может не быть и на качество сервисов это не повлияет.
Из того, что понравилось:
- Задумка. Донести до коллег-рекрутеров чуть больше про инженеров и нюансы их найма это хорошо.
- Условия, стек, вилка и бонусы это действительно важно.
- Фидбек — крайне важен, особенно когда его запрашивают.
Искренне желаю успехов как в найме инженеров, так и в дальнейшем изучении нюансов IT индустрии.
Ваш senior system engineer.
Спасибо за такой развернутый комментарий!
Очепятки поправляю, волновалась, это моя первая статья =)
По остальному: просто спасибо! Мне есть, над чем работать )))
И да, по поводу «девопс-инженеров». Это не какие-то невероятные хотелки рекрутеров или еще кого-то. Это экономия строчек и времени. Писать «Вакансия Синьор Инженер, применяющий на практике DevOps-методологию» — длинно и неуютно в поиске, как вакансий, так и резюме. Поэтому и пишут senior DevOps.
Почему не прижилось «системный инженер» — не могу сказать, так повелось и привело вот к такому.
Спасибо!
Очепятки поправляю, волновалась, это моя первая статья =)
По остальному: просто спасибо! Мне есть, над чем работать )))
И да, по поводу «девопс-инженеров». Это не какие-то невероятные хотелки рекрутеров или еще кого-то. Это экономия строчек и времени. Писать «Вакансия Синьор Инженер, применяющий на практике DevOps-методологию» — длинно и неуютно в поиске, как вакансий, так и резюме. Поэтому и пишут senior DevOps.
Почему не прижилось «системный инженер» — не могу сказать, так повелось и привело вот к такому.
Спасибо!
Все хорошо написали, по делу. Но дружное и общительное девопс-сообщество всегда найдет, к чему прицепиться, без этого никуда :)
Системный инженер, это всё-таки немного другое, где-то между системным администратором и системным архитектором. Профессиональный уровень тот же, что и у девопса, просто он не занимается доставкой кода.
Если верить вот этой ссылке, то системный инженер это программист с дополнительными навыками.
Я бы сказал, по моему мнению, что на текущем рынке, фидбэк важен только когда кандидат сам откликнулся на вакансию. В текущих реалиях, когда перекос сильно в строну кандидатов, при 5-7 собеседованиях в день, на чтение фидбэков времени не остается, обращают внимание только на оффер.
Надежда, что же вы делаете. Сейчас рекрутеры вытащат из вашей статьи все ключевые слова/термины и обзовут их фильтром на devops/sre инженера. И удачи нам всем потом объяснять, что если ты использовал ansible, но имеешь очень поверхностное представление, что такое chef, то это не значит, что ничего не знаешь о configuration management systems.
Ага, лучше им посоветовать смотреть на digital.ai/periodic-table-of-devops-tools
Девопс — это сотрудник, который является коммуникационной структурой между бизнесом и IT.
А то, что вы понаписывали в требованиях — это просто «програмист yaml»
А то, что вы понаписывали в требованиях — это просто «програмист yaml»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DevOps для IT-рекрутеров