Кем вы видите себя через 5 лет?
Я думаю у многих из моих подписчиков интересовались подобным.
На сегодняшний день собеседования в ИТ сфере стали исключительно опросником с бинарными оценками, и тут как всегда, ответили вы хорошо - то ваш ответ просто скорее всего пропустят, а вот ответите "как-то не так" - ваш ответ тут же будет помечен цветным флагом. Цветной флаг (желтый/красный) - это вполне может стать причиной отказа.

Вот и вопрос про ваше видение себя через 5 лет - это уже откровенный моветон. Что является причиной такого заключения? Да все просто - люди в ИТ меняют работу с завидной частотой. Согласно анализу рынка, средний срок работы в ИТ сегодня это что-то в районе 2 лет. Для грейдов поменьше срок ниже, где грейдов повыше - выше. Но тем не менее, даже взяв высокий грейд - среднее время работы будет чуть больше 3х лет.

Потому единственно честный ответ на вопрос про 5 лет - то, что статистически вы скорее всего будете работать на новом месте. Устроит ли этот ответ HR? Разумеется красный флаг - только устраивается и уже думает как свалить.

Разумеется, даже HR все равно кем вы будете через 5 лет, потому что статистически их тоже не будет в этой компании через 5 лет. Этот вопрос - лишь попытка прощупать то, как вы видите свой вектор развития. Но предлагаю всем собеседующим исключить этот вопрос из своего опросника (если он там есть) и спрашивать прямо: "как собираетесь развиваться и в какую должность расти" а не задавать вопрос, который (особенно новичков) ставит в тупик и не имеет практически ничего общего с реальностью.

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

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

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

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

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

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

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

Так ли все хорошо? Увы, нет. Фиксы багов - это буквально следующее: представьте что вы разрабатываете калькулятор и обнаружили баг, что 2+2=5. Знаете какой скорее всего фикс будет сделан? Там захардкодят результат для этого ввода. Демо приложение проверяющее гипотезу? Оно так и останется демо, более того, бросьте сразу желание расширять это приложение, лучше просто написать другое, переиспользовав пару строк из этого демо. Прототип другого приложения? Он буквально красивая картинка и не более - тонны багов, которые правятся по примеру калькулятора выше. Попробуете в отместку зареверсить то, что прислали вам - вы буквально открываете портал в ад.

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

На днях компания Revolut объявила о новом раунде, который поднял стоимость компании с 33 млрд $ до 45. С чем поздравляю всех причастных, так как это серьезный буст и поднятие стоимости опционов, в том числе и моих 🙂

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

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

Как так вышло? А главное работает ли это?

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

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

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

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

Далее каждую свою фичу разработчик обязан был покрыть максимальным количеством юнит тестов. Юнитов было не просто много, их было очень много, настолько что этап их прогона даже занимал приличное время во время сборок на CI.

Немаловажный аспект - найм, в Револют нанимали действительно скилловых ребят, даже взять мое собеседование туда - оно длилось 4,5 часа. И это если что после тестового задания, на которое я тогда “убил” около 25 часов.

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

Благодаря всем этим аспектам, качество продукта оставалось на высочайшем уровне. Стоит отдать должное - я до сих пор восхищен этим фактом. Проверил сейчас - свыше 10 млн скачек в гугл плей, оценка 4.6. Полное отсутствие QA.

Как думаете, смогли бы вы организовать такое качество своего продукта, если бы в вашей компании не было QA? 🙂

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

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

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

Так как выравнять эти ожидания?

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

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

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

Такую вещь я впервые подглядел в докладе Саши Блинова Молчание джунов.

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

А какие бывают вообще онбординги?

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

Человек должен уметь самостоятельно разрабатывать фичи по завершению обучения? Скорее всего речь про то, чтобы человек потратил достаточно много времени и сделал какую-то полноценную задачу. Причем будьте готовы, что для онбординга очень часто берутся задачи, которые по завершению нужно просто удалить.

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

Получается что потратить неделю-две на бесполезное ожидание всех доступов, сборки проекта (которая по неведомым причинам не случается) и когда наконец Вася вернется из отпуска - это что-то типо “норм”. То вот занять человека синтетическое задачей, которая подготовит этого человека к вашему проекту и ускорит его с первых же боевых задач - ЭТО ГДЕ ТАКОЕ ВИДАНО ВООБЩЕ?

Итак, шаг назад - я привел пример крупной задачи, которая хорошо погружает глубоко в проект, но тем не менее имеет существенный минус - удаляется в конце. А что если сделать онбординг не таким “всеобъемлющим”, но при этом он всегда будет знакомить с какой-то частью основ? У себя в компании мы нашли такой выход в одной из команд (которая не хотела задачу под удаление) - у них всегда есть огромный беклог задач на написание/исправление элементов дизайн системы. Это супер типовые задачи, которых натурально сотни, старшие разработчики ими брезгуют, но они дают хорошее понимание старта проекта и при этом - в конце эта задача вливается в мастер и живет себе спокойно.

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

А если ситуация обратная? У вас доска трещит от беклога, вы нанимаете одного новенького человека, готовы ли вы ждать лишнюю неделю-две? Скорее всего нет - поэтому давайте смело пропускайте онбординг и переходите к задачам. Разумеется будьте готовы, что человек задаст миллиард “глупых” вопросов, но вы знали, на что идете ?

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

Вдогонку ко вчерашнему разгону про разницу в ролях teamlead/techlead.

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

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

Или нет? У вас не так? У меня сейчас, например, точно не так ?

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

Зато проводить 1-1 и ставить оценки должен тимлид. Который в свою очередь может быть обычным членом команды (пример команды описал выше). Ставить оценки и проводить 1-1 тимлид должен конечно только тем, кто является его подчиненным; т.е. у тимлида Android это будут Android разработчики, необязательно внутри той же команды, что и тимлид.

Уже нехилое такое различие, неправда ли?

А как там зарубежом? Engineering manager? Это еще кто такой??
Чтобы облегчить этот текст - короткий ответ: это роль, которую потребовалось ввести бизнесу для достижения поставленных целей.

Так получается нет четкого определения роли тимлида/техлида/EMа? Все верно, в разных компаниях это могут быть абсолютно разные роли. Где-то тимлид пишет код как не в себя, где-то техлид раздает задачи налево-направо. А где-то все совсем наоборот.

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

Для большего погружения в тему, предлагаю посмотреть доклад с конференции 2020го года, на котором я впервые для себя сделал эти открытия.

https://www.youtube.com/watch?v=Fb8pwgtRpFs

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

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

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

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

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

Лирическое отступление.

Вообще вступление в роль руководителя для разработчика - это как начать карьеру практически с 0. Серьезно, именно такие чувства испытывают многие senior разработчики, кто только получил казалось бы “повышение”. Да, от компании к компании понятие руководителей очень разнится. Где-то вас заставят писать код 90% вашего времени и изменений вы почти не почувствуете. Но где-то “пипл менеджмент” может начать отнимать бОльшую часть времени на работе. Тут и будут первые сюрпризы. Например может оказаться, что руководитель вы так себе. Или проще - вы вообще не понимаете что делать на новой роли. Пожалуй напишу об этом детально в следующих постах.

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

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

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

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

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