Pull to refresh

Comments 11

Как говорилось в комментариях это лучший этап для внесения финальных изменений в webpack stats;

В каких комментариях? Это перепечатка откуда-то?

Нет, в комментариях к коду одной из исследуемых библиотек, если не ошибаюсь, то в react-flight

Привет. Спасибо, крутая статья! Редкость нынче)

Сам активно уже год копаю тему с React-18 и и потоковым рендерингом. Все это вылилось в https://github.com/artem-malko/react-ssr-template Там есть и гидрация (данные запрашиваем и храним в react-query, тут подробнее про гидрацию и как гидрация запускается на клиенте), и про проблему загрузки чанков lazy-компонентов (тут собираем стату, а так используем ее). Живая демка — http://174.138.13.187:5000/

Интересно узнать ваше мнение, к чему пришли в итоге.

Супер, спасибо, еще код для исследований - обязательно посмотрю! :) У меня цель как раз избавиться от фрейворка в этой концепции, пока все решения слишком зависят от контекста решения. А еще сюда же надо будет докидывать поддержку WMF. Из того ресерча, что я по нему делал - там отдельный род задач - собрать все eager-chunk'и, объединяющиеся с async boundary. Если супер коротко - то WMF позволяет использовать синхронные импорты, если они используются внутри за асинхронными.

Попробую как-нить прикрутить WMF в качестве эксперимента. Думаю еще одного сервиса хватит рядом положить. Или просто какой-нить UI-kit компонент с динамическим импортом вытащу в отдельное приложение. Кажется, необходимый stats можно будет собрать сразу для всего. Потом только нужно будет придумать, как эту инфу использовать)

Ну и да, жду продолжения)

Собеседуя senior-разработчиков, для определения уровня их владения инструментами (bundlers, transpilers, post-processors, compilers), я люблю углубляться в вопросы работы webpack.

Так что я собственно знаю про webpack? Выходит, что ничего.

Так зачем терроризировать такими вопросами на собеседованиях? По честному в вакансии тогда нужно указывать "знать вебпак вдоль и поперёк наизусть, потому что это надо непосредственно для работы"

Реальность такова, что рынок наводнен middle-разработчиками, которые видят свое продвижение исключительно в лидов и руководителей, по общению с большинством из них - они достигли потолка, узнали все, что можно знать. Что происходит, когда их погружают в инфраструктурные, архитектурные или R&D проекты? Они сыпятся. Если же не погружать и не выводить из зоны комфорта - то в лучшем случае они ограничены теми инструментами, которыми пользуются ежедневно.

На собеседованиях я не задаю вопросы в лоб - «а что там внутри webpack’а». Обычно начинаю с простого, работал ли с ним, на каком уровне, отличаешь ли назначение loader’ов. Ответ говорит о многом, если повторить аналогичную процедуру с различными областями - то становится понятен общий уровень стратегического и системного мышления.

А как еще отличить senior от middle, с хорошо подвязанным языком?

Не вижу смысла различать senior от middle, да и вообще употреблять эти термины.

Но насвкиду обычно спрашиваю такое:
- что ждёшь от новой работы?
- почему ищёшь новую работу? скучно на старой? нет челенджей? надоело легаси? меняешь просто каждые пол-года/год чтоб "развиваться"? тренируешь собеседования? Каждое "да" - маркер для меня что не "синьйор"
- расскажи, самую интересную, на твой взгляд, проблему которую приходилось решать?
- что не любишь делать? (в контексте разработки)
- что нравится делать? (в контексте разработки)
- почему реакт хороший?
- почему реакт плохой?
- сколько разрабатывал продакшн-проектов одновременно? Какая была роль? Как спускались задачки?
- ну и на всякий случай, парочка тех. вопросов - типа что там по http, ws, sse; как рендерит информацию браузер; как скопировать объект; опиши ивент-луп своими словами, что это вообще? троттлинг и дебаунс - что это за слова? канвас и свг - что лучше? чем отличается веб-воркер от сервис-воркера? что это за html-символы такие, например A

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

Далее кидаем в воду (испыталка), пусть барахтается. Если выплывает, закрывает проблемы, не создаёт дополнительной энтропии как в коде так и в команде, сам в состоянии достать недостающие требования к задаче, умеет общаться с бизнесом и задавать вопросы - значит наш человек. А синьойр он или нет - как-то пофиг, эйчары пусть думают))

Все перечисленное тоже спрашиваю, кроме одновременно разрабатываемых проектов. Особенно круто работает - какие последние достижения за год-два-n.

Но это больше вопросы по софтовому собесу, а вот чем отличается веб-воркер от сервис-воркера звучит хардкорно, особенно учитывая, что мало кто применял и те, и другие))

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

А на каком основании вы легально увольняете с испытательного срока?)

Почему хардкор..достаточно просто указать что сервис-воркеры - это прокси между приложением и интернетом, со своим хитрым жизненным циклом (крутяться даже когда браузер закрыт), полезны в основном для оффлайн-фёрст подходов. Ну а веб-воркеры - это как доп. фоновая вкладка со своим собственным ивент-лупом, только без dom, поэтому полезны для тяжёлых задач, которые фризили бы основной поток.

Вот спрашивать про вебпак (который просто инструмент, сегодня есть, завтра вместо него vite) - это хардкор. Надо будет - почитает документацию, разберётся.

Для увольнения на испытательном сроке по-моему не нужно основания. Главное дать честный фидбек. Но вообще крайне редко такое бывает.

какие последние достижения за год-два-n.

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

Мы уже пошли по кругу - говорим об одних вещах на разных примерах))

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

Кроме этого, не стоит забывать, что оба участника собеседования оценивают друг друга.

Sign up to leave a comment.