Нет, не один и тот же) Каждому человеку достаточно один раз дать линейкой по рукам. Но на проекте у меня 8 бекеров, и если каждый сделает каждую ошибку... привет декартово произведение
Про лекции думал, но алгоритмическое мышление лекциями не достигается, думаю. Пока пришли к перекрестному кодревью перед моим кодревью, помогает большую часть вопросов снимать
Стоит добавить, что здесь речь не просто о столбцах в БД, а о именах полей (свойств) доменной модели. Поэтому, как они называются - вопрос действительно важный.
Очень здорово, что вы проанализировали стандарты. Опираясь на них, можно действительно пересмотреть подход к наименованию этих свойств.
Но из вашего же анализа я вижу, что единого мнения на этот счёт нет, а значит "здесь так принято" всё ещё имеет власть
У нас сейчас есть такой персонаж. Зп требует маленькую, соотношение цена/качество руководство радует, но работать с ним никто не хочет. Буквально сейчас увольняется человек, нанятый на такую же с ним позицию неделю назад, ибо этот персонаж просто устраивал конфликты на ровном месте
Ваше решение - это ответ на конкретный кейс, когда соискатель накидал шпаргалок. Т. Е. вы предлагаете целое собеседование дополнительное ради решения только одной конкретной проблемы. В разработке это называется костыль)
Я пришёл к мысли от необходимости алгоритмического собеседования, когда раз за разом в команде сталкивался с тем, что люди не думают об алгоритмической сложности своего кода. Например, человек (очень неглупый) берёт массив пользователей из (10к) и для каждой записи делает отдельный запрос к БД. И таких проходов по массиву пользователей - N в секунду. БД ложилась под нагрузкой, хотя тяжёлых запросов не было. И таких кейсов много.
Если бы я проводил алгоритмические собеседования, не нанял бы человека (см выше). А этот человек реально тащит.
Сделал для себя вывод: алгоритмические собеседования это хорошо, если можешь себе это позволить. Я вот не могу
За сам факт статьи спасибо, ибо вопрос найма девопс актуальный, и наличие дискуссии - уже прекрасно.
По существу статьи:
Много сказано про найм в ит. Зачем? Про это сломано так много копий, что еще одно ничего не изменит. Много в статье и верно сказано и спорных моментов
Было бы здорово сделать акцент на найме именно девопса, в чем специфика, отличия от найма программиста, админа, менеджера, аналитика, которых (я надеюсь) мы уже умеем нанимать?
У нас было два железных криптосервиса с библиотекой на .net 2.0, сто семьдесят семь микросервисов на .net 3.5 на поддержке (сервисы хорошие, оплачивать их рефакторинг, мы, конечно, не будем), три сервиса на java, разработчики которых уже не с нами, пять версий одного микросервиса с разной степенью реализованности интеграций (партнер по интеграции до сих пор не предоставил тест, а сдавать прод через две недели), и целое море микросервисов, которые можно запустить только на проде, поскольку цепочки интеграции превышают все мыслимые человеческому мозгу размерности. Не то, чтобы всё это было категорически необходимо для успешной работы бизнес-процессов, но если ты мастодонт масштабов страны, то все описанное выше - лишь малая часть твоей инфраструктуры
Возможность писать на разных языках - это только одна из множества возможностей. Банально у меня в одном мс устаревший стек и нет возможности поднять версию фреймворка, а в другом нужна новая фича, которая вот только вышла в бета-тестирование в новом фреймворке, и ещё не известно, насколько хорошо она будет работать под нагрузкой. В монолите это стало бы неразрешимой проблемой
Соглашусь, надо соизмерять подходы с потребностями. Как говорил наш препод по морской практике, лучший узел - тот, который ты знаешь.
Однако чем больше ты вкладываешься в технологии, тем меньше у тебя проблем роста. А проблемы роста, они, собаки такие, мешают, как это ни удивительно, росту. А это, зачастую, наша приоритетная задача - чтобы проект развивался.
Так что можно оставаться малышом на монолите, а можно стремиться применять современные подходы там, где это можно себе позволить, рассчитывая на дивиденды в будущем в виде меньших издержек развития проекта
Для домашнего проекта я бы писал монолит просто потому, что у меня нет ни желания, ни возможности тратить время на всю суету вокруг микросервисов. Но на рабочем проекте я монолит бы даже не стал рассматривать
У нас на девопс открыто четыре вакансии, нашли одного джуна. Ох, как же он меня утомил: капризный, это не хочу, то не буду, а вот это мне интересно, это я буду, и вообще, что вы мне тут качество жизни своими задачами понижаете и докажите, что это моя задача. Девопсы нонче - айтишники среди айтишников. Кажется, я начал догадываться, почему нас недолюбливают
С началом войны многие адекватные люди убыли и из страны и из Яндекса. Закономерно, что уровень всего упал. Моё имхо по существу
Тестовые задания сомнительная вещь сама по себе, прежде всего как раз из за таких ситуаций: соискатель тратит неадекватное количество своего времени без каких-либо гарантий на профит.
Такие ситуации с тестовыми заданиями скорее правило, чем исключение. Делая тестовое задание, будьте готовы даже не получить ответа.
Подобное поведение со стороны компании - свинство (звучит единодушное осуждение)
Вывод о цели тестовых заданий в виде сбора данных для обучения нейросети выглядит совой на глобусе
Обижаться на всю компанию и призывать бойкотировать - звучит наивно. Но выводы о неизбежности второго закона термодинамики сделать можно
"Гендиректор корпорации Boeing, выступая перед акционерами, признал вину в части, касающейся недалекости инженеров при проектировании самолета " - вот от этого у меня, как инженера, подгорает. Как раз таки инженеры во всю трубили о недопустимости выпуска самолета в такой конфигурации, но их... заткнули. А самых громких тупо уволили (если правильно помню).
Мне сложно судить о том, что в такой ситуации мог сделать пилот. Думаю, все сильно зависит от пилота, его опыта, состояния, подготовленности. Кстати, о подготовленности: подобные ситуации должны, но не были отработаны на тренажерах. Вспомнить в критической ситуации правильные действия... ну, это надо быть особого склада человеком, и сейчас, думаю, все меньше пилотов являются такими людьми. По своему опыту если судить - в критической ситуации ты вспоминаешь только то, что хорошенько отработал на тренировках, что записалось в рефлексы, в мозжечок.
Пилоты разбившихся самолетов по тем или иным причинам не были готовы к такого рода ситуациям. А ситуацию создало руководство Боинга, игнорируя все возможные правила безопасности ради сиюминутной выгоды.
Суть истории, что очередной гений управления довел яхтосторительную компанию с мировой историей и репутацией до банкротства, начав клепать яхты, забив на безопасность.
В истории катастрофы Боинг много составляющих, как и у большинства катастроф. Но основной причиной является управление компанией, поставившее деньги выше человеческих жизней
Спасибо за ресеч. Да, про эту опцию я и имел в виду: инженеры в один голос утверждали, что эта опция должна быть обязательной, но их заткнули. Так же проблему усугубило то, что про наличие/отсутствие опции пилоты не знали/не задумывались, проблемы с датчиками и работой системы стабилизации на тренажёрах не отрабатывались, инструкций что делать в такой ситуации не было. По факту при отсутствии этой опции самолёт отправлялся автоматикой в пике/сваливание, а экипаж вообще не понимал что происходит.
Т. Е. Ещё раз
1) О проблеме знали
2) проблему игнорировали
3) даже после первых катастроф проблему не признавали и замалчивали
4) проблема была создана искусственно на пустом месте ради небольшого дополнительного дохода
все эти проблемы (и катастрофы с MCAS, и оторвавшаяся дверь) - от Эффективных Менеджеров (ТМ).
В первом случае Эффективные Менеджеры (ТМ) решили сделать датчики системы опциональными за дополнительные деньги, оставив только один обязательный, проигнорировав инженеров и забив на безопасность. Деньги же не пахнут, верно?
Во втором случае отдали работы на аутсорс в компанию, где еще более Эффективные Менеджеры (ТМ) решили вообще забить болт (горький сарказм) на безопасность.
В обоих случаях еще одни - государственные - Эффективные Менеджеры (ТМ) отдали проверку безопасности на откуп Боинга. Это все равно, что принимать экзамен по вождению у вас будет человек, которому вы платите за обучение. Казалось бы, что могло пойти не так?
И, наконец, еще одни - европейские государственные - Эффективные Менеджеры (ТМ) отдали проверку безопасности на откуп американским Эффективным Менеджерам (ТМ) (см. пункт выше). Казалось бы?
И весь этот порнхаб творился и копился годами, пока не стали падать самолеты в Европе. Ведь этих африканцев\индусов кто считать будет, правда?
И вишенкой на этой зловонной куче непотребства - золотой парашют Самого Эффективного Менеджера (ТМ), который загнал (бы если бы не государство) в банкротство некогда ведущую мировую корпорацию, размером $37 млн (таки не выплатили) и $62 млн начислений и акций (таки выплатили). Т.е. человек образцово-показательно угробил лучшую на тот момент компанию и получил за это столько денег, сколько ты не смог бы потратить за всю свою жизнь.
Любите ли вы Эффективных Менеджеров (ТМ) так, как люблю их я?
Не думали сделать онлайн версию? По своему опыту могу сказать, что когда внезапно собрались компанией, часто играете в то, что есть под рукой. Не будешь же таскать на всякий случай набор игр)
Нет, не один и тот же) Каждому человеку достаточно один раз дать линейкой по рукам. Но на проекте у меня 8 бекеров, и если каждый сделает каждую ошибку... привет декартово произведение
Про лекции думал, но алгоритмическое мышление лекциями не достигается, думаю. Пока пришли к перекрестному кодревью перед моим кодревью, помогает большую часть вопросов снимать
Стоит добавить, что здесь речь не просто о столбцах в БД, а о именах полей (свойств) доменной модели. Поэтому, как они называются - вопрос действительно важный.
Очень здорово, что вы проанализировали стандарты. Опираясь на них, можно действительно пересмотреть подход к наименованию этих свойств.
Но из вашего же анализа я вижу, что единого мнения на этот счёт нет, а значит "здесь так принято" всё ещё имеет власть
У нас сейчас есть такой персонаж. Зп требует маленькую, соотношение цена/качество руководство радует, но работать с ним никто не хочет. Буквально сейчас увольняется человек, нанятый на такую же с ним позицию неделю назад, ибо этот персонаж просто устраивал конфликты на ровном месте
Думаю, те, кого что-то достало, не станут отправлять в топку, а выразят в опросе своё недовольство
перформит, решает наиболее сложные задачи, помогает другим
Спасибо за статью, попробую покритиковать)
Ваше решение - это ответ на конкретный кейс, когда соискатель накидал шпаргалок. Т. Е. вы предлагаете целое собеседование дополнительное ради решения только одной конкретной проблемы. В разработке это называется костыль)
Я пришёл к мысли от необходимости алгоритмического собеседования, когда раз за разом в команде сталкивался с тем, что люди не думают об алгоритмической сложности своего кода. Например, человек (очень неглупый) берёт массив пользователей из (10к) и для каждой записи делает отдельный запрос к БД. И таких проходов по массиву пользователей - N в секунду. БД ложилась под нагрузкой, хотя тяжёлых запросов не было. И таких кейсов много.
Если бы я проводил алгоритмические собеседования, не нанял бы человека (см выше). А этот человек реально тащит.
Сделал для себя вывод: алгоритмические собеседования это хорошо, если можешь себе это позволить. Я вот не могу
За сам факт статьи спасибо, ибо вопрос найма девопс актуальный, и наличие дискуссии - уже прекрасно.
По существу статьи:
Много сказано про найм в ит. Зачем? Про это сломано так много копий, что еще одно ничего не изменит. Много в статье и верно сказано и спорных моментов
Было бы здорово сделать акцент на найме именно девопса, в чем специфика, отличия от найма программиста, админа, менеджера, аналитика, которых (я надеюсь) мы уже умеем нанимать?
Гуглить по слову "оркестрация")
У нас было два железных криптосервиса с библиотекой на .net 2.0, сто семьдесят семь микросервисов на .net 3.5 на поддержке (сервисы хорошие, оплачивать их рефакторинг, мы, конечно, не будем), три сервиса на java, разработчики которых уже не с нами, пять версий одного микросервиса с разной степенью реализованности интеграций (партнер по интеграции до сих пор не предоставил тест, а сдавать прод через две недели), и целое море микросервисов, которые можно запустить только на проде, поскольку цепочки интеграции превышают все мыслимые человеческому мозгу размерности. Не то, чтобы всё это было категорически необходимо для успешной работы бизнес-процессов, но если ты мастодонт масштабов страны, то все описанное выше - лишь малая часть твоей инфраструктуры
Возможность писать на разных языках - это только одна из множества возможностей. Банально у меня в одном мс устаревший стек и нет возможности поднять версию фреймворка, а в другом нужна новая фича, которая вот только вышла в бета-тестирование в новом фреймворке, и ещё не известно, насколько хорошо она будет работать под нагрузкой. В монолите это стало бы неразрешимой проблемой
Соглашусь, надо соизмерять подходы с потребностями. Как говорил наш препод по морской практике, лучший узел - тот, который ты знаешь.
Однако чем больше ты вкладываешься в технологии, тем меньше у тебя проблем роста. А проблемы роста, они, собаки такие, мешают, как это ни удивительно, росту. А это, зачастую, наша приоритетная задача - чтобы проект развивался.
Так что можно оставаться малышом на монолите, а можно стремиться применять современные подходы там, где это можно себе позволить, рассчитывая на дивиденды в будущем в виде меньших издержек развития проекта
Для домашнего проекта я бы писал монолит просто потому, что у меня нет ни желания, ни возможности тратить время на всю суету вокруг микросервисов. Но на рабочем проекте я монолит бы даже не стал рассматривать
З. Ы. И, простите, ться
У нас на девопс открыто четыре вакансии, нашли одного джуна. Ох, как же он меня утомил: капризный, это не хочу, то не буду, а вот это мне интересно, это я буду, и вообще, что вы мне тут качество жизни своими задачами понижаете и докажите, что это моя задача. Девопсы нонче - айтишники среди айтишников. Кажется, я начал догадываться, почему нас недолюбливают
С началом войны многие адекватные люди убыли и из страны и из Яндекса. Закономерно, что уровень всего упал. Моё имхо по существу
Тестовые задания сомнительная вещь сама по себе, прежде всего как раз из за таких ситуаций: соискатель тратит неадекватное количество своего времени без каких-либо гарантий на профит.
Такие ситуации с тестовыми заданиями скорее правило, чем исключение. Делая тестовое задание, будьте готовы даже не получить ответа.
Подобное поведение со стороны компании - свинство (звучит единодушное осуждение)
Вывод о цели тестовых заданий в виде сбора данных для обучения нейросети выглядит совой на глобусе
Обижаться на всю компанию и призывать бойкотировать - звучит наивно. Но выводы о неизбежности второго закона термодинамики сделать можно
"Гендиректор корпорации Boeing, выступая перед акционерами, признал вину в части, касающейся недалекости инженеров при проектировании самолета " - вот от этого у меня, как инженера, подгорает. Как раз таки инженеры во всю трубили о недопустимости выпуска самолета в такой конфигурации, но их... заткнули. А самых громких тупо уволили (если правильно помню).
Мне сложно судить о том, что в такой ситуации мог сделать пилот. Думаю, все сильно зависит от пилота, его опыта, состояния, подготовленности. Кстати, о подготовленности: подобные ситуации должны, но не были отработаны на тренажерах. Вспомнить в критической ситуации правильные действия... ну, это надо быть особого склада человеком, и сейчас, думаю, все меньше пилотов являются такими людьми. По своему опыту если судить - в критической ситуации ты вспоминаешь только то, что хорошенько отработал на тренировках, что записалось в рефлексы, в мозжечок.
Пилоты разбившихся самолетов по тем или иным причинам не были готовы к такого рода ситуациям. А ситуацию создало руководство Боинга, игнорируя все возможные правила безопасности ради сиюминутной выгоды.
Яркий пример подобного стиля управления можно так же увидеть в истории гибели яхты https://www.yachtrussia.com/articles/2015/11/30/oyster825.html
Суть истории, что очередной гений управления довел яхтосторительную компанию с мировой историей и репутацией до банкротства, начав клепать яхты, забив на безопасность.
В истории катастрофы Боинг много составляющих, как и у большинства катастроф. Но основной причиной является управление компанией, поставившее деньги выше человеческих жизней
Спасибо за ресеч. Да, про эту опцию я и имел в виду: инженеры в один голос утверждали, что эта опция должна быть обязательной, но их заткнули. Так же проблему усугубило то, что про наличие/отсутствие опции пилоты не знали/не задумывались, проблемы с датчиками и работой системы стабилизации на тренажёрах не отрабатывались, инструкций что делать в такой ситуации не было. По факту при отсутствии этой опции самолёт отправлялся автоматикой в пике/сваливание, а экипаж вообще не понимал что происходит.
Т. Е. Ещё раз
1) О проблеме знали
2) проблему игнорировали
3) даже после первых катастроф проблему не признавали и замалчивали
4) проблема была создана искусственно на пустом месте ради небольшого дополнительного дохода
Хм. У меня другая инфа. Завтра погуглю
все эти проблемы (и катастрофы с MCAS, и оторвавшаяся дверь) - от Эффективных Менеджеров (ТМ).
В первом случае Эффективные Менеджеры (ТМ) решили сделать датчики системы опциональными за дополнительные деньги, оставив только один обязательный, проигнорировав инженеров и забив на безопасность. Деньги же не пахнут, верно?
Во втором случае отдали работы на аутсорс в компанию, где еще более Эффективные Менеджеры (ТМ) решили вообще забить болт (горький сарказм) на безопасность.
В обоих случаях еще одни - государственные - Эффективные Менеджеры (ТМ) отдали проверку безопасности на откуп Боинга. Это все равно, что принимать экзамен по вождению у вас будет человек, которому вы платите за обучение. Казалось бы, что могло пойти не так?
И, наконец, еще одни - европейские государственные - Эффективные Менеджеры (ТМ) отдали проверку безопасности на откуп американским Эффективным Менеджерам (ТМ) (см. пункт выше). Казалось бы?
И весь этот порнхаб творился и копился годами, пока не стали падать самолеты в Европе. Ведь этих африканцев\индусов кто считать будет, правда?
И вишенкой на этой зловонной куче непотребства - золотой парашют Самого Эффективного Менеджера (ТМ), который загнал (бы если бы не государство) в банкротство некогда ведущую мировую корпорацию, размером $37 млн (таки не выплатили) и $62 млн начислений и акций (таки выплатили). Т.е. человек образцово-показательно угробил лучшую на тот момент компанию и получил за это столько денег, сколько ты не смог бы потратить за всю свою жизнь.
Любите ли вы Эффективных Менеджеров (ТМ) так, как люблю их я?
спасибо, пригодится. Если что-то найдете - буду благодарен. У нас показателя точности пока нет, как раз над этим сейчас работаем
О, у нас сейчас такая задача по gps. Подкинете ссылок/советов?
Не думали сделать онлайн версию? По своему опыту могу сказать, что когда внезапно собрались компанией, часто играете в то, что есть под рукой. Не будешь же таскать на всякий случай набор игр)