Подборка статей, которые я уже написал и опубликовал в этом канале по system design
#systemdesign

Обновление подборки

Общие статьи:
Как устроено System Design Interview в FAANG?

1) Load Balancers 1
2) Load Balancers 2
3) Load Balancers 3
4) Consistent Hashing
5) Data Partitioning/Sharding
6) Design Web Crawler
7) Дизайн Uber/Яндекс Такси
8) Дизайн новостной ленты соцсети типа Twitter или Facebook
9) Availability
10) Consistency
11) Дизайн мессенджера Telegram
12) Обработка ошибок при вызове другой компоненты
13) Распределенный кэш. Часть 1.
14) Распределенный кэш. Часть 2.
15) Распределенный кэш. Часть 3.
16) Характерные числовые характеристики, которые нужно знать для System Design собеседования
17) Дизайн Google Maps
18) Некоторые подходы к архитектуре приложений в Amazon
19) Какие AWS сервисы мы часто использовали, когда я работал в Amazon?
20) Какие базы данных используются в FAANG?
21) Memcached vs Redis
22) CAP Theorem
23) Bloom Filter

Еще один подозрительный случай с собеседования

Собеседовал сегодня кандидата из Индии. Я, обычно, не смотрю резюме до того, как засабмичу фидбек, но сегодня посмотрел во время самого собеседования. В резюме написано, что текущее место работы - Amazon.

Почему я решил посмотреть?
Кандидат вел себя очень странно. Вначале он жаловался, что он меня плохо слышит. Я предложил ему перенести собеседование, т.к. с плохой связью будет тяжело нормально провести собеседование. Но он сказал, что хочет продолжать.
Далее я слышал свой голос в виде эха. Или проблемы связи или он пользовался спикерами в ноуте. При этом у него в ухе был только один наушник. Т.е. когда я говорил, я слышал свой голос, но при этом у него был наушник в ухе, но только один. Но это было не очень подозрительно, возможно, просто проблемы интернета.
Далее, когда я рассказал постановку задачи, то он ее написал в виде текста, ничего не уточнял и завис на минуту или две. После этого начал водить глазами так, как будто читает, и начал описывать оптимальное решение, но в стиле LLM/Chat GPT. Люди, обычно, так не говорят. После этого начал писать код в полной тишине. При этом писал строки символ за символом оптимального решения. Ничего не пояснял, и процесс написания кода был не естественным. Обычно, люди пишут не последовательно. Они скорее начинают с общей идеи, потом дополняют детали, пропущенные условия, пропущенные объявления переменных и т.д. Обычно, написание кода это итеративный процесс. В его случае выглядело так, что он очень медленно перепечатывает код символ за символом.
В итоге он не успел его потестить. При этом по problem solving и coding я поставил strong и moderate соответственно. По verification поставил N/A и по communication - Insufficient. И описал всю историю с моими подозрениями и выставил галочку, что я подозреваю его в читерстве.
Когда я посмотрел резюме, я начал подозревать, что, возможно, резюме фейковое. Обычно, кандидаты из Amazon показывают себя неплохо. Далеко не все проходят, но есть с чем работать. А тут как будто или чел супер странный или у него возник гениальный план пройти собес и получить зп в несколько сотен тысяч долларов и получить в первый же месяц десятки тысяч долларов sign-on бонуса просто используя ChatGPT.

В рамках Meta Connect 2024 показали прототип AR очков

Прямо сейчас идет презентация Meta Connect.
В рамках презентации был публично показан прототип разрабатываемых очков.
Официальная трансляция: https://www.facebook.com/share/zCv9EvbAAdmPLkfZ/

Пока на официальном канале на ютубе записи нет, но думаю скоро появится.

Не официальная трансляция на ютубе:

https://www.youtube.com/live/ezXhxAkhJfk?si=y7505TrDg-4CPogK

Короткое виде про очки:

https://youtu.be/mpKKcqWnTus?si=hsBXRvFCi2GYouHm

Уверенные пользователи ChatGPT кучно пошли

Прошлый случай был буквально вчера: https://t.me/faangmaster/451

Сегодня похожая история. Кандидат снова из Индии. В этот раз девушка и не настолько глупая. Прошлый тупо читал текст из ChatGPT ничего не понимая. Эта очень заметно отводила взгляд и потом пыталась своими словами обьяснить оптимальное решение. Правда обьясняла уже написанное решение неправильно.

Они, видимо, решили задедосить нас такими кандидатами.

P.S. Они - это (уверенные пользователи ChatGPT) https://youtu.be/iH1CUPlmBUs?si=W5xgdQQhkQXVtsXM

Жду когда картинка и звук будут нейронками.

Рейтинг Big Tech компаний по зп

Сделал расчет медианного офера, который предлагают 10 Big Tech компаний. Расчет делал из моих знаний про распределение по уровням в процентном соотношении. Для Amazon и Facebook я знаю это распределение достаточно точно. Для остальных я предположил аналогично. Уровни, которые я учитывал - Junior, Middle, Senior, Staff, Senior Staff, Principal. В Amazon уровни широкие, там я замапил их следующим образом: L4(SDE1) - Junior и Middle, L5(SDE2) - Middle, Senior, L6(SDE3, Senior SDE) - Staff, L7(Principal) - Senior Staff, L8(Senior Principal) - Principal.

Итоговый рейтинг и медианный офер:

1) Databricks - $409k
2) Facebook - $392k
3) Two Sigma - $356k
4) Uber - $344k
5) Netflix - $340k
6) Google - $294k
7) Lyft - $259k
8) Apple - $254k
9) Amazon - $222k
10) Microsoft - $213k

Сюрпризы для меня:
1) Ожидал Google увидеть месте на 4, а не 6.
2) Не ожидал увидеть Uber в первой пятерке.

Также надо иметь ввиду, что Databricks - это все еще приватная компания. Они дают много акций, но их не так просто продать. Эта компания рассматривается как Pre-IPO.
Также есть нюансы с Netflix. Они не дают акции. Поэтому ваша компенсация не может расти в разы, как в других публичных компания. Да и попасть в Netflix в большинстве случаев можно только при 3 условиях: 1) вы Senior+ 2) Вы уже в США 3) Вы работаете в другом FAANG

Рейтинг BigTech компаний по отзывам сотрудников

Сделал рейтинг тех же 10 компаний, но по отзывам на Glassdoor. Более того, я убрал оценку компенсации (во многих компаниях, где много платят, оценка по компенсации тянет общую оценку вверх) и Diversity & Inclusion (для выходцев из СНГ это мало значимо).

Почему я решил убрать оценку компенсации?
В компаниях, вроде Facebook или Uber, много платят, но там очень конкурентная среда и очень высокие ожидания. Из-за этого там страдает WLB (Work-Life Balance) и стрессовая оценка перфоманса сотрудников (калибровки, PSC). Из-за такой среды, многие сотрудники постоянно испытывают сильный стресс. Я захотел убрать фактор компенсации (золотой клетки), и в изоляции посмотреть как себя чувствуют сотрудники просто от ежедневной работы в компании, а не от большой зп.

Итоговый рейтинг:

1) Google - 4,075
2/3) Microsoft - 4,025
2/3) Two Sigma - 4,025
4) Databricks - 3,925
5) Netflix - 3,8
6) Apple - 3,75
7) Facebook - 3,6
8) Lyft - 3,45
9) Uber - 3,4
10) Amazon - 3,375

Первое место в рейтинге меня не удивило. Опыт работы в Microsoft тоже намного лучше, чем в других, т.к. они сильно пересмотрели stack ranking сотрудников из-за жалоб в прошлом. Two Sigma - это Google в мире финансов/хэдж фондов. Databricks - относительно новый игрок на рынке и платит больше всех, чтобы переманить сотрудников из других FAANG компаний, но при этом имеет хорошую атмосферу.
А Facebook и Uber платят хорошо, но опыт работы будет намного хуже (намного больше стресса). И там вы ощутите эффект золотой клетки больше, чем где-либо еще.

Amazon при этом и платит не очень много по сравнению с другими FAANG компаниями, но и опыт работы там в среднем хуже. Я сам 3.5 года проработал в Amazon. Было сложно, но я многому научился и какой-то жести не было. Я бы рекомендовал Amazon, как первую ступеньку в FAANG (проще попасть) для джавистов (т.к. там много Java). Если вам понравится и вы будете быстро расти, то особого смысла сразу менять работу возможно и нет. Но если вы будете там страдать, то через пару-тройку лет можно перейти в другую компанию.
Microsoft я бы рекомендовал, как первую ступеньку(легче попасть) в Big Tech для тех, кто любит C#, C++. Опыт работы у вас будет, с большой верояностью, хорошим. Но как только захотите больше денег, придется менять работу.

У подозрительного кандидата и резюме подозрительное

Недавно я писал про кандидата из Индии, который зачитывал ChatGPT текст и перепечатывал решение посимвольно: https://t.me/faangmaster/451

Я решил более подробно изучить его резюме. Еще в предыдущем посте я сказал, что он работает в Amazon, что видимо, и позволило ему попасть на собес.

После детального прочтения я уверен на 100%, что он не работает в Amazon. В целом, его резюме оптимизировано под FAANG. Оно соответствует всем рекомендациям, которые я давал ранее в этом канале. Оно и легко парсится, оно короткое, в нем описаны достижения с цифрами, там есть известные компании.

Почему я уверен, что он не работает в Amazon?

Прочитав список достижений, я увидел там много упоминаний open source технологий, которые почти или вообще не используются в Amazon. Он вплетал в текст достижений, названия технологий, которые используют средние и маленькие компании. Все они open source. В FAANG, в основном, внутренние, закрытые тулы и технологии. Хоть в Amazon и есть open source, но там были указаны те, которые почти не используются.
Более того, хоть в достижениях есть цифры, текст самих достижений очень не конретный и мало привязан к реальным задачам, которые решает Amazon. Т.е. все эти достижения можно написать для любой не FAANG компании.

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

Темплейт резюме

Пример, хорошего темплейта для резюме в FAANG: https://faangpath.com/template/
Нажимаем кнопку: Get the template

Вместо Objective я бы написал Summary, кто вы и почему вы нужны именно этой компании.

Education и Experience я бы поменял местами.

Последние 3 секции опциональны, если есть достижения вне работы, победы на олимпиадах, хакатонах, контрибьюшены в open source, свои проекты, выступления на конференциях и т.д.

P.S. Как дойдут руки, сделаю свой темплейт. Тут все равно несколько заточен под fresh graduate с малым опытом.

Как FAANG компании делают бэкграуд чек

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

FAANG компании не делают этот чек самостоятельно. Они поручают это сторонним компаниям, вроде https://www.hireright.com/.

Сотрудники этой компании с вами свяжутся и попросят вас предоставить много информации о себе.
Это список предыдущих мест работы, адреса работодателей, контактные данные (телефон, почта), имена коллег/менеджера. Попросят данные про места учебы, также в виде названий, адресов и т.д. Могут попросить ссылки на ваши социальные сети. Могут попросить справки о несудимости или их аналоги в ваших странах.

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

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

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

Я проходил этот процесс два раза, оба раза успешно, не смотря на то, что у меня образование получено в России, а также пару работодателей были в России. Занимает этот процесс 1-2 месяца.

Почему Amazon имеет такие низкие оценки от сотрудников

Я публиковал ранее рейтинг Big Tech компаний, по отзывам от сотрудников, без учета отзыва по компенсации и дайверсити: рейтинг
Amazon там на последнем месте.
Я проработал в Amazon 3.5 года, и я бы не сказал, что мой опыт был ужастным.

Но, что же тянет рейтинг Amazon вниз?
В Amazon, в основном, такие же плюсы и минусы, как и в других фангах. Ожидания везде высокие, везде есть оценка перфоманса сотрудников, везде внутренние тулы и везде oncall. Но некоторые минусы или особенности, отражаются более негативно, по сравнению с другими фангами:

1) Amazon Leadership Principles. Во всех фангах есть ключевые ценности компании, слоганы и своя культура. Но нигде она так не форсится, как в Amazon. Эти Leadership Principles не просто слоганы, они реально используются в ежедневной работе. Они используются во время технических обсуждений, design review, code review, sev/coe review как реальные аргументы. По ним вас будут оценивать во время перфоманс ревью в конце года. По ним вам будут давать фидбек коллеги. Все это начинает напоминать какую-то секту или религию. И многие называют это промывкой мозгов. Что касается меня, то вначале все это было непривычно, было отторжение, но потом привык и даже начал считать все это, как имеющее вмысл. Если в них вдуматься, то они достаточно осмысленны и полезны.
2) Oncall. Все разрабы по очереди делают саппорт системы, которую они разрабатывают. В некоторых командах такой саппорт - это ночной кошмар. Вам приходится просыпаться посреди ночи и тушить пожары. Особенно, это характерно, для некоторых AWS команд. Многие не выдерживают такого режима и уходят. У меня такого не было в команде. Я за 3.5 года просыпался может быть раз 5 среди ночи и быстро делал рестарт или ролбек, если он автоматически не срабатывал, иногда быстрые конфиг изменения. А уже детальный поиск рут коза и починка была в обычное время. Поэтому, когда собеседуетесь в команду, спросите про oncall, если не спать всю неделю это не ваше.
3) Менеджеры. От менеджера зависит ваша оценка на перфоманс ревью очень сильно. Если вы испортите отношения с менеджером в Amazon, то это сделает вашу жизнь в компании очень короткой и неприятной. Это бывает редко, но все же случается. Я такое несколько раз видел за свою работу, опишу отдельными постами.
4) PIP. PIP - это performance improvement plan. Если вы получили плохую оценку перфоманса, или менеджер хочет от вас избавиться, то вам дадут сложный проект на ограниченный промежуток времени. Все будет документироваться. Если вы его не сделаете, то вас уволят. В Amazon, почти никто не выживает на pip. Люди просто используют эти пару месяцев для поиска работы. Поэтому его в шутку называют paid interview preparation. В других компаниях он тоже есть, но в Amazon и Facebook это чаще, чем в других компаниях. Раньше это было для ~5% в год, или что-то около этого. Сейчас не знаю, может больше. В Facebook раньше это было для 1-3% и половина его переживала. Сейчас в Facebook говорят про 10% в год и даже без pip. Многие называют это silent layoff. Опишу постами, истории, которые я знаю. Но на практике это мало заметно.

P.S. в Amazon есть и другие минусы, но часть из них связана с компенсацией, что в других компаниях можно больше получать, херовый vesting schedule, вам первые два года будут давать мало акций, меньше рефрешеров. Но я не оцениваю компенсацию. Также есть проблемы с промоушенами выше L5, но это в той или иной степени везде не так просто.

Какие плюсы в работе в Amazon?

Предыдущий пост может создать впечатление, что Amazon это худшее место на Земле для работы программистом: Почему Amazon имеет такие низкие оценки от сотрудников

Но это далеко не так. Он имеет множество плюсов. Многие плюсы такие же как и в других FAANG компаниях:
1) Высокие зп. Хоть Amazon платит меньше многих FAANG- компаний, но это все равно сильно выше рынка. Чтобы было понятно, я переведу на реалии российского рынка. Допустим в средней компании платят 300k рублей. Если бы Amazon был в России, то Amazon бы платил 500k. Хотя при этом какой нить Facebook платил бы 1 миллион.
2) Хорошая строчка в резюме. Наличие FAANG компании в резюме откроет дорогу для легкого попадания на собеседование в любую компанию, в том числе и другие фанги.
3) Умные коллеги. В FAANG компаниях средний уровень программистов сильно выше, чем в других компаниях. Если вы были лучшим в своей компании, то с большой вероятностью вы будете средним в Amazon. Это позволит вам многому научиться у многих коллег. Хотя, в том же Google или Facebook, уровень людей еще выше. И есть вероятность, что вы будучи лучшим в своей компании станете ниже среднего в Google. Но это хороший способ стать лучше.
4) Работа над масштабными и сложными проектами. В Amazon, как и в других фангах, масштаб многих проектов такой, которого нет нигде в мире. Практическая работа над такими проектами дает очень полезный опыт.
5) Стоки/акции. Как и в других фангах, существенная часть компенсации это акции, которые имеют тенденцию к быстрому росту. И за несколько лет работы в компаниии ваша зп может вырасти в разы, без промоушена.

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

Есть ли у Amazon плюсы, которые выделяют его среди других FAANG-компаний, а не только среди остальных компаний?

Да:
1) Культура инжиниринга. Тут очень сильная культура инжиниринга. Даже по сравнению с другими фангами. Тут очень серьезные code review, design review, coe(incident) review, oncall review. Тут огромное число различного типа тестов, с которыми вам придется работать, с большим, иногда идеальным процентом покрытия. Это: юнит тесты, интеграционные тесты, перфоманс тесты, лоад тесты, стресс тесты, canary release, shadow testing, хаос инжиниринг. Это различные решения для повышения релиабилити: circuit breaker, retry, rate limiting/throttling, auto-scaling. Невероятного масштаба и качества мониторинг системы. И много чего другого. До Amazon, мне казалось, что это такого не бывает. Что такое бывает только в книгах. А тут это обыденность. Можно подумать, что и в других фангах также. Но нет. В Facebook все заточено на скорость разработки (move fast). Культура инжиниринга тут хуже. Она частично компенсируется более высоким качеством разрабов, но все равно, вы тут многим вещам не научитесь, если до этого их не знали. Про Netflix я слышал примерно такую же историю. Там тоже очень мало чего тестируется на должном уровне. Такого же уровня культуру разработки вы скорее всего увидите только в Google.
2) Разнообразие проектов. В Netflix один основной продукт (хоть и много компонент и библиотек), в Facebook тоже продуктов не много. В Amazon это тонна разных продуктов AWS, это собственно Amazon, это Prime Video и тонна всего другого. Вы можете время от времени менять команду и работать над очень разнообразными задачами.
3) Ориентированность на процессы. Тут очень много процессов, которые так или иначе связанны с процессом и культурой разработки. Это все замедляет процесс, но вы можете многому научиться. Если вы любите процессы, то Amazon вам подойдет больше. В том же Facebook больше индивидуальной работы. Никаких процессов нет или они очень редуцированы. Все заточено на скорость разработки и того, что люди индивидуально суперзвезды. Они сразу будут писать быстро и правильно код. Никаких скрамов, спринтов, частых планингов или оценки задач тут нет. Тут как в анекдоте, дали пушку и крутись как хочешь. В конце полугодия мы сравним как ты накрутился по сравнению с другими такими же суперзвездами.

В продолжении темы резюме

Слышу много жалоб на то, что резюме постоянно реджектят.
Частично, это связано с общим состоянием рынка. Сейчас рынок труда уже не тот, что был в 2021.
Но по сравнению с состоянием рынка в 2023 сейчас сильно лучше.
В Линкедине часто вижу, как кто-то постит резюме. Там не вооруженным глазом видны слабости резюме. Я уже о них писал ранее. Это и моменты связанные с оформлением (плохо парсится, длинное, много лишней информации, сайдбары, фотографии, вордарты). Но, основное, это конечно, содержание.
90+% процентов упорно продолжают писать должностные обязанности (писал код, ревьюил код, диплоил код), вместо решенных задач и достижений. Ну офигеть, а мы то думали, что программисты компьютеры чинят.
Иногда, пытаются писать достижения, но достижение заключается в том, что человек использовал какую технологию. Иногда еще пытаются подогнать это под требуемый стек в вакансии.
Достижение, вроде, написал код на Spring Boot, или использовал git и задеплоил при помощи docker - это не достижение. Это перечисление тех стека. Название технологий можно вплетать в текст, но это не самоцель. Нужно писать какую бизнес задачу вы решили. К какому результату это привело. Почему это было сложно. Что именно сделали вы (вот тут можно вплетать название технологий).
На другом конце спектра достижения, которые концентрируются только на решенной бизнес задаче. Без указания собственной роли, технической сложности и технического метода решения.
Вроде, увеличил продажи на 10%. Тут не понятно, как именно. В чем была техническая сложность задачи. Какая была во всем этом ваша роль.
Изучайте метод STAR, набросайте основные положения и если не можете сами это красиво сформулировать, скормите входные данные ChatGPT. Он как раз хорошо с текстами работает.

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

Неоднозначность в тайтлах выше Senior

Недавно собеседовал кандидата из Microsoft. Его текущий тайтл это Principal Software Engineer в Microsoft. Собеседовали его на позицию E6/L6/Staff Software Engineer. Он завалил кодинг, а на систем дизайнах и поведенческом его опредили как соответствующего E5/L5/Senior. Т.е. проекты и задачи, над которыми он работает не соответствуют уровню Staff Software Engineer.
Это все, потому что нет универсальной шкалы для уровней. В Microsoft после Senior сразу идет Principal. Что во многих компаниях соответствует Staff или TL(Tech Lead). Поэтому Principal Principal'у рознь. В некоторых компаниях это тех лид команды из 8 человек, а в некоторых это разработчик который оперирует на уровне организации в 200-300 человек и репортит VP компании.

На сколько я напрограммировал в 2023.

Недавно отчитывался перед налоговой за 2023 год.

Доход за год:
£383k/$501k/48 миллионов рублей

Доход за год, после вычета налогов:
£218k/$285k/27 миллионов рублей

Доход в месяц на руки, после вычета налогов:
£18k/$23k/2.25 миллиона рублей

Разбор резюме подписчика

Подписчик прислал резюме. Я, кратко, посмотрел. Мысли набросал тут: https://dev.to/faangmaster/razbor-rieziumie-podpischika-2acf

Резюме хорошее. Есть несколько замечаний по отсутствию summary, сильно большой секции Education для опытного программиста, порядку разделов в резюме. В резюме описано много достижений. Но во многих не хватает описание роли владельца резюме (или хорошо бы ее расширить для показаная синьерности), импакта задачи, зачем это было нужно. Для роли Middle можно ограничиться Implemented, Created или Developed, в качестве роли. Если есть достижения, где вы играли большую роль, то лучше это написать, это нужно для ролей Senior+. Led/Drove/Identified/Came up with an initiative/idea/ in a collaboration with...
Я часто задаю вопрос, зачем, к достижениям, потому что не ясен импакт. Вот вы что-то implemented, но не ясны бенефиты от этого. Добавьте, например, resulted in reduction/improvement/increase .... by x%.
Но это уже лучше, чем I was responsible for coding, code review and deployment. Достижения описаны, местами не хватает одного или пары пунктов из STAR, или если можно расширить свою роль для более синьерных позиций, а не только implemented/created.

Conflict Resolution

На поведенческом собеседовании в FAANG компании очень часто можно встретить вопросы вроде:

1) Tell me about a time you had a conflict with your manager.
2) Tell me about a time you had a conflict at work.
3) Tell me about a time you had a disagreement with someone.

Такие вопросы часто спрашивают в Facebook (Meta) для оценки Conflict Resolution, а также в Amazon при оценке Amazon Leadership Principle - Have Backbone; Disagree and Commit.

Junior-Senior кандидаты из СНГ, да и Staff тоже, очень частно заваливаются на этом вопросе. Это, очень часто, служит причиной получения офера на более низкий уровень или реджекта.

Казалось бы, какой-то бессмысленный HR-вопрос. Но поработав в FAANG более 7 лет я понял, что этот навык супер важный. Не только на собеседовании, а в ежедневной работе. Особенно, с ростом вашего левела.

Кандидаты из СНГ очень часто получают Red Flags и получают reject или down level.
Типичные Red Flags:
1) У меня никогда не было конфликтов. Это просто вранье. Конфликты на работе программиста встречаются почти каждый день. Это не конфликты по типу гопстопа или ты меня уважаешь, а конфликты по вопросам связанным с вашей работой. Это несогласия по время code review, design review, разные мнения и подходы у разных людей к той или иной проблеме. Разные мнения по поводу приоритета той или иной задачи, проекта и т.д. Конфликты возникают как между коллегами в рамках одной команды, так и разногласия между командами, отделами или даже внешними компаниями-партнерами или клиентами. Если у вас не было конфликтов - вы никогда не работали программистом. Или же вы всегда решали их двумя плохими способами: избеганием или продавливанием своего мнения.
2) У меня был конфликт X, и в итоге он решился тем, что я доказал, что я прав, а все другие не правы. Даже если такие случаи были, то это плохой пример. Вы должны обосновывать свою позицию, но должны слышать и другую сторону, а не силой пытаться ее продавить. Если у вас только такие примеры, то скорее всего большинство таких примеров, когда вторая сторона просто забила и прогнулась, для нее это не было приоритетом или у вас было больше власти, сил и желания это продавить. И скорее всего, в итоге часть таких решений были неоптимальными.
3) У меня был конфликт X, в итоге я, просто, проигнорировал и избежал конфронтации и все как-то само решилось. Конфликт на работе это не обязательно что-то плохое. Игнорирование конфликта на работе приводит к накоплению противоречий между сторонами, ухудшению collaboration, а как следствие к ухудшению эффективности организации. При правильном подходе можно найти лучшее решение, чем форсила каждая из сторон конфликта. В таком случае выигрывают все - win-win Conflict Resolution.
4) Вы не использовали данные, в конфликтах. Иногда причина конфликта - это нехватка данных и неверные предположения сторон. В таких случаях можно отложить resolution конфликта, сделать сбор данных и собраться снова и найти win-win resolution.

Не критические, но отрицательные сигналы:
1) У нас был конфликт X, и мы нашли компромисс. Это скорее всего означает, что каждая из сторон немного прогнулась, и осталась немного недовольной. Каждая из сторон просто пошла на уступки, не пытаясь найти какое-то новое, более лучшее решение, которое бы удовлетворила все валидные требования и приоритеты каждой из сторон. Обычно, это от лени и безразличия или свойства психики по избежанию конфликтов. Часто это приводит к неоптимальными решениям.
2) У нас был конфликт X, я полностью признал, что я не прав и сделал так, как сказали, не протестуя. Такое бывает, но это не оптимальный пример для собеседования. Если вы попытались возразить и уже в обсуждение поняли, что были не правы - то это хорошее поведение. Но не лучший пример для собеседования. Лучше подойдут примеры win-win. А если вы не пытались возразить, то скорее всего в итоге было получено неоптимальное решение.

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

Как это можно сделать?
1) Не отрицать конфликт, признать что он есть, обозначить вовлеченные стороны и позиции.
2) Собраться, выслушать другую сторону. Выслушать нужно очень внимательно. Если вовлечены эмоции, то признать право человека на эмоции и попытаться их понять. Проявить эмпатию.
3) Попытаться поставить себя на место другой стороны, чтобы более четко понимать позицию и эмоции другой стороны.
4) Активно слушать, стараться понять в деталях позицию, приоритеты стороны и причины такой позиции.
5) Спросить, как вы видите решение проблемы?
6) Донести свою позицию и ее причины.
7) Будьте открытыми для альтернативных точек зрения, признания, что можете чего-то не знать или заблуждаться. Но нельзя соглашаться на все, просто, чтобы избежать конфликта. Концентрируйтесь на том, чтобы найти правильное и лучшее решение, чем было у каждой из сторон на момент начала конфликта.
8) Установите common ground и общие цели. Обычно, вы можете установить что-то общее. Очень часто у вас будет много общих целей и задач. В конечном счете, вы хотите решить одну и туже проблему, просто разными способами.
9) Если после обсуждения вы можете устранить сразу какие-то неверные предпосылки и решения, которые не были понятны до обсуждения, то сделайте это (например, вы чего-то не знали и узнали во время обсуждения или знали неверно, и теперь вы можете изменить свою точку зрения). Это сократит число concerns и противоречий между сторонами
10) Если для решения оставшихся разногласий нужно больше данных - сделайте паузу на сбор и анализ данных
11) найдите новое, альтернативное решение, которое удовлетворит оставшиеся концерны обоих сторон (win-win).
12) Опишите и задокументируйте достигнутое решение. В будущем вы можете на него ссылаться.

Вообще, это большая тема. Можете начать ее изучать с википедии: Conflict resolution

Изобразил это в виде картинки. Пишите, что об этом думайте.

Нобелевскую премию по химии в 2024 году получил сотрудник Google

Дэмис Хассабис получил Нобелевскую премию по химии 2024 года.

Он co-founder DeepMind, которая теперь часть Google.

Он один из создателей AlphaFold, которая предсказывает структуру белка.

Увидел вот такой пост в линкедине. В заголовке у него была еще картинка FAANG.
Если в кратце, то он говорит, что он прошел все раунды собеседования, но получил реджект. И по его мнению, это некий новый феномен - ghost hiring. Т.е. собеседования только для метрик, без реального найма.
Я собеседую 2-3 раза в неделю и участвую в дебрифах, где принимается решение о найме. Такого ниразу не было за более чем 7 лет моей работы в разных FAAANG компаниях.
Мне интересна самоуверенность автора поста, что он прошел все раунды. Самостоятельно, после интервью, можно быть более или менее уверенным в coding раундах. Вы можете проверить, правильно ли вы решили, правильно ли протестили. Но даже так, может быть недостаточным communication.
А про system design и поведенческое быть уверенным, не зная реального фидбека, сложно. Вы можете получить много red flags, не зная о них, просто потому что вы так думали и действовали всегда, а это ред флаги для компании. Или же вы их прошли успешно, но по результатам ваш уровень ниже, чем тот на который вы собеседуетесь, а позиции на уровень ниже нет.
Иногда, даже успешных кандидатов, помещают в очередь ожидания, т.к. в моменте исчезли такие позиции. Но об этом вам сообщат, что вы в очереди ожидания или больше таких позиций нет.
Недавно собеседовали кандидата на позицию Staff, он на поведенческом рассказывал, что он во всех конфликтах побеждал, потому что все вокруг глупые, особенно, коллеги женщины. Я думаю, он был уверен, что прошел. Да и по system design он был оценен на уровень ниже.