В прошлую субботу выступал в качестве спикера в Белграде на IT-митапе по софт скилам (@belgradeitmeetups). Тема: "behavior собеседования на западном рынке".
Основные тезисы:
1. CV - упор на Achievements вместо Responsibilities
2. English - основная причина провала технарей из СНГ на собеседованиях в иностранные компании
3. Необходимо мыслить с точки зрения вашего value для компании, а не с точки зрения какой вы классный или классная и сколько задачек вы успеваете делать.

По-моему эти три пункта отвечают за 20% усилий и 80% успеха с точки зрения поведенческой оценки кандидата с рынка СНГ для западных компаний. Более того - вчерашнее обсуждение этой темы с моим проджект менеджером из США подтвердило эти тезисы.

В следующих постах раскрою подробнее каждый пункт.

CV - Responsibilities vs Achievements

Какое же основное отличие резюме для западного рынка и резюме с рынка СНГ? Из моего опыта - это упор на достижения вместо описания зоны ответственности. Особенно удручающе выглядят фразы типа “написание кода”, “исправление багов”, “проведение код ревью” - это похоже на “ответсвенный, коммуникабельный стрессоустойчивый, легкообучаемый” что, конечно, является огромным клише. Итак, вместо “разработка функционала” лучше написать “реализовал рекоммендательную систему, которая увеличила прибыль на 40%”. Вместо “оптимизация кода” лучше написать “оптимзировал главную страницу на 200 мс, что улучшило конверсию на 30% и сэкономило на оборудовании 20%”. Вместо “проведение код ревью” лучше написать “внедрил автоматический процесс проверки качества кода который экономит 20 человекочасов разработчиков IT-департамента еженедельно”. Так уж сложилось что на западном рынке не смотрят на, что специалист делал ежедневно, Намного важнее, чего он достиг и как он поможет бизнесу зарабатывать больше денег. В конце концов зарабатывать деньги - и есть цель любого бизнеса.

Бонусом же к такому подходу в составлении CV будет и то, что и на рынке СНГ такое CV не выглядит чужим. Оно выглядит нормально для западных компаний и свежо для компаний рынка СНГ.

English

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

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

Что делать, если хотите работать на западном рынке? Учите английский.

В новой компании в слаке есть канал #insights куда падают feature-реквесты от пользователей и куда кидают результаты опроса-фидбека по поводу причин почему пользователь начал или прекратил пользоваться услугами компании.

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

Value

И наконец, третье отличие рекрутингового процесса на западе и СНГ-рынка - это ориентация на ценности (или value). По сути эта ориентация в процессе интервью позволит не просто пройти интервью, но и получить позитивную, а зачастую и восторженную, обратную связь от менеджеров. В самом примитивном варианте value - количество заработанных для компании денег, т.е. в процессе интервью показывайте сколько денег сэкономлено или заработано в прошлых компаниях и сколько заработаете для этой. Более продвинутый вариант - это почитать на сайте о ценностях компании и излагать опыт и умения с точки зрения ценностей для конкретной компании. Но последним мерилом ценности и полезности все равно являются деньги, поэтому деньги - универсальная метрика, которая помогает компании оценивать профессионалов. Если доказать, что будете приносить компании $30к, то можно легко просить обоснованную зарплату в $10к.

Запостил новую статью про то как делать какие-то прикидки насколько быстро или долго может выполняться тот или иной запрос:
https://hackernoon.com/how-to-make-rough-estimates-of-sql-queries

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

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

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

Dependency Inversion для процессов разработки

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

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

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

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

Через пару недель вместе с замечательной @xuyanet планируем провести стрим с обсуждением IT рыночка и в качестве бонуса разберём и покритикуем несколько резюмешек. Если хотите чтоб ваша резюмешка попала в разбор - кидайте мне в личку, самые типовые ошибки обсудим, а самые интересные CVшки разберём на стриме.

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

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

А выводов пока что не будет. Вот посоветую только интересную статью как тот самый Т9 доэволюционировал до ChatGPT: https://thebell.io/evolyutsiya-neyrosetey-ot-t9-do-chatgpt-obyasnyaem-na-prostom-russkom-kak-rabotayut-yazykovye-modeli

Fill Factor для РСУБД

Fill Factor — это параметр, определяющий, какой процент каждого блока данных базы данных будет использоваться для операций вставки (INSERT). Оставшееся пространство будет использоваться для операций обновления (UPDATE). Это означает, что если в том же блоке имеется свободное пространство, строка будет перезаписана в тот же блок, что в свою очередь не потребует пересчета индекса.

Для некоторых паттернов нагрузки на таблицу, например, если ваша таблица часто получает запросы по определенному индексу (не первичному) и возвращает более одной строки, а также имеет много запросов на обновление отдельных записей, установка Fill Factor ниже 100% позволит хранить часто запрашиваемые данные вместе, избегая фрагментации. В результате, это приведет к уменьшению случайных чтений (Random Reads) с диска и увеличению процента последовательного чтения.

Применяя Fill Factor и команду CLUSTER в одном из моих недавних экспериментов на продакшен-базе на сервере Google Cloud SQL, мне удалось ускорить выполнение критических запросов в ~1000 раз для наиболее сложных сценариев. Конечно, все зависит от характера нагрузки на таблицы, но у меня сложилось ощущение что это может вылечить многие сложные случаи.

Снова про ChatGPT

В последнее время так получилось что я работаю с фронтендом и много пишу на React/TypeScript. До начачала использования ChatGPT я просто полагался на свой большой опыт в бекенде, некоторые интуитивные штуки и гуглеж. Но сейчас ИИ стал прям постоянным бадди который четко отвечает на вопросы, помогает писать некоторые куски кода, скидывает мне примеры, описывает плюсы и минусы разных подходов. По моим ощущениям продуктивность изучения технологии, эффективность реально ощутимо выросли. Изначально было и про выросшее качество кода но тут видел в тви ссылку на исследование что ИИ приводит к понижению качества кода, так что тут еще посмотрим :) субъективно - растет, объективно - не знаю.

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

Наскринил рандомных мест из диалога для примера (появятся в комментариях к посту). Это по сути я в новой для себя технологии занимаюсь архитектурными делами + одновременно изучаю эту самую технологию и докапываюсь до всяких непонятных мне деталей. А этих непонятных деталей в каждой новой технологии всегда полно.

Так что если вам не хватает ментора - за 20 долларов в месяц его легко сейчас найти :)

Скоро еще сделаю пост с различными хаками которые помогают работать с ИИ эффективнее.

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

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

Завтра залейтайте к нам на стрим! :) мы немного изменили планируемую тему с рекрутинговой на ИИшную но надеюсь это будет более интересно :)

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