Pull to refresh
1
0
Send message

Я ориентирусь на то, что у человека о опыте в резюме написано.
А потом когда провожу собеседования на позицию инженера.
Задаю вопросы про Patroni, ESXi и т.д. А в пответ получаю: "Ничего не знаю, написал что знаю стек, т.к. в большинстве резюме видел". Т.е. люди даже не знаю, что они пишут.
Очень много неадекватных соискателей и в ТП на 2ю линию, и в DevOps. Запросы нереальные, знания/опыт никакие или плохие.

Единственный дельный совет из всей статьи - проходите собесы, записывайте вопросы, на которые затрудняетесь ответить, изучайте. Подготовка к тех.интервью бывает тоже важна.
Вопросы по теории на позицию DevOps/SRE и даже Ops инженеров пересекаются.

Я Сам недавно искал работу, конец июля.
Сам я собеседования почти не проходил, и обычно проходил через тестовое задание. Да и за более 10 лет опыта в ИТ работодателей у меня было всего 4.
Поэтому практики дофига, а по теории были пробелы.
Откликнулся на 4 вакансии.
Из 4х первых тех интервью. 3 были неудачные.
Я выписал вопросы, подтянул теорию, и был готов отвечать на 90% вопросов по теории.
Далее Открыл резюме и общался с приходящими компаниями. За 2 с половиной недели было 25 тех интервью (можно было бы продолжить, но я устал и решил что надо закругляться) и только на 2х я был действительно очень плох.
Тензор - У этих своя атмосфера. И ещё одно, где очень плотно и глубоко спрашивали про Еластик и PHP. Elastic в целом я не готовил, но знаю его хорошо, могу рассказать о том как организовал бы кластер, о том как оптимизиировать индексы. Но спрашивали ещё глубже, а PHP я просто не люблю.

Если говорить именно о самых популярных вопросах, то такие действительно есть, отмечу 3:

1. Открываем сайт в браузере(CURL), что происходит под капотом?

  1. Лоад Еверейдж

  2. Рассказать о шапке top

Ещё Бывают вопросы прям DevOps. Например что такое DevOps, что такое SRE. Или Например о идельном пайплайне и вариации на эту тему. Тут либо ты общаешься с новичком в вопросе (кто не сожрал кучу говна), разработчиком или очень принципиальным человеком. Вообще я не очень люблю этот вопрос по понятным причинам, но само развитие диалога на эту тему может сложить картину о человеке с которым ты общаешься, а так же для твоего собеседника картину о тебе. Но у меня зависило от настроения, когда я получал такой вопрос, чаще я отвечал, что не готов сейчас обсуждать эту тему по понятным причинам. Наверное такой вопрос я получал раз 5, пообщался только один раз, когда было интересно.

Если на тех интервью присутствуют разработчики, то вопросы бывают очень глупые (Например, Чем принципиально отличается под от контейнера?) или максимум (как разрешить конфликт при МР). Вообще про конфликт МР у меня 1 раз и инженер спрашивал и это было очень душно, т.к. он подразумевал, что есть единственно верный ответ.
Так же могут быть вопросы о базах данных, конечно же сетях, организации памяти, сигналах.

Архитектурные вопросы, например о том как сделать HA систему, или о архитектуре современных приложений.

Примерно на 6 интервью я писал код, решал простенькую задачку. На одном было такое, что час пол часа теория, пол часа программирование. По теории мы классно пообщались, но ушло 40 минут, думали задержаться на 10 минут на решение задачки, но я программку реализовал за 15 минут и мы закончили на 5 минут раньше.
Конечно, вас могут спрашивать о опыте, спрашивать о интрументах из вашего резюме, о том что вы делали на предыдущем месте работы и какую роль исполняли. Поэтому я бы наоборот не рекомендовал бы врать в резюме. да, прокатить может, но я сам ловил таких умелцев, которые в резюме писали все подряд, даже не представляя о том, о чем они написали.

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

Бывает, что вам надо прочитать чужой код. Хорошо если он полный или есть хотя бы контекст. В одном тех.интервью мне выдрали кусок Gitlab-ci без какого-либо контекста, со ссылками хз куда (extend) при этом такой жобы не было и блока include не было. В такой ситуации можно было только гадать и предполагать что вообще происходит.

Как Итог.
1. Большее количество тех-интервью делает вас более натаскаными. Если вы просто ищете работу, без цели устроиться в Яндекс, Тинькофф, Касперский или Joom, то пойти на собеседование к ним - это лучший способ себя натренеровать и сделать уверенее. У Яндекса, Тинькофф бездушная машина найма проверяющая по шаблону твои знания. И Joom и Каспера не такая отлаженая, но вопросы там схожие + проверяются более глубокие, которые тоже в последствии у себя в голове уложить можно. Так же у всех этих компаний есть секция с кодингом при найме, тоже вас поднатаскает.

2. В каких-то более личностных моментах (когда тебя собеседует человек к себе в команду) Адекватный интервьюер сразу поймет насколько ты ему подходишь, поэтому глубокие знания в таком случае не важны, их даже могут не проверять. Главное сойтись. Это работает и в противоположную стону. Болшую часть собеседований я не довел до оффера или так называемого финального интервью, потому что понял, что не мое.

3 Не всегда конечно важно, но все же хорошо, если вы умеете быстро решить путем реализации кода какую-то простенькую задачу, а так же умете читать чужой код (Python, Go, Bash, Dockerfile, Ansible или gitlab-ci). Странно но за 25 тех интервью прочитать что-то на Terraform не довелось.

Задача 1
Если нам важна скорость определения и экономия затрат энергии на передвижение в поезде, то можно решить так:
1. В первом вагоне включаем свет.
2. Начинаем движение в любую сторону.
3. Встретив вагон с включенным светом — выключаем свет, запоминаем число пройденных вагонов от начального и продолжаем движение строго в ту же сторону.
4. Если мы прошли такое же расстояние не выключая свет, как от начального вагона до последнего выключенного, то вероятность того, что мы ошиблись 1 / (2 ^ m) * 100%, где m — количество от начального до последнего вагона в котором мы выключили свет.
Далее есть 2 варианта развития событий. Если критична скорость, то можно заложить определенную вероятность и продолжить движение, если наше значение из 4 пункта выше этой положенной вероятности.
Если скорость определения не так критична, как точность, то:
5. Возвращаемся в начальный вагон и проверяем его, если свет выключен, то мы знаем число вагонов — m, если остался включен, то начинаем в движение в противоположную сторону
6. Гасим свет во всех вагонах по пути, отсчитывая 2m вагонов.
7. После 2m вагона повторяем пункт 3.

Information

Rating
Does not participate
Registered
Activity