Написал численную симуляцию и проверку решения задачи про забеги лошадей

Задача: https://t.me/faangmaster/555

Код проверки выложил тут: Численная проверка решения головоломки про топ 3 из 25 лошадей
Сделал 2 почти одинаковых варианта. В первом - время забега - случайное целое уникальное среди всех лошадей. Вторая - вещественное случайное.

Если вы считаете, что у вас есть контрпример - можете вернуть его в методе Horses.init() и проверить на нем.

Пишите в комментариях, если есть ошибки в коде.

Какие самые тупые вопросы(не технические) вам задавали на собеседованиях?

Из того, что у меня спрашивали:
1) Кем вы видите себя через 5 лет?
2) Есть ли у вас хобби?
3) Есть ли у вас друзья?
4) Готовы ли вы много работать?

Плюсы работы в Facebook

По моему мнению:

1) Компенсация. За время работы в компании я заработал ~$2.1М gross. Если бы я был в США эта цифра была бы в 1.5 раза больше. Мало кто платит столько разрабам. Правда, надо сказать, что вне повезло с качелями в цене стоков в 2022-2024.
2) Хорошая строка в резюме. Позволяет проще попадать на собесы в любые компании.
3) Scale. Опыт деливери фичей, инфры для такого масштаба пользователей, обьема данных, нагрузки.
4) Опыт работы с большим числом умных коллег. Такой концентрации умных людей я не видел нигде. Ни в одной другой компании или даже в топ вузе. Это имеет свои плюсы и минусы, но плюсы в этом тоже есть.
5) Относительная свобода в работе. В компании часто используется bottom up подход. Не везде и не всегда, но все же. Менеджер не занимается технической частью, он скорее занимается people частью, карьерным ростом сотрудников. От разрабов зависит очень многое, не только execution. Но и планирование, сетинг целей и метрик, алайнменты, дизайн и т.д. Это имеет и свои минусы, я об этом напишу в минусах.
6) Крутые внутренние тулы. Они делают разработку очень быстрой и простой. Вам, часто, не нужно тратить время на сетап энвайронмента, скачивание кода, долгую компиляцию. Есть куча внутренних библиотек, фреймворков, инфры, которая делает деливери решений очень простым и быстрым. Не нужно с нуля придумывать стек, сетапить, писать куча бойлерплейт кода. Часто это как соеденить несколько кусков лего, чтобы все заработало на масштабе миллионов или миллиардов пользователей. Внутренние тулы хорошие, но не идеальные. В этом есть свои минусы.
7) Лайтовый oncall. Он есть, и его напряжность варьируется от команды к команде. Но в среднем по больнице, он лайтовей, чем в Амазоне.
8) Лайтовые процессы или их отсутствие. Это позволяет быстро разрабатывать и шипить код. В командах, обычно, нет ни скрама, ни канбана. Sev-review также лайтовый, по сравнению с Амазоном. Но у этого тоже есть свои минусы. Я об расскажу в минусах.

Coffee badging

Это новый, относительно свежий, buzzword. Обозначает ситуацию, когда сотрудник приходит на работу на короткий промежуток времени(попить кофе, поболтать с коллегами), чтобы был засчитан день работы из офиса.
Явление появилось после обьявления RTO(return to office) policy.

Я постоянно практикую это. У нас сейчас гибридный график-3 дня из офиса, 2 удаленно.
Наличие сотрудника в офисе трекается и засчитывается по сканирыванию баджа(пропуска).
Поэтому я часто появляюсь на работе на 3-4 часа, пообедаю бесплатно, поговорю с коллегами, немного поработаю и домой.

Практикуете ли вы coffee badging?

Минусы работы в Facebook

Плюсы тут: https://t.me/faangmaster/561

Минусы, по моему мнению:
1) PSC (перфоманс ревью). Сейчас все в работе крутится вокруг этого. Так было и раньше, но в последние пару лет это стало основным и практически единственным, вокруг чего строится вся работа и жизнь в компании. Все сотрудники выстраивают свою работу так, чтобы оптимизировать метрики для PSC. Это влияет на коллаборацию, командную работу (которая практически отсутствует), усиливает конкуренцию между сотрудниками . Я называю это PSC Driven Development.
2) Хаос. Из-за отсутствия формальных процессов и бюрократии, нужно постоянно прикладывать дополнительные усилия, чтобы держать себя и других в курсе о том, что происходит, кто, что делает и т.д. Часто разные команды из одного или разных отделов решают одну и туже задачу, конкурируют между собой. Иногда, другие люди начинают решать уже решенную проблему и изобретать велосипеды, хотя над этим уже 5 лет работает целый отдел. Вначале, разраб, особенно ниже senior может чувствовать себя несколько потерянным в таком энвайронменте. Если вам раньше давали задачу и говорили, что делать, то тут этого практически нет. Каждый день, кто-то придумавает что-то новое и нужно постоянно прикладывать усилия, чтобы держать себя в курсе всего.
3) Очень высокая конкуренция. Это вытекает из высокого среднего уровня сотрудников, PSC Driven Development и потенциальных бенефитов. В основном, тут разрабы, которые привыкли быть лучшими, конкурировать с другими. Очень много людей с синдромом отличника, нарциссов, необходимостью быть лучшим. И среда внутри компании это все поощряет при помощи оценки перфоманса и гигансткой компенсации, бонусов, рефрешеров и т.д. Эта конкуренция чувствуется во всем. Особенно, это усилилось за последние пару лет.
4) Стэк технологий. Я люблю Java, но в Meta ее практически нет. Только в мобильной разработке. В бэкенде и инфре она есть но очень мало. Поэтому приходится писать на разных других языках (hack, python, c++).
5) Частые реорги, смены скоупа и менеджеров. Это связано с тремя факторами: культура компании (move fast, bold prioritization), болтанка последних двух лет и PSC Driven Development. Из-за культуры компании приоритеты команды, отдела могут смениться очень быстро, даже быстрее чем за 6 месяцев. Это может произойти за месяцы или даже недели. Если кто-то поймет, что нужно работать над чем-то другим, а текущий скоуп не имеет смысла. Directors/VP для своего PSC могут решить резко сменить структуру отдела, перераспределить скоуп для повышения эффективности. Могут быстро похоронить проекты, над которыми работают целый команды или отделы. Из-за массовых сокращений у вас может исчезнуть или смениться менеджер. Все это усилилось в последние пару лет. Из-за такой болтанки вы можете просесть на PSC. Но это никого волновать не будет. Работали над проектом, который быстро стал никому не нужен, потом начали работать над другим с другим менеджером, который вас не знал до этого и не успели себя проявить и достичь хороших результатов на новом проекте - плохой рейтинг на PSC.
6) Внутренние тулы. Это наверное самый лайтовый из минусов. Он применим ко всем фангам. Хотя тулы и крутые, их нигде больше нет. И опыт их использования вам напрямую не поможет в других компаниях. В среднестатистической компании другой стэк тулов и технологий. Обычно, разработанный кем-то другим и ставший open source. Также из-за этого использование google+stackoverflow или LLM сейчас не очень эффективно. Т.к. комьюнити этих тулов маленькое и находится внутри компании. Если раньше вы могли что-то загуглить, то в фангах это не работает. Надо выяснять внутри. LLM чуть-чуть помогают, но они все равно натренированные на внутренних доках и вопросах-ответах, которых мало, они не полны и устарели давно. Поэтому надо задавать вопросы в группах, которые занимаются разработкой тулов, искать во внутренних доках или копать код самому.

FIRE movement

Это аббревиатура: Financial Independence, Retire Early. Что означает финансовую независимость и ранний выход на пенсию.

Движение стало популярным в десятые, особенно среди программистов США.

Основная идея в том, чтобы откладывать существенную часть зарплаты и инвестировать(индексы, акции, депозиты и т.д.). За 10-20 лет накопить существенную сумму и жить на проценты, не работая.

Ориентировочно, нужно накопить столько, чтобы жить на 4% в год от накопленной суммы.
Например, если вы хотите жить на 300 тысяч рублей в месяц, не работая, вам нужно накопить 300k×12/0.04=90 миллионов рублей. Причем, существенная часть этой накопленной суммы будет сренерирована не зарплатой напрямую, а сбережениями, которые были инвестированы в фондовый рынок.

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

Если суммы недостаточно, можно переехать в другую локацию, где дешевле, и жить там.

https://en.wikipedia.org/wiki/FIRE_movement

Non-lucrative residence visa (NLV)

Это тип визы в Испанию, которую можно получить, если у вас есть доход вне Испании (удаленка, сдача в аренду и т.д.) или просто достаточно сбережений.
Сколько нужно сбережений или дохода: ~€27k в год + ~€7k на каждого члена семьи.
После 5 лет можно получить ВНЖ, а через 10 гражданство.
Подходит тем у кого есть пассивный доход, достаточно сбережений или удаленка.
Больше деталей тут: Non-lucrative residence visa (NLV)
Также есть Digital Nomad Visa, но предназначена конкретно для удаленщиков.

Очередное видео от одного из основателей Open AI, про использование LLM

Andrej Karpathy выпустил очередное видео, где рассказывает про разные функциональности LLM и как они в реальности работают. И как использовать LLM эффективно, зная их внутреннее устройство. https://www.youtube.com/watch?v=EWvNQjAaOHw

Собеседовал сегодня очередного кандидата из Google

По моему опыту, особого смысла проводить кодинг собеседование для кандидатов из Google нет. Пока не встречал кандидата, кто бы его не прошел. Я бы оставил для них только собеседование по System Design и поведенческое. Эти два собеседования они иногда не проходят.
Про кандидатов из других компаний такое сказать не могу. Кандидаты из Amazon, Microsoft, Yandex хоть и чаще проходят, чем в среднем, но в существенном проценте случаев заваливают кодинг собеседование.

Отличие в процессах и методологиях в FAANG по сравнению с другими компаниями

1) Реальный CI/CD. После того как вы запушите свой код, он окажется в проде в течении нескольких часов. Никаких ручных процессов, версионирований, долгих релиз циклов. От написания кода до релиза на миллиард пользователей проходит несколько часов. Есть исключения(особенно в мобильной разработке), есть A/B тестирование, есть прогрессивный роллаут, но чаще сам код в проде через несколько часов.
2) Нет QA, или почти нет QA. Написание тестов (unit, integration, perfomance, stess, load, e2e, chaos engineering) лежит полностью на разработчиках. Есть исключения, но большая часть команд не имеют выделенных QA.
3) Менеджеры это не тех лиды и не занимаются разработкой и технической частью. Менеджеры занимаются оценкой перфоманса сотрудников, их карьерным ростом, конфликтами между командами/отделами, участвуют в планирование, статус репорте и овнят роудмап. Но не занимаются дизайном, архитектурой, разработкой, раздачей тасков, микроменеджментом.
4) Саппортом занимаются разработчики. Есть исключения, есть SREs(Site Reliability Engineers), но все разработчики занимаются саппортом своих компонент/кода(oncall). Вас может разбудить ночью аларм на рабочем телефоне(пейджинг), если какие-то метрики просели, упала какая-то критическая функциональность. Вам нужно быстро среагировать и начать митигировать проблему.
5) Очень много индивидуальной работы. Очень мало командной работы. Связано с тем, как устроен процесс оценки перфоманса сотрудников. Разрабы работают над проектом от начала до конца. Они не могут просто брать самую приоритетную таску из бэклога из разных проектов. Иначе будет сложно описать нарратив, что этот разработчик сделал то-то с таким импактом. Поэтому все работают индивидуально над своими проектами. Они коллаборируют с другими, но имеют выделенный кусок работы, с понятным импактом. Поэтому Scrum/Kanban в чистом виде не особо применим.
6) Нет выделенных Архитекторов. Поэтому все разработчики на всех уровнях делают дизайн/архитектуру. Конечно, ее масштаб и импакт будут разными в зависимости от вашего уровня. Это может быть просто дизайн локальной для команды фичи или дизайн архитектуры, которая затрагивает десяток команд и несколько отделов.
7) Мало сторонних, открытых библиотех, фреймворков, тулов, технологий. Обычно, все или почти все разработанно внутри. Вплоть до языков программирования и систем контроля версий. Поэтому, приходится разбираться в этом с нуля. Нельзя просто загуглить ответ на любой вопрос по этим тулам. Нужно искать внутри, смотреть код, общаться с разрабами.

Как leetcode изменил coding собеседования в FAANG?

FAANG/BigTech компании используют алгоритмические задачи на coding-собеседованиях уже более 20-30 лет. Этот тренд был задан Microsoft в 90х годах. Потом его подхватили новые интернет-компании вроде Google, Amazon, Facebook и т.д. Вначале, единственный способ пройти такого рода собеседование - быть топовым олимпиадником, заботать книги вроде: "Искусство программирования" Д. Кнут, "Алгоритмы: построение и анализ" Т. Кормен, "The Algorithm Design Manual" Скиена.

В 2008 году появилась книга - "Cracking the coding interview", которая сделала подготовку проще и более доступной для бОльшего числа людей. Но все равно, вы скорее тренировались решать типовые задачи. Общее число задач, которые предлагались на собеседованиях, было сильно больше. Книга помогала освоить принципы решения, но не конкретные задачи.
В 2015 году появился Leetcode, который изначально состоял из задач из книги Cracking the coding interview. Далее туда стали добавлять сливы задач с реальных собеседований. И к 2018-2020 база задач уже не сильно отличается от баз задач внутри FAANG/BigTech компаний.
Во время собеседования интервьюер может спрашивать задачи только из официальной внутренней базы. Число задач в ней ограничено и задачи меняются в ней очень медленно.
По мере роста компаний, выросло и число собеседований, а как следствие и число сливов задач на leetcode. Поэтому на leetcode есть существенная часть задач, которые спрашивают на реальном собеседовании.
Это привело к кому, что такого рода задачами уже практически никого не удивить. А большинство кандидатов, которые успешно проходят собеседование - просто знают все задачи наизусть. Достаточно знать наизусть 50 первых по частоте задач для конкретной компании, чтобы с большой вероятностью получить эти задачи на собесе и просто воспроизводить их из памяти.
Проведя более 100 кодинг собеседований, я уверен, что почти все, кто его прошел успешно, просто, воспроизводил решение из памяти.

Как решать алгоритмические задачи так, чтобы не забывать решение

1) Сначала попробуйте решить самостоятельно. Не используйте подсказки, не смотри решение, разбор. Подумайте 0.5-2 часа. После этого посмотрите решение/разбор, даже если решили самострятельно и оптимально. Самостоятельное обдумывание прокачает ваши problem solving скилы, а также позволит вам глубже погрузиться в задачу, ее нюансы, сложности именно для вас, подсветит ваши пробелы. Когда будете смотреть разбор, вы поймете, чего не хватило именно вам для оптимального решения. Это сделает процесс обучения более персонализированным, а также из-за эмоционального отклика позволит запомнить решение и его сложности именно для вас.
2) Воспроизведите решение. Попробуйте, после самостоятельного решения и разбора решения - воспроизвести его так, как будто вы его обьясняете с нуля кому-то. Можете рассказать сами себе, можете жене, мужу, другу, коллеге. Лично я рассказывал решение сам себе и писал код на листе A4. Это поможет отложить решение в долгосрочную память, а также еще раз может подсветить пробелы в ваших знаниях. Вы можете считать, что разобрались в задаче, а когда начнете ее обьяснять, могут возникнуть дополнительные неясности и пробелы в понимании. Также можете делать это сразу на английском, потренируете одновременно и разговорный английский.
3) Периодически повторяйте решения важных задач. Это может быть и просто проговаривание вслух идеи решения, но также желательно быстро по памяти написать код. Важно также то, что вначале решения забываются быстрее. Поэтому повторите задачу в тот же день, потом через неделю, потом через месяц, потом через полгода, потом через пару лет. Например, это может быть так - решаете в течении недели задачи - повторяете их в тот же день методом воспроизведения. В конце недели повторяете задачи, решенные в течении недели. В конце месяца - решенные в течении месяца. Само повторение из памяти, обычно, быстрое - 5-15 минут на задачу. За выходные можно задач 50 повторить. Через полгода можно повторить 100 самых важных задач. Повторение займет ~неделю. С течением времени, задачи будут в вашей долгосрочной памяти и часто повторять их не обязательно. Например, можно через 2 года, а потом перед следующим собеседованием.

Накрутка опыта и закрытие пробела в опыте

Собеседовал кандидата в офис в Индии.
Открыл резюме, последние несколько лет у него позиция - Senior, но компании не указано и написано self employment. В качестве проектов и достижений - пет-проекты и ссылки на github и youtube видео с демо.
При этом до этого у него не было опыта Senior. Т.е. он не работал, но на первый взгляд у него нет пробела в опыте и позиция синьера.

Не знал, что такое бывает...

Bret Taylor

Обычно, на слуху люди вроде Цукерберга, Маска, Безоса, Гейтса. Многие из них основали свои компании будучи еще студентами или как одна из своих первых работ.

Решил привести пример человека с успешной карьерой, который не на слуху и не создал сверхуспешный бизнес в 20 лет.

Bret Taylor, родился в 1980 году. Закончил Стэнфорд в 2003.
В том же году устроился в Google, где работал в команде Google Maps.
В 2007 вместе с бывшими коллегами из Google основал стартап FriendFeed.
В 2009 этот стартап купил Facebook. Facebook оттуда взял кнопку Like.
В 2010 Bret стал CTO Facebook.
В 2012 Bret ушел из Facebook и основал компанию Quip.
В 2016 его компанию купил Salesforce, где в 2017 он занял позицию CPO, а в 2019 позицию COO. В рамках работы в Salesforce он занимался покупкой компании Slack.
На данный момент он также chairman в Open AI и Shopify.
В 2023 основал AI компанию Sierra.

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

На сколько можно увеличить свои сбережения, работая в FAANG?

Не смотря на то, что зп программиста сильно больше средней зп, обычно, чем больше ты зарабатываешь, тем больше тратишь. Большинство программистов могут откладывать деньги на отпуск, покупку электроники и т.д. В лучшем случае на первоначальный взнос по ипотеке. А также платить не за аренду, а за ипотеку и за кредит по машине. Купить квартиру и машину (дороже 3-5 миллионов рублей) на сбережения может далеко не каждый.
Работая в FAANG, у вас будет выше будет базовая зп, но основное финансовое преимущество FAANG-компаний - стоки. Практически всегда, для поддержания хорошего уровня жизни вам будет достаточно базовой зп. В это входит: аренда или оплата ипотеки, коммуналка, транспорт, еда, одежда, отпуск, электроника, мебель, развлечения. А стоки можно использовать в качестве основного источника сбережений.
Например, на позиции Staff Software Engineer (E6) в Facebook, вам дадут ~$1.6M долларов на 4 года. После налогов это примерно $0.8M. Но доп преимущество стоков - они могут расти. В 2010-2020, типичный сценарий был, когда твои акции вырастали в 4 раза за 4 года. В 2020-2025 более типично это в 2 раза за 4 года. Т.е. с большой вероятностью мы можете получить ~$1.6M за 4 года на руки в виде чистых сбережений. Эта цифра для США и для позиции Staff в Facebook. В зависимости от компании, позиции и локации это цифра будет другой.

Свежее интервью Yann LeCun

Yann LeCun - главный по AI в Meta. Чем известен - один из создателей Deep Learning. Его также называют отцом/крестным отцом AI. Получил премию Тьюринга за 2018 (аналог нобелевской в Computer Science). Создал CNN (Convolutional neural network), а также формат DjVu.


https://www.youtube.com/watch?v=RUnFgu8kH-4