Front-End Engineer Blog

Exceptional Talent Visa - Personal Experience Привет👋, сегодня поговорю с Надей про свой опыт получения визы таланта в ЮК. Присоединяйтесь к стриму, если интересно послушать про визу и документы. Язык стрима - английский Время: 06.00pm London Time — Hi👋, today I’m going to talk with Nadia about my experience of getting UK Exceptional Talent Visa. Come and join the stream, if you’re interested in UK Talent visa and preparing the documents for it. Stream language - English Time: 06.00pm London Time https://www.linkedin.com/video/event/urn:li:ugcPost:7007799658211074048/

[System Design Bits]: The way to HTTP 2 ☃️ Hello folks, finally, the the first part of the HTTP protocol series is arrived 🚀. In this video, we're going to cover the following: 1. What’s HTTP and how the request is made through the browser 2. Evolution of HTTP and Web, from simple syntax to fully fledged protocol 3. HTTP 1.1 Issues and prerequisites from HTTP 2.0 4. Web Performance Tricks of HTTP1.1, and why they are antipattern now I've decided to split the topic into 2 videos due to the large size and material complexity. The second part of the video will be published in a few weeks (hopefully) I’d be happy if you re-share this post to your friends so more people can find it. Thank you! Happy Upcoming New Year ❄️ — Всем привет! Наконец то закончил работу над серией видео по HTTP 🚀. В ней мы разберемся: 1. Что за зверь такой HTTP, как браузер делает запрос 2. Эволюция протокола и веба, от простого синтаксиса, до полноценного протокола 3. Проблемы протокола и пререквезиты для второй версии. 4. Какие подходы используются для улучшения производительности веб-приложений, и почему большинство из них теперь антипаттерн (но многие до сих пор используют) Я решил разделить топик на 2 видео из-за большого размера. Вторая часть выйдет через несколько недель (надеюсь) Буду очень благодарен за фидбек и если пошарите пост с друзьями, в своих каналах. Это мотивирует меня выпускать больше контента. Happy Upcoming New Year ❄️ https://youtu.be/gxF9fLo5XQw

Path to Staff Software Engineer | Part 2 🚀 (English version can be found above) Привет! Это вторая часть серии постов про работу над промо до Стаффа. Сегодня расскажу, что делаю я, для того, чтобы получить промо 👨‍💻 Немного контекста Про архитипы, мы поговорили в прошлом посте. Будем исходить из того, что мы идем по Архитипу ТЛ - Tech Lead. ☑️ Какие преквезиты нужны, чтобы запромоутиться до E6 в Мете: - Быть тех-лидом для команды 6+ человек - Успешно запустить, как минимум, один большой проект - Драйвить архитектурные решения - бизнес дает проблему X. Твоя задача - кларифицировать требования, работая с ПМами и дизайном. Из проблемы Х, создать архитектурное решение в виде спецификации, части которой можно распределить между инжинерами. Желательно, чтобы каждый инжинер мог раскрыть технически в глубину, каждую часть спеки. - Деливерить через других. Научиться скейлить себя - твои возможности ограничены, Ты не можешь кодить и делать архитектуру и планировать дальнейший скоуп на команду. Умение делигировать задачи критически важно. Делегировать нужно так, чтобы давать людям задачи, на которых они будут расти. - Влияние на свою и внешние команды, стафы, как правило имеют влияние на соседние команды, с которыми работают. Это выражается в контрибуции в спеку других команд, влияние на роадмаппинг скоупа внешних спек - Контрибуции в org-wide инициативы. Например имлементации поддержки нового фреймворка внутри всех команд в орге или запуск менторинг инициатив внутри орга - Работать в high-prio area и оказаться в нужное время и в нужном месте ( Это очень важно ). Очень сложно работать над промо в команде, где ТЛ распределены, скоуп потянет и нужны только лишь исполнители. Очень важно попасть в проект на его начальном этапе развития. - Менеджер, должен хотеть тебя запромоутить. К сожалению, это так. Если менеджер не прикладывает здесь усилий, очень высока вероятность, что промо ты не получишь Как вы понимаете, все эти вещи нельзя сделать сразу, на это требуется как минимум 6-9 месяцев. Главная ошибка - пытаться делать какие то вещи ради fake-impact. Например хайрить людей в команду, на неэффективный проект и запускать инициативы, которые не принесут организации пользу. Как я уже говорил, я оказался в нужном месте и в правильное время. Я принял решение менять команду, когда понял: - Моя команда не будет расти и уровень задач будет низкий - Мой орг - не приоритетное направление компании В итоге, я выбрал команду - которую приоритизировала компания и я пришел в нее на начальном этапе развития, когда в ней было всего 7 инжинеров. Сейчас нас 53. Мне очень нравятся люди внутри этой команды. Таких продуктивных и талантливых ребят я не видел давно. Многие - сильнее меня в техническом плане и это хорошо.

Path to Staff Software Engineer | Part 2 🚀 (Версия на русском внизу после поста) Link to part one: https://t.me/frontend_engineer_blog/168 Hi, this is the second part of a series of posts about working on the staff engineer promo. Today I'm going to tell you what I do to get that promo 👨‍💻 Context We talked about software engineer archetypes in the last post. So, let's assume we're going with TL Architype - Tech Lead. ☑️ What are the prerequasites for E6 promo at Meta: - Be the Tech Lead for a team of 6+ people - Successfully run at least one large project - Drive architectural solutions - business gives problem X - your job is to clarify requirements, work with PMs and design. From problem X, create an architectural solution in the form of a specification, parts of which can be distributed among the engineers. Preferably, each engineer should dive technically in-depth and contribute to the assigned spec part - Deliver through others. Learn to scale yourself - your capabilities are limited, and you can't code, do the architecture, and plan further scoping on the team. The ability to delegate tasks is critical. Delegate in a way that gives people tasks that they will grow on. - Influencing your own and external teams, staff engineers tend to impact sister teams they work with. This translates into contributing to other teams' specs and roadmaps - Contributions to org-wide initiatives. For example, implementing support for a new framework within all teams in the org or running mentoring initiatives across multiple teams - Work in the high-priority area and be in the right place at the right time ( This is very important ). It is challenging to work on promo in a team where TLs are assigned already, the scope is defined, and only execution is needed. So it's essential to get into a project at its early stages. - The manager has to want to promote you. Unfortunately, it's a cruel reality. If the manager doesn't put in the effort here, there's a very high probability that you'll never get the promo As you understand, you can only do some of these at a time; it takes at least 6-9 months to have a good contribution. The main mistake is trying to do something for fake impact. For example, hiring people on a team, on an ineffective project, and launching initiatives that won't benefit the organization. As I said, I was in the right place at the right time. I made the decision to change my team when I realized the following: - My team would not grow, and my task level would be low - My org was not a company priority In the end, I chose a team - which was prioritized by the company, and I joined at the beginning of its development when there were only 7 engineers. Now, there are 53 of us. I really like the people within this team. I haven't seen such productive and talented folks in a long time. So many of them are stronger than me technically, and that's a good thing.

React.js - The documentary 📽️ Привет! Команда Реакта запускает документальный сериал про разработку реакта. Рекомендую посмотреть, по мере выхода, чтобы понять, как react из маленькой библиотечки вырос в целую парадигму диктующую стандарт индустрии. — Hey👋 React team launches a documentary video series about developing React.js. I highly recommend watching it as soon as it launches. It will give you a great insight of how a small library became an industry standard https://youtu.be/gmp0istg5xo

Cons: 1. It's the rarest type. Very few people can generate so much code. You need to have a special kind of mind and the ability to work in such a way 2. This type of people needs clearly described requirements for the system - otherwise, it's hard to use its full potential. In our team, we have Tech-Leads, Coding-Machine and Product-Gens. For myself, I choose to develop myself a Tech Lead. I'll tell you more details about myself in the next upcoming post. Thanks for reading 🙏

Tech Lead (TL) - aka architect, from a complex and incomprehensible problem, makes a fully clarified project, writes an initial architectural doc, breaks everything into workstreams, assigns a lead for each workstream, implements the most complex and obscure parts - kicks off the project. Once the project starts running like clockwork, work with PM and PG (product manager and product generalist) to figure out and design the future scope for the team. Pros: 1. You do a lot of architectural work and think a lot within a large system 2. You continue to be an engineer and implement the most complex parts 3. Direct influence on the product through constant communication with PMs and PGs 4. Increase your value in the marketplace as a staff engineer Cons: 1. 50-60% of your time will be spent writing architecture specs and communicating 2. You have to consider people's interests, give them challenging enough tasks and plan a lot 3. You'll only finish part of the project - your role: Kickstarter, configure the project and start delegating as much as possible. Ideally, the team should function even without you. 4. Stressful enough since you're combining pm, architect and programmer roles — Product Gen (PG) - aka programmer who became a TPM. You work with TLs, connect sub-teams, and set up parallel workstreams. You must understand perfectly the architectural specs of all the sub-teams you work with and communicate closely with the leaderboard and the business. Often, PGs establish team communication processes, track the progress of all workstreams, analyze potential risks and proactively address them. Pros: 1. Close work with the business, management and directors. If you're aiming for a director or management role, it's a great role. 2. Less stressful than the TL role since there's no expectation that you'll be coding, even though you're still considered an engineer Cons (at least for me): 1. You stop programming and gradually lose your skills and your market value as a programmer 2. You spend 70-90% of your time at meetings. 3. You understand a project's high-level architecture very well but cannot go deep into it because of the lack of time. — Fixer - the "son of your mother's friend", throw him into a burning house, the next day, the house is renovated, and everything is clean. This type of programmer - solves the most challenging problems to put down the fire within the project. A kind of band-aid put it on, and everything gets better. Quickly analyze the project's issues, offer a solution, and implement it. Whether it's the technical one (Tech Fixer) - system performance issue, metrics are sinking, nothing works, or the product part (Prod Fixer) - development is stalled, there is no proper coordination, and nobody understands anything. Pros: 1. You continue to grow as an engineer and develop analytical skills. You can solve any problem most efficiently and budget-wise for the business, a valuable skill set on the market. 2. Focused work, you don't have to sit half the time at the meetings - you spend half the time analyzing the problem and another half solving it 3. You are not a people manager and are not expected to be one. 4. You are very valuable for business Cons (subjective): 1. Fixers often change projects and jump from problem to problem. Usually, the fixer's job is to understand the problem, fix it, and move on to the next one. — Coding Machine - Need to build something quickly and make it work but sacrifice a little on quality? Throw a couple of coding machines into the project, and all project statuses turn green. In short, this archetype is when all the "character skill points" are thrown into coding. Such people can generate 10-20k lines of code in a few days, making even some automated code generators useless. But on the other hand, they figure out what needs to be done in the project quickly and can code everything blazingly fast. Pros: 1. 95% of the work is pure coding, no bullshit job meetings and figuring out requirements 2. You continue to be a software engineer

The path towards staff engineer | Part 1 (Russian version can be found above) Hi, I'm going to start sharing my work for the E6 promo at Meta. I recently decided to pursue this goal and set a deadline for myself - Summer 2023. Why am I writing about it now? At a touchpoint ( the equivalent of an interim performance review), the manager informed me that he would be putting my package out for a promotional review in January. Although, I won't get a promo in January. Inside WhatsApp, you must show an E6 performance review for 9 months before you get promoted. The early promo review aims to get feedback from a broad group inside WhatsApp. The feedback you obtain at this review will help close the gaps (if there are any) and will serve as additional arguments in the next promotional cycle. In this series of posts, I'll talk about what I'm doing now for the promo, a little bit about my current responsibilities, and how the work on the promo at Meta in general works. So, Is it worth it in terms of money? First, let's look at economic feasibility. Here are the figures for the UK & USA. E6 base salary: 140-160K GBP | 230-260K USD Bonus: 20% 28-32K GBP | 46-52K USD Annual Refresher: 234K USD | 275K USD over 4 years So, a tenured E6 with 4 years of experience in the company gets the following compensation: TC UK: 160 + 32 + 234 / 1.2 ~= 387K GBP ~ 464K USD TC US: 260 + 52 + 275 = 587K USD After the promo, the compensation will level up gradually. But in general, economically - promo E6 allows you to grow in compensation almost twice. Is it worth it from a career standpoint? This is where it will all depend on how you want to see yourself further in the industry and how far away from "programming" you want to be. Beginning with E6, everyone chooses a particular archetype - a base model you will follow. There are 4 main archetypes (the second post below):

Tech Lead (TL) - aka архитектор, из сложной и непонятной проблемы, делает проект, пишет начальный архитектурный док, разбивает все на воркстримы, назначает лида на каждый ворк-стрим, имлементит самые сложные и непонятные части - делает kick-off проекта. Как только проект начинает работать как часики, рабоает с ПМ (продукт менеджер и продуктом генералистом), выясняя и проектируя дальнейший скоуп. Плюсы: 1. Делаешь много архитектуры и много думаешь в рамках большой системы 2. Остаешься программистом, пишешь самые сложные части 3. Прямое влияние на продукт через постоянно общение с ПМ и ПГ 4. Увеличиваешь свою ценность на рынке, как стафф программист Минусы: 1. 50-60% времени будет уходить на написание архитектуры и общение 2. Нужно учитывать интересы людей, давать вменяемые по сложности задачи и много планировать 3. Ты никогда не закончишь проект целиком - твоя роль: кик-стартер, запустить проект и начинать максимально делегировать. 4. Достаточно стрессово, так как ты совмещаешь в себе мини-пма, архитектора и программиста. — Product Gen (PG) - aka программист, который стал ТПом. Твоя задача - работать с тех-лидами, соединять под-команды и налаживать паралельную работу. Нужно отлично понимать архитектурные спеки всех под-команд с которыми работаешь и плотно общаться с лидершипом и бизнесом. Часто ПГ налаживают процессы коммуникации в команде, трекают прогресс всех воркстримов и анализируют потенциальные риски, превентивно устраняя их. Плюсы: 1. Плотная работа с бизнесом, менеджементом и директорами. Если целишься на директора - отличная роль. 2. Менее стрессово, чем роль ТЛ, так как нет ожиданий, что ты будешь кодить, хотя все еще считаешься инжинером Минусы (по-крайней мере для меня): 1. Перестаешь программировать, теряешь навыки и свою рыночную стоимость, как программист 2. 70-90% времени сидишь на митингах 3. Отлично понимаешь высокоуровневую архитектуру проекта, но физически не можешь разбираться вглубь, из-за отстувия времени — Fixer - тот самый, сын маминой подруги, кинь его в горящий дом, на следующий день, в доме сделан евроремонт и все чисто. Данный тип программиста - решает самые сложные проблемы внутри проекта. Этакий пластырь, налепил и стало хорошо. Быстро индефицирует проблему проекта, предлагает решение и имлементирует его. Будь то техническая часть (Tech Fixer) - проблема с перфомансом, метрики тонут, ничего не работает, а также продуктовая (Prod Fixer) - разработка заглохла, нет нужной координации и всем ничего непонятно. Плюсы: 1. Ты остаешьешься программистом, развиваешь навыки анализа и можешь решить любую проблему наиболее эффективным и дешевым путем для бизнеса, очень ценен на рынке. 2. Фокусная работа, не нужно сидеть половину времени на митингах - половину времени тратишь на анализ проблемы и еще половину на ее решение 3. Ты не пипл менеджер и от тебя нет таких ожиданий. 4. Ты очень ценен Минусы (субъективно): 1. Фиксеры часто меняют проекты и прыгают от проблемы к проблеме. Обычно задача фиксера - понять проблему, пофиксить и идти дальше. — Coding Machine - горят проект и сроки? Нужно имлементировать быстро и чтобы работало, но немного жертвуя качеством? Закидываешь в проект парочку кодинг машин и все статусы проекта становятся зелеными. Короче говорят, данный архитип - это когда все очки навыков вбросил в кодинг. Такие люди могут генерировать 10-20к строк года за несколько дней, обгоняя некоторые автоматические генераторы. Быстро разбираются в проекте, понимают, что нужно делать и без лишних слов имлементируют. Плюсы: 1. 95% работы - чистый кодинг, никакого булшита в виде митингов и выяснения требований 2. Остаешься программистом и проложаешь развивать свои навыки Минусы: 1. Самый редкий архитип, очень мало людей способны генерировать такой объем работы, нужен особый склад ума и умение работать в полном фокусе 2. Таким людям, нужны четко описанные требования к системе - иначе ничего не выйдет. У нас в команде, есть Тех-лиды, Coding-Machine и Продукт-Гены. Я для себя выбрал путь Тех-Лида. В следующем посте расскажу про себя. Спасибо, что читаешь 🙏

Привет! Видео о HTTP2, к сожалению, сильно задержалось, произошло много событий в жизни за последний месяц, поэтому пришлось отложить, транскрипт написан, осталось записать видео, планирую это сделать на следующей неделе. Чтобы скрасить твое ожидание, в течении недели выложу посты на следующие темы 🚀 1. Рабочая поездка в 🗽 Нью-Йорк 🗽 , впечатление и сравнение с Лондоном. 2. Покупка квартиры в Лондоне, сколько стоит, разумное ли решение? (Недавно въехал в свою 2БД квартиру) 3. Состояние рынка труда для разработчиков в Англии и как инфляция сильно поменяло компенсацию FAANG в сравнении с рынком. Увольнения в Мете. 4. Работа над промо до Е6 (Staff Software Engineer), стоит ли оно того? Расскажу, как у меня дела на данный момент с этим. Есть хорошие новости. Также, недавно мой коллега по цеху Ян (https://t.me/front_end_interview) выложил статью про его опыт интервью и релокацию в США, и получения кучи офферов. Думаю тебе будет интересно ознакомиться. Прикладываю ссылки на его статьи на двух языках: English: https://javascript.plainenglish.io/how-i-relocated-to-the-usa-looked-for-opportunities-offers-i-received-from-maang-and-more-30e2cea7b99e Russian: https://habr.com/ru/post/690066/ 🍁 Всем теплой осени 🍁 —— Hi folks! Unfortunately, I had to delay a video about HTTP 2 due to many life events in the last month. The video transcript is ready, and now I need to record myself. I’m planning to do that next week. To brighten up your waiting, I'll be posting posts on the following topics during the week: 1. Work trip to 🗽 New York 🗽 , impression and comparison with London 2. Buying an apartment in London, how much does it cost? Is it a smart decision? (I recently moved into my 2BD apartment) 3. The state of the job market for developers in England and how inflation has dramatically changed the compensation within FAANG. Layoffs in the Meta. 4. Working on promo to E6 (Staff Software Engineer); is it worth it? I'll tell you how I'm doing at the moment with this. There's some good news. Also, recently Yan (https://t.me/front_end_interview) posted an article about his experience interviewing and relocating to the U.S. and getting a bunch of offers. I think you may be interested to read it. Here are links to his articles in two languages: English: https://javascript.plainenglish.io/how-i-relocated-to-the-usa-looked-for-opportunities-offers-i-received-from-maang-and-more-30e2cea7b99e Russian: https://habr.com/ru/post/690066/ 🍁 Warm autumn to everyone 🍁

HTTP2+ Above and Beyond: Web Performance, caching and many more 🧑‍🎓 [September 26] — Hey folks, I've had a vacation and took a break from posting. But now, I’m feeling recharged 👨‍💻  On September 26, I’m going to publish a serie on System Design bits. We’re going to do a truly deep dive into HTTP2 Protocol and cover the following topics: 1. What’s HTTP2 and how the request is made over HTTPS 2. How HTTP2 enables effective content serving 3. Web Performance Tricks, HTTP1.1 vs HTTP2 a. Why Webpack Single file bundle is antipattern b. What’s a domain clustering and why you don’t need it anymore 4. Making your Web App HTTP2 ready 5. Request caching and compression. 6. and a many more 🙂 This is going to be the most complex video so far on the channel in terms of material and quality. I’d be happy if you re-share this post to your friends so more people can find it✌️ See you 😉 —— Привет! Я был в отпуске, поэтому взял перерыв с постами. Перезарядился и готов снова релизить контент! 26 Сентября, на канале выйдет видео по протолку HTTP2. Сделаем подробный его разбор с точки зрения веб-инжинера. Разберем следующие темы: 1. Что за зверь такой, HTTP2 и как браузер делает запрос через HTTPS 2. Что нам дает HTTP2 с точки зрения отдачи контента 3. Веб-перф, как оптимизировали веб-сайт под HTTP1.1 и в чем отличие от HTTP2 a. Почему бандлить весь джс в один файл плохо b. Что такое кластеризация домена и почему она теперь не нужна 4. Как сделать вашу веб апликуху готовой к HTTP2 5. Кеширование запросов и их сжатие 6. и многое другое 🙂 Это будет одно из самых сложных видео на канале с точки зрения подготовки материала и продакшена. Я буду очень рад, если ты пошаришь этот пост друзьям, чтобы больше людей могли увидеть будущее видео! Спасибо! Скоро увидимся! 😉

⚠️Vote for the next topic! ⚠️ Hey, let's choose the next video topic. I'm planning to record 3 more SD videos, however, I think it's good to some other topics that might be insteresting for community. We have a democracy in our channel, so YOU get to decide the next topic👨‍💻 ---- Привет, выбираем тему следующего ролика! У меня пока в планах записать еще 3 видео по СД, но думаю разбавить контент, чем то еще. В нашем канале демократия, так что тему следующего ролика выбираешь Ты👨‍💻 1. Solving one of the most diffucult and common coding problem 2. Life in the UK, salary, expenses, visa situation, path to citizenship and many more 3. Next serie of Front-End System Design 4. System Design bits: HTTP2 protocol, all type of client side caching (from browser to client-side libraries) Your vote is important! 🗳

Недавно наткнулся на неплохую серию статей по фронтенд архитектуре от Khalil Stemmler. Серия статей покрывает архитектурные паттерны с учетом современного стека 👨‍💻 —— Recently, I stumbled across a pretty comprehensive article series about frontend-architecture from Khalil Stemmler. This series covers UI architectural patterns with a modern tech stack in mind. Useful to read 👨‍💻 https://khalilstemmler.com/articles/client-side-architecture/architecture/