Вас спрашивали «Кем Вы видите себя через 5 лет»? Меня тоже. За двадцать пять лет в IT я понял, зачем они так делают. Понял – это значит, что я «привык и научился пользоваться» (С). Но «неприятно удивлять» они меня не перестали.

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

Дисклеймер:

Я не призываю врать или «играть по правилам» HR. Я делюсь практической схемой подачи опыта и скиллов, чтобы минимизировать отказы «по софтам». В моем случае она работает.

Портфельная теория Марковица(далее ПТМ) (Modern portfolio theory) — разработанная Гарри Марковицем методика формирования инвестиционного портфеля, направленная на оптимальный выбор активов, исходя из требуемого соотношения доходность/риск. Сформулированные им в 1950-х годах идеи составляют основу современной портфельной теории.

Основные положения портфельной теории были сформулированы Гарри Марковицем при подготовке им докторской диссертации в 1950—1951 годах.

Рождением же портфельной теории Марковица считается опубликованная в «Финансовом журнале» в 1952 году статья «Выбор портфеля». В ней он впервые предложил математическую модель формирования оптимального портфеля и привёл методы построения портфелей при определённых условиях. Основная заслуга Марковица состояла в предложении вероятностной формализации понятий «доходность» и «риск», что позволило перевести задачу выбора оптимального портфеля на формальный математический язык. Надо отметить, что в годы создания теории Марковиц работал в RAND Corp., вместе с одним из основателей линейной и нелинейной оптимизации — Джорджем Данцигом и сам участвовал в решении указанных задач. Поэтому собственная теория, после необходимой формализации, хорошо ложилась в указанное русло.

"Лежит на струнах пыль
Ржавеет под окном
Разбитый телевизор
Ты сгладил все углы
И жизнь твоя сплошной
Проклятый компромисс
Ни вверх ни вниз"

Так поёт группа Би-2 в песне "Компромисс" и с ними трудно не согласиться. Наша жизнь действительно состоит из сплошных проклятых компромиссов между несколькими решениями. Мы пытаемся найти максимально дешёвую, но качественную электронику, ищем экономичный, но быстрый автомобиль и красивого, но надёжного партнёра для отношений.

Каждая из этих повседневных задач заключается в поиске оптимума нескольких конфликтующих между собой функций. Это называется многокритериальная оптимизация (Multi-objective optimization). В этой статье мы ближе познакомимся с этой задачей, посмотрим на 2 популярных метода её решения и узнаем, как с её помощью заработать на криптовалюте с минимальным риском.

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

При помощи api2app можно быстро создать графический интерфейс для API. Его можно использовать для тестирования или демонстрации работы вашего API. Созданным приложением можно поделиться со всеми желающими или использовать по приватной ссылке.

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

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

Вам кажется, что ничего особенного в работе не делаете и среди коллег не особо выделяетесь? Или переживаете, что руководитель стал отстраненнее общаться и ищет нового сотрудника? Тогда бегом за обратной связью по работе. В статье привожу примеры, как получить бережный фидбек, чтобы не надумывать, быть в контакте с реальностью, подсветить точки роста и не чувствовать себя разочарованным.

В тексте найдете:

• 5 шаблонов-вопросов для запроса обратной связи;

• варианты сообщений, чтобы пригласить коллегу на встречу для получения фидбека;

• тест.

На рынке не так много книг, которые помогают начинающим тимлидам, которые еще вчера писали код и строили архитектуру, понять, как нужно приступать к работе с людьми и строить свое развитие по ветке управления. Это, естественно, две популярные книги: "Мама, я тимлид!  Практические советы по руководству IT-командой" Перескоковой Марины и "Как пасти котов. Наставление для программистов, руководящих другими программистами" Дж. Ханк Рейнвотера.

И вот на свет вышка книга: "Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Needs", которую Издательство Питер @ph_piter перевело как: "Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО". Не нужно пугаться позиции "Software Engineering Manager" - это именно что тимлид в понимании рынка РФ. И эта книга по своей сути является такой же отправной точкой в карьере начинающего тимлида, как и две предыдущие, но немного иначе!

Разберем популярные паттерны проектирования ML-систем для ответа на следующие вопросы:

1. Какой способ выбрать для деплоя модели в production?

2. Как затащить составной ML-пайплайн в real-time сервис?

3. Каким способом тестировать новую версию модели?

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

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

Я составил список своих задач и разбил их на категории. Кстати говоря, добрую половину этих задач я повесил на себя сам.

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

KoboldAI - удобный граф. интерфейс для запуска вообще всех GPT-подобных текстовых нейронок, которые поддерживает библиотека transformers. Онлайн версия со всякими модельками.

Vicuna 1.1 - очень хороший чат-бот на базе слитой LLaMa от фейсбука на 7 миллиардов, специально квантованная в 4бита и сконвертированная в формат ggml для быстрой работы на ЦПУ с граф. интерфейсом koboldcpp. Умеет в русский. Требует от 4гб RAM и процессор с AVX (любой после 2009 года вроде). Koboldcpp тоже может запускать почти всё текстовое в ggml. Онлайн версию 1.0 можно попробовать здесь.

NLLB - переводчик от фейсбука между 200 языками. Запуск не совсем однокнопочный и в jupytere, на цпу. Жрёт 4 гига оперативы. Онлайн демка.

FreeVC - не очень хороший, зато открытый клонер голоса с одного аудио на другое. Запуск тоже немножко через консоль, зато с вебгуем и на цпу. Онлайн потыкать здесь.

Whisper - транскрибатор на 60 языках от openai, работает на ЛЮБОМ гпу, даже на встроенном в ноутах(на цпу тоже, но немного помендленнее), ест мало видеопамяти, но есть и большие прожорливые модельки. Очень хорошая онлайн демка.

1. Руководитель недостаточно времени уделяет хорошим сотрудникам

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

Богдан Печёнкин, автор Симулятора ML, собрал 10 ошибок специалистов, которые зачастую встречаются в первые годы карьеры.

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

Почему так происходит? Потому что с вами люди, а люди все разные. Ничего удивительного. Менеджмент находится на пересечении науки и искусства. И все это именно из‑за наличия здесь людей. Нельзя просто взять какой‑то готовый инструмент и просто им пользоваться. Приходится креативить, адаптировать под своих сотрудников.

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

Как именно — приглашаю почитать.

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

Привет, Хабр!

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

Эта статья может быть интересна ребятам, которые переходят в новые компании на руководящие должности техлидов и тимлидов, либо разработчикам, которым выпало неожиданно возглавить не их «родные» команды.

Итак, рассмотрим ситуацию, когда в команду разработки (или в командЫ разработки) приходит новый руководитель, о котором самим участникам команды ничего не известно. И этот руководитель — вы.