#работа #лабораторный_журнал

Я бы не сказал, что мы до сих пор хорошо справлялись с наймом MLE. Мы отсобеседовали много людей, но всех отсеяли. Главная проблема: необходимость поиска внутри Португалии. На позицию подавались почти исключительно свежие выпускники двух местных институтов. Или вчерашние студенты, или другие люди вообще без релевантного опыта. Ожидаемо: непросто затащить людей в Коимбру.

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

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

Теперь вместе с ролью лидера по данным на меня свалился найм на еще две позиции: Data Analyst и Data Engineer. На практике все это выражается в шести собеседованиях на следующей неделе, плюс время на отсмотр резюме и ответы на почте.

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

Когда ищешь работу думаешь: "Вот если бы я нанимал, то все было бы не так!" В итоге обнаруживаешь, что твой максимум это сделать процесс чуть менее ужасным: не гостить, не токсить, не затягивать с ответом, защитить от "лучших" практик HR типа IQ тестов. The game is rigged from the start.

Надо отметить, что мой руководитель великолепно собеседует людей и я многому учусь. Приятный плюс работы в PF.

#работа

# Другая сторона найма

Поиск инженеров в PF это мой первый опыт полноценного процесса найма. Хочу поделиться несколькими наблюдениями.

1. Для работодателя найм это тоже numbers game.

Со стороны работодателя даже в большей степени, чем со стороны соискателя! Мы не так долго и активно ведем процесс, но на одну позицию уже отсмотрели более 200 резюме. Естественно большая часть отсеивается на этапе резюме и HR скрининга: до интервью дошло только 12 человек. При этом если соискатель тратит на поиск работы только свое время, то работодатель тратит время трех и более человек.

2. Релевантность опыта важнее общей крутизны.

Оказалось, что мне, как нанимающему инженеру в небольшой компании, важно, чтобы человек имел подходящий опыт. В идеале чтобы он уже решал раньше те задачи, для которых мы его нанимаем. Это может быть даже важнее чем его общие способности. Например, мы отсеяли одного сильного full stack инженера, который хотел сменить карьерный трек на MLE. Ну не знает человек, что такое градиентный спуск, и тут ничего не поделаешь: слишком долго придется ждать, пока он станет приносить пользу.

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

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

3. У компании, в отличие от работника, всегда есть заранее определённая зарплатная вилка.

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

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

В этом случае у компании есть гибкость в принятии решений, что дает работнику с хорошей переговорной позицией преимущество. Используйте это в свою пользу.

4. Прыжки через обручи не обязательно красный флаг.

Бывает, что компания заставляет вас пройти какой-нибудь дурацкий personality test. Выглядит как будто это признак того, что работать там будет непросто. Однако на практике это может быть просто причуда HR, которая никак не влияет на работу в компании и с которой технари ничего не могут поделать.

Вывод: стоит оценивать позицию в первую очередь по нанимающей команде.

5. Мотивационные письма не читают.

Я честно стараюсь просматривать их хотя бы по диагонали, но факт остается фактом: еще ни разу мотивационное письмо не повлияло на мое решение.

Возможно мотивационное письмо влияет на HR. Так это или нет я, к сожалению, не знаю.

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

# Эксель как тропа через газон

Когда программист начинает заниматься инфраструктурой аналитики у него возникает соблазн сразиться с экселем.

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

Любой, кто освоил простой анализ табличек на python, приходит в ужас, когда обнаруживает, что ключевые процессы в компании держатся на ЭТОМ. Кажется, будто можно заменить много неудобных таблиц на несколько красивых дешбордов, построенных в модном BI инструменте. И сразу принести пользу. Поставить в резюме, что совершил цифровую трансформацию бизнеса.

Но это заблуждение!

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

Пользователю нужно свести два набора данных и у него появляется выбор: просить разработку сделать новую сложную штуку или быстро сделать таблицу. Он выбирает второе, т.к. не знает, пригодится эта таблица в будущем или нет. Если это расчет на один раз то эксель как раз подходящий инструмент. Но если таблица оказывается полезной, то ей начинают часто пользоваться, расширять ее и давать доступ разным людям. Незаметно одноразовая табличка превращается в критический компонент системы.

Эксель это как тропинка, протоптанная через газон в обход неудобного асфальтированного пути.

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

# Разыгрываю Playstation 5 в честь 5000 подписчиков!

Выберу победителя рандломайзером сегодня в 00:00. Как доставить придумаем после.

Форма для записи на розыгрыш здесь, оставляйте свой телеграм юзернейм .

———

Ладно, шутка, я по вашему миллиардер что-ли? Не заезженная шутка а золотая классика

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

В последнее время я стал меньше писать про личное и больше про профессиональное. Давайте в честь такого события устроим AMA (ask me anything). Задавайте любые вопросы в комментариях, а я попробую честно ответить

Любители roguelike здесь?

# Этот простой трюк увеличивает продуктивность джуна вдвое, нужно лишь…

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

На 1х1 подсказал ему такую вещь: deliverables. Каждый день или даже каждый час у твоей работы должен быть конкретный результат, которым можно поделиться (но не всегда нужно). Это может быть что угодно: релизнул фичу, написал класс, написал тест, разобрался в работе куска кода. Главное, чтобы это был маленький результат. Тогда ты переходишь из одного стабильного состояния системы в другое и маленькими шажками приближаешься к конечному результату. Это удобно совмещать с хорошими практиками git: один результат — один коммит, и каждый коммит оставляет систему в рабочем состоянии.

По итогам продуктивность заметно выросла. Дополнительный плюс: если делишься результатами с коллегами, просто отписав в слек чат, то все видят, какой ты молодец, становится приятно, и синдром самозванца отступает.

Надеялся, что ChatGPT будет моим репетитором по математике и научит меня доказательствам.

Но она начала врать даже на детской задаче

By https://xn--r1a.website/seeallochnaya

Подглядев за Ваней (https://xn--r1a.website/adventures_somewhere), который сходил на митап любимого наси обоими блога ACX (www.astralcodexten.com), я нашел такой же в Лиссабоне. Лучшие полтора часа жизни за неделю. Наконец-то cнова оказался в привычном кругу интересных нердов, отчего и сам почувствовал себя интересным человеком. Была очень разная публика: один парень делает юридический софт на LLM, другой профессиональный игрок в покер, третий рисерчит что-то про то, как нам выживать в постапокалипсисе, а одна дама какой-то крутой юрист в эффективном альтруизме. Это конечно не калифорнийский weird ai safety sex cult, но все равно было прикольно

#обзор_статьи #ml

# Explaining grokking through circuit efficiency, Vikrant et. al

Я обожаю статьи где берут маленькую модель и изучают фундмантельные свойства нейронных сетей.

Статья про grokking: откуда он возникает. Grokking это явление, когда предобученная нейронная сеть сначала переобучается под тренировочные данные (трейн лосс идет вниз, а тест лосс идет вверх), а затем вдруг начинает обучаться обобщаемому решению (тест лосс идет вниз, трейн лосс остается маленьким). Раньше предполагалось, что происходит так: сначала нейронная сеть находит решение, которое идеально описывает трейн сет, а затем начинает под воздействием регуляризации перебирать разные решения, которые и описывают трейн сет, и имеют маленькую норму параметров. То есть нейросеть как бы ищет более простое решение задачи.

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

Основная идея в circuits — механизмах, состоящих из множества нейронов, которые нейросеть использует для принятия решения. Грубо говоря circuit это набор нейронов, которые выполняют одну функцию. Например, предсказывают один класс (т.е. отвечают за один выходной логит). Подронее про circuits в моделях можно почитать на distil.pub в прошлых работах Chris Olah. Там довольно прикольно: например есть circuit отвечающий за распознавание Дональда Трампа в текстах и изображениях.

Авторы обнаруживают, что существует два семейства circuits. Первое, C_mem, запоминает тренировочный датасет. Второе, C_gen, изучает обобщаемое решение. C_mem зависит от количества данных. При добавлении одного примера в датасет C_mem приходится его запоминать, изменить решение и возможно сделать его чуть хуже. C_gen же имеет большую эффективность: при добавлении одного примера в датасет C_gen чаще всего предсказывает его верно и не меняется. Значит C_gen не может быть хуже C_mem, но чаще всего оказывается лучше. Таким образом достаточно обученный C_gen почти не зависит от размера датасета.

Эффективность C_gen авторы определяют следующим образом: норма параметров. C_gen выдает верные ответы на трейн сете, при этом норма параметров у него в среднем меньше, чем у C_mem. Таким образом C_gen может уменьшать оба компонента лосса одновременно: и лосс классификации и регуляризацию на норму весов.

С_gen обучается сильно медленнее, чем C_mem. Поначалу C_mem быстрее снижает лосс просто запоминая примеры, поэтому обучается первым. Однако с увеличением датасета оптимизатор отдает все больше предпочтения C_gen, т.к. тот получает решения с меньшей нормой параметров. При достижении некоторого критического размера датасета C_gen начинает “побеждать” C_mem из-за своей большей эффективности.

При размере датасета больше критического мы наблюдаем grokking. При размере датасета сильно меньше мы наблюдаем переобучение: C_mem имеет больший вес, трейн лосс идет вниз, тест лосс вверх. Наконец, при размере близком к критическому мы наблюдаем что-то среднее, близкое к типичному обучению модели: трейн лосс идет вниз, тест лосс выходит на плато

Если предположения авторов верны мы должны наблюдать два новых феномена:
* Ungrokking: при дообучении модели на маленьком датасете она начинает снова отдавать предпочтение С_mem и теряет способность к обобщению,
* Semi-grokking: при недостаточном количестве данных модель имеет схожие веса для обоих circuits, так что мы наблюдаем что-то среднее.

Чтобы подтвердить все это экспериментами авторы делают простую модель, где заранее задают C_mem и C_gen и наблюдают, как градиентный спуск меняет их веса. В качестве задачи используют сложение по модулю, а в качестве модели однослойный трансформер. В таком случае circuits представляют по сути lookup table для верных ответов, где C_mem содержит ответы для случайно сгенерированных данных, а C_gen верные ответы для настоящих данных.

Эксперименты подтверждают теорию, сейчас покажу картинки

Запускаем много раз обучение для разных размеров датасета. Для C_mem, чем больше датасет, тем больше норма параметров (тем “сложнее” решение). При этом логит становится не сильно больше, т.е. модель не становится увереннее в предсказаниях.

Для C_gen никакой структуры не наблюдается. При увеличении датасета норма параметров не меняется, т.к. модели не нужно запоминать новые примеры.

При дообучении на достаточно маленьком датасете нейросеть начинает снова отдавать предпочтение C_mem, качество на тесте падает, происходит ungrokking

При схожих весах для обоих circuits моделям требуется очень много времени, чтобы достичь высокого качества на тесте. Некоторые выходят на плато, а другие вообще не сходятся. Примечательно, что достаточно долгое обучение как правило приводит к идеальному качеству на тесте даже при маленьком датасете.

Для себя я сделал такие выводы:
* Нейросети способны изучать обобщаемые решения, т.е. они не просто статистические попугаи. Получается, что LLM вполне может строить настоящую модель мира, которая в пределе сходится к истине. Это так же подтверждается статьей, которую я не могу откопать, где модель играла в настольную игру, и покопавшись в ее мозгах ученые обнаружили, что она строит модель всей доски, а не только действий на шаг вперед.
* Существует критический размер датасета, который позволяет изучить обобщаемое решение. Если ты не наблюдаешь grokking, то или данных мало, или учишь недостаточно долго. К сожалению этот критический размер скорее всего очень большой.
* Внутри нейросети есть подсети, которые имеют обобщаемое решение. Было бы очень круто научиться их вытаскивать и выбрасывать все остальное. Вероятно мы увидим какой-то умный прунинг (умнее чем доступный сейчас), который позволит сжимать модели еще больше.