#машины_разное #люди

Пару слов об архитектурных решениях.

Для начала давайте определимся с терминологией:
ADR - реестр архитектурных решений, то есть архив всех архитектурных и дизайн документов с историей.
RFC - request for comments, он же (русское значение мне больше по душе) рабочее предложение - документ, описывающий новое решение или радикальное изменение текущего.

Многие из вас слышали про RFC под разными номерами, и ассоциируете этот акроним только с сетевыми штучками. Это в корне неверно (RFC есть даже по UTF-8 и SQL), и в то же время верно - ведь его придумали не абы кто, а отцы-основатели интернета IETF.

Несложно догадаться, что ADR хранит в себе один и более RFC, как принятых, так и (что еще важнее) непринятых - быть им наукой для новичков, которые с полпинка хотят внедрить вундервафлю и получить солидный бонус.

А что касается RFC, то порядок и формат оформления, рассмотрение и принятие оного разнится от организации к организации. Однако некоторые постулаты неизменны.

Во-первых, RFC обладают своими уровнями: какие-то преподносят изменения, пусть и радикальные, в одно-два места, другие же трансформируют инженерные процессы или организацию в целом. Для сравнения: 1) развернуть один из продуктов на облачном провайдере или 2) перенести все нагрузки в K8s. Идея 1 по масштабу значительно меньше Идеи 2, а значит и рассматривать ее будет меньше людей (об этом позже).

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

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

Ну и самое интересное: после принятия решения - то есть когда RFC подписано всеми, кем надо, и готово к имплементации - оспаривать его уже нельзя. Можно изменить что-то на уровне ниже, но если вы договорились тащить K8s, на полпути переходить на Nomad не выйдет.

Даже если очень хочется.

#люди

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

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

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

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

Отказывать же нужно аргументированно и аккуратно - глобус маленький, и никогда не знаешь, с кем придется иметь дела в будущем. Лучший способ - честно и прозрачно объяснить почему вы готовы за что-то браться. Мне иногда помогает How to say No, чтобы найти нужные слова, но усложнять нет необходимости.

Нет времени, и вы загружены? Так и говорите.
Не работаете бесплатно? Ничего плохого в этом нет.
Не интересуетесь темой? Явно укажите и перечислите то, что вам реально интересно (авось, подкинут что покруче).
Просто задолбались, выгорели и едете кукухой? Со всеми бывает.

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

#машины_разное

Новая версия HTTP именуемая HTTP/3 обещает радикальное изменение в транспортной части протокола, которая предлагает альтернативу “медленному” TCP - QUIC.

Может показаться, что с TCP проблем-то и нет, и это будет частично правдой. В TCP достаточно функциональности, чтобы проталкивать как можно больше полезной нагрузки без overhead’а: fast-open, TCP windows, TSO/GSO и иже с ним. Однако следует помнить, что все дополнительные примочки строились как раз из-за того, что гарантии TCP заметно замедляют его работу!

Поначалу я подумал, что нас ждет очередной Connected UDP, но все оказалось куда интереснее.

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

Сам протокол очень молодой (и судя по RFC - невероятно дерзкий) и обещает стать “комплементацией” не только TCP, но и TLS!

Возможно я был неправ, когда написал, что самое интересное в индустрии уже придумали.

#машины_разное

Итак, благодаря Олегу Ковалову мы знаем, что NaN не равен NaN. А как насчет nil != nil?

Я еще осваиваюсь в мире сусликового программирования и частенько захожу в чужие Pull Request’ы учиться уму разуму. Однажды мое внимание привлек следующий кусок кода:

if err == nil { 
 return err
}

В комментариях затребовали незамедлительно заменить return err на return nil, указав, что так в Go делать ни в коем случае нельзя, и что “где-то выше” такой nil не будет интерпретирован как nil!

Я прихожу из змеиного мирка, где NoneType всегда NoneType, так что я пошел за советом к коллегам. Оказалось, что: 1) есть типизированный и нетипизированный nil (што); 2) nil-значения интерфейсов содержат не только само значение (nil), но и конкретный тип (*CustomError, например) (ШТО)!

Ну а error как раз Interface, так что вариантов прострелить себе руки, ноги, затылок и спину масса.

Такие дела. Прочитать подробнее можно тут:
- https://dave.cheney.net/2017/08/09/typed-nils-in-go-2
- https://golang.org/doc/faq#nil_error

Отдельное спасибо @sergdudk за разъяснение.

#люди #пятничное

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

Когда я покинул EPAM и заступил на службу в Uber, я принял для себя два сложных решения:
1. Я перестаю инвестировать свои ресурсы в изучение AWS
2. Я заметно сокращаю свое участие в публичной активности

Почему? Долгая и скучная история про смену приоритетов и закон Парето. Да и пост не про это.

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

Согласен с автором по всем пунктам.

#машины_разное

Позвольте признаться: Карен, 31 с лишним годиков, с месяц назад открыл для себя ТРИЗ (Спасибо, Миша!)

Ранее я не интересовался вне-ИТ паттернами решения задач, посыпаю голову пеплом - тем интереснее читать "Найти идею" - вводный материал для тех, кто про ТРИЗ никогда не слышал.

Я приведу одну цитату, которая глубоко засела в голове и не дает покоя: "Система идеальна, если ее нет, а функция осуществляется."

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

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

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

Переиспользование, к слову, является препятствием для career-driven development. Но это тема следующего поста.

#люди

В предыдущем посте я упомянул career-driven development. Само название, безусловно, шутка, производная от *-driven development, например Test-Driven Development.

Это первый пост из трех. Прежде чем я раскрою мысль (и дам вам повод устроить ад в комментариях), я должен уточнить: CDD сам по себе не означает ничего плохого в моем видении.

Всем знаком термин “терминальная позиция”? В нашем ИТ-мирке это чаще всего senior engineer. Терминальная позиция - это та должность, до которой каждый, со временем, обязательно дойдет, если будет… просто работать. В среднем, такой путь занимает от 7 от 10 лет, 22-летних вундеркиндов в расчет не берем.

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

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

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

Вот тут и начинается загвоздка. Чем выше по должности вы пытаетесь пройти, тем больше становится масштаб! Если не перейти в менеджмент, дальнейшая линия развития после Senior это Staff+ (инженер-архитектор здорового человека, не путать с чуваками, которые кроме Visio и Outlook ничем не пользуются) - и если условный L5 (senior) делает что-то крупное, но в пределах своей команды, то L6 (staff) работает в проекции нескольких команд, влияя на несколько продуктов или на целые бизнес-юниты.

Становится понятно, что, чтобы стать Staff’ом, нужно писать не очередной микросервис, а что-то уровня Nginx/ClickHouse. Об этом в следующем посте.

#люди

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

Предыдущий пост вызвал ряд непониманий. Оно и видно, ведь я использовал некорректное действие "написать".

Безусловно, Staff+ бывают разные, как по "классификации", так и по становлению - и есть те, кого повышают за выслугу лет вкупе с коммуникативными талантами. Но я не знаю, как вы, а я тот еще мамкин карьерист и рассматриваю своих... конкурентов. Так что и писать буду о тех ребятах, которые идут вперед, а не ждут у моря погоды.

Итак, чтобы встать на ступень выше, нужно соответствовать должности выше. А Staff+ часто решают стратегические задачи и обладают авторитетом размером с целый бизнес юнит.

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

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

В больших (технических) компаниях, как я уже говорил, процесс повышения бюрократизирован. Да, к нам эта вездесущая бигдата с вовлечённостью пришли куда раньше одноименного скандала, и номинант, перед отправкой своего резюме на рассмотрение суда присяжных комитета, занимается сбором данных (как его действия повлияли на компанию) и артефактов. Артефактами служит все релевантное, что попадется под руку: дизайн документы, pull request'ы, записи тренингов, документация, epic'и в JIRA.

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

Вы, наверняка, догадались куда я клоню. Чтобы показать, как вы решаете стратегические задачи, надо бахнуть что-то стратегическое. Чтобы получить повышение, нужен не просто проект, а ПРОЕКТИЩЕ.

О том, как такие проектища появляются и к чему приводят - в понедельник. Обещаю!

#люди

Наконец-то к теме, с которой все началось.

Итак берем какую-то стратегическую проблему, из нее берем тактическую проблему - что-то, что можно измерить. Если вы работаете в платформенной/инфраструктурной команде, то лучшая метрика - либо масштаб, либо расходы, либо “возможность” (дать техническую возможность для бизнеса делать Х). В непродуктовых командах, инженеры чаще всего сами обозначают проблемы и способы их решения. И чем серьезнее проблема, тем серьезнее способ.

Тут стоит сделать небольшую отсылку на пару постов назад и вновь процитировать Генриха Альтшуллера: “Система идеальна, когда ее нет, а ее функция выполняется.” Казалось бы, что может быть лучше для предприятия, чем использовать уже существующие инструменты и системы для решения новых задач?

В этом и есть одна из первых серьезных проблем: нельзя получить повышение, просто взяв уже существующее и натянув на него проблему (Как вы думаете, почему у Google так много мессенджеров?) . Карьеристы это прекрасно понимают. Бизнес это прекрасно понимает. И бизнес, чтобы блокировать злоупотребление креативным подходом, имеет при себе штат инженеров-“дедов”, которые задают каверзные вопросы: “А почему не хотите использовать Y? А чем вас не устраивает Z?” Карьеристу нужно найти такую (дополнительную) проблему, что не может решиться уже существующей системой. Из чего растут ноги второй серьезной проблемы: если такой проблемы нет, ее нередко придумывают!

Помните тот стикер-пародию O’Rly “Solving imaginary scaling problems”? Приблизительно так это и работает.

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

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

Отсюда четвертая проблема: не всегда можно проверить “честность” этих метрик, и более того - берутся только те метрики, что изменились в плюс. Многие знают гигантскую историю Dropbox о том, как они построили свои ЦОДы и уехали из AWS, сэкономив миллионы миллиардов. Есть и обратные истории, как компании залетали в AWS, точно так же экономя миллиарды миллионов. Мы не знаем, нельзя ли было добиться того же эффекта внутренними оптимизациями (мой опыт эксплуатации собственных инфраструктур и облаков подтверждает, что чаще всего можно).

И пятая, в продолжение: учитывая сроки планирования, разработки, имплементации и запуска проекта, мы не можем знать наверняка, что все вложенные силы и инвестиции отбились. А значит мы не знаем, можно ли было направить столько ума и таланта на что-то более весомое и полезное для предприятия.

---

Выводов из этого поста делать не стоит. В конце концов, благодаря инициативным кадрам the Big Tech задает тренды индустрии, выпускает свои проекты в Open Source и дает компаниям меньшего размера выходить на больше рынков и объемов подготовленными. Цитируя своего приятеля: “Все, что сейчас решается в FAANG, будет решаться и в других компаниях через несколько лет.”

С другой стороны, не все общеизвестные системы появились на свет из-за карьерных аппетитов их изобретателей. Сысоев хотел ускорить Apache; Миловидов вряд ли придумал ClickHouse ради бесплатной ипотеки от Яндекса (хотя кто знает?); Роб Пайк явно сидел достаточно высоко в Google, когда придумывал Golang; Гвидо ван Россум решил “ускорить” Python, потому ему наскучила пенсия, и в Microsoft ему сказали взять себе любой проект по душе.

Даже если из ста проектов только один принесет реальную пользу - разве это плохо?

#машины_aws

Амазонщики часто с нетерпением ждут re:Invent. Оно и понятно - самые большие и громкие анонсы происходят именно там.

Однако есть громкие заявления - и прошедшее мероприятие явно дает понять, в каком направлении двигается AWS - и есть оглушительно тихие.

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

Первое: поддержка Graviton2 в AWS Lambda. AWS крайне заинтересован перевести часть своих клиентов на собственные процессоры, и поддержка их в FaaS как нельзя лучше помогает запустить в собственную среду не только бизнес, живущий на виртуальных машинах и контейнерах, но и тех, кто практикует FullStack Serverless. Это эволюционный путь и он ожидаем (все всё понимают).

Второй анонс куда интереснее - AWS выкатил CRUDL API для управления жизненным циклом своих ресурсов. Я не буду раскрывать всех тонкостей его работы: мои коллеги и евангелисты из AWS тусовки куда лучше с этим справятся, да и CRUD’ами сейчас никого не удивить. Для себя отмечу, что идемпотентность API реализованная через передачу клиентского токена, ИМХО, крайне сомнительная затея.

Самый сок не в этом. Глядя на спецификацию ("TypeName": "AWS::Lambda::Function"), становится понятно, что обращения идут не абы куда, но в CloudFormation Registry - что тоже вполне себе логичный ход, удовлетворяющих всех Оккам их бритвы.

Особой фишкой релиза Cloud Control API является интеграция с Pulumi и Terraform. AWS не в первый раз демонстрирует свою готовность работать совместно с ISV - это помогло появится таким прекрасным продуктам как OpenSearch (оставим за скобками, что стало с компанией Elastic, мы же потребители). Однако теперь, что Pulumi, что Terraform будут заинтересованы добавить поддержку не-AWS сервисов в Cloud Control API - а значит они будут разрабатывать необходимые провайдеры для CloudFormation Registry… Что экономит силы самого AWS и дает им поддержку внешних поставщиков в CloudFormation и CDK. (все всё понимают)

Я не отношу себя к левакам, которые требуют от всех и вся “зарегулировать” AWS, дабы он не подгибал всю индустрию под себя. Защитить ИТ от монополизации - задача конкурентов AWS, а так же самих предприятий-потребителей. Каждое предприятие должно принимать решение с откупом: или инвестировать в свою собственную инфраструктуру - и речь не только о железе и ЦОДах, но и собственных инфраструктурных продуктах - или готовиться к долгосрочному стратегическому партнерству с поставщиком облачных услуг.

#жиза #люди

Не пост, но предложение к обсуждению.

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

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

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

Но это мое видение. Собственно, дискас.

#пятничное

Извините.

#машины_разное

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

#машины_aws

Из поста выше: “But this took time, because these facilities are designed with high levels of physical and system security in mind. They’re hard to get into, and once you’re inside, the hardware and routers are designed to be difficult to modify even when you have physical access to them.”

Это напомнило мне ситуацию, когда я “зашил” управление инфраструктурой в AWS так, что только CloudFormation может вызывать изменения и только TeamCity может “дергать” CloudFormation.

Когда я кое-что сломал по ошибке (в т.ч. и в самом CloudFormation), мне пришлось бегать от лида до безопасника и от безопасника до СТО, чтобы получить конверт с MFA устройством от root’ового пользователя.

#машины_aws

Дубовый евангелизм хуже чем его отсутствие. Вот @count0_digest зачем-то просит объясниться (или оправдаться?) за каких-то чуваков, которые глупейшим образом решили набрать себе трафика и продать свой продукт.

Беглый гугл говорит о том, что Ottertune автотюнит облачные базы. Балдеж, зумеры придумали Oracle AWR/ADDM с красивым UI.

Оставлю продукт в покое, но проедусь по сантименту поста. Во-первых, ультимативные посты в духе You are doing XXX - низкий ход и чистой воды кликбейт. Во-вторых, считать чужие деньги и уж тем более расписывать, на что они тратятся, еще ниже. Не похер ли, на что тратит свое состояние Безос? Вы еще расследуйте, что это за дворец в Гелленджике.

Теперь к посту. Если убрать весь скучный флер, то можно обнаружить следующие советы:
1. Не использовать слишком большие машины
2. Не использовать настройки по-умолчанию
3. Не использовать слишком много PIOPS

То есть те же базовые вещи, которые рассказывают на курсе подготовки к AWS Certified Solutions Architect. Потрясающе! Хорошее повтори и еще раз повтори.

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

Я не хочу ковырять цифры по всему калькулятору, так что посчитаю только один экземпляр m5.8xlarge. По оценке ребят, такая дура c 32 (!!!) ядрами стоит 25к в год. Много, согласен. Только если купить резервацию на год с полной оплатой вперед, цена сразу срезается до 15к. Сумма 25 000 - цена по модели OnDemand которую используют либо по незнанию, либо недолго.

Не говоря уже о том, что правильно выбирать сервер СУБД по разным характеристикам, а ребята-тюнеры взяли сервер “общего назначения” и издеваются над ним как могут.

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

От себя замечу, что лучшая ACID СУБД в AWS это Aurora, и я искренне не понимаю людей, которые заходят в облако и покупают там OpenSource. А потом еще несут деньги всяким хулиганам, чтобы их базы “оптимизировали”.

#пятничное

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

#машины_aws

Пока я работаю над длиннопостом, два занимательных и одновременно неприятных факта про DynamoDB:

1. DynamoDB TTL - бесплатный server-side способ удаления устаревших данных не предоставляет гарантий удаления в срок истечения! Хуже того то, что объекты с истекшим сроком жизни все еще отображаются в запросах, что перекладывает ответственность за фильтрацию валидных данных на клиента. Не смотря на то, что в среднем удаление занимает до 48 часов, мне известны случаи о задержке аж на 10 суток.

2. Capacity Units распределяются по шардам (Partition Key) таблиц, что может привести к ProvisionedThroughputExceededException при том, что throttle происходит только на конкретном шарде - так называемая проблема Hot Partition. По результатам общения с техподдержкой выяснилось, что:
- В режиме provisioned CUs, они равномерно распределяются по шардам; далее DDB будет распределять CU на более активные шарды. Как происходит распределение, когда количество шардов превышает количество CU, неизвестно.
- В режиме OnDemand, каждый шард получает 1000 WCU и 3000 RCU сразу же и перераспределения между шардами уже не происходит, поскольку 1000 записей и 3000 чтений в секунду - верхний порог.

Казалось бы мелочи, но эти мелочи выпили мне немало крови в Uber. И заметно сузили мой личный список подходящих бизнес задач для DynamoDB.

#анонсы

Я обещал, что на этом канале нет и не будет рекламы, но я не расчитывал, что удар в спину реклама придет от самого Телеграмма.

Пока я не вижу никаких постов (в отличие от каналов моих коллег) что хорошо. Но когда реклама начнет появлятся регулярно, я приложу возможные усилия, чтобы ее на моем канале не было.

Ни от кого.

#люди

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

Новостей тут нет, результаты исследований закономерные. Кандидаты, которым дали задание и оставили наедине, справились вдвое лучше, чем те несчастные, кто проходил интервью в присутствии интервьюера и должен был (какой ужас!) озвучивать ход своих мыслей.

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

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

Со стороны кандидата, чтобы получить желанный оффер из FAANG+, достаточно скрепить зубы и сесть на от 1 до 6 месяцев за LeetCode и просить более опытных товарищей побыть наставниками по архитектуре и проектированию систем.

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

Однако, мне не дает покоя пункт про толерантность к интроверсии кандидатов. Пресловутый Software Engineering отличается от Coding’а именно тем, что за последние десятки лет эта работа социализировалась, и про это хорошо рассказывается в первой главе Software Engineering at Google. Времена атомарных единиц, выполняющих свой кусок задач и ни с кем не коммуницирующих хотя бы в формате текста, канули в лету.

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