Сразу уточню, что это мой субъективный опыт, основанный на личных наблюдениях и аналитике
Скорее, просто хотел поделиться опытом) В начале статьи сразу уточнил, что это мой личный взгляд, основанный на наблюдениях и анализе, и постарался выделить из этого конкретные рекомендации.
В комментариях люди рассказывают, как у них было, это в целом интересно всегда послушать
Да, такое встречается. Бывает, что люди годами сидят на одном месте, не развиваясь, просто найдя "теплое местечко". Видели, знаем)
Но количество лет в резюме — это скорее входной билет на собеседование, а реальный уровень кандидата выясняется уже в процессе. Может, человек действительно просто "отсидел" эти годы, а может, наоборот, быстро рос и развивался, тут не угадаешь
И тут же есть обратная проблема — когда реально толковый специалист не может даже попасть на собеседование, потому что у компании фильтр "от 3 лет опыта", и никто не смотрит на реальные навыки. В итоге все упирается не столько в стаж, сколько в подход компании к найму и в сам процесс собеседования, короче всем не угодишь)
А если серьезно, то в этом пункте речь идет не о том, что отсутствие вопросов — это автоматический провал. Конечно, если кандидат уверенно ответил на все вопросы, показал себя с хорошей стороны и в конце просто сказал: "Нет, у меня нет вопросов", — в этом нет ничего страшного.
Но если кандидат явно провалил техническую часть, не смог ответить на базовые вопросы, "плавал" по всем темам (тут именно про таких кандидатов идет речь), а в конце не задал ни одного вопроса, это выглядит странно. В такие моменты действительно стоит задуматься: а все ли прошло так, как хотелось? Это точно ок? Может быть, стоило бы хотя бы спросить у интервьюеров, что пошло не так, и получить обратную связь?
Этот пункт был именно об этом — о ситуациях, когда кандидат явно провалился, но при этом не делает ничего, чтобы извлечь из этого пользу. Да, иногда стоит проявить инициативу и выяснить, где были ошибки, чтобы не повторять их в будущем)
Да, согласен, к вакансиям тоже есть вопросы, про это и писал в статье, ЗП как у джуна, требования, как у миддла, опыт 5+ лет, с технологиями, которые только пару лет назад стали ходовые
Также мне кажется, что к накрутке опыта приводят неадекватные требования рекрутеров и работодателей. Когда хороший и толковый кандидат не может попасть на собеседование только потому, что у него 2 года и 7 месяцев опыта, а на вакансию требуется 3 года. Тут, наверное, стоит сделать отдельный разговор о неадекватных вакансиях, когда работодатели хотят нанять мидла+ с зарплатой джуна и требованием 3 года опыта. Не знаю, на что они рассчитывают, возможно, на низкую самооценку кандидата.
Вы подняли несколько очень важных моментов, которые стоит обсудить.
По поводу противоречий. Возможно, на первый взгляд, мои советы могут показаться взаимоисключающими, но на деле это скорее разные подходы в зависимости от контекста.
Про "Не врите" и "не лейте воду" — это в первую очередь касается ситуаций, когда кандидат сознательно искажает свою компетенцию. Когда человек заявляет, что знает что-то, в чем на самом деле не разбирается, это, по сути, обман. Но тут важно отличать честное признание незнания от того, чтобы начать выдавать непроверенные, но уверенные в себе ответы, пытаясь произвести впечатление. Это, на мой взгляд, не честно и часто выглядит неубедительно.
Про 10-15 минут подготовки — тут еще интереснее. Уже попадались кандидаты, которые на вопрос, был ли у них опыт с технологией X, отвечают: "Да, был". Но когда начинаю задавать уточняющие вопросы: "Что делали?", "Какие сферы применения?", кандидаты затрудняются ответить, начинаются невнятные ответы, и в итоге идет полный слив. Почему так происходит? Все дело в тех же "советчиках" для собеседований, которые рекомендуют: если спросили про технологию X — скажи, что знаешь, и авось прокатит и дальше спрашивать не будут. А знаете почему так? А потому что оно работает! Есть ведь реально много собеседующих, которые после вопроса "А вы знаете технологию X?" и ответа "Да" (самое главное уверенно, еще брови нахмурить, как будто приготовился отвечать), дальше спрашивать уже не будут. Так вот моя рекомендация: либо реально разобраться в технологии и честно сказать, что да, читал, изучал и знаю это и это, либо сказать: "Нет, не знаю, но если потребуется, загуглю и разберусь". А не выдумывать, не придумывать и не пытаться выдавить из себя знания, которых нет.
И я даже специально уточнил, чтобы это не было пустым звуком
И правда разберитесь — это как минимум полезно для общего развития.
Согласен с вами, но вы описываете классику былого времени, когда курсы по IT еще не были вездесущи, а каждый второй работяга не стремился вкатиться в айтишечку, дабы откусить побольше
Сейчас, как показывает практика, все обстоит немного иначе, есть вакансия, есть кандидат, у которого написано, 6 лет опыта в сфере X, но если разложить и капнуть, то получаем 2 года опыта в сфере X и 4 года придуманного опыта в сфере X. Да, стоит отметить, что всегда были неадекватные работодатели и неадекватные работники, мне кажется не важно какое это было время)
Мне тоже не весело от таких собесов, именно поэтому в последнее время я вообще попросил, чтобы мне их ставили по минимуму
Ну уже молчу, про конторы, которые помогают пройти собес, про скрытые наушники и прочую тему, короче лучше туда не погружаться, а то вдруг выяснится, что чей-то, а может быть ваш/мой коллега именно так на работу и попал
Да, история интересная, особенно когда эйчар еще начинает спорить с тобой по техническим вопросам, просто потому что в бумажечке так написано) И тут уже скорее вопросы к таким эйчарам, зачем они спорят с кандидатами в вопросах, в которых не компетентны, да и в принципе зачем спорить - да-да/нет-нет)
Как будто задача рекрутера задать вопросы с одной бумажечки и перписать ее на другую, и показать это уже тем спецам, которые шарят
Да, вы правы, возможно скрининг это не серебряная пуля, но суть статьи не в этом) Такой скрининг позволяет отсеить совсем невдупленышей и неадекватов
Я тоже технарь и как будто технарь/не технарь, проходить скрининг или нет, это выбор каждого. Проходил скрининги и не раз, и даже в очень крупные компании, где спрашивают "по листочку" с каменным лицом, что-то в формате "100 самых популярных вопросов из гугла на профессию X". По такой логике можно при любом не понравившемся тебе вопросе/процессе разворачивать любую контору, потому что ты технарь) Как бы тут дело каждого
Как минимум стоит попробовать запросить обратную связь, например, в моем случае это вообще обязалово, дать рекомендации кандидату, после собеседования. Прям конкретно, какие технологии подтянуть, над чем поработать и прочее
Также встречал ситуации, когда кандидата вообще не зовут на собес, даже с HR, но это уж совсем для новичков, помогает спросить, в чем причина. И я был сильно удивлен, что причины иногда отличаются от тех, которые кандидат сам себе додумал/предположил/придумал
В данном случае скрининг перед собеседованием скорее вынужденная мера, иначе приходят совсем слабые кандидаты, не исключаю, что они только после курсов, с полностью нарисованным опытом
Так хотя бы попадаются кандидаты с реальным опытом, но по его объему есть вопросы)
Уже есть такое для поддержки, разрабатывается отдельной командой бэкофиса
Важно не путать QA Admin с бэкофисом. Это принципиально разные инструменты:
Бэкофис доступен на продакшене, требует авторизации и соблюдения прав доступа.
QA Admin — исключительно тестовый сервис, который не используется на продакшене. Он позволяет выполнять «незаконные» операции (например, пополнения на миллионы долларов) для тестирования.
Предположу имеется в виду что-то типа - "отклик системы", "количество запросов в секунду", "количество пользователей". Вот потому и возникло дополнение
Да, именно это и имелось ввиду) Возможно термин SLA тут был не уместен, можно было просто написать "требования". Тут скорее локальное употребление этого термина, возможно знаете ситуации, когда все в команде/компании используют термин, никто не знает его точно определение, но все понимают о чем вы)
Это маловато для анализа результатов. А использовать среднее анализа рискованно . Среднее значение сильно подвержено выбросам. К тому, же например среднее время отклика СУБД в принципе не может быть использовано для оценки производительности СУБД .
Поэтому и возник вопрос - "Проводится ли статистическая обработка результатов? " - может я невнимательно прочитал, пропустил что-то .
Результаты сравниваются с желаемыми требованиями, я писал про это в разделе Results про сравнения
Сравнение текущего результата с SLA. Тут все предельно просто, данный параметр показывает отклонение от заданных в сценарии SLA. Позже рассмотрим, как задаются SLA для сценария. Данный параметр статичен, в отличие от предыдущих и средних значений. Например, сервис начал деградировать и с каждым новым релизом среднее и предыдущие значения будут только ухудшаться, но SLA останутся теми же, что позволит нам объективно оценивать производительность
Вы правильно заметили, более глубокого анализа пока не делается, но думаю над этим точно стоит подумать)
Вот эти примеры , с конкретными цифрами - очень интересны
Мы работаем над банковским приложением, конкретно моя команда занимается отображением виджетов на главной странице и лентой операций, а это самая высоко нагруженная часть в мобильном приложении. Если будут проблемы с загрузокой аккаунтов, кешбэков, подписок, операций, рассрочек, то приложением невозможно будет пользоваться, поэтому стабильность наших микросервисов очень критична
Наш продукт пока активно растет и развивается, но на проде уже нагрузка доходит до 20-30 RPS в обычные дни, 130-150 RPS в пики, это происходит в начале месяца при выборе категорий кешбэка, при каких-либо акциях, либо рекламных кампаниях. Сейчас мы нагружаем наши сервисы, с нагрузкой ~ X10 от продовской в пике. Также есть заранее созданные данные - операции, которых на текущий момент ~60KK, это в 3-4 раза больше чем на проде, то есть мы грузим не пустую базу данных
Также задача нагрузки у нас очень не тривиальная, т.к. наша команда интегрируется с огромным количеством внешних сервисов, примерно 30 внешних сервисов. Все это нужно мокать, при этом имитировать время ответа внешнего сервиса
Ну и собственно весь процесс нагрузочного тестирования автоматизирован и в этой статье я, как раз рассказывал про сервис, который аггрегирует всю информацию касаемо результатов НТ и визуализирует информацию команде
Да, все верно! Чтобы сервис load-testing-hub работал, нужно на своем сервере/кластере/виртуальной машине/в облаке раздеплоить API часть load-testing-hub-api и UI часть load-testing-hub-panel
Под термином SLA в статье подразумеваются требования к системе, например, в моем случае это RPS X10 от RPS-са на продакшене
Не совсем понял вопрос, можете, пожалуйста, подробнее описать, что имеется ввиду?
В статье приведен пример из жизни, автоматизация НТ и применение самого сервиса аналитики, данный процесс работает сейчас на реальном проекте, просто я не вдавался в продуктовые/командные подробности. Если вы подразумевали это, то я могу накинуть больше контекста
Структура статьи, подход, библиотеки, концепция, даже названия некоторых папок, функций и модулей слизаны с этой статьи https://habr.com/ru/articles/709380/
Рекомендую в следующий раз хотя бы указывать ссылки на ресурсы, которыми пользуешься для написания статьи
Привет! Из какой директории запускаешь команду allure serve? Проверь есть ли в директории, из которой запускаешь команду allure serve папка allure-results. Скорее всего папка allure-results была создана тут
По сути BaseFixture это просто интерфейс, который описывает встроенные фикстуры в playwright и используется для описания правильной типизации объекта фикстуры. Чтобы typescript правильно воспринял тип Fixturesиз playwright нам необходимо передать в него типы тех фикстур, которые мы используем или от которых наследуемся Fixtures<ContextPagesFixture, BaseFixture> .
В этой фикстуре мы используем page (встроенная фикстура в playwright), если не указать BaseFixture, то typescript выдаст ошибку по типу "Property 'page' does not exist on type 'ContextPagesFixture'.ts(2339)". Чтобы это исправить мы передаем тип BaseFixture, как бы говорим typescript, смотри все ок, это известный нам аргумент
Кстати, тут я допустил ошибку, лучше использовать встроенный в playwright тип, который называется PlaywrightTestArgs внутри него есть все встроенные фикстуры по типу page, context, browser, request и т.д. Тогда бы у нас тип выглядел так Fixtures<ContextPagesFixture, PlaywrightTestArgs> + не пришлось бы писать свой тип
Скорее, просто хотел поделиться опытом) В начале статьи сразу уточнил, что это мой личный взгляд, основанный на наблюдениях и анализе, и постарался выделить из этого конкретные рекомендации.
В комментариях люди рассказывают, как у них было, это в целом интересно всегда послушать
Да, такое встречается. Бывает, что люди годами сидят на одном месте, не развиваясь, просто найдя "теплое местечко". Видели, знаем)
Но количество лет в резюме — это скорее входной билет на собеседование, а реальный уровень кандидата выясняется уже в процессе. Может, человек действительно просто "отсидел" эти годы, а может, наоборот, быстро рос и развивался, тут не угадаешь
И тут же есть обратная проблема — когда реально толковый специалист не может даже попасть на собеседование, потому что у компании фильтр "от 3 лет опыта", и никто не смотрит на реальные навыки. В итоге все упирается не столько в стаж, сколько в подход компании к найму и в сам процесс собеседования, короче всем не угодишь)
Да, действительно! Как он посмел!
А если серьезно, то в этом пункте речь идет не о том, что отсутствие вопросов — это автоматический провал. Конечно, если кандидат уверенно ответил на все вопросы, показал себя с хорошей стороны и в конце просто сказал: "Нет, у меня нет вопросов", — в этом нет ничего страшного.
Но если кандидат явно провалил техническую часть, не смог ответить на базовые вопросы, "плавал" по всем темам (тут именно про таких кандидатов идет речь), а в конце не задал ни одного вопроса, это выглядит странно. В такие моменты действительно стоит задуматься: а все ли прошло так, как хотелось? Это точно ок? Может быть, стоило бы хотя бы спросить у интервьюеров, что пошло не так, и получить обратную связь?
Этот пункт был именно об этом — о ситуациях, когда кандидат явно провалился, но при этом не делает ничего, чтобы извлечь из этого пользу. Да, иногда стоит проявить инициативу и выяснить, где были ошибки, чтобы не повторять их в будущем)
Да, согласен, к вакансиям тоже есть вопросы, про это и писал в статье, ЗП как у джуна, требования, как у миддла, опыт 5+ лет, с технологиями, которые только пару лет назад стали ходовые
Вы подняли несколько очень важных моментов, которые стоит обсудить.
По поводу противоречий. Возможно, на первый взгляд, мои советы могут показаться взаимоисключающими, но на деле это скорее разные подходы в зависимости от контекста.
Про "Не врите" и "не лейте воду" — это в первую очередь касается ситуаций, когда кандидат сознательно искажает свою компетенцию. Когда человек заявляет, что знает что-то, в чем на самом деле не разбирается, это, по сути, обман. Но тут важно отличать честное признание незнания от того, чтобы начать выдавать непроверенные, но уверенные в себе ответы, пытаясь произвести впечатление. Это, на мой взгляд, не честно и часто выглядит неубедительно.
Про 10-15 минут подготовки — тут еще интереснее. Уже попадались кандидаты, которые на вопрос, был ли у них опыт с технологией X, отвечают: "Да, был". Но когда начинаю задавать уточняющие вопросы: "Что делали?", "Какие сферы применения?", кандидаты затрудняются ответить, начинаются невнятные ответы, и в итоге идет полный слив. Почему так происходит? Все дело в тех же "советчиках" для собеседований, которые рекомендуют: если спросили про технологию X — скажи, что знаешь, и авось прокатит и дальше спрашивать не будут. А знаете почему так? А потому что оно работает! Есть ведь реально много собеседующих, которые после вопроса "А вы знаете технологию X?" и ответа "Да" (самое главное уверенно, еще брови нахмурить, как будто приготовился отвечать), дальше спрашивать уже не будут. Так вот моя рекомендация: либо реально разобраться в технологии и честно сказать, что да, читал, изучал и знаю это и это, либо сказать: "Нет, не знаю, но если потребуется, загуглю и разберусь". А не выдумывать, не придумывать и не пытаться выдавить из себя знания, которых нет.
И я даже специально уточнил, чтобы это не было пустым звуком
Согласен с вами, но вы описываете классику былого времени, когда курсы по IT еще не были вездесущи, а каждый второй работяга не стремился вкатиться в айтишечку, дабы откусить побольше
Сейчас, как показывает практика, все обстоит немного иначе, есть вакансия, есть кандидат, у которого написано, 6 лет опыта в сфере X, но если разложить и капнуть, то получаем 2 года опыта в сфере X и 4 года придуманного опыта в сфере X. Да, стоит отметить, что всегда были неадекватные работодатели и неадекватные работники, мне кажется не важно какое это было время)
Мне тоже не весело от таких собесов, именно поэтому в последнее время я вообще попросил, чтобы мне их ставили по минимуму
Ну уже молчу, про конторы, которые помогают пройти собес, про скрытые наушники и прочую тему, короче лучше туда не погружаться, а то вдруг выяснится, что чей-то, а может быть ваш/мой коллега именно так на работу и попал
Да, история интересная, особенно когда эйчар еще начинает спорить с тобой по техническим вопросам, просто потому что в бумажечке так написано) И тут уже скорее вопросы к таким эйчарам, зачем они спорят с кандидатами в вопросах, в которых не компетентны, да и в принципе зачем спорить - да-да/нет-нет)
Как будто задача рекрутера задать вопросы с одной бумажечки и перписать ее на другую, и показать это уже тем спецам, которые шарят
Да, вы правы, возможно скрининг это не серебряная пуля, но суть статьи не в этом) Такой скрининг позволяет отсеить совсем невдупленышей и неадекватов
Я тоже технарь и как будто технарь/не технарь, проходить скрининг или нет, это выбор каждого. Проходил скрининги и не раз, и даже в очень крупные компании, где спрашивают "по листочку" с каменным лицом, что-то в формате "100 самых популярных вопросов из гугла на профессию X". По такой логике можно при любом не понравившемся тебе вопросе/процессе разворачивать любую контору, потому что ты технарь) Как бы тут дело каждого
Как минимум стоит попробовать запросить обратную связь, например, в моем случае это вообще обязалово, дать рекомендации кандидату, после собеседования. Прям конкретно, какие технологии подтянуть, над чем поработать и прочее
Также встречал ситуации, когда кандидата вообще не зовут на собес, даже с HR, но это уж совсем для новичков, помогает спросить, в чем причина. И я был сильно удивлен, что причины иногда отличаются от тех, которые кандидат сам себе додумал/предположил/придумал
В данном случае скрининг перед собеседованием скорее вынужденная мера, иначе приходят совсем слабые кандидаты, не исключаю, что они только после курсов, с полностью нарисованным опытом
Так хотя бы попадаются кандидаты с реальным опытом, но по его объему есть вопросы)
Уже есть такое для поддержки, разрабатывается отдельной командой бэкофиса
Эти докер образы предназначены для кубера, как запустить локально я описал в ридмишках
https://github.com/Nikita-Filonov/load-testing-hub-panel/blob/main/README.md
https://github.com/Nikita-Filonov/load-testing-hub-api/blob/main/README.md
Базу постгреса соотвественно нужно будет поднять либо локально, либо в докере, как вам удобно
Рад, что материал оказался полезен!
Да, именно это и имелось ввиду) Возможно термин SLA тут был не уместен, можно было просто написать "требования". Тут скорее локальное употребление этого термина, возможно знаете ситуации, когда все в команде/компании используют термин, никто не знает его точно определение, но все понимают о чем вы)
Результаты сравниваются с желаемыми требованиями, я писал про это в разделе Results про сравнения
Вы правильно заметили, более глубокого анализа пока не делается, но думаю над этим точно стоит подумать)
Мы работаем над банковским приложением, конкретно моя команда занимается отображением виджетов на главной странице и лентой операций, а это самая высоко нагруженная часть в мобильном приложении. Если будут проблемы с загрузокой аккаунтов, кешбэков, подписок, операций, рассрочек, то приложением невозможно будет пользоваться, поэтому стабильность наших микросервисов очень критична
Наш продукт пока активно растет и развивается, но на проде уже нагрузка доходит до 20-30 RPS в обычные дни, 130-150 RPS в пики, это происходит в начале месяца при выборе категорий кешбэка, при каких-либо акциях, либо рекламных кампаниях. Сейчас мы нагружаем наши сервисы, с нагрузкой ~ X10 от продовской в пике. Также есть заранее созданные данные - операции, которых на текущий момент ~60KK, это в 3-4 раза больше чем на проде, то есть мы грузим не пустую базу данных
Также задача нагрузки у нас очень не тривиальная, т.к. наша команда интегрируется с огромным количеством внешних сервисов, примерно 30 внешних сервисов. Все это нужно мокать, при этом имитировать время ответа внешнего сервиса
Ну и собственно весь процесс нагрузочного тестирования автоматизирован и в этой статье я, как раз рассказывал про сервис, который аггрегирует всю информацию касаемо результатов НТ и визуализирует информацию команде
Да, все верно! Чтобы сервис load-testing-hub работал, нужно на своем сервере/кластере/виртуальной машине/в облаке раздеплоить API часть load-testing-hub-api и UI часть load-testing-hub-panel
Добрый вечер! Давайте по порядку:
Под термином SLA в статье подразумеваются требования к системе, например, в моем случае это RPS X10 от RPS-са на продакшене
Не совсем понял вопрос, можете, пожалуйста, подробнее описать, что имеется ввиду?
В статье приведен пример из жизни, автоматизация НТ и применение самого сервиса аналитики, данный процесс работает сейчас на реальном проекте, просто я не вдавался в продуктовые/командные подробности. Если вы подразумевали это, то я могу накинуть больше контекста
Структура статьи, подход, библиотеки, концепция, даже названия некоторых папок, функций и модулей слизаны с этой статьи https://habr.com/ru/articles/709380/
Рекомендую в следующий раз хотя бы указывать ссылки на ресурсы, которыми пользуешься для написания статьи
Привет! Из какой директории запускаешь команду allure serve? Проверь есть ли в директории, из которой запускаешь команду allure serve папка allure-results. Скорее всего папка allure-results была создана тут
Да, тут скорее ошибка, забыл, что у playwright это можно в playwright.config.ts вынести
Спасибо, исправил)
Спасибо, приятно это слышать!
По сути BaseFixture это просто интерфейс, который описывает встроенные фикстуры в playwright и используется для описания правильной типизации объекта фикстуры. Чтобы typescript правильно воспринял тип
Fixturesиз playwright нам необходимо передать в него типы тех фикстур, которые мы используем или от которых наследуемсяFixtures<ContextPagesFixture, BaseFixture>.В этой фикстуре мы используем page (встроенная фикстура в playwright), если не указать BaseFixture, то typescript выдаст ошибку по типу "Property 'page' does not exist on type 'ContextPagesFixture'.ts(2339)". Чтобы это исправить мы передаем тип BaseFixture, как бы говорим typescript, смотри все ок, это известный нам аргумент
Кстати, тут я допустил ошибку, лучше использовать встроенный в playwright тип, который называется PlaywrightTestArgs внутри него есть все встроенные фикстуры по типу page, context, browser, request и т.д. Тогда бы у нас тип выглядел так
Fixtures<ContextPagesFixture, PlaywrightTestArgs>+ не пришлось бы писать свой типНа счет статьи, хорошая идея, обязательно подумаю