[Frontend System Design] - Google sheets

It’s online 🚀

Looking forward to your comments and suggestion 🙂

https://youtu.be/fmIiDLbLc_s

Поиск новой команды - Часть 2
(English translation is below)
——
Привет! Продолжение моих карьерных мыслей 🤔

Начал я поиск команды, вариант со штатами пришлось отменить, из-за визовых проблем, которые описывал вот тут, так что сначала решил стать бритишем 💂

Процесс поиска я инициировал за 2 недели до хайринг фриза, так что в какой степени я очень удачлив. В дополнении к этому решил по-собеседоваться на стороне (об этом потом). Я списывался с несколькими менеджерами, но в итоге мне написал IC(7?) (senior staff, почти уверен) и предложил вакансию, которой пока не было на внутреннем портале. Я знал этого инженера, так как проходил буткамп в его предыдущей команде и когда то давно читал его книгу, но тогда решил уйти в другую команду. Мир тесен.

Мы побеседовали о проекте и мне сразу все понравилось, а такое бывает редко 😀. Был довольно большой и главное сложный скоуп работы, стек не самый приятный 💩, но работая в фанге и используя hack и vscode, запаха говна уже давно не чувствуешь. Intellij, я скучаю. Для меня была важна именно продуктовая часть и предполагаемый уровень задач.

Так получилось, что команде нужен TL (tech-lead), который взял бы на себя жирную часть проекта и тех-лидинг команды в 7 человек (4 прямых репортов, 3 XFN). Под этот скоуп искали изначально IC6 (staff eng), но найти не смогли, поэтому решили попробовать поставить туда IC5 (меня). Я должен признать, что несмотря на свои неплохие технические скилы, опыта в лидинга команд у меня мало, эта часть всегда отставала и я ее хотел развивать. Мне представилась отличная возможность.

Что повлияло на мое решение? 🤔

Мне дали интересный и сложный 0 - 1 скоуп в приоритетном направлении для компании, от которого будет зависеть успех проекта в целом:

1. Тех-лидинг команды
2. Прямая работа с IC7 и IC6
3. Очень сильные люди в команде. Есть автор технических книг. У кого-то был бизнес в прошлом. Кто-то просто очень крутой разраб.
4. Работая в больших компаниях, где уровни скрыты, всегда тяжело найти "role-model", на которую хотелось бы равняться. Но в этой команде есть стафы и даже старший стафф, я знаю кто они и вижу как они работают. Чем не role-model?
5. Diversified people. Люди со всех уголков. Будете смеяться, но мне очень нравится работать в таких командах.

Я также получил офферы на стороне, самый сильный был примерно с 65% прибавкой к текущей компенсации. Но я решил, что опыт, который я могу получить в текущем проекте - ценнее. Поэтому, я присоединился к оргу WhatsApp. Что делаем, пока сказать не могу, так как продукт разрабатывается и все под NDA. Пожалуй, теперь буду регулярно постить апдейт по работе. Так как интересныз чалленджей вижу много и будет нелегко.

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

Интересно, есть ли на моем канале стаффы в фангах?🤔

Спасибо, что читаешь. Теплого солнца желать не буду, Лондон был парилкой последние 2 дня (+44!), так что желаю наслаждаться второй половиной лета.

Беригите себя ☀️

#career #personal_notes

Team search - Part 2
———
(текст на русском выше)
Hi! Continuation of my career thoughts 🤔

I started looking for a team, I had to drop the US team option because of visa problems I was describing here, so I decided to become a Brit first💂

I initiated the search process two weeks before the hiring freeze, so I was very fortunate to some extent. In addition, I decided to check out UK Market and interview a bit on the side (more on that later, though). I contacted a few managers, but one day, IC(7?) (senior staff eng, most likely) contacted me and offered me the position, which wasn't on the internal portal yet. I knew this engineer because I used to bootcamp in his previous team and had read his book long ago, but I decided to join another team then. The world is so tiny.

We chatted about the project, and surprisingly I liked it immediately. There was quite an enormous and, most importantly, complex scope of work, although the stack is not the most pleasant one 💩 but after working in FAANG and using Hack and VSCode, you get used to the smell shit (c) (sorry for foul language). Intellij, I miss you. But, for me, the product part and the perceived level of the challenge were important and got my attention.

It just so happened that the team needed a TL (tech-lead) to take on the meaty part of the project and lead a team of 7 people (4 direct reports, 3 XFN). They were initially looking for IC6 (staff eng) for this scope but couldn't find an engineer, so they decided to try and put IC5 (me) there. I must admit that despite my pretty good technical skills, I have little experience leading teams, this part has always lagged, and I wanted to develop it.

What influenced my decision? 🤔

I was given an exciting and challenging 0 -> 1 scope on a priority area for the company, on which the project's success as a whole would depend.

But here are also a few things that got my attention:

1. Opportunity for tech-leading the team.
2. Working directly with IC7 and IC6.
3. Strong people on the team. Quite diverse backgrounds
4. Working in large companies where the levels are hidden, it is always hard to find a "role-model" to look up to. But there are multiple IC6 on this team, I know who they are, and I see how they work.
5. Diversified people. People from all corners of the world. You'll laugh, but I enjoy working on teams like this.

I've also received offers on the side. The strongest one was about a 65% raise to my current compensation. But I decided that the experience I could get from my current project was more valuable. So I joined the WhatsApp org. Unfortunately, I can't say what we do because the product is not yet announced, and everything is under NDA. Perhaps now, I will regularly post updates about the work. I see many interesting challenges in terms of career growth and learning new skills.

Let's see what happens! I'll tell you about the offers in the following posts. Spoiler alert: Google rejected me without an interview. But I think it's because of the global hiring freeze in the industry. A recession is coming 🙂

I wonder if there are any staff engs at FAANGs on my channel? 🤔

Thanks for reading. I won't wish you sunny weather, because London has been a sweat lodge for the last two days (+44C!) 🔥. Instead, I hope you enjoy the second half of summer.

Take care of yourself ☀️

#career #personal_notes

📆 [Frontend System Design] - Google Calendar [S2, E2]

Привет! Двигаю немного релиз следующего видео по календарю, из-за личной загрузки, выпуск видео состоится в Понедельник, 1 Августа.

В следующем видео:

1. Интервальное дерево на фронтенде, зачем оно нужно в календаре? Как быстро находить конфликтующие эвенты.
2. Продумаем взаимодействие с сервером и зачем тут GraphQL и SSE.
3. Оптимизация рендеринга (нет, не виртуализация!)
4. Построим мостик между вебом и мобильными приложениями

Увидимся в следующий понедельник 🙂

——
Hi! I'm moving a bit the release date of the calendar system design video. It will be released next Monday

In the next video:

1. Interval tree on the frontend, why do you need it in the calendar? How to quickly find conflicting events in the calendar.
2. How to solve the problem of server communication, and what for we need GraphQL and SSE.
3. Rendering optimization (no, not virtualization!).
4. Building a bridge between web and mobile apps

See you next Monday 🙂

📆 [Frontend System Design] - Google Calendar [S2, E2]

As promised, the next episode of Frontend System Design. Looking forward to your comments!

https://youtu.be/leo1FZ6vu1I

Недавно наткнулся на неплохую серию статей по фронтенд архитектуре от 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/

^^^^ ⚠️Vote for the next topic! ⚠️ ^^^^
(check the poll above)

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! 🗳

Привет! Видео о 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 🍁

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 и Продукт-Гены. Я для себя выбрал путь Тех-Лида. В следующем посте расскажу про себя.

Спасибо, что читаешь 🙏

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

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 🙏

React.js - The documentary 📽️

Привет!👋 Команда Реакта запускает документальный сериал про разработку React.js👨‍💻

Рекомендую посмотреть, по мере выхода, чтобы понять, как 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

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.

Path to Staff Software Engineer | Part 2 🚀 (English version can be found above)

Привет! Это вторая часть серии постов про работу над промо до Стаффа. Сегодня расскажу, что делаю я, для того, чтобы получить промо 👨‍💻

Link to part one: https://t.me/frontend_engineer_blog/168

Немного контекста
Про архитипы, мы поговорили в прошлом посте. Будем исходить из того, что мы идем по Архитипу ТЛ - Tech Lead.

☑️ Какие преквезиты нужны, чтобы запромоутиться до E6 в Мете:

- Быть тех-лидом для команды 6+ человек
- Успешно запустить, как минимум, один большой проект
- Драйвить архитектурные решения - бизнес дает проблему X. Твоя задача - кларифицировать требования, работая с ПМами и дизайном. Из проблемы Х, создать архитектурное решение в виде спецификации, части которой можно распределить между инжинерами. Желательно, чтобы каждый инжинер мог раскрыть технически в глубину, каждую часть спеки.
- Деливерить через других. Научиться скейлить себя - твои возможности ограничены, Ты не можешь кодить и делать архитектуру и планировать дальнейший скоуп на команду. Умение делигировать задачи критически важно. Делегировать нужно так, чтобы давать людям задачи, на которых они будут расти.
- Влияние на свою и внешние команды, стафы, как правило имеют влияние на соседние команды, с которыми работают. Это выражается в контрибуции в спеку других команд, влияние на роадмаппинг скоупа внешних спек
- Контрибуции в org-wide инициативы. Например имлементации поддержки нового фреймворка внутри всех команд в орге или запуск менторинг инициатив внутри орга
- Работать в high-prio area и оказаться в нужное время и в нужном месте ( Это очень важно ). Очень сложно работать над промо в команде, где ТЛ распределены, скоуп потянет и нужны только лишь исполнители. Очень важно попасть в проект на его начальном этапе развития.
- Менеджер, должен хотеть тебя запромоутить. К сожалению, это так. Если менеджер не прикладывает здесь усилий, очень высока вероятность, что промо ты не получишь

Как вы понимаете, все эти вещи нельзя сделать сразу, на это требуется как минимум 6-9 месяцев. Главная ошибка - пытаться делать какие то вещи ради fake-impact. Например хайрить людей в команду, на неэффективный проект и запускать инициативы, которые не принесут организации пользу.

Как я уже говорил, я оказался в нужном месте и в правильное время. Я принял решение менять команду, когда понял:
- Моя команда не будет расти и уровень задач будет низкий
- Мой орг - не приоритетное направление компании

В итоге, я выбрал команду - которую приоритизировала компания и я пришел в нее на начальном этапе развития, когда в ней было всего 7 инжинеров. Сейчас нас 53. Мне очень нравятся люди внутри этой команды. Таких продуктивных и талантливых ребят я не видел давно. Многие - сильнее меня в техническом плане и это хорошо.