А мне кажется что это и человек никак не понимает) Мы даем тестовое всем и проверяем независимо от того, насколько плохо написано резюме, какой у человека опыт, как он выглядит, сколько ему лет итп. И оцениваем по результатам тестового.
Мы считаем некорректным вываливать на кандидата сразу весь поток информации о компании, графике, режиме работы и прочем – на это не всегда есть запрос.
А чат-бот на все эти вопросы ответит, если его спросить.
Когда незнакомый вам рекрутер, с которым вы общаетесь, просит отправить резюме, вы ведь, скорее всего, уважаете его просьбу и резюме таки отправляете. Про личность этого рекрутера вы, скорее всего, знаете не больше, чем про чат-бота. Если ваше резюме размещено на hh.ru, то оно уже доступно непонятно кому 🤷♀️
Добрый вечер, есть опыт использования tap-facebook, он в актуальном состоянии, но для того чтобы он нормально работал, нужно зарегистрировать приложение на фейсбуке и получить расширенный доступ для ads_read и Ads Management Standard Access.
Звучит как комментарий человека, знакомого с концепциями! :)
Мы сначала реализуем каждый атрибут независимо, но потом из независимых атрибутов собираем 1) широкую таблицу на анкер, просто left join‘ом всех атрибутов на анкер 2) широкую таблицу со всеми линками (по возможности).
То есть, когда появляется ещё один атрибут, мы добавляем ещё одну строчку left join’а в таблице анкера.
Это удобно для аналитики, для отображения в Metabase и sql-запросов.
Ща, погодите, у Singer же архитектура какая: - есть tap'ы – они для сбора данных из источников - есть target'ы – они для заливки данных в destination
Ну и соответственно если нужно данные из vk, например, залить в clickhouse, то надо взять tap-vk (например, наш), и target clickhouse. Target clickhouse кажется гуглится – https://www.npmjs.com/package/target-clickhouse например
https://arrows.app/ Вообще Arrows используется для визуализации labeled property graphs из домена графовых баз данных. Но выяснилось, что для визуализации моделей данных в терминах анкеров/атрибутов/линков тоже отлично подходит.
Привет! Мы тоже используем в работе производную от Anchor Modeling модель (Minimal Modeling). С событиями да, тоже замечали такую проблематику.
Сори, сейчас будет длинный комментарий :)
Вообще интересно, откуда берутся event'ы (давайте для простоты про мобильные event'ы только поговорим). Event’ы берутся из взаимодействия пользователя с интерфейсными элементами. Например:
USER clicked BUTTON
USER viewed PRODUCT_CARD итп
Где button, product_card - это реально анкера (в терминах Anchor Modeling), а действие с ними (USER clicked BUTTON) - это честный линк.
Но вместо «USER clicked BUTTON» логируется событие «green_button_click», которое содержит в себе след этого линка с потерей анкера + атрибуты.
В общем event - это реально линк, в котором мы потеряли информацию, и поэтому оно такое стрёмное.
Ещё про event’ы отдельно интересно, что они (почти) всегда достаточно хорошо документированы. Потому что прежде чем event’ы появляются в мобилке или на сайте, например, сначала появляется натурально ЭКСЕЛЬКА, в которой написано как именно какой event называется, когда логируется, какое-то у него есть описание, иногда даже скриншоты места в приложении откуда оно логируется.
Ну то есть у отдельного event’а самого по себе так-то довольно много самостоятельных описательных атрибутов.
Ну и простое следствие из этих рассуждений - что рядом с этим вот стрёмным анкером event есть анкер event_catalog со списком логируемых событий и их честными атрибутами.
И следующая мысль: а не получится ли на уровне вот этого event_catalog’а восстановить у event’а потерянный анкер и семантику линка (все равно event catalog это полностью ручная штука), и не появится ли от этого в event’ах интересного слоя дополнительного смысла.
Ну то есть, например, событие green_button_click не получится ли восстановить до USER clicked Button (с двумя анкерами, ликнком между ними и атрибутом green).
Мы как-то провели эксперимент и раскрыли User made Event в недостающие анкера и получилась вот такая штука:
То есть, в трекинг-плане например были события:
onboarding_shown
onboarding_second_step_shown
onboarding_third_step_shown
onboarding_fourth_step_shown
onboarding_fifth_step_shown
Каждое из этих событий – это атрибут линка "USER views ONBOARDING_SCREEN".
В общем мы сейчас размышляем о том, как бы на уровне инструмента ведения трекинг-планов вернуть потерянные анкера для этих event'ов. Потому что если получается так делать, то возникает еще интересная связка события с объектом реального мира (например, с конкретным товаром, item'ом итп)
А мне кажется что это и человек никак не понимает) Мы даем тестовое всем и проверяем независимо от того, насколько плохо написано резюме, какой у человека опыт, как он выглядит, сколько ему лет итп. И оцениваем по результатам тестового.
Ваше право!
Но да, соглашусь, что подход к найму senior-специалистов может отличаться.
Мы считаем некорректным вываливать на кандидата сразу весь поток информации о компании, графике, режиме работы и прочем – на это не всегда есть запрос.
А чат-бот на все эти вопросы ответит, если его спросить.
Когда незнакомый вам рекрутер, с которым вы общаетесь, просит отправить резюме, вы ведь, скорее всего, уважаете его просьбу и резюме таки отправляете. Про личность этого рекрутера вы, скорее всего, знаете не больше, чем про чат-бота.
Если ваше резюме размещено на hh.ru, то оно уже доступно непонятно кому 🤷♀️
Добрый вечер, есть опыт использования tap-facebook, он в актуальном состоянии, но для того чтобы он нормально работал, нужно зарегистрировать приложение на фейсбуке и получить расширенный доступ для ads_read и Ads Management Standard Access.
Звучит как комментарий человека, знакомого с концепциями! :)
Мы сначала реализуем каждый атрибут независимо, но потом из независимых атрибутов собираем 1) широкую таблицу на анкер, просто left join‘ом всех атрибутов на анкер 2) широкую таблицу со всеми линками (по возможности).
То есть, когда появляется ещё один атрибут, мы добавляем ещё одну строчку left join’а в таблице анкера.
Это удобно для аналитики, для отображения в Metabase и sql-запросов.
Ща, погодите, у Singer же архитектура какая:
- есть tap'ы – они для сбора данных из источников
- есть target'ы – они для заливки данных в destination
Ну и соответственно если нужно данные из vk, например, залить в clickhouse, то надо взять tap-vk (например, наш), и target clickhouse. Target clickhouse кажется гуглится – https://www.npmjs.com/package/target-clickhouse например
Или вопрос в другом?
Да ну ой, это тезис про качественные и количественные данные что ли?
Ну как откуда данные! На дашборд посмотрели, там график "средний чек заказа по дням" – и вон, видно же, что упал! :)
Привет! Легко:
- https://github.com/epoch8/tap-yandexdirect
- https://github.com/epoch8/tap-vk
Если будут вопросы – пишите olga@epoch8.co
А, или речь идет о картинке с Lineage? Такие штуки рисует https://getdbt.com/
https://arrows.app/ Вообще Arrows используется для визуализации labeled property graphs из домена графовых баз данных. Но выяснилось, что для визуализации моделей данных в терминах анкеров/атрибутов/линков тоже отлично подходит.
Привет! Мы тоже используем в работе производную от Anchor Modeling модель (Minimal Modeling). С событиями да, тоже замечали такую проблематику.
Сори, сейчас будет длинный комментарий :)
Вообще интересно, откуда берутся event'ы (давайте для простоты про мобильные event'ы только поговорим). Event’ы берутся из взаимодействия пользователя с интерфейсными элементами. Например:
USER clicked BUTTON
USER viewed PRODUCT_CARD итп
Где button, product_card - это реально анкера (в терминах Anchor Modeling), а действие с ними (USER clicked BUTTON) - это честный линк.
Но вместо «USER clicked BUTTON» логируется событие «green_button_click», которое содержит в себе след этого линка с потерей анкера + атрибуты.
В общем event - это реально линк, в котором мы потеряли информацию, и поэтому оно такое стрёмное.
Ещё про event’ы отдельно интересно, что они (почти) всегда достаточно хорошо документированы. Потому что прежде чем event’ы появляются в мобилке или на сайте, например, сначала появляется натурально ЭКСЕЛЬКА, в которой написано как именно какой event называется, когда логируется, какое-то у него есть описание, иногда даже скриншоты места в приложении откуда оно логируется.
Ну то есть у отдельного event’а самого по себе так-то довольно много самостоятельных описательных атрибутов.
Ну и простое следствие из этих рассуждений - что рядом с этим вот стрёмным анкером event есть анкер event_catalog со списком логируемых событий и их честными атрибутами.
И следующая мысль: а не получится ли на уровне вот этого event_catalog’а восстановить у event’а потерянный анкер и семантику линка (все равно event catalog это полностью ручная штука), и не появится ли от этого в event’ах интересного слоя дополнительного смысла.
Ну то есть, например, событие green_button_click не получится ли восстановить до USER clicked Button (с двумя анкерами, ликнком между ними и атрибутом green).
Мы как-то провели эксперимент и раскрыли User made Event в недостающие анкера и получилась вот такая штука:
То есть, в трекинг-плане например были события:
onboarding_shown
onboarding_second_step_shown
onboarding_third_step_shown
onboarding_fourth_step_shown
onboarding_fifth_step_shown
Каждое из этих событий – это атрибут линка "USER views ONBOARDING_SCREEN".
В общем мы сейчас размышляем о том, как бы на уровне инструмента ведения трекинг-планов вернуть потерянные анкера для этих event'ов. Потому что если получается так делать, то возникает еще интересная связка события с объектом реального мира (например, с конкретным товаром, item'ом итп)