Господа программисты, мне от вас нужно инженерное решение. Я уже обсуждал варианты решения с друзьями из IT, пока нет ничего на 100% рабочего.

Проблема: бомжи терроризируют район Маяк Минска (это НЕ шутка!). Сейчас все мусорные баки закрыты в беседках из железных листов. На каждой беседке есть дверь с кодом. Код 2-значный и нужно вводить цифры на замке одновременно.

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

Задача: необходимо придумать решение, благодаря которому бомжи бы не ходили по району с целью опустошения мусорок.

Уже предложенные варианты:
1. Беседки с мусорными баками будут открываться при помощи чипа. Но проблема в том, что если бомжу в руки попадется чип, то вся система «защиты» рухнет.
2. Вызвать несколько раз милицию, чтобы они разогнали бомжей. Это чересчур легко, нам нужно инженерное решение!

А КАКИЕ У ВАС ПРЕДЛОЖЕНИЯ, ГОСПОДА?

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

Кратко покажу мои последние диалоги в LinkedIn.

М: Здравствуйте, мне интересна ваша вакансия. Она все еще актуальна?
Р: Добрый день, Максим! Да, актуальна.
М: Подскажите вилку ЗП по вакансии?
Р: Знаете, мы отталкиваемся от ожиданий кандидата. Какие у вас ожидания?
М: N$ чистыми в месяц. Вам подходят такие условия?
Р: Ой нет, это много для нас, мы можем дать максимум X$.

Неужто они надеются найти тех, кто попросит гораздо меньше от их максимальной вилки? 🤔

✌️React Fiber для собеседований

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

Fiber это...

Fiber – переделанная реализация алгоритма Reconciliation.

Ключевые задачи Fiber:

1. Возможность разбивать работу по рендерингу на фрагменты (чанки) и распределять данную работу по нескольким кадрам.
2. Возможность прерывать, приостанавливать или повторно использовать обновления (работу) по мере поступления новых обновлений.
3. Возможность задавать приоритет конкретным обновлениям.

Fiber Call Stack

Fiber переделывает поведение обычного Call Stack. Единицу Fiber можно рассматривать как элемент стека (либо единицу работы).

Главное преимущество Fiber Call Stack в том, что он может хранить элементы стека в памяти и исполнять эти элементы (выполнять работу) когда это необходимо, то есть Fiber Call Stack может планировать выполнение задач (scheduling). А обычный JS Call Stack так не может, он будет продолжать выполнять работу до тех пор, пока стек не опустеет.

Полезные ссылки:

1. React Fiber Architecture
2. Подробно о React Reconciliation, или Как React добился 60 fps

P.S. В следующем посте расскажу про структуру Fiber-объекта (type, key, pendingProps, memoizedProps, pendingWorkPriority и др)

✌️Структура Fiber

Ссылка на 1-ю часть про React Fiber.

Единицу Fiber можно рассматривать как элемент стека, но можно и как экземпляр компоненты. И у данной компоненты (объекта) есть несколько ключевых полей.

1. type - тип компоненты. Для обычных компонент как HTML-элементов это строка ('div', 'span' и др). Для кастомных компонент (<MyComponent /> например) type - это функция или класс.

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

3. child - это то, что возвращает компонента для рендера. В примере ниже в параметре child будет храниться MyChild.

function Parent() {
return <MyChild />
}

4. return - это Fiber элемент, к которому должна вернуться программа после обработки текущего Fiber элемента.

Из примера кода выше значением return для MyChild будет Parent.

5. pendingProps и memoizedProps - pendingProps это пропсы в начале выполнения, memoizedProps - пропсы в конце выполнения. Если данные пропсы равны, то это знак для алгоритма React, что предыдущее возвращаемое значение можно переиспользовать. А это значит, что нет необходимости в ререндере.

6. pendingWorkPriority - это число, которое обозначает приоритет единицы работы (задачи для выполнения). Чем больше число, тем ниже приоритет (всего 6 приоритетов).

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

P.S. Это конечно же не весь список, но для базового понимания хватит.

✌️Минусы React

Я уже больше 4 лет пишу на React и поэтому могу выделить несколько его минусов. При этом я немного писал на Vue, поэтому есть с чем сравнить.

1. Это библиотека и поэтому большинство разработчиков пишут на React как хотят. Многие не задумываются по поводу архитектуры, как разделять бизнес логику и UI, поэтому всё пихают внутрь компонент. Если в команде нет правил и ограничений по архитектуре, то каждый будет писать, как хочет.

2. useContext. У данного хука нет мемоизации селекторов и поэтому если делать большой объект с данными, то это будет вести к большому количеству ненужных апдейтов.

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

Если хотите больше подробностей и реальных примеров из кода про пункт 3, то наставьте 🔥 под этот пост.

3. Нужно много думать о том, как построить свое дерево компонент, чтобы предотвратить лишние ререндеры и сделать само дерево максимально оптимизированным при апдейтах. Почему разработчик должен об этом думать? Разве не проще делегировать эту задачу самой библиотеке?

4. React заставляет много думать об объектах как о ссылках. Особенно это связано с передачей объектов (или функций) в deps и пропы мемоизированной компоненты.

Допустим моя компонента обернута в memo и она принимает в себя проп-функцию. Тогда мне эту функцию нужно обернуть в useCallback, а чтобы это понять, необходимо лезть в компоненту. А я ведь могу забыть про это, что моя компонента мемоизирована. В общем, это очень большая сложность.

5. Бывают моменты, когда очень много зависимостей в useEffect, useMemo либо useCallback. Разработчику приходится следить, не забыл ли он добавить какую-либо зависимость, не забыл ли он удалить лишнюю зависимость.

А вы согласны со всеми 5-ю минусами React? Может у вас есть что добавить?)

Полезные ссылки

1. Кто не понял пункт 4, то почитайте мой пост “Когда применять React.memo? Оптимизации в React”
2. useContext в React
3. React Fiber для собеседований
4. How the useEffect Hook Works

✌️Главный минус useContext и как с ним справиться

В посте про минусы React я говорил, что одним из минусов является useContext. Главная его проблема в том, что у данного хука нет мемоизации селекторов и поэтому если делать большой объект с данными, то это будет вести к большому количеству ненужных апдейтов.

Я для вас сделал пример кода, по которому можно понять ключевую проблему useContext. Чтобы его посмотреть перейдите в CodeSandbox (с телефона тоже можно потыкать пример). В примере есть контекст CounterContext, который управляет двумя состояниями count1 и count2. Дело в том, что состояния не зависят друг от друга и используются в разных компонентах (count1 в Count1Component, count2 в Count2Component).

В примере нажмите на кнопку "increment count1". Вы сразу же увидите, что состояние обновилось и изменения отобразились на экране. Но дело в том, что изменение состояния в Count1Component ведет к ререндеру компоненты Count2Component (обратите внимание на параметр Renders amount). Хотя казалось бы, зачем обновлять другую компоненту, когда обновление интерфейса происходит в совсем другой части приложения?

В этом и состоит главная проблема контекста. И для ее решения один из разработчиков React Дэн Абрамов предлагает 3 варианта решения:

1. Разделить один контекст на два контекста.
2. Сделать вместо одной компоненты две: одна использует useContext, вторая обернута в memo и предотвращает лишние ререндеры из-за useContext.
3. Оставить одну компоненту, но весь JSX обернуть в useMemo и в качестве deps передать значения из контекста.

Более подробно про эти 3 пункта со всеми примерами кода можно ознакомиться здесь.

Честно говоря, я на практике использовал только 1-й вариант. Все остальные как-то не доводилось, да и большого смысла я в этом не видел. Все-таки я считаю, что контекст нужно использовать в правильном назначении, а 2 и 3 варианты больше исправляют неправильно применение useContext в проекте.

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

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

Хочу поделиться с вами некоторыми задачами, которые давили мне на последних собеседованиях. Позиция Middle+ / Senior 🔥. Они в принципе довольно простые, поэтому можете проверить свои знания. Я предлагаю вам не запускать код, а попробовать самим сначала решить.

Напишите потом в комментариях к этому посту, сколько вы решили задач. Я лично решил 2 из 3 :)) Вот что бывает, если не повторять базу перед собесами.

1. Задача на контекст this. Что будет выведено в консоль? Как исправить данный пример, чтобы он корректно работал?

const database = {
filterId: 'active',
users: [
{
id: 'active',
label: 'Active',
},
{
id: 'inactive',
label: 'Inactive',
},
],
getUsers: function() {
return this.users.filter(function (user) {
return user.id === this.filterId
})
}
}

console.log(database.getUsers())

2. Задача на hoisting. Что будет выведено в консоль?

(function () {
f()

f = function() {
console.log(1)
}
})()

function f() {
console.log(2)
}

f()

3. Задача на event loop. Что будет выведено в консоль? Будет ли блокироваться UI в таком случае?

sleep(2000).then(() => {
console.log(0)
})

console.log(1)

setTimeout(() => {
console.log(2)
})

function sleep(ms) {
return new Promise((resolve) => {
setTimeout(resolve, ms)
})
}

console.log(5)

function myPromise() {
abc().then((val) => {
console.log(val)
return myPromise()
})
}

function abc() {
return new Promise((resolve) => {
resolve(6)
})
}

myPromise()

Хмм, JavaScript? 😏

Вспомнил недавно одну интересную и смешную историю при переписке с рекрутером. Хочу поделиться ей.

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

Я тогда работал в аутсорсе и поэтому проектов у меня было достаточно. Я выбрал 3 хороших проекта, взял оттуда некоторые файлы с кодом: примеры redux-редьюсеров, файлы для работы с api бэкенда, ui-kit компоненты с анимацией и логикой и другое. В общем и целом, выбрал те файлы и куски кода, которыми можно "похвастаться".

После эти файлы я отправил ссылкой рекрутеру. Где-то через одну неделю я получаю сообщение в формате "Максим, наши разработчики посмотрели ваш код, вынуждены вам отказать". Я уточнил "Почему?".

Мне ответили что-то вроде:

Наши разработчики не смогли запустить ни один из ваших 3-х проектов. В вашем коде есть импорты файлов, которых не существуют. Там даже не было package.json!

Как же я сгорел с этого! Вы понимаете, они хотели, чтобы я им скинул исходники всех 3-х проектов! Полностью ВЕСЬ КОД, который я писал для других заказчиков!

Я понимаю, если они бы попросили скинуть пет проекты. Но мы на звонке с рекрутером договорились на примеры кода с реальных коммерческих проектов. Короче полный угар))

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

Если кратко, есть функция getUsers, которая вызывается подряд много раз. Не важно сколько раз вызывается, главное что много. Вопрос: что в этом коде не так? Необходимо исправить недочет.

function getUsers() {
  const users = [
    {
      filter: 'active',
      name: 'A',
    },
      {
      filter: 'Inactive',
      name: 'A',
    },
  ]
  const appliedFilters = ['active']
  const result = []

  for (let i = 0; i < users.length; i += 1) {
    if (appliedFilters.includes(users[i].filter)) {
      result.push(users[i])
    }
  }

  return result
}

getUsers()
getUsers()
getUsers()
// вызывается еще N раз (то есть очень много вызвовов подряд)

Если честно, я долго ломал голову, что не так. Единственное, до чего я додумался, что можно цилк for заменить на filter, будет меньше кода. Но это был неверный ответ.

Что ж, не буду томить, скажу правильный ответ. Только перед этим попробуйте сами подумать, что в этом коде не так, а после открывайте спойлер.

ОТВЕТ:

Нужно

вынести массивы users и appliedFilters за функцию getUsers. При многократном вызове функции getUsers создается много массивов, что влияет на размер выделяемой памяти для создания объектов в JS.

Если честно, интервьюер как бы прав. Но это очень странная задача. Прям очень странная. Зачем ее давать, не очень понятно. Мне сказали, что у них в проекте таких кейсов много и многочисленное создание JS-объектов влияет на производительность их приложения.

Но этот аргумент был бы логичным, если мы бы создавали прям большие массивы при каждом вызове функции. А в примере дан массив на 2 и 1 элемента. Поэтому как по мне, задача не очень доработана.

А вы как думаете, задача по условию нормальная либо странно ее давать на собеседовании? 🧐

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

Я последние 3.5 месяца активно проходил собеседования в АйТи компании на СНГ рынке как Senior Front-End разработчик.

В ноябре 2023 увидел классную вакансию, созвонился с рекрутером, мы обсудили детали вакансии и у меня уточнили зарплатные ожидания. Я ответил от 300 000 RUB.

(если что все суммы в данном посте выдуманные, не хочу говорить реальные цифры)

После я прошел собеседование. Через неделю мне написали, мол все круто, Максим, ты нам подходишь, ребята хотят, чтобы ты присоединился к команде. Затем выслали оффер, где написано примерно следующее.

Оклад: 220 000 RUB

Премия: раз в 3 месяца 250 000 RUB (по результатам выполнения поставленных задач, согласованных с непосредственным руководителем, а также по результатам выполнения ключевых показателей эффективности).

Мы созвонились с рекрутером, чтобы обсудить оффер. Я задал вопрос, почему оклад не 300k RUB, как мы заранее обговаривали. Мне же ответили, что вот смотри, премия 250 000 RUB раз в 3 месяца. 250k / 3 ~ 83300 RUB за 1 месяц. Значит средняя ЗП за месяц будет 220000 + 83300 = 303 300 RUB.

Также я уточнил, за что именно дается премия? Оказывается, каждые 3 месяца выводится список метрик, которые необходимо выполнить для получения премии. Какие точно метрики, не сказали, так как они согласовываются лично с лидом.

Тут я думаю понятно, что меня хотят надурить с этой премией. Нет четких определений, за что она дается. А значит вообще не факт, что премия будет каждые 3 месяца. А если у компании будет плохой рабочий квартал и недостаточно средств для премий? То велика вероятность, что меня пошлют с моими словами «ну вы же обещали, что мой оклад + премия будет примерно 300k».

Какой вывод? 🤔 Всегда при первом общении с рекрутом стоит проговаривать

Мои ожидания по окладу: от N RUB в месяц после вычета налогов. Данная сумма не должна включать в себя премии и другие бонусы, т.е. это чистый оклад.

Как я получил оффер в Яндекс с 3-й попытки…

Я ни разу не работал в бигтехе СНГ. Еще в мае 2022 года я пошел на первое собеседование в Яндекс. Кто не знает, в бигтехах обычно 3 стадии собеседований: решение задач на специфику конкретного языка программирования (в моем случае JavaScript), решение задач на алгоритмы и финальная секция по софт-скилам.

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

Осенью 2023 я начал искать новую работу. На этот раз я пошел на собеседование в Тинькофф. Там примерно такие же секции, как и в Яндекс. По итогу, я опять завалил 2-ю стадию на алгоритмические задачи :(

Меня раздражали эти задачи на алгоритмы, а еще больше меня бесило то, что я не знал, как к ним готовиться. Но в декабре 2023 я все же смог пройти все 3 стадии собеседований в Яндекс и получить оффер! Хочу вам рассказать, что мне в этом помогло.

1️⃣ Марафон подготовки к собеседованию в бигтехи от Андрея Кобеца. Я на инстаграм Андрея подписан уже давно. Он опытный разработчик, создает образовательный контент для Middle и Senior Front-End.

Марафон длился 17 дней. Каждый день Андрей отправлял в приватную ТГ-группу по 4 задачи. После 18:00 каждого дня автор марафона присылал видео с подробным разрабором решения каждой задачи. Участники марафона также присылали свои решения в текстовом формате и Андрей давал комментарии по их качеству.

За эти 17 дней я жетско прокачался в алгоритмических задачах! На собеседовании в Яндекс я их шелкал как орешки. В итоге, на 1-й секции я решил 6 задач из 6, на 2-й - 3 из 4.

2️⃣ ТГ-канал "JS-прожарка". В нем собраны задачи с реальных собеседований в бигтехи. В каждом посте содержится условие задачи, указывается компания, на собеседовании в которую давали данную задачу, а также в комментариях подписчики присылают свои решения.

Я в этом ТГ-канале сделал поиск по задачам из Яндекса и все их прорешал. Это очень помогло в подготовке к алгоритмической секции.

P.S. Если что, это ни в коем случае не реклама. Я просто делюсь своим опытом. У меня не получалось 2 раза подряд пройти секцию на алгоритмы в бигтехи. А эти два инструмента очень помогли мне хорошо подготовиться. И по итогу с 3-й попытки я все же получил оффер в бигтех (Яндекс) на позицию Middle+! 🔥

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

Почему я отказался от оффера в Яндекс?

В предыдущем посте я рассказал, как все же смог получить оффер в Яндекс с 3-й попытки. Но от оффера я отказался. Объясняю почему.

1️⃣ Зарплатные ожидания. Яндекс оценил меня как Middle+, а собешусь я на Senior. И по ЗП в других компаниях мне предлагают на 50% больше, чем в Яндекс.

Поторговаться получается разве что на +10к RUB к окладу. На все другие предложения по повышению оклада говорят «ты же понимаешь, Яндекс крутой бренд, это тебе в будущем очень сильно поможет. Строчка в резюме с надписью Яндекс играет большую роль».

2️⃣ Не совсем очевидный формат работы. Яндекс сейчас в основном топит за гибрид (3 дня в офисе, 2 дома). Я в идеале хотел удаленку, но готов был согласиться на гибрид, если команде проекта очень важно ходить в офис. «Очень важно» - это когда большинство членов команды ходит в офис, вы проводите общие собрания оффлайн и у вас действительно повышается от этого продуктивность.

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

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

3️⃣ Привязка к курсу RUB.

Я живу в Минске и мне в идеале получать ЗП либо в BYN, либо в USD. Яндекс же платит в RUB, но конвертирует каждый месяц RUB в BYN.

Я перевожу большую часть денег в USD. И поэтому конвертация RUB - BYN - USD мне точно на руку не сыграет, когда будет проблема с высокими курсами. В идеале конечно конвертировать просто из BYN в USD либо вообще иметь ЗП в USD.

---------

А для вас эти 3 пункта являются важными? Пошли ли бы вы работать в компанию при таких условиях?

P.S. Если что, я все же получил оффер, который хотел, от другой компании на СНГ рынке. Уже с конца января 2024 я работаю на новом месте. Расскажу про это подробнее в следующих постах.