👰‍♀️ Немного мотивации и добрых слов для джунов, которые ужасно устали от поиска работы 🥹

#мотивация

1. Лучше делать плохо, чем никак. Что угодно - откликаться на вакансии, проходить собеседования, решать тестовые.

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

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

Успехов тебе на этом нелегком пути! 💕

👰‍♀️А нужно ли сопроводительное?

#рекрутинг

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

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

- Куда меньший грех - копировать и вставлять одно и то безликое сопроводительное на все вакансии. Это тоже видно, но, если писать отдельный сопровод к каждому объявлению о поиске, можно поехать крышей, и мы, рекрутеры, тоже это понимаем 🙂

- Длинные сопроводительные вряд ли будут дочитаны до конца.

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

⌨️ Мета вопросов в технических собесах

#реальные_вопросы

Разберемся, что понимается под метой технического интервью. Как, возможно, читатели догадались “мета” - это греческая приставка или предлог. Её позаимствовали многие языки для обозначения чего-то, что абстрагирует и/или агрегирует знания о предмете, который следует за этой приставкой. Например, можно привести следующие слова: “метаданные” - данные о данных, “метаирония” - ирония над иронией. И самое близкое по значению к слову, которое я хочу ввести: “метагейминг” - то есть попытка игроков выйти за пределы геймплея, получить больше информации об игре и своих в ней соперниках, чтобы улучшить свой результат. Мета в конкретной игре означает данные о состоянии игры в целом и конкретных её элементов. Например, метовые колоды, в коллекционных карточных играх это самые сильные и часто встречающиеся наборы карт, мета в шутерах - выбираемое игроками оружие, в MOBA - герои, в батлроялях - точки высадки, и тому подобное.

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

Мета может меняться, это случается когда вопрос становятся настолько заезженным и так долго висит в топе различных тематических репозиториев, что превращается в общее место. Ответ на него знают все соискатели, он становится неинтересным и выходит из оборота. Так случилось с королем всех вопросов, касающихся Linux:

Что такое load average? (с комплектом дополнительных вопросов, вроде что показывает эта метрика, почему там три значения, в чем измеряется показатель LA и тому подобное).

Его настолько затерли, что задавать его скоро станет плохим тоном.

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

Linux
- Порядок загрузки дистрибутива Linux (длинный вопрос, который уже всем надоел до зубного скрежета, вполне заслуженно)

- Что такое inode и какова его роль в файловой системе? (у вас когда-нибудь заканчивались inode на сервере? У меня тоже не заканчивались, но базовые концепции OC знать надо)

Сети
- Вы вводите в строке браузера <что-то>.com/ru (чаще всего это сайт компании, в которую вы устраиваетесь). Опишите процесс от нажатия клавиши до загрузки страницы (я знаком с людьми, которые принципиально отказываются отвечать на этот вопрос из-за его духоты и длины ответа на него).

- Объясните модель OSI и ее уровни (пресловутая семиуровневая модель, самое теоретическое, что вообще встречается среди вопросов, тем не менее, знать к какому уровню относятся коммутатор, а к какому маршрутизатор, строго обязательно).

K8s
- Опишите архитектуру кластера Kubernetes, из чего состоит? (надо перечислить основные компоненты control plane и worker nodes, рассказать про их взаимодействие и основные концепции, такие как Pod, Service, Namespace и т.д.).

- В чем разница между Deployment и StatefulSet? (вопрос на сравнение контроллеров Kubernetes)

- Какие существуют пробы в k8s (Readiness, Liveness, Startup), чем они отличаются?

Контейнеры
- Виртуализация vs контейнеризация (без комментариев)

- Каким образом в Docker реализована изоляция контейнеров друг от друга? (Namespaces, cgroups, сетевые интерфейсы, CoW, UnionFS, OverlayFS и так далее)

- Какие команды порождают слои? (те, которые изменяют файловую систему)

А еще есть один новичок в мете, это вопрос о контейнерах. Ответ на него очевиден не всем, но он настолько прост, что долго в мете вопрос не продержится, я расскажу о нем в своем следующем посте.

👰‍♀️Когда сопроводительное действительно нужно?

#рекрутинг

В прошлый раз я рассказала о некоторых секретах того, что случается с сопроводительными письмами после того, как кандидат нажал кнопку “Откликнуться”. Давайте разберемся, в каких случаях сопроводительные письма по-настоящему полезны?

1. Первое и самое главное: когда в тексте вакансии прямым текстом указывается его необходимость и предполагаемое содержание.
2. Когда у вас скрыты контакты и в сопроводительном вы указываете их.
3. Если вакансия действительно (а не как те сто остальных, на которые вы отправили отклики) сильно запала вам в душу и вы хотите сообщить об этом.
4. Если по названиям компаний и описанию опыта не до конца понятно, чем вы занимались, в то время как в реальности эта сфера очень близка к описываемому проекту. Например, вы работали в компании-интеграторе на банковском проекте, а теперь откликаетесь на вакансию в самый настоящий банк.
5. Если вы точно знаете, что компания обращает внимание на них.

А помогали ли сопроводительные вам, и если да, то в какие компании? Давайте делиться опытом в комментариях ⬇️!

⌨️ Меняешь права - умножаешь на 2

#реальные_вопросы #docker

А теперь, как я обещал, вопрос из новой меты, даже не вопрос, а целая задачка.

Задача:
На изображении мы видим Dockerfile, в котором за основу берется базовый образ alpine, в контейнер копируется файл размеров 1Gb, следующая инструкция меняет права файла. Вопрос: какого размера получится докер образ?

Ответ:
Образ будет весить ~2.01GB.

Подробный разбор:
Каждая инструкция в файле порождает новый слой, размер образа растет путем простого сложения их размеров.
Слой 1. FROM
Базовый образ Alpine (версия latest) занимает около 8 MB. Минималистичный дистрибутив, он очень популярен, благодаря своему небольшому размеру.
Слой 2. COPY
Файл testfile.img размером 1 GB копируется в контейнер. Docker добавляет новый слой (layer) для этой инструкции, и размер слоя равен размеру файла (в нашем случае случае 1 GB).
Слой 3. RUN
Вносит изменения в файл testfile.img. Docker создает новый слой для этой операции. Даже если изменяются только метаданные (например, права доступа), весь файл копируется в новый слой. Это связано с механизмом Copy-on-Write (COW), который требует копировать весь файл при любых модификациях.
Новый слой добавляет еще 1 GB из-за копирования нашего файла на новый слой.
Итого:
Размер Alpine: ~8 MB.
Слой с копированием файла: ~1 GB.
Слой с изменением прав: ~1 GB.
2.01 GB.

Как исправить?
Копировать файл сразу с нужными правами (заменить последние две инструкции на эту):

COPY --chmod=600 testfile.img /testfile.img

Немного о механизме Copy-on-Write (COW)
Я рассмотрю COW подробнее в другом посте, а пока расскажу о простом правиле. Слои в OverlayFS являются неизменяемыми, стратегия Copy-on-write, обеспечивает совместное использование и копирование файлов, если файл или каталог существует в нижнем слое образа, а другому слою требуется доступ к нему на чтение, он просто использует существующий файл. А когда другому слою потребуется изменить файл, файл копируется в этот слой и изменяется.

👰‍♀️Как впечатлить рекрутера своим английским?

#рекрутинг

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

1. Заранее напишите рассказ о себе и своем опыте на английском.
2. Посмотрите наиболее частые вопросы эйчар-интервью и напишите ответы на них тоже.
3. Добавьте в рассказ сложную лексику и грамматические конструкции, которые указывали бы на высокий уровень владения языком (conditionals, пассивный залог). Можете попросить сделать это кого-нибудь из знакомых или ChatGPT.
4. Учим все написанное - по возможности. Не подглядывая, рассказываем кому-нибудь из близких.
5. Готово, вы восхитительны 🎉

⌨️ SQL-инъекции: технология древних хакеров, которая до сих пор работает

#интересное

Легкий пятничный пост. Предвкушаем завершение рабочей недели

SQL-инъекции — это классический метод атаки на базу данных сайтов или приложений. В мире инфобеза затертый просто до дыр пойнт. И даже, несмотря на это, я нашел новость о крупной утечке данных, датированную 2023 годом. Хотя точные детали не раскрываются, эксперты предполагают, что одним из возможных векторов атаки могли быть SQL-инъекции. Про количество успешных атак в чуть более далеком прошлом можно даже не упоминать. Притом что сам механизм SQL-инъекции был описан аж в конце 1998.

SQL-инъекции позволяют злоумышленнику манипулировать запросами к базе данных через поля ввода или другие точки взаимодействия с пользователем. Если приложение не проверяет вводимые данные, это дает хакеру возможность прочитать, изменить или удалить данные.
Что надо такое вставить в поле для ввода? Вот пример:

hi'); DROP DATABASE customers; --

hi'); Закрывает открытую ранее кавычку и скобку в исходном SQL-запросе. Это позволяет выйти из контекста ожидаемого строкового значения и создать новый запрос

DROP DATABASE customers; Это команда, которая при выполнении удалит базу данных customers. В идеале знать наименование bd, да и тип db тоже имеет значения.

-- Обозначает начало комментария в SQL. Все, что следует после этого, игнорируется СУБД. Это предотвращает возможные ошибки синтаксиса из-за оставшихся частей исходного запроса.

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

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

Хотите разобраться в этой теме глубже, без вреда для себя и окружающих? У меня есть решение. Готовя этот пост, я создал небольшое тестовое приложение для демонстрации SQL-инъекций. Поля для ввода данных, вы можете увидеть на картинке в шапке поста, они за токсичной белкой. В сборку входит: Dockerfile, docker-compose, код приложения на python + конфигурация nginx. Сделка проста, тридцать 👍 и я приступлю к созданию репозитория с подобными интересностями, одним из первых выложу это тестовое web - приложение для SQL-инъекций. Прикручу подробную инструкцию и сборку одной-двумя командами. Ну и вообще, репозиторий канала, вещь, как мне кажется, просто необходимая. Не в постах же код публиковать.

Всем доброй пятницы, друзья, и приятных выходных.

⌨️ Не быть джуном

#карьера

Когда меня спрашивают, как устроиться junior DevOps, я часто пожимаю плечами и говорю о том, что вообще сомневаюсь в существовании таких вакансий. Чести стать junior DevOps удостаиваются, в массе своей, одна категория людей — выпускники профильных вузовских специальностей. Джунами они, правда, становятся не сразу, а после практики. О попадании на практику я напишу как-нибудь потом — это отдельная боль и "голодные игры".

Хорошо, путь в junior DevOps для нас закрыт, допустим. Но что ты предлагаешь?

Есть несколько вариантов ответа на этот вопрос. Разберем ситуацию, когда у вас вообще нет опыта работы в IT. Стоит ли откликаться на вакансии junior DevOps? Я думаю, нет. Подобные вакансии привлекают слишком много внимания и там слишком высокие требования. А еще там присутствует тестовое задание, что, казалось бы, могло быть плюсом вакансии, но о тестовых заданиях мы тоже ещё поговорим. А уж если там отсутствует требование к опыту работы (которого у вас, напомню, тоже нет), откликаться на неё точно не стоит. Немного контринтуитивные выводы, правда? Сейчас всё объясню.

Почему это не лучший путь?
Слишком много чужих откликов, слишком мало шансов.
Примите во внимание тот факт, что, скорее всего, вы не машина, а человек. В ситуациях, когда 95% ваших откликов будут полностью игнорироваться, тестовые задания будут отнимать кучу сил и времени, а после тех редких технических собеседований, на которые вы попадёте, вам будут приходить отказы — выгореть очень легко. Не каждый человек имеет достаточно воли ломиться в закрытую дверь на протяжении длительного времени.
Давайте постепенно идти к цели. Я сейчас опишу шаги в общих чертах, а подробно — в отдельных постах.

Начало начал
Ваша задача на первом этапе — не стать DevOps, а просто получить работу в IT или около IT. Благо на нашем направлении, а мы, вне зависимости от названия записи в трудовой книжке, все специалисты по эксплуатации (немного кондовое обозначение, но зато зонтичное), достаточно специальностей, пригодных для старта IT-карьеры. Обратите внимание на такие вакансии, как: специалист третьей линии поддержки, эникей, дежурный инженер мониторинга, и так далее.
Устроившись на эту вакансию, ваша задача — проработать там от одного года, попутно готовясь ко второму этапу.

Еще не девопс, но уже не джун
А вот теперь вторая часть нашего плана. Теперь нам нужна мидловая вакансия. Опять же, подойдет почти любая с приставкой "мидл", вне зависимости от того, указана она явно или предполагается опытом работы (который у вас уже есть): системный администратор, администратор серверов, сетевой инженер, DBA.
Устроились? Вы великолепны. У вас есть годик или чуть больше, чтобы подготовиться к последнему рывку.

Устраиваемся middle DevOps/SRE
Вот теперь вы готовы и близки к цели — получить высокооплачиваемую работу с большими перспективами.

Стоп, но ведь я не работал DevOps?

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

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

⌨️ Контейнеры и Zero Trust. Познаём безопасность, прокачиваем резюме

#docker #ImproveCV #ShowYourSkills

Фундаментальная идея модели безопасности Zero Trust заключается в том, что к внешним и внутренним объектам следует относиться одинаково. Это означает выход за рамки традиционного подхода к безопасности, основанного на «периметре», когда пользователям или серверам во внутреннем периметре компании можно автоматически доверять. В модели Zero Trust привилегии предоставляются исключительно на основе идентификации и роли, мы никому и ничему не доверяем по умолчанию.

Аналогия: Раньше фермер ожидал опасности лишь снаружи, от диких зверей, которые водились за пределами его угодий и пастбищ. Для защиты от внешних угроз высокого забора казалось достаточно, но времена меняются. Фермер пережил несколько инцидентов, связанных с болезнями скота, падежом и бешенством. Он понёс серьёзные убытки и понял, что важна также внутренняя безопасность и порядок. С тех пор все животные снабжены специальными бирками, привязывающими их к конкретным зонам и разрешающими доступ только к определённым кормушкам.

Контейнеры, такие как Docker, предоставляют изолированные среды для приложений, однако их изоляция не абсолютна, что делает их уязвимыми для атак. Применение модели Zero Trust обеспечивает строгий контроль для каждого взаимодействия как внутри контейнерной инфраструктуры, так и для каждого контейнера отдельно. Это минимизирует риски несанкционированного доступа и последовательного взлома систем по схеме «одну за одной», «одну через другую» в одной сети (lateral movement).

Давайте рассмотрим некоторые базовые механизмы и принципы:

Принцип наименьших привилегий — это фундаментальный подход к безопасности, утверждающий, что пользователь, программа или процесс должны иметь только минимальные разрешения, необходимые для выполнения своей предполагаемой функции, и не более. Что касается работы с контейнерами, эффективная реализация этого принципа требует использования AppArmor/SELinux и профилей seccomp. Это позволит обеспечить невозможность запуска контейнеров с root-правами, недопустимость запроса и получения контейнерами повышенных привилегий.

Дополнительно управление привилегиями в Linux осуществляется через механизм capabilities. По умолчанию Docker предоставляет контейнерам ограниченный набор таких привилегий, однако для повышения безопасности рекомендуется явно запрещать все привилегии и затем разрешать только необходимые. Это достигается с помощью опций --cap-drop и --cap-add при запуске контейнера. Например, команда:

docker run --cap-drop ALL --cap-add CHOWN <image_name>

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

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

А теперь самый главный вопрос: зачем тебе это знать, разбираться и практиковаться?

Всё просто — чтобы добавить в своё резюме и уметь защитить следующую строчку, например:

Настройка контейнеров Docker в соответствии с принципом минимальных привилегий через управление Capabilities, профили AppArmor/политики SELinux, с автоматизацией сборки и развертывания посредством CI/CD (GitLab), а также анализом уязвимостей контейнерных образов с помощью Clair/Trivy.

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

⌨️ docker.sock

#docker

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

dockerd
docker API
docker CLI

Давайте разберемся в каждом из этих пунктов. C dockerd всё более менее понятно, это фоновый процесс (демон), управляющий всеми аспектами работы docker на хосте. Обрабатывает запросы на создания контейнеров, создает контейнеры, уничтожает контейнеры. Командный центр, взаимодействующий непосредственно с ОС хоста в части изоляции, также управляет сетями и хранилищами.

Docker CLI (Command Line Interface) тоже затруднений вызывать не должен, самый базовый способ взаимодействия с docker. Если вы знакомы с командами docker run / ps / images / build / stop / rm / rmi, значит с CLI вы уже работали.

Эти две сущности должно что-то связывать и эту работу берет на себя REST API через UNIX сокеты или сетевой интерфейс. По умолчанию сокет докера располагается в /var/run/docker.sock и готов принять запросы не только от Docker CLI, но и любого другого клиентского приложения.

Возможность обращаться к сокету напрямую, очень удобна, но является благодатной почвой для разного рода уязвимостей. Владельцем данного ресурса должен быть пользователь root. Предоставлять доступ к docker.sock другому пользователю означает, означает выдать ему root-привилегий хоста, поскольку сам демон dockerd запускается с такими правами. Кроме того, не следует монтировать этот сокет внутрь контейнера (например, через volume), по сути подобное действие означает передачу контроля над хост системой контейнеру.

⌨️ Planning poker

#Agile #PersonalExperience

Всех с предпоследней пятницей года! Сегодня расскажу о покере планирования — инструменте невероятной простоты и эффективности. Традиционно эту методику относят к Agile, что логично: человек, описавший эту методику, был одним из соавторов Agile-манифеста . Текущий пост скорее описывает опыт автора, а не саму концепцию. Поэтому я не буду углубляться в разъяснение терминологии, касающейся современных (или уже не очень) методов разработки. О них расскажу вам позже.

Название метода указывает на проблему, которую он пытается решить: как с большей точностью оценить и запланировать задачу.
Сначала вводные. Бизнес или смежные отделы просят отдел DevOps решить большую задачу — скажем, развернуть в инфраструктуре новый k8s-кластер или расширить существующий. Эта большая задача оценивается приблизительно и с запасом, в формате: «Сделаем до такого-то числа, если не возникнет форс-мажоров». Так как задача большая, её необходимо разделить на несколько задач поменьше, которые уже можно оценить с той или иной точностью.
Итак, собираем новый кластер. Что надо сделать?

Декомпозируем задачу:
Заказать новые серверы у хостинговой компании.
Протестировать их (чтобы предупредить проблемы при эксплуатации).
Выполнить преинстал (новые серверы должны на базовом уровне соответствовать другим серверам парка в части ОС, установленного базового ПО, сетевых настроек, прав пользователей и так далее).
Развернуть на них кластер.
Настроить мониторинг кластера и серверов.
Подключить кластер к уже существующей реализации Argo CD (инструмент для удобства деплоя, выполняющий роль прослойки между вашим репозиторием и кластером).

Каждую задачу необходимо оценить отдельно.

Приступаем к оценке. Сразу обозначу некоторое противоречие: несмотря на то что мы будем оценивать задачу в часах, оцениваем мы скорее не время, а усилия и ресурсы, необходимые для завершения задачи с учётом неопределённости.

В оригинальной версии покера планирования это могут быть стори-пойнты (Story Points) — по сути, абстрактные единицы оценки сложности задачи. Классические статьи на эту тему предлагают пользоваться размером одежды (XS, S, M, L, XL … XXL), размером собак (от чихуахуа до волкодава) или просто числами из адаптированного ряда Фибоначчи (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 или 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100). Зачем такие сложности?

Это попытка абстрагироваться от времени как единицы измерения. Однако я предпочитаю всё-таки оценивать задачи в часах. Будем использовать следующий ряд: 2h, 4h, 8h или 1d, 2d, где h — часы, d — дни. Даже из этого не слишком длинного ряда я бы убрал 6h как оценку, нагнетающую неопределённость: рабочий день длится 8 часов, а оценить задачу в ⅔ рабочего дня не совсем понятно. Цифра 6, полагаю, предназначена для задач, которые кажутся слишком большими для 4 часов и слишком маленькими для 8. Но почему бы тогда не округлить в большую сторону?

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

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

⌨️ HR фрустрирует

#из_первых_рук
#рекрутинг

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

Я не сторонник идеи прекрасного мира рынка без HR и уж точно не считаю, что именно они сломали систему найма. Мы живем в мире с разделением труда, и возвращаться к чучхе, где каждый тимлид сам себе HR, мне не хочется. Кесарю — кесарево, слесарю — слесарево. В противном случае можно договориться до того, что вообще никто, кроме разработчиков, в IT не нужен.
И тем не менее, есть ситуации, когда HR может создать больше проблем, чем решить. Вот пример. Если СТО опаздывает на собеседование, то не стоит брать на себя его работу и начинать собеседовать вместо него. HR, пытаясь заполнить паузу, попросила соискателя рассказать о своём опыте. Соискатель рассказал — и, на мой взгляд, прекрасно справился: самопрезентация была отличной, технологии, задачи, трудности — всё изложено чётко и по делу. HR кивала и подбадривающе улыбалась,. А потом пришел СТО и задал тот же самый вопрос.

На этом этапе соискатель, осознав бессмысленность своего первого ответа, стушевался. Его повторная самопрезентация была сбивчивой: технологии, задачи, трудности — всё скомкано и неполно. Закончил он на полуслове, так что повисла неловкая пауза. Пара коротких ответов на вопросы СТО — и сразу перешли к технической части. Самопрезентация была провалена.
Есть ли в этом вина HR? Можно ли было поступить лучше? Думаю, да. Например, HR мог просто завести лёгкий разговор, чтобы разрядить обстановку и потянуть время: о погоде, интересах, чём-то нейтральном. Возможно, если бы соискатель воспринял первый вопрос как "разминку" и вложил в ответ меньше стараний, ситуация сложилась бы иначе. Или если бы HR предложил ему кратко подготовить ключевые моменты для СТО. Но сложилось как сложилось. Вывод следующий: HR не принимает решения об успешности технического интервью. Держите это в голове, оказавшись в похожей ситуации, и приберегите своё вдохновение для тех, кто действительно будет выносить вердикт.

Однако фрустрацию от проваленной самопрезентации можно превзойти. Например, вот такой обратной связью от HR:

XXX, добрый день!
Хотела бы сообщить обратную связь, как и обещала.
К сожалению, в данный момент не удалось получить положительный фидбек от лида команды. Ваш грейд был оценён на Junior+, мы же сейчас ищем Middle+/Senior. Спасибо за уделённое время и желаем вам успехов!

Спасибо за подтверждение грейда, конечно. Собеседование проходил Junior+, он претендовал на оклад Junior+, имел резюме с четко указанным Junior+ опытом. Как получилось, что джун попал на собеседование для сеньоров? Соискателя не смутило, что в вакансии указаны требования опыта, которого у него нет. Это была очень большая компания, и он рассудил: раз приглашают на техсобес, значит, его опыт устроил. HR не смутило "несеньёрское" резюме и запросы по окладу. Лид команды тоже не придал значения несоответствию уровня. Все остались довольны (нет), все с пользой (нет) провели своё время. Где же тот самый HR-фильтр, когда он так нужен?
Эти истории не выдающиеся, и даже провал HR в каждой из них не так очевиден. Главная проблема в них, конечно, пресловутое недопонимание, или, английское слово, подходящее чуть более, — miscommunication.
Тем не менее, истории правдивые, без прикрас и, возможно, даже слегка поучительные.

Всем успеть завершить дела до Нового года и провести время с пользой!

⌨️ Когда я смогу закончить учиться? (1/5)

#PersonalExperience

Этот вопрос повис в воздухе в тот момент, когда я осознал, что для развития себя как условного DevOps-инженера, знаний, которые я получаю на работе, никогда не будет достаточно. Придётся учиться и получать знания дополнительно и, скорее всего, на протяжении длительного времени. Причин тут огромное количество, вот 6, что пришли мне в голову первыми:

Жадность. Простое человеческое хочется больше денег. Вечное соревнование в дисциплине “успешность”, заложенное природой, которое и привело человечество в целом к невероятному прорыву (оно же может впоследствии его и уничтожить как вид, но не будем о грустном). Человечество может и привело, но вечная гонка, лично тебя, способна сделать несчастным и отстающим от других в сферах жизни, не связанных с потреблением и накоплением материальных ресурсов. Как это связано со сферой, где знания напрямую коррелируют с зарплатой, объяснять излишне.

Сертификации и собеседования. Мне на ум не приходит отрасль, где настолько требовалось подтверждение знаний и было столько вендоров, это подтверждение предоставляющих. А зачем они нужны лично тебе? Смотри пункт первый: если сертификат может удвоить твою зарплату, то почему бы его не получить? Про IT-собеседования тут даже ничего писать не буду, кто знает, тот знает. Кто не знает, у меня ещё много постов на эту тему будет.

Всем привет, пост в этот раз получился очень объёмным, поэтому я разбил его на 5 (!) частей, так что это выходит первая из пяти.

В следующей части я вкратце опишу ещё две причины и отвечу на вопросы:
Как legacy на вашей текущей работе заставит вас почувствовать отставание?
Почему автоматизация вами рутины приводит к рутине второго порядка?

👰‍♀️ Календарный цикл найма: когда лучше всего искать работу

#рекрутинг

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

Календарный цикл найма айти-специалистов в России условно делится на 5 сезонов.

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

Февраль-апрель: пик активности. Салаты доедены, проекты стартуют.


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

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


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

Желаю счастливого нового года и, если планируете менять работу, дотянуть до следующего пика найма на нынешнем месте!

⌨️ Когда я смогу закончить учиться? (2/5)

#PersonalExperience

В предыдущей серии: жадность и специфика отрасли как вечные драйверы вашей учёбы в нерабочее время.

Legacy. Всегда в положении догоняющего. Например, в 95% случаев практики эксплуатации вашей инфраструктуры отстают минимум года на три (а то на 5–10) от современных отраслевых стандартов. Действительно, нам бы успевать поддерживать актуальные версии утилит, какие там инфраструктурные инновации? Если в саму концепцию вашей инфры не заложена гибкость (а она, скорее всего, не заложена), то хоть сколько-нибудь значимый пересмотр и изменение практик будет стоить вам столько головной боли, человеко-часов и согласований со смежными отделами, что высказывание «работает — не трогай» покажется вам непреложной истиной. И даже если вам удастся согласовать инновации, то компетенций и опыта для их внедрения, скорее всего, не окажется, придётся зарываться в документацию и набивать шишки, что в целом не такой уж и плохой путь: он удовлетворяет двум критериям — вам за это платят и ваша компетенция растёт. Но опять же это не учеба, это боевые знания, которые хоть и ценятся выше, всё же несколько ограничены реальными условиями, выделенными под задачи временем и вечной необходимостью технических компромиссов (читай костылей, то там, то тут).

Рутина. Эх, если бы хотя бы каждый второй рабочий час шёл на улучшение ваших навыков, но нет: затыки, тушение пожаров и рутина — вечные спутники инженеров нашей направленности. И даже избавляя себя и свой отдел от рутины путём автоматизации того, что раньше делалось руками, bash-скриптами или бог ещё знает чем, вы просто выходите на новый уровень рутины. Теперь вам предстоит поддерживать ваше решение до собственного ухода из компании, а всё потому что вы просто автоматизировали рутину, не изменив саму практику.

В следующей части я вкратце опишу ещё две причины и отвечу на вопросы:
- Какой процесс сильно ускорило широкое распространение нейросетей?
- Почему в большинстве случаев переходить на новую работу выгоднее, чем просить повышения на старой?

Пишите в комментариях, почему лично вы не можете сейчас взять и перестать учиться, может быть наберем материал на ещё один пост. ⬇️

⌨️ Когда я смогу закончить учиться? (3/5)

#PersonalExperience

Первая часть
Вторая часть

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

Сфера меняется. Вы можете поверить в то, что 8 лет назад крутым админом делало умение писать bash-скрипты, которые могли в цикле пробежаться по списку сервисов и выполнить там ту или иную команду? А что 5 лет назад человек, который мог превратить ваш doc-файл с инструкцией по подготовке сервера, установке и настройке утилиты в Ansible-роль, был самым ценным сотрудником в отделе? Вот и я нет, а это было. Абсолютно непонятно, что быстрее девальвируется: наши навыки или наша зарплата. И это происходило ещё до того, как в нашу жизнь ворвался генеративный AI. С какой скоростью сейчас наши навыки станут обесцениваться — страшно представить.

Рынок растёт быстрее, чем зарплата. Сидеть на одном месте абсолютно невыгодно. Новички, приходящие в вашу компанию, стандартно будут получать больше. А вы, требующий повышения или хотя бы индексации, будете получать крохи, и в конце концов решите, что сменить работодателя, получив x2 к окладу, всё же слегка продуктивнее, чем выпрашивать по 10–20 процентов в год. А чтобы сменить работу, требуются знания, адекватные рынку.

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

Пишите в комментариях, почему лично вы не можете сейчас взять и перестать учиться. Может быть, наберём материал на ещё один небольшой пост. ⬇️

⌨️ Когда я смогу закончить учиться? (4/5)

#PersonalExperience

Первая часть
Вторая часть
Третья часть

В предыдущей серии:
Владение каким навыком 8 лет назад сделало бы Вас уважаемым админом?
Почему часто легче и выгоднее найти новую работу, чем просить прибавку к зарплате?

Возвращаясь к заданному в начале статьи вопросу: когда можно расслабиться и перестать учиться?

Подготовьтесь и пройдите сертификацию в зависимости от вашего профессионального профиля. Работаете с облаками, которые располагаются вне РФ, пройдите сертификацию одного из провайдеров большой тройки: Azure (Microsoft), если собираетесь работать на европейскую компанию, AWS, если на американскую, Google Cloud, если вам нравится Google Cloud. Если работаете напрямую с Linux, сдайте вендор-агностик CompTIA Linux+ или LPIC, или специфическую типа Red Hat (они, кстати, сертифицируют и по Ansible тоже). Работаете с кубером — пройдите одну из соответствующих сертификаций от Linux Foundation. Там ещё HashiCorp сертифицирует IaC, круто cloud-агностик-скиллы, куда же без них) и GitLab удостоверяет ваши знания по автоматизации…

Получили? Не забудьте сменить работу (переоценка ваших новых и подтверждённых знаний на старом рабочем месте будет проходить оооооочень медленно). Готово, вы великолепны, можно не учиться года два-три, пока не придётся обновлять сертификат, но вспоминать же всё равно легче, правда? Там ещё какая-нибудь must-have технология появится на горизонте.

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

⌨️ Когда я смогу закончить учиться? (5/5)

Первая часть
Вторая часть
Третья часть
Четвертая часть

В предыдущей серии:
Сертификации и смена работы, очень обнадеживающе (нет).

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

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

Но что-то мне подсказывает, что если вы тут, то цель у вас несколько другая. Может быть, найти новую работу и увеличить свой доход в два раза? Релоцироваться в Европу? Или найти валютную удалёнку? Work-life-study balance мы тоже обязательно найдём, но сначала придётся хорошенько поработать. Когда я смогу закончить учиться? Когда почувствуете сытость, когда вам станет абсолютно комфортно с финансовой и карьерной точки зрения.

Прислушайтесь к себе, если вы голодны, то заканчивать учиться ещё не время.