Технические вопросы по списку на hr- этапе это нормально, для отсева совсем уж и неподходящих кандидатов. После этого назначается (или не назначается) техническое собеседование
"Принцип единственной ответственности (SRP) - это принцип, сформулированный Робертом Мартином (Uncle Bob), который утверждает, что каждый объект должен иметь одну и только одну причину для изменения, то есть каждый объект должен быть ответственен за выполнение только одной задачи или иметь только одну обязанность." - вот вы тоже вводите людей в заблуждение. Мартин подчёркивает, что дело не в обязанности, а ответственности перед кем-то. Строго говоря, у каждого работника только один начальник. У сотрудника может быть несколько зон ответственности и обязанностей, но причиной меняться может быть только один (человек, класс, сервис).
Я разрабатываю часть системы для большого бизнеса, и скажу вам, не все так однозначно
Мы работаем с k8s и тут всегда встает вопрос гарантированные ресурсы vc утилизация ресурсов. И очень большим % цпу и озу приходится жертвовать ради надежности.
Long story short: приходится задавать реквесты и лимиты, и они должны быть равны. А это значит, что я могу выделить 1 цпу на сервис или 0.5 или 2, но этот ресурс будет использоваться только этим сервисом, или не использоваться вообще. Честно говоря, меня это убивает, но ничего не поделаешь. И единственный ответ на эту ситуацию - масштабировать горизонтально. Но при этом все равно 10-50% ресурсов оказываются неутилизированными
все красиво, когда есть специалист, который умеет правильно готовить. У нас вот в компании год цирк с конями (девопсами), не могут нормального найти. Наболело, прастити
Нет, не один и тот же) Каждому человеку достаточно один раз дать линейкой по рукам. Но на проекте у меня 8 бекеров, и если каждый сделает каждую ошибку... привет декартово произведение
Про лекции думал, но алгоритмическое мышление лекциями не достигается, думаю. Пока пришли к перекрестному кодревью перед моим кодревью, помогает большую часть вопросов снимать
Стоит добавить, что здесь речь не просто о столбцах в БД, а о именах полей (свойств) доменной модели. Поэтому, как они называются - вопрос действительно важный.
Очень здорово, что вы проанализировали стандарты. Опираясь на них, можно действительно пересмотреть подход к наименованию этих свойств.
Но из вашего же анализа я вижу, что единого мнения на этот счёт нет, а значит "здесь так принято" всё ещё имеет власть
У нас сейчас есть такой персонаж. Зп требует маленькую, соотношение цена/качество руководство радует, но работать с ним никто не хочет. Буквально сейчас увольняется человек, нанятый на такую же с ним позицию неделю назад, ибо этот персонаж просто устраивал конфликты на ровном месте
Ваше решение - это ответ на конкретный кейс, когда соискатель накидал шпаргалок. Т. Е. вы предлагаете целое собеседование дополнительное ради решения только одной конкретной проблемы. В разработке это называется костыль)
Я пришёл к мысли от необходимости алгоритмического собеседования, когда раз за разом в команде сталкивался с тем, что люди не думают об алгоритмической сложности своего кода. Например, человек (очень неглупый) берёт массив пользователей из (10к) и для каждой записи делает отдельный запрос к БД. И таких проходов по массиву пользователей - N в секунду. БД ложилась под нагрузкой, хотя тяжёлых запросов не было. И таких кейсов много.
Если бы я проводил алгоритмические собеседования, не нанял бы человека (см выше). А этот человек реально тащит.
Сделал для себя вывод: алгоритмические собеседования это хорошо, если можешь себе это позволить. Я вот не могу
За сам факт статьи спасибо, ибо вопрос найма девопс актуальный, и наличие дискуссии - уже прекрасно.
По существу статьи:
Много сказано про найм в ит. Зачем? Про это сломано так много копий, что еще одно ничего не изменит. Много в статье и верно сказано и спорных моментов
Было бы здорово сделать акцент на найме именно девопса, в чем специфика, отличия от найма программиста, админа, менеджера, аналитика, которых (я надеюсь) мы уже умеем нанимать?
У нас было два железных криптосервиса с библиотекой на .net 2.0, сто семьдесят семь микросервисов на .net 3.5 на поддержке (сервисы хорошие, оплачивать их рефакторинг, мы, конечно, не будем), три сервиса на java, разработчики которых уже не с нами, пять версий одного микросервиса с разной степенью реализованности интеграций (партнер по интеграции до сих пор не предоставил тест, а сдавать прод через две недели), и целое море микросервисов, которые можно запустить только на проде, поскольку цепочки интеграции превышают все мыслимые человеческому мозгу размерности. Не то, чтобы всё это было категорически необходимо для успешной работы бизнес-процессов, но если ты мастодонт масштабов страны, то все описанное выше - лишь малая часть твоей инфраструктуры
Возможность писать на разных языках - это только одна из множества возможностей. Банально у меня в одном мс устаревший стек и нет возможности поднять версию фреймворка, а в другом нужна новая фича, которая вот только вышла в бета-тестирование в новом фреймворке, и ещё не известно, насколько хорошо она будет работать под нагрузкой. В монолите это стало бы неразрешимой проблемой
Соглашусь, надо соизмерять подходы с потребностями. Как говорил наш препод по морской практике, лучший узел - тот, который ты знаешь.
Однако чем больше ты вкладываешься в технологии, тем меньше у тебя проблем роста. А проблемы роста, они, собаки такие, мешают, как это ни удивительно, росту. А это, зачастую, наша приоритетная задача - чтобы проект развивался.
Так что можно оставаться малышом на монолите, а можно стремиться применять современные подходы там, где это можно себе позволить, рассчитывая на дивиденды в будущем в виде меньших издержек развития проекта
Для домашнего проекта я бы писал монолит просто потому, что у меня нет ни желания, ни возможности тратить время на всю суету вокруг микросервисов. Но на рабочем проекте я монолит бы даже не стал рассматривать
У нас на девопс открыто четыре вакансии, нашли одного джуна. Ох, как же он меня утомил: капризный, это не хочу, то не буду, а вот это мне интересно, это я буду, и вообще, что вы мне тут качество жизни своими задачами понижаете и докажите, что это моя задача. Девопсы нонче - айтишники среди айтишников. Кажется, я начал догадываться, почему нас недолюбливают
Технические вопросы по списку на hr- этапе это нормально, для отсева совсем уж и неподходящих кандидатов. После этого назначается (или не назначается) техническое собеседование
А в чем прикол? Вручную контролить?
"Принцип единственной ответственности (SRP) - это принцип, сформулированный Робертом Мартином (Uncle Bob), который утверждает, что каждый объект должен иметь одну и только одну причину для изменения, то есть каждый объект должен быть ответственен за выполнение только одной задачи или иметь только одну обязанность." - вот вы тоже вводите людей в заблуждение. Мартин подчёркивает, что дело не в обязанности, а ответственности перед кем-то. Строго говоря, у каждого работника только один начальник. У сотрудника может быть несколько зон ответственности и обязанностей, но причиной меняться может быть только один (человек, класс, сервис).
про докер согласен, про баш уже нет) Но знаний одного докера ой как недостаточно для решения большинства вопросов
Я разрабатываю часть системы для большого бизнеса, и скажу вам, не все так однозначно
Мы работаем с k8s и тут всегда встает вопрос гарантированные ресурсы vc утилизация ресурсов. И очень большим % цпу и озу приходится жертвовать ради надежности.
Long story short: приходится задавать реквесты и лимиты, и они должны быть равны. А это значит, что я могу выделить 1 цпу на сервис или 0.5 или 2, но этот ресурс будет использоваться только этим сервисом, или не использоваться вообще. Честно говоря, меня это убивает, но ничего не поделаешь. И единственный ответ на эту ситуацию - масштабировать горизонтально. Но при этом все равно 10-50% ресурсов оказываются неутилизированными
все красиво, когда есть специалист, который умеет правильно готовить. У нас вот в компании год цирк с конями (девопсами), не могут нормального найти. Наболело, прастити
Интересно, в k8s тоже наверное pivot_root использует?
Любой разработчик запустит на другой ос и столкнётся с деталями реализации на это ос. Если проект не hello world конечно
В эпоху монолитов всё эти компоузы были не нужны как-то
Через 10 лет у вас будет другая ОС (см п1)
Нет, не один и тот же) Каждому человеку достаточно один раз дать линейкой по рукам. Но на проекте у меня 8 бекеров, и если каждый сделает каждую ошибку... привет декартово произведение
Про лекции думал, но алгоритмическое мышление лекциями не достигается, думаю. Пока пришли к перекрестному кодревью перед моим кодревью, помогает большую часть вопросов снимать
Стоит добавить, что здесь речь не просто о столбцах в БД, а о именах полей (свойств) доменной модели. Поэтому, как они называются - вопрос действительно важный.
Очень здорово, что вы проанализировали стандарты. Опираясь на них, можно действительно пересмотреть подход к наименованию этих свойств.
Но из вашего же анализа я вижу, что единого мнения на этот счёт нет, а значит "здесь так принято" всё ещё имеет власть
У нас сейчас есть такой персонаж. Зп требует маленькую, соотношение цена/качество руководство радует, но работать с ним никто не хочет. Буквально сейчас увольняется человек, нанятый на такую же с ним позицию неделю назад, ибо этот персонаж просто устраивал конфликты на ровном месте
Думаю, те, кого что-то достало, не станут отправлять в топку, а выразят в опросе своё недовольство
перформит, решает наиболее сложные задачи, помогает другим
Спасибо за статью, попробую покритиковать)
Ваше решение - это ответ на конкретный кейс, когда соискатель накидал шпаргалок. Т. Е. вы предлагаете целое собеседование дополнительное ради решения только одной конкретной проблемы. В разработке это называется костыль)
Я пришёл к мысли от необходимости алгоритмического собеседования, когда раз за разом в команде сталкивался с тем, что люди не думают об алгоритмической сложности своего кода. Например, человек (очень неглупый) берёт массив пользователей из (10к) и для каждой записи делает отдельный запрос к БД. И таких проходов по массиву пользователей - N в секунду. БД ложилась под нагрузкой, хотя тяжёлых запросов не было. И таких кейсов много.
Если бы я проводил алгоритмические собеседования, не нанял бы человека (см выше). А этот человек реально тащит.
Сделал для себя вывод: алгоритмические собеседования это хорошо, если можешь себе это позволить. Я вот не могу
За сам факт статьи спасибо, ибо вопрос найма девопс актуальный, и наличие дискуссии - уже прекрасно.
По существу статьи:
Много сказано про найм в ит. Зачем? Про это сломано так много копий, что еще одно ничего не изменит. Много в статье и верно сказано и спорных моментов
Было бы здорово сделать акцент на найме именно девопса, в чем специфика, отличия от найма программиста, админа, менеджера, аналитика, которых (я надеюсь) мы уже умеем нанимать?
Гуглить по слову "оркестрация")
У нас было два железных криптосервиса с библиотекой на .net 2.0, сто семьдесят семь микросервисов на .net 3.5 на поддержке (сервисы хорошие, оплачивать их рефакторинг, мы, конечно, не будем), три сервиса на java, разработчики которых уже не с нами, пять версий одного микросервиса с разной степенью реализованности интеграций (партнер по интеграции до сих пор не предоставил тест, а сдавать прод через две недели), и целое море микросервисов, которые можно запустить только на проде, поскольку цепочки интеграции превышают все мыслимые человеческому мозгу размерности. Не то, чтобы всё это было категорически необходимо для успешной работы бизнес-процессов, но если ты мастодонт масштабов страны, то все описанное выше - лишь малая часть твоей инфраструктуры
Возможность писать на разных языках - это только одна из множества возможностей. Банально у меня в одном мс устаревший стек и нет возможности поднять версию фреймворка, а в другом нужна новая фича, которая вот только вышла в бета-тестирование в новом фреймворке, и ещё не известно, насколько хорошо она будет работать под нагрузкой. В монолите это стало бы неразрешимой проблемой
Соглашусь, надо соизмерять подходы с потребностями. Как говорил наш препод по морской практике, лучший узел - тот, который ты знаешь.
Однако чем больше ты вкладываешься в технологии, тем меньше у тебя проблем роста. А проблемы роста, они, собаки такие, мешают, как это ни удивительно, росту. А это, зачастую, наша приоритетная задача - чтобы проект развивался.
Так что можно оставаться малышом на монолите, а можно стремиться применять современные подходы там, где это можно себе позволить, рассчитывая на дивиденды в будущем в виде меньших издержек развития проекта
Для домашнего проекта я бы писал монолит просто потому, что у меня нет ни желания, ни возможности тратить время на всю суету вокруг микросервисов. Но на рабочем проекте я монолит бы даже не стал рассматривать
З. Ы. И, простите, ться
У нас на девопс открыто четыре вакансии, нашли одного джуна. Ох, как же он меня утомил: капризный, это не хочу, то не буду, а вот это мне интересно, это я буду, и вообще, что вы мне тут качество жизни своими задачами понижаете и докажите, что это моя задача. Девопсы нонче - айтишники среди айтишников. Кажется, я начал догадываться, почему нас недолюбливают