🖥 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

[Версия 1.3.0] - Обновление платформы

Мы продолжаем развивать YeaHub, чтобы сделать обучение ещё удобнее, эффективнее и интереснее. В этом обновлении — важные и давно ожидаемые улучшения 👇

🔹 Навыки и ключевые слова из вакансий HH
Мы запустили сервис, который помогает прокачать резюме с помощью популярных навыков и ключевых слов, встречающихся в вакансиях. Это поможет вам выше ранжироваться в поиске среди кандидатов и увеличит конверсию откликов.
https://yeahub.ru/hh-analytics?page=1&mode=skills&specialization=11

🔹 Исправления и улучшения
Мы учли вашу обратную связь: исправили баги, улучшили интерфейс и сделали работу с платформой ещё комфортнее 🧠

🔥 Скоро
1. Сервис Лайвкодинга с реальными задачами с собеседований

👉 Обучайтесь, общайтесь, растите вместе с https://yeahub.ru

#release #news #update #yeahub

👩‍💻 Идеальный собес на 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