[Карьера в IT-индустрии, DevOps] Собеседование в DevOps Engineering, как оценить свой опыт и сколько нужно знать?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
Основное про DevOps и про обязанностиDevOps — это набор практик, которые помогают автоматизировать и интегрировать процессы между командой разработчиков и командой ответственной за инфраструктуру, чтобы они могли быстрее и надежнее собирать, тестировать и выпускать релизы. Основная цель подхода - убрать "стену" между командой разработки и командой Operations (Operations так же называют: System Administration, System Engineering) и увеличить скорость релизов. "Стена" образуется из-за того что у команд разные цели. Разработчики преследуют цель выпускать релизы как можно чаще, а Operations снизить количество отказов или держать энвайрмент стабильным и безопасным. DevOps подход объединяет команды, цели и делит риски.Основные практики DevOps это:
- Continuous Integration
- Continuous Delivery
- Continuous Deployment
- Continuous Testing
- Continuous Monitoring
- Infrastructure as Code
Некоторые практики разделяются между инженерами, например QA может отвечать за Continuous Testing а Security за Continuous Monitoring. Как правило, инженер который получил роль DevOps (не принято говорить "DevOps инженер" но рынок уже взял в оборот, звучит так же неопределенно как "Scrum инженер") отвечает за все что происходит с момента как команда разработки пушнула код в репозиторий или выпустила релиз. Т.е за CI/CD пайплайны, энвайрменты проекта и базовый мониторинг. Сколько инструментов в домене DevOps и что именно нужно знать?PROD Grade инфраcтруктура, CI/CD пайплайны и мониторинг это целая экосистема инструментов. Сейчас это более 100 популярных названий. Какие то из них нужно знать глубоко и уметь конфигурировать. Некоторые достаточно настроить однажды, прочитав короткую документацию. 
В области технической экспертизы DevOps возникает вопрос: что именно выбирать, сколько вообще инструментов нужно знать и что показывать на собеседовании?Инженеры переходящие в DevOps, например из системного администрирования, при выборе технологий "для изучения" испытывают страх что они будут привязаны к чему то одному и для другого проекта их опыт будет не актуален. Тут можно немного успокоить: если вы научились писать код Terraform вы справитесь и с Ansible, не потому что они похожи или близки в синтаксисе, нет, ваш мозг теперь умеет решать задачи автоматизации, а психика окрепла верой в себя. На собеседовании это будет заметно и в большинстве случаев вызовет адекватное доверие. Поэтому не стоит стремится выучить большое количество инструментов. Если вы просто учитесь, выберите инструменты которые вам реально интересны, это даст позитивную энергию и удовольствие от процесса обучения.Если выбор происходит при запуске нового проекта, появляется страх перед неверным выбором инструмента. Тут тоже не стоит тратить много энергии. Рано или поздно вам придется мигрировать с инструмента на инструмент такова жизнь инженера. Миграция это бесценный опыт, так что вместо того что бы исследовать все риски можно следовать Agile принципам и просто сделать MVP вашей автоматизации. В большинстве случаев MVP перерастает в основное решение.Какое количество инструментов/платформ и насколько глубоко вам нужно знатьЧто бы облегчить задачу выбора, все инструменты DevOps можно поделить на домены:
На картинке представлено 30 наиболее популярных инструментов разделенных по соответствующим доменам, вы можете добавить домены или инструменты по необходимости. Стараться выучить все бессмысленно и долго, лучше выбрать из каждого домена один или два инструмента, и составить небольшую, личную матрицу компетенций, например:IaC: TerraformCM: AnsibleCloud: AWSCI/CD: CircleCIScripting: Python, BashContainerization: KubernetesMonitoring: ELK, PrometheusOS: LinuxSQL: Postgres, MongoDBКоличество инструментов сильно сократилось, но все равно список большой. Есть риск, что на собеседование придут неопытные интервьюверы-инженеры и если в резюме вы укажете все из вашего проекта или опыта, они будут проверять знание по всем заявленным вами инструментам, ожидая от вас высокого уровня. Такое интервью получится сложным и разочаровывающим. Лучше управлять ожиданиями и указать уровень владения инструментом или платформой разбив на относительно простые и условные категории:Novice - использовал инструмент/технологию однажды или читал документацию. (Эта категория имеет право на существование, например я устанавливал и настраивал MySQL для различных проектов, делал это раз тридцать точно, но каждый раз читая инструкции. Без предварительной подготовки я не расскажу хорошо про MySQL. Тем не менее не стоит увлекаться, если указать в CV все что вы "читали", резюме потеряет конкретику).Intermediate - уверенное использование технологии/инструмента (важное замечание: этот уровень может достигается через обучение).Advanced - широкий опыт использования на проектах, неоднократно приходилось конфигурировать/писать код, hands-on experience от года. Продолжительность hands-on experience очень важна, в IT это как боевые вылеты в авиации, если вы не просидели за консолью или IDE свои боевые часы решая задачу или выполняя issue troubleshooting, вы не обретете экспертизу и не погрузитесь в технологию. (Здесь не надо беспокоиться если вам скучно в консоли или в IDE, иногда вкус не сразу приходит). Можно говорить, что Advanced уровень приобретается на PROD проектах, но иногда учебный проект может быть сложнее реального PROD заказчика. Expert - использовал технологию на сложных проектах продолжительное время от года и выше. Знает лучше чем производитель технологии или является коммиттером.*эти категории можно критиковать в комментариях, это позволит выработать более точную модель!!Теперь получилась следующая матрица:IaC: Terraform - AdvancedCM: Ansible - IntermediateCloud: AWS - IntermediateCI/CD: CircleCI - NoviceScripting: Python, Bash - NoviceContainerization: Kubernetes - IntermediateMonitoring: ELK, Prometheus - NoviceOS: Linux - AdvancedSQL: Postgres, MongoDB - NoviceТаким образом мы сильно сузили область, если вы только входите в профессию вам проще строить цели. Если вы идете на интервью, из этой матрицы видно, что нужно подтянуть и на какие темы общаться. Можно указать уровень владения в CV, но я бы рекомендовал выделять основные инструменты с которыми работаете на проекте и отдельной строкой категорию Novice. Это нужно для того что бы состоялся разговор по конкретному опыту. Тут можно добавить еще один еще один уровень оценки: если вы претендуете на позицию Senior DevOps Engineer, нужно владеть 3-4 инструментами на Advanced уровне и одним инструментом как Expert. Для Middle DevOps достаточно работать с 2-3 на Advanced. Итого, ваша матрица компетенций:Middle DevOps Engineer Terraform, Linux - Advanced: основные инструментыAWS, Ansible, Kubernetes - Intermediate: регулярно приходится решать задачиELK, Prometheus, CircleCI, Python, Bash, Postgres, MongoDB - Novice: общее понимание Конкретика в CV и на собеседовании избавляет от разочарования, вызывает доверие, и освобождает вас от траты времени на подготовку, например если вы не хотите учить SQL позволяя сконцентрироваться на том что реально нужно подтянуть. За последние 3 года я провел около 180 собеседований на роли DevOps, Senior DevOps и Team Lead в различные команды и с разными интервьюверами. Мне самому приходится проходить собеседования к различным заказчикам внутри компании. На интервью моя цель состоит в том, что бы раскрыть насколько опыт кандидата соответствует заявленному и как отвечает ожиданиям заказчика. Я так же проверяю насколько наши ожидания к открытой вакансии соответствуют с рынком, является ли они ниже или выше и можем ли мы влиять на это. Опыт интервьюируемого не должен совпадать с требованиями к позиции на 100%. Но к сожалению, приблизительно 70% интервьюируемых собеседование валят несмотря на то что это просто беседа, о заявленном кандидатом опыте, без каверзных вопросов. По сути, на интервью нужно показать что вы знаете, с чем сталкивались и имеете опыт, чего не знаете но хотели бы развиваться и мотивацию. Адекватная оценка своего опыта, общая эрудиция и мотивация, это ключ к позитивному собеседованию.
===========
Источник:
habr.com
===========
Похожие новости:
- [SQL, Data Mining, Big Data, Google Cloud Platform, Data Engineering] Вращение таблиц в Google BigQuery (PIVOT)
- [Исследования и прогнозы в IT, Карьера в IT-индустрии, Статистика в IT, IT-компании, Удалённая работа] В офисе полный рабочий день? «Нет, спасибо», – говорят 86 процентов IT специалистов (перевод)
- [Python, Data Mining, Big Data, Data Engineering] Оффер за 2 дня в X5: для Data Analyst/Data Scientist
- [Настройка Linux, Сетевые технологии, Big Data, DevOps] Сеть в bitly: Linux tc для минимизации издержек и забавы ради (перевод)
- [Системное администрирование, Облачные вычисления, DevOps, Kubernetes] Self-Hosted, или Kubernetes для богатых: почему самостоятельное развертывание кластера — не всегда способ сэкономить
- [Управление персоналом, Карьера в IT-индустрии, Научно-популярное] Откровения трезвого инженера (перевод)
- [Программирование, Учебный процесс в IT, Карьера в IT-индустрии] В разработчики пойду, пусть меня научат. Бакалаврские программы при поддержке JetBrains
- [Учебный процесс в IT, Контент-маркетинг, Карьера в IT-индустрии] Вебинар «Как начать писать о технологиях». Расскажем, что такое хороший технический текст и как его написать
- [Исследования и прогнозы в IT, Управление персоналом, Карьера в IT-индустрии, Здоровье] Bloomberg: сотрудники предпочитают увольнение возвращению с удаленки в офисы
- [Разработка игр, Управление персоналом, Карьера в IT-индустрии, Читальный зал] Как художнику найти работу мечты в геймдеве. А также советы по оформлению портфолио
Теги для поиска: #_karera_v_itindustrii (Карьера в IT-индустрии), #_devops, #_devops, #_sobesedovanie (собеседование), #_vojti_v_it (войти в ит), #_engineer, #_karera_v_itindustrii (
Карьера в IT-индустрии
), #_devops
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 16-Май 23:58
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
|
Основное про DevOps и про обязанностиDevOps — это набор практик, которые помогают автоматизировать и интегрировать процессы между командой разработчиков и командой ответственной за инфраструктуру, чтобы они могли быстрее и надежнее собирать, тестировать и выпускать релизы. Основная цель подхода - убрать "стену" между командой разработки и командой Operations (Operations так же называют: System Administration, System Engineering) и увеличить скорость релизов. "Стена" образуется из-за того что у команд разные цели. Разработчики преследуют цель выпускать релизы как можно чаще, а Operations снизить количество отказов или держать энвайрмент стабильным и безопасным. DevOps подход объединяет команды, цели и делит риски.Основные практики DevOps это:
 В области технической экспертизы DevOps возникает вопрос: что именно выбирать, сколько вообще инструментов нужно знать и что показывать на собеседовании?Инженеры переходящие в DevOps, например из системного администрирования, при выборе технологий "для изучения" испытывают страх что они будут привязаны к чему то одному и для другого проекта их опыт будет не актуален. Тут можно немного успокоить: если вы научились писать код Terraform вы справитесь и с Ansible, не потому что они похожи или близки в синтаксисе, нет, ваш мозг теперь умеет решать задачи автоматизации, а психика окрепла верой в себя. На собеседовании это будет заметно и в большинстве случаев вызовет адекватное доверие. Поэтому не стоит стремится выучить большое количество инструментов. Если вы просто учитесь, выберите инструменты которые вам реально интересны, это даст позитивную энергию и удовольствие от процесса обучения.Если выбор происходит при запуске нового проекта, появляется страх перед неверным выбором инструмента. Тут тоже не стоит тратить много энергии. Рано или поздно вам придется мигрировать с инструмента на инструмент такова жизнь инженера. Миграция это бесценный опыт, так что вместо того что бы исследовать все риски можно следовать Agile принципам и просто сделать MVP вашей автоматизации. В большинстве случаев MVP перерастает в основное решение.Какое количество инструментов/платформ и насколько глубоко вам нужно знатьЧто бы облегчить задачу выбора, все инструменты DevOps можно поделить на домены:  На картинке представлено 30 наиболее популярных инструментов разделенных по соответствующим доменам, вы можете добавить домены или инструменты по необходимости. Стараться выучить все бессмысленно и долго, лучше выбрать из каждого домена один или два инструмента, и составить небольшую, личную матрицу компетенций, например:IaC: TerraformCM: AnsibleCloud: AWSCI/CD: CircleCIScripting: Python, BashContainerization: KubernetesMonitoring: ELK, PrometheusOS: LinuxSQL: Postgres, MongoDBКоличество инструментов сильно сократилось, но все равно список большой. Есть риск, что на собеседование придут неопытные интервьюверы-инженеры и если в резюме вы укажете все из вашего проекта или опыта, они будут проверять знание по всем заявленным вами инструментам, ожидая от вас высокого уровня. Такое интервью получится сложным и разочаровывающим. Лучше управлять ожиданиями и указать уровень владения инструментом или платформой разбив на относительно простые и условные категории:Novice - использовал инструмент/технологию однажды или читал документацию. (Эта категория имеет право на существование, например я устанавливал и настраивал MySQL для различных проектов, делал это раз тридцать точно, но каждый раз читая инструкции. Без предварительной подготовки я не расскажу хорошо про MySQL. Тем не менее не стоит увлекаться, если указать в CV все что вы "читали", резюме потеряет конкретику).Intermediate - уверенное использование технологии/инструмента (важное замечание: этот уровень может достигается через обучение).Advanced - широкий опыт использования на проектах, неоднократно приходилось конфигурировать/писать код, hands-on experience от года. Продолжительность hands-on experience очень важна, в IT это как боевые вылеты в авиации, если вы не просидели за консолью или IDE свои боевые часы решая задачу или выполняя issue troubleshooting, вы не обретете экспертизу и не погрузитесь в технологию. (Здесь не надо беспокоиться если вам скучно в консоли или в IDE, иногда вкус не сразу приходит). Можно говорить, что Advanced уровень приобретается на PROD проектах, но иногда учебный проект может быть сложнее реального PROD заказчика. Expert - использовал технологию на сложных проектах продолжительное время от года и выше. Знает лучше чем производитель технологии или является коммиттером.*эти категории можно критиковать в комментариях, это позволит выработать более точную модель!!Теперь получилась следующая матрица:IaC: Terraform - AdvancedCM: Ansible - IntermediateCloud: AWS - IntermediateCI/CD: CircleCI - NoviceScripting: Python, Bash - NoviceContainerization: Kubernetes - IntermediateMonitoring: ELK, Prometheus - NoviceOS: Linux - AdvancedSQL: Postgres, MongoDB - NoviceТаким образом мы сильно сузили область, если вы только входите в профессию вам проще строить цели. Если вы идете на интервью, из этой матрицы видно, что нужно подтянуть и на какие темы общаться. Можно указать уровень владения в CV, но я бы рекомендовал выделять основные инструменты с которыми работаете на проекте и отдельной строкой категорию Novice. Это нужно для того что бы состоялся разговор по конкретному опыту. Тут можно добавить еще один еще один уровень оценки: если вы претендуете на позицию Senior DevOps Engineer, нужно владеть 3-4 инструментами на Advanced уровне и одним инструментом как Expert. Для Middle DevOps достаточно работать с 2-3 на Advanced. Итого, ваша матрица компетенций:Middle DevOps Engineer Terraform, Linux - Advanced: основные инструментыAWS, Ansible, Kubernetes - Intermediate: регулярно приходится решать задачиELK, Prometheus, CircleCI, Python, Bash, Postgres, MongoDB - Novice: общее понимание Конкретика в CV и на собеседовании избавляет от разочарования, вызывает доверие, и освобождает вас от траты времени на подготовку, например если вы не хотите учить SQL позволяя сконцентрироваться на том что реально нужно подтянуть. За последние 3 года я провел около 180 собеседований на роли DevOps, Senior DevOps и Team Lead в различные команды и с разными интервьюверами. Мне самому приходится проходить собеседования к различным заказчикам внутри компании. На интервью моя цель состоит в том, что бы раскрыть насколько опыт кандидата соответствует заявленному и как отвечает ожиданиям заказчика. Я так же проверяю насколько наши ожидания к открытой вакансии соответствуют с рынком, является ли они ниже или выше и можем ли мы влиять на это. Опыт интервьюируемого не должен совпадать с требованиями к позиции на 100%. Но к сожалению, приблизительно 70% интервьюируемых собеседование валят несмотря на то что это просто беседа, о заявленном кандидатом опыте, без каверзных вопросов. По сути, на интервью нужно показать что вы знаете, с чем сталкивались и имеете опыт, чего не знаете но хотели бы развиваться и мотивацию. Адекватная оценка своего опыта, общая эрудиция и мотивация, это ключ к позитивному собеседованию. =========== Источник: habr.com =========== Похожие новости:
Карьера в IT-индустрии ), #_devops |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 16-Май 23:58
Часовой пояс: UTC + 5