Как думаете, почему всегда одно и тоже:

куда не полезешь глубже, чем базовые знания, всегда начинается «вакханалия», ошибки и баги?

Как в фреймворках, так и в книгах, официальной документации и изредка в алгоритмах.

Вот сколько лет занимаюсь столько лет сталкиваюсь

🗓️ Как оценивать срок задачи

Ребята, привет)
В свое сам неверно оценивал задачи, а потом ночами дорабатывал, чтобы успеть. У кого было?

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

И вы прикидываете в мыслях: «Не знаю, что он хочет, но за 2 недели успею. А если нет – посижу на выходных» и озвучиваете ему дату в 2 недели.
Так происходит, потому что вы чувствуете давление, или хотите угодить, или имеете синдром самозванца.

❌ В момент, когда вы сделали такую оценку, вы солгали)
Через 2 месяца, когда из-за вашей реализации, сделанной под давлением сроков, начнут сыпаться баги – эта ложь будет на вашей совести.

Оценивать задачу, которую вы не понимаете – это "самоубийство". Из-за этого заканчивались карьеры. Вы выгораете, проект рушится.
А всё потому, что вы постеснялись, и сказали "2 недели". Когда вы сказали срок, основанной ни на чем, вы подписали контракт, который не можете выполнить. И вы проиграете, когда время подойдет к сдаче проекта.

Решение
📌Неопределенность задачи порождает неопределенность сроков. Если менеджеру нужна точность, ему придется предоставить вам точность. Если он будет настаивать, скажите ему, что вам нужно 2 дня на исследования. Это защитит вас и покажет ему, что он не знает, чего хочет.

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

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

Если вам запрещают указать диапазон, говорите следующее:
✅ Передача риска: «если я назову конкретную дату выполнения, даю 70%, что я не успею. И если что-то пойдет не так, то задача растянется на месяц. Не думаю, что нам стоит так рисковать»
✅ Предложение по исследованию: «сейчас я не могу назвать реальную цифру. Мне надо 2 дня, чтобы разобраться. После этого я буду знать диапазон, когда задача, скорее всего будет выполнена»

Выводы
Ваша задача – отказаться от вранья. Ложь вредит и вам, и компании. Неверные оценки имеют стоимость: из-за них половина проектов выходит за бюджет. В итоге:
❌ Вы работаете по выходным и пишите плохой код, везде, где это экономит время.
❌ В коде, написанном под высоким давлением, в разы больше ошибок (видел цифру до 15 раз)
❌ Вы не экономите время. Вы берете в долг под огромные проценты. И платите их своим временем и здоровьем.

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

Если вы будете брать на себя невыполнимые сроки, вы выгорите и начнете ненавидеть эту работу.

✍🏼 В следующий раз, когда вас загонят в угол, используйте шаблон выше:
✅ Назовите диапазон, а не конкретную дату
✅ Настаивайте на предоставлении полной информации о проекте: «если вам нужны от меня точные сроки, мне нужна от вас дополнительная информация».

Вы не ведете себя токсично. Вы ведете себя профессионально.
Перестаньте успокаивать людей ложью, начните успокаивать их правдой)

Кто уже 3й месяц бездельничает и обещает себе завтра взяться за ум и всё никак?

Кто знает что на фотке?)

Мы тут продираемся сквозь кластеры. Грязное дело очень.

Кстати, redis мне не ответил

🙅‍♂️ Как избегать бесполезных встреч

Господа, у кого голова болит, когда за день у вас 3 звонка, но за эти 3 часа ты только сказал «привет-пока» и еще раз 20 кивнул в камеру?

Ситуация
Вам приходит приглашение вида «Quick Sync\Надо синкануться» и никакого описания, что вы там будете делать. Ты принимаешь его, т.к. боишься пропустить что-то важное или показаться сложным сотрудником.
Придя на встречу, через 5 минут понимаешь, что вместо совещания тебе просто могли написать письмо. На совещании тебя даже ни о чём не спрашивали - просто украли час жизни.

Причины бесполезных встреч
Менеджер использует тебя как страховку, т.к. боится рисковать. Если проект провалится, он скажет: «Он же там был». Ты - психологическая подушка безопасности. Ты там не потому, что нужен, а потому что он запаниковал и решил перестраховаться.

Как вернуть себе время
Перед тем как нажать «принять», задай вопрос отправителю:

«Решение какого вопроса от меня требуется в течение встречи?»

Это вынудит менеджера быть конкретным. Если ответ есть, то иди на встречу. Иначе ты им нужен не как разработчик, а как страховка.
Если тебе ответят «надо прийти» - вежливо отказывайся. Скажи, что ознакомишься с заметками о встрече позже, сейчас погружен в другую задачу.
Этим ты приучаешь их уважать свою профессию инженера.
❗️Это может казаться токсичным, но если ты senior или lead - так делать необходимо.

Иногда сказать «нет» невозможно. Требует CEO. Клиент кричит. В этом случае иди, но придерживайся правил. Скажите своё мнение один раз и прекращай слушать разговор. Не предлагай лишнего. Не заполняй тишину. Твоя задача - внести полезный вклад, а не изображать присутствие, выжигающее твои силы и нервы.

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

Как этим пользоваться:
Если за 15 минут никто не обратился к тебе за советом, пиши в чат и выходи:  
«Похоже, я здесь не нужен. У меня в календаре есть в среду 2х часовой слот на любые вопросы, пишите в это время или приглашайте на встречу – с радостью отвечу».  

❗️Каждая бессмысленная встреча убивает глубину работы. А именно в глубокой работе создаётся настоящая ценность проекта и рост тебе, как инженера. В среднем 5 встреч в день тратят 3 часа в пустоту. А это ведет к тому, что ты приходишь домой еле живой. Не потому, что создал что-то важное, а потому что весь день реагировал на внешние раздражители.

Границы - это не эгоизм и токсичность. Границы - это структура. Без них ты выгоришь.

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

«Решение какого вопроса от меня требуется в течение встречи?»

✅ Сэкономь себе час или сделай встречу полезной.  
✅ Твоё время не общий ресурс. Это твоя карьера и жизнь. 
✅ Охраняй его, т.к. от этого зависит твоя жизнь.

Минутка размышлений:

«Всем известен опыт одиночного плавания доктора Линдемана. Этот ученый проплыл в пироге от Западной Африки до Гаити за сто девятнадцать дней и на складной лодке от Канарских до Антильских островов.Линдеман уверяет, что моральный фактор не менее важен, чем все физические условия. Основа опасности, пишет он, в самом человеке, если он становится жертвой душевного надлома и не может действовать трезво. Линдеман изучил работы психолога Шульца, рекомендующие самовнушение как очень важный элемент закалки воли и работоспособности. Самовнушение спасло его на пятьдесят седьмой день путешествия, когда лодку опрокинуло и он девять часов во тьме ночи цеплялся за крохотную скользкую калошу. Когда тебя качают девятиметровые волны, налетают шквалы, бешено завывает ветер — такое требует, пожалуй, большего, нежели обычной воли к жизни»
Иван Ефремов, Лезвие бритвы

Как думаете, какое это отношение имеет ко всем нам, кто строит карьеру и развивается, как инженер?

🐣Что делать, если вы застряли в карьере [часть 1 из 2]

Кто здесь постарше, уже не раз видели, как тренды в IT казались будущим, а потом лопались. Меняются стеки технологий и их названия. Проблемы разработки и карьеры остаются теми же. Давайте их разберем.

Ошибка 1: «Стратегическое нет»
Кто узнал себя: человек отдал 5-10 лет, стараясь быть полезным, а не ценным. Для этого он чинил вещи, которые в принипе не должны ломаться.
Многие думают, что если быть полезным, то тебя будут повышать. Это ошибка, т.к. твоя полезность делает тебя заменяемым. Каждый раз, когда ты бежишь решать проблему, ты учишь команду звать именно тебя. Ты становишься тем, который чинит, а не предотвращает проблемы.
С самого старта карьеры, всегда используйте «стратегическое нет».

Cразу говорите «нет» половине запросов. Приучите себя приоритизировать задачи.

Наверняка сейчас у вас на проекте большинство «горящих» задач – это просто паника менеджеров, которые не до конца понимают, что важно. Поэтому приручите себя к автоматизации вашего процесса разработки. Для этого:
1️⃣ Всегда записывайте подходы для решения типовых «горящих» задач
2️⃣ Затем научите других, как их решать
3️⃣А сами берите те 20% задач, которые влияют на проект (закон Парето). Именно в них находится точка вашего быстрого карьерного роста.

Ошибка 2: «Невидимка»
❗️Менеджер НЕ видит ваши ночные переработки, о которых вы не рассказываете.
Он видит только результат. Поэтому хорошо выполненная задача за свой счет не покажет вас хорошим инженером. Она исчезнет незамеченной менеджером. Вы играете в невидимку.
Ваша работа заключается не только в том, чтобы быть хорошим инженером. К высочайшим результатам в карьере приходят инженеры, которые умеют говорить на языке бизнеса. Собственника компании волнуют 3 вещи:
1️⃣ Сколько денег он потратил
2️⃣ Сколько денег он заработал
3️⃣ Какие есть риски в будущем
Пока вы не будете показывать менеджменту, как соотносится ваша работа с этими 3-ми пунктами, для бизнеса вы будете невидимкой.

Поэтому запомните 3 метрики:
☑️ Стоимость привлечения клиента (англ. customer acquisition cost, CAC)
☑️ Пожизненная ценность клиента (англ. lifetime value LTV)
☑️ Время до получения ценности (англ. time to value)

Каждая выполненная вами задача должна отвечать на вопрос — какую из этих метрик вы улучшаете.
Пример: если вы ускоряете онбординг - вы сокращаете Time to Value. Так и говорите.
Повышение получают разработчики, которые не просто добавляют функционал в проект, а объясняют, как этот функционал меняет бизнес.
Чтобы все это привело к быстрому росту, вы должны с первого дня работы, каждую пятницу в течение 15 минут соберирать доказательства своей важности для компании. Для этого записывайте себе в заметки\почту:
☑️ Какие задачи вы реализовали
☑️ Какие задачи благодаря вам разблокировались для других разработчиков
☑️ Какие будущие потенциальные проблемы на проекте вы предотвратили

Описывая ваши задачи, свяжите их с тем, какую пользу они принесли бизнесу по метрикам, перечисленным выше.
❌ Не пишите: «исправил баг»
✅ Пишите: «защитил выручку, уменьшив кол-во падений сервера в месяц»

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

🐣Что делать, если вы застряли в карьере [часть 2 из 2]

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

Инвестируйте 10% своего времени в политический капитал:
✅ Сходите раз в неделю на кофе с кем-то вне команды. Спросите, что его тревожит и не даёт спать ночью.
✅ Вызывайтесь помогать в проектах, где задействованы разные отделы (например: рекламщики, финансисты и программисты) для достижения общей цели компании
✅ Задавайте вопросы, о которых все думают, но вслух никто не произносит. Это не выставит вас тупым, а наоборот смелым
✅ Чем больше вы набираете таких знакомств, тем больше ваше влияние. Чем больше влияние на проекте и в компании, тем быстрее рост.

Ошибка 4: «Культура и 6 месяцев»
Придя в компанию, в ней уже есть своя культура. Вы не можете исправить это культуру, просто хорошо выполняя свою работу инженера. В конечном итоге токсичная культура поглотит вас.
Признавайтесь, кто здесь отдал плохим компаниям годы, которых они не заслуживали 😅
Теперь вы знаете, что это было время, украденное у вашего будущего.

Придя на новую работу, используйте правило «6 месяцев»:
☑️ Сначала 3 месяца наблюдайте, кого за какие задачи повышают
☑️ Потом 3 месяца тестируйте систему, попросив похожие задачи на рост
☑️ На шестом месяце принимайте решение оставаться или нет

❗️Если культура компании токсична, т.е. вы сделали все задачи, а вам не дали повышение - уходите. Преданность токсичной компании - это выстрел себе в ногу. При первом вашем неугодном поведении вас заменят за 2 недели.

Ошибка 5: «Позиционирование и доверие»
Быть отличным инженером - это инструмент, а не стратегия. Людей, как правило, повышают из-за их умения позиционировать себя.

Для карьеры важно то, что о вас говорят за вашей спиной.

❌ Перестаньте шлифовать идеальный код.
✅ Начните шлифовать ваш вклад в бизнес.

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

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

Вам НАДО доносить до менеджмента выполненную вами работу, не чтобы потешить эго, а чтобы к вам росло доверие. С первого дня карьеры собирайте доказательства, что вам можно доверять: пишите статьи, выступайте, обучайте других. Сделайте так, чтобы в вашей индустрии люди знали вас еще до того, как позовут на интервью.
Создавайте сеть контактов до того, как вас уволят и вам понадобится кто-то, кто вас порекомендует. Ходите на конференции, общайтесь на них с CTO, поддерживайте связь.

Выводы:
1️⃣ Вы слишком часто говорите «да»
2️⃣ Вы невидимы
3️⃣ Вы не говорите на языке бизнеса
4️⃣ Вы слишком долго остаетесь в плохих компаниях
5️⃣ Вы не увеличиваете доверие компании к себе

Навыки программирования у вас есть. Вам не хватает стратегии построения карьеры.
Ваша карьера — ваша ответственность.

Пару минут назад прислал ученик)

Если надоело пинать камни, и хочешь так же, напиши нам в @cronis_service «хочу курс». Годовое стоит $270

А завтра еще кое-что покажу важное

Интрига)

Интенсив?
Новые задачи от учеников?
Новые курсы?
Скидки?

Что хотите?

Есть ребята, кто за System Design переживает больше, чем за алгоритмы?
Не продажа. Интересно для себя, чтобы понимать куда развивать школу)

О «плохих» программистах и вере в себя

Мой путь в Google начался не с оффера в Калифорнию, а с фразы «ты никогда не станешь программистом»

То, что я хотел быть программистом, я знал всегда. В универ пришел из слабой школы. Приходилось зубрить ночами. Объемы были такие, что мозг не вывозил. И где-то недели за 3 до сессии я понял «секрет»:

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

Но понял я это слишком поздно, и в первом семестре плохо сдал 3 предмета: историю, физику и программирование. Помню ту ошибку, написал на экзамене на листке, задача была на C++:

int 4 = x;

Преподаватель мне сказала:
«Вы не думали, что неверно выбрали университет? Вы никогда не станете программистом».
Еще масло подливало в огонь то, что пара одногруппников, кто учился программированию еще со школы, ухмылялись с моего кода и тоже говорили:
«Ты уверен, что верно выбрал профессию?»

Тогда, выходя с экзамена, думал:
«Да вы там оф***ли» (на самом деле слово было грубее)

Эта злость и понимание, что надо учить не наизусть, как в школе, а понимать, что ты делаешь – сработала. Мало сна, много учебы и программирования, и со 2-го семестра я стал первым в рейтинге факультета. Параллельно устроился на работу в аутсорс.
Получил президентскую стипендию (выдавали 3м людям). На 4-ом курсе захотел получить красный дипломом, мне разрешили пересдачу экзаменов первого курса, но преподаватель по физике наотрез отказался ее принимать. Красный диплом не случился из-за принципа одного человека. Что я тогда понял:

Неовозвратное решение вашего будущего может зависеть от одного человека.

На работе пахал по 10-12 часов, дома курсовые + лабораторные + изучение фреймворков для работы. Результат не заставил себя ждать, тимлид сказал мне в лицо:
«Ты — один из худших, никакой зарплаты».

В тот вечер я долго ворочался, и было больно до слез. Синдром самозванца просто парализовал меня. Когда ты работаешь, отдаешься на 100%, постоянно учишься и на выходе получаешь тотальное уничтожение психики.
К утру в голове появилась знакомая уже мысль:
«Да вы там оф***ли!».

Боль стала топливом, и я решил, что не позволю чужому мнению определять, кто я. Стало понятно, что аутсорс часто ценит тех, кто быстро лепит костыли. А я хотел быть инженером, и знал, что никто в мире не заставит меня писать код, который я не понимаю. Поэтому по крупицам я начал строить свою систему: Computer Science,System Design, Soft Skills.
Была ли поддержка? Только усмешки коллег:
«Алгоритмы для лохов, надо изучать .NET 3.5»

Итог
✅ В 22 года: тот же лид, который сказал, что я худший, был вынужден дать мне должность Senior, проведя со мной 2 собеседования по 6 часов и осознав, что я знаю всё, и даже больше и по метрикам компании на мой официальный запрос на повышение он не может ничего сделать.
✅ В 24 года: TVC Senior Software Engineer в Google.
✅ 2 года жизни в Калифорнии (там были свои приколы, пишите, кому интересно – расскажу)
✅ Именная благодарность от моего тех. лида из Google.
✅ Исправил реализацию Rate Limiter от Redis, убрав ошибку многопоточки Race Condition

Те, кто называли меня худшим, скорее всего, остались в аутсорсе. А я с 2016 года помог 5000+ студентам изучить computer science и найти дорогу в лучшие компании, где высшей точкой является MAANG и Яндекс.

❗️Знайте: ваш «потолок» - иллюзия. Плохой тимлид, слабая база или то, что в вас никто не верит - не определяют ваш потенциал. То что я рассказал – краткая история, но поверьте, я совершил все возможные ошибки и наткнулся на все попытки убедить меня, что я ничего не смогу. Это говорили все: от друзей и комментаторов в интернете до преподавателей.

Кто чувствует, что застрял в стеклянном потолке аутсорса, несмотря на все старания?
Ставьте 🔥, кто понимает о чем я, и делитесь историей в комментариях. 👇

🎁 Лекции курса по System Design:
https://www.youtube.com/watch?v=J_2MZuDDOXA
https://www.youtube.com/watch?v=gPlk5q6wUhY

Ошибаются даже создатели Redis (и наш любимый ИИ)
Вчера я поделился, как фразы «ты худший в команде» стало моим топливом, чтобы учиться активнее. Сегодня хочу показать, к чему приводит такая «инженерная внимательность к мелочам», когда она накладывается на системные знания.

Многие разработчики годами используют Redis как «черный ящик», доверяя документации на 100%. Работает и ладно. Но когда ты готовишься к уровню MAANG, ты перестаешь верить документации на слово. Ты начинаешь смотреть «под капот».
В добавок, сегодня все это ухудшилось слепым доверием к ИИ.
Кому-то может казаться: «Claude скорее всего прав, можно комитать». Но правда в том, что и документация, и нейронки могут выдавать код, который работает в песочнице, но валится в реальном проекте.
Месяц назад я разбирал реализацию ограничителя кол-ва запросов (англ. Rate Limiter) в официальной документации Redis, и заметил серьезную ошибку: состояние гонки (англ. race condition).
В многопоточной среде, под реальной нагрузкой, код вел себя непредсказуемо, и система могла пропускать лишние запросы. ИИ, кстати, до сих пор может генерировать этот алгоритм с той же самой ошибкой, потому что он «учился» на этих данных.

Что я сделал?
Я написал об этом на GitHub тут. Разработчики Redis признали ошибку, поблагодарили меня за вклад и исправили код в документации.

Почему я про это рассказываю?
❌ В outsource тебе надо быть пользователям чужих решений и промптов.
✅ В BigTech тебя ценят за то, что ты можешь улучшать эти решения и видеть, где ИИ даёт сбой.

✅ Разница между Middle и Senior не в годах опыта и не в умении пользоваться нейронкой, а в глубине понимания базы Computer Science.
✅ Когда ты понимаешь, как работают алгоритмы, то магии не существует. Ты видишь ошибки там, где другие (и даже ИИ) видят эталон.
✅ Именно этому мы и учим - инженерному рентгеновскому зрению.

На вебинаре (уже через неделю!) в первый день мы как раз начнем с этого фундамента - Computer Science. Покажу, как перестать зависеть от подсказок ИИ и начать видеть такие баги с первого взгляда. Чтобы попасть, вступайте в группу

Вопрос)
Часто ли вы ловили ИИ на «галлюцинациях» или коде, который мог положить проект?
У кого быть такие же жесткие баги, когда виноват ИИ \ фрейморк, а не вы?

Ошибка выжившего или математический расчет?

После вчерашнего поста про Redis, возможно кто-то из вас подумал:
«Это уровень гения. Чтобы такое видеть, нужно родиться с процессором в голове».

Я тоже долго так думал)
Работая в outsource, выкладываясь на 100% и получив оценку «худшего в команде» от токсичных коллег, я на короткий срок в это поверил. Почему?

Потому что тогда они были для меня авторитетами. И поэтому мысль «BigTech только для избранных» укреплялась в голове. Если бы не моя злость и тотальное несогласие, вырвавшие меня оттуда, я бы так и остался работать в той же компании.

Но мой путь от заваленной физики до именной благодарности от Google доказывает обратное:

Это не магия. Это дисциплина + стратегия, то есть алгоритм. А значит его можно повторить.

В 2016 году я открыл школу Cronis, потому что знал: можно передать это «инженерное зрение» другим. С тех пор обучение прошли 6600+ заочно (статистика) и 400+ очно студентов по всему миру: от СНГ до США и Европы.

Результаты за 9 лет:
✅ Ученики, которые прошли до конца и выполнили все домашние задания, сейчас работают в Яндексе, топовых финтехах и компаниях MAANG.
✅ Другими словами, их результат не случайный, а системный.

Среди моих выпускников были ребята из таких же «слабых» школ, как у меня. Были те, кому в них не верили коллеги. Были те, кто не верил в себя, будучи умнее меня.

Но когда ты даешь человеку правильный фундамент — Computer Science, System Design, Soft Skills и поддержку - он перестает «угадывать» решение на интервью. Он начинает его видеть.
Если вы выполните все задания обучения, вы просто не сможете не вырасти.
❗️Это как в математике: подставив верные значения в формулу, ответ всегда будет верным.

До нашего 3-дневного интенсива осталось всего 7 дней. Мы пройдем по всем 3м пунктам, за которыми стоит ваш офер:
1️⃣ Computer Science: база, чтобы пройти интервью и понимать, где ошибается ИИ
2️⃣ System Design: архитектура, которую не заменит ИИ
3️⃣ Soft Skills: как показать свой для максимальной зарплаты

Я не обещаю «волшебную таблетку», но я покажу систему, которая работает уже 9 лет. Чтобы попасть, вступайте в группу

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

50% из вас застряли из-за одной ошибки

Вчерашний опрос подтвердил мои догадки. Большинство из вас (ровно половина!) ответили, что главная преграда на пути к оферу в BigTech - это отсутствие четкого плана действий.
И я вас прекрасно понимаю. Когда ты Middle или Senior в outsource, на тебя валится гора информации:
☑️ Зубри LeetCode
☑️ Разберись с Kafka
☑️ Купи курс по System Design
Ты хватаешься за всё сразу, тратишь вечера после работы, но через месяц понимаешь, что стоишь на месте.

Знаете, почему в университете я стал первым в рейтинге и получил президентскую стипендию?
Не потому, что я гений. А потому что знаю секрет, про который говорил выше:

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

Что я умею лучше всего, так это структурировать хаос. И я знаю, как даже сверхсложную задачу разложить на понятный алгоритм.
Чтобы не быть голословным: на 3-м курсе я провел эксперимент: разложил сложные методички на понятные шаги, из-за чего быстро изучил программу семестра за 1 месяц и сделал все лабораторные работы. Пока остальные только начинали вникать в темы, у меня освободилось 3 месяца семестра, которые я полностью посвятил развитию себя как специалиста и работе.
Побочный эффект: экзамены были сданы на 10 (в Беларуси это что-то вроде 5-ки с двумя плюсами, т.е. эту оценку не ставят), самый придирчивый преподаватель поставил 9, потому что не принципиально не ставил никому 10. Но обсудив со мной работу виртуальной памяти, был настолько удивлен, что попросил показать, где я всё это вычитал. На это я показал ему свой конспект, который собирал по крупицам (был 2010 год). Просмотрев его, он поставил мне 10 и включил этот конспект, как методичку к своему курсу.

Этот навык, - находить суть в хаосе и бить точно в цель, в 2016 году я применил для помощи ребятам к подготовке в MAANG. Я убрал всё лишнее, оставил суть и упаковал это в систему Cronis.

🥇Результат: 6600+ учеников прошли по этой карте. Все, кто дошел до конца - работают там, где мечтали. Им не нужно было гадать, что учить сегодня вечером. У них был ПЛАН.

До интенсива осталось всего 6 дней. Я искренне жду нашей встречи. Мне хочется не просто «рассказать про карьеру», а помочь вам превратить хаос в голове в четкую стратегию из 3х шагов:
1️⃣ Фундамент (CS): чтобы вы умели решать задачи не заучивая и видели баги в Redis раньше, чем их найдет ИИ.
2️⃣ Масштаб (System Design): чтобы вы проектировали системы на миллионы пользователей, а не «красили кнопки».
3️⃣ Офер (Soft Skills): чтобы вы знали, как получить именную благодарность от Google, даже если в начале пути вас называли «худшим».

План у меня есть. Буду рад, если он поможет вам так же, как когда-то помог мне.
Чтобы попасть, вступайте в группу

Ниже фото зачетки, с исправленной 9-ой на 10-ку.

Почему 5 лет в outsource часто превращаются в «день сурка»
До интенсива осталось 5 дней, и сегодня я хочу поговорить о самой болезненной ловушке для Middle и Senior разработчиков.

Многие ребята пишут мне:

Я 5 лет в индустрии, знаю 3 фреймворка, почему меня не зовут на собеседование в Яндекс или MAANG?

Ответ жесткий, но честный: в outsource мы часто проживаем один и тот же год опыта 5 раз подряд. Мы учимся быстро клепать фичи, гуглить готовые решения и надеяться на ИИ. Но когда дело доходит до фундамента Computer Science - наступает тишина.

Computer Science - это не теория для олимпиадников. Это ваша суперсила. Без CS вы видите только поверхность кода. А вот с ним вы навсегда снимаете с себя синдром самозванца.

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

В первый день интенсива мы начнем именно с этого - с разбора Computer Science:
✅ Мы рассмотрим метод, как решать задачи, не заучивая код наизусть, а зная, какие свойства структур данных используются для их решения.
✅ Разберем, как все в программировании связано, и покажем, что хаоса не существует, но существуют плохие учебники, заставляющие вас поверить, что вы ничего не можете и всё это для гениев.
✅ И в доказательство, что подход работает, решим задачи с интервью и вы увидите, как все может быть просто

Вопрос)
leetcode часто превращается в бесконечную зубрежку, которая не дает уверенности. Какая тема в алгоритмах для вас самая "сложная, на котором вы чаще всего спотыкаетесь?

Господа, завтра веб. Будет много пользы, даже тем кто раньше был.

Приглашаю, группа тут:

https://t.me/+mRtJMFnjutU4M2Fi