Часто получаю вопросы о том, как можно адекватно оценить свой уровень на рынке. И тут думаю ответ очевидный — просто проходить собесы и смотреть, на какую должность/зп у вас получается пройти. Однако проблема у людей возникает с тем, что на первом этапе при общении с рекрутером у них спрашивают ожидания по ЗП.

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

Но, большое заблуждение заключается в том, что обязательно сразу же надо отвечать на вопрос о ваших зарплатных ожиданиях. Тут просто рекрутеры хотят сделать свою работу по проще и сразу узнать всю информацию.

Я обычно на такие вопросы отвечаю примерно так: “Сейчас рассматриваю очень много разных предложений, везде разные условия, разная команда, продукт, стек, плюшки и тд. Поэтому сложно называть какое-то конкретное число, не узнав все детали. Предпочел бы отложить данный разговор на потом. Если обе стороны все устроит, думаю сможем уже договориться и по компенсации.”

Чаще всего этот момент просто пропустят и вернутся к этому вопросу позже. Когда проходил собесы в ОАЭ/Европу, я заметил, что рекрутеры в таких случаях почти всегда сами говорят свою вилку и спрашивают, подходит ли она под ожидания. В России я такого ни разу не встречал, хотя собесов намного больше проходил.

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

Например, вы идете на мидла и ориентируетесь на ЗП 240-260. В таком случае можно сказать рекрутеру что-то такое: “Сейчас вот общаюсь с разными компаниями. Вилка примерно 240-320, ну и других деталей везде много помимо самой компенсации”.

Плюсов тут сразу несколько:

1) Вы не знаете, какой на самом деле бюджет на позицию у компании. Часто бывает, он намного выше, чем ваши ожидания (синдром самозванца есть почти у всех). Однако раз сами попросили — никто геройствовать не будет. Просто сэкономят деньги. Поэтому стоит заложить на такой случай. Если вы хорошо пройдете собес и понравитесь компании — то вам сразу же могут дать ЗП больше, чем ваши изначальные ожидания.

2) Вы оставляете окно для торга. Если назвать конкретное число — то и торговаться будет не удобно.

3) Даже если вы оценили свой уровень правильно (низ вашей вилки). То запас сверху даст психологический эффект. Если говорить простым языком, то когда вы говорите 240-320, то промежуток 240-260 выглядит как адекватное число, даже маленькое. А когда вы говорите просто 240 — то тут уже немного другой эффект получается.

Если интересна данная тема, то могу посоветовать вот этот видос и книгу “Никаких компромиссов”, автор Крис Восс (там разные типы переговоров обсуждаются, но про ЗП и работу тоже есть глава).

Ну и на конец скажу, что никто вас не заставляет всем этим заниматься. Если хотите — можете сразу называть конкретную сумму. Компании так точно проще будет. Однако если хотите получать максимально хорошую компенсацию — то лучше подходить к общению чуть более тактично.

Давайте сегодня вместо поста попробуем чуть пообщаться. Заходите в голосовой чат и задавайте свои вопросы.

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

И чаще всего вопрос почему-то один и тот же: “а что можно почитать/посмотреть?”. Тут мне кажется и лежит обычно проблема. Да, читать новый материал полезно. Но кажется после определенного момента это не дает такой сильной пользы. Вроде бы все основные знания уже есть. А что-то более глубокое и сложное не всегда нормально передашь в виде статьи или видео.

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

Да и в конце концов очередное поглощение материала сильно вперед вас не двинет. Поэтому могу посоветовать 3 вещи:

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

По началу сложно будет придумывать разные варианты. Да и накладывать их на проект и находить плюсы/минусы тоже. Но чем больше будете пробовать — тем лучше будет становиться. Тут также можно пробовать реализовывать идеи из различных статьей/книг/видосов (главное держать баланс). Ну и когда есть время — можно реально реализовывать задачу несколькими способами.

2) Делать сложные задачи вне вашей зоны комфорта. Я чаще всего советую написать клон библиотеки, которую вы постоянно используете, так как уже и функционал ясен, и в целом понимаете, какие есть детали. Еще большой плюс в том, что можно скопировать тесты и сверять свое решение относительно них. Но можно и что-то другое взять. Главное, чтобы вам было интересно и вы понимали, как работает “бизнес” часть, и думали только о коде.

3) Пробовать разбираться в темах, которые вы не понимаете. Искать ответы на свои вопросы. Лично у меня часто возникают вопросы о том, как работает какой-то инструмент, с которым я работаю. Чаще всего не весь, а какая-то определенная деталь. Либо же почему разработчики пошли на решение Х, вместо У? Какие там есть плюсы/минусы?

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

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

Получил вопрос от подписчика о том, почему JSX переданный в children или другие пропсы не будет обновляться при обновлении компонента, в который он передан.

Речь идет о таком кейсе:

<Dialog header={<Header />} />

Тут у нас при обновлении компонента Dialog, у компонента Header не будет происходить ререндер. Чтобы ответить на этот вопрос, нам нужно разобрать 2 момента.

Во-первых, при обновлении компонента Dialog у нас проп header будет иметь одно и то же значение. То есть он будет иметь ссылку на один и тот же JSX объект (подробнее тему с самим JSX разбирал вот в этом видео). Поведение в целом логичное, так работают все пропсы, но решил все же уделить этому отдельное внимание.

Во-вторых, если не меняется ссылка на JSX объект, то ререндера не будет, даже без использования memo:

const Component = () => {
  console.log("render");
  return <div>Random</div>;
};

const componentJSX = <Component />;

const Counter = () => {
  const [count, setCount] = useState(0);
  return (
    <div>
      <div onClick={() => setCount((c) => c + 1)}>{count}</div>
      {componentJSX}
    </div>
  );
};

В примере выше в консоли вы увидите "render" только один раз при первом рендере. Почему? Потому что React в первую очередь проверят, поменялась ли ссылка на JSX объект. Если нет — то и обновлять там нечего. Поэтому рендер не происходит.

В случае же если вы напишите <Component /> внутри компонента Counter, то JSX объект описывающий компонент Component будет создаваться при каждом рендере заново, что поведет за собой и дальнейший ререндер данного компонента.

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

Тут увидел, что Ден Абрамов теперь работает в bluesky (первый раз слышу, говорят, что аналог twitter).

Но что мне показалось более интересным, так это их опен сорс приложение на react-native, expo и mobx. Пока кода не так много — разобраться не должно быть сложно. Кто хотел посмотреть на какой-то референс того, как пишут код в реальном мире — думаю пример не плохой.

Также можно будет в дальнейшем следить за изменениями в ПР, что тоже бывает полезно.

А так, интересно еще насколько переход Дена повлияет на развитие React Native. Так как он над самим реактом до сих пор работает.

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

Друзья, на этой неделе будет только одно видео. Поэтому давайте проведем розыгрыш по всем «долгам». Накопилось у нас их 5.

Для тех, кто не знает, я пообещал выпускать 2 видео в неделю и 1 пост в день. За каждый пропуск розыгрываю 1:1 сессию менторинга или $50.

Чтобы участвовать, нужно оставить ровно 1 коммент под следующим постом.

Пост для сбора комментариев на розыгрыш.

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

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

https://youtu.be/8wWDGwjdbDs

Подвел итоги розыгрыша. Удача повернулась на этот раз к @stake44 @KasparovN @foydali_fkr @dragonite24 @tokarskyy. Давайте поздравим победителей!

Получил вопрос о том, откуда я беру идеи для видео и постов. Нет ли ощущения, что скоро уже не останется тем.

Данный вопрос мне показался интересным, так как раньше сам удивлялся, как у людей получается постоянно что-то придумывать. Особенно когда смотрел на каких-то ютуберов, которые снимают по 5-10 лет видео в одной нише. Да и в целом придумать тему для видео, статьи или проекта раньше было очень сложно. Порой бывало сидел 30-40 минут у ноута и просто думал.

Улучшить данную ситуацию мне помогли 2 вещи:

1) Вести список, куда я записываю свои идеи. Уделять ему минут 5-10 в день. Где вы будете вести этот список — не важно. Главное, чтобы всегда был под рукой. Мне в этом плане дефолтное приложение заметок нравится на Маке. В ноушен уже потом переношу. После того, как начинаешь вести список понимаешь, что идеи какие-то всегда есть, просто ты их забываешь. А когда они нужны — то уже ничего не вспомнишь).

2) Явная цель, для которой нужно придумывать идеи. История с двумя видео в неделю и одним постом в день в этом году совсем по другому открыла глаза на вопрос придумывания идей. Раньше у меня не было каких-то четких сроков, поэтому как-то фокуса у меня не было на том, чтобы замечать идеи вокруг. Хотя на самом деле решая даже банальные ежедневные задачи или проводя ревью можно найти очень интересные моменты, которые могут быть полезны и другим.

Когда же появились сжатые сроки и какое-то “наказание” за их нарушение, то мозг начал постоянно фокусироваться на этой теме. Например, отвечая даже на вопросы в комментариях я начал задумываться о том, есть ли у этого вопроса какое-то более глубинное происхождение, которое можно было бы раскрыть в отдельном посте или видео. Либо же смотря на код какой-то библиотеки приходят идеи, чем интересным от туда можно было бы поделиться.

В общем, все просто и банально. На чем мысли фокусируешь — о том идеи и будут приходить, а дальше их просто не забывать надо. Главное просто начать как-то. Надеюсь кому-то будет полезно.

Пара апдейтов по ближайшему контенту на канале. Готовлю плейлист по погружению в детали React. Хочется разобрать все базовые вещи, в которых у многих я вижу пробелы (наверное что-то похожее на разборы по JSX и синтетической системе ивентов). Опыт менторинга и комменты под плейлистом по хукам показали, что те моменты, которые я предполагал, что уже все знают, оказались понятными далеко не для всех. Думаю будет полезно и тем, кто раньше смотрел. Также тех, кто только пришел на канал можно будет на этот плейлист отправлять, перед видосами по хукам.

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

Также, помимо подготовки плейлиста скопилась работа по другим проектам, поэтому давайте на этой неделе вместо видео проведем 2 стрима. Проходить они будут в эти субботу и воскресенье в 12:00 по мск. Если хотите задать какие-то вопросы — буду ждать. В плане кода собираюсь начать пилить проект на Next + React Server Components. Хочется детальнее в них погрузиться и в дальнейшем сделать больше видео на эту тему (разбор опыта, какие-то паттерны, как работает под капотом).

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

В итоге после проб разных инструментов, остановился на 2-х — ts-prune и ts-unused-export. Первый уже активно не поддерживается, хотя работает в целом хорошо. Ко второму претензий нет. Даже обертка для работы в виде eslint плагина есть. Если вам нужна проверка на неиспользуемые экспорты в проекте — рекомендую попробовать.

https://github.com/pzavolinsky/ts-unused-exports

Для тех, кто тоже не любит скачивать cli различных библиотек глобально, нашел вариант, как можно этого избежать:

npx -p {package_name} {cli_command}

Вот пример со стартом ангуляр проекта, без скачивая @angular/cli:

// пишем вот это
npx -p @angular/cli ng new angular-app

// вместо
npm i -g @angular/cli
ng new angular-app

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

Начинаем через 15 минут. У кого есть время — заходите.

https://www.youtube.com/live/afWcwr9cJd0?si=pfU_RVTx75anjy2D

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

https://youtube.com/live/bp903YS4Bxk?feature=share

Наткнулся на классную статью с объяснением того, какие проблемы решает Relay (и как это делает). Раньше что-то читал о нем, но как-то не смог полноценно погрузиться. Схемы + сравнение с другими решениями супер упрощают понимание.

https://hasura.io/blog/scaling-frontend-app-teams-using-relay/