This media is not supported in your browser
VIEW IN TELEGRAM
Опытный тестировшик решает проблему накопившихся тасок
Бэклог
Картинка с тюленями постом выше - суровая реальность работы разработчика и тестировщика. Проект растёт, ресурсов не хватает, задачи копятся.
Такое скопление задач, по которым уже сформулированы требования и которые поставлены в очередь на исполнение, называются бэклогом.
Чем меньше бэклог, тем ярче твоя жизнь- тебя любят все вокруг, ты можешь заняться своим проектом, поучиться чему-нибудь или просто лечь поспать.
Картинка с тюленями постом выше - суровая реальность работы разработчика и тестировщика. Проект растёт, ресурсов не хватает, задачи копятся.
Такое скопление задач, по которым уже сформулированы требования и которые поставлены в очередь на исполнение, называются бэклогом.
Чем меньше бэклог, тем ярче твоя жизнь- тебя любят все вокруг, ты можешь заняться своим проектом, поучиться чему-нибудь или просто лечь поспать.
Резюме
Недавно помогал подруге с разбором резюме ее ученика - он хочет найти работу в тестировании, но опыта не так много. Некоторые тезисы по разбору оставлю здесь.
1. Электронную почту лучше всего указать с формальным адресом - по типу ivan.ivanov@...
2. Непрофильные образование и опыт работы (не IT) лучше всего не указывать, либо указывать максимально лаконично - эта информация скорее всего не заинтересует IT-рекрутера и будет лишней.
4. Когда совсем мало опыта, остаётся делать акцент на стажировки, тренинги, курсы - в резюме нужно указать не только название, но и приложить ссылку на сертификат.
5. Не нужно указывать курсы, которые вы прошли на пиратских ресурсах, - это очень быстро выявляется и может перекрыть доступ сразу к нескольким крупным компаниям.
5. Hard skills лучше детализировать. Умеете работать в баг-трекинговой системе - в какой именно? Умеете проводить нефункциональное тестирование - какое именно?
6. Подгонять резюме под вакансию не нужно - требования в вакансии нужно учесть при составлении резюме, но не более.
Да, кстати, в этом посте есть небольшой «баг». Нашли?
Недавно помогал подруге с разбором резюме ее ученика - он хочет найти работу в тестировании, но опыта не так много. Некоторые тезисы по разбору оставлю здесь.
1. Электронную почту лучше всего указать с формальным адресом - по типу ivan.ivanov@...
2. Непрофильные образование и опыт работы (не IT) лучше всего не указывать, либо указывать максимально лаконично - эта информация скорее всего не заинтересует IT-рекрутера и будет лишней.
4. Когда совсем мало опыта, остаётся делать акцент на стажировки, тренинги, курсы - в резюме нужно указать не только название, но и приложить ссылку на сертификат.
5. Не нужно указывать курсы, которые вы прошли на пиратских ресурсах, - это очень быстро выявляется и может перекрыть доступ сразу к нескольким крупным компаниям.
5. Hard skills лучше детализировать. Умеете работать в баг-трекинговой системе - в какой именно? Умеете проводить нефункциональное тестирование - какое именно?
6. Подгонять резюме под вакансию не нужно - требования в вакансии нужно учесть при составлении резюме, но не более.
Да, кстати, в этом посте есть небольшой «баг». Нашли?
Новый год
Знаете, какому виду тестирования отводится особая роль в предпраздничные дни? Все верно, нагрузочному (load testing).
Для проведения такого тестирования нужны более узкие специалисты и инструменты (например, Apache JMeter, HP LoadRunner и т.п.).
В пиковые дни (праздники, акции) нагрузка на серверы в несколько раз (бывает, что и в десятки и сотни раз) превышает среднюю нагрузку. Если не оптимизировать приложение и инфраструктуру, то серверы скорее всего перестанут успевать обрабатывать запросы и прилягут на какое-то время.
Для имитации нагрузки тестировщики придумывают различные нагрузочные профили, которые отличаются, в основном, по времени и по количеству потоков.
Знаете, какому виду тестирования отводится особая роль в предпраздничные дни? Все верно, нагрузочному (load testing).
Для проведения такого тестирования нужны более узкие специалисты и инструменты (например, Apache JMeter, HP LoadRunner и т.п.).
В пиковые дни (праздники, акции) нагрузка на серверы в несколько раз (бывает, что и в десятки и сотни раз) превышает среднюю нагрузку. Если не оптимизировать приложение и инфраструктуру, то серверы скорее всего перестанут успевать обрабатывать запросы и прилягут на какое-то время.
Для имитации нагрузки тестировщики придумывают различные нагрузочные профили, которые отличаются, в основном, по времени и по количеству потоков.
#Ролевыеигры
DevOps
Честно, я в восторге от наших девопсеров. Их работа часто невидима и неосязаема, но в этом и фишка - на них держится автоматизация CI/CD-процессов, мониторинг продуктивной среды, поддержка разработчиков и тестировщиков.
Если бы у нас их не было в команде - мы бы погрязли в рутине.
Внедрение автодеплоя (автоматизированной установки приложения на сервер) на моем проекте - во многом результат моей лени и большого желания автоматизировать процесс и двух девопсеров с их желанием помочь - до этого мне приходилось делать всё вручную.
Что значит деплоить вручную, спросите вы. Это значит, что один и тот же набор операций нужно будет монотонно сделать на всех нодах приложения и, разумеется, где-то забыть поменять конфиги, где-то поставить не ту сборку, где-то не прокатить скрипт. А потом полдня разгребать, почему тестовый стенд не работает. Я, конечно, утрирую, но плюс/минус такие ситуации случались.
По моим оценкам после внедрения автодеплоя влияние человеческого фактора на проекте снизилось на 80%, трудозатраты на деплой тоже снизились, процентов на 60%.
В итоге каким бы ленивым я ни был, но автодеплой вынудил прокачать некоторые скиллы - мы стали юзать git, Ansible, научились немного настраивать плейбуки и работать с YAML-форматом. Вот такие дела.
DevOps
Честно, я в восторге от наших девопсеров. Их работа часто невидима и неосязаема, но в этом и фишка - на них держится автоматизация CI/CD-процессов, мониторинг продуктивной среды, поддержка разработчиков и тестировщиков.
Если бы у нас их не было в команде - мы бы погрязли в рутине.
Внедрение автодеплоя (автоматизированной установки приложения на сервер) на моем проекте - во многом результат моей лени и большого желания автоматизировать процесс и двух девопсеров с их желанием помочь - до этого мне приходилось делать всё вручную.
Что значит деплоить вручную, спросите вы. Это значит, что один и тот же набор операций нужно будет монотонно сделать на всех нодах приложения и, разумеется, где-то забыть поменять конфиги, где-то поставить не ту сборку, где-то не прокатить скрипт. А потом полдня разгребать, почему тестовый стенд не работает. Я, конечно, утрирую, но плюс/минус такие ситуации случались.
По моим оценкам после внедрения автодеплоя влияние человеческого фактора на проекте снизилось на 80%, трудозатраты на деплой тоже снизились, процентов на 60%.
В итоге каким бы ленивым я ни был, но автодеплой вынудил прокачать некоторые скиллы - мы стали юзать git, Ansible, научились немного настраивать плейбуки и работать с YAML-форматом. Вот такие дела.
С наступившим Новым годом, ребятки! Пусть бэклог уменьшается, баги своевременно находятся, а собеседования проходятся!
Очень скоро допишу для вас пост про работу в Германии: какие условия, требования к квалификации и к знанию языка.
Подписывайтесь сами и расскажите кому-нибудь из друзей о канале - это будет лучшим подарком мне на Новый год🙃
Очень скоро допишу для вас пост про работу в Германии: какие условия, требования к квалификации и к знанию языка.
Подписывайтесь сами и расскажите кому-нибудь из друзей о канале - это будет лучшим подарком мне на Новый год🙃
Какой будет зарплата, если ты решил переехать в Германию?
В минувшие праздники я побывал в Гамбурге и Берлине и заодно выяснил, что же ждёт тестировщиков там.
Вообще, зарплата у IT-сотрудников в Германии несильно отличается от зарплат специалистов другого профиля - учителей, юристов, аудиторов, финансистов. Многие инженеры и врачи здесь будут получать даже побольше, чем айтишники.
По требованиям все достаточно уютно: из всех вакансий, которые я просмотрел, только в одном месте, к примеру, потребовалась сертификация ISTQB FL. Инструменты для тестирования - фактически те же, что и указаны в большинстве наших вакансий. Заметил, что тестировщики требуются для многих индустриальных компаний, соответственно, требуются знания на стыке технологий - из машиностроения, робототехники.
Основное препятствие - знание языка. Немецкий нужен не менее B2, чаще - C1. Английский - Intermediate, Upper-intermediate. Часто команды интернациональные и рабочий язык английский, даже если большинство сотрудников в команде - немцы.
Зарплата - пожалуй, самая больная тема из-за больших налогов. В Германии существуют налоговые классы, в зависимости от которых меняется налоговая ставка. Например, если ты приехал в Германию один, без семьи и детей - налог будет одной величины, если приехал с семьей - налог уже будет поменьше. В вакансиях поэтому часто указывается годовая(!) зарплата брутто, до вычета налога. Для примерного расчёта налога есть куча онлайн-калькуляторов, которые учитывают налоговые классы.
По моим очень усреднённым подсчетам джун-тестировщик будет получать около 2000-2500€ в месяц на руки. Автотестеры - 3000-3500€ на руки. Понятное дело, везде есть свои исключения.
В минувшие праздники я побывал в Гамбурге и Берлине и заодно выяснил, что же ждёт тестировщиков там.
Вообще, зарплата у IT-сотрудников в Германии несильно отличается от зарплат специалистов другого профиля - учителей, юристов, аудиторов, финансистов. Многие инженеры и врачи здесь будут получать даже побольше, чем айтишники.
По требованиям все достаточно уютно: из всех вакансий, которые я просмотрел, только в одном месте, к примеру, потребовалась сертификация ISTQB FL. Инструменты для тестирования - фактически те же, что и указаны в большинстве наших вакансий. Заметил, что тестировщики требуются для многих индустриальных компаний, соответственно, требуются знания на стыке технологий - из машиностроения, робототехники.
Основное препятствие - знание языка. Немецкий нужен не менее B2, чаще - C1. Английский - Intermediate, Upper-intermediate. Часто команды интернациональные и рабочий язык английский, даже если большинство сотрудников в команде - немцы.
Зарплата - пожалуй, самая больная тема из-за больших налогов. В Германии существуют налоговые классы, в зависимости от которых меняется налоговая ставка. Например, если ты приехал в Германию один, без семьи и детей - налог будет одной величины, если приехал с семьей - налог уже будет поменьше. В вакансиях поэтому часто указывается годовая(!) зарплата брутто, до вычета налога. Для примерного расчёта налога есть куча онлайн-калькуляторов, которые учитывают налоговые классы.
По моим очень усреднённым подсчетам джун-тестировщик будет получать около 2000-2500€ в месяц на руки. Автотестеры - 3000-3500€ на руки. Понятное дело, везде есть свои исключения.
Как улучшить продукт?
Неделя выдалась очень продуктивной: новый релиз, новые баги, а ещё внедрение новеньких Feature requests.
О фича реквестах как раз и поговорим. По сути, это запросы на улучшение приложения. Такие задачи не являются багами, а скорее пожеланиями на доработку продукта. Инициаторами могут быть пользователи, менеджеры, тестировщики, разработчики и т.п. - по сути, все заинтересованные лица. Но кому, как не тестировщикам, знать плюсы и минусы своего продукта? Где-то такие запросы поощряются руководством, где-то воспринимаются в штыки - ведь это дополнительная работа для всех. Задача тестировщика - постараться убедить руководителя, команду, менеджера или иное лицо, принимающее решение, что данная фича действительно необходима (потом она облегчит твою же работу).
Как я продвигаю свои фича реквесты?
1. Есть свободное время - изучаю продукт: анализирую, что было неудобно при последнем регрессе, какие операции оказались слишком рутинными, изучаю как реализовано у других, общаюсь с коллегами
2. Появилась идея - готовлю прототип и набрасываю начальные требования
3. Обсуждение. Общаюсь со своим руководителем, руководителем разработки
4. Если идея зашла и ее реализация существенно не бьет по бюджету проекта, то допиливаю требования
5. Готовлю feature request и жду релиз, в котором фича будет реализована.
Неделя выдалась очень продуктивной: новый релиз, новые баги, а ещё внедрение новеньких Feature requests.
О фича реквестах как раз и поговорим. По сути, это запросы на улучшение приложения. Такие задачи не являются багами, а скорее пожеланиями на доработку продукта. Инициаторами могут быть пользователи, менеджеры, тестировщики, разработчики и т.п. - по сути, все заинтересованные лица. Но кому, как не тестировщикам, знать плюсы и минусы своего продукта? Где-то такие запросы поощряются руководством, где-то воспринимаются в штыки - ведь это дополнительная работа для всех. Задача тестировщика - постараться убедить руководителя, команду, менеджера или иное лицо, принимающее решение, что данная фича действительно необходима (потом она облегчит твою же работу).
Как я продвигаю свои фича реквесты?
1. Есть свободное время - изучаю продукт: анализирую, что было неудобно при последнем регрессе, какие операции оказались слишком рутинными, изучаю как реализовано у других, общаюсь с коллегами
2. Появилась идея - готовлю прототип и набрасываю начальные требования
3. Обсуждение. Общаюсь со своим руководителем, руководителем разработки
4. Если идея зашла и ее реализация существенно не бьет по бюджету проекта, то допиливаю требования
5. Готовлю feature request и жду релиз, в котором фича будет реализована.
Профдеформация и перегорание
У многих тестеров есть одна не очень хорошая особенность: чем дольше они работают в тестировании, тем больше косяков и изъянов замечают вокруг, в том числе и за пределами работы. Это угнетает, удовольствие от самой работы проходит, и иной раз масла в огонь подливают отдельные разработчики (не все), которые в тестерах в первую очередь видят монстров, ломающих тестовые стенды. В общем, налицо выгорание, хроническая усталость и все такое.
Самое главное в такой ситуации - вовремя остыть и успокоиться. Теряешь контроль - бери отпуск. Это самый лучший вариант. Еще можно переключиться на другой продукт и другую команду, если есть такая возможность в компании.
У многих тестеров есть одна не очень хорошая особенность: чем дольше они работают в тестировании, тем больше косяков и изъянов замечают вокруг, в том числе и за пределами работы. Это угнетает, удовольствие от самой работы проходит, и иной раз масла в огонь подливают отдельные разработчики (не все), которые в тестерах в первую очередь видят монстров, ломающих тестовые стенды. В общем, налицо выгорание, хроническая усталость и все такое.
Самое главное в такой ситуации - вовремя остыть и успокоиться. Теряешь контроль - бери отпуск. Это самый лучший вариант. Еще можно переключиться на другой продукт и другую команду, если есть такая возможность в компании.
MosQA #2
Мейлрушечка провела вчера второй митап тестировщиков MosQA. Если коротко - всё было на уровне. Встреча прошла в атриуме их офиса - обычно там сотрудники играют в волейбол/баскетбол, но в этот раз отдали площадку нам - зарегалось больше 600 человек на мероприятие.
Читали хорошие доклады про автоматизацию тестирования, развитие soft skills, взаимодействие с разработчиками и не только. Новые подходы и внутренняя кухня тестеров в других компаниях - это всегда интересно. А тем, кому было скучно, дали ссылку на сайтик, который можно было попытаться поломать и набрать за это баллы.
Чуть позже выложу ссылки на материалы, а пока ловите немного фоток с митапа.
Мейлрушечка провела вчера второй митап тестировщиков MosQA. Если коротко - всё было на уровне. Встреча прошла в атриуме их офиса - обычно там сотрудники играют в волейбол/баскетбол, но в этот раз отдали площадку нам - зарегалось больше 600 человек на мероприятие.
Читали хорошие доклады про автоматизацию тестирования, развитие soft skills, взаимодействие с разработчиками и не только. Новые подходы и внутренняя кухня тестеров в других компаниях - это всегда интересно. А тем, кому было скучно, дали ссылку на сайтик, который можно было попытаться поломать и набрать за это баллы.
Чуть позже выложу ссылки на материалы, а пока ловите немного фоток с митапа.
Только хотел написать анонс про митап в Райффайзенбанке, который планировался в марте, как коллеги рассказали, что регистрацию на него прикрыли из-за короновируса и карантина. Чувствую, такими темпами все перейдут скоро на вебинары. Ну, а картинка просто в тему) Не болейте!
UPD: пока митап перенесён на апрель, подождем-с.
UPD: пока митап перенесён на апрель, подождем-с.
Документация на проекте
Нет ничего хуже для QA, если на проекте нет документации и вокруг тотальная agile обстановка с сопутствующим хаосом, изменением требований каждый час и т.п. Столько горя можно схватить - вы даже не представляете.
Но выход есть:
1) Начать писать тестовую документацию прямо сейчас, даже если вы только пришли на проект. Для этого общаемся с разработчиками, аналитиками, саппортом, девопсами, продуктовыми менеджерами - со всей командой. Общаемся и пишем.
2) Выстраивать процессы обмена информацией внутри команды. Хорошо, если есть единомышленники - продавливайте с ними свои идеи, пресекайте любые попытки вам помешать. Документация - это часть обеспечения качества. Нет документации - нет контрактов между интерфейсами, нет API, нет тест-кейсов, нет проекта.
Если первый пункт зависит целиком от вас и вашей QA-команды, то со вторым все намного сложнее. Документация разработчиков может выглядеть лишь поверхностным описанием работы приложения в Confluence, это в первом приближении разумно, так как в случае чего всегда можно посмотреть более точный источник - код. Но могут ли его посмотреть QA, другие коллеги? Далеко не всегда, да и в большинстве случаев не должны. Пусть аналитики напишут требования, а разработчики напишут, как они эти требования реализовали - они и только они владеют этой информацией.
Одновременно с этим, много документации - тоже плохо: протоколы меняются очень часто, нужно все взаимодействия отслеживать и своевременно править. Нужна золотая середина.
В общем, не буду томить: я пришёл к тому, что идеальнее и проще всего описывать процессы схемами, mind maps или UML-диаграммами. Последние - просто очень круты - схематично можно показать не только сам процесс какого-либо взаимодействия, но и хронологическую последовательность, то есть, условно, какой запрос за каким должен следовать - это безумно важно, когда к примеру тестируется бэкенд с кучей интеграций.
Напишите мне в личку - @pavelthai, как у вас построен процесс обмена информацией, какие инструменты используете, все ли делятся информацией? Независимо от того, где вы работаете - это процесс везде плюс/минус одинаковый. Самые интересные и полезные идеи опубликую в одном из ближайших постов.
Нет ничего хуже для QA, если на проекте нет документации и вокруг тотальная agile обстановка с сопутствующим хаосом, изменением требований каждый час и т.п. Столько горя можно схватить - вы даже не представляете.
Но выход есть:
1) Начать писать тестовую документацию прямо сейчас, даже если вы только пришли на проект. Для этого общаемся с разработчиками, аналитиками, саппортом, девопсами, продуктовыми менеджерами - со всей командой. Общаемся и пишем.
2) Выстраивать процессы обмена информацией внутри команды. Хорошо, если есть единомышленники - продавливайте с ними свои идеи, пресекайте любые попытки вам помешать. Документация - это часть обеспечения качества. Нет документации - нет контрактов между интерфейсами, нет API, нет тест-кейсов, нет проекта.
Если первый пункт зависит целиком от вас и вашей QA-команды, то со вторым все намного сложнее. Документация разработчиков может выглядеть лишь поверхностным описанием работы приложения в Confluence, это в первом приближении разумно, так как в случае чего всегда можно посмотреть более точный источник - код. Но могут ли его посмотреть QA, другие коллеги? Далеко не всегда, да и в большинстве случаев не должны. Пусть аналитики напишут требования, а разработчики напишут, как они эти требования реализовали - они и только они владеют этой информацией.
Одновременно с этим, много документации - тоже плохо: протоколы меняются очень часто, нужно все взаимодействия отслеживать и своевременно править. Нужна золотая середина.
В общем, не буду томить: я пришёл к тому, что идеальнее и проще всего описывать процессы схемами, mind maps или UML-диаграммами. Последние - просто очень круты - схематично можно показать не только сам процесс какого-либо взаимодействия, но и хронологическую последовательность, то есть, условно, какой запрос за каким должен следовать - это безумно важно, когда к примеру тестируется бэкенд с кучей интеграций.
Напишите мне в личку - @pavelthai, как у вас построен процесс обмена информацией, какие инструменты используете, все ли делятся информацией? Независимо от того, где вы работаете - это процесс везде плюс/минус одинаковый. Самые интересные и полезные идеи опубликую в одном из ближайших постов.
Работа в Yandex
Моя подруга Мила (работает QA Automation Engineer в одной зарубежной компании) успела до пандемии коронавируса попасть на экскурсию в Яндекс и поделилась своими впечатлениями.
Далее Мила от первого лица:
«Я сходила на экскурсию в офис Яндекса для технических специалистов (было это 26-го февраля - да, улиточка во мне не дремлет! Или как раз дремлет).
Кто может попасть на эту экскурсию? Любой технический специалист в сфере информационных технологий, который зарегистрируется на сайте https://yandex.ru/promo/on-site. Сейчас, впрочем, надо дождаться окончания периода самоизоляции. Приглашают они не всех. Как выбирают, кого позвать, а кого нет - не знаю. Меня позвали, а коллегу, который прислал мне ссылку с предложением зарегистрироваться - нет.
Что было на экскурсии? Водили по офису и показывали, как у них там хорошо. Есть кабинки, похожие на телефонные будки - в этих кабинках можно уединяться, если вдруг захотелось. Даже кресла для интровертов имеются - с высокими спинками и боковыми стенками - сядешь в такое и никто не достанет. Много разных кухонь с запасами различной еды в виде мюслей, каш, чая, печенек и еще чего-то подобного.
Офис очень зеленый, вся зелень настоящая с автоматическими поливалками.
Кстати, в самом офисе на лестничных площадках есть карты с указанием того места, где вы находитесь и всех помещений, что находятся с вами на этаже.
Приятный парень, работающий в Яндексе бэкенд-разработчиком, рассказал об условиях работы: оплачивают фитнес, занятия английским, участие в конференциях, ДМС со стоматологией с первого дня работы (насколько я помню), даже выдают деньги на покупку квартиры - на 3 года без процентов или на 10 лет под 3% годовых.
Помимо заработной платы каждому сотруднику начисляют 9700 рублей для обедов. Этими деньгами можно оплачивать обед в большинстве кафе и ресторанов, что находятся в шаговой доступности от офиса. А также каждый день на карту падает некоторая сумма до 10 утра, которую можно потратить на завтрак. Если вовремя не потратить, то деньги сгорают, конечно, потому что начисляются на пропуск, с которым сотрудники проходят в офис. Им же и производится оплата в кафе и ресторанах.
Что может быть интересно девушкам - в офисе есть комната матери и ребенка. Все сотрудники без проблем могут приводить в офис своих детей. Которым там точно будет, чем заняться.
На крыше офиса площадка для отдыха, в самом офисе - столы для игры в настольный теннис, различные зоны отдыха и все, что может понадобиться человеку.
А ещё в Яндексе дают премию своими же акциями. Но не совсем акциями, потому что вроде как они есть, но дивиденды будут начисляться только через 4 года после их получения и только если все эти 4 года работать в Яндексе. Каждый год активируется четверть полученных в виде премии акций».
Как вам условия? Хотели бы работать в Яндексе?)
Моя подруга Мила (работает QA Automation Engineer в одной зарубежной компании) успела до пандемии коронавируса попасть на экскурсию в Яндекс и поделилась своими впечатлениями.
Далее Мила от первого лица:
«Я сходила на экскурсию в офис Яндекса для технических специалистов (было это 26-го февраля - да, улиточка во мне не дремлет! Или как раз дремлет).
Кто может попасть на эту экскурсию? Любой технический специалист в сфере информационных технологий, который зарегистрируется на сайте https://yandex.ru/promo/on-site. Сейчас, впрочем, надо дождаться окончания периода самоизоляции. Приглашают они не всех. Как выбирают, кого позвать, а кого нет - не знаю. Меня позвали, а коллегу, который прислал мне ссылку с предложением зарегистрироваться - нет.
Что было на экскурсии? Водили по офису и показывали, как у них там хорошо. Есть кабинки, похожие на телефонные будки - в этих кабинках можно уединяться, если вдруг захотелось. Даже кресла для интровертов имеются - с высокими спинками и боковыми стенками - сядешь в такое и никто не достанет. Много разных кухонь с запасами различной еды в виде мюслей, каш, чая, печенек и еще чего-то подобного.
Офис очень зеленый, вся зелень настоящая с автоматическими поливалками.
Кстати, в самом офисе на лестничных площадках есть карты с указанием того места, где вы находитесь и всех помещений, что находятся с вами на этаже.
Приятный парень, работающий в Яндексе бэкенд-разработчиком, рассказал об условиях работы: оплачивают фитнес, занятия английским, участие в конференциях, ДМС со стоматологией с первого дня работы (насколько я помню), даже выдают деньги на покупку квартиры - на 3 года без процентов или на 10 лет под 3% годовых.
Помимо заработной платы каждому сотруднику начисляют 9700 рублей для обедов. Этими деньгами можно оплачивать обед в большинстве кафе и ресторанов, что находятся в шаговой доступности от офиса. А также каждый день на карту падает некоторая сумма до 10 утра, которую можно потратить на завтрак. Если вовремя не потратить, то деньги сгорают, конечно, потому что начисляются на пропуск, с которым сотрудники проходят в офис. Им же и производится оплата в кафе и ресторанах.
Что может быть интересно девушкам - в офисе есть комната матери и ребенка. Все сотрудники без проблем могут приводить в офис своих детей. Которым там точно будет, чем заняться.
На крыше офиса площадка для отдыха, в самом офисе - столы для игры в настольный теннис, различные зоны отдыха и все, что может понадобиться человеку.
А ещё в Яндексе дают премию своими же акциями. Но не совсем акциями, потому что вроде как они есть, но дивиденды будут начисляться только через 4 года после их получения и только если все эти 4 года работать в Яндексе. Каждый год активируется четверть полученных в виде премии акций».
Как вам условия? Хотели бы работать в Яндексе?)