То что мы делаем сейчас в GenAI - это во многом DevOps работа

Качественно новое, что придумалось за 3 последних года во всем нашем GenAI, - это интерпретатор с любого языка (не только программирования) на любой другой язык. Мы его называем LLM. А раз так, то английский - теперь тоже интерпретируемый язык программирования (пусть и с вероятностной семантикой). Интерпретируемый в bash, python, java, json, xml - ровно как в английский, русский, немецкий, ровно как в user stories, хайку, эссе, письмо - в любой комбинации этих форматов. Можно попросить интерпретировать текст идеи в хайку на немецком, который выдаст текст на питоне, который напечатает текст на джаваскрипте, который будет вставлен внутрь сопроводительного письма в eml-формате. Изи (ну, почти).

 

Новый GenAI инженер - это во многом DevOps

А во многом из того, что мы делаем поверх этого, - очень много от DevOps-работы. Раньше DevOps-специалисты автоматизировали CI/CD на bash/batch, а сейчас любой может автоматизировать на английском любой SDLC. И новый тип инженера, о котором все говорят, - это во многом DevOps-мышление. По сути: прийти на проект, разобраться в SDLC pipeline и тулах, которые использует команда. Автоматизировать его. Показать команде, на какие кнопочки нажимать, чтобы все летело. И потом просто на 15% ассайнмента поглядывать за пайплайном, чтобы не свалился, и если появятся новые требования - оперативно их дореализовать. Коллеги DevOps - поправьте, если не прав.

Это подтверждается и на практике. Во время коучинга, который провожу каждый день, единственная аудитория, которая не удивляется так же, как все, - это DevOps. Все в "щенячьем восторге" от создания всяких DarkFactory, а вот DevOps - "да ладно, мы это всегда делали, просто не все можно было в bash/batch уложить оперативно". Раз так, то давайте переиспользовать многолетний опыт DevOps-специалистов.

Промпт - это исходный код

И второе - раз уж мы относимся к любому тексту как к исходному коду на языке (программирования). Не важно, это ваши данные, вытянутые скиллом из бинарника xls. Или тот же смысл, переданный текстом письма на русском. Или программа, написанная на питоне, делающая то же самое. И мы все программируем. Во многом программируем сейчас в процедурном стиле, создавая маркдаун-документы - читай, процедуры и функции. Так почему бы не переиспользовать все те накопленные знания и умения за последние лет 50 в области программирования? Те же базовые SRP, OCP, DRY, KISS и так далее - вплоть до более сложных, только применительно к новым интерпретируемым благодаря LLM языкам. Простой пример: одна и та же инструкция, повторяющаяся в пяти промптах, - это нарушение DRY, и лечится оно ровно так же, как в коде.

Отсюда следует ещё один важный момент. В мире, где все генерируется из ваших промптов, ваши промпты - и есть source code. Организуйте и храните его в кодовой базе - с версионированием, ревью и историей изменений. Например я использую iterative prompt для общения с агентами. Теперь всегда можно посмотреть как любой участник пришел к тому результату, который мы наблюдаем. Теперь больше не будет вопроса у QA как и почему Dev сделал такой фикс. Теперь можно всегда спросить у агента, гдие и когда такое решение было принято. 

 

Всё сводится к тексту, а текст - к Unix 

Все, что можно свести к тексту сегодня, - будет сведено. Потому что текст - это программа. Бинарник (xls, mp4, zip, docx) сводится к тексту с помощью другого текста - программы на питоне с подключением определенной opensource-библиотеки, организованной в Skills. Если нужно достать данные откуда угодно - тот же Skills в помощь. Skill - это сейчас как Unix tools.

И тут стоит напомнить, откуда растут ноги. Принципы Unix были сформулированы Дугом МакИлроем (создатель pipe в Unix) и развиты в культуре Bell Labs. Классическая формулировка:

• Do one thing and do it well. Одна утилита - одна задача. grep ищет, sort сортирует, wc считает. Не пытаться сделать швейцарский нож.
• Write programs to work together. Утилиты должны быть комбинируемыми. Выход одной - вход другой. Отсюда пайпы: cat file | grep error | sort | uniq -c.
• Write programs to handle text streams, because that is a universal interface.
  Текст - универсальный интерфейс. Не бинарные форматы, не проприетарные протоколы. Простой текст, который читается человеком и парсится другой программой.

Дополнительные принципы (из «The Art of Unix Programming» Эрика Реймонда):

• Rule of Modularity - пиши простые части, связанные чистыми интерфейсами.
• Rule of Composition - проектируй так, чтобы можно было соединять с другими программами.
• Rule of Separation - отделяй политику от механизма (что делать - от того, как).
• Rule of Simplicity - проектируй в сторону простоты, добавляй сложность только когда обязан.
• Rule of Silence - если программе нечего сказать, она должна молчать (никакого лишнего output).
• Rule of Least Surprise - интерфейс должен быть предсказуемым.
• Rule of Repair - если что-то сломалось, ломайся громко и сразу.

Skill - это package, а не откровение 

Концепция Skills очень мне близка с другой, уже известной нам концепцией - package. Любой проект состоит из кирпичей, пакетов. Каждый пакет делает что-то полезное и стоит особняком. Пакет может зависеть от другого пакета. Пакет дает публичный интерфейс и прячет реализацию. Добавьте к пакету Skill.md (как документацию) и снабдите CLI-интерфейсом - и вот вам Skill. А что такое этот Skill.md - это индекс для модельки над внутренностями пакета, чтобы ей не приходилось загружать все файлы в контекст. Это документация, и она дублирует поведение, а значит устаревает. Были бы у нас бесконечные контексты, мы бы не писали эти индексы. Ну то есть в Skill-концепции не так уж и много нового по сути. А раз так, зачем изобретать колесо? Переиспользуем то, что мы уже знаем.

И может быть, MCP тогда не понадобится 

Если принять эту оптику, может быть, и не появится таких штук, как MCP - напрочь искусственных и очень молодых, а значит, не продуманных интерфейсов. Ведь он первый появился в ответ на «нам надо USB между агентными упряжками и остальным миром как провайдерами контекста». Придумали целый протокол. SDK на сервере, SDK на клиенте. К нашему старому доброму REST надо добавить точно такой же сервис, дублирующий API, но через MCP. Потом кто-то подумал: а почему бы не переиспользовать REST? Пишем тонкого клиента - и все.

MCP уйдет. Не только по этой причине. А еще и потому, что тулу в Skill можно сделать такой, которая будет читать файл, класть результат выполнения в другой файл, и при этом моделька не будет вмешиваться (читать, интерпретировать) в эти данные. После этого вторая Skill прочитает файл, превратит его в другой. А моделька - как оркестратор. А вот если окажется, что и сам путь оркестрации уже устаканился - его можно упаковать в pipeline, используя любой доступный для этого конфигурируемый фреймворк.

Отсюда и градация по цене и детерминизму. Можно открыть чат с агентом, выбрать Claude Opus и попросить сделать работу - будет дорого, но сделает. Можно попросить написать скрипты в Skill, которые будут переиспользуемыми и передавать работу друг другу через файлы. Можно попросить сделать упряжку для всего пайплайна. Модельку оставить только там, где детерминированный код невозможно написать.

Вывод: мы не изобретаем - мы переоткрываем 

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

Любые эксперименты - ок, ведь можно открыть что-то новое. Но база посыла в том, что на 90% мы пытаемся пересоздать в GenAI старые концепции, хотя надо их переиспользовать.

Моя версия эмулятора ЛИКа - или почему инженеры делают то, что делают

Мой герой - инженер. Именно ботаны двигают этот мир вперед. 88й год, бытовой самодельный компьютер "Специалист". Небыло не то что "войти в IT" небыло вообще никаких "интернетов" (разработка той самой Всемирной Паутины Веб, или сокращенно WWW, началось годом спустя в 89м). Небыло никакой какой-либо комерческой выгоды. Но у уважающего себя инженера дома был бытовой компьютер (БК), собранный собственноручно по схемам из журналов Радио. Потому что мог. Спасибо Папе, что привил мне любовь к этому делу. (на видео не мой Папа, но мой был таким же чудным).

Поделюсь своей историей, которую хочется продолжать. Если я уйду когда-нибудь из IT, то из кодинга оставлю себе мой ЛИК и все, что с ним связано. Сейчас я пишу эмулятор, делаю реверс инжиниринг реального компа, который совсем недавно попал мне в руки. Делаю это все со скоростью улитки, смакуя каждый момент. Как та вкусняшка, которую хочется есть самой маленькой ложечкой, растирая языком по небу каждый новый кусочек. Конечно на любой проект нужно время, а его как всегда мало. Но даже если бы его было в избытке, мой первый компьютер - штука особенная. Это то, что возвращает магию.

Первым компьютером у меня был Синклер. И конечно же Синклер этот использовался для игр. Их было очень много. Даже в эпоху Дэнди у меня (и всех до кого я мог дотянуться) небыло столько картриджей. Ко мне домой приходли мои одноклассники. Мы все первоклашки. Какая домашка? Мы играли каждый день после уроков. Я был крут. У меня дома было что-то, что ни у кого небыло. Напомню, это были 90е. 1992 год, кажется. И конечно же я успешно забил на учебу. Оценки упали. А Синклер был продан. Травмирующий опыт. Была игрушка и ее забрали. Не делайте так родители, никогда.

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

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

Как говорится: нифига не понятно, но очень интересно. Одни ошибки попадались чаще всего - 02, например. Другие все никак не поддавались. Так я изучил почти все функции языка и многие corner-кейзы их использования.

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

Потом поломался и Бейсик. Он был записан в ПЗУ. И что-то там видимо перетерлось, т.к. контрольные суммы стали выдавать другое значение - что говорило мне о том, что ПЗУ накрылась. Где накрылась не понятно. Что с этим делать так же не понятно. Больно.

Ковырять чесалось. А потому мое внимание привлек раздел руководства по экплуатации, которое про встроенный ассемблер. Я понимал, что Бейсик - это интерпретатор языка более высокого уровня в машинный код. Я понимал, что процессор выполняет инструкции, которые записаны байтами в оперативной или постоянной памяти. Часть этих байт - инструкции, часть собственно данные. Время пришло.

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

Если ты когда-то смотрел/а фильм Прибытие. Все было именно так. Встреча с пришельцами инопланетянами говорящими на непонятном языке. Они пришли что-то мне дать. Что именно - я должен разгадать. Каждый день я просыпался и все, что хотел - еще немного поговорить с ними. Я делал это весь день и пол ночи. Отвлекаясь только на еду и сон. Это был 5й класс школы на секунду.

Фильм кстати очень рекомендую для многократного пересмотра. 

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

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

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

Так как у меня появились новые-старые игры. Я начал их изучать. Это было не просто. Но постепенно они открывали свои шестнадцатеричные секреты. Подпрограммы Загрузчика. Подпрограммы Монитора. Разные полезные штуки вычлененные из игр. Самая моя большая гордость - это додебажиться до той процедуры, которая отвечает за звучание кринжового голоса говорящего "BUDY" во время заставки одноименной игры. Удаление всего лишнего, так что остается всего 25-30 байт кода. И реализация на основе этого кода диктофона. Мой комп превратился в диктофон, где секунд 5-7 звука записывалось из микрофона в 48 килобайт оперативной памяти. А потом это все RAW воспроизводилось на динамик. И затем снова перезаписывалось с микрофона. Качество конечно было неахти, но все было слышно. После этого я понял - что могу все. Вот прям все.

Затем мой комп поломался вовсе. И я остался с паяльником. Погрузился в мир логических элементов и строил разные примитивные схемки. Читал про моделирование компьютера подобного моему в книге. Паял много. Запах канифоли в носу как сейчас. Светил светодиодами. Обжигал пальцы. Пока не увлекся Химией в 9м классе. 

Конечно я хотел вернуться в эти воспоминания. Я долго искал возможности приобрести компьютер ЛИК. А тем временем я пытался по фоткам плат, доступным схемам сделать свою реплику. Об этом кстати писал в блоге тоже.

Только в позапрошлом году мне удалось на форуме таких же инженеров ценителей ретро компов как и я купить один. 7 лет я за ним охотился. И наконец-то он у меня. Я смотрю на него, он смотрит на меня. Паяльник я уже купил. Скоро он откроет мне все свои тайны. Осцилограф только надо освоить. И купить перед тем.

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

А еще год назад я нашел вот тут эмулятор Специалиста (старший брат ЛИКа) написанного на джаве. Он был переделан из эмулятора Синклера, о чем и как Автор интересно пишет на страничках форума. И пару недель рефакторингов (о которых обязательно расскажу позже, т.к. есть и тут чем похвастать) и я пришел к своему очередному pet-проекту эмулятору ЛИКа. 

Первый запуск старого кода. Запуск на этом коде ПЗУшек ЛИКа. Исправление команд, т.к. изначально использовался Z80 (синклер) вместо i8080 (ЛИК). Успешный запуск Бейсика. Отладка команд на Экзорцисте. Запуск игры Клад. Оптимизация видео. Адаптация клавиатуры. И много много юнит и интеграционных тестов.

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

В туду еще много всего. Кому это нужно? Да никому. Может быть кто-то еще через 10 лет наткнется на мои наскальные рисунки и порадуется им так же как и я. 

Я точно знаю, что сделаю реплику. Я точно знаю, что дизассемблирую и разберусь в том, как устроена игра Клад. И напишу пару своих уровней. Я точно знаю, что разберусь со звуком (над ним сейчас работаю) и он не будет звучать кринжово. И много всего, что еще придет в голову в процессе.  Ведь самураю не нужна цель. Только путь.

Почему? Потому что могу.

Мое отношение к поиску кандидата его интервью и найму

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

Собеседования не эффективны по своей природе. Я как интервьюер в первые пару минут разговора уже знаю (чувствую) беру ли этого человека к себе на проекте или нет. Все остальное время - "тыкание палочкой" и поиск оправданий для своего изначального чувства. Даже если все идет по процессу - быть субъективным 1 человеку разумному сложно. Первое впечатление задает весь тон собеседования. А еще многое зависит от совместимости психотипов, что ты ел сегодня утром, болит ли у тебя голова, выспался ли, ругался ли ты сегодня утром с представителем ЖЕКа по поводу протекающей канализации под домом, получил ли ты ожидаемый бонус на прошлой неделе и массы других факторов, которыми наполнен каждый день каждого из нас. Разговор будет не про твой опыт - так точно. Скорее про обмен веществ. Но всем будет казаться, что про опыт.

И так, чтобы сэкономить время себе, команде и кандидату - можно посмотреть запись (если таковая имеется) прошлых собеседований. Лучше, если кандидат сам подготовит такое видео, на котором расскажет о всем, о чем гордится в своей карьере. И вместе с резюме (а как сделать "вкусным" и при не очень глубоком опыте - google в помощь) затем отправить в компанию. Там будет ответ. Да или нет. 

Если да - отлично! Давайте пообщаемся по существу - как мы (и наш опыт) можем быть полезны друг другу. Если нет - то нет. Все равно, даже если мы проведем классическое интервью - фидбек будет приблизительно такой "спасибо, мы выбрали другого кандидата", "спасибо, мы вам еще напишем (ложь)", "спасибо, вы нам не подходите". Любые попытки разузнать что не так - очень модерируются и в результате ты не получаешь подробного (хоть и неприятного, но потому и полезного) фидбека. Банальные отписки. Или тишина. Да я понимаю почему - тебе как менеджеру проект надо застафить. Вакансий 5. Кандидатов 25. Попробуй всем отписывать подробную обратную связь. А если ты рекрутер - твоя зона внимания уже не 25, а 250 кандидатов. К тому же кандидат может и не услышать (понять) фидбек, обидеться, отпишется и через год, когда станет более опытным не захочет иметь дело с компанией. Сложно тут. Я все же стараюсь давать емкие фидбеки даже когда освобождаю (увольняю) ребят из команды. Но всегда это трогает такие слои, которые не очень приятно поднимать и осознавать коллеге. Но так у него есть шанс. Он получил обратную связь. Ее, эту связь, кстати, хорошо бы получить и для проекта от него. Такую же не удобную. А потом превратить в план работы над ошибками. 

Про резюме я сказал. Оно вообще ни о чем не говорит. Написать его любым мне как кандидату ничего не мешает. Масса сататей и видосов на эту тему написаны. Целые разделы IT тренингов этому посвящены. Как высосать коммерческий опыт из пальца. Другое дело отзывы коллег, с которыми трудился. Потому я лично их всегда для себя запрашиваю и сам делюсь. Если не спрашивать - никто и не оставит. Все спешат. Надо спросить и напомнить. И еще раз напомнить. Вот мой профиль, я им горжусь. Я уже не может быть всего над чем трудился с коллегами, но в любой момент смогу прочитать их отзывы. Надеюсь мои отзывы им так же греют. И я никогда не писал того, во что не верил сам, иначе теряется весь смысл.

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

На самом собеседовании это выливается в вопросы типа "а чем отличается интерфейс от абстрактного класса". Не ну вы серьезно? Это ж как надо не доверять резюме кандидата, чтобы начинать с подобного вопроса. Ну или "а давайте по-программируем на листочке A4 и посмотрим как вы соображаете". Очень полезный навык, раскрывающий всю суть инженера. Программирование на листочке. Лет 30-40 назад так и было, но не сегодня.

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

Когда я работал в офисе то порой наблюдал за тем, как все окружающие вставали и синхронно шли к кофепоинту. Интернет отключился. Google driven development больше не работает. Работа стала. И с таким настроем ребята принимают решение про трудоустройство на основе написанного кандидатом в блокноте. А ты попробуй выключи интернет и сам попрограммируй хоть два часа к ряду. А ведь в опыте кандидата могли быть и такие показательные моменты, когда в целях пожаротушения без IDE по SSH на удаленном linux prod сервере в консоли в jar (что внутри war, что внутри докера) подменить 1 перекомпилированный вручную класс чтобы NPE исправить не пересобирая всего приложения (допустим, это не возможно). Его ж не спросят. А про давайте двусвязный список напишем в блокноте... Ну такое. 

Хочешь посмотреть как кодит кандидат? Запроси его гитхаб. Коллега должен уже что-то сделать до того как предложить свою кандидатуру. Его github аккаунт должен быть живой и показывать что помимо работы и зарабатывания о постоянно в тонусе инженерии. Что-то делает. Его это интересует, он живой. И в коде видно насколько. Как он относится к тестированию. Как он работает с техдолгом. Как у него с документацией и CI/CD. Как у него с алгоритмами. А ты и есть этот инженер и у тебя нет до сих пор гитхаба - опубликуй в нем все свои домашние проектики (я не верю что у тебя их нет). As is. И потом веди их уже так, как если бы за тобой подглядывает весь мир. Мне повезло, у меня проект opensource. Роль на проекте у меня больше менеджерская, но свой вклад в опенсорс я успел сделать.

Имея базу гитхаб + резюме + продающее видео ты как инженер становишься привлекательнее. Я как менеджер быстро могу понять хочу ли продолжить общение или нет? Может просто опыт не подходит нашему проекту - это можно понять уже через 5 минут. Или по темпераменту человек не впишешься в коллектив - так же 5 минут. Зачем суммарно тратить N часов времени, ведь 2 часа только самого интервью суммарно всех участников, а сколько для подготовки к нему, сколько ментальных сил кандидата. Если мы ускоряемся, а мы ускоряемся, то я хочу иметь возможность общаться за тот же 1 час с 10ю кандидатами. Не меняя в корне подхода интервью, это не возможно. 

Идем дальше. Что бы не происходило на интервью, как бы вы друг другу не понравились - все тайное станет явным в процессе триал периода. Инженер пришел помогать бизнесу или зарабатывать не сильно напрягаясь. А раз так, почему бы не проверить это заранее? У меня проект опенсорсный, я могу привлекать контрибьюторов. А тем из них, кто показал лучшие результаты - предлагать место в команде. Мне бы хотелось, чтобы в любом проекте, каким бы он ни был закрытым - нашлась часть работы, ТЗ которой можно было бы опубликовать в интернете без нарушения контрактов. Результат полезен всем. Кандидат имеет шанс показать себя, прокачать свой гитхаб, а может даже и получить плюшку от компании (как фрилансер). Команда получает дополнительную возможность решать свои вопросы, заметить на рынке талантливых ребят, сделать им предложение. Но это ж надо заморочиться. Да и проект у нас закрытый. Собеседования ж привычнее. 

Это все про мир, каким бы он мог быть, если бы я переизобретал его с нуля. 

К слову про переизобретения. Раньше (на заре моей профессиональной карьеры) все менеджеры твердили, что удаленная работа не возможна. Что мы скажем другим, если тебе разрешим? Как мы проверим вы там шаритесь, а работаете? Как организовать рабочее место? Как быть с безопасностью? И тому подобные вопросы-отговорки без желания (скорее потребности) искать на них ответы. Но меня волновало другое - 2,5 часа на дорогу с/на работу в сутки дают 3 полных рабочих месяца по 8 часов в году или 22 сутки из 365 доступных в дороге. Не с семьей, не за проектом, не за книгой, а в дороге, нюхая выхлоп или потную подмышку соседа в метро. Но я добился удаленной работы за 6 лет до карантинных ограничений и доказал, что офис для работы лично мне не нужен, более того он мешает. А работая из дому проблемы совсем другие возникают, не те, о которых менеджеры переживали - как делать перерывы и не перерабатывать. Сейчас моя команда работает по всему миру. И нам всегда было достаточно для решения любых вопросов чата и созвонов. Это про IT. А офис с печеньками и тенисным столом... Хорошо, что это отходит. Отойдут и собеседования. 

Еще момент, называется синдром самозванца. Если кандидат им страдает, у него шансов в моем проекте в разы больше, даже если опыта у него недостаточно. По моему важно не то, сколько опыта ты перелопатил в прошлом, а как ты готов ускоряться в будущем. Если в карьере кандидата все уже было и цель заработать на ипотеку не сильно напрягаясь - продуктивности не будет. Еще год назад студент, который только только стал мидлом будет больше драйва и энергии проекту давать, чем ленивый гуру. При чем тут синдром самозванца? А все просто - в тот момент, когда кто-то решает, что более чем заслужил быть сдесь - начинается его незаметная деградация. Зачем напрягаться, если все и так ок. Зачем делать больше, если это ни на что не повлияет. А я скажу. Есть инженеры которые делают свою работу в 100 раз быстрее других. При чем правда, что зарплаты у них могут и не отличаться заметно. Но не в этом дело. Дело в том, чтобы успеть сделать больше. Успеть оставить след. И шансов больше у того, кто не уверен в своих силах. И все потому, что ему некомфортно если ничего не происходит, он ищет пути. И находит. А есть опытный уверенный в себе, но как окажется поже ленивый синьйор-помидор, он уже все умеет и знает. Я возьму молодного и неуверенного. 

Камушек в сторону устоявшегося процесса рекрутинга. Создавая тренинг школу с коллегами мы сталкивались с проблемой наших выпускников - рекрутеру не интересны студенты выпускники. Опытных надо. И отношение к ним не очень. Получается студенты бегают за рекрутерами до получения первого комерческого опыта. А после первого проекта картина разворачивается на 180 градусов - за инженерами бегают уже рекрутеры. Вопрос к рекрутерам - как будут относиться к вам инженеры которым пол года назад на любой их запрос вы отвечали отказом или игнором? И как мне быть с вашими 100500 запросами по всем каналам связи о том, что мне бесконечно надо рассмотреть вашу компанию для нового места работы. Причем все из них мимо. А если вдруг интервью я не пройду по причине какого-то несварения с интервьюером стоит ли включать игнор? Эта игра не в долгосрочную. Ясное дело, что завтра придут другие. Но те, кому вы сказали нет вчера - завтра больше не придут. Я точно не приду.

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

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

А пока все ж работает. А значит не трогай! Так жеж?