В компании есть процесс найма, через который проходят все кандидаты. Собеседования являются частью этого процесса. Основная цель собеседования - понять подходит кандидат или нет. Все остальное - это мое мнение и наблюдения, которые я сделал и отразил в статье. И все же, как я чуть ранее писал, хотелось бы уточнить, какая именно фраза натолкнула вас на то, что собеседования в Авито проходят только для прокачки навыков, а не выполняют свою основную задачу?
Но скажите, тогда, пожалуйста, по вашему мнению, зачем это компании? Зачем создавать "левые" вакансии, тратить время на обучение собеседующих, которые скорее всего никогда не смогут участвовать в "честных" собеседованиях и не факт, что такой процесс прокачки навыков принес человеку хоть какую-то пользу, так как обучение - процесс индивидуальный, но при этом ставить под удар репутацию, как минимум, тратить в пустую финансы на поиск и общение с кандидатами, и, как вы сказали, нарушать КЗоТ? Не проще ли, как я писал, просто делать тогда фичи и на них обучаться? И все довольны: бизнес развивается, люди прокачиваются.
Можете, пожалуйста, уточнить, какие именно фразы натолкнули вас на мысль, что в Авито создаются "левые вакансии" для тренировок действующих сотрудников?
Процесс устроен таким образом, что с экспертом-собеседующим может ходить обучающийся и перенимать опыт ведения секции. Кажется, это нормальная практика, чтобы получать реальный опыт. Однако все это происходит на существующих вакансиях, которые есть в компании
Присоединюсь к комментарию. Действительно хороший вариант. Сам не особо практикую именно в таком виде, так как хорошей идеи для пет-проекта пока не появилось, а делать еще один условный TO-DO лист не очень хочется) Чаще просто "в вакууме" смотрю на технологию и пробую ее использовать, но у этого есть свои минусы с тем, что в реальном проекте технология показывает себя совершенно по-другому
Такая мысль была, но тогда сильно больше бы прошло времени до попытки запуска первого A/B-теста, а продуктовые изменения только росли и приходилось бы их поддерживать, что еще дальше оттягивало момент переключения на отрефакторенный код. Поэтому и выбрал вариант делать итеративно по частям. К сожалению, с ним тоже возникли проблемы, как описывал выше, поэтому для последующих работ подход решили поменять. Пока не ясно насколько это хорошее решение, но надеюсь, что закончим быстрее, чем за полтора года
У нас сейчас тоже стоит инициализация аналитики gtm на onload. Сам не замерял насколько сильно оно влияет на производительность, но, видимо, стоит обратить внимание. Спасибо за наводку
Вполне можно, с этим не спорю. Но согласитесь, есть разница между тем, чтобы сразу делать нетормозящее приложение на React, и рефакторить существующий код (у которого есть определенные проблемы с перфомансом), переводя его на React, и при этом не потерять в производительности. Я как раз и рассказываю в своей статье о том, что походу рефакторинга было важным не потерять в производительности от текущего состояния и старался по возможности его улучшать. Да и в целом, кнопки контактов, о которых рассказываю, только вершина айсберга, так как план переписать всю страницу объявления на React, избавившись от легаси решений, которые ухудшают перфоманс
К сожалению, показатели некоторых страниц действительно не настолько хороши, как хотелось бы. Планы по улучшению перфоманса есть, занимаемся ими по мере возможности
Так как появление в поисковой выдаче гугла - это один из способов привлечения траффика на сайт (в данном случае внешнего траффика), то нам важно обращать внимание на метрики, благодаря которым удасться улучшить позиции в выдаче. Поэтому мы стараемся внимательно относиться к метрикам производительности.
Мы не разделяем сейчас бампы пакетов. То есть если в каком-то пакете необходимо поднять patch версию, то во всех зависимых пакетах будет поднята patch версия. Это связано с тем, что наш самописный скрипт не умеет разделять версии, и в юните приняли решение, что сейчас нет необходимости в этом.
Rush выглядит интересным решением. Когда только обсуждали решение о внедрении Lerna, Rush не рассматривали. Сейчас выглядит так, что то, что решает наш скрипт для поднятия версий, уже решено в Rush. Сам не пользовался этим инструментом, но он выглядит интересным
Мы не используем практику коллаборативных пул-реквестов. Для понимания масштаба, наш монорепозиторий сейчас насчитывает 37 npm-пакетов. У нас бывают два типа обновлений зависимостей: обновление зависимости, которая лежит внутри монорепозитория, и внешняя для монорепозитория. В первом случае мы поддерживаем актуальные версии зависимостей внутри монорепозитория, то есть во всех пакетах latest-версии всех внутренних к монорепозиторию зависимостей (это еще нужно, чтобы Lerna работала с пакетами). Поэтому тесты если ломаются, то уже из-за изменений, которые внес разработчик. В таком случае разработчик либо правит код, либо правит тест. Внешние зависимости обновляются чаще всего нашей командой и в случае поломок при обновлении, сами правим тесты и код.
Если я правильно понял, то Bazel — это инструмент для синхронизации и сборки проектов, и работает Bazel в основном как раз с собранными проектом. Сборка проектов в нашем репозитории идет от внутреннего инструмента для бойлерплейтинга (вот здесь можно подробнее о нем узнать ) и этот инструмент учитывает особенности сборки основного монолита. Поэтому нам нужен был инструмент только для синхронизации версий. Lerna работает таким образом, что зависимости внешние могут быть вынесены на корневой уровень монорепозитория, а внутренние зависимости связаны через ссылки. Благодаря такому механизму нам удалось в какой-то момент избавиться от package-lock файлов в наших пакетах, оставив только один lock файл в корне. Плюс, кроме синхронизации, Lerna позволяет автоматизировать работу именно с изменением версий пакетов. Так, к примеру, с помощью двух команд можно узнать какие пакеты были изменены, где и как необходимо изменить версии (поднять патч, минорную или мажорную версию), а затем опубликовать пакеты. И в данном случае синхронизация позволила решить проблему построения явного дерева зависимостей, которое может быть автоматически измененно, а автоматизация упростила работу с монорепозитрием, сведя до работы с небольшим набором команд. Если я правильно понимаю, то в Bazel нет механизма для автоматизации работы именно с версиями пакетов. Кроме того, отмечу что наш монорепозитрой нужен для разработки без сборки, так как пакеты из него еще нужны в основной кодовой базе монолита, в которой настроена и работает своя сборка проекта.
Спасибо за вопросы. Bazel мы не рассматривали как инструмент. Сам о таком инструменте не слышал. Но поизучав документацию, понял, что он не подходит для решения наших проблем. Bazel и Lerna по-разному работают с зависимостями. Lerna создает связь между пакетами (на подобии npm link), благодаря чему изменения, внесенные в зависимом пакете, сразу видны при разработке пакета. Эти изменения могут быть как исполняемым кодом (тогда при разработке сразу будут видны все изменения), а могут быть и изменением версии пакета. Благодаря этому, Lerna позволяет проводить процесс синхронизации зависимостей без участия разработчика по всему дереву зависимостей. Bazel же работает по большей части с node_modules папкой и исходниками, что в ней хранятся. При этом ссылочных связей между пакетами не создается. Bazel позволит решить проблему с неявным описанием зависимостей, но, в отличие от Lerna, не позволит решить проблему с синхронизацией, так как она все еще остается на плечах разработчика. Плюс для Bazel нужна более сложная инфраструктура, чтобы он использовал свои преимущества по полной.
В случае, если кто-то сломал тест или код, то, согласно соседскому соглашению, он его и чинит. У нас эта практика распространяется не только наш монореопзиторий, но и на другие проекты. Плюс, в случае монорепозитория CI настроен таким образом, что без прохождения всех тестов, смержить пул-реквест не получится. Если есть вопросы о том, каким образом лучше внести правки, то разработчик, который лучше разбирается, может помочь, но сами исправления все равно остаются на том, кто сломал.
В компании есть процесс найма, через который проходят все кандидаты. Собеседования являются частью этого процесса. Основная цель собеседования - понять подходит кандидат или нет. Все остальное - это мое мнение и наблюдения, которые я сделал и отразил в статье. И все же, как я чуть ранее писал, хотелось бы уточнить, какая именно фраза натолкнула вас на то, что собеседования в Авито проходят только для прокачки навыков, а не выполняют свою основную задачу?
Но скажите, тогда, пожалуйста, по вашему мнению, зачем это компании? Зачем создавать "левые" вакансии, тратить время на обучение собеседующих, которые скорее всего никогда не смогут участвовать в "честных" собеседованиях и не факт, что такой процесс прокачки навыков принес человеку хоть какую-то пользу, так как обучение - процесс индивидуальный, но при этом ставить под удар репутацию, как минимум, тратить в пустую финансы на поиск и общение с кандидатами, и, как вы сказали, нарушать КЗоТ? Не проще ли, как я писал, просто делать тогда фичи и на них обучаться? И все довольны: бизнес развивается, люди прокачиваются.
Можете, пожалуйста, уточнить, какие именно фразы натолкнули вас на мысль, что в Авито создаются "левые вакансии" для тренировок действующих сотрудников?
Процесс устроен таким образом, что с экспертом-собеседующим может ходить обучающийся и перенимать опыт ведения секции. Кажется, это нормальная практика, чтобы получать реальный опыт. Однако все это происходит на существующих вакансиях, которые есть в компании
Присоединюсь к комментарию. Действительно хороший вариант. Сам не особо практикую именно в таком виде, так как хорошей идеи для пет-проекта пока не появилось, а делать еще один условный TO-DO лист не очень хочется) Чаще просто "в вакууме" смотрю на технологию и пробую ее использовать, но у этого есть свои минусы с тем, что в реальном проекте технология показывает себя совершенно по-другому
Такая мысль была, но тогда сильно больше бы прошло времени до попытки запуска первого A/B-теста, а продуктовые изменения только росли и приходилось бы их поддерживать, что еще дальше оттягивало момент переключения на отрефакторенный код. Поэтому и выбрал вариант делать итеративно по частям. К сожалению, с ним тоже возникли проблемы, как описывал выше, поэтому для последующих работ подход решили поменять. Пока не ясно насколько это хорошее решение, но надеюсь, что закончим быстрее, чем за полтора года
У нас сейчас тоже стоит инициализация аналитики gtm на onload. Сам не замерял насколько сильно оно влияет на производительность, но, видимо, стоит обратить внимание. Спасибо за наводку
Вполне можно, с этим не спорю. Но согласитесь, есть разница между тем, чтобы сразу делать нетормозящее приложение на React, и рефакторить существующий код (у которого есть определенные проблемы с перфомансом), переводя его на React, и при этом не потерять в производительности. Я как раз и рассказываю в своей статье о том, что походу рефакторинга было важным не потерять в производительности от текущего состояния и старался по возможности его улучшать. Да и в целом, кнопки контактов, о которых рассказываю, только вершина айсберга, так как план переписать всю страницу объявления на React, избавившись от легаси решений, которые ухудшают перфоманс
К сожалению, показатели некоторых страниц действительно не настолько хороши, как хотелось бы. Планы по улучшению перфоманса есть, занимаемся ими по мере возможности
Так как появление в поисковой выдаче гугла - это один из способов привлечения траффика на сайт (в данном случае внешнего траффика), то нам важно обращать внимание на метрики, благодаря которым удасться улучшить позиции в выдаче. Поэтому мы стараемся внимательно относиться к метрикам производительности.
Rush выглядит интересным решением. Когда только обсуждали решение о внедрении Lerna, Rush не рассматривали. Сейчас выглядит так, что то, что решает наш скрипт для поднятия версий, уже решено в Rush. Сам не пользовался этим инструментом, но он выглядит интересным
Если я правильно понял, то Bazel — это инструмент для синхронизации и сборки проектов, и работает Bazel в основном как раз с собранными проектом. Сборка проектов в нашем репозитории идет от внутреннего инструмента для бойлерплейтинга (вот здесь можно подробнее о нем узнать ) и этот инструмент учитывает особенности сборки основного монолита. Поэтому нам нужен был инструмент только для синхронизации версий. Lerna работает таким образом, что зависимости внешние могут быть вынесены на корневой уровень монорепозитория, а внутренние зависимости связаны через ссылки. Благодаря такому механизму нам удалось в какой-то момент избавиться от package-lock файлов в наших пакетах, оставив только один lock файл в корне. Плюс, кроме синхронизации, Lerna позволяет автоматизировать работу именно с изменением версий пакетов. Так, к примеру, с помощью двух команд можно узнать какие пакеты были изменены, где и как необходимо изменить версии (поднять патч, минорную или мажорную версию), а затем опубликовать пакеты. И в данном случае синхронизация позволила решить проблему построения явного дерева зависимостей, которое может быть автоматически измененно, а автоматизация упростила работу с монорепозитрием, сведя до работы с небольшим набором команд. Если я правильно понимаю, то в Bazel нет механизма для автоматизации работы именно с версиями пакетов. Кроме того, отмечу что наш монорепозитрой нужен для разработки без сборки, так как пакеты из него еще нужны в основной кодовой базе монолита, в которой настроена и работает своя сборка проекта.
В случае, если кто-то сломал тест или код, то, согласно соседскому соглашению, он его и чинит. У нас эта практика распространяется не только наш монореопзиторий, но и на другие проекты. Плюс, в случае монорепозитория CI настроен таким образом, что без прохождения всех тестов, смержить пул-реквест не получится. Если есть вопросы о том, каким образом лучше внести правки, то разработчик, который лучше разбирается, может помочь, но сами исправления все равно остаются на том, кто сломал.