👰‍♀️ Что делать после провального интервью?

#рекрутинг

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

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

2. На основании фидбека, а также собственных ощущений, выпишите вопросы, на которых застопорились, и распишите красивые, максимально полные ответы на них.

3. Если у вас есть ментор - разберите эти вопросы с ним.

4. Помните, что любой опыт, даже негативный, очень ценен. Каждое следующее интервью будет даваться легче предыдущего, и работа мечты уже не за горами!

Дайджест#1

#дайджест

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

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

Приятного чтения!

#рекрутинг

👰‍♀️ Как точно НЕ получить работу в айти: 5 простых шагов. Вредные советы

👰‍♀️ Так почему они вредные?

👰‍♀️ Странные вопросы на интервью

👰‍♀️ Лучший запрос самооценки, лучшая обратная связь

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

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

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

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

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

👰‍♀️ Самая высокооплачиваемая айти-профессия

#process_management

⌨️ Из чего сделаны наши процессы?

⌨️ Внутри процесса (thread inside)

⌨️ Имя отчество (PID PPID)

⌨️ Как они размножаются? fork()/clone() exec()

⌨️ Отцы и дети (parent - child processes)

⌨️ Родился, потерпел и умер: Жизненный цикл процесса

⌨️ Биография. Вспоминаем и делимся

⌨️ STAT Жди, работай, спи

⌨️ Сигналы: 30 способов умереть или быть убитым

#PersonalExperience

👰‍♀️ О моём опыте собеса на сисадмина (начало)

👰‍♀️ О моём опыте собеса на сисадмина (продолжение)

⌨️ Planning poker

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

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

⌨️ Вопросы с реального собеседования #1

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

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

#мотивация

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

#docker

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

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

⌨️ docker.sock

#k8s

⌨️ K8s. Компоненты кластера

⌨️ K8s. Pod

#карьера

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

⌨️ Об отношениях с работодателем

#собеседования

⌨️ Немного о чудовищных собеседованиях

#интересное

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

⌨️ Задачи (1/4)

#PersonalExperience

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

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

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

Какие задачи интересны лично мне в первую очередь?

Два типа задач.

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

Второй тип — это задачи, которые позволяют улучшить навыки в технологиях, востребованных на рынке труда. Решив такую задачу, понимаешь, что теперь твое время как специалиста стоит дороже. Для меня сейчас это в основном DevSecOps-таски: работа с GitLab CI, Vault, Terraform, Go, K8s и различным прикладным софтом.

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

Но бывают и другие задачи. Они почти не дают профессионального роста, но при этом отнимают кучу времени. Это задачи, над которыми приходится корпеть не только днем, в рабочее время, но и ночью, вместо сна. Однако, выполнив их, ты испытываешь невероятное удовлетворение. Кроме того, подобные задачи в твоем активе — отличный аргумент, чтобы попросить повышение зарплаты.

Что это за задачи и подробности об одной из них — в следующем посте, который выйдет завтра.

⌨️ Задачи (2/4)

#PersonalExperience

Надеюсь ваша среда была легче чем моя.

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

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

Даже в компаниях, где инфраструктура полностью описана в коде, может существовать неавтоматизированный разрыв между предоставлением сервера под управление и его попаданием в инфраструктуру. Особенно если провайдер не имеет API или сдаёт в аренду выделенные серверы.

Физические выделенные серверы (Dedicated) имеют ряд преимуществ над виртуальными и облачными решениями:

Предсказуемая производительность без влияния "шумных соседей" (noisy neighbors)

Отсутствие оверхеда гипервизора и задержек связанных с шарингом ресурсов.

Стоимость тоже является преимуществом dedicated серверов. Аренда выделенных серверов может оказаться выгоднее, особенно в перспективе.

Недостатков тоже хватает:

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

! Гибкость — если сервер простаивает, его ресурсы нельзя оперативно перераспределить.

Физическая уязвимость — поломка HDD, RAM или другого компонента может привести к простоям.

И именно последний недостаток такого подхода, послужил причиной образования неавтоматизированной лакуны. Перед тем как сервер станет частью твоей инфраструктуры, все его компоненты необходимо проверить. Как это сделать часто указывает скрижаль древних в формате docx. И в первый раз выполнив все предписываемые инструкции я едва не выгорел…

⌨️ Задачи (3/4)

#PersonalExperience

Днями выше рассказал вам о некоторых нюансах профессии, с которыми мне пришлось столкнуться. В рабочем процессе присутствовала неавтоматизированная лакуна — порядка 200 кликов для каждого сервера. Она включала в себя выполнение операций на хосте в аналоге live-CD режима (с операционной системой, загруженной в оперативную память) и внесение полученных результатов в таблицу. Причём по одному значению, так как вывод из консоли не был отформатирован в достаточной мере.

Но как получилось, что столь очевидная цель для автоматизации оставалась неотработанной? Дело в нестандартной конфигурации: одни и те же команды утилиты, запущенные на разном железе, показывали если и не разный вывод, то, как минимум, различное расположение ключевых значений (тех, что в итоге оказывались в таблице). Это зависело, например, от производителя. Самый простой пример такой разницы — показания температуры ядер под нагрузкой. lm-sensors, указанная в скрижалях древних, выдавала разный вывод в зависимости от того, был процессор произведён Intel или AMD. Да что там производитель — вывод отличался даже в зависимости от поколения чипа.

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

Пришлось взяться за это. Ситуация осложнялась тем, что первый рабочий прототип утилиты (а это процентов 70 всей работы) я решил написать, не ставя никого в известность, используя только то время, что было выделено под тестирование серверов. Причина банальна: я не сомневался, что автоматизация возможна, и не сомневался в своей компетенции. Я думал о другом — хватит ли мне терпения довести утилиту до состояния, в котором ею сможет пользоваться кто-то, кроме меня. Потому не хотел идти к тимлиду с пустыми руками, имея лишь идею. Хотел оставить себе пути для отступления.

Не буду подробно описывать процесс разработки. Скажу лишь, что писал на Python, взяв за основу библиотеку fabric для основной части утилиты и openpyxl для парсера. Отдельную боль доставило тестирование дисков: пришлось разрабатывать для них отдельную логику, поскольку различались как их количество, так и состояние (диски могли поставляться дата-центром как в RAID, так и без него, с файловой системой нужного формата или без неё). Скрипт должен был, без ручного вмешательства, приводить диски к целевому состоянию.

В итоге мне удалось разработать прототип утилиты для тестирования, а позже довести её до ума. Спустя некоторое время я упаковал её в контейнер и сделал возможность запуска непосредственно из GitLab, соорудив для неё пайплайн.

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

⌨️ Задачи (4/4)

#PersonalExperience

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

Часть 1, в которой я рассказываю о типах рабочих задач и их пользе.

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

Часть 3, в которой я, наконец, описываю задачу и некоторые подробности её решения.

Подведем итоги

Я решил поставленную самому себе задачу. Что получил в качестве награды?

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

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

Избавление от ненавистной мне задачи, которая опасно приближала моё выгорание.

Респект и уважение от команды (скорее всего).

Что получила моя команда?

Сокращение количества действий для выполнения типовой и довольно частой задачи процентов на 90-95. Теперь она оценивается минимальным количеством стори-пойнтов. Надеюсь, что я также отсрочил чьё-то выгорание.

Вывод

Задачи, повышающие собственное work quality и work quality твоих коллег, обладают невероятным потенциалом для satisfaction. Если по-русски, то очень приятно видеть пользу от своего труда. Это помогает любить своё дело и видеть в нем смысл.

Любить свою работу полезно, потому что не любить то, чему посвящаешь треть своего времени, чревато негативными последствиями — как физического, так и ментального характера. Осознаю банальность вывода, но к чему пришёл, к тому пришёл.

Поэтому всем интересных задач, а я пошёл писать серию постов на тему K8s 101 и рисовать к ним схемы. Увидимся на следующей неделе!

⌨️ Всем привет!

Завтра обещанный пост на тему K8s 101. Разберу популярный вопрос с собеседований:

«Опишите путь, который проходит Pod от момента деплоя его манифеста до статуса Running».

А прямо сейчас читайте пост Кати 👰‍♀️ о том, что писать в разделе «О себе» в резюме!

👰‍♀️ Что писать в поле “О себе”?

#рекрутинг

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

1. Самым лучшим решением будет указать телеграм для связи. У многих рекрутеров, в частности, почти во всех агентствах, не оплачена база открытия контактов в Хэдхантере. Вписав телеграм в поле “О себе”, вы будете получать больше предложений пройти интервью.

2. Можно кратко суммировать весь свой опыт. Например “DevOps-инженер с трехлетним опытом работы в интеграторе и продуктовой компании с отличным знанием Kubernetes”.

3. Описать, что вы ищете и в каком направлении хотели бы развиваться. “Рассматриваю предложения с возможностью удаленки из-за пределов РФ и зарплатой в валюте” или “Хотел бы работать в компании, продукт которой полезен людям. Букмекерские конторы и казино не рассматриваю”.

4. Информация о ваших увлечениях вне работы совершенно не обязательна. Но если хочется сделать резюме более живым и человечным - почему бы и нет 🙂