Почему разработчики часто проваливают собеседование в бигтех?

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

1️⃣ Решают live coding задачи, которые навряд ли им попадутся на собеседовании. Обычно на каждом этапе есть топ тем, на которые дают решать задачи. И если знать эти темы, то во время подготовки можно сделать на них основной упор.

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

3️⃣ Недооценивают финальную секцию. Разработчики могут успешно пройти все стадии с кодом, но завалить этап на проверку софт скилов. А чтобы его пройти, необходимо знать, какие вопросы задают и заранее подготовить на них ответы.

Я сам понял все трудности, когда проходил собеседование в Яндекс. Я прошел все этапы интервью только с 3-й попытки и получил в итоге оффер на 300k+ RUB! 🔥

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

Я прекрасно понимаю ваши трудности на пути к получению оффера, поэтому подготовил для вас гайд "Как получить оффер в ЯНДЕКС на 300k+ RUB на позицию Front-End?". В нем подробно описаны все этапы интервью в Яндекс: какие задачи дают, какие каверзные вопросы задают, все дополнено полезными ссылками на материалы и многим другим.

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

Вышло новое видео на YouTube, где разбираем решение 3-х задач с реального собеседования в Яндекс 🔥

Кто еще не смотрел, переходите по ссылке https://youtu.be/ilZiDZ_rXXo?si=pBq6XrY0jrdPmr7g

Как эффективно готовиться к техническим вопросам перед собеседованием?

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

И к теории тоже стоит готовиться. Потому что интервьюеры часто задают вопросы на глубокое понимание JavaScript и React. О таких вещах мы не думаем на работе во время решения повседневных задач. Поэтому знания постепенно забываются.

Но самое главное, что эти знания можно эффективно освежить в своей голове. Как это делается? Простые заметки!

Я заметки веду в Google Keep, где сделал отдельную вкладку с различными сложными вопросами с собеседований. Там и про React Fiber, Reconciliation, Event Loop, про то как работает парсинг веб-страниц в браузере, различия SPA и SSR, минусы React как библиотеки и многое другое. Мне часто задают подобные теоретические вопросы на собеседованиях. Поэтому я заранее подготовил на них краткие ответы в виде заметок.

Итого, как проходит моя подготовка к теории? Открываю Google Keep, пробегаюсь за 20 минут по всем сложным темам, после иду уверенно проходить собеседование 🔥.

Я настоятельно рекомендую вам использовать такой же подход. Если вам задали сложный теоретический вопрос на собеседовании и вы на него не ответили, то после запишите этот вопрос в заметки, найдите на него ответ в Гугле, кратко распишите ключевые моменты. С таким подходом у вас накопится несколько записей. И потом для подготовки к следующему собеседованию вы просто откроете приложение для заметок и пробежитесь за 10-20 минут по всем сложным вопросам.

---------

А как вы готовитесь к теоретическим вопросам перед собеседованием? Сколько у вас времени занимает подготовка? 🤔

P.S. Кстати, многие свои заметки со сложными вопросами я выкладываю здесь. Почитать их можно в закрепленном посте (смотрите "Теория с собесов").

Буквально недавно в приватном сообществе выложил полностью все части гайда "Как получить оффер в ЯНДЕКС на 300k+ RUB на позицию Front-End?". 🔥

Делюсь с вами содержанием гайда. В нем подробно описаны все этапы интервью в Яндекс: какие задачи дают, какие каверзные вопросы задают, все дополнено полезными ссылками и материалами.

Присоединиться к сообществу и получить гайд можно через ТГ бота @easy_jobinterivew_frontend_bot 😉

Вышло новое видео на YouTube!

В нем подробно рассказал, как решать задачи на Event Loop на собеседованиях 🔥. В видео сначала приводится кратко вся теоретическая база Event Loop, а после дается разбор решения 2-х задач: легкой и сложной.

Кто еще не смотрел, переходите по ссылке! https://youtu.be/iL4srHpf6gE?si=J_VgUvLgCVb4WyuP

Какие существуют форматы собеседований и что вам нужно знать о них для получения оффера?

За всю свою карьеру я прошел десятки собеседований и из них могу выделить два формата интервью.

1️⃣ Интервью с большим количеством live-coding задач на JavaScript и алгоритмы. Бигтехи

Такие собеседования обычно есть в бигтехах (Яндекс, Тинькофф и т.п.). Также само собеседование разбито на 3-4 стадии, которые проводятся в разные дни.

👍 Плюсы:

- Возможность работать в крупной компании над большими проектами с миллионами пользователей.

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

👎 Минусы:

- Нужно тратить от 1-2 недель на хорошую подготовку к решению live-coding задач.

- Как уже говорил, у таких компаний обычно 3-4 этапа интервью, которые проходят в разные дни. А это большая потеря времени, особенно если получить отказ на предпоследнем/последнем этапе.

- Задают мало вопросов про ваш реальный опыт и проблемы, которые вы решали в рабочее время. Основной акцент идет на решение live-coding задач.

2️⃣ Интервью с одним этапом на 1-2 часа, где задают в основном только теоретические вопросы

👍 Плюсы:

- Время на подготовку к собеседованию занимает мало времени. Обычно от 30 минут до 2 часов (можно и быстрее, если уметь правильно готовиться).

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

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

👎 Минусы:

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

- Иногда бывает такое, что после 1 часа теоретических вопросов, могут дать решить 1-2 live-coding задачи. Как по мне, это абсолютно бессмысленно, если человек за 1 час интервью уже показал всю свою компетентность и глубину знаний.


ИТОГО

Скажу так, самый идеальный формат собеседования под пунктом 2️⃣. Он не отнимает у вас как кандидата много времени на подготовку и позволяет за один звонок показать всю компетентность знаний. Кстати, мое собеседование в текущую компанию было как раз в разговорном формате и без live-coding задач.

Но вариант 1️⃣ тоже имеет место быть, так как позволяет устроиться в крупную компанию на IT рынке.

‼️ Поэтому перед каждым собеседованием задайте вопросы HR: "В каком формате будет проходить интервью? Будет ли live coding? На какие темы обычно задают вопросы на собеседовании в вашу компанию?". Это абсолютно нормальные вопросы, не бойтесь их задать. Большинство HR подробно рассказывают про формат и часто задаваемые вопросы на собеседовании в их компанию.

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

Совсем забыл рассказать, вышло новое видео на YouTube! 🔥

еще 3 недели назад))

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

Поэтому кто еще не смотрел, переходите по ссылке! https://youtu.be/dYeOfz_ttUA?si=KFuP5zkr_NRu5Gu-

Расскажи, как работают браузеры?

Этот вопрос может попасться на собеседовании Front-End разработчику. Ставьте 🔥, если вам задавали такой вопрос на интервью.

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

1️⃣ Парсинг. Когда Браузер получил первый пакет данных, то он сразу начинает парсинг. Парсинг - Преобразование данных в DOM и CSSOM.

1.1. Построение DOM-дерева. На данном этапе происходит обработка разметки HTML.

Парсер (обработчик) кроме обычных HTML-тегов может наткнуться на неблокирующие ресурсы (например, изображения). В этот момент браузер отправляет запрос на загрузку ресурсов, но сам продолжает обработку.

Важно отменить, что тег script без async или defer - это блокирующий ресурс. Когда парсер встречает блокирующий ресурс, то обработка HTML приостанавливается до завершения загрузки скрипта.

1.2. Построение CSSOM (объектная модель CSS). Браузер считывает каждый набор правил в CSS, создаёт дерево узлов с родителями, детьми и соседями, основываясь на CSS селекторах.

2️⃣ Рендеринг. Он делится на следующие этапы: стилизация, компоновка, отрисовка и композиция.

2.1. Стилизация. На данном этапе идет комбинация DOM и CSSOM в дерево рендеринга (DOM + CSSOM = Render Tree). Render tree дублирует структуру DOM, но сюда не попадают невидимые элементы. Например, <head /> или элементы с display: none не будут включены в Render Tree, так как они не должны быть отрисованы.

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

2.2. Компоновка (layout). На данном шаге вычисляется геометрия каждого узла, то есть ширина, высота и расположение внутри окна браузера.

Важное уточнение: когда компоновка происходит 2 и более раз, то этот процесс называется перекомпоновка (reflow).

2.3. Отрисовка (Paint). Во время фазы отрисовки браузер преобразует каждое поле, вычисленное на этапе компоновки, в фактические пиксели на экране. Грубо говоря, на данном этапе идет раскрашивание элементов.

Важное уточнение: когда отрисовка происходит 2 или более раз, то этот процесс называется перерисовка (repaint).

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

Хороший пример композиции - анимация через свойства transform и opacity. Элементы с данными свойствами выносятся на отдельный слой и обрабатываются при помощи GPU (графический процессор). Если основной поток JS заблокируется (например, через бесконечный цикл), то анимация через transform и opacity будет работать и не зависнет на экране, так как она запускается в отдельном потоке. Но вот если написать анимацию через другие свойства (например, left, right, top, bottom), то анимация зависнет, если основной поток JS будет занят другой тяжелой задачей. Визуально это можно посмотреть в данной статье.

P.S. Более подробно углубиться в тему работы браузеров рекомендую через эту статью на MDN.

⚛️ Как работает React и его алгоритм Reconciliation?

Первым делом выделим основные сущности алгоритма Reconciliation:

1. Current Tree - дерево (Virutal DOM), которое отображает текущее состояние приложения.
2. Rendering Environment (RE) - отдельная среда, которая преобразует Virutal DOM в набор операций (задач).
3. Work-in-Progress Tree - дерево (Virutal DOM), которое отображает обновленное состояние приложения.

Давайте разбираться, как вообще эти сущности работают и взаимодействуют между собой. Рассмотрим все подробно по шагам.

1. При монтировании у нас создается Current Tree.
2. Current Tree передается в Rendering Environment. RE в свою очередь преобразует дерево в набор задач и расставляет их по приоритетам.
3. Все задачи, которые создал RE, начинают выполняться по приоритету. После выполнения задач создается браузерный DOM и пользователь видит контент веб-страницы на экране.
4. После того как пользователь провзаимодействовал с веб-страницей (нажал кнопку, открыл модальное окно и т.п.), создается Work-in-Progress Tree, которое содержит обновленный Virtual DOM.
5. Происходит операция сравнения двух деревьев Current Tree и Work-in-Progress Tree. Все различия межу деревьями передаются в RE. Различия - это измененные, добавленные или удаленные узлы из Virtual DOM.
6. RE на основе различий двух деревьев создает задачи, которые опять же расставляет по приоритетам. Таким образом, React не обновляет полностью все дерево, а только те узлы, которые изменились.
7. Все заканчивается тем, что Work-in-Progress Tree становится Current Tree.

И дальше React снова ждет, когда появятся новые обновления в интерфейсе, чтобы проделать заново шаги 4-7. А интерфейс в React обновляется, когда изменяется state либо props компоненты.

Это базовое описание работы алгоритма Reconciliation. Конечно, можно углубиться в детали реализации виртуального DOM, но чаще всего данного объяснения на собеседовании хватает. В следующих постах будем более подробно разбирать Reconciliation и сам React.

P.S. У меня было одно собеседование, где интервьюер задал мне этот самый вопрос "Как работает React?". Я ему рассказал все примерно так же, как описано в этом посте. Он сказал, что вопросов задавать больше не будет, так как видит, что я хорошо шарю за React. В итоге собеседование длилось минут 15 🙃

⚛️ Допущения алгоритма Reconciliation в React

В продолжение к посту как работает React и его алгоритм Reconciliation хочется рассказать про допущения этого алгоритма. Допущения алгоритма Reconciliation - это те условия, которые нам как разработчикам необходимо выполнять, чтобы React рендерил компоненты оптимизировано и без пролагивания UI.

Для начала давайте поймем, какая сложность алгоритма сравнения деревьев (Virtual DOM) у React? Алгоритм React это делает за O(N), т.е. сложность линейная. В то время как браузерное API сравнивает DOM-деревья за O(N^3).

И чтобы React продолжал выполнять свою работу за O(N), необходимо знать следующее.

1️⃣ изменился тип узла ==> происходит создание нового дерева.

Допустим, у нас было такое дерево,

<main>
  <h1>Users</h1>
  <UsersList />
</main>

а после обновления стало таким.

<section>
  <h1>Users</h1>
  <UsersList />
</section>

Как мы видим, тег main изменился на section. При этом контент внутри этого элемента остался без изменений. Но React удалит и заново создаст все узлы, которые начинаются с main и идут глубже, так как у узла изменился type. Был type: 'main', а стал type: 'section'.

2️⃣ изменился key узла ==> происходит создание нового дерева.

key - полезный инструмент в React. Он позволяет оставлять нетронутыми конкретные узлы между рендерами. Вы точно использовали key при работе со списками.

<div>
  {users.map((user) => (
    <UserItem key={user.id} id={user.id} name={user.name} />
  ))}
</div>

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

Более наглядный пример. В коде ниже у компоненты Content произойдет размонтирование и после монтирование. Так как при изменении checked изменился key.

<div className="App">
  {checked ? <Content key="1" /> : <Content key="2" />}
</div>

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

3️⃣ изменился атрибут узла ==> обновляется только измененный атрибут, создание нового дерева не происходит

Допустим у нас есть следующий JSX.

<div data-testid={isVisible ? 'content-visible' ? 'content-hidden'}>
  <UsersList />
</div>

Как мы видим, у div меняется только атрибут data-testid в зависимости от состояния isVisible. В таком случае создание нового дерева и размонтирование всех дочерних узлов div НЕ произойдет. Потому что изменение атрибута не вызывает создание нового дерева.

P.S. Ставь 🔥, если было полезно! Больше про advanced-темы в React можно найти в закрепленном посте.

Недавно помог Front-End разработчику пройти алгоритмическую секцию в Яндекс на Middle позицию 🔥

В своем приватном Telegram-сообществе я выкладываю видео-разборы live coding задач с реальных собеседований.

Вот человек посмотрел разбор, понял как решается одна из задач. В итоге, он без проблем решил похожую задачу на алгоритмической секции. Круто, не правда ли? 💪

Вы тоже можете получить доступ к видео-разборам и вдобавок гайд "Как получить оффер в ЯНДЕКС на 300k+ RUB на позицию Front-End разработчика?". Все это найдете в приватном сообществе 👇

@easy_jobinterivew_frontend_bot

————————————

В канале "Один день айтишника" выложили мою историю увольнения за то, что я не был онлайн в Slack 🟢

Благодаря этому на мой Telegram-канал за 2-е суток подписались больше 100 человек. Спасибо вам! 🔥

Кто еще не читал историю про мое увольнение, то вот ссылка: https://t.me/one_IT_day/443