? Джун, который достиг потолка

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

Как я писал ранее, после технических секций профили кандидатов приходят на рассмотрение к тимлидам для финального собеседования.

Один из таких финалов у меня проходил с челом из СберТеха. По техническим секциям грейд оценивался как мидл / мидл+.

Стандартный вопрос, который влияет на грейд: «Расскажи о самой сложной / масштабной задаче, которую ты решал». Рассказал о паре задач уровня джун+ / низ мидла.

На вопрос почему хочет уйти из Сбера ответил: «Есть сложности с ростом». Это триггернуло, учитывая, что СберТех — это не веб-студия и работал он там всего 4 месяца. Когда начали копать, выяснилось, что он недоволен своей текущей ЗП — назвал маленькую цифру на этапе оффера. При этом на скрининге сказал, что ему просто всегда был интересен Яндекс.

Дальше было самое интересное: по ходу собеса кандидат отметил, что хочет стать тимлидом в ближайшей перспективе. Тут я почувствовал, что мой трон пошатнулся и я напрягся ? (нет). Опыта управления людьми как такового не было.

На финале с другим лидом тот спросил его: «Что, если тебе не будут давать эту позицию три года подряд?». Ответил, что будет искать другую компанию. При том, что это абсолютная норма.

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

Какие выводы можно из этого сделать?

?Адекватно оценивайте себя
?Проработайте свое позиционирование: какой у вас стек, куда хотите развиваться (разработка или управление)
?Проработайте кейсы, о которых вы будете рассказывать
?Не нужно вываливать свой поток сознания на рекрутера и собеседующих — продумайте ответы, которые будут совпадать с ожиданиями работодателя (для этого необязательно лгать)

Как рассказывать о кейсах расскажу в следующих постах.

?Подписаться на Imangazaliev Blog

Альтернативы Notion ?‍?

9 сентября российские аккаунты Notion будут отключены и данные станут недоступны. Печалька. Есть еще надежда, что они найдут выход, как Miro )

Какие есть альтернативы:

?Переехать на какой-нибудь облачный сервис (список альтернатив на Reddit). Из более-менее адекватного показалось Coda.
?self hosted-решение
?~~Уехать из России~~

Какие есть варианты self-hosted:

?Распиаренный Obsidian. Мне не зашел, слишком много телодвижений нужно для того, что делалось в Notion в один клик. Возможно, это как-то настраивается, если обвешаться плагинами, но чет как-то не хочется. Из плюсов, что можно положить в Git.
?Outline — визуально похож на Notion. Пару лет назад поднимал его через докер одной командой — пользоваться можно. Были небольшие баги в интерфейсе, но, учитывая, как он активно развивается, думаю, их давно пофиксили. Нужно только подумать над бэкапами.

?Подписаться на Imangazaliev Blog

? Как проходит HR-скрининг

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

Что спрашивают?

?Текущий статус. Где и на какой позиции сейчас работаешь, насколько активно ищешь, есть ли офферы от других компаний (лучше их иметь).

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

Для высоких грейдов: есть ли опыт управления, проектирования архитектуры, запуска крупных проектов.

?Причины поиска. Норм ответ — достиг потолка в развитии, однотипные задачи, нестабильность компании и т. д.

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

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

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

?Мотивация. Какие задачи интересны, что важно в работе, чем не хотелось бы заниматься.

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

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

?Подписаться на Imangazaliev Blog

? Кладбища полезных материалов

Как-то листал чат, куда я сохраняю полезные материалы и наткнулся на сообщение 2016 года про библиотеку Riot.js — эдакий Vue.js на минималках. С нее я начинал свой путь во фронтенде и она уже практически мертва.

Чуть ниже в этом чате была ссылка на «100 полезных каналов и чатов для программистов», а еще ниже — статья про фразовые глаголы в английском языке. Таких чатов у меня в телеге с десяток.

Есть у меня привычка накапливать полезные (как мне кажется) материалы — своеобразный синдром Плюшкина.

Когда я сидел в ВК, это были репосты на стену; когда активно использовал Discord — отдельный сервер с каналами по тематикам. Ни в ВК, ни в Discord я уже давно не захожу и эти материалы так и остались лежать там.

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

Многое из этого либо уже неактуально само по себе (как в случае с Riot.js), либо стало неинтересно мне, либо я это уже изучил, когда возникла необходимость.

Простые выводы:

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

Что можно с этим сделать:

?Меньше сохранять. Читать здесь и сейчас или просто закрыть и забыть.
?Сохранять структурировано. Использовать базы в Notion — теги, описание, когда и зачем сохранил, привязывать их к какому-то проекту.
?Беспощадно удалять сохраненное. Я много раз случайно закрывал сотни вкладок в браузере, несколько раз полностью терял все данные на диске и один раз удалил чат в телеге с сотнями ссылок и, вроде, ничего ?
?Использовать инструменты, которые дают саммари — Яндекс Браузер, ChatGPT.
?Периодически уделять время на просмотр накопленных материалов.

Немного погуглив на тему подобного накопительства нашел видео) Дорофеева, тоже полезно послушать.

?Подписаться на Imangazaliev Blog

? Квартальное планирование

На этой неделе у нас в Яндекс 360 прошло очередное планирование. На нем примерно 150 человек и 20 команд пытаются понять, что они будут делать следующие три месяца. Процесс сложный, немного выматывающий, но очень интересный.

*? Сбор бэклога и капасити*

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

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

Каждую задачу нужно оценить в днях дизайна, разработки и тестирования. Точность оценки зависит от степени проработки задачи — где-то уже есть дизайн и описание API, а где-то только тех. задание.

Еще у команды есть ограниченные ресурсы дизайна, разработки и тестирования. Для них рассчитывается капасити (емкость) с учетом отпусков, дежурств, созвонов и т. д. Объем бэклога больше, чем команда реально способна переварить — просто потому что часть задач может отвалиться на следующих этапах.

*? Согласование бэклогов*

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

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

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

*? Удается ли уложиться в сроки?*

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

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

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

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

Если интересна тема, можно погуглить про PI-планирование и Scaled Agile Framework (SAFe).

?Подписаться на Imangazaliev Blog

السلام عليكم ورحمة الله وبركاته

Поздравляю всех мусульман с праздником 'Ид аль-Адха!

تقبل الله منا ومنكم

?‍? Так ли тяжело найти первую работу в IT?

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

Что сделал бы я на месте джуна с текущими знаниями о поиске работы:

?Проанализировал свой день и исключил все отвлекающие факторы — фокус только на поиске работы
?Хорошо оформил резюме: проанализировал чужие резюме, посмотрел разборы на Ютубе и попросил ревью у эксперта
?Разместил его на всевозможных площадках. Есть около десятка популярных сайтов кроме hh.ru или Хабр Карьеры, каналы в Telegram и группы в ВК, сайты крупных компаний, аутсорс и аутстафф-контор
?Адаптировал сопроводительные письма под каждую вакансию
?Оформил GitHub с несколькими пет-проектами, красивым README и демо (!)
?Просмотрел записи интервью на Ютубе, которых там десятки
?Нашел топ 50 / 100 вопросов на собеседовании в своем направлении и отточил их до совершенства
?Прошел мок-интервью
?Подался на стажировки, которых тоже десятки
?Нашел контакты HR, менеджеров или разработчиков и написал им в личку, либо нашел еще более оригинальные способы выделиться из толпы
?Записался на карьерную консультацию на Хабр Карьере, Solvery, GetMentor, Эйч (есть кто делает это бесплатно)
?Нашел себе ментора

Как это обычно выглядит на самом деле:

?Резюме: в графе «О себе» максимально общее описание, места работы указаны без каких-либо подробностей
?Резюме размещено на одной-двух площадках
?Отклики с шаблонным текстом
?Пустой GitHub или проекты, сделанные на курсе под копирку (которые рекрутеры уже знают наизусть)
?Не могут внятно ответить на базовые вопросы по своему стеку

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

Напоследок подкину пару полезных ссылок:

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

?Подписаться на Imangazaliev Blog

? О чем спросить на собеседовании?

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

Чтобы выбрать правильный оффер и не разочароваться после выхода на работу, просто задавайте вопросы ?‍♂️

Какие моменты нужно прояснить для себя:

?Продукт — что из себя представляет, какую ценность несет для пользователя и сколько этих самых пользователей
?Технологии — стек, архитектура
?Команда — размер, состав
?Процессы — откуда приходят задачи, как планируют, работают, оценивают результаты
?Планы на ближайшее время (условно, год)
?Задачи, которые будут стоять перед вами

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

Часто ситуацию, когда мы задаем вопросы называют обратным собеседованием (reverse interview) — можно погуглить и найти список вопросов. Есть пара неплохих подборок: раз и два.

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

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

Были времена ?

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

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

А еще GitHub хранит мои первые шаги в веб-разработке: первый сайт на PHP и проект на Vue. Тогда я еще не знал про Git, поэтому в некоторых проектах можно заметить папки «v1», «v2» ?