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

👩‍💻 Знаешь useEffect? Нестандартные вопросы с собеседования "на подумать"

Вот несколько интересных вопросов с недавнего frontend-собеседования. На подумать.

1. Автосохранение отправило старое название.

Пользователь поменял название черновика. До этого эффект уже поставил таймер на сохранение.

Какое значение окажется внутри callback? Почему новый рендер сам по себе его не заменит? Где здесь замыкание и что должна делать очистка эффекта?

И дополнительный вопрос: что, если сохранение уже началось?

2. Поиск показывает результаты предыдущего запроса.

На каждый символ отправляется запрос. Пользователь продолжает печатать, ответы приходят в разном порядке.

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

3. Весь редактор живёт в одном Context.

Поля формы, выбранные блоки, статус сохранения — всё положили в один контекст на страницу.

Какие компоненты будут обновляться при вводе символа? Как бы ты разделил состояние и по какому принципу?

4. На странице 200 карточек. Всё тормозит.

Карточка уже обёрнута в memo.

Что проверишь первым? Как выяснишь, где тратится время? Когда станешь менять передачу props, когда — работу с контекстом, а когда — количество отрисованных карточек?

И чем готов пожертвовать ради скорости?

В этих задачах интересно проследить весь путь: пользователь что-то сделал → состояние изменилось → код выполнился → на экране или сервере оказался результат.

Возьмите любую из них. Сможете объяснить по шагам, где именно появляется ошибка?

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

💼 Не всегда самый опытный — самый сильный

Выше я написал, что за месяц нельзя стать сильным бэкенд-разработчиком. Но потом задумался: а что вообще значит «сильный бэкенд-разработчик» и чем мы измеряем эту силу? Годами опыта?

Еще одна мысль, которая постоянно вызывает споры, — опыт и его «накрутка».

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

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

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

Поэтому для меня «5 лет опыта» и «5 лет сильного опыта» — совершенно разные вещи.

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

Но сами по себе годы ничего не гарантируют.

Именно поэтому я все меньше смотрю на разработчика через призму «сколько лет ты пишешь на X» и все больше — через то, насколько быстро ты способен разобраться в том, чего пока не знаешь.

Не знаешь Next.js? Окей. Сколько тебе нужно, чтобы разобраться и начать на нем работать?

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

Не писал бэкенд? Окей. Можешь взять NestJS, документацию, ИИ, разобраться в базе и начать закрывать задачи?

Вот в таком IT живу я.

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

И где одним из главных навыков разработчика становится не способность заранее знать абсолютно всё, а способность быстро адаптироваться и добирать знания тогда, когда они тебе понадобились.

А в эпоху ИИ ценность этого навыка, на мой взгляд, становится только выше.

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

👩‍💻 Бэкенд за 1 месяц

В прошлом видео я сказал, что фронтендер может за месяц неплохо погрузиться в бэкенд и уже начинать ходить на собеседования как фулстак, условно 80% фронт / 20% бэк, продолжая параллельно углубляться. В комментариях, конечно, зацепились за «месяц», а кто-то и за «бэкенд за неделю», хотя там я говорил конкретно про CRUD и базовые кейсы.

Расскажу, откуда у меня вообще такое отношение к скорости обучения.

Когда-то давно, еще до ChatGPT, я пришел на первую работу в аутсорс, зная только фронтенд. Мне дали задание ознакомиться с бэком и сделать CRM: CRUD, авторизация, фильтрация, сортировка, загрузка картинок и т.д.

Я тогда был джуном-гуманитарием, которому даже фронтенд дался не особо легко. И у меня был тот же стереотип: бэкенд сложнее, это уже «не для меня».

В итоге за неделю я закрыл ТЗ и задеплоил проект на Heroku. Поднял MongoDB, Express, сделал авторизацию, запросы к базе, фильтрацию и остальные кейсы. Без нейронок.

Как? Я не стал сначала «учить бэкенд». Я сразу начал делать. Смотрел курсы Минина, Ульби и адаптировал решения под свой проект. Посмотрел авторизацию — сделал у себя. Увидел фильтрацию товаров — перенес тот же принцип на пользователей в CRM. Возникла проблема — разобрался, решил, пошел дальше.

Параллельно мне дали PDF примерно со 100 вопросами по бэкенду. Я учил теорию вокруг того, что уже видел руками, а потом прошел проверку знаний у тимлида.

Стал ли я за неделю бэкендером? Конечно нет. Но за неделю прошел путь от «бэкенд вообще не для меня» до работающего приложения и понимания базовой логики.

И это было без ИИ.

Поэтому сегодня мне странно видеть подход: «Сначала 3–6 месяцев поучу новую технологию, потом попробую что-нибудь написать».

Мы живем уже в другую эпоху разработки. Если ты опытный фронтендер и переходишь на Node.js/NestJS, ты не начинаешь с нуля. Ты уже умеешь программировать, знаешь TypeScript, async/await, HTTP, REST, API, авторизацию, JSON, query-параметры. Ты годами стоял с одной стороны API — теперь нужно встать с другой.

А сегодня еще и рядом 24/7 есть ИИ, которому можно показать код, ошибку, запрос в БД или архитектуру и за несколько минут разобраться в том, на что раньше мог уйти вечер.

Поэтому мой главный принцип последних лет — адаптация.

Не «я React-разработчик и больше ничего не трогаю». Не «сначала пройду 40 часов курса, а потом начну».

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

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

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

Поэтому «бэкенд за месяц» — это не «стань Senior Backend Developer за 30 дней».

Это за месяц пройти руками основные сценарии, собрать цельную картину бэкенда, сделать fullstack-проект, подготовить базу для собеседований и дальше продолжать углубляться уже параллельно с поиском работы.

А вот как именно я бы построил этот месяц — что учить, в каком порядке, какой проект делать, когда подключать PostgreSQL, Redis, Kafka, мониторинг и микросервисы — в пост уже не влезет.

На выходных запишу отдельное видео и подробнее раскрою свою тактику "Бэкенд за месяц".

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