Что дело наживное согласен, если человек подходит по всем остальным параметрам, то это точно не блокер, дообучить sql можно без проблем, тут скорее когда все остальное одинаково с другим кандидатом то будет фактором решающим, но такое бывает не всегда
Грустно что остался такой фидбэк! Но зачастую стажировки проходят достаточно комфортно, сам проходил стажировку и беру стажеров к себе в команду.
По пунктам. на все ответ один, если есть потребность в определенных навыках то будут разные способы проверить их. и да иногда нужно тестовое, в статье подчеркнул когда это применимо и да нужны ситуационные вопросы, важно чтобы с человеком было комфортно работать и конечно если человек не имеет навыков работы с определенным инструментом, а кто то умеет и в остальном все одинаково, сам подумай какой бы выбор сделал ты?
Не могу отвечать за остальных собеседующих, тут изложил свой опыт и видение, но Яндекс большей и бывает по разному, надеюсь, в том числе и этой статьей будет возможно поднять культуру собеседований в том числе и внутри Яндекса
Спасибо, за интерес, но тут в 2 словах не расскажешь, тут в пору отдельную статью делать. Если прям кратко, используем фреймворк gemini, который является надстройкой над селениумом и юзает те же методы, тесты пишутся на js. Сравниваются 2 скриншота элемента продакшн среды и релиз кандидата. Если есть отличие при наложении они подсвечиваются. Очень удобно для тестирования юая. На счёт мобилок, мы используем только для мобильной версии маркета, в разных разрешениях, которые настраиваются в канфиге. В приложении не используется скринтестинг, пока что.
Откладывать нет, не приходилось, если падает несколько тестов мы их можем руками перепрогнать и понять связано с задачей или нет, а вот если массово тесты падают, то тут другое дело, и это может затянуть релиз. Обычно получается, как раз, что идет сначала базовая, а потом все остальные, но это скорее не умышленно происходит.
Ими занимаются если они падают по причине изменений в задаче, обычно они зелёные, но бывают что падают по не зависящим от тестируемого функционала причинам и в таком случае мы их оставляем.
Конечно, если падения вызваны багом их правят до релиза. Но иногда падения вызваны нестабильностью бэков/учениями итд. и в таком случае, просмотрев глазами падения, задерживать релиз нецелесообразно
Да не менее 5 релизов в неделю.
Не все тесты замоканы, по возможности отлавливаем и мокаем, из за разных обстоятельств попадают в релиз(нестабильность бэков/учения итд). Падения тестов разбирает, да, тестировщик и далее уже отдаёт програмисту конкретные задачи на починку.
Раз в неделю примерно гоняем полный регресс, занимает около 4 часов.
Спасибо за ваш комментарий.
Рад быть полезным!) спасибо)
Во во +- я также раньше думал, пока не начал погружаться в тему, а там такая кроличья нора...
Привет! Для менеджеров, например, большая часть точно является хардами, для тех. специалиста уровня ниже Лида, скорее нет.
Блин, интересный вопрос, а как бы ты хотел час на твои вопросы и 10 минут на вопросы от компании? в чем смысл?)
Что дело наживное согласен, если человек подходит по всем остальным параметрам, то это точно не блокер, дообучить sql можно без проблем, тут скорее когда все остальное одинаково с другим кандидатом то будет фактором решающим, но такое бывает не всегда
Грустно что остался такой фидбэк!
Но зачастую стажировки проходят достаточно комфортно, сам проходил стажировку и беру стажеров к себе в команду.
По пунктам.
на все ответ один, если есть потребность в определенных навыках то будут разные способы проверить их.
и да иногда нужно тестовое, в статье подчеркнул когда это применимо
и да нужны ситуационные вопросы, важно чтобы с человеком было комфортно работать
и конечно если человек не имеет навыков работы с определенным инструментом, а кто то умеет и в остальном все одинаково, сам подумай какой бы выбор сделал ты?
Привет, в боте можно выбрать матрицу и скачать ее
Не могу отвечать за остальных собеседующих, тут изложил свой опыт и видение, но Яндекс большей и бывает по разному, надеюсь, в том числе и этой статьей будет возможно поднять культуру собеседований в том числе и внутри Яндекса
Спасибо, за интерес, но тут в 2 словах не расскажешь, тут в пору отдельную статью делать. Если прям кратко, используем фреймворк gemini, который является надстройкой над селениумом и юзает те же методы, тесты пишутся на js. Сравниваются 2 скриншота элемента продакшн среды и релиз кандидата. Если есть отличие при наложении они подсвечиваются. Очень удобно для тестирования юая. На счёт мобилок, мы используем только для мобильной версии маркета, в разных разрешениях, которые настраиваются в канфиге. В приложении не используется скринтестинг, пока что.
Не все тесты замоканы, по возможности отлавливаем и мокаем, из за разных обстоятельств попадают в релиз(нестабильность бэков/учения итд). Падения тестов разбирает, да, тестировщик и далее уже отдаёт програмисту конкретные задачи на починку.
Раз в неделю примерно гоняем полный регресс, занимает около 4 часов.
Спасибо за ваш комментарий.