У такого подхода, когда у вас одна сборка для обеих экосистем, есть несколько минусов, но главный из них состоит в том, что время от времени ревью-команда гугла отклоняет сборки, содержащие хуавеевские зависимости, ссылаясь на "уязвимости", "вредоносный код" и так далее. Конечно, в таких случая HMS библиотеки оперативно обновляются чтобы соответствовать представлениям гугл о безопасном коде, но некоторое количество нервов и времени это может скушать.
Все-таки хочется один артефакт — так удобнее работать, ну и можно, как и говорил в статье/видео, для пользователей HMS+GMS приоритезировать HMS для каких-либо фичей
А какие еще видите минусы / риски?
Поэтому я обычно советую не тащить в сборку те зависимости, которые там не нужны а пилить на флейворы. Единственная существенная издержка это то что надо тестировать и на GMS и на HMS устройствах (а как показал ваш опыт, то и на GMS+HMS тоже). Но на самом деле по-хорошему и ваш подход тоже необходимо тестировать и там и там, я даже не особо верю, что вы этого не делаете.
У нас только смоук делается (и то не всегда), основные проверки автоматизированы. Да, для HMS-фичей они не гоняются, так как эмуляторы Huawei не может предоставить
Я, кстати не рекомендую использовать флейворы для разных вариантов кода! При включении варианта сборки остальные убираются из индекса IDE. А еще сборки идут строго друг за другом (баг тулзов наверное). Это крайне затрудняет разработку, лучше уж сделать на модулях + два различных приложения.
Ну и про карты. Вы не стали вдаваться в детали, почему не стали в итоге интегрировать хуавеевские в финальной версии, жаль, было бы интересно узнать почему. Но даже если возникли какие-то непреодолимые сложности есть ещё один подход. Можно интегрировать те карты, которое работают и на GMS и на HMS аппаратах, те же яндексовские. Аналогичный подход можно использовать и для других библиотек.
Это больше продуктовая история. Пока что сделали MVP технической командой. Если продакт посчитает необходимым добавить карты в HMS сборку, то да, будем рассматривать в том числе и кросссервисные (слово то какое придумал?)варианты
Имеете в виду, что если кандидат не подошел, то пусть другие компании тоже видят? С одной стороны это интересная затея, так как оценка скиллов облегчит найм другим компаниям, но с другой — это попахивает каким-то социальным рейтингом, не находите? А эта штука прямо на грани!
Есть несколько факторов: на сколько сложно будет работать с фреймворком, готовы ли разработчики помогать, есть ли желание у ручных тестировщиков развиваться. У нас и на Android и на iOS нативные тесты с удобной оберткой (писали про них с Олей тут и тут). На текущий момент все наши QA справляются с автоматическим тестированием, более того, ребята отвоевали у разработчиков ответственность за написание автотестов)
Скажем так — до 30 лет у айтишников способность обучаться находится на весьма высоком уровне.
Мне 31, можно ставить крест на развитии? :)
Скорей всего QA кинули на амбразуру, а знаний и опыта у него не хватает.
На амбразуру никого не кидаем) В одной из охэхэнных историй рассказывали как у нас онбординг проходит. Как раз, как все любят — мягко и поддерживающе
Но есть базовые практики собесов, которые работают везде и для всех. Или не работают — таких тоже немало, например вопросы типа «Кем Вы себя видите в нашей компании через 5 лет?». Или — «Почему люк круглый?».
Про люк не спрашиваем. Кстати первый раз слышу такой вопрос
А в вопросе «Кем Вы себя видите в нашей компании через 5 лет?» есть рациональное зерно, просто его кадровики опошлили. Его надо задавать так: «В какую сторону Вы планируете развиваться? Что Вас драйвит и мотивирует?»
Вообще-то, составление тестовой документации и поддержка ее в актуальном состоянии — одна из основных обязанностей тестировщика.Не слышал чтобы в других компаниях для этого создавали специальные отделы.
В хх просто нет документации и по сути ее роль выполняют автотесты. Не поверите, это реально работает, и, тестировщики, освободившись от бюрократии получают буст времени на автотесты и ресечи.
Другими словами, НН использует кандидатов в качестве бесплатной рабочей силы.Нехорошо. Тестовое задание не должно быть связано с деятельностью компании.
Вы же понимаете, что смысл так делать нет? Наоборот тестовым дается та часть, про которую проверяющий знает все и может беглым взглядом оценить глубину погружения
MetAmfetamin Так а чему там загибаться-то в Toothpick? Он уже законченный, на мой взгляд. В отличии от сахарнокотлиновых Koin/Kodein ему и за языком гнаться не надо. Работает? Не меняй!
По поводу смены DI фреймворка: мне не очень нравится, что в Toothpick нужен kapt. Хотя, возможно, KSP решит все проблемы медленной сборки
MetAmfetamin бездумное использование runtime DI — это действительно сомнительная дорожка. Если его заключить в строгие рамки (как это сделано у нас), то разницы с compile time фреймворками особо-то и нет. Дело в том, что нет мест, в которых может вылезти вариативность от «рантаймовости».
Да, у нас еще же UI-тесты не дают пролезть каким-то багам.
Тем не менее, при выборе DI фреймворка я, рекомендую крепко подумать и взвесить все за и против. Думать и оценивать риски вообще полезное занятие ;)
Вообще сам факт, что у вас есть такой набор навыков для кандидата — это сильно ограничивает в кандидатах. К примеру, навык «agile» сразу отсекает всех, кто по нему не работал
Согласен с Вами, что такие вещи, как опыт/понимание agile скорее не являются блокирующими — этому всему можно научить. Тем не менее, некоторые вещи для нас критичны.
Выписать на и ранжировать характеристики, которые важны для конкретной позиции — это отличное упражнение, которое как раз делает собеседование максимально продуктивным
Если человек сам пришел на собес — то самостоятельность у него в какой-то мере точно присутствует.
Конкретно для нас у QA необходим немного больший уровень самостоятельности :)
Это связано с тем, что в команде в мобилке 2 iOS, 2 Android и 1 QA. Всвязи с чем QA приходится принимать решения и уже прятаться за спину старшего товарища не получится.
В других компаниях, в которых QA собраны в отдельные команды, уровень самостоятельности QA-инженеров может быть ниже
желание развиваться есть практически у всех айтишников до 30 лет.
В желании развиваться есть грань между мечтой и планами.
Что-то мне подсказывает, не те скилы Вы требуете от кандидатов ).
Я не претендую на то, что наша схема собеседования или критерии выбора являются единственными правильными. В зависимости от продукта, устройства компании, схемы взаимодействия, текущего коллектива, бюджета ФОТ и много другого требования, критерии, да и сама схема найма могут меняться.
Возможно то, что не работает у нас, будет хорошо работать в Вашей компании и наоборот, и это нормально :)
То, что Вы вообще очерчиваете такой набор навыков — это уже весьма ограниченный подход
Какой «такой»? Не понял Вас, если честно. Я выше не приводил характеристики, по которым принимаем решение. Привел лишь кейс, который нам помог как раз задуматься и понять, что действительно важно для каждой роли.
Как это устроено: У нас есть набор навыков / характеристик, которые в разной степени необходимы на должность. К примеру, для QA специалиста нам критически важны самостоятельность, умение находить баланс и желание развиваться. При этом умение писать автотесты на swift — это необязательный навык.
Собеседование, соответственно, строится на том, чтобы оценить кандидата по критериям, которые нам важны.
1) Руководитель тимлида (у нас, например, это я). Как показывает практика, роль тимлида в каждой компании включает в себя свою ответственность и набор навыков. Более того, для кандидатов не из компании приходится сразу же изучать 3 направления:
тимлидство в этой компании;
технический стек;
предметную область бизнеса
Поэтому нанять тимлида с «улицы» — это весьма непростая задача, и кадровый резерв тимлидов — весьма крутая затея
2) Самому тимлиду, на самом деле тоже интересно:
Разгрузка за счет делегирования;
В целом передавать опыт и рефлексировать — довольно интересная задачка
Финальное решение складывается из довольно большого числа факторов:
— общий технический уровень кандидата и потенциал развития;
— софт скиллы и то, на сколько подходит к текущему коллективу;
— продуктовое мышление (в продуктовых командах у нас конкретно это важно, так как разработчики не просто исполнители ТЗ, а инженеры, нацеленные на донесение ценности до пользователя);
— желаемое направление развития (иногда, к примеру, мы заинтересованы в том, чтобы из кандидата растить тимлида);
— зарплатные ожидания и т.д.
Допустим у вас 4 кандидата на подходе, вы прособесили первого и он в целом хорошо. Но у вас еще есть 3 кандидата, которые, возможно лучше по каким то параметрам, а возможно нет.
В итоге, в случае если человек не подошел, то все просто — ему отказывают, причем иногда сразу же на собесе. Если есть шанс, что он будет конкурировать с остальными — приходится морозить.
Совсем не потерять кандидатов нам помогает Talantix — в нём можно настроить, сколько кандидат может находиться на этапе.
В любом случае, я с Вами согласен, что необходимо регулярно уведомлять кандидата о статусе. Если осталось прособесить еще троих — так и скажите: «У нас довольно много хороших кандидатов — планируем их прособеседовать за ближайшую неделю». По итогу к вам вернемся с ответом. Прозрачность в отношениях очень хорошо говорит о вашей компании.
Воронка за довольно большое время — сюда вошел найм с октября 2020 и найм в марте
Кандидаты попадают к нам несколькими способами: Отклик на hh, Поиск на hh, Добавление из файлов/других ресурсов. Довольно больша́я часть откликов (красная полоска на скриншоте ниже) обычно не релевантны.
По воронке видно, что только процентов 20 из откликнувшихся доходят до технических специалистов.
Причина простая — часто откликаются кандидаты с релевантным опытом:
не iOS разработчик
не разработчики вообще (войти в IT)
iOS-разработчики, с недостатком опыта для текущей позиции
Спасибо, отвечу инлайн!
Все-таки хочется один артефакт — так удобнее работать, ну и можно, как и говорил в статье/видео, для пользователей HMS+GMS приоритезировать HMS для каких-либо фичей
А какие еще видите минусы / риски?
У нас только смоук делается (и то не всегда), основные проверки автоматизированы. Да, для HMS-фичей они не гоняются, так как эмуляторы Huawei не может предоставить
Я, кстати не рекомендую использовать флейворы для разных вариантов кода! При включении варианта сборки остальные убираются из индекса IDE. А еще сборки идут строго друг за другом (баг тулзов наверное). Это крайне затрудняет разработку, лучше уж сделать на модулях + два различных приложения.
Это больше продуктовая история. Пока что сделали MVP технической командой. Если продакт посчитает необходимым добавить карты в HMS сборку, то да, будем рассматривать в том числе и кросссервисные (слово то какое придумал?)варианты
Вы крутые, так держать!
Имеете в виду, что если кандидат не подошел, то пусть другие компании тоже видят? С одной стороны это интересная затея, так как оценка скиллов облегчит найм другим компаниям, но с другой — это попахивает каким-то социальным рейтингом, не находите? А эта штука прямо на грани!
Специальный вид тестирования: билибердовый
Есть несколько факторов: на сколько сложно будет работать с фреймворком, готовы ли разработчики помогать, есть ли желание у ручных тестировщиков развиваться. У нас и на Android и на iOS нативные тесты с удобной оберткой (писали про них с Олей тут и тут). На текущий момент все наши QA справляются с автоматическим тестированием, более того, ребята отвоевали у разработчиков ответственность за написание автотестов)
Мне 31, можно ставить крест на развитии? :)
На амбразуру никого не кидаем) В одной из охэхэнных историй рассказывали как у нас онбординг проходит. Как раз, как все любят — мягко и поддерживающе
Про люк не спрашиваем. Кстати первый раз слышу такой вопрос
А в вопросе «Кем Вы себя видите в нашей компании через 5 лет?» есть рациональное зерно, просто его кадровики опошлили. Его надо задавать так: «В какую сторону Вы планируете развиваться? Что Вас драйвит и мотивирует?»
В хх просто нет документации и по сути ее роль выполняют автотесты. Не поверите, это реально работает, и, тестировщики, освободившись от бюрократии получают буст времени на автотесты и ресечи.
Вы же понимаете, что смысл так делать нет? Наоборот тестовым дается та часть, про которую проверяющий знает все и может беглым взглядом оценить глубину погружения
По поводу смены DI фреймворка: мне не очень нравится, что в Toothpick нужен kapt. Хотя, возможно, KSP решит все проблемы медленной сборки
Да, у нас еще же UI-тесты не дают пролезть каким-то багам.
Тем не менее, при выборе DI фреймворка я, рекомендую крепко подумать и взвесить все за и против. Думать и оценивать риски вообще полезное занятие ;)
Ещё раз поправил, спасибо за внимательность! Это как пушить в мастер без компиляции
Спасибо, поправил! Копипаста в деле
Согласен с Вами, что такие вещи, как опыт/понимание agile скорее не являются блокирующими — этому всему можно научить. Тем не менее, некоторые вещи для нас критичны.
Выписать на и ранжировать характеристики, которые важны для конкретной позиции — это отличное упражнение, которое как раз делает собеседование максимально продуктивным
Конкретно для нас у QA необходим немного больший уровень самостоятельности :)
Это связано с тем, что в команде в мобилке 2 iOS, 2 Android и 1 QA. Всвязи с чем QA приходится принимать решения и уже прятаться за спину старшего товарища не получится.
В других компаниях, в которых QA собраны в отдельные команды, уровень самостоятельности QA-инженеров может быть ниже
В желании развиваться есть грань между мечтой и планами.
Я не претендую на то, что наша схема собеседования или критерии выбора являются единственными правильными. В зависимости от продукта, устройства компании, схемы взаимодействия, текущего коллектива, бюджета ФОТ и много другого требования, критерии, да и сама схема найма могут меняться.
Возможно то, что не работает у нас, будет хорошо работать в Вашей компании и наоборот, и это нормально :)
Какой «такой»? Не понял Вас, если честно. Я выше не приводил характеристики, по которым принимаем решение. Привел лишь кейс, который нам помог как раз задуматься и понять, что действительно важно для каждой роли.
Как это устроено: У нас есть набор навыков / характеристик, которые в разной степени необходимы на должность. К примеру, для QA специалиста нам критически важны самостоятельность, умение находить баланс и желание развиваться. При этом умение писать автотесты на swift — это необязательный навык.
Собеседование, соответственно, строится на том, чтобы оценить кандидата по критериям, которые нам важны.
Вообще задавать вопрос «Что бы что?» — крайне полезная затея. Причем, даже когда все хорошо идет
Поэтому нанять тимлида с «улицы» — это весьма непростая задача, и кадровый резерв тимлидов — весьма крутая затея
2) Самому тимлиду, на самом деле тоже интересно:
Финальное решение складывается из довольно большого числа факторов:
— общий технический уровень кандидата и потенциал развития;
— софт скиллы и то, на сколько подходит к текущему коллективу;
— продуктовое мышление (в продуктовых командах у нас конкретно это важно, так как разработчики не просто исполнители ТЗ, а инженеры, нацеленные на донесение ценности до пользователя);
— желаемое направление развития (иногда, к примеру, мы заинтересованы в том, чтобы из кандидата растить тимлида);
— зарплатные ожидания и т.д.
Допустим у вас 4 кандидата на подходе, вы прособесили первого и он в целом хорошо. Но у вас еще есть 3 кандидата, которые, возможно лучше по каким то параметрам, а возможно нет.
В итоге, в случае если человек не подошел, то все просто — ему отказывают, причем иногда сразу же на собесе. Если есть шанс, что он будет конкурировать с остальными — приходится морозить.
Совсем не потерять кандидатов нам помогает Talantix — в нём можно настроить, сколько кандидат может находиться на этапе.
В любом случае, я с Вами согласен, что необходимо регулярно уведомлять кандидата о статусе. Если осталось прособесить еще троих — так и скажите: «У нас довольно много хороших кандидатов — планируем их прособеседовать за ближайшую неделю». По итогу к вам вернемся с ответом. Прозрачность в отношениях очень хорошо говорит о вашей компании.
Кандидаты попадают к нам несколькими способами: Отклик на hh, Поиск на hh, Добавление из файлов/других ресурсов. Довольно больша́я часть откликов (красная полоска на скриншоте ниже) обычно не релевантны.
По воронке видно, что только процентов 20 из откликнувшихся доходят до технических специалистов.
Причина простая — часто откликаются кандидаты с релевантным опытом:
А если серьезно, пока Вы не построите процесс найма, никто за Вас этого не сделает