Много людей, в первый раз сталкивающихся в работе с датчиками, склонны считать, что получаемые показания — это точные значения. Некоторые вспоминают, что в показаниях всегда есть погрешности и ошибки. Чтобы ошибки в измерениях не приводили к ошибкам в функционировании системы в целом, данные датчиков необходимо обрабатывать. На ум сразу приходит словосочетание “фильтр Калмана”. Но слава этого “страшного” алгоритма, малопонятные формулы и разнообразие используемых обозначений отпугивают разработчиков. Постараемся разобраться с ним на практическом примере.

Часть первая. Конфликт

Среда, 4 марта 2020, полдень

Я отдыхаю дома. Звонит наш техдир Рома:
— Миша, когда ты будешь на работе?
— Я решил сегодня остаться дома.
— Хорошо, я передам руководству
— По ТК есть норма, что если 15 дней задержка, то можно не выходить
(на тот момент я не видел зарплаты больше месяца)
— Да, я знаю
Рома перезванивает мне через 15 мин:
— Во сколько ты можешь приехать за зарплатой?
— Давай уже завтра, как обычно
— Хорошо, тогда до завтра

Привет, меня зовут Вася Рубцов, я занимаюсь разработкой рекомендательных систем в Авито.

Основная цель площадки для размещения объявлений — помочь продавцам найти покупателей, а покупателям — товары, которые они ищут. В отличие от интернет-магазинов факт продажи происходит за пределами нашей платформы, и мы не можем это отследить. Поэтому ключевой метрикой у нас является «контакт» — это событие нажатия кнопки «показать телефон» на карточке товара, либо начало диалога в мессенджере с продавцом. Из этой метрики мы получаем «байеров» — количество уникальных пользователей в день, которые сделали по крайней мере один контакт.

Два основных продукта, которым занимается отдел рекомендаций в Авито, — это рекомендации для пользователя на главной странице или user2item и блок похожих объявлений на карточке товара или item2item. Треть всех просмотров объявлений и четверть всех контактов происходит с рекомендаций, поэтому рекомендательные движки играют важную роль в Авито.

В статье я расскажу, как мы улучшили наши item2item рекомендации за счёт item2vec и как это повлияло на user2item рекомендации.

^{Моё домашнее рабочее место}

Да, о работе из дома есть уже миллион текстов, в том числе и на Хабре. Но многие советы из них вроде «оденьтесь по-офисному, и тогда будет рабочий настрой» для меня выглядят слишком обобщающими. Люди разные, и одним формальная одежда действительно помогает, а другим куда лучше работается в пижаме.

Поэтому сейчас, когда с удалёнкой столкнулось много новых людей и им полезна информация, я решил написать о ней немного по-другому. В тексте разделены общие соображения и мой личный опыт. Не надо считать этот опыт «правильным», ваш может очень отличаться. Скажем так, в тексте есть абстракция и пример реализации — а дальше вам надо разобраться, как всё имплементировать конкретно в вашем случае.

Я работаю из дома много лет (сначала как фрилансер, сейчас как штатный удалённый сотрудник с фиксированным графиком), а также читал много чужих текстов об удалёнке. Всё это не сделало меня идеалом эффективности, у меня самого не во всём получается следовать собственным советам. Но они заметно помогают мне, и если вы сейчас оказались на удалёнке, то могут помочь и вам. Также буду рад дополнениям в комментариях.

Как все начиналось

Эта история началась 15 лет назад. Работая программистом в столице, я накапливал деньги и увольнялся, чтобы потом создавать собственные проекты. Для экономии средств уезжал домой, в небольшой родной город, где работал над сайтом для студентов, программой для торговли, играми для мобильных телефонов. Но из-за отсутствия опыта ведения бизнеса это не приносило дохода, и вскоре проекты закрывались. Приходилось снова ехать в столицу и устраиваться на работу. Эта история повторилась несколько раз.

Когда у меня в очередной раз закончились деньги, наступил кризис. Я не смог найти работу, ситуация стала критической. Пришло время посмотреть на все вещи трезвым взглядом. Нужно было честно признаться себе, что я не знаю, какие ниши выбрать для бизнеса. Создавать проекты, которые просто нравятся, — путь в никуда.

За последние несколько лет в обучении с подкреплением (reinforcement learning, RL) произошли серьезные прорывы: от первого успешного его использования в обучении по сырым пикселям до обучения Open AI роборуки, ― и для дальнейшего прогресса становятся необходимы все более сложные среды, в чем на помощь приходит Unity.

Инструмент Unity ML-Agents ― это новый плагин в игровом движке Unity, позволяющий использовать Unity как конструктор среды для обучения МО-агентов.

От игры в футбол до ходьбы, прыжков со стен и обучения ИИ собаки игре с палкой, Unity ML-Agents Toolkit предоставляет широкий спектр условий для тренировки агентов.

В этой статье мы рассмотрим, как работают МО-агенты Unity, а затем научим одного из таких агентов перепрыгивать через стены.

В прошлой статье рассмотрено как можно получить информацию по финансовым инструментам. Дальше будет опубликовано несколько статей о том, что первоначально можно делать с полученными данными, как проводить анализ и составлять стратегию. Материалы составлены на основании публикаций в иностранных источниках и курсах на одной из онлайн платформ.

В этой статье будет рассмотрено, как рассчитывать доходность, волатильность и построить один из основных индикаторов.

Появление async/await в C# привело к пересмотру того, как писать простой и корректный параллельный код. Зачастую, используя асинхронное программирование, программисты не только не решают проблемы, которые были с потоками, но и привносят новые. Дедлоки и рейсы никуда не пропадают — их просто становится труднее диагностировать.



Дмитрий Иванов — Software Analysis TeamLead в Huawei, в прошлом техлид JetBrains Rider и разработчик ядра ReSharper: структур данных, кэшей, многопоточности, регулярный спикер конференции DotNext.

Под катом — видеозапись и текстовая расшифровка доклада Дмитрия с конференции DotNext 2019 Piter.

Эта статья написана как ответ на статью «Собеседование в Додо Пиццу» со стороны разработчика с опытом синьора. Я не претендую на истинность суждений, мне хотелось бы выразить довольно популярное среди моих знакомых мнение о процессе найма в частности и жизни разработчика в целом.

Представьте Ваши ощущения, если Вам будет предложено сдавать экзамен на водительские права каждый раз при смене автомобиля той же категории. Я не буду спорить, что каждый водитель должен знать правила дорожного движения наизусть, однако в реальности такие водители встречаются крайне редко. Подавляющее большинство водителей, управляя автомобилем уже несколько лет, держат в голове только ключевые правила, например, движение на перекрестке. У подавляющего большинства водителей годами не случается ни одного ДТП. А ведь именно безопасность дорожного движения является основным назначением правил дорожного движения.

В итоге пересдача прав случается только со злостными нарушителями дорожного движения. При поступлении на работу водитель обязан просто показать права, он не обязан сдавать экзамен. Так почему же разработчик должен каждый раз доказывать свою профессиональную пригодность? Кто-то скажет, что далеко не у каждого программиста есть сертификаты (аналог водительских прав) и что далеко не каждая технология вообще может быть сертифицирована. Согласен, но только в случае приема на работу выпускников учебных заведений, не имеющих опыта, и только в случае, если диплом непрофильный. В случае, если есть документальные подтверждения предыдущего опыта работы в аналогичной должности, уверен, можно обойтись без тестирования.

Кроме того, испытательный срок никто не отменял, и всегда можно уволить человека в этот период, если совершена ошибка. От ошибок работодатель не избавится, даже если будет применять онлайн тестирование, они будут в любом случае.

Вместо введения

Давным давно была первая часть, теперь настало время для второй части! Здесь затронем вопросы, связанные с теорией вероятностей.

Вряд ли среди наших читателей есть школьники, которые размышляют над карьерой, но скорее всего, есть дети-племянники, которые уже спрашивают: «Куда пойти учиться после школы, чтобы стать, как ты?»

В ряде интервью, как с отечественными CTO, так и с западными разработчиками из Google и Tungsten Labs, я раз за разом встречался с мнением, что при приёме на работу высшее образование не является необходимым фактором, а его отсутствие не считается «стоп-флагом» на собеседованиях в западных компаниях. Больше внимания уделяется знаниям и навыкам, которые порой человек получил и изучил самостоятельно.

И тогда мы в Southbridge решили провести небольшое исследование среди знакомых CTO, СEO и руководителей разработки.

Три года подряд я проводила лето на стажировках в компании Google: сначала в Цюрихе, затем в Лондоне и, наконец, в Саннивейл (город в штате Калифорния, США). В этом посте я поделюсь тем, как подавать заявки и проходить собеседования, какими проектами я занималась и чем стажировки в Европе отличались от США. А еще расскажу, чем Цюрих понравился мне больше Кремниевой долины, где лучше обеды и вечеринки и почему я пока решила остаться в России.

Когда мне было семь, папа купил наш первый Ардуино и мы сделали игрушку для котов. Лазерная указка подвешивалась на два сервомотора и пускала луч — а животные носились за красной точкой по комнате. Я стал копатьcя в программе, что написал отец, пытаясь понять, как все работает… и так попробовал C++.

Быстро поняв, что “плюсы” для первоклассника как-то не очень, а вот программировать мне интересно, я засел за Scratch — учить его как раз посоветовал папа. Когда перерос его, отец показал пару приёмов на Python. Потом был классический путь: захотелось смастерить веб-страничку, засел за jQuery, JS-фреймворки и Node.js. И вот он я)

Недавно в корпоративном блоге Parallels выходила статья, где приводились размеры оплаты труда разработчиков на западе со словами "в любом случае российские зарплаты пока не дотягивают до европейских". Частое столкновение с тем, как люди очень выборочно сравнивают условия жизни поросенка Петра и тех, кто не уехал, побудили поделиться некоторыми наблюдениями о жизни в США изнутри. Цель данного поста — подтолкнуть подходить к вопросу комплексно и делать сравнение яблок с яблоками, а не точечно сравнивать то, что выгодно, и закрывать глаза на остальные важные аспекты. Если вам покажется, что в данной статье есть иные подтексты — прошу списать это на то, что "чукча — не писатель" и по возможности игнорировать их.

Всем привет! Я руковожу командой антиспама в Mail.ru Group, а также несколькими группами по машинному обучению. Тема этой статьи — саморазвитие для тимлидов/руководителей, но на самом деле многие техники и рецепты совершенно не зависят от роли. Для меня этот вопрос очень актуален, так как машинное обучение развивается крайне стремительно, и чтобы хотя бы быть в теме, надо потратить уйму времени. Поэтому вопрос, как и на что тратить время для развития, стоит достаточно остро.

Контент статьи, разумеется, не истина в последней инстанции, а всего лишь описание результатов моего продолжающегося квеста, в котором изложены сработавшие для меня подходы, основанные на книгах и тренингах, на пробах и ошибках. Буду рад подискутировать с вами в комментариях.

tl;dr За последние десятилетия мода на собеседования программистов менялась несколько раз, и каждая из них выглядит нелепо в ретроспективе. Либо мы наконец-то нашли настоящий секрет эффективных собеседований, либо увлеклись очередным модным течением, которое через десять-двадцать лет покажется столь же нелепым.

Когда я спрашиваю людей в модных больших технологических компаниях, почему на собеседовании так обязательно спрашивать об алгоритмах, самый распространённый ответ — что-то вроде: «У нас такой масштаб, мы не можем позволить, чтобы кто-то случайно написал функцию O(n^2) и повалил всю систему»¹. Что особенно забавно, в последнее время я немало применял на практике эти алгоритмы и решал реальные проблемы, но не могу пройти собеседования, где о них спрашивают! Думаете, я проваливаю половину собеседований или что-то в этом роде? Нет, больше половины. Я участвовал примерно в 40 «настоящих» собеседованиях и прошёл, может, одно или два. Или ни одного².

Когда я написал черновик этой статьи, друзья посчитали его занудным, потому что я провалил слишком много собеседований. Они говорят, нужно свести все неудачи в таблицу, потому что никто не станет читать десять страниц текста с длинным перечнем неудач. Хороший совет. Уже работаю над таблицей.

На Хабре с завидной периодичностью возникают посты от возмущенных программистов, которые справедливо (наверное) негодуют, почему на собеседовании никто не спросил про их прошлые проекты, не посмотрел их код, но задавал шаблонные справочные вопросы или заставлял решать алгоритмические задачи, которые, скорее всего (в 99%), не будут применяться на вакантной работе.

Чтобы уменьшить поток этих публикаций (святая простота), ниже будет краткий, но лаконичный справочник по типам собеседований, которые вам стоит ожидать от конкретного типа компании. Справочник основан на личном многолетнем опыте. Надеюсь, это поможет вам (именно тебе, да) выбрать лучшую стратегию успешного получения работы.

Наш отчёт по зарплатам в ИТ за второе полугодие 2019 года построен на данных из калькулятора зарплат Хабр Карьеры, в котором за этот период было собрано более 7000 зарплат.

В отчёте мы посмотрим на текущие зарплаты по основным ИТ-специализациям, а также на их динамику за прошедшее полугодие как в целом по стране, так и отдельно по Москве, Санкт-Петербургу и остальным городам. Как обычно, детальнее изучим специализации разработчиков ПО: посмотрим на их зарплаты в разрезе языков программирования, городов и компаний.

Данные, представленные в этом отчёте, а также любые другие, каждый желающий может получить самостоятельно с помощью калькулятора зарплат Хабр Карьеры. Если вам нравится информация, которую мы получаем с помощью калькулятора, и если вы хотите внести свой вклад в формирование более прозрачного рынка труда в ИТ, приглашаем поделиться своей текущей зарплатой, данные о которой мы используем в нашем следующем годовом отчёте.

Сервис зарплат запущен на Хабр Карьере в конце 2017 с целью регулярного мониторинга зарплат в ИТ-индустрии. Зарплаты оставляют сами специалисты, мы их собираем и предоставляем всем в открытый доступ в агрегированной и анонимной форме.

Прочитав этот пост, написанный farwayer, сначала хотел просто оставить комментарий, но, подумав пару десятков минут, решил, что тема глубокая, и мне есть что сказать на целый пост. Все таки, с одной стороны, я один из тех, кто на собеседованиях не смотрит на код и кого разочаровывает незнание оценки сложности поиска по индексу в реляционных СУБД, с другой, считаю, что могу дать понимание того, как мыслит достаточно большой кластер интервьюверов, зачем они поступают (на первый взгляд) нелогично и деструктивно, и какие проблемы сами хотят этим решить. Есть надежда, что понимание картины мира «врага» само по себе ответит на множество вопросов.