Maxim WebDev
رفتن به کانال در Telegram
Здесь узнаешь, как проходить собеседования Front-End разрабу на СНГ рынке - Я Senior Front-End, делюсь с тобой личным опытом в IT - Рассказываю про лайфхаки в прохождении собесов - Показываю примеры задач с моих job-интервью My Contact: t.me/max_webdev
نمایش بیشتر449
مشترکین
اطلاعاتی وجود ندارد24 ساعت
اطلاعاتی وجود ندارد7 روز
+15330 روز
در حال بارگیری داده...
کانالهای مشابه
هیچ دادهای
مشکلی وجود دارد؟ لطفاً صفحه را تازه کنید یا با مدیر پشتیبانی ما تماس بگیرید.
ابر برچسبها
هیچ دادهای
مشکلی وجود دارد؟ لطفاً صفحه را تازه کنید یا با مدیر پشتیبانی ما تماس بگیرید.
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
دسامبر '24
دسامبر '24
+27
در 1 کانالها
نوامبر '24
+19
در 0 کانالها
Get PRO
اکتبر '24
+30
در 0 کانالها
Get PRO
سپتامبر '24
+22
در 0 کانالها
Get PRO
اوت '24
+442
در 1 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 21 دسامبر | +1 | |||
| 20 دسامبر | 0 | |||
| 19 دسامبر | +2 | |||
| 18 دسامبر | +1 | |||
| 17 دسامبر | +1 | |||
| 16 دسامبر | 0 | |||
| 15 دسامبر | 0 | |||
| 14 دسامبر | +1 | |||
| 13 دسامبر | +1 | |||
| 12 دسامبر | +1 | |||
| 11 دسامبر | 0 | |||
| 10 دسامبر | 0 | |||
| 09 دسامبر | 0 | |||
| 08 دسامبر | 0 | |||
| 07 دسامبر | 0 | |||
| 06 دسامبر | +2 | |||
| 05 دسامبر | +3 | |||
| 04 دسامبر | +6 | |||
| 03 دسامبر | +8 | |||
| 02 دسامبر | 0 | |||
| 01 دسامبر | 0 |
پستهای کانال
| 2 |  ————————————
В канале "Один день айтишника" выложили мою историю увольнения за то, что я не был онлайн в Slack 🟢
Благодаря этому на мой Telegram-канал за 2-е суток подписались больше 100 человек. Спасибо вам! 🔥
Кто еще не читал историю про мое увольнение, то вот ссылка: https://t.me/one_IT_day/443 | 615 |
| 3 |  Недавно помог Front-End разработчику пройти алгоритмическую секцию в Яндекс на Middle позицию 🔥
В своем приватном Telegram-сообществе я выкладываю видео-разборы live coding задач с реальных собеседований.
Вот человек посмотрел разбор, понял как решается одна из задач. В итоге, он без проблем решил похожую задачу на алгоритмической секции. Круто, не правда ли? 💪
Вы тоже можете получить доступ к видео-разборам и вдобавок гайд "Как получить оффер в ЯНДЕКС на 300k+ RUB на позицию Front-End разработчика?". Все это найдете в приватном сообществе 👇
@easy_jobinterivew_frontend_bot | 521 |
| 4 | ⚛️ Допущения алгоритма 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 можно найти в закрепленном посте. | 596 |
| 5 | ⚛️ Как работает 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 🙃 | 746 |
| 6 | Расскажи, как работают браузеры?
Этот вопрос может попасться на собеседовании 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. | 685 |
| 7 |  Совсем забыл рассказать, вышло новое видео на YouTube! 🔥
еще 3 недели назад))
В видео разобрал решение 3-х алгоритмических задач, которые часто попадаются на собеседованиях в бигтех. Задачи идут от простых к более сложным.
Поэтому кто еще не смотрел, переходите по ссылке! https://youtu.be/dYeOfz_ttUA?si=KFuP5zkr_NRu5Gu- | 611 |
| 8 |  +3Был в отпуске 2 недели. Погулял по Питеру несколько дней и после съездил к родственникам, которые живут за 1500 км от Минска.
Главное правило любого отдыха - не брать с собой ноутбук, с чем я успешно справился.
Сейчас потиху нужно возвращаться в рабочие задачи. Сегодня смог заставить себя сесть за работу только к 13:00 🙃 | 449 |
| 9 | Какие существуют форматы собеседований и что вам нужно знать о них для получения оффера?
За всю свою карьеру я прошел десятки собеседований и из них могу выделить два формата интервью.
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 вы поймете плюсы и минусы формата интервью и будете знать, как готовиться к собеседованию. | 709 |
| 10 |  Вышло новое видео на YouTube!
В нем подробно рассказал, как решать задачи на Event Loop на собеседованиях 🔥. В видео сначала приводится кратко вся теоретическая база Event Loop, а после дается разбор решения 2-х задач: легкой и сложной.
Кто еще не смотрел, переходите по ссылке! https://youtu.be/iL4srHpf6gE?si=J_VgUvLgCVb4WyuP | 592 |
| 11 |  Буквально недавно в приватном сообществе выложил полностью все части гайда "Как получить оффер в ЯНДЕКС на 300k+ RUB на позицию Front-End?". 🔥
Делюсь с вами содержанием гайда. В нем подробно описаны все этапы интервью в Яндекс: какие задачи дают, какие каверзные вопросы задают, все дополнено полезными ссылками и материалами.
Присоединиться к сообществу и получить гайд можно через ТГ бота @easy_jobinterivew_frontend_bot 😉 | 538 |
| 12 |  +2Я купил себе новый Macbook на Wildberries 🍓
Я около 3 лет разрабатывал Front-End на Macbook Air M1 (13 дюймов, 8 ГБ RAM и 512 ГБ SSD). Для разработки большинства проектов ноутбук подходил идеально. Процессор M1 довольно мощный, справляется со многими задачами во Front-End.
Но вот 8 ГБ оперативной памяти создавали дискомфорт. С 8 ГБ довольно трудно работать, если запустить два проекта в WebStorm, если запустить один проект и слушать видео на фоне и др. А еще плюсом можно открыть несколько вкладок дизайнов Figma, вот тут и начинается "веселье"))
Что ж, буквально неделю назад я купил себе Macbook Air M3 на 16 ГБ RAM, 512 ГБ SSD и диагональю экрана 13 дюймов. Все мои боли с ограниченной оперативной памятью ушли. Я так рад, что ноутбук больше не лагает после одновременного запуска проекта и видео на YouTube! 🔥
Кроме этого, я заказал ноут на WB. Довольно странный выбор площадки для покупки, с одной стороны. Но с другой стороны, я работаю на Wildberries и компания дает скидку на ноутбуки в 40%. И главное условие скидки - заказать технику через сайт WB. И еще одно ограничение, технику не могут доставить в ПВЗ (пункт выдачи) Беларуси. Поэтому пришлось ехать в ближайший город РФ Смоленск и забирать ноутбук там 🙃
В общем и целом, берите для Front-End разработки как минимум 16 ГБ оперативной памяти, чтобы потом не страдать, как я) | 573 |
| 13 | Как эффективно готовиться к техническим вопросам перед собеседованием?
Есть собеседования, где нужно не только решать задачи, но и отвечать на технические вопросы.
И к теории тоже стоит готовиться. Потому что интервьюеры часто задают вопросы на глубокое понимание JavaScript и React. О таких вещах мы не думаем на работе во время решения повседневных задач. Поэтому знания постепенно забываются.
Но самое главное, что эти знания можно эффективно освежить в своей голове. Как это делается? Простые заметки!
Я заметки веду в Google Keep, где сделал отдельную вкладку с различными сложными вопросами с собеседований. Там и про React Fiber, Reconciliation, Event Loop, про то как работает парсинг веб-страниц в браузере, различия SPA и SSR, минусы React как библиотеки и многое другое. Мне часто задают подобные теоретические вопросы на собеседованиях. Поэтому я заранее подготовил на них краткие ответы в виде заметок.
Итого, как проходит моя подготовка к теории? Открываю Google Keep, пробегаюсь за 20 минут по всем сложным темам, после иду уверенно проходить собеседование 🔥.
Я настоятельно рекомендую вам использовать такой же подход. Если вам задали сложный теоретический вопрос на собеседовании и вы на него не ответили, то после запишите этот вопрос в заметки, найдите на него ответ в Гугле, кратко распишите ключевые моменты. С таким подходом у вас накопится несколько записей. И потом для подготовки к следующему собеседованию вы просто откроете приложение для заметок и пробежитесь за 10-20 минут по всем сложным вопросам.
---------
А как вы готовитесь к теоретическим вопросам перед собеседованием? Сколько у вас времени занимает подготовка? 🤔
P.S. Кстати, многие свои заметки со сложными вопросами я выкладываю здесь. Почитать их можно в закрепленном посте (смотрите "Теория с собесов"). | 627 |
| 14 |  Вышло новое видео на YouTube, где разбираем решение 3-х задач с реального собеседования в Яндекс 🔥
Кто еще не смотрел, переходите по ссылке https://youtu.be/ilZiDZ_rXXo?si=pBq6XrY0jrdPmr7g | 540 |
| 15 | Почему разработчики часто проваливают собеседование в бигтех?
Мне много кто рассказывал, что собеседования в бигтех очень сложные и что большинство разработчиков их проваливают. Да что уж тут говорить, я сам 2 раза не смог пройти собеседование, прежде чем получил заветный оффер. Поэтому выделил для вас топ ошибок, из-за которых разработчики проваливают собеседование в бигтех.
1️⃣ Решают live coding задачи, которые навряд ли им попадутся на собеседовании. Обычно на каждом этапе есть топ тем, на которые дают решать задачи. И если знать эти темы, то во время подготовки можно сделать на них основной упор.
2️⃣ Выделяют мало времени на подготовку к этапам собеседования. Оптимально, это взять 1-2 недели и каждый день в спокойном темпе решать задачи. Тогда и будет результат.
3️⃣ Недооценивают финальную секцию. Разработчики могут успешно пройти все стадии с кодом, но завалить этап на проверку софт скилов. А чтобы его пройти, необходимо знать, какие вопросы задают и заранее подготовить на них ответы.
Я сам понял все трудности, когда проходил собеседование в Яндекс. Я прошел все этапы интервью только с 3-й попытки и получил в итоге оффер на 300k+ RUB! 🔥
Представьте, как здорово, если у вас была бы подробная информация по каждому этапу собеседования в бигтех с примерами задач, ссылками на материалы для подготовки, с вопросами по софт скилам, которые задают на финальной секции.
Я прекрасно понимаю ваши трудности на пути к получению оффера, поэтому подготовил для вас гайд "Как получить оффер в ЯНДЕКС на 300k+ RUB на позицию Front-End?". В нем подробно описаны все этапы интервью в Яндекс: какие задачи дают, какие каверзные вопросы задают, все дополнено полезными ссылками на материалы и многим другим.
Гайд выложил в приватном Telegram канале, где хочу вам помочь получить оффер в Яндекс на хорошую ЗП, лично отвечать на ваши вопросы и давать фидбек. Поэтому залетайте по ссылке и получайте доступ в канал! | 647 |
| 16 | Формат найма в бигтех. Какие есть стадии собеседования в бигтех?
Неоднократно с вами говорили в этом канале на тему собеседований на позицию Front-End разработчика, в особенности про бигтехи. Обычно у бигтехов в СНГ (Яндекс, Тинькофф и другие) есть 3-4 стадии интервью, которые проводятся в разные дни.
1️⃣ Секция по JS
Интервьюер дает в среднем от 3 до 6 задач по JavaScript. И вам нужно будет их решать в формате live-coding.
2️⃣ Секция по алгоритмам
Интервьюер дает в среднем от 2 до 5 задач на алгоритмы, которые нужно решать в формате live-coding.
3️⃣ Секция по архитектуре
На данном этапе обсуждаются разные архитектурные подходы в разработке приложений. А это значит, у вас должен быть опыт построения проектов с нуля.
Данная секция проводится только для кандидатов уровня Senior. Если вы планируете идти на позицию Мидла, то вам такую секцию не дадут и сразу отправят на финальную.
4️⃣ Финальная секция
Здесь проверяют ваши софт-скиллы. И не поверите, эту секцию можно провалить 🙃
----------
Не знаю как вам, но 4 стадии это довольно много. Во-первых, это отнимает время. Во-вторых, самое страшное: можно пройти 1-3 стадии успешно, но провалить последнюю или предпоследнюю. 😵 И тогда снова попробовать свои силы вы сможете только через полгода.
У меня лично такой опыт был, я проваливал 2-ю стадию на алгоритмы. А вы какой этап провалили на собеседовании в бигтех? Либо все стадии с первого раза прошли?) | 562 |
| 17 | Почему разработчики так хотят работать в бигтехах? Плюсы и минусы работы в бигтехе
Проясним сразу, собеседование в бигтех (Яндекс, Тинькофф и т.п.) состоит из большого количества live-coding задач на JavaScript и алгоритмы. Также само собеседование разбито на 3-4 этапа, которые проводятся в разные дни.
Понятное дело, что многие отваливаются на первых двух этапах. Пройти с первого раза все стадии довольно тяжело. При том после провала снова попробовать свои силы можно только через 6 месяцев.
Но это все равно не останавливает разработчиков, они снова и снова пробуют пройти успешно собеседование в бигтех. Наверное, на это есть какие-то причины? Давайте разберем плюсы и минусы работы в бигтех и поймем, почему так много программистов стремятся работать там.
👍 Плюсы:
- Возможность работать в крупной компании над большими проектами с миллионами пользователей. Многих сильно мотивирует тот факт, что ты внес вклад в разработку крупного проекта и с твоими модалкакми, кнопками, инпутами взаимодействует много людей.
- В бигтехах приличное количество сильных разработчиков, у которых можно многому научиться и поднять свои хард скилы на высокий уровень.
- Стабильная хорошая зарплата, которая сопровождается премией в размере ежемесячного оклада 1 раз в год (а то и 2 раза в год).
- Крутые офисы, большое количество оффлайн мероприятий, всякие плюшки в плане страховки и т.п. Кажется мелочи, но многих это привлекает.
👎 Минусы:
- Бигтехи могут "обижать" в плане зарплаты. Они платят строго по рынку, что может не удовлетворить ваши зарплатные ожидания, если вы хотите получать выше среднего.
- Чаще всего вы "винтик" в системе, если будете работатать над большим продуктом. Обычно, у проектов, которые на рынке существуют давно, довольно большая кодовая база и медленные процессы. Большинство задач будут в формате "покрасить кнопку" (утрирую конечно, но тем не менее). Это касается не каждого проекта, есть и молодые продукты, в которых со скоростью доставки фич и со сложностью задач все намного лучше.
- Обычно в бигтехах много самописных технологий и систем, с которыми нужно будет научиться работать, и этот опыт больше нигде не пригодится.
----------
А какие вы выделите плюсы и минусы работы в бигтехе? 🤔 | 464 |
| 18 | Стоит ли перерабатывать и отдавать все свои силы проекту?
Не знаю как вы, но меня многие проекты на работе очень увлекают. Особенно, когда появляются сложные задачи, которые ты никогда не решал.
И часто бывает такое, что ты сидишь над этими сложными задачами больше 8 часов в день, пытаешься сделать все идеально, хочешь разработать крутой продукт. И конечно такой образ жизни сильно выматывает.
В моей карьере случился один момент, который кардинально изменил мое отношение к переработкам и желанию вкладывать много сил в продукт.
Я работал в финтех продукте и в команде фронтов я был единственным Сеньором. Моей основной задачей была разработка архитектуры проекта, который разрабатывался с нуля. Также большинство сложных и не тривиальных задач назначались на меня.
Я хотел сделать идеальный продукт, заложить хорошую кодовую базу, максимально оптимизировать работу приложения. Очевидно, что я вкладывал много сил в разработку и часто перерабатывал.
Но в один день мне написал мой лид в формате «го кол». На звонке он сказал, что CTO ему передал следующее: я очень дорогой для компании, зарплата не соотносится с вкладом в развитие компании, разрабатываемый нами проект сейчас не является приоритетным продуктом. В общем и целом, мне передали, что меня хотят уволить. И желательно (желательно для компании) уволиться по собственному желанию (чтобы не платить мне 3 зарплаты за сокращение, угар 🙃).
Какой вывод я сделал? Не стоит отдавать все свои силы в развитие продукта, даже если тебе этого хочется. Работодатель не семья, тебя могут уволить в любой момент, даже если ты сделал очень много для проекта.
Вместо переработок лучше уделить время себе: сходить погулять, спортом позаниматься, попить пиво в баре с друзьями, съездить на отдых. Это все гораздо приоритетнее и интереснее работы. Не правда ли? ))
—————————
А у вас были похожие ситуации, когда вы вкладывали много сил в проект, а потом вас хотели уволить? | 583 |
| 19 |  +3Проехали больше 30 км на велосипедах по Беловежской пуще. Катались около 6 часов 🚴
Усложнением было то, что катались на обычных (не горных) велосипедах, а там любая кочка сильно чувствуется одним местом )) | 542 |
| 20 | Идеальное собеседование на Senior Front-End?
Я сейчас работаю в Wildberries на позиции Senior React разработчик. В этом посте хочу рассказать про собеседование, которое мне проводили в эту компанию 3 месяца назад.
Забегая вперед, собес был просто офигенный и образцовый. Почему? Перечислю по пунктам.
1️⃣ Не было никакого лайв-кодинга с решением непонятных задач. А это значит, что не нужно перед собеседованием 1-2 недели задротить leetcode.
2️⃣ Мне задавали вопросы исключительно по тому стеку, который использует команда. И вопросы не были в формате "юзал ли ты react-query?". Интервьюеры рассказывали проблемы, которые возникают у них в разработке продуктов, и предлагали мне описать их решение и выбрать для этого необходимые технологии.
3️⃣ Была расслабленная атмосфера. Мы не раз уходили от технических вопросов к каким-то шуткам либо рассказам об интересных историях с работы.
4️⃣ Интервьюеры в первый час поняли, что я хорошо шарю за их стек и подхожу команде. После окончания интервью мне не давали никаких дополнительных секций (хотя и могли), потому что я идеально подходил вакансии. Я думаю, вы знаете другие компании, где дают 3 секции собесов и не дай бог завалить одну из них, сразу кинут отказ.
А какие у вас критерии идеального собеседования на Front-End разработчика?
—————————
Моя (не) любимая жизненная шутка.
- Ты где работаешь?
- В Wildberries
- На пункте выдачи? Хахаха | 687 |
