Всем привет!

Запускаю свою вторую попытку создать активное и полезное сообщество (на самом деле это уже удалось: в чате с учениками — 215 человек, и там отличная активность; теперь хочется сделать ещё и открытую бесплатную версию).

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

Параллельно собираюсь активно ворваться на YouTube — идей действительно много. Фактически у меня уже есть готовые сценарии: мои собственные курсы с менторства. Осталось всего лишь начать записывать видео, так что контента будет достаточно!

Сообщество будет закрытым, но бесплатным чатом. Назвал его «Frontend Элита» 😂
Буду рад каждому участнику. До конца недели пришлю ссылку сюда

Давайте вместе сделаем фронтенд снова великим! 💪 😇

💪 Frontend Элита — сообщество фронтендеров от Reactify x YeaHub

Ну что, пора начинать! Чат ещё не полностью доделан, но уже готов принимать своих первых участников 🙌

Присоединяйтесь, коллеги и единомышленники!
Чат абсолютно бесплатный — впереди гайды, полезные материалы и различные активности, которые мы будем постепенно добавлять.

Добро пожаловать в наше сообщество! 🚀

https://news.1rj.ru/str/+TCFPcrZTS9YwZDli

🖥 TypeScript — как его стоит изучать

Есть важный момент: в реальной работе разработчик использует далеко не весь TypeScript — зачастую лишь 20–30% его возможностей. Поэтому новичку совершенно не обязательно сразу пытаться охватить всю технологию. Это только замедлит процесс, усложнит обучение и снизит эффективность.

К тому же теория без практики даётся тяжело, изолированные примеры часто непонятны, а задачи по TS поначалу кажутся перегруженными. В результате уходит много времени, а прогресс ощущается слабым. Классическое правило 20/80 здесь работает идеально: небольшой, но правильно выбранный набор знаний даёт максимальный результат.

🔹 Этап 1 — База + поверхностное знакомство с продвинутыми темами

На старте важно понять только основу типизации:
- примитивные типы
- type
- interface
- union-типы
- type aliases

И всё! Поверьте, большинство опытных разработчиков не держат в голове сложные типизации событий или утилит — всё это гуглится за 10 секунд.

Главное — практика. Получать ошибки TypeScript, гуглить их, разбираться — именно так и формируется настоящее понимание логики TS.

Что делать на этом этапе?

1. Посмотреть 1–2 курса (любые):
Полный курс TypeScript за час — https://www.youtube.com/watch?v=V7hBejCH1HI

TypeScript с 0 до Профи. Полный курс + Практика — https://www.youtube.com/watch?v=PYWaUwjofJo

2. Сразу начать проект:
Туду-лист, работа с API, калькулятор — неважно. Главное, чтобы был реальный код, а не только теория.

Идеальная длительность этапа — примерно 2 недели.

🔹 Этап 2 — Продвинутые темы (после освоения React, RTK)

Этот этап точно не нужен новичку. Продвинутый TS лучше изучать тогда, когда уже освоен весь React-стек и есть несколько пет-проектов.

Что входит в продвинутую часть?
- Generics
- Utility Types
- Type Guards
- Маппинг типов
- Сложные паттерны типизации

Как изучать?

1. Посмотреть фундаментальный курс:
TypeScript ФУНДАМЕНТАЛЬНЫЙ КУРС от А до Я — https://youtu.be/LWtHl__oEWc?si=JQidflBDL61By3mS

2. Начать решать задачи:
https://bigfrontend.dev/typenoscript
https://github.com/type-challenges/type-challenges

⭐️ Почему так?

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

Точно так же, как нет смысла проходить весь React от и до при первом знакомстве, нет смысла полностью изучать TypeScript на старте.

Кстати, начал внедрять такие практики на менторстве. Снова все улучшать и переделывать курсы свои😅

#typenoscript

🤒 Рынок ошалел. Сеньоры больше не нужны

Провёл небольшой эксперимент на HH: решил создать «идеального кандидата» — выпускника МФТИ, с английским C1, опытом работы в топ-компаниях (Т-Банк, ВБ, Яндекс), участием в олимпиадах и хакатонах, и общим стажем около 5 лет.

Резюме сделал максимально аккуратным: короткие, легко читаемые пункты, сильные и чуть ли не нереалистичные достижения — в общем, всё как по учебнику идеального CV.

Ожидания были выше.

Вот какие выводы я сделал:

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

Важно: автоотказов было мало, в основном — ручные, значит фильтры я прошёл хорошо.

Цифры:
✔️ ~200 откликов — маловато, но выборка всё же репрезентативная.
✔️ 12 приглашений на собеседование.
✔️ 57 отказов.
✔️ 128 — «ожидает».

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

Из 12 «приглашений» реальных контактов с рекрутерами было всего 4 (остальное — боты/автоответы). И ни одного бигтеха — только компании около бигтех-уровня.

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

Планы: в декабре снова выйти на рынок с новым аккаунтом и похожим резюме, но уже не таким «идеальным».

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

💪 Хочешь увидеть само резюме и материалы для подготовки?
Вступай в Frontend Элиту — там я выкладываю всё самое полезное.
https://news.1rj.ru/str/+TCFPcrZTS9YwZDli

🔥 Фронтенд будущего: ИИ-инструменты и Docs-as-Code в ЮMoney

Фронтендеры из ЮMoney поделятся опытом 6 декабря, онлайн, на бесплатной IT-конференции ЮMoneyDay, который помогает делать быстрее и качественнее:

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

🟣 Docs-as-Code на фронтенде: почему выбрали Markdoc и как мы решаем практические задачи с помощью этого инструмента.

Подробнее о программе и регистрации — на сайте конференции ™️

👩‍💻 Идеальный собес на React-разработчика

Часто думаю о том, какими вообще должны быть собеседования: сколько этапов, сколько времени, что именно они должны проверять и что мы хотим увидеть в кандидате. У меня сформировалось своё мнение.

Как собесы выглядят сейчас?

1. Чистая теория.
Тут всё понятно: вопросы можно заучить, зазубрить до автоматизма — и толку от этого этапа минимум. Проверить реальный уровень сложно.

2. Теория с упором на опыт и рассуждения.
Это уже лучше. Спрашивают не «что такое утечка памяти?», а «сталкивался ли, как решал?». Не «что такое WebSocket?», а «как использовал, какие были проблемы?». Тут хотя бы можно услышать мышление кандидата, а не выученные определения.

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

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

5. Хардкор-копание в опыт.
Когда идут в глубину, разбирают рабочие кейсы, задают наводящие вопросы, проверяют по мелочам — тут уже не притворишься. Особо если затрагивают что-то рутинное, что знает только человек с реальным опытом: git-кейсы, интерфейс инструментов, реальные проблемы в проекте и т.п.

6. Лайвкодинг.
Сделать запрос, пофиксить баг, отрефакторить код. Лучше, чем алгоритмы, но всё ещё можно улучшить.

Итого: два лучших формата сейчас
— глубокое копание в реальный опыт + нюансы
— лайвкодинг с приближёнными к работе задачами

Но кажется, что можно сделать ещё лучше.

💡 Идея: собес на реальном мини-проекте

За 1.5–2 часа реально понять уровень кандидата, если сделать более «приближённый к бою» формат.

Что делаем?
1. Готовим небольшой проект, похожий на ваш реальный стек и домен.
2. Создаём трекер задач: фичи, баги, настройки инструментов, конфиги eslint и т.д.
3. Добавляем документацию и гайдлайн по стилю.
4. Кандидат ориентируется в проекте, читает доку, смотрит структуру, разбирается в задачах и процессе работы с ветками.
5. Он берёт любую задачу, оценивает сложность, начинает решать, задаёт вопросы, изучает ТЗ, ищет баги.
6. Можно пользоваться интернетом.
7. Кандидат работает с экраншарингом.

Важно: проект должен быть не «один файл», а со средней структурой — страницы, компоненты, хелперы. Тогда нейронка мало поможет: слишком много контекста. Нужно читать код, разбираться в ТЗ, проверять результат в браузере.

Что это даёт?

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

Минусы
— Тяжелее готовить новые задачи — их могут «разгадать» предыдущие кандидаты.
— Сразу нужно уделить ~2 часа времени. Но это компенсируется тем, что можно остановить собес в первые 15–20 минут, если видно, что кандидат не тянет.

Почему идея кажется логичной?
— Уменьшается конкуренция: сложнее готовиться
— Если человек справился с такой задачей — уже не важно, настоящий у него опыт или нет. Он ориентируется в коде и показывает результат.

Почему такие собесы до сих пор не распространены?

Похоже, многим компаниям просто комфортно в текущей системе. Или им действительно всё равно — лишь бы нанять кого-то «достаточного».

💪 Если хотите обсудить — присоединяйтесь в наш бесплатный чатик Frontend Элита: https://news.1rj.ru/str/+TCFPcrZTS9YwZDli

🚀 От фронтендера к руководителю (COO)

Многие из вас знают мой путь в IT, а если не знаете — вот серия постов.

→ Мой путь в IT. От монтажника до Frontend Разработчика
→ Как я изучал программирование
→ Как я искал первую работу в 2021 году
→ Мой первый серьезный проект: как я, джун, работал за мидла в британском финтехе
→ Работа в международной компании
→ Миграция бекенда и масштабный рефакторинг
→ Мой первый стартап — сервис онлайн-записи App-Salute
→ Уникальный опыт, который переоценить невозможно
→ Мой полный стек технологий

Если коротко: уже 5 лет я расту как не в себя. Мне это нравится, и я хочу большего.

Год назад я ушёл из найма, чтобы развивать свой проект YeaHub, и он растёт очень быстрыми темпами. К нам присоединяются другие менторы со своими учениками, а теперь все наши стажёры работают вместе: Frontend, iOS, Android, QA, BA/SA, AQA, Backend, Design — скоро ждём и PM.

Сегодня в команде YeaHub уже 110 участников 🤯
И я выступаю в роли непосредственного руководителя.

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

В YeaHub выстроилась чёткая иерархия: у каждой команды есть свой лид, все взаимодействуют друг с другом, процессы работают. И это круто. Потому что моя задача уже не только «делать», а отвечать за стратегию YeaHub, привлекать новых специалистов, улучшать продукт и добавлять актуальные сервисы.

Сегодня YeaHub — это полноценная компания:
процессы, графики релизов и обновлений, поддержка, маркетинг.
Но мне хочется большего.

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

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

Это серьёзные вызовы, конкуренция и масштабирование. Мне хочется дорасти до уровня таких проектов, как Хабр, Хекслет и других сильных IT-платформ. Готов ли я к этому сейчас? Честно — пока нет.

Я давно хотел изменить своё мышление и получить системные знания для руководителя. И вот этот момент настал.

С нового года я начинаю обучение на COO в Стратоплане.
Про эту школу я давно слышал, видел много отзывов — и наконец решился.

Изначально я шёл на курс CTO. Логика простая: я разработчик, значит нужно становиться техническим директором, архитектором, отвечать за технологии и инфраструктуру.

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

Мне прямо сказали: «У тебя нет проблем с технологиями. У тебя на проекте есть полноценная инфраструктура. Твой запрос — в другом. Ты хочешь развивать проект и формировать бизнес-стратегию».

Мои решения, кейсы и подход при решении задания показали, что мне ближе роль COO, а не CTO. И это был момент прозрения. Я выбирал путь «по привычке», а не по реальному запросу.

Сейчас я уже добавлен во все чаты, получил материалы и жду первого занятия в новом году. Этот курс — не просто обучение, а среда для руководителей уровня C-level: нетворкинг, реальные задачи, нестандартные ситуации и общение с сильными управленцами и наставниками из разных компаний.

Новый год — новые возможности. 💪