Подключайтесь к стриму с опытной IT-рекрутеркой. Мы уже начинаем)

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

Залетайте на стрим и задавайте свои вопросы в прямом эфире!

https://youtube.com/live/QJnkx5bHvRI?feature=share

Скоро новый поток курса, куда хочу добавить пару новых тем: работу с Redis и Kafka. Сегодня уже успел накодить кайфовых примеров с редисом, теперь кафка на очереди, но там думаю побольше будет возни) А потом ток записать останется)

Ко мне пригнал в гости мой хороший друг Шемистан:) Знакомлю вас с ним, потому что он будет помогать мне проверять домашки на грядущем потоке курса по микросервисам, чтобы больше человек смогло залететь:) а то в прошлый раз мне нормально так людей писало, что не успели

Шемик уже три года пишет на гошке и тоже, как и я, работает в Авито:) А вообще мы оба учились в одном классе и сидели за одной партой:) Также у него крайне интересная история жизни и тернистый путь попадания в IT, о котором можно почитать в его канале.

Хоть у Шема и хороший опыт в гошке, я перед тем, как его брать ревьювером на курс, заставил его целиком пройти курс самостоятельно😂 Чтоб он на своей шкуре почувствовал каково это ахахаха А самое главное, он весьма эмпатичный человек, который помогает советами по коду, пока не увидит, что человек понял и начал шпарить прогу дальше) Кажется это очень важно для того, кто дает тебе фидбек

А в преддверии запуска нового потока мы хотим поотвечать на ваши вопросы:) Можно про курс задавать вопросы, про го, да и в целом на общие темы) Пишите их в комменты и мы там же будет отвечать на них кружочками:)

P.S. На фотке мы показываем на свой родной город:)

🌹Rate Limiter: что, как и нафига

Го поговорим о Rate Limiter. Это штукень, которая ограничивает количество запросов к серверу за определённое время. Типа как раньше еду по карточкам давали, вот и тут та же картина с запросами к серваку. Вариков как именно ограничивать трафик много, глянем на четыре из них.

ВИДЫ АЛГОРИТМОВ

1. Fixed Window: Всё просто — допустим допускается 100 запросов в минуту. Но на границе интервалов возможны пики, и тогда сервер офигеет. Типо 99 запросов прилетит в последнюю секунду первой минуты, и в первую секунду второй минуты. В итоге за 2 секунды прилетит 198 запросов.
- Плюсы: Легко реализовать.
- Минусы: Возможны пиковые нагрузки на границах интервалов.

2. Sliding Window: Этот варик поумнее. Считает запросы в скользящем окне времени, так что пики сглаживаются, и сервер не перегревается.
- Плюсы: Сглаживает пики, равномерно распределяет нагрузку.
- Минусы: Сложнее реализовать, требует больше ресурсов.

3. Token Bucket: Это буквально ведро с токенами. Каждый запрос берёт один токен. Токены восстанавливаются со временем. Если токенов нет — запрос дропаем. Навалили в ведро 100 токенов и раз в 1/100 минуты докидываем новый токен на фоне. Если трафик летит быстрее этого темпа тут уж сорян, се ля ви.
- Плюсы: Гибкость, равномерное распределение нагрузки.
- Минусы: Может быть сложным в настройке.

4. Leaky Bucket: Ещё одно ведро, только с дыркой!)) Запросы вытекают с постоянной скоростью, а если их слишком много — всё льётся через край, и сервер рад не будет. По сути это очередь, каждый элемент которой обрабатывается через равные промежутки времени. И если очередь переполнится, то лишние запросы начинаем скипать.
- Плюсы: Предсказуемое поведение, стабильная обработка запросов.
- Минусы: Не так гибок, может отбрасывать внезапные пиковые запросы.

RATE LIMITER VS CIRCUIT BREAKER

Рейт лимитер похож ещё на один паттерн, который ограничивает трафик - сёркет брейкер. Вопрос только в чём между ними разница. Фишка в том, что Rate Limiter ограничивает количество запросов за определённое время, а Circuit Breaker предотвращает дальнейшие запросы, если предыдущие попытки завершились ошибкой.

Короче говоря, Rate Limiter юзают, чтоб предотвратить проблему с перегрузкой сервака, а Circuit Breaker, когда жопа уже наступила ахаха

Rate Limiter:
- Плюсы: Предотвращает перегрузку сервера, защищает от DDoS атак.
- Минусы: Не шарит за ошибки внутри сервиса.

Circuit Breaker:
- Плюсы: Изолирует ошибочные компоненты, предотвращает каскадные отказ системы.
- Минусы: Не предотвращает перегрузку, работает только после возникновения проблемы.

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

ПРИМЕР ТЕСТОВЫЙ, В ПРОД ТАКОЕ НЕ ТАЩИТЕ!

Писали когда-нить свой рейт лимитер или всё готовые юзали?

P.S. На фотке держим ведра с токенами😁

А какая технология вас прет больше всего?:)

Вопрос возник к вам. Мы вот каждый день чего-то там кодим и используем разные инструменты. Тут тебе и всякие протоколы а-ля http и grpc, и всякие базы типо постгреса и редиса, брокеры типо кафки, докеры, куберы и так далее)

И мне вот интересно: а какая из технологий нравится вам больше всего в плане использования? Ну чтоб вот работаешь с ней и на душе тепло)

И второй вопрос: а с какой технологией бы очень хотелось познакомится?)

P.S. Это может быть язык, инструмент, концепция и все такое

Подготовка к стриму идет полным ходом:) Прикупил 5 книжек кайфовых, которые разыграем в эфире!)

Напомню, что стрим будет:
29 июня в 19мск, а в 20мск уже можно будет купить курс:) Но стримить то мы на этом не прекратим, нам еще яйцо кощея разыгрывать😂

Норм книги выбрал?)

Сегодня выступаю на гошном митапе с докладом о типичных ошибках в гошке:) Много кота и крутых анимаций обеспечено😂

В 19:00 мск подключайтесь! Я там и на вопросы поотвечаю:)

https://www.youtube.com/live/SJHRxVxNLPg?si=p7hAN7Gjh4-67i2n

Что такое OKR и зачем они нужны?

Решил поделиться с вами интересной темой, пока ждем вечернего стрима. В крупных компаниях часто выделяют время на планирование всех процессов. Планируются дни, спринты, кварталы и года. А что такое OKR? Это цели команды на квартал, включая ключевые результаты, которых планируется достичь.

Представь, ты задумал разработать картофельную пушку в этом квартале и стремишся не отстать от графика 😂 Но вот нюанс: бизнес также внимательно следит за OKR еще на стадии их создания и может задать свои вопросы.

Важный дядька из бизнеса обращается к тебе и спрашивает:

- Олег, а подскажи пожалуйста, как разработка картофельной пушки улучшит наш продукт? Мы ж бл*ть банк!

И здесь важно уметь убедительно обосновать выбор цели, иначе придется искать новые варианты.

- Все верно, мы банк! У нас есть коллекторы, которым нужно, чем пугать должников. Наша картофельная пушка идеально впишется в это направление.

Как правило, OKRы описывают не 100% работы на квартал, а только основную часть. Остатки уходят на форс-мажоры, тех. долг и всё такое.

Лично у меня двоякие чувства по поводу OKR. С одной стороны, полезно ставить цели на будущее и систематически их достигать. С другой стороны, иногда появляется масса задач, которые важны для продукта, но не попадают в рамки OKR, да и в тех.долг не лезут, а решать их надо. Короч, такое ощущение, что постоянное использование OKR затея так себе.

🌭если юзаете OKR у себя на работе

P.S. На фото я пошел на завод окр планировать 😂

ТИПИЧНЫЕ ОШИБКИ В GOLANG

Ты пишешь на golang и до сих пор делаешь это? Да сколько можно, пора уже отучить себя от этих пороков! Смотри этот видос и узнаешь как делать в golang не стоит и почему. После видоса преисполнишься мудрости и сможешь пойти выпендриваться перед корешами.

А на какую из этих ошибок ты сам нарывался в работе?

Доп. материалы: https://t.me/olezhek28go/1308

СМОТРЕТЬ ВИДОС

Как подружить сервисы друг с другом?

Инженеры по всему миру навыдумывали всяких технологий, что башка кругом идёт, когда пытаешься во всём этом многообразии разобраться. Надо тебе намутить общение между сервисами - так одни говорят REST API юзай, другие крутят пальцем у виска и втюхивают свой gRPC, а кто-то сидит в уголке и натирает до блеска малоизвестный GraphQL. Ну и кого слушать?

Чаще всего технологии появляются, чтобы решить какую-то проблему, которую другие технологии или не решают, или решают фигово. Осталось понять, когда какую технологию применять, и будет нам счастье. Сейчас глянем на примерах, когда лучше юзать REST, когда gRPC, а когда и GraphQL можно расчехлить.

1. REST
Это как швейцарский нож в мире API. Он идеально подходит, когда вам нужно общаться с фронтендом. REST работает через HTTP/1.1, и браузеры отлично поддерживают этот протокол. JSON, который чаще всего используется в REST, легко обрабатывается на фронте, да и все к нему привыкли.

Есть у тебя магаз, где ты свои огурцы с кабачками продаешь. Заходишь ты на сайт магаза, и фронтенд запрашивает информацию о товарах с бэкенда. REST здесь нормас так ляжет. Ещё ж кайфово, если ребятки rest full поддержат, чисто по http методам будет ясно что делает та или иная ручка. Видишь patch метод и сразу всё ясно про это ваше обновление.

Несмотря на то, что JSON не самый лёгкий по весу формат и HTTP/1.1 не самый быстрый протокол, REST остаётся удобным и универсальным решением для большинства веб-приложений.

2. gRPC
А вот если ты вписался в мир микросервисов, то я тебе конечно соболезную, но надо как-то с этим жить. Запрос идёт с фронтенда, и чтобы собрать ответ, нам надо слазать в пяток микросервисов. Скорость тут уже начинает ролять сильнее. Надо мутить быстрый и эффективный способ обмениваться данными.

Тут-то и выходит на авансцену gRPC. Во-первых, он работает через HTTP/2, что уже делает его быстрее, так как умные ребята серьезно потюнили этот протокол с версии 1.1. Во-вторых, gRPC использует бинарный формат данных Protobuf, что уменьшает размер передаваемой информации. А коль сообщенька весит меньше, значит и летит по сети быстрее.

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

3. GraphQL
Решил ты сделать магаз с кучей фильтров, где можно по-всякому вертеть, какие данные отображать при поиске, а какие нет. Не будешь же ты каждый раз получать с бекенда все данные, а фильтровать их уже на фронте. Это шляпа какая-то, которая забьет тебе сеть. Надо быть хитрее и запрашивать только то, что действительно нужно.

GraphQL — это как SQL для API: вместо того, чтобы получать фиксированный набор данных, как принято в контрактах REST или gRPC, ты можешь запросить ровно то, что нужно. Это снижает нагрузку на сеть и ускоряет загрузку данных, особенно когда речь идёт о сложных и динамичных запросах.

Итого
REST — проверенный годами варик, особенно для взаимодействия между фронтендом и бэкендом. gRPC идеально подходит для быстрого и эффективного взаимодействия между микросервисами, когда важна производительность. GraphQL даёт максимальную гибкость в запросах данных, позволяя получать только то, что нужно, и оптимизируя взаимодействие между клиентом и сервером. Короче, как обычно всё зависит от контекста. Так что вникай в контекст и включай голову. Опять думать придётся(((

🔥 - мне REST больше всего по душе
🌭 - gRPC one love
🍌 - юзаю graphQL и не стесняюсь этого!

Твой опыт не влияет на зарплату

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

Эту мантру говорят джунам, которые хотят залететь в айти. Позадроть литкод пару лет, сделай 4 pet-проекта, пройди 3 бесплатных стажировки. И только после этого ты имеешь морально право искать работу.

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

Всё это сказки, которые рассказывают те, кому выгодно сэкономить на нас деньги!

Конечно, хочется просто писать код и не вникать в социальные процессы, НО реальность диктует иные правила. Если желаешь расти по бабкам и находить интересные проекты, выход один - нужно постоянно мониторить рынок и ходить по собесам.

Думаешь сидеть в одной компании и старательно делать таски? Итог один - получишь прибавку процентов 10 за год, даже если поразишь всех на performance review. На собесах же ты имеешь шанс кратно увеличить свой доход за выполнение тех же задач.

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

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

А какие у вас провалы бывали на собесах?

Что нужно знать для собесов?

Когда я устраивался в Озон, код был чище, печенье в офисе вкуснее, а ТындексТеоретикус не был крестным отцом половины джунов в РФ.

До собеса туда я сидел в лабе при Политехе, кодил, закрывал таски и думал, что умею программировать. Как вдруг зовут на собес. Я вообще был без понятия, что на нём спросят. До этого у меня был всего один собес, где мы смотрели видосы с моего ютуб-канала и угорали.

На нервяке я начал листать какие-то книги и смотреть курсы невпопад. Инфы в голову лилась тонна, но толку ноль, потому что читал я хрен пойми что, и отношение к реальности эта инфа имела слабое. И вот, вдогонку к стрессу, я ещё и усталость словил перед собесом(

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

Причина такой нервозности одна - страх неизвестности. Я постоянно проигрывал в голове разные сценарии, и, конечно, концентрировался на самых фиговых. Даже нормально сериал вечером посмотреть не мог. В один из вечеров переизбыток тревоги на слезы даже разъ***л.

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

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

Что обычно спрашивают на гошных собесах? (я только про гошную часть, а не про весь бэк)

- Какую-нить дрочь на слайсах с ловушками
- Могут докопаться до работы строк и их устройстве
- Куда без интерфейсов?! А там ведь тоже можно подловить на тонкостях
- Мапки. Как говорил один из моих тимлидов: "Дайте мне мапку и я решу любую бизнес задачу")))
- И конечно канкаренси. Тут тебя и за горутины притянут и за всякие паттерны, ну и куда без "очень важного" знания о работе планировщика

Разумеется, только теоретическими вопросами всё не заканчивается. Частенько дают разные задачки с кодом, где эти темы и прощупывают.

А что у вас на собесах спрашивали? И какой уровень духоты вы встречали?

Как я преисполнился в собесах

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

Было страшно, потому что я не знал, что будут спрашивать. И очень не хотелось облажаться, да ещё и публично( Интернет же всё помнит, потом будут угорать. При это хотелось себя испытать. Я ещё и на успех надеялся, а там уже тачки, деньги, слава ахахаха

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

Следом я съездил в Иваново на подкаст "Мы обречены" и совсем важной птицей себя почувствовал. Был уверен, что теперь успех неминуемо настигнет меня.

Спустя неделю попал на собес в зелёный облачный провайдер. Собес шёл часа полтора, вопросы были стандартные. Немного спросили за кафку и всё. Спустя 10 минут после собеса мне звонит рекрутер и говорит: "го скорее к нам, даём 250к на руки". Я охренел от такой скорости, а тем более суммы, потому что на тот момент моя ЗП была 140к.

Вывод, который я сделал из моего успеха:

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

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

А у вас бывали такие моменты, когда жестко прёт на собесах, офер за офером летит в руки или раз на раз не приходится?

Жизнь дала мне под дых

Получив сочный офер на 250к, я добился повышения на работе. Ещё робко, но уже с удовольствием, я налил себе банановый смузи и сел изучать рынок найма дальше.

Я наткнулся на Weekend Offer от одной популярной барахолки, где ещё можно снять хату и пробить тачку. Для меня это был новый формат. Мне казалось это весело, всего за пару дней намутить себе оффер. В этот раз я рвался не за большими деньгами, а скорее за признанием. Мне вновь хотелось услышать предложение о работе, и тем самым получить удовольствие от того, что я хорош и преодолел все препятствия.

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

Это был жесткий удар по самолюбию. С уверенности, что пройду любой собес, я свалился в состояние "еб*** я лох". В этот момент я подумал, что, возможно, все мои предыдущие успехи на собеседованиях были просто удачей. А я этого всего не достоин. Мало того, что ничего не решил, так ещё и молчал половину времени, что тоже создало не самое хорошее впечатление.

По итогу я пришёл к выводам:

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

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

А какие неожиданности на собесах бывали у вас?