Хочу поделиться опытом проведения собеседований по SQL в формате лайфкодинга. За последний год у меня была возможность оценить множество кандидатов, и я заметил несколько общих признаков, которые бы хотел обсудить и дать небольшие советы.
Дисклеймер: Я понимаю скептицизм многих по поводу корректности проверки навыков SQL путем лайфкодинга на нескольких задачах. Мы в Авито на основании SQL скоринга не выставляем грейд, а просто принимаем решение hire/no hire. Соответственно и оцениваем мы больше подход к решению, а не знание синтаксиса
По части софт скиллов: зачастую кандидаты не слишком внимательно читают условия задач. Вместо того чтобы потратить немного времени на понимание всех условий, накидывание вопросов - они спешат писать код. В реальной работе же никто не сядет за клавиатуру без пытки заказчика уточнениями пока не станет все ясно (духота спасает аналитика от переработок). В большинстве задач (как реальных, так и тех что я встречал на собесах) есть подводные камни и формулировки которые можно понять неоднозначно. Может быть здесь будет полезный такой подход - представьте что это не собеседование а созвон с заказчиком какого-то странного эдхока.
По части хард скиллов: многие не очень хорошо ориентируются в теории SQL, часто просто механически используют функции, но не задумываются о том, как и почему они работают.
Например группировка. Часто ее рассматривают как некое следствие (группировка нужна для агрегации и расчета значений) а не как механизм -в котором расчет это последний этап, а один из первых - сбор уникальных групп. Когда задумываешься с этой стороны, можно найти группировке много интересных применений.
Иногда ставит в тупик кандидатов вопрос "Как ты думаешь, какой способ решения задачи будет оптимальнее?" Тут основной пункт - просто почитать статьи о том как работают разные СУБД и какие есть основные ошибки и альтернативные решения. Почитайте про индексацию и анализ планов выполнения запросов. Попробуйте использовать на практике если не пользовались раньше. Но конечно все зависит от СУБД.
Вобщем советы избитые, но думаю полезные - читайте документацию и практикуйтесь,
не стесняйтесь задавать вопросы,
представляйте что это реальный кейс с эдхок задачей.
Что вообще думаете про sql- скрининг биайщиков?
Дисклеймер: Я понимаю скептицизм многих по поводу корректности проверки навыков SQL путем лайфкодинга на нескольких задачах. Мы в Авито на основании SQL скоринга не выставляем грейд, а просто принимаем решение hire/no hire. Соответственно и оцениваем мы больше подход к решению, а не знание синтаксиса
По части софт скиллов: зачастую кандидаты не слишком внимательно читают условия задач. Вместо того чтобы потратить немного времени на понимание всех условий, накидывание вопросов - они спешат писать код. В реальной работе же никто не сядет за клавиатуру без пытки заказчика уточнениями пока не станет все ясно (духота спасает аналитика от переработок). В большинстве задач (как реальных, так и тех что я встречал на собесах) есть подводные камни и формулировки которые можно понять неоднозначно. Может быть здесь будет полезный такой подход - представьте что это не собеседование а созвон с заказчиком какого-то странного эдхока.
По части хард скиллов: многие не очень хорошо ориентируются в теории SQL, часто просто механически используют функции, но не задумываются о том, как и почему они работают.
Например группировка. Часто ее рассматривают как некое следствие (группировка нужна для агрегации и расчета значений) а не как механизм -в котором расчет это последний этап, а один из первых - сбор уникальных групп. Когда задумываешься с этой стороны, можно найти группировке много интересных применений.
Иногда ставит в тупик кандидатов вопрос "Как ты думаешь, какой способ решения задачи будет оптимальнее?" Тут основной пункт - просто почитать статьи о том как работают разные СУБД и какие есть основные ошибки и альтернативные решения. Почитайте про индексацию и анализ планов выполнения запросов. Попробуйте использовать на практике если не пользовались раньше. Но конечно все зависит от СУБД.
Вобщем советы избитые, но думаю полезные - читайте документацию и практикуйтесь,
не стесняйтесь задавать вопросы,
представляйте что это реальный кейс с эдхок задачей.
Что вообще думаете про sql- скрининг биайщиков?
Трудная рабочая неделя закончилась, и мне хочется поделиться с вами практически не-биайной историей
Не так давно я стал тимлидом (пока acting, это нечто вроде испытательного срока внутри компании) и понял что количество встреч резко выросло, и под конец дня у меня не остаётся сил не то что на работу IC, но и на те проекты, которые я хочу реализовать в качестве тимлида. Спустя пару месяцев шока и прочитанных материалов по тайм-менеджменту я начал вырабатывать какое то подобие своей системы работы с календарём, и хотел бы вынести ее на вашу критику.
Последние пару недель я классифицировал свои встречи по тому, насколько они меня выматывают и сколько мне надо приходить в себя чтобы вдумчиво сесть и поработать, и в итоге у меня получилась определённая шкала стрессовости встреч. Я раскрасил её от зелёного к красному и превратил свой календарь в хитмап😅 Я предупреждал, что чуть чуть биая все равно будет)
Теперь буду экспериментировать с тем, чтобы перемещая встречи внутри дня попробовать получить побольше эффективности на единицу времени календаря.
А как вы решаете проблему с множеством встреч?
Не так давно я стал тимлидом (пока acting, это нечто вроде испытательного срока внутри компании) и понял что количество встреч резко выросло, и под конец дня у меня не остаётся сил не то что на работу IC, но и на те проекты, которые я хочу реализовать в качестве тимлида. Спустя пару месяцев шока и прочитанных материалов по тайм-менеджменту я начал вырабатывать какое то подобие своей системы работы с календарём, и хотел бы вынести ее на вашу критику.
Последние пару недель я классифицировал свои встречи по тому, насколько они меня выматывают и сколько мне надо приходить в себя чтобы вдумчиво сесть и поработать, и в итоге у меня получилась определённая шкала стрессовости встреч. Я раскрасил её от зелёного к красному и превратил свой календарь в хитмап
Теперь буду экспериментировать с тем, чтобы перемещая встречи внутри дня попробовать получить побольше эффективности на единицу времени календаря.
А как вы решаете проблему с множеством встреч?
Please open Telegram to view this post
VIEW IN TELEGRAM
Сегодня у меня была эталонная задача на доработку дашборда (желаю всем таких задач)
Сел разобрать переписки в корпоративном мессенджере, а там череда непрочитанных сообщений:
- Дима привет! Нам нужна вот такая-то доработка дашборда
Спустя час:
- Подожди, сейчас с командой обсудим что конкретно нам надо
Спустя еще час:
- Отмена, пока ничего не надо)
Сел разобрать переписки в корпоративном мессенджере, а там череда непрочитанных сообщений:
- Дима привет! Нам нужна вот такая-то доработка дашборда
Спустя час:
- Подожди, сейчас с командой обсудим что конкретно нам надо
Спустя еще час:
- Отмена, пока ничего не надо)
Айгуль написала классную статью про одну из главных болей биайщика - невостребованные пользователями дашборды. От себя бы еще добавил пункт про доверие пользователя к отчетности - если часто возникают ошибки и проблемы, то даже самый лояльный пользователь однажды подумает "Может ну его нафиг, я лучше таро разложу, шансы на правильный ответ одинаковы"
И переломить этот тренд будет очень проблематично
Ну и все это нас приводит к альтернативной или теневой отчетности: табличка в эксель, старый неактуальный дашборд, который никто не поддерживает, но при этом им по привычке пользуются.
В общем цените своих пользователей, общайтесь с ними и будет вам счастье и востребованные дашборды)
И переломить этот тренд будет очень проблематично
Ну и все это нас приводит к альтернативной или теневой отчетности: табличка в эксель, старый неактуальный дашборд, который никто не поддерживает, но при этом им по привычке пользуются.
В общем цените своих пользователей, общайтесь с ними и будет вам счастье и востребованные дашборды)
Forwarded from Avito Data Tech
Привет, меня зовут Айгуль Ахметова. Я BI разработчик из команды BI Core, разрабатываю и поддерживаю кросс-функциональную отчётность и разрабатываю дашборды в Redash.
Весной все начинают генеральную уборку — BI-разработчики же проводят ревизию своих дашбордов: изучают пользователей, смотрят, кто из заказчиков и с какой периодичностью заходит в отчёты.
Но вот незадача: дашборд создавался для 50 пользователей в месяц, а в аналитике — всего два просмотра. И один из них — твой…
Появляется мысль: удалить всё и сделать вид, что ничего не было. Но, может попробуем вдохнуть в дашборд новую жизнь? Добавить понятные подписи, убрать лишнее, заменить длиннющие таблицы на наглядные диаграммы. В общем, немного магии BI-стилиста!
Что делать, если твой дашборд игнорируют?
Если твой отчёт требует 100-страничного мануала, им будут пользоваться только самые отчаянные)) Дашборд должен быть понятным с первого взгляда. Покажи макет коллеге, который в BI понимает столько же, сколько улитка в квантовой физике. Если он разберётся — ты на верном пути!
Статистика гласит, что 47% пользователей ожидают загрузку страницы меньше, чем за 2 секунды. Посмотри, как можно оптимизировать запросы, чтобы всё летало. Быстрый дашборд — это дашборд, к которому хочется вернуться.
Голые цифры — просто цифры. Опиши, что они значат, какие выводы из них можно сделать. Иногда пара слов объяснения эффективнее, чем длинное видео-объяснение, до которого редко кто так и поспевает дойти.
Выбирая между таблицей с миллионом строк и наглядным графиком, лучше выбрать график. Пусть данные рассказывают историю, а не вынуждают пользователей играть в «найди десять отличий». Но не переусердствуй с цветами — с лаконичностью ты точно будешь на коне.
Может, проблема была на поверхности? Отчёт гениальный, но при переходе по ссылке люди видят белый экран, потому что у них нет прав. Дай доступ и сразу объясни, где его получить, когда ты впервые отправляешь дашборд потенциальным пользователям.
Ты поработал над дашбордом, добавил визуализации, фильтры, документацию, он стал удобным и быстрым. Но знают ли о его существовании те, кому он действительно нужен? Собери потенциальных пользователей, проведи демо, ответь на вопросы и внеси доработки. Пять минут презентации — и твой дашборд может обрести новых поклонников на всю его технологическую жизнь.
А если после всего этого на твой отчёт всё равно никто не смотрит?… Возможно, стоит отпустить его с миром. Но, уверена, что до этого не дойдёт!
#Redash #BI
Please open Telegram to view this post
VIEW IN TELEGRAM
В честь 100 подписчиков на канале расскажу вам небольшую историю про пасхалку которая случайно получилась в канале.
Изначально я сделал этот канал как просто альтернативу избранным сообщениям, куда я скидываю всякие интересности и книги которые я когда-нибудь обязательно прочитаю (ага-ага).
Потом я из закрытого канала перевел его в открытый и у меня появилась опция - придумать никнейм для него. И я как истинный зануда начал придумывать как бы обыграть слово data. В итоге не был занят никнейм withdata ("c данными" если перевести буквально). Ну и название канала появилось примерно тогда же - как описание меня и моего профессионального проявления. Что я - не просто я, я делаю биай. Ну а пасхалку эту я сам обнаружил случайно когда прочитал вслух через какое то время вместе название и никнейм канала = )
Если игра слов осталась не ясна, попробуйте реально вслух это произнести. Или прочитать следующий абзац
Ну и собственно мораль - если можешь при тех же усилиях делать лучше - делай не просто лучше, делай пиздато
Изначально я сделал этот канал как просто альтернативу избранным сообщениям, куда я скидываю всякие интересности и книги которые я когда-нибудь обязательно прочитаю (ага-ага).
Потом я из закрытого канала перевел его в открытый и у меня появилась опция - придумать никнейм для него. И я как истинный зануда начал придумывать как бы обыграть слово data. В итоге не был занят никнейм withdata ("c данными" если перевести буквально). Ну и название канала появилось примерно тогда же - как описание меня и моего профессионального проявления. Что я - не просто я, я делаю биай. Ну а пасхалку эту я сам обнаружил случайно когда прочитал вслух через какое то время вместе название и никнейм канала = )
Если игра слов осталась не ясна, попробуйте реально вслух это произнести. Или прочитать следующий абзац
Как вы думаете, что может объединять дорожную разметку, классическую архитектуру, панораму городской улицы и проекции детали на чертеже?
Подсказка - везде используется свойства человеческого мозга достраивать прямые или плавные линии из разрозненных частей
Или если сформулировать получше - принцип непрерывности (continuity) в гештальте.
Темы принципов гештальта достаточно избиты, про их использование при построении инфографики не высказался только ленивый, но в выходные я столкнулся с их неочевидным проявлением и решил прикинуть, а где же еще мы сталкиваемся с ними?
А началось все с того, что мы с сыном рисовали картинку по точкам (ту где надо объединить точки линиями и получить какое-то животное). И у нас завязался спор - Миша вполне обоснованно спросил меня - почему вот тут если сделать линию прямую - то ничего не получается, и почему папа утверждает что линию надо делат с углом, ведь видно что она должна быть прямой.
На что я ему резонно возразил: "Потому чтопапа блин знает как выглядит жираф надо обращать внимание не только на то как точки расположены, но и какие рядом с ними цифры, а линия выглядит прямой потому что человек любит в хаосе видеть порядок и продолжить точки в прямую линию человеку проще чем в два угла (условно X это скорее / + \ а не > + <)
Принцип непрерывности говорит нам, что элементы, расположенные на одной линии или плавной кривой, воспринимаются как связанные друг с другом.
В контексте визуализации данных это означает, что линии и кривые помогают устанавливать связи между точками данных, формируя тем самым четкие тренды и зависимости. Плавные линии и последовательные формы могут связывать разные части инфографики, помогая читателю лучше понять и запомнить представленную информацию.
Ну а еще этот принцип позволяет
- В наборе черточек на асфальте увидеть сложную разметку движения по полосам
- Увидеть красоту и прямые линии в нагромождении архитектурных элементов
- Идти от обратного - нарисовать сходящиеся в точку линии и на них расставить элементы городского пейзажа для четкой передачи перспективы
- ну и сопоставить между собой грани детали на разных проекциях чертежа
Так что когда вы будете маневрировать на огромном перекрестке с грамотной разметкой, сможете похвалить себя "Как хорошо что мой мозг умеет в непрерывность"😄
Подсказка - везде используется свойства человеческого мозга достраивать прямые или плавные линии из разрозненных частей
Или если сформулировать получше - принцип непрерывности (continuity) в гештальте.
Темы принципов гештальта достаточно избиты, про их использование при построении инфографики не высказался только ленивый, но в выходные я столкнулся с их неочевидным проявлением и решил прикинуть, а где же еще мы сталкиваемся с ними?
А началось все с того, что мы с сыном рисовали картинку по точкам (ту где надо объединить точки линиями и получить какое-то животное). И у нас завязался спор - Миша вполне обоснованно спросил меня - почему вот тут если сделать линию прямую - то ничего не получается, и почему папа утверждает что линию надо делат с углом, ведь видно что она должна быть прямой.
На что я ему резонно возразил: "Потому что
Принцип непрерывности говорит нам, что элементы, расположенные на одной линии или плавной кривой, воспринимаются как связанные друг с другом.
В контексте визуализации данных это означает, что линии и кривые помогают устанавливать связи между точками данных, формируя тем самым четкие тренды и зависимости. Плавные линии и последовательные формы могут связывать разные части инфографики, помогая читателю лучше понять и запомнить представленную информацию.
Ну а еще этот принцип позволяет
- В наборе черточек на асфальте увидеть сложную разметку движения по полосам
- Увидеть красоту и прямые линии в нагромождении архитектурных элементов
- Идти от обратного - нарисовать сходящиеся в точку линии и на них расставить элементы городского пейзажа для четкой передачи перспективы
- ну и сопоставить между собой грани детали на разных проекциях чертежа
Так что когда вы будете маневрировать на огромном перекрестке с грамотной разметкой, сможете похвалить себя "Как хорошо что мой мозг умеет в непрерывность"😄
Оконки оконочки. Иногда у меня есть подозрение что я слишком часто их использую и "когда в руках молоток все кажется гвоздями"
Недавно на работе была с виду несложная задача - есть логи системы с каким-нибудь свойством (например статус). И этот статус логировался только в момент его изменения, причем только если менялись другие поля в логах. В итоге надо для каждой строчки восстановить актуальный статус.
Собственно пример данных и сама задача на скриншоте.
Здесь вы можете сделать паузу, заварить чаек и подумать как можно решить такую задачу .
А я под спойлером напишу мой вариант решения + в комментарии закину более явно объясняющий это скрин (увы мне для этого решения не были доступны процедурные способы)
спойлер:там четыре уровня оконных функций получилось
Первым моим вариантом кстати было сделать какой-нибудь хитрый джойн таблицы саму на себя через неравенство, но:
Для этого нам надо знать интервал действия каждого статуса. Порядок статусов и их нейминг нам никто не гарантирует, поэтому я этот вариант отложил и обратился к оконкам
По сути здесь основная проблема - у нас нет на что опереться в построении окна, по которому мы будем "размазывать" значения. Кстати сам способ "размазывания" не так важен - можем джойном с группировкой, можем джойном по неравенству.
Если мы посмотрим на эти данные "сверху" то можем формализовать границы этого окна как "начиная со строки где статус поменялся (либо с первой строки) и заканчивая строкой, которая предшествует новому статусу"
После формализации уже становится проще - мы можем детектить строку изменения статуса с помощью lag или lead - а распределять их значение с помощью кумулятивной оконки (грубо говоря для каждой строки посчитать количество изменений статуса).
И потом уже сдвинув эти значения на строку вверх можно использовать эту нумерацию как окно и по нему распределить статусы.
Способ возможно выглядит переусложненным, но увы ничего лучше я не нашел (я еще пробовал различные вариации first_value(coalesce(status,'')) over(partition by id order by create_dttm desc range between unbounded precending and current row)
Но они мне не помогли). Буду рад если вы принесете другие варианты
UPD: в комментариях предложили вариант получше:)
Недавно на работе была с виду несложная задача - есть логи системы с каким-нибудь свойством (например статус). И этот статус логировался только в момент его изменения, причем только если менялись другие поля в логах. В итоге надо для каждой строчки восстановить актуальный статус.
Собственно пример данных и сама задача на скриншоте.
Здесь вы можете сделать паузу, заварить чаек и подумать как можно решить такую задачу .
А я под спойлером напишу мой вариант решения + в комментарии закину более явно объясняющий это скрин (увы мне для этого решения не были доступны процедурные способы)
спойлер:
Первым моим вариантом кстати было сделать какой-нибудь хитрый джойн таблицы саму на себя через неравенство, но:
Для этого нам надо знать интервал действия каждого статуса. Порядок статусов и их нейминг нам никто не гарантирует, поэтому я этот вариант отложил и обратился к оконкам
По сути здесь основная проблема - у нас нет на что опереться в построении окна, по которому мы будем "размазывать" значения. Кстати сам способ "размазывания" не так важен - можем джойном с группировкой, можем джойном по неравенству.
Если мы посмотрим на эти данные "сверху" то можем формализовать границы этого окна как "начиная со строки где статус поменялся (либо с первой строки) и заканчивая строкой, которая предшествует новому статусу"
После формализации уже становится проще - мы можем детектить строку изменения статуса с помощью lag или lead - а распределять их значение с помощью кумулятивной оконки (грубо говоря для каждой строки посчитать количество изменений статуса).
И потом уже сдвинув эти значения на строку вверх можно использовать эту нумерацию как окно и по нему распределить статусы.
Способ возможно выглядит переусложненным, но увы ничего лучше я не нашел (я еще пробовал различные вариации first_value(coalesce(status,'')) over(partition by id order by create_dttm desc range between unbounded precending and current row)
Но они мне не помогли). Буду рад если вы принесете другие варианты
UPD: в комментариях предложили вариант получше:)
Сегодня в МИРЭА читал небольшую лекцию об аналитике в целом, аналитике в Авито, и BI аналитике в частности. Очень отзывчивые и вовлеченные студенты были, две пары пролетели незаметно)
Чтобы не было так скучно и приторно, провел для них небольшой интерактив из двух частей - «Прожарка», где надо было критиковать и предлагать улучшения сомнительных визуализаций (спасибо за них каналу «Отвратительные графики» @awfulcharts ) и обзор нескольких видов графиков, где надо было поставить оценки по нескольким критериям типа понятности и применимости и придумать кейс к которому подходит тот или иной тип графиков (нетривиальность и остроумие приветствовалось)
Промежуточные выводы:
1) Абсолютно зря повально ругают зумеров
2) Когда на лекции появляется возможность поругать чужую работу - аудитория оживляется
Собственно слайд со второго интерактива на фото и вы в комментариях можете предложить свой вариант что можно изобразить с их помощью
Чтобы не было так скучно и приторно, провел для них небольшой интерактив из двух частей - «Прожарка», где надо было критиковать и предлагать улучшения сомнительных визуализаций (спасибо за них каналу «Отвратительные графики» @awfulcharts ) и обзор нескольких видов графиков, где надо было поставить оценки по нескольким критериям типа понятности и применимости и придумать кейс к которому подходит тот или иной тип графиков (нетривиальность и остроумие приветствовалось)
Промежуточные выводы:
1) Абсолютно зря повально ругают зумеров
2) Когда на лекции появляется возможность поругать чужую работу - аудитория оживляется
Собственно слайд со второго интерактива на фото и вы в комментариях можете предложить свой вариант что можно изобразить с их помощью
Ревью близко!
Для многих компаний и команд с полугодовым циклом перф ревью этот мем становится актуален и добавляет стресса в текущей работе
Я впервые буду проходить/проводить ревью как руководитель, и определённый мандраж присутствует конечно. Получится ли откалибровать своих так как задумано, получится ли защититься самому 😅
Надеюсь мне помогут заметки которые я делал в течение полугода о работе себя и команды) Но смотрю в них и понимаю что надо было писать их подробнее.
Еще стрессовый момент- запрашивание отзыва о своей работе от коллег. Тут я могу поделиться маленьким лайфхаком - запрашивая отзыв, напишите человеку: объясните оценку каких качеств себя и своей работы вы бы хотели получить, какие проекты вы с ним сделали (помогите ему вспомнить и начать писать - не все набили руку на написании отзывов, и зачастую сами испытывают стресс). Так вы уменьшите вероятность получить неинформативный отзыв «Вася классный, все было супер»
Пожелаю вам терпения и выдержки для этого непростого периода, а также сознательности не использовать для всего этого LLM :)
Для многих компаний и команд с полугодовым циклом перф ревью этот мем становится актуален и добавляет стресса в текущей работе
Я впервые буду проходить/проводить ревью как руководитель, и определённый мандраж присутствует конечно. Получится ли откалибровать своих так как задумано, получится ли защититься самому 😅
Надеюсь мне помогут заметки которые я делал в течение полугода о работе себя и команды) Но смотрю в них и понимаю что надо было писать их подробнее.
Еще стрессовый момент- запрашивание отзыва о своей работе от коллег. Тут я могу поделиться маленьким лайфхаком - запрашивая отзыв, напишите человеку: объясните оценку каких качеств себя и своей работы вы бы хотели получить, какие проекты вы с ним сделали (помогите ему вспомнить и начать писать - не все набили руку на написании отзывов, и зачастую сами испытывают стресс). Так вы уменьшите вероятность получить неинформативный отзыв «Вася классный, все было супер»
Пожелаю вам терпения и выдержки для этого непростого периода, а также сознательности не использовать для всего этого LLM :)
Жизненная жиза от Aurélien Vautier
Вообще функционал «Накидать в панамку не выходя с дашборда» очень полезный. Добавлять на дашборд кликабельную ссылку в мессенджер на ответственного - классика, которая на мой взгляд очень положительно влияет на опыт использования отчёта.
Генерить письмо - о подобном функционале я слышал, но честно сказать сам ни разу не делал.
Но вот генерить создание встречи- это прям интересный ход
Вообще функционал «Накидать в панамку не выходя с дашборда» очень полезный. Добавлять на дашборд кликабельную ссылку в мессенджер на ответственного - классика, которая на мой взгляд очень положительно влияет на опыт использования отчёта.
Генерить письмо - о подобном функционале я слышал, но честно сказать сам ни разу не делал.
Но вот генерить создание встречи- это прям интересный ход
Forwarded from PharmaDataLab
PharmaDataMeeting №2
29 июня 2025, 15:00 (воскресенье)
Друзья, всем привет.
Собираемся на второй митинг нашего сообщества, в этот раз будут презентации спикеров из других отраслей, в том числе из бигтех компаний. Как всегда говорим про реальные кейсы, никаких агентств и рекламы, только максимально полезная информация для развития аналитического коммьюнити.
1️⃣ Герингер Владимир - директор бизнес-аналитики, GLS pharmaceuticals: "Информационная система: архитектура решения"
Автор канала: PharmaDataLab
2️⃣ Снигирев Дмитрий - тимлид Core BI - Авито: "Как выглядит роль BI аналитика в требованиях разных компаний"
Автор канала: Делаю BI
3️⃣ Корнев Иван - аналитик данных: "Приблизительный подсчёт уникальных записей в SQL"
Автор канала: Откровенная аналитика
Приходите, будет интересно!
Ссылка для подключения: https://telemost.yandex.ru/j/65617501912823
🔥 - ставь, если придешь в эфир
29 июня 2025, 15:00 (воскресенье)
Друзья, всем привет.
Собираемся на второй митинг нашего сообщества, в этот раз будут презентации спикеров из других отраслей, в том числе из бигтех компаний. Как всегда говорим про реальные кейсы, никаких агентств и рекламы, только максимально полезная информация для развития аналитического коммьюнити.
1️⃣ Герингер Владимир - директор бизнес-аналитики, GLS pharmaceuticals: "Информационная система: архитектура решения"
Автор канала: PharmaDataLab
2️⃣ Снигирев Дмитрий - тимлид Core BI - Авито: "Как выглядит роль BI аналитика в требованиях разных компаний"
Автор канала: Делаю BI
3️⃣ Корнев Иван - аналитик данных: "Приблизительный подсчёт уникальных записей в SQL"
Автор канала: Откровенная аналитика
Приходите, будет интересно!
Ссылка для подключения: https://telemost.yandex.ru/j/65617501912823
🔥 - ставь, если придешь в эфир