🏆 Что ждут компании от кандидата. АТС-фильтрация кандидатов

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

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

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

Собрал для вас небольшую выборку того, чего сейчас хотят компании от фронтенд-разработчиков:

1. Оптимизировать производительность — такая формулировка встречается очень часто, примерно в 20% вакансий.

2. Разрабатывать интерфейсы и приложения — здесь много разных формулировок и синонимов, но в сумме это около 40% вакансий.

3. Внедрять новые технологии и практики — примерно 25% компаний ожидают, что разработчик будет активно предлагать и внедрять улучшения.

4. Проводить код-ревью — встречается в разных вариациях, но если объединить все формулировки, получается около 38% вакансий.

5. Проектировать архитектуру — около 18% работодателей хотят, чтобы сотрудник занимался архитектурой решений, микрофронтендами и связанными задачами.

6. Оптимизировать приложение и процессы разработки — различные формулировки этой задачи встречаются примерно в 24% вакансий.

7. Рефакторить код, модули и приложения — ощущение, что кто-то когда-то наговнокодил, а теперь новым сотрудникам предстоит это разгребать. В сумме такие требования встречаются примерно в 22% вакансий.

8. Писать тесты — от unit-тестов до полного покрытия приложения тестами. Встречается примерно в 35% вакансий.

Наверное, это основные обязанности и задачи, которые сейчас чаще всего встречаются на рынке.

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

🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

🕯 Подъехал топ задач на собеседованиях

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

💼 Техническое интервью во ВКонтакте (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

🖥 Задачи с собеседования в ВК

А вот и задачи подъехали

Какой порядок вывода будет?

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

Сходка в Питере 2026 🚀

В моменте нас было 36 человек. Из них 31 — мои ученики! 5 — те, с кем мы познакомились в YeaHub и они помогают мне развивать проект 🚀

Честно говоря, я был приятно удивлён. Всё-таки это не Москва, где на сходку в 2025 году пришло около 14 учеников. Это Питер, не менее большой город, но не столица

Было очень круто увидеть всех вживую и познакомиться лично. Кого-то я знаю уже 2–2,5 года, кого-то всего месяц, но был рад встретиться с каждым. На встречу пришли как выпускники, так и те, кто ещё находится в процессе обучения.

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

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

План был такой:

📍 В 14:00 встретились в Новой Голландии. Посидели на газонах, пообщались, позагорали, выпили кофе.

🚶‍♂️ В 17:00 отправились пешком до Севкабеля, где нас ждал лофт.

🍕 В 18:00 началась основная программа. Пицца, пиво, кола — всё как на настоящих конференциях и митапах. Было 5 докладов от учеников, много общения, обмена опытом и полезных знакомств.

Время пролетело незаметно — целых 4 часа.

Теперь хочу проводить такие встречи чаще. Следующая — Москва. Цель — собрать 50+ участников.

И что самое приятное — организация обошлась не так дорого, как я ожидал. А вот эмоций, впечатлений и мотивации хватит надолго.

Сегодня ещё встречаемся с ребятами на прогулке по Питеру. Подарю им футболки Ехаб — к самой сходке они не успели приехать, доставку перенесли на 4 дня.

Люблю своё дело. Люблю помогать ребятам находить работу и менять свою жизнь.

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

Наверное, это и есть лучшее подтверждение того, что я всё делаю правильно.

Я за честность, прозрачность и открытость.

По-другому не умеем ✊🏻

💻 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 Элита — 📚 Менторство — 📹 YouTube

💼 Топ инструментов и технологий, которые стоит добавить в резюме

Все привыкли, что основные навыки любого фронтендера — это 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

Если хочешь развиваться в бэкенд-разработке — выстроить сильную базу, углубиться в архитектуру или перейти в роль тимлида — в Центральном университете есть магистратура под каждый сценарий. И на нее можно получить грант до 75%. Места ограничены, дедлайн подачи заявок — 20 августа.

«Бэкенд-разработка» — это офлайн-направление (пары по вечерам и в выходные в центре Москвы) с тремя треками на выбор:

⚫️Технический — для студентов старших курсов и разработчиков в начале карьеры. Языки программирования, DevOps-инструменты, базы данных, архитектура ПО и распределенные системы. Программа ежегодно обновляется под реальные запросы компаний, а преподают разработчики, тимлиды и CTO из ведущих IT-компаний. К выпуску — сильное портфолио бэкенд-проектов
⚫️Совместный с MAGNIT TECH — обучение на реальных кейсах и архитектуре распределенных систем федерального масштаба, буткемп с экспертами компании и возможность выйти на оплачиваемую стажировку в техническую команду в течение первого года
⚫️Тимлидский — для опытных разработчиков, которые хотят перейти к роли руководителя команды: выстраивать процессы разработки, принимать архитектурные решения и развивать команду

Магистратура в ЦУ — это 2 года обучения, которое можно совмещать с работой, и диплом государственного образца. Карьерная поддержка начинается еще во время учебы: консультации, тренировочные собеседования и помощь с трудоустройством. Студенты уже в процессе обучения выходят на новые позиции или повышаются в грейде в Яндексе, Авито, Т-Банке и других компаниях.

Поступление проходит через грантовый конкурс — это одновременно способ попасть на программу и возможность выиграть финансовую поддержку на все время обучения: грант покрывает до 75% стоимости. В 2026 году доступно 550 грантов на все программы магистратуры.

Подробнее о программе и условиях участия в конкурсе — по ссылке

🖥 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