Приветствую вас всех, мои дорогие читатели!
Сегодня я хочу поделиться своими мыслями о давно наболевшей теме, и возможно, обсудить ее в комментариях.
Достаточно часто мне попадаются статьи по плохим практикам собеседования на должность программиста, которые на мой взгляд достаточно жизнены и, надеюсь, читаемы HR отделами компаний крупных и не очень.
В наших краях, насколько мне можно судить, есть востребованность таких интересных сущностей, как DevOps инженер. Я отношусь к тем людям, кто такое словосочетание не очень воспринимает ( да-да, DevOps методология, и тд ), поэтому вижу некоторое различие в путях развития у данной группы специалистов.
В первую очередь, я свято верю, что у каждого человека есть свой круг интересов, даже в рабочей области, то есть кому то по душе облака, кому то заниматься глубоким копанием в Application servers, настраивать глубоко Java, а кому то писать код на Python или упаси боже yaml код. То есть тут появляются так называемые Infrastructure engineer, Build engineer, Senior Yaml Developer :)
Все это позволяет с одной стороны найти человека, максимально подходящего под ваш пулл задач, а с другой создает недопонимание на собеседованиях
Основываясь на личном опыте, провел какой то количество десятков собеседований, а так же учавствовал в различных в качестве ответчика, хочу поделиться своим взглядом на все происходящее.
Первый и наверное самый мой любимый антипаттерн — желание кого-нибудь, чтобы он делал все, или непонятно кто нужен, посмотрим кучу кандидатов, там поймем. Наверное, это применимо к любой области, но тут есть свои особенности.
Как я обратил внимание, люди больше падки на вакансии со словами DevOps чем System Administrator, хотя на мой взгляд на уровне Senior область задач максимально отличается в этих двух областях.
Любой работодатель, которому на самом деле нужен сисадмин, пишет в заголовке вакансии девопс, перечисляя в теле запроса абсолютно все подряд, K8S/Java/gradle/oracleDB и тд по списку, хотя изнутри человеку предстоит заниматься поддержкой кластера K8S и поддержкой OracleDB стека в отрыве от команды.
Ну то есть и какое тут взаимодействие формата Developers / Operations?
Далее выясняется, что и как такого процесса взаимодействия с командой не предусмотрено и вообще, operations как отдела нет и вам предстоит и компы разработчиков настраивать.
Такой вариант на самом деле, подходит части соискателей, но давай те будем честны, это Senior System Administrator, так почему не хотят так писать и что вообще в этом постыдного? Отличие в зп между разными названиями профессий? Но бюджет у компании один, и как корабль не назови, поплывет он на свой бюджет.
Ну и еще даже слышал про такое, сейчас кандидат все быстро автоматизирует и вольется в разработку продукта на питоне, какая разница, везде питон один и тот же. Разница в мировозрении и подходах не учитывается.
Далее я обычно дифференцирую уровень специалистов, которые приходят и отдельно для каждого вижу свои неприятности
Junior — лично для меня Junior DevOps, это человек, который на среднем уровне освоил сисадминство / разработку. Тут приятно дифференцировать крепких линуксойдов, которые хотят расти в новой области, либо разработчиков, у которых есть желание делать хорошо для других разработчиков. Крепких, с какими то навыками дебага, поиска логов, либо с каким то запасом накодированных проектов.
Встречал как и сисадминов, которые попробовали чтото и хотят прикоснуться к облакам, так и тех, кто пробовал фронт, бэк и по каким то причинам нашел для себя интерес в процессах DevOps.
На данном уровне меня всегда смущает когда начинают валить по огромному стеку технологий, Puppet, Ansible — почему не пробовал все? K8S, K3S — чем отличается? Сколько видов баз данных знаешь? почему так мало? как шифрование в Java работает? Особенно тех, кто пришел из разработки, хотя это очень полезные кадры, для них всегда есть работа в данной области.
Меня всегда в гоняет в ступор, когда происходит такое, первое, что хочется спросить — зачем??? второе, что приходит на ум — а сам интервьюер готов ответить на вопросы по такому разнообразному стеку? Неужели они хотят взять джуна и повесить на него все?
Частенько, такое встречается в всяческих бодишопах, когда надо человека продать на какой то проект и нужно больше крутых слов для резюме ну или компания никого не хочет брать, а просто смотрит, какие бывают джуны.
Уровень Middle
тут несколько крайностей на мой взгляд, во-первых тяжело наверное определить именно четко, что человек тянет на мидла, его либо пытаются просадить до джуна, либо начинают гонять как синьора, пытаясь хапнуть синьора по цене мидла (ага, рынок то решает, ничего личного)
Самое удивительное, что я видел — уходить глубоко в коддинг, валить питончиком, мучать Java GC, то есть более уже глубоко специфичными темами, или наоборот, вскрывать пробелы в давно не используемых знаниях, гонять по сетям, типам драйверов ОС, ухмыляюсь и злорадствуя, как же человек мог это забыть. И тут происходит самое интересное!
К мидл уровню, на мой взгляд, у специалиста формируется круг интересов и личный взгляд на то, с чем он хочет работать — хайпануть на самом свежем стеке, пихая в кубик подмана, либо качаться для страшного энтерпрайза, уходя в глубь перфоманса кода.
На мой взгляд стоит уже тут распросить о процессах, по которым человек работал, распросить что было максимально интересно, а что нет, и уже на основе данных знаний строить кластер вопросов, неприменно замапливая вопросы на свой стэк. Иначе, проведя увлекательную беседу на час два о конфигурировании OpenShift кластера, нанять человека и посадить его строить мониторинг. Наверное это понравится обеим сторонам.
Уровень Senior
О, мой любимый уровень.
Перед вами крепкий спец, который взрастил себя на разного рода проектах, человек, который уже знает что хочет, а что ему не так сильно нравится.
И вот начинается шоу:
— глубокие вопросы по системному администрированию (см. первый антипаттерн)
— глубокие вопросы по линуксу в целом из области теории, далекой от практических знаний ( Уровни OSI топовый вопрос )
— академические вопросы по кодингу ( потому что сам интервьюер толком не знает область, его просто попросили пособеседовать странного девопса)
Сделаю тут ремарку небольшую. Как то раз, на собеседовании меня попросили написать какой то кусочек кода. На листочке. Ну как все любят, каждый день пишут, листочек наше все.
Справившись с задачей, после просмотра моего листочка и решения, был видвинут вердикт, что алгоритм будет неоптимальный. Я предложил, чтобы интервьер написал свой алгоритм, на что получил ответ «Это не входит в рамки собеседования». Я попросил минутку, переделал немного код и показал, спросив, так будет быстрее или медленее? На что получил ответ, перейдем к следующему вопросу. Разница была в работе кода в цикле и без цикла и у меня был заготовлен ответ почему лучше сделать так, а не так. Ну после этого мне уже не хотелось отвечать на вопросы и работать с данным человеком.
Надо учесть, что все мы разные и кандидата может отпугнуть любая вещь, которая для вас несущественна.
— обычно у спецов уровня Senior четко описан рабочий стек, так нет же, надо начинать гонять по близкому, к примеру, у вас написано Ansible, отлично а у нас Puppet, мы вас просто так позвали, ну ка расскажите про Puppet. Превосходно! Работали с OpenShift? У нас K8s, мы различий не знаем, но ваш опыт нерелеватный. Замечательно!
Есть еще такой подкласс — я лично себе беру стажеров на вырост в джунов.
Вот хочется, чтобы все понимали что стажер это сущность еще вообще не сформированная. Меня ужасно пугает, когда стажеров начинают гонять на уровень крепкий Junior и потом, с довольным видом предлогают стажировку (иногда неоплачиваемую, кошмар !)
Не надо так.
Стажер, на мой взгляд это либо студент старших курсов, либо вот кому-то очень хочется «уйти в айти».
Со студентами все просто — отлично узнать, чем занимается в университете, что делал сам, посмотреть на каких вопросах загорятся глаза — если загорятся, спросить почему именно в девопс и что вообще про это известно. Почувствовать человека и понять, будет ли приятно с ним дальше возиться, хочется ли научить чему то именно этого человека.
С теми, кто хочет «уйти в айти», чуть все построже — посмотреть насколько человек самообучается, что сделал перед тем, как попасть к вам на собеседование, тут уже хороший вариант будет посмотреть гитхаб, если имеется конечно, плотность коммитов и какие были упражнения сделаны. Распросить так же, почему все же девопс, ведь в фронтенде веселее и затейливее?
Ну и напоследок, хочется дать в очередной раз совет, определитесь, кто вам на самом деле нужен и вы сразу же найдете необходимого человека. Выявите потребности, посмотрите на специалиста как на специалиста, найдите его сильные стороны и успешно используйте их в вашей работе. Будьте внимательны к собеседуемому, он пришел к вам на беседу, а не на соревнование, кто кого завалит или не завалит.
Сегодня я хочу поделиться своими мыслями о давно наболевшей теме, и возможно, обсудить ее в комментариях.
Достаточно часто мне попадаются статьи по плохим практикам собеседования на должность программиста, которые на мой взгляд достаточно жизнены и, надеюсь, читаемы HR отделами компаний крупных и не очень.
В наших краях, насколько мне можно судить, есть востребованность таких интересных сущностей, как DevOps инженер. Я отношусь к тем людям, кто такое словосочетание не очень воспринимает ( да-да, DevOps методология, и тд ), поэтому вижу некоторое различие в путях развития у данной группы специалистов.
В первую очередь, я свято верю, что у каждого человека есть свой круг интересов, даже в рабочей области, то есть кому то по душе облака, кому то заниматься глубоким копанием в Application servers, настраивать глубоко Java, а кому то писать код на Python или упаси боже yaml код. То есть тут появляются так называемые Infrastructure engineer, Build engineer, Senior Yaml Developer :)
Все это позволяет с одной стороны найти человека, максимально подходящего под ваш пулл задач, а с другой создает недопонимание на собеседованиях
Основываясь на личном опыте, провел какой то количество десятков собеседований, а так же учавствовал в различных в качестве ответчика, хочу поделиться своим взглядом на все происходящее.
Первый и наверное самый мой любимый антипаттерн — желание кого-нибудь, чтобы он делал все, или непонятно кто нужен, посмотрим кучу кандидатов, там поймем. Наверное, это применимо к любой области, но тут есть свои особенности.
Как я обратил внимание, люди больше падки на вакансии со словами DevOps чем System Administrator, хотя на мой взгляд на уровне Senior область задач максимально отличается в этих двух областях.
Любой работодатель, которому на самом деле нужен сисадмин, пишет в заголовке вакансии девопс, перечисляя в теле запроса абсолютно все подряд, K8S/Java/gradle/oracleDB и тд по списку, хотя изнутри человеку предстоит заниматься поддержкой кластера K8S и поддержкой OracleDB стека в отрыве от команды.
Ну то есть и какое тут взаимодействие формата Developers / Operations?
Далее выясняется, что и как такого процесса взаимодействия с командой не предусмотрено и вообще, operations как отдела нет и вам предстоит и компы разработчиков настраивать.
Такой вариант на самом деле, подходит части соискателей, но давай те будем честны, это Senior System Administrator, так почему не хотят так писать и что вообще в этом постыдного? Отличие в зп между разными названиями профессий? Но бюджет у компании один, и как корабль не назови, поплывет он на свой бюджет.
Ну и еще даже слышал про такое, сейчас кандидат все быстро автоматизирует и вольется в разработку продукта на питоне, какая разница, везде питон один и тот же. Разница в мировозрении и подходах не учитывается.
Далее я обычно дифференцирую уровень специалистов, которые приходят и отдельно для каждого вижу свои неприятности
Junior — лично для меня Junior DevOps, это человек, который на среднем уровне освоил сисадминство / разработку. Тут приятно дифференцировать крепких линуксойдов, которые хотят расти в новой области, либо разработчиков, у которых есть желание делать хорошо для других разработчиков. Крепких, с какими то навыками дебага, поиска логов, либо с каким то запасом накодированных проектов.
Встречал как и сисадминов, которые попробовали чтото и хотят прикоснуться к облакам, так и тех, кто пробовал фронт, бэк и по каким то причинам нашел для себя интерес в процессах DevOps.
На данном уровне меня всегда смущает когда начинают валить по огромному стеку технологий, Puppet, Ansible — почему не пробовал все? K8S, K3S — чем отличается? Сколько видов баз данных знаешь? почему так мало? как шифрование в Java работает? Особенно тех, кто пришел из разработки, хотя это очень полезные кадры, для них всегда есть работа в данной области.
Меня всегда в гоняет в ступор, когда происходит такое, первое, что хочется спросить — зачем??? второе, что приходит на ум — а сам интервьюер готов ответить на вопросы по такому разнообразному стеку? Неужели они хотят взять джуна и повесить на него все?
Частенько, такое встречается в всяческих бодишопах, когда надо человека продать на какой то проект и нужно больше крутых слов для резюме ну или компания никого не хочет брать, а просто смотрит, какие бывают джуны.
Уровень Middle
тут несколько крайностей на мой взгляд, во-первых тяжело наверное определить именно четко, что человек тянет на мидла, его либо пытаются просадить до джуна, либо начинают гонять как синьора, пытаясь хапнуть синьора по цене мидла (ага, рынок то решает, ничего личного)
Самое удивительное, что я видел — уходить глубоко в коддинг, валить питончиком, мучать Java GC, то есть более уже глубоко специфичными темами, или наоборот, вскрывать пробелы в давно не используемых знаниях, гонять по сетям, типам драйверов ОС, ухмыляюсь и злорадствуя, как же человек мог это забыть. И тут происходит самое интересное!
К мидл уровню, на мой взгляд, у специалиста формируется круг интересов и личный взгляд на то, с чем он хочет работать — хайпануть на самом свежем стеке, пихая в кубик подмана, либо качаться для страшного энтерпрайза, уходя в глубь перфоманса кода.
На мой взгляд стоит уже тут распросить о процессах, по которым человек работал, распросить что было максимально интересно, а что нет, и уже на основе данных знаний строить кластер вопросов, неприменно замапливая вопросы на свой стэк. Иначе, проведя увлекательную беседу на час два о конфигурировании OpenShift кластера, нанять человека и посадить его строить мониторинг. Наверное это понравится обеим сторонам.
Уровень Senior
О, мой любимый уровень.
Перед вами крепкий спец, который взрастил себя на разного рода проектах, человек, который уже знает что хочет, а что ему не так сильно нравится.
И вот начинается шоу:
— глубокие вопросы по системному администрированию (см. первый антипаттерн)
— глубокие вопросы по линуксу в целом из области теории, далекой от практических знаний ( Уровни OSI топовый вопрос )
— академические вопросы по кодингу ( потому что сам интервьюер толком не знает область, его просто попросили пособеседовать странного девопса)
Сделаю тут ремарку небольшую. Как то раз, на собеседовании меня попросили написать какой то кусочек кода. На листочке. Ну как все любят, каждый день пишут, листочек наше все.
Справившись с задачей, после просмотра моего листочка и решения, был видвинут вердикт, что алгоритм будет неоптимальный. Я предложил, чтобы интервьер написал свой алгоритм, на что получил ответ «Это не входит в рамки собеседования». Я попросил минутку, переделал немного код и показал, спросив, так будет быстрее или медленее? На что получил ответ, перейдем к следующему вопросу. Разница была в работе кода в цикле и без цикла и у меня был заготовлен ответ почему лучше сделать так, а не так. Ну после этого мне уже не хотелось отвечать на вопросы и работать с данным человеком.
Надо учесть, что все мы разные и кандидата может отпугнуть любая вещь, которая для вас несущественна.
— обычно у спецов уровня Senior четко описан рабочий стек, так нет же, надо начинать гонять по близкому, к примеру, у вас написано Ansible, отлично а у нас Puppet, мы вас просто так позвали, ну ка расскажите про Puppet. Превосходно! Работали с OpenShift? У нас K8s, мы различий не знаем, но ваш опыт нерелеватный. Замечательно!
Есть еще такой подкласс — я лично себе беру стажеров на вырост в джунов.
Вот хочется, чтобы все понимали что стажер это сущность еще вообще не сформированная. Меня ужасно пугает, когда стажеров начинают гонять на уровень крепкий Junior и потом, с довольным видом предлогают стажировку (иногда неоплачиваемую, кошмар !)
Не надо так.
Стажер, на мой взгляд это либо студент старших курсов, либо вот кому-то очень хочется «уйти в айти».
Со студентами все просто — отлично узнать, чем занимается в университете, что делал сам, посмотреть на каких вопросах загорятся глаза — если загорятся, спросить почему именно в девопс и что вообще про это известно. Почувствовать человека и понять, будет ли приятно с ним дальше возиться, хочется ли научить чему то именно этого человека.
С теми, кто хочет «уйти в айти», чуть все построже — посмотреть насколько человек самообучается, что сделал перед тем, как попасть к вам на собеседование, тут уже хороший вариант будет посмотреть гитхаб, если имеется конечно, плотность коммитов и какие были упражнения сделаны. Распросить так же, почему все же девопс, ведь в фронтенде веселее и затейливее?
Ну и напоследок, хочется дать в очередной раз совет, определитесь, кто вам на самом деле нужен и вы сразу же найдете необходимого человека. Выявите потребности, посмотрите на специалиста как на специалиста, найдите его сильные стороны и успешно используйте их в вашей работе. Будьте внимательны к собеседуемому, он пришел к вам на беседу, а не на соревнование, кто кого завалит или не завалит.
ctacka
В последнее время собеседую много devops-ов. Кажется, антипаттерны не использую, по крайней мере хочется надеяться. Но вот несколько замечаний:
SicYar Автор
Согласен, не все так просто :)
на первое я бы сказал стоит как то внимательнее слушать, что говорит, возможно распросить по какому то кейсу, таких встречал соискателей, обычно они валятся на распросе подробном как что сделать, но да, тут все неоднозначно
на второе и соглашусь и нет, иногда, на мой взгляд бывает потребность в технаре, который вот может решить сложные проблемы, готов много дизайнить и экспериментировать, но например, с взаимодействием у него сложно, для такого человека всегда можно найти и место и ему задачи подобрать. Так же есть мнение, что такой человек может со временем например вырости в хорошего ТехЛида, архитектора и это будет всем плюс, либо научиться взаимодействовать.
menstenebris
Ну и возможно потеряете отличного специалиста. Большая часть разрабов не могут писать код на собеседованиях потому что привыкли писать код в удобной и спокойной обстановке. Есть отличное правило, что контролируете то и получаете. Если кандидат хорошо пишет код на листочке значит это он умеет делать хорошо а остальное не факт. Если хорошо решает абстрактные задачки, то же самое.
P.S. Я действительно видел человека хорошо воспринявшего эту парадигму. Он отлично решал абстрактные задачи и выучил О нотацию по википедии. Но при этом пишущего очень запутанный и медленный код, но это на собеседованиях никто не проверял в результате ему очень быстро удалось занять высокооплачиваемое неотствечивающее место в крупной компании.
ctacka
Я не прошу писать на листочке. Я задаю вопросы по структурам данных и прошу решить одну из задачек на одном онлайн сервисов. При этом даже если человек не решает эту задачу (что конечно плохо), уровень можно оценить.
W001fer
Вечная проблема — адекватная оценка компетенции. Были на собеседованиях ребята с сертификатами от Cisco, MS, Oracle и многие другие, которые сыпались на простейших вопросах, но при этом в резюме писали, что имеют экспертные знания и решают какие-то нереальные задачи :) Другая сторона — человек на собеседовании показывает крутые знания теории, но когда доходит до реального применения этой теории — пшик и все, сидит и ничего не может сделать без подсказки. Тупо зазубрил теорию :)
mad_nazgul
Чтобы оценить уровень соискателя собеседующий должен быть выше уровнем.
Обычно адекватно оценить соискателя просто — «поговорить за жизнь».
Т.е. о работе что делал, с какими проблемами сталкивался, как решали.
Вот тут «теоретиков» видно сразу, т.к. они вряд ли смогут предъявить практические навыки.
ctacka
Есть большие специалисты — "поговорить за жизнь". И расскажут, как делали, и почему там говно, а там мёд. Особенно когда ваш стек отличается от его, и вы не знаете, как оно у них там точно.
И ещё, когда у вас есть несколько кандидатов, как вы выберете? На личных ощущениях? А вы вдвоем собеседовали, и ощущения разные.
Так что я за измеримый подход: вот есть вопросы из необходимых областей знания, простые и сложные. Не ответил — прости, чувак, нам с тобой не по пути. Ответил на простые — молодец, ответил на сложные — вот теперь давай о жизни поговорим.
mad_nazgul
Во время разговора «за жизнь» эти вопросы можно задать, никто не мешает.
Но только в контексте реального использования.
А так зазаубрить теорию это не проблема.
ctacka
Я как подумаю о мотивации человека, который зазубрил теорию в тех областях, по которым я задаю вопросы, так мне сразу хочется его нанять!
amarao
Ага, только что такого собеседовал. В начале я прям плюсики на бумажку ставил — и это хорошо, и это отлично. Потом его попросили описать как бы он внедрил CI/CD для группы программистов, у которых используется git и ftp на папочку на сервер для деплоя. Zero restrictions. Начал бодро, но уж очень поверхностно. Потом после пары уточняющих вопросов выяснилось, что слова знает, а что слова означает — нет.
А потом я его попросил сказать, как посмотреть какой интерфейс на сервере используется для отправки трафика в интернет… И мне сказали, что traceroute'ом. Ну, в вопросе же было "через какой интерфейс маршрутизируется трафик в интернет" — значит маршрут, а что нам показывает маршрут? traceroute. Логично? Логично!
devops, блин.
CrzyDocTI
Ахах. А можно мне к вам? Я знаю что такое icmp!) Правда на вопрос ответил бы что надо подумать(ну, не решал такого — сисадмин я) и вероятно предложил бы изменить способ деплоя.
CrzyDocTI
не возьмут. там traceroute а это UDP по умолчанию=(
amarao
Можете попробовать (я без шуток).
https://hh.ru/vacancy/36113395
CrzyDocTI
Спасибо. К сожалению не подхожу по навыкам. Как сетевик работал 2 года, домен win, потом ушел на администрирование Z/os и немного centos — отвечаю буквально за все(кроме DB2 и WS. спасите, меня не выпускают из подвала). А у вас релокация и, думаю, никто не будет тащить джуна=)
Но было интересно посмотреть список требований — на удивление кажется адекватным(с некоторыми уточнениями)
amarao
Нам на самом деле нужен просто толковый админ с зачатками программирования и более-менее хорошей производственной культурой (тесты, воспроизводимость результата и т.д.).
VolCh
А почему это просто в вакансии не написать? :)
amarao
Так оно и написано.
ctacka
Ну вот если про CI/CD я бы с вами бы поговорил с удовольствием, то вопрос про сеть меня бы очень смутил. Я бы често ответил, что нагуглил бы это за 2 минуты, но так не знаю — не приходилось как-то, или просто не запомнил.
При этом не считаю себя плохим devops-ом, если честно.
amarao
В вакансии сеть указана как отдельное требование (см в комментах ссылку на вакансию). Алсо, я не понимаю, как может быть хорошее понимание работы современных систем оркестрации (от k8s до системного пакетирования) без уверенного знания хост-системы. Т.е. человек гит/гитлаб умеет, файлик в kubectl засунуть умеет, а когда оно чуть-чуть начнёт по сети прогибаться, то всё? Контрек? Какой контрек? Посмотри что там с unknown unicast в сети? Ой, нам это не рассказывали...