ну так если не продаётся иначе, то странно было бы ожидать массового бессеребреничества и идеализма, как бы это не было бы неприятным для нас, сторонников честного резюме
цифры из многих энтерпрайзов и из неоднократных безуспешных попыток удержать вырощенного подопечного в разных местах. Это неприятное открытие про типовые регламентированные 20% и я его обнаруживаю во всех крупных российских компаниях, с которыми пересекался. Вижу я естественно не всё, тольно линейные инженерные и линейные менеджерские позиции
Про 100/200 процентов у джунов это про нынешние 70/140/210, которые я наблюдаю на некоторых джуновых и миддловых вилках.
Вы совершенно зря делите ИТ на "только топ" и "ничего нет". ИТ большое и в нем много качественного места результативным инженерам. А топ он относительно небольшой по сравнению со всем ИТ
в энтерпрайзах есть типовое ограничение на ФОТ: рост не более 20% в год, даже если ты переводишься из дворников в Воркуте в директоры департамента в Москве. То самое "бюджет на удержание сильно ниже бюджета на найм". А у джунов за полгода-год стоимость на рынке растёт на 100, а то и 200 процентов и поэтому там, где об этом не подумали финансисты, джуны часто чистый минус по доходности, потому что у них есть только 1 рациональная стратегия: скорее менять работодателя и делать это не реже раза в год в первые годы карьеры. Потому и избегают. Потому и многие учат джунов накручивать опыт и притворяться миддлами, чтобы начать своё собственное колесо развития.
циничный взгляд на работу: она в разрезе долгих лет карьеры на условные 80% состоит из "надо" и на условные 20% из "хочу" и на мой замыленный и искажённый взгляд редко кто из бросивших универ молодых айтишников не сдадутся при первых же рабочих проблемах. С опытом и возрастом за человека уже начинают говорить результаты. Ну и основу из фундаментальных наук как фундамент для инженерной прокачки отрицать нельзя: сам мало кто добровольно в себя этот фундамент засунет
На мой взгляд, в ИТ-сфере, которая ориентирована на немедленный и постоянный результат, ВУЗ вторичен.
По моему скромному опыту в 25 лет работы айтишником в энтерпрайзах, степень заборостроительности универа обычно имеет некоторое значение для первой вакансии, т.к. у тебя нет опыта и сравнивать тебя можно только по "был ли заучкой в школе и универе", хотя это легко перебивается "реализовал то-то", если не был. Как появляется опыт, то для окружающих название универа становится просто булевой переменной "есть высшее образование", а на первое место выходят достижения, навыки и умение в социализацию. Нет, бывают конечно блатные вакансии и вакансии с придурью, где результативность вторична и заменяется системными процессами, где можно поставить мартышку и ничего не поломается, и там под "работать у нас большая честь" пишут "МГУ" в требованиях и подобное, но нужны ли инженерам такие места я сильно сомневаюсь.
И не стоит переоценивать элитарность: несколько ведущих вузов выпускают каплю в море от потребностей и она не является определяющей. Это не говоря уже о том, что совсем не 100% получивших диплом дальше будут работать в ИТ, а из пошедших в ИТ все разбегутся по 100500 узких специализаций, не все из которых легко конвертируются, поэтому факт, что вы когда-то с кем-то пили пиво несколько раз и несколько раз пересекались на парах много лет назад я бы не стал считать значительным.
при упоминании SRE у нас почему-то упускают из вида, что по классике от Гугла SRE это сами разработчики конечного продукта, которые в том числе отвечают за эксплуатацию на проде. Чаще всего у нас SRE упоминается как отдельная коммунальная команда разработчиков-инфраструктурщиков, которая круглосуточно саппортит чужие продукты, что на мой взгляд только вредит этим продуктам и их надёжности, сохраняя в них "у меня все работает". Демо собеседований от того же Т-Банка очень наглядно это демонстрируют для сторонних наблюдателей, но они не одни такие.
Сын учится в профильной магистратуре, знает без большой практики кучу языков программирования, юникс, докер, обучает нейросети, писал модули питона на c++ под linux, знает высшую математику, алгоритмы. Литкод ковырял. Сейчас пытается в стажёры прорваться и никак не может пройти хоть на одно собеседование с технарём, чтобы его техскиллы попроверяли. Всё умирает на hr. Возможно их заваливают вкатуны, прокачанные сообществом "осознанная меркантильность" и боты вкатунов, что он выглядит не ярко на их фоне. И как помочь не соображу, кроме как научить подходам из "осознанная меркантильность" и курсов для вкатунов, когда учать придумывать себе коммерческий опыт. Врать очень сильно не хочется, ведь база есть и она хорошая на мой технарский взгляд.
"у меня точно такая же нога и она не болит". Я это в смысле, что не помогший Вам набор таблеток и практик никоим образом не означает, что всем подбирают неправильное или все обязательно будут мучиться без шансов на выздоровление. На мой взгляд Вы провели антипропаганду лечения и кто-то может на неё совешенно зря повестись
Интересное, спасибо. По поводу переключения master/slave у vault: а разве оно при shared storage вроде consul не работает как набор отдельных реплик vault, не знающих о других?
Мне для подобного очень помогла связка emacs+vim-плагин и org-mode. Org-mode даёт быстро вставляемые шаблоны заметок/дневниковых записей/итогов периода, а vim-плагин помогает отмечать или не отмечать чекбоксики в самоопросниках простым нажатием '.' в связке с 'j', который переходит к следующей строке. Ну и всё это под gpg и внутри git, т.е. нет никакой зависимости ни от операционной системы, ни от коммерческой компании.
Не исключено, что это нужно для госов и окологосов и их интеграторов. Международные сертификации больше не доступны, а внутренний ответ на "конкурс требует наличия у исполнителя не менее N сертифицированных специалистов по M" такая сертификация даёт. Ну и в госкомпаниях это может быть частью системы требований к должностям. однако прокторинг пока отсутствует и потому ценности в такой оценке сейчас мало: отвечать на вопросы может вообще другой человек.
Вы точно честно сравниваете между собой стоимость инсталляции Оракла с его сертифицированным под него железом и стоимость решения на Постгрессах поверх чего попалось, где дельту можно смело вложить в Департамент Разработки Великолепных Решений и не остаться в накладе по итогу?
Посмотрел ссылки. Никакого подтверждения тезису, что на одной и той же железке джоин пары таблиц с фуллсканом оракл будет делать на два порядка быстрее постгресса не увидел. Увидел обсуждение неких специфичных конкретных кейсов, которых может просто не существовать в куче мест и которые в случае возникновения решаемы самим владельцем сервиса несколькими разными способами.
Я как-то всё по крупным компаниям обретаюсь и обычно везде C-level назначал владельца DevOps-экосистемы и продуктовые менеджеры вполне могли обсуждать с ним потребное взаимодействие, в случае необходимости эскалируя.
Вам нужна не инфра, а возможности для релизов, тестирования и эксплуатации. Вот именно они и являются темой для обсуждения с DevOps-командой. А уж как они там работают внутри оставьте инфраструктурщиками и их коммунальным решениям
По опыту вот эти вот быстрые проверки на продах регулярно становятся причиной авралов, потому и реакция такая: все регулярно бьют себя пяткой в грудь "да ничего страшного, я сто раз так дома на ноуте делал" и оно регулярно же от такого сыпется из-за разных неучтённых моментов и банального человеческого фактора. Отдайте ответственность за доступность вашего прода вашему командному девопсу и тогда вы сами сможете управлять рисками и подобными тестами. Но хорошей практикой является выстраивание отлаженной цепочки релизов DEV->UAT->PROD, которую вы в любой момент можете быстро прогнать: тогда у вас сохраняется управляемость и появляется скорость.
ну так если не продаётся иначе, то странно было бы ожидать массового бессеребреничества и идеализма, как бы это не было бы неприятным для нас, сторонников честного резюме
цифры из многих энтерпрайзов и из неоднократных безуспешных попыток удержать вырощенного подопечного в разных местах. Это неприятное открытие про типовые регламентированные 20% и я его обнаруживаю во всех крупных российских компаниях, с которыми пересекался. Вижу я естественно не всё, тольно линейные инженерные и линейные менеджерские позиции
Про 100/200 процентов у джунов это про нынешние 70/140/210, которые я наблюдаю на некоторых джуновых и миддловых вилках.
Вы совершенно зря делите ИТ на "только топ" и "ничего нет". ИТ большое и в нем много качественного места результативным инженерам. А топ он относительно небольшой по сравнению со всем ИТ
в энтерпрайзах есть типовое ограничение на ФОТ: рост не более 20% в год, даже если ты переводишься из дворников в Воркуте в директоры департамента в Москве. То самое "бюджет на удержание сильно ниже бюджета на найм". А у джунов за полгода-год стоимость на рынке растёт на 100, а то и 200 процентов и поэтому там, где об этом не подумали финансисты, джуны часто чистый минус по доходности, потому что у них есть только 1 рациональная стратегия: скорее менять работодателя и делать это не реже раза в год в первые годы карьеры. Потому и избегают. Потому и многие учат джунов накручивать опыт и притворяться миддлами, чтобы начать своё собственное колесо развития.
циничный взгляд на работу: она в разрезе долгих лет карьеры на условные 80% состоит из "надо" и на условные 20% из "хочу" и на мой замыленный и искажённый взгляд редко кто из бросивших универ молодых айтишников не сдадутся при первых же рабочих проблемах. С опытом и возрастом за человека уже начинают говорить результаты. Ну и основу из фундаментальных наук как фундамент для инженерной прокачки отрицать нельзя: сам мало кто добровольно в себя этот фундамент засунет
На мой взгляд, в ИТ-сфере, которая ориентирована на немедленный и постоянный результат, ВУЗ вторичен.
По моему скромному опыту в 25 лет работы айтишником в энтерпрайзах, степень заборостроительности универа обычно имеет некоторое значение для первой вакансии, т.к. у тебя нет опыта и сравнивать тебя можно только по "был ли заучкой в школе и универе", хотя это легко перебивается "реализовал то-то", если не был. Как появляется опыт, то для окружающих название универа становится просто булевой переменной "есть высшее образование", а на первое место выходят достижения, навыки и умение в социализацию. Нет, бывают конечно блатные вакансии и вакансии с придурью, где результативность вторична и заменяется системными процессами, где можно поставить мартышку и ничего не поломается, и там под "работать у нас большая честь" пишут "МГУ" в требованиях и подобное, но нужны ли инженерам такие места я сильно сомневаюсь.
И не стоит переоценивать элитарность: несколько ведущих вузов выпускают каплю в море от потребностей и она не является определяющей. Это не говоря уже о том, что совсем не 100% получивших диплом дальше будут работать в ИТ, а из пошедших в ИТ все разбегутся по 100500 узких специализаций, не все из которых легко конвертируются, поэтому факт, что вы когда-то с кем-то пили пиво несколько раз и несколько раз пересекались на парах много лет назад я бы не стал считать значительным.
дефолт-сити и офис?
при упоминании SRE у нас почему-то упускают из вида, что по классике от Гугла SRE это сами разработчики конечного продукта, которые в том числе отвечают за эксплуатацию на проде. Чаще всего у нас SRE упоминается как отдельная коммунальная команда разработчиков-инфраструктурщиков, которая круглосуточно саппортит чужие продукты, что на мой взгляд только вредит этим продуктам и их надёжности, сохраняя в них "у меня все работает". Демо собеседований от того же Т-Банка очень наглядно это демонстрируют для сторонних наблюдателей, но они не одни такие.
Сын учится в профильной магистратуре, знает без большой практики кучу языков программирования, юникс, докер, обучает нейросети, писал модули питона на c++ под linux, знает высшую математику, алгоритмы. Литкод ковырял. Сейчас пытается в стажёры прорваться и никак не может пройти хоть на одно собеседование с технарём, чтобы его техскиллы попроверяли. Всё умирает на hr. Возможно их заваливают вкатуны, прокачанные сообществом "осознанная меркантильность" и боты вкатунов, что он выглядит не ярко на их фоне. И как помочь не соображу, кроме как научить подходам из "осознанная меркантильность" и курсов для вкатунов, когда учать придумывать себе коммерческий опыт. Врать очень сильно не хочется, ведь база есть и она хорошая на мой технарский взгляд.
"у меня точно такая же нога и она не болит". Я это в смысле, что не помогший Вам набор таблеток и практик никоим образом не означает, что всем подбирают неправильное или все обязательно будут мучиться без шансов на выздоровление. На мой взгляд Вы провели антипропаганду лечения и кто-то может на неё совешенно зря повестись
Интересное, спасибо. По поводу переключения master/slave у vault: а разве оно при shared storage вроде consul не работает как набор отдельных реплик vault, не знающих о других?
Мне для подобного очень помогла связка emacs+vim-плагин и org-mode. Org-mode даёт быстро вставляемые шаблоны заметок/дневниковых записей/итогов периода, а vim-плагин помогает отмечать или не отмечать чекбоксики в самоопросниках простым нажатием '.' в связке с 'j', который переходит к следующей строке. Ну и всё это под gpg и внутри git, т.е. нет никакой зависимости ни от операционной системы, ни от коммерческой компании.
Не исключено, что это нужно для госов и окологосов и их интеграторов. Международные сертификации больше не доступны, а внутренний ответ на "конкурс требует наличия у исполнителя не менее N сертифицированных специалистов по M" такая сертификация даёт. Ну и в госкомпаниях это может быть частью системы требований к должностям. однако прокторинг пока отсутствует и потому ценности в такой оценке сейчас мало: отвечать на вопросы может вообще другой человек.
Вы точно честно сравниваете между собой стоимость инсталляции Оракла с его сертифицированным под него железом и стоимость решения на Постгрессах поверх чего попалось, где дельту можно смело вложить в Департамент Разработки Великолепных Решений и не остаться в накладе по итогу?
Посмотрел ссылки. Никакого подтверждения тезису, что на одной и той же железке джоин пары таблиц с фуллсканом оракл будет делать на два порядка быстрее постгресса не увидел. Увидел обсуждение неких специфичных конкретных кейсов, которых может просто не существовать в куче мест и которые в случае возникновения решаемы самим владельцем сервиса несколькими разными способами.
Я как-то всё по крупным компаниям обретаюсь и обычно везде C-level назначал владельца DevOps-экосистемы и продуктовые менеджеры вполне могли обсуждать с ним потребное взаимодействие, в случае необходимости эскалируя.
Вам нужна не инфра, а возможности для релизов, тестирования и эксплуатации. Вот именно они и являются темой для обсуждения с DevOps-командой. А уж как они там работают внутри оставьте инфраструктурщиками и их коммунальным решениям
при том, что менеджеры бывают всякие, а Вы их всех в своём комментарии уравняли и потребовали от них техскиллов инженеров инфраструктуры
а сможете пруфы привести?
По опыту вот эти вот быстрые проверки на продах регулярно становятся причиной авралов, потому и реакция такая: все регулярно бьют себя пяткой в грудь "да ничего страшного, я сто раз так дома на ноуте делал" и оно регулярно же от такого сыпется из-за разных неучтённых моментов и банального человеческого фактора. Отдайте ответственность за доступность вашего прода вашему командному девопсу и тогда вы сами сможете управлять рисками и подобными тестами. Но хорошей практикой является выстраивание отлаженной цепочки релизов DEV->UAT->PROD, которую вы в любой момент можете быстро прогнать: тогда у вас сохраняется управляемость и появляется скорость.