Если честно, то немного 'водянистый' текст в статье. Мы сделали, мы собрали - но что именно?
У вас в начале самом было:
На собеседовании кандидаты столкнулись с некоторыми трудностями из-за стиля интервьюирования. Интервьюер глубоко погружался в вопросы, часто комментируя предыдущий опыт кандидата и указывая на возможные ошибки
Т.е. вы говорите, что частично проблема именно в стиле интервьюерирования и самого интервьюера. Но полечили это новым пулом вопросов?
И следующий пункт:
Опросили интервьюеров о формировании пула вопросов для собеседования, приоритетных навыках кандидатов и тех, которые могут считаться незначительными, поскольку мы готовы обучить нового сотрудника.
Здесь вы по сути увеличили воронку - что может сказаться негативно на пропускной способности собеседующих (и затратах на это). Ну и то, что портрет для найма был составлен неверно - раз какие-то пункты легко убрали.
И что именно подправили тоже непонятно.
В общем, дьявол кроется в деталях, а именно деталей нет и не понятно что конкретно помогло решить вашу проблему и как вы поняли, что это помогло? Новая обратная связь? Метрики найма улучшились?
Суть assert, как уже подмечено выше, именно в проверке только внутренних инвариантов программы и тестах. И то, что в pydantic его затащили для проверок данных - это косяк проектирования и не верное использование инструмента.
Использование и применение очень похожи на то, как это реализовано в Java: использование-assert
Если подытожить про конкуренцию, то сейчас предпочтение чаще отдают кандидату с большим опытом, даже если ему 50 лет, нежели 21-летнему выпускнику курсов.
Если мы сравниваем тяжеловеса (50 лет и большой опыт) с 'курсами', то это сейчас вообще никто и не делает. Как раз в 'курсах' многие компании разочаровались, что не говорит о том, что студенты из хороших ВУЗ-ов в целом могут как раз быть где-то более предпочтительным кандидатом.
Вообще пункт Путь конкуренции очень странный.
Ну и вообще, править в какой-то области (неважно это IT или нет) всегда будет тот, кто быстрее подстраивается и адаптируется к изменениям, мне кажется.
На мой взгляд тут есть одна большая ошибка в том, что проект, который вы задумали для облегчения тестирования нужен именно продукту, а не вам самому и имеет ощутимые и измеримые метрики как успешности/полезности, так и новых доработок. И из-за того, что отнеслись (как мне кажется) к этому как к пет-проекту нужному больше для вас - столкнулись с ожиданиями и их не соответствиям.
Например, Ожидание 1: все будут контрибьютить будет выполнено - потому что вы делаете не просто так же что-то, а проект, для ускорения/улучшения тестирования и снижения тем самым TTM (на этом слове ваш менеджер должен как минимум приоткрыть один глаз).
А раз так, то ваш же менеджер по идее должен был попросить/потребовать план развития проекта и доработок, что вылилось бы в то, что при формировании плана (читай функциональных требований) вы бы собрали пожелания от всех и Ожидание 2: горячие клавиши – это круто возможно (но, понятно, что не факт) не было бы шоком.
Тут отметим, что Ожидание 3: аудитория – люди в той же роли, что и я и другие ожидания, конечно, наврятли можно было бы избежать, так как в таких проектах все достаточно спорадически, но это подчеркивает важность документации - что тоже можно было бы внести в план и минимизировать "Автор уже даже не знает список всех пользователей и не может проконсультировать каждого лично. "
Вообще, вы столкнулись с тем, что это именно проект - со всеми вытекающими проблемами, такими как докумуентация, пользователи, эксплуатация и прочее - это отличный опыт!
И (кмк) на будущее - важно к таким вот вещам относиться сразу как к проекту, как к тому, что не только для вас - а значит и требования другие.
Но, повторюсь, это не критика - я постарался просто добавить новых мыслей и это отличный опыт, который вы приобрели!
Вы не упомянули важную вещь, а именно - это то, как список будет преобразовываться в дерево (и в какое дерево именно), а также вклад в таком случае Comparable. Вот тут я разбирал как это будет происходить: JBook/HashMap#коллизии
Ну и вообще, сама заметка про HashMap, может будет кому полезно: JBook
Все так, если количество элементов в бакете превышает TREEIFY_THRESHOLD (который как раз и равен 8), то будет вызван метод treeifyBin и бакет преобразуется в красно-черное дерево.
Благодаря этому, начиная с Java 8+ производительность java.util.HashMap в худшем случае не O(n), а O(log n).
При всем уважении к автору статьи и материалу (в котором, безусловно, есть доля истины), мне кажется, что все забывают, что лучшее, что вы можете сделать для сотрудников от выгорания - это недопускание таких жестких дедлайнов, в которых ваша команда сгорает. Если вам уже нужны советы из этой статьи не для 1-2 человек, а уже больше, плюс вы начинаете реально собирать такие метрики - вы просто плохой менеджер, который лечит не причину, а симптом.
При этом некоторые советы (Изменения в привычках, язык тела) - это вообще мониторинг настолько глубокий/микро, что съест у вас кучу времени и вам просто некогда будет работать самому (разве что только если это и есть ваша основная работа). И надо помнить, что вы все таки работаете с взрослыми людьми, а не с подростками.
На мой взгляд, если у вас кранчи и дедлайны постоянно, несправедливость (читай - не поощрение тех же успешных дедлайнов или поощрение на словах) - вот вам первая метрика, что у вас сотрудники начали выгорать. Вам не надо подключать микро мониторинг, поверьте.
А лучшее, что вы можете сделать - это исправить процесс/процессы.
Важно заметить, что из России пользоваться ngrok становится все сложнее, а сам их сайт без vpn не открывается сейчас, оплатить подписку уже нельзя, а бесплатные функции всё время урезают. По этому , если это не учебный проект, то сразу желательно посмотреть какие есть альтернативы.
Проблема Hibernate, кмк, в том, что за внешней простотой скрывается достаточно большой пласт дополнительных знаний, которые вам необходимо иметь. При этом, если их нет вы столкнетесь с проблемами только по ходу даже не разработки скорее всего, а уже эксплуатации продукта в продакшене. И эти знания должны быть у всех членов команды разработки, а это не всегда достижимо. И вот эта сложность, которая очень хорошо скрыта и завуалирована - главная проблема в использовании. Hibernate, кмк, очень хорош в прототипировании и mvp, после уже становится сложно.
Видел много команд, кто как раз запускался на Hibernate и после с него уходили.
Это действительно важный аргумент, однако в противовес можно сказать, что Python предоставляет бОльшую гибкость, за что расплачивается как раз тем, что надо окружение настраивать дополнительно (должны быть стандарты по конфигурации серверов, внутренние репозитории-зеркала, надо больше отслеживать уязвимости и реагировать на них) . И не всегда эта гибкость нужна и даже уместна. Плюс научить стильноможномолодежных девопсов проще писать на Python. Поэтому тут надо смотреть под задачу/команду и выбирать с умом.
За свой 25+ летний опыт в разработке ПО я не видел тупых руководителей и заказчиков. Вообще.
Ну а я видел. Это не говорит о том, что все тупые вокруг, но я видел примеры, когда проекты и компании закрывались и не от ума.
А еще я видел манипуляции, обман, причем как заказчиков, так и работников, раздутие бюджета, распилы и многое другое. Это не значит, что везде так и все плохие. Но это есть.
В АйТи, как и в любой сфере, достаточно глупых и дураков. И начальники, как и заказчики, не исключение.
На самом деле в реальности эта позиция миф и все превращается в девопса, который запускает эти инструменты и кое-как настраивает их. При этом сам процесс должен постоянно улучшаться, надо тюнить инструменты, реагировать на false-positive, правила менять, разбирать вектора атак и так далее.
Да чего уж там, по хорошему в каждом из направлений:
Статический анализ: SonarQube, Checkmarx.
Динамическое тестирование: OWASP ZAP.
Фаззинг: AFL, libFuzzer.
Анализ Docker-образов: Trivy.
Нужны свои компетенции.
И где искать человека-оркестр в итак агрессивном мире найма девопсов? Вопрос риторический.
1.2. Отсутствие наставника Для начала, новичкам хочется дать еще такой совет: ОЧЕНЬ внимательно относитесь к курсам, менторам которых вы выбираете. Курсов становится все больше, менторов - тем более и велик шанс попасть на то, где вы разочаруетесь и потратите деньги на ветер.
1.3. Узкий круг задач Здесь скорее лучше не просто 'расширять кругозор', а посмотреть на hh и вакансиях то, что надо работодателю и развивать это. Например: увидели 'опыт работы с PostgreSQL и Kafka': попробуйте реализовать проект на этих технологиях, постарайтесь и сделайте его аккуратно, красиво, добавьте README, docker compose, попросите ревью в чатах и каналах у разных людей, послушайте критику, исправьте и сделайте это как вашу визитку. Да, не все собеседующие посмотрят это, но это будет в любом случае полезно.
2.3 Применяйте T-shaped подход По началу не распыляйтесь и сфокусируйтесь на том, что просят работодатели.
3.1. Следите за трендами Это вообще может быть очень вредный совет, особенно для начинающего. Сфокусируйтесь на важном - на вашем развитии, тренды на то и тренды, что меняются регулярно.
LeetCode - полезен, научитесь решать спокойно задачи хотя бы уровня easy, попрактикуйтесь, чтобы на собеседовании не растеряться.
Про книги Для начинающего разработчика читать книги из раздела "Софт-скиллы и развитие карьеры" - рано. Такие книги пора читать тогда, когда вы уже уровня middle и выше, на мой взгляд.
Помните, что ваше время ограничено и все успеть не получится - не распыляйтесь!
Про книги "Разработка на Java": это хорошие и полезные книги, но уже не новые и некоторые вещи там устарели. Опять же, "Java Concurrency in Practice" - это не книга для совсем начинающего, хоть и это крайне полезная книга. Если уж совсем посмотреть в классику, то также полезно посмотреть "Философию Java", она тоже старая и где-то устаревшая, но все еще дает хорошие мысли. И я НЕ советую читать Шилдта. Лучше посмотрите Хортсмана, на собеседованиях также спрашивают про GoF design patterns.
И еще: смотрите mock-собеседования и отвечайте на вопросы там, подмечайте свои белые пятна в знаниях. Вообще, в статье не указали, но сейчас достаточно много интересных и полезных youtube каналов про образование и обучение (в том числе и Java) - не упускайте это.
Если честно, то немного 'водянистый' текст в статье. Мы сделали, мы собрали - но что именно?
У вас в начале самом было:
Т.е. вы говорите, что частично проблема именно в стиле интервьюерирования и самого интервьюера. Но полечили это новым пулом вопросов?
И следующий пункт:
Здесь вы по сути увеличили воронку - что может сказаться негативно на пропускной способности собеседующих (и затратах на это). Ну и то, что портрет для найма был составлен неверно - раз какие-то пункты легко убрали.
И что именно подправили тоже непонятно.
В общем, дьявол кроется в деталях, а именно деталей нет и не понятно что конкретно помогло решить вашу проблему и как вы поняли, что это помогло? Новая обратная связь? Метрики найма улучшились?
Суть assert, как уже подмечено выше, именно в проверке только внутренних инвариантов программы и тестах. И то, что в pydantic его затащили для проверок данных - это косяк проектирования и не верное использование инструмента.
Использование и применение очень похожи на то, как это реализовано в Java: использование-assert
А что нет-то? Ну в Айти много изменений и они частые, так, и?
В новых версиях intellij idea это по умолчанию так, скриншот скорее всего оттуда.
Если подытожить про конкуренцию, то сейчас предпочтение чаще отдают кандидату с большим опытом, даже если ему 50 лет, нежели 21-летнему выпускнику курсов.Если мы сравниваем тяжеловеса (50 лет и большой опыт) с 'курсами', то это сейчас вообще никто и не делает. Как раз в 'курсах' многие компании разочаровались, что не говорит о том, что студенты из хороших ВУЗ-ов в целом могут как раз быть где-то более предпочтительным кандидатом.
Вообще пункт Путь конкуренции очень странный.
Ну и вообще, править в какой-то области (неважно это IT или нет) всегда будет тот, кто быстрее подстраивается и адаптируется к изменениям, мне кажется.
Вот как раз новичкам с энтузиазмом должен помогать менеджер, что не всегда происходит и это плохо (тоже метрика, но для руководителя).
И вы совершенно правы, что это действительно энтузиазм - и слава богу ваш не угас!
На мой взгляд тут есть одна большая ошибка в том, что проект, который вы задумали для облегчения тестирования нужен именно продукту, а не вам самому и имеет ощутимые и измеримые метрики как успешности/полезности, так и новых доработок. И из-за того, что отнеслись (как мне кажется) к этому как к пет-проекту нужному больше для вас - столкнулись с ожиданиями и их не соответствиям.
Например, Ожидание 1: все будут контрибьютить будет выполнено - потому что вы делаете не просто так же что-то, а проект, для ускорения/улучшения тестирования и снижения тем самым TTM (на этом слове ваш менеджер должен как минимум приоткрыть один глаз).
А раз так, то ваш же менеджер по идее должен был попросить/потребовать план развития проекта и доработок, что вылилось бы в то, что при формировании плана (читай функциональных требований) вы бы собрали пожелания от всех и Ожидание 2: горячие клавиши – это круто возможно (но, понятно, что не факт) не было бы шоком.
Тут отметим, что Ожидание 3: аудитория – люди в той же роли, что и я и другие ожидания, конечно, наврятли можно было бы избежать, так как в таких проектах все достаточно спорадически, но это подчеркивает важность документации - что тоже можно было бы внести в план и минимизировать "Автор уже даже не знает список всех пользователей и не может проконсультировать каждого лично. "
Вообще, вы столкнулись с тем, что это именно проект - со всеми вытекающими проблемами, такими как докумуентация, пользователи, эксплуатация и прочее - это отличный опыт!
И (кмк) на будущее - важно к таким вот вещам относиться сразу как к проекту, как к тому, что не только для вас - а значит и требования другие.
Но, повторюсь, это не критика - я постарался просто добавить новых мыслей и это отличный опыт, который вы приобрели!
Вы не упомянули важную вещь, а именно - это то, как список будет преобразовываться в дерево (и в какое дерево именно), а также вклад в таком случае Comparable.
Вот тут я разбирал как это будет происходить: JBook/HashMap#коллизии
Ну и вообще, сама заметка про HashMap, может будет кому полезно: JBook
Все так, если количество элементов в бакете превышает TREEIFY_THRESHOLD (который как раз и равен 8), то будет вызван метод treeifyBin и бакет преобразуется в красно-черное дерево.
Благодаря этому, начиная с
Java 8+производительностьjava.util.HashMapв худшем случае неO(n), аO(log n).При всем уважении к автору статьи и материалу (в котором, безусловно, есть доля истины), мне кажется, что все забывают, что лучшее, что вы можете сделать для сотрудников от выгорания - это недопускание таких жестких дедлайнов, в которых ваша команда сгорает. Если вам уже нужны советы из этой статьи не для 1-2 человек, а уже больше, плюс вы начинаете реально собирать такие метрики - вы просто плохой менеджер, который лечит не причину, а симптом.
При этом некоторые советы (Изменения в привычках, язык тела) - это вообще мониторинг настолько глубокий/микро, что съест у вас кучу времени и вам просто некогда будет работать самому (разве что только если это и есть ваша основная работа). И надо помнить, что вы все таки работаете с взрослыми людьми, а не с подростками.
На мой взгляд, если у вас кранчи и дедлайны постоянно, несправедливость (читай - не поощрение тех же успешных дедлайнов или поощрение на словах) - вот вам первая метрика, что у вас сотрудники начали выгорать. Вам не надо подключать микро мониторинг, поверьте.
А лучшее, что вы можете сделать - это исправить процесс/процессы.
Важно заметить, что из России пользоваться ngrok становится все сложнее, а сам их сайт без vpn не открывается сейчас, оплатить подписку уже нельзя, а бесплатные функции всё время урезают. По этому , если это не учебный проект, то сразу желательно посмотреть какие есть альтернативы.
Проблема Hibernate, кмк, в том, что за внешней простотой скрывается достаточно большой пласт дополнительных знаний, которые вам необходимо иметь. При этом, если их нет вы столкнетесь с проблемами только по ходу даже не разработки скорее всего, а уже эксплуатации продукта в продакшене. И эти знания должны быть у всех членов команды разработки, а это не всегда достижимо. И вот эта сложность, которая очень хорошо скрыта и завуалирована - главная проблема в использовании. Hibernate, кмк, очень хорош в прототипировании и mvp, после уже становится сложно.
Видел много команд, кто как раз запускался на Hibernate и после с него уходили.
Это действительно важный аргумент, однако в противовес можно сказать, что Python предоставляет бОльшую гибкость, за что расплачивается как раз тем, что надо окружение настраивать дополнительно (должны быть стандарты по конфигурации серверов, внутренние репозитории-зеркала, надо больше отслеживать уязвимости и реагировать на них) . И не всегда эта гибкость нужна и даже уместна. Плюс научить стильноможномолодежных девопсов проще писать на Python. Поэтому тут надо смотреть под задачу/команду и выбирать с умом.
Ну а я видел. Это не говорит о том, что все тупые вокруг, но я видел примеры, когда проекты и компании закрывались и не от ума.
А еще я видел манипуляции, обман, причем как заказчиков, так и работников, раздутие бюджета, распилы и многое другое. Это не значит, что везде так и все плохие. Но это есть.
В АйТи, как и в любой сфере, достаточно глупых и дураков. И начальники, как и заказчики, не исключение.
На самом деле в реальности эта позиция миф и все превращается в девопса, который запускает эти инструменты и кое-как настраивает их. При этом сам процесс должен постоянно улучшаться, надо тюнить инструменты, реагировать на false-positive, правила менять, разбирать вектора атак и так далее.
Да чего уж там, по хорошему в каждом из направлений:
Статический анализ: SonarQube, Checkmarx.
Динамическое тестирование: OWASP ZAP.
Фаззинг: AFL, libFuzzer.
Анализ Docker-образов: Trivy.
Нужны свои компетенции.
И где искать человека-оркестр в итак агрессивном мире найма девопсов? Вопрос риторический.
Для скриптов и маленьких программ есть свои языки, Java в их число не входит.
Мне не хватает кармы плюс поставить, поэтому оставлю плюс этим комментарием.
Тут согласен, также как и с курсами - надо осторожно.
Но есть мок собеседования от достаточно известных ребят, например, тот же Пронин по питону, от подлодки есть моковые, от Хекслета.
Да и в целом вопросы послушать полезно, на мой взгляд.
Привет!
Спасибо за статью!
Что хотелось бы добавить/отметить:
1.2. Отсутствие наставника
Для начала, новичкам хочется дать еще такой совет: ОЧЕНЬ внимательно относитесь к курсам, менторам которых вы выбираете. Курсов становится все больше, менторов - тем более и велик шанс попасть на то, где вы разочаруетесь и потратите деньги на ветер.
1.3. Узкий круг задач
Здесь скорее лучше не просто 'расширять кругозор', а посмотреть на hh и вакансиях то, что надо работодателю и развивать это. Например: увидели 'опыт работы с PostgreSQL и Kafka': попробуйте реализовать проект на этих технологиях, постарайтесь и сделайте его аккуратно, красиво, добавьте README, docker compose, попросите ревью в чатах и каналах у разных людей, послушайте критику, исправьте и сделайте это как вашу визитку. Да, не все собеседующие посмотрят это, но это будет в любом случае полезно.
2.3 Применяйте T-shaped подход
По началу не распыляйтесь и сфокусируйтесь на том, что просят работодатели.
3.1. Следите за трендами
Это вообще может быть очень вредный совет, особенно для начинающего. Сфокусируйтесь на важном - на вашем развитии, тренды на то и тренды, что меняются регулярно.
LeetCode - полезен, научитесь решать спокойно задачи хотя бы уровня easy, попрактикуйтесь, чтобы на собеседовании не растеряться.
Про книги
Для начинающего разработчика читать книги из раздела "Софт-скиллы и развитие карьеры" - рано. Такие книги пора читать тогда, когда вы уже уровня middle и выше, на мой взгляд.
Помните, что ваше время ограничено и все успеть не получится - не распыляйтесь!
Про книги "Разработка на Java": это хорошие и полезные книги, но уже не новые и некоторые вещи там устарели. Опять же, "Java Concurrency in Practice" - это не книга для совсем начинающего, хоть и это крайне полезная книга.
Если уж совсем посмотреть в классику, то также полезно посмотреть "Философию Java", она тоже старая и где-то устаревшая, но все еще дает хорошие мысли. И я НЕ советую читать Шилдта.
Лучше посмотрите Хортсмана, на собеседованиях также спрашивают про GoF design patterns.
И еще: смотрите mock-собеседования и отвечайте на вопросы там, подмечайте свои белые пятна в знаниях. Вообще, в статье не указали, но сейчас достаточно много интересных и полезных youtube каналов про образование и обучение (в том числе и Java) - не упускайте это.
Также можете посмотреть мои советы новичкам в Java и заметки по Java.
Ну Яндекс же не единственная компания у нас!