Если кандидат не разбирается в односвязных списках, то он, как правило, не разбирается в структурах данных вообще.
Если кандидат не разбирается в структурах данных, то он, как правило, не умеет писать эффективные реализации алгоритмов на высокоуровневых языках программирования, где эти структуры данных уже реализованы.
И пишет потом в прод:
xs = list(...)
ys = list(...)
for y in ys:
if x in xs:
...
и тому подобное.
Односвязные списки – отличный фильтр, с которого можно начать блок вопросов про структуры данных.
И когда вы в Okko добавите поддержку автофреймрейта (preferredDisplayModeId) в версии для Android TV? (в последний раз, когда смотрел вашу программу, поддержки не было)
Скор первого места – 0.048, скор нашей системы на тех же данных – 0.061. Но тут нужно принимать во внимание смещение, вызванное работой продуктовой системы во время сбора данных.
На Netflix гораздо меньше библиотека, если не считать их оригинального контента. Например, там никогда не будет новинок, потому что студии не открывают подписные права на новинку ни для одного игрока рынка. У нас же новинки будут доступны для покупки.
Или всё же полученная сейчас модель и так дает нечто среднее, взвешенное по активности между всеми членами семьи, и все ок?
Нет, далеко не всё ок. Есть известные кейсы, когда вся семья пользуется Okko и в рекомендациях полно мультиков, т.к. ребёнок, естественно, смотрит больше всех. Для родителей такие рекомендации не релевантны и они туда не заглядывают. Хотя там и может быть ~20% релевантного родителям контента, но они не будут выискивать его среди кучи не релевантного.
Вряд ли кто ответит честно — и так всем надо чрезмерно много неочевидно зачем нужных данных, и людей это выбешивает.
Ну, если пользователь хочет получать релевантные персональные рекомендации и понимает, что без выбора своего профиля их не получить, то выбора у него не будет.
Скорее перспективно угадывать по устройству, времени и дню недели, таймингам между нажатиями… но вот как подготовить датасет для обучения, не зная таки, кто именно смотрел?
Это ОЧЕНЬ сложная задача, которая совершенно точно не может быть решена с идеальной точностью. Соответственно, всегда будут ошибки и всегда будут недовольные пользователи. Спрашивать пользователя – вполне нормальная практика. Так делает, например, Netflix, а опыта в UI/UX у них полно.
"Лучшее" – это просто лента постов за день, отсортированная по рейтингу. Утром постов мало и даже новый пост с небольшим рейтингом может там оказаться.
Если честно, я был бы только рад заплатить хабру за трафик и промоутинг, но такой возможности, к сожалению, нет.
Аккаунты, которыми пользуются сразу несколько человек, – один из главных пунктов нашего плана развития. Самое правильное решение здесь – перед началом сеанса спрашивать кто сейчас смотрит.
Если писать тесты "правильно", то они будут фактически повторять реализацию проверяемой функции и сравнивать две эти реализации.
На мой взгляд такой подход вреден, т.к:
1) необходимо выполнить двойной объём работы,
2) если ошибка кроется в логике или неправильном понимании требований, обе реализации будут содержать одну и ту же ошибку.
А тесты в виде набора правил входные данные -> выходные данные:
1) простые, быстро пишутся,
2) практически невозможно допустить ошибку,
3) выходные данные придумываются ещё до написания функции (берутся из бизнес-требований, считаются на бумажке или другой реализацией), поэтому не подвержены логическим ошибкам, допущенным при написании функции.
Ошибки в тестах не могут остаться незамеченными и привести к серьёзным последствиям, ведь обнаружив несоответствие, вы сначала проверите тестируемую функцию, а затем и сами тесты.
Если кандидат не разбирается в односвязных списках, то он, как правило, не разбирается в структурах данных вообще.
Если кандидат не разбирается в структурах данных, то он, как правило, не умеет писать эффективные реализации алгоритмов на высокоуровневых языках программирования, где эти структуры данных уже реализованы.
И пишет потом в прод:
и тому подобное.
Односвязные списки – отличный фильтр, с которого можно начать блок вопросов про структуры данных.
Очень круто! И coverage 100% радует. Попробуем по возможности.
Обзоры фильмов? Вроде нет такого хаба.
Передал пожелание в отдел разработки.
Зачем это на Хабре? Контент явно для пикабу.
Скор первого места – 0.048, скор нашей системы на тех же данных – 0.061. Но тут нужно принимать во внимание смещение, вызванное работой продуктовой системы во время сбора данных.
На Netflix гораздо меньше библиотека, если не считать их оригинального контента. Например, там никогда не будет новинок, потому что студии не открывают подписные права на новинку ни для одного игрока рынка. У нас же новинки будут доступны для покупки.
Нет, далеко не всё ок. Есть известные кейсы, когда вся семья пользуется Okko и в рекомендациях полно мультиков, т.к. ребёнок, естественно, смотрит больше всех. Для родителей такие рекомендации не релевантны и они туда не заглядывают. Хотя там и может быть ~20% релевантного родителям контента, но они не будут выискивать его среди кучи не релевантного.
Ну, если пользователь хочет получать релевантные персональные рекомендации и понимает, что без выбора своего профиля их не получить, то выбора у него не будет.
Это ОЧЕНЬ сложная задача, которая совершенно точно не может быть решена с идеальной точностью. Соответственно, всегда будут ошибки и всегда будут недовольные пользователи. Спрашивать пользователя – вполне нормальная практика. Так делает, например, Netflix, а опыта в UI/UX у них полно.
"Лучшее" – это просто лента постов за день, отсортированная по рейтингу. Утром постов мало и даже новый пост с небольшим рейтингом может там оказаться.
Если честно, я был бы только рад заплатить хабру за трафик и промоутинг, но такой возможности, к сожалению, нет.
Но в статье нет описания никаких технологий, только реклама.
¯\_(ツ)_/¯Странно думать, что эта статья была написана ради рекламной кампании АПЛ. То что дата публикации совпала с анонсом цен – совпадение.
По поводу ценообразования могу лишь напомнить классическую диаграмму:
Аккаунты, которыми пользуются сразу несколько человек, – один из главных пунктов нашего плана развития. Самое правильное решение здесь – перед началом сеанса спрашивать кто сейчас смотрит.
Очень классно, спасибо что поделились.
Хаб Big Data лишний.
Хорошая статья, спасибо.
Выглядит как первоапрельская шутка.
Ну то есть практически никогда не мешает :)
Так я с вами и не спорю, у вас тесты правильно написаны :)
Если писать тесты "правильно", то они будут фактически повторять реализацию проверяемой функции и сравнивать две эти реализации.
На мой взгляд такой подход вреден, т.к:
1) необходимо выполнить двойной объём работы,
2) если ошибка кроется в логике или неправильном понимании требований, обе реализации будут содержать одну и ту же ошибку.
А тесты в виде набора правил входные данные -> выходные данные:
1) простые, быстро пишутся,
2) практически невозможно допустить ошибку,
3) выходные данные придумываются ещё до написания функции (берутся из бизнес-требований, считаются на бумажке или другой реализацией), поэтому не подвержены логическим ошибкам, допущенным при написании функции.
Ошибки в тестах не могут остаться незамеченными и привести к серьёзным последствиям, ведь обнаружив несоответствие, вы сначала проверите тестируемую функцию, а затем и сами тесты.