Руслан Куянец | Reactify

💼 Персонализированная подготовка Весь июль тестировали Календарь собеседований и внедряли новый подход к подготовке. Раньше мы в основном готовили ученика до выхода на рынок, а дальше уже подключались точечно, если нужен был мок. И этого подхода в целом хватало. Каждый ученик до выхода на рынок проходил 5–13 экзаменов по всем темам (экзамен = мок с ментором), потом ещё 2+ дополнительных мока и прожарки. Плюс были рандомные моки с другими ребятами примерно 2 раза в неделю. Этого было достаточно, чтобы получать офферы. Но рынок стал тяжелее. Конкуренция выросла, компании стали сложнее отбирать кандидатов, и сейчас нужно выжимать максимум из каждого шанса. Поэтому мы поменяли подход. Есть собеседование в Т-Банк и там лайвкодинг? Сделаем мок лайвкодинга именно под формат Т-Банка. Финальный этап в Сбере? Сделаем часовой мок по софтам и разбору опыта, чтобы максимально повысить шанс пройти. То есть после выхода на рынок ученик теперь имеет возможность делать практически неограниченное количество моков с ментором по необходимости, пока ищет работу. Это и есть персонализированная подготовка. И всё это стало возможным благодаря трекингу собеседований через Календарь. Но моки — это только часть. Календарь даёт ещё несколько сильных возможностей. 🚂 Паровозы собеседований Например, Ваня прошёл собеседование в Авито. Через неделю Петя идёт туда же — Ваня может передать ему вопросы, рассказать про этапы и помочь подготовиться осмысленно. Раньше такие связи часто терялись. Теперь мы специально их создаём. 📚 Материалы и реальные вопросы Мы подключили помощника, у которого есть доступ к куче источникам с записями собеседований, слитыми вопросами, задачами и закрытыми базами. Когда ученик добавляет собеседование в календарь — мы можем искать актуальные материалы именно под эту компанию и этот этап. Давать это ученику. 🤝 Рефералы Ещё один важный эффект — растёт база контактов. Например, ученик прошёл собеседование в Сбер, но понял, что ему не подходит офисный формат. Он с большей вероятностью сможет порекомендовать другого ученика, которому такой формат подходит. Получается система, где ученики помогают друг другу получать больше возможностей. За июль Календарь уже показал хороший результат: — 8 рефералок ученик → ученик — 11 паровозов по собеседованиям — 20 собеседований, где удалось найти вопросы и записи, которые совпали с реальными этапами примерно на 90% — дополнительные моки для подготовки к алгоритмам и финальным этапам Это только первый месяц. Чем больше данных собираем, тем точнее понимаем, где можно помочь, какие компании сейчас нанимают и как увеличить шанс получить оффер. Мы не ждем хороший рынок 🚀 Мы побеждаем на любом 💪

Для меня это был шок. Код был слабый, базовой логики и понимания разработки почти не было. Но человек получал 250 тысяч рублей в месяц. И знаете что? Он молодец. Он смог попасть в систему, пройти фильтры и получить результат. Возможно, ему вообще не интересно, что кто-то считает его путь неправильным. Типа: «Хэй, я получаю 250к, а вы тут сидите и год ищете работу, зато говорите про честность». Это было бы не очень красиво с его стороны. Но доля правды в этом есть. Потому что рынок в итоге вознаграждает не самых правильных. Он вознаграждает тех, кто смог адаптироваться под его правила. И, наверное, главный вопрос не в том, правильно это или нет. А в том: Нужно ли быть лучшим разработчиком или нужно уметь доказать рынку, что ты им являешься?

🤬 Дилемма IT-рынка Дилемма разработчика: быть хорошим инженером или хорошим кандидатом? Под комментариями к видео-прожарке люди разделились на два лагеря. https://youtu.be/a43a-SCCHLg Одни говорят: «Как можно не знать такие вопросы? Это же база». Вторые говорят: «А зачем вообще задавать такие вопросы? Они ничего не показывают». При этом и среди первых, и среди вторых были люди как с опытом, так и без него. И вот тут начинается интересная дилемма. Когда еще не было всей этой рыночной истерии, к собеседованиям относились проще. Опытные ребята, работающие в топовых компаниях, на собесах могли просто поговорить за жизнь — и их брали в Альфу, ВК, Сбер, Ростелеком и другие компании. Не было жесткой проверки знаний. Алгоритмы, задачки и вопросы с собеседований считались отдельным навыком, который хороший разработчик знать не обязан. Время шло. Записей собеседований на YouTube стало в сотни раз больше. Списки вопросов, подборки задач, сервисы подготовки — все стало доступно. Подготовиться стало намного легче. Но вместе с этим поменялись и правила игры. Сейчас уже недостаточно просто хорошо работать. Если ты приходишь на собеседование неподготовленным, то можешь проиграть человеку с меньшим опытом, который просто хорошо натренировал формат собеседования. Готовиться к собеседованиям нужно. Это буквально часть профессии и реалии текущего рынка. Улучшать резюме, правильно себя презентовать, иногда чуть подкручивать формулировки — это тоже часть игры. Потому что какой смысл быть добрым, честным и иметь реальные навыки, если ты просто не проходишь первый фильтр и месяцами сидишь без работы? Особенно сейчас, когда самый жесткий рынок находится в диапазоне 1-3 лет опыта. Но даже если человек условно добавит себе год и попадет в фильтр 3-6 лет, он все равно будет внизу выдачи. HH ранжирует кандидатов: сначала идут люди с опытом 5+ лет, потом уже 3-4 года. Когда я делал эксперимент с вакансией, в топ-50 выдачи было около 80% людей с опытом 5 лет и больше. Хотя на саму вакансию откликались разные люди. Кандидатов с 3-4 годами было тоже много, просто они находились ниже. Кстати, проводя собеседования опытным ребятам, которые приходят за помощью с поиском работы, я часто вижу пробелы в базе. Многие опытные разработчики не знают нормально про классы и прототипы. Ошибаются в задачах на this и Event Loop. Не умеют решать алгоритмические задачи. Кто-то не может нормально отрефакторить React-компонент — хотя это один из популярных типов лайвкодинга. А иногда проблемы вообще с базой: человек не помнит, что делают логические операторы, какая разница между функциями, как работают фундаментальные вещи языка. И вот тут возникает вопрос: а что тогда вообще считать опытом? Количество лет в компании? Количество написанных строк кода? Умение решать реальные бизнес-задачи? Или способность пройти проверку на рынке? Правильно говорят, что собеседования — это отдельный навык. Если опытный разработчик не готовится, его может обойти менее опытный специалист, который просто лучше подготовился и умеет играть по новым правилам. Еще часто говорят: «Опытный разработчик не значит хороший разработчик». И я с этим согласен. Я регулярно встречаю людей с большим опытом, которые пишут код, который сложно поддерживать, сложно читать и сложно масштабировать. Мне кажется, что в ближайшие годы с развитием нейросетей разница между просто опытным разработчиком и специалистом, который умеет думать, писать хороший код и правильно использовать AI-инструменты, будет только расти. Мой пик менторства и помощи с трудоустройством новичкам пришелся на 2025 год. И честно, я иногда не понимаю, как некоторые ребята раньше без нейронок умудрялись накручивать опыт и работать в компаниях. Только если с помощью сильного наставника на испытательном сроке. Но как-то же люди справлялись. И за это им большое уважение. Помню, в начале 2024 года я помогал человеку, который накрутил себе 3 года опыта и попал в Сбер. Он обратился за помесячной помощью на испытательном сроке.

👩‍💻 Прожарка собеса на Frontend Разработчика https://youtu.be/a43a-SCCHLg Когда мне предложили провести прожарку собеса, я сначала хотел взять какой-нибудь идеальный кейс. Тот самый собес, где ученик приходит, отвечает на все вопросы, закрывает все этапы и забирает оффер. Казалось бы, для ментора это самый красивый пример. Но когда я начал готовить сценарий, понял — разбирать там особо нечего. В YouTube и так много собесов, а сама идея прожарки как раз в другом: найти ошибки, разобрать их и понять, что можно было сделать лучше. Поэтому решил взять первый серьезный собес ученика в Big Tech. Ученик учился 8 месяцев: прошел весь стек, закрыл все основные темы и сдал 13 экзаменов. После этапа теории еще 2-3 месяца ушли на практику, стажировку, создание резюме, проработку опыта и подготовку самопрезентации. И вот здесь есть важный момент. Когда ты проходишь большой объем теории, а потом несколько месяцев фокусируешься на практике и подготовке выхода на рынок, часть тем уже не ощущается так свежо, как сразу после изучения. Поэтому перед собесами всегда важно возвращаться к базе и держать знания в тонусе. Сейчас рынок тяжелый, поэтому стратегия была не уходить в бесконечную подготовку, а быстрее выйти на рынок: начать откликаться, получать реальные собеседования и параллельно повторять уже изученный материал. Плюс нужно учитывать временной лаг: часто после отклика проходит 2-4 недели, пока HR дойдет до резюме и начнется активная коммуникация с компаниями. Но хорошее позиционирование сработало быстрее, чем ожидали. Уже в первые дни начали приходить сообщения от компаний, а технические этапы начали назначаться буквально через пару дней. Среди них были крупные компании: Альфа, Сбер, VK, Яндекс, X5 и другие. Поэтому я и решил прожарить именно первый его собес в Big Tech: сделать работу над ошибками, вместе с Антоном разобрать моменты, дать советы и навалить базы. 📚 Материалы для подготовки к собеседованиям Что важно понять из этой истории: — Даже на сложном рынке правильная подготовка и позиционирование могут привести к большому количеству возможностей. — Даже если ты прошел все темы и сдал десятки проверок, нельзя терять тонус. Базу нужно постоянно поддерживать. — Любой собес — это не приговор, а обратная связь. Он показывает, что нужно докрутить перед следующими этапами. — Не стоит быть вечным учеником. Конечно, если бы подготовка продолжилась еще 1-2 месяца, знаний было бы еще больше. Но было бы столько собесов? А кто его знает, рынок меняется быстро. Спустя месяц после этого собеса ученик получил оффер в финтех-компанию с хорошей зарплатой — 260к. Он не сдался, продолжил искать, сделал работу над ошибками и выбрал правильную стратегию выхода на рынок. 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

Про ИИ истерию. Полностью согласен. Наконец-то все собрали в одно видео 😁 https://youtu.be/t_Z-KkJamSg?si=bBuScU9n-NHN2fQr

🖥 CI/CD для фронтендера часть 2 Недавно мы разобрались с основными понятиями: что такое CI/CD, GitOps, Docker, Kubernetes и зачем вообще фронтендеру понимать эти вещи. Теперь давайте посмотрим, как выглядит путь обычной задачи в реальном проекте. Представим, что разработчик берет задачу YH-1422. Под нее создается отдельная ветка, например:

feature/YH-1422

В этой ветке пишется код, фиксируются изменения через commit, после чего они отправляются в удаленный репозиторий:

commit → push → Pull Request

Еще до отправки кода могут запускаться локальные проверки. Обычно это Husky, линтеры, форматирование или тесты. Их задача — поймать простые ошибки еще до того, как изменения попадут в репозиторий. Это еще не CI, а скорее локальная автоматизация, которая помогает разработчику. После создания Pull Request уже подключается настоящий CI. В зависимости от проекта автоматически могут запускаться: — установка зависимостей; — линтеры; — тесты; — сборка приложения; — дополнительные проверки безопасности или качества кода. Если хотя бы одна проверка не пройдет, замержить изменения, скорее всего, не получится. Часто CI интегрирован с таск-трекером. Например, после создания Pull Request задача автоматически переходит в статус In Review, а после merge — в Done. Разработчику уже не нужно менять статусы вручную. На некоторых проектах для каждого Pull Request автоматически создается отдельное тестовое окружение (Preview Environment). То есть изменения из ветки feature/YH-1422 разворачиваются по отдельному адресу, и тестировщики или заказчик могут проверить новую функциональность, не затрагивая общий стенд разработки. После того как код прошел ревью, получил аппрув и успешно протестирован, Pull Request мержится в ветку develop. И вот здесь для большинства проектов заканчивается CI и начинается CD. Дальше коду предстоит пройти еще несколько этапов: — сборка приложения; — создание Docker-образа; — публикация образа в Registry; — обновление приложения в Kubernetes; — синхронизация через GitOps (например, с помощью ArgoCD). Именно на этом этапе код превращается в работающее приложение, которое увидят пользователи. Но это уже отдельная большая тема. В следующем посте разберем весь путь от merge до деплоя в Kubernetes и посмотрим, что происходит "под капотом". 🙂 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

Если хочешь развиваться в бэкенд-разработке — выстроить сильную базу, углубиться в архитектуру или перейти в роль тимлида — в Центральном университете есть магистратура под каждый сценарий. И на нее можно получить грант до 75%. Места ограничены, дедлайн подачи заявок — 20 августа. «Бэкенд-разработка» — это офлайн-направление (пары по вечерам и в выходные в центре Москвы) с тремя треками на выбор: ⚫️Технический — для студентов старших курсов и разработчиков в начале карьеры. Языки программирования, DevOps-инструменты, базы данных, архитектура ПО и распределенные системы. Программа ежегодно обновляется под реальные запросы компаний, а преподают разработчики, тимлиды и CTO из ведущих IT-компаний. К выпуску — сильное портфолио бэкенд-проектов ⚫️Совместный с MAGNIT TECH — обучение на реальных кейсах и архитектуре распределенных систем федерального масштаба, буткемп с экспертами компании и возможность выйти на оплачиваемую стажировку в техническую команду в течение первого года ⚫️Тимлидский — для опытных разработчиков, которые хотят перейти к роли руководителя команды: выстраивать процессы разработки, принимать архитектурные решения и развивать команду Магистратура в ЦУ — это 2 года обучения, которое можно совмещать с работой, и диплом государственного образца. Карьерная поддержка начинается еще во время учебы: консультации, тренировочные собеседования и помощь с трудоустройством. Студенты уже в процессе обучения выходят на новые позиции или повышаются в грейде в Яндексе, Авито, Т-Банке и других компаниях. Поступление проходит через грантовый конкурс — это одновременно способ попасть на программу и возможность выиграть финансовую поддержку на все время обучения: грант покрывает до 75% стоимости. В 2026 году доступно 550 грантов на все программы магистратуры. Подробнее о программе и условиях участия в конкурсе — по ссылке

💼 Топ инструментов и технологий, которые стоит добавить в резюме Все привыкли, что основные навыки любого фронтендера — это JavaScript, TypeScript, React. Сюда же можно добавить основной стек: Redux, Router, FSD и различные библиотеки типа React Hook Form. Но знали ли вы, что ваша конверсия на рынке может сильно проседать, если в резюме нет навыков, которые не всегда используются в работе, но при этом почти все хотят видеть у кандидата? Давайте обсудим. 👩‍💻 1. Next.js Пожалуй, самый очевидный навык, но многие его до сих пор не указывают или не доходят до него, считая чем-то опциональным. Хотя уже создается ощущение, что Next.js есть почти в каждой вакансии. И если его нет в вашем резюме, есть вероятность, что вы просто не пройдете ATS. 👩‍💻 2. Тесты: unit-тесты, Jest и всё вокруг этого Иногда мне кажется, что требования к вакансиям просто штампуются по одному шаблону. Ну прям везде нужны тесты. А по факту на работе часто звучит одно и то же: — Ой, пока времени нет писать тесты, но мы планируем внедрить. Тем не менее, в резюме наличие опыта с тестированием сильно повышает вашу привлекательность для работодателя. Даже если на текущем проекте тестов было не так много. 👩‍💻 3. Архитектура и микрофронтенды Сказать, что у всех компаний сейчас на рынке микрофронтенды — будет лукавством. Но при этом это очень важный навык на перспективу. Такой себе навык «на вырост». Ну а что? Компании могут себе позволить выбирать, рынок сейчас больше на стороне работодателя. Раньше, если ты указывал архитектуру в резюме, это могло добавить тебе +100к к вилке. А сейчас это постепенно превращается в норму. Те же 250к в месяц уже не выглядят чем-то фантастическим для специалистов с таким уровнем. 👩‍💻 4. CI/CD, деплой, Docker Скоро фронтендер станет просто программистом и заменит бэкендера. Но если серьезно — от фронтендеров действительно требуют всё больше. И постепенно от всех разработчиков будут ждать понимания инфраструктуры. (Шутка про бэкендеров, не бейте 😄) Если вы не погружаетесь в систему, не изучаете инфраструктуру, а главное — не указываете это в резюме, ATS может вас просто отсеять. Научиться базово настраивать инфраструктуру, понимать деплой и знать, как это делают на реальных проектах, точно стоит. Мораль В общем, рынок очень плавно меняется. Все ожидали, что однажды все разом потеряют работу, потому что придется стать супер-пупер AI-инженерами и фулстеками. Но нет. Всё происходит гораздо спокойнее. Просто каждые полгода к вашей работе добавляется новый навык или инструмент. Сначала это идет как: «Будет плюсом» А потом превращается в: «Требуется в вакансии». Постепенно будет становиться больше вакансий для таких универсальных инженеров-программистов, как в старые добрые времена, когда ты был одновременно фронтендером, бэкендером, админом, DevOps-инженером и тестировщиком. Но это не значит, что нельзя остаться просто фронтендером. Сейчас же всё еще есть просто верстальщики или разработчики чисто на JavaScript. Просто рынок сам всё расставил: таких вакансий стало меньше. Ко мне до сих пор приходят ребята с опытом 4–6 лет, и весь их опыт — это чистый JS с кастомными фреймворками, которые существуют только в их компании. И что? Ничего страшного. 3–4 месяца переучиваются на React и сопутствующие инструменты — и находят новую работу. 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

💻 CI/CD для фронтендера Должен ли фронтендер знать, как устроен CI/CD на его проекте? Сложный вопрос. Если говорить про уровни, то я бы разделил так. Сеньор должен понимать систему целиком. Не обязательно знать каждую настройку инфраструктуры, но он должен понимать: — где собирается приложение; — какие проверки проходят перед merge; — как код попадает в окружения; — где происходит деплой; — какие инструменты участвуют в процессе. То есть понимать не только "я сделал push и оно само задеплоилось", а что именно произошло между этими событиями. Мидл должен понимать общую картину проекта: — какие проверки запускаются; — как работают линтеры; — где запускаются тесты; — как происходит сборка приложения; — какие процессы настроены в репозитории. Например, какие workflow существуют, что проверяется на Pull Request, что происходит после merge. А вот джун не обязан глубоко разбираться в инфраструктуре. Но базовое понимание жизненного цикла изменения сейчас становится важным навыком. Особенно учитывая современные инструменты и нейросети: простые задачи разработки становятся доступнее, а понимание системы вокруг кода становится одним из факторов роста. 📕 Давайте немного разберем GitOps подход и основные понятия. CI/CD — это набор практик автоматизации, который помогает проверять, собирать и доставлять код. CI (Continuous Integration) — это процесс постоянной интеграции изменений: — проверка кода; — линтеры; — форматирование; — тесты; — сборка приложения. CD (Continuous Delivery / Deployment) — это доставка изменений в окружения: — создание сборки; — публикация артефактов; — деплой приложения. Workflow — это сценарий автоматических действий, который запускается при определенном событии.

push → запустить проверки
Pull Request → запустить тесты и сборку
merge в develop → задеплоить приложение

Pipeline — это последовательность шагов внутри workflow.

1. Скачать код из репозитория
2. Установить зависимости
3. Запустить линтер
4. Запустить тесты
5. Собрать приложение
6. Создать Docker image

Docker — это технология упаковки приложения вместе с необходимым окружением в контейнер. Например, наше фронтенд приложение после сборки может превратиться в Docker image, который потом будет запущен на сервере. Kubernetes — это система управления контейнерами. Она отвечает за то, чтобы приложение работало: — нужное количество копий; — автоматический перезапуск; — распределение нагрузки; — обновление версий. GitOps — это подход, при котором Git становится источником правды для состояния системы. То есть мы не идем вручную на сервер и не говорим "обнови приложение". Мы описываем желаемое состояние в Git, а специальные инструменты сами приводят систему к этому состоянию.

В Git указано:
- версия приложения: 1.5.0
- Kubernetes сейчас работает на версии 1.4.0
- Инструмент GitOps увидит расхождение и обновит приложение.

ArgoCD — один из таких инструментов. Он следит за Git-репозиторием и Kubernetes-кластером, сравнивает текущее состояние с описанным в Git и синхронизирует их. В следующий раз разберем весь флоу — от момента написания кода до полноценного деплоя. Получилось слишком много информации, поэтому пришлось разделить тему на несколько частей 😁

👩‍💻 Топ тем с Frontend собеседований Суть в том, что на собеседованиях почти никогда не проверяют “конкретный вопрос” в буквальном виде — проверяют понимание темы, которая за ним стоит. Формулировка может быть любой, от базовой до усложнённой, но она всегда указывает на один и тот же слой знаний 1️⃣ Асинхронность и Event Loop (JS runtime) Сюда попадает почти треть вопросов: - event loop - microtask vs macrotask - setTimeout / setInterval - порядок выполнения задач - Promise и их поведение 👉 Суть темы: как JavaScript выполняет код, как устроены очереди задач и почему асинхронность работает именно так. 2️⃣ Контекст выполнения и базовая модель JS - this и контекст - hoisting (всплытие) - var / let / const - стрелочные функции - типы данных в JS 👉 Суть темы: как JS интерпретирует код: область видимости, контекст вызова, TDZ, поведение функций и переменных. 3️⃣ React rendering model - Virtual DOM - React Reconciliation - SSR (Server Side Rendering) - useEffect (зачем нужен и как работает) - useLayoutEffect 👉 Суть темы: как React принимает решения о перерисовке и как устроен процесс рендера от начала до DOM. 4️⃣ Хуки и оптимизация - useEffect (разные сценарии использования) - useMemo / useCallback - useRef 👉 Суть темы: управление побочными эффектами, мемоизация и сохранение значений между рендерами. То есть логика такая: в топе мы намеренно смешиваем базовые вопросы и их “соседние” формулировки, потому что на собеседованиях проверяется не конкретный вопрос, а понимание темы. Например, если есть вопрос про TDZ, мы почти всегда рядом добавляем базовый вопрос про var/let/const — не потому что это отдельные сущности, а потому что они относятся к одной и той же зоне знаний: область видимости, hoisting, замыкания и механизм выполнения JS. Мы также следим за формулировками вопросов и стараемся их унифицировать, но в реальности они могут немного отличаться от собеса к собесу, поэтому допускаются вариации. Статистика

Сходка в Питере 2026 🚀 В моменте нас было 36 человек. Из них 31 — мои ученики! 5 — те, с кем мы познакомились в YeaHub и они помогают мне развивать проект 🚀 Честно говоря, я был приятно удивлён. Всё-таки это не Москва, где на сходку в 2025 году пришло около 14 учеников. Это Питер, не менее большой город, но не столица Было очень круто увидеть всех вживую и познакомиться лично. Кого-то я знаю уже 2–2,5 года, кого-то всего месяц, но был рад встретиться с каждым. На встречу пришли как выпускники, так и те, кто ещё находится в процессе обучения. Круто было наблюдать, как ребята, которые уже нашли работу, делились своим опытом и развеивали страхи новичков. Рассказывали, как проходили собеседования, искали первую работу и справлялись с трудностями на старте. Отдельно порадовало, что многие ребята познакомились ещё на мок-собеседованиях и внутри сообщества. Для кого-то это была первая встреча вживую после месяцев общения в чатах и совместной подготовки. План был такой: 📍 В 14:00 встретились в Новой Голландии. Посидели на газонах, пообщались, позагорали, выпили кофе. 🚶‍♂️ В 17:00 отправились пешком до Севкабеля, где нас ждал лофт. 🍕 В 18:00 началась основная программа. Пицца, пиво, кола — всё как на настоящих конференциях и митапах. Было 5 докладов от учеников, много общения, обмена опытом и полезных знакомств. Время пролетело незаметно — целых 4 часа. Теперь хочу проводить такие встречи чаще. Следующая — Москва. Цель — собрать 50+ участников. И что самое приятное — организация обошлась не так дорого, как я ожидал. А вот эмоций, впечатлений и мотивации хватит надолго. Сегодня ещё встречаемся с ребятами на прогулке по Питеру. Подарю им футболки Ехаб — к самой сходке они не успели приехать, доставку перенесли на 4 дня. Люблю своё дело. Люблю помогать ребятам находить работу и менять свою жизнь. В конце встречи чуть слезу не пустил. Было очень много слов благодарности. Наверное, это и есть лучшее подтверждение того, что я всё делаю правильно. Я за честность, прозрачность и открытость. По-другому не умеем ✊🏻

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

Проверено на личном опыте: я тоже преподаватель-ментор. Менторство помогает структурировать знания, видеть пробелы и сильнее разбираться в теме. Это недооценённый, но очень сильный формат профессионального роста.

Отличную возможно для этого предлагает Центральный университет: фаст-трек для будущих преподавателей — это шанс для разработчиков попробовать себя в новой роли уже этой осенью. Всего за одни выходные 27 и 28 июня вы пройдете основные этапы найма: — техническое интервью с действующим преподавателем; — пробное 20-минутное занятие. Тем, кто справиться со всеми этапами, подберут академическую команду до 3 июля. Кого ждут в Центральном университете: — мидл-разработчиков с уверенным навыком в Python, Java или одном из языков фронтенд-разработки; — сеньор-разработчиков, которые работают с инфраструктурой, инжинирингом данных или архитектурой решений. Не помешает основной работе, преподавать можно от 5 часов в неделю. В команде уже более 600 преподавателей, 70% из которых — практики из Т-Банка, Avito, Яндекса, VK и других ведущих компаний. 27 и 28 июня, онлайн и в кампусе Центрального университета (м. «Маяковская»). Регистрируйтесь здесь до 24 июня

🖥 Задачи с собеседования в ВК А вот и задачи подъехали Какой порядок вывода будет?

requestAnimationFrame(() => {
    console.log(0);
});
setTimeout(
    () => console.log(1),
    0
);
Promise.resolve().then(
    () => console.log(2)
);
new Promise((resolve, reject) => {
    console.log(3);

    resolve();
    reject();
}).then(
    () => {
        console.log(4);
        throw 5;
    }
).then(() => {
    console.log(6);
}, () => {
    console.log(7);
}).catch(() => {
    console.log(8);
}).then(() => {
    console.log(9);
});
Promise.resolve().then(
    () => console.log(10)
);
console.log(11);

Отрефактори код:

function App({ userId }) {
  const [user, setUser] = useState(null);

  const processUser = (user) => {
    return {
      ...user,
      friendIds: user.friends.reduce((acc, friend) => [...acc, friend.id])
    };
  };

  useEffect(() => {
    fetch(`https://api.vk.com/method/users.get?userId=${userId}`).then((response) => {
      setUser(processUser(response));

      if (user.status === "inactive") {
        const { toast } = useToast();

        toast("Пользователь неактивен.");
      }
    });
  }, [userId, processUser, setUser]);

  if (user?.status === "active") {
    const userIsOnline = useUserOnline(userId);
    if (userIsOnline) {
      const { toast } = useToast();

      toast("Пользователь в сети");
    }
  }

  return (
    <div>
      {user.friendIds.map((friendId) => {
        return <li>{friendId}</li>;
      })}
    </div>
  );
}

Доп. вопросы: • Что делает этот код? • Какие проблемы в нём есть? • Какие ошибки возможны? • Что не так с массивом зависимостей useEffect? • Какая cleanup-функция должна быть? • Почему processUser может работать некорректно? • Что будет без response.json()? • Что произойдёт, если user === null? • Какая ошибка возникнет, если вместо массива придёт null? • Поможет ли значение по умолчанию [] избежать падения приложения? 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

💼 Техническое интервью во ВКонтакте (Frontend) Очень много вопросов из совершенно разных областей: от вёрстки и специфичности CSS до устройства браузера, Event Loop, производительности, React и TypeScript. По зарплате ожидания были от 220k+, но с этим у VK обычно проблем нет — для сильных Middle специалистов вилки в районе 260–300k выглядят вполне реалистично. 🖥🖥 HTML/CSS • Что такое доступность (Accessibility) и зачем она нужна? • Каким инструментом экранный диктор читает aria-label? • Если у элемента есть класс и ID с одинаковым CSS-свойством — какой стиль применится? • Что такое специфичность (Specificity) селекторов? • Разница между display: none и visibility: hidden? • Какие виды позиционирования существуют? • Чем отличаются relative, absolute и fixed? • Как управлять специфичностью стилей? • Влияет ли порядок объявления селекторов на итоговый стиль? • В каком порядке браузер ищет элементы по сложному селектору? • Как центрировать элемент? Назови несколько способов. • Что производительнее: Flexbox или Grid? • Что лучше для анимаций и перемещений: transform или изменение координат? • Что вызывает reflow и repaint? • Может ли getBoundingClientRect() инициировать reflow? 🖥 Браузер и производительность • Что происходит после ввода URL в адресную строку? • Как браузер загружает страницу? • Как происходит рендеринг элемента? • Какие структуры строятся помимо DOM? • Чем отличаются async и defer? • В каком порядке выполняются несколько defer-скриптов? • Как работают inline-скрипты? • Блокируют ли async/defer парсинг HTML? • Какие метрики производительности знаешь? • Что такое LCP? • Что такое TTI? • Где смотреть метрики и как их улучшать? • Какой формат изображений считается современным? • Нужен ли fallback для WebP/AVIF? 🖥 JavaScript • Какие области видимости существуют? • Способы объявления функций. • Отличие Function Declaration от Function Expression. • Примитивные и ссылочные типы. • Что такое NaN? • Какой у NaN тип? • Чем Map отличается от Object? • Для чего нужен Symbol? • Что такое утечки памяти? • Почему они возникают? • Как избежать утечек? • Что означает утечка памяти для клиента? • Что такое Event Loop? • Как он работает? • Примеры макротасок. • Клики и события — микро- или макротаски? • Что будет, если длинная макротаска занимает поток? • Когда обработается пользовательский клик? • Как вынести тяжёлые вычисления? • Что такое Web Workers? • Выполнение скрипта — это микро- или макротаска? • Как Event Loop связан с рендерингом? • Можно ли строить анимации на Promise? • Что такое замыкание? • Что именно хранит замыкание? • Что такое Execution Context? • Как работает this? • Что делают call, apply и bind? • Чем стрелочная функция отличается от обычной? • Какой глобальный объект используется в Node.js? 👩‍💻 React • Зачем вообще нужен React? • Почему появился Virtual DOM? • Что такое реконсиляция? • Какие причины перерендера компонента существуют? • Что происходит с дочерними компонентами при размонтировании родителя? • Что такое Hooks? • Почему сообщество ушло от классов? • Какие ограничения есть у хуков? • Почему важен порядок вызова хуков? • Как писать кастомные хуки? • Распространяются ли на них правила хуков? • Какие способы оптимизации React-приложений знаешь? • Как работает React.memo? • Когда мемоизированный компонент всё равно перерисуется? • Для чего нужен useCallback? • Как оптимизировать код, доступный только авторизованным пользователям? • Что такое Suspense? 🖥 TypeScript • Что такое TypeScript? • Основные плюсы и минусы. • Как запретить сборку при TS-ошибках? • Насколько TS обеспечивает реальную типобезопасность? • Чем any отличается от unknown? • Что такое Generics? • Как вывести тип пропсов компонента? 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

🤝 Сходка в Питере с учениками Менторство уже давно переросло формат простой подготовки к трудоустройству и стало чем-то гораздо большим. Мы встречались в Москве летом 2025 года, вместе выступаем, общаемся, работаем в онлайн-коворкинге и поддерживаем друг друга на пути к цели. Всё это объединяется вокруг одного центра — YeaHub, где ученики проходят стажировку и получают свой первый реальный опыт работы в индустрии. Мы — команда. 🚀 Для меня сообщество — это самая важная часть всего процесса. Сообщество людей с общей целью: прокачаться, получить практический опыт и найти работу. И мы делаем всё возможное, чтобы каждый участник смог этого добиться. 💪 Ребята выступят с докладами, их первый ивент😁 А еще подготовил для выпускников 12 футболок YeaHub 🚀 19 учеников подтвердили 100% участие, еще 16 с большей вероятностью будут на сходке 🤯 Только так, а по другому не умеем. Будь с лучшими — Будь с YeaHub

Подъехал топ задач на собеседованиях 1. Сжатие последовательности чисел в диапазоны (Compress Numbers to Ranges) Дают задачу: VK, Яндекс, Сбер, Озон

function compress(numbers) {
    // TODO: напишите решение здесь
    return "";
}

https://app.yeahub.ru/tasks/7b6dff40-f902-40c5-b7d8-c92aef1ceada 2. Реализация функции compose (Function Composition) Дают задачу: Яндекс, Озон, Симбирсофт

function compose(...fns) {
    // TODO: напишите решение здесь
    return (x) => x;
}

https://app.yeahub.ru/tasks/58ba2a4b-0598-4bdf-92f7-e5b4c8a6d8fe 3. Обход объекта и сбор значений (Traverse Object) Дают задачу: Яндекс, Сбер, WB, Озон

function traverseObject(obj) {
    // TODO: write your solution here
    return "";
}

https://app.yeahub.ru/tasks/f861e899-cf37-48a8-a4db-5b99fc6fb685 4. Банкомат (ATM) Дают задачу: Яндекс, Сбер, Авито, Оптимакрос

function getMoney(amount) { // TODO: write your solution here return { 5000: 0, 1000: 0, 500: 0, 100: 0, 50: 0 }; }

В YeaHub мы стремимся связывать задачи с собеседований между компаниями, чтобы формировалась максимально полная картина. Активно пополняем платформу новыми собесами 💪🏼 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

Столько времени прошло, блогу уже 3 года 🥹 Все получится, нужно только начать 🙏🏻

💼 Как устроен C-level в IT-компаниях Когда говорят про карьерный рост в IT, обычно обсуждают путь от Junior до Team Lead или Head of Department. Но чем выше уровень компании, тем чаще появляются загадочные аббревиатуры: CEO, COO, CTO, CFO, CPO. Пока я проходил обучение операционному управлению на курсе COO в "Стратоплане" (https://stratoplan-school.com/coo/), у меня постепенно сложилась более цельная картинка того, как устроен C-level в IT-компаниях и как между собой связаны роли руководителей. Упрощенно это выглядит так: - CEO — определяет направление развития бизнеса и отвечает за результат компании в целом. - COO — превращает стратегию в работающую систему. Если CEO отвечает на вопрос «куда идем», то COO отвечает на вопрос «как именно туда придем». - CTO — отвечает за технологии, архитектуру, инженерные решения и техническое развитие продукта. - CPO — отвечает за продуктовую стратегию, развитие продукта и ценность для клиентов. - CFO — отвечает за финансы, бюджетирование, финансовое планирование и устойчивость бизнеса. - CMO — маркетинг, позиционирование и рост клиентской базы. - CHRO — люди, культура, развитие команд и организационная эффективность. Интересно, что роль COO часто остается «за кадром», хотя именно через нее проходят практически все вопросы операционного управления: — реализация стратегии; — построение бизнес-процессов; — финансовое планирование; — управление эффективностью; — организационная структура; — KPI и метрики; — управление изменениями; — работа со стейкхолдерами. Курс мне понравился — почти 5 месяцев обучения, много теории и практики, работа в группах. Было довольно много материалов и занятий как по основной программе, так и дополнительных: мастер-классы по работе с ИИ, автоматизации процессов и отдельные модули для руководителей. Наверное, самое ценное для меня — это работа в группах. Мы разбирали задания вживую: сначала получали кейс и самостоятельно думали над решением, а затем обсуждали в группе. Иногда делились на роли и разыгрывали ситуации, где каждый отстаивал свою часть решения или позицию. Почти все задания были специально «неоднозначные» — без одного правильного ответа. Сначала кажется, что решение очевидно, но затем появляются новые вводные, которые полностью меняют картину. И в итоге это не про правильность ответа, а про умение аргументировать, договариваться и пересобирать позицию по мере появления новой информации. В целом это хорошо прокачивает именно управленческое мышление: когда нет фиксированного решения, а есть контекст, ограничения и необходимость постоянно пересматривать выбор. Сертификат тоже получен — логичное завершение этой истории 😄 Работаем дальше 💪🏼 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube