Женя Янченко

Давай разберем шаги на примере Яндекс OAuth для логина пользователей в другом приложении. Вообще по правилам OpenID Connect все сделано у Google, но поскольку на практике сейчас скорее всего столкнемся с интеграцией с Яндексом, решила рассмотреть его флоу. 1️⃣ Пользователь в браузере открывает PetApp и нажимает кнопку: «Войти с Яндекс ID» 2️⃣ PetApp перенаправляет пользователя на страницу Яндекс OAuth. Для этого используется запрос на эндпойнт /authorize Яндекса: https://oauth.yandex.ru/authorize? response_type=code &client_id=pet-app &redirect_uri=https://pet.app.ru/oauth/callback &scope=login:info%20login:email response_type=code означает, что PetApp просит вернуть ему код подтверждения для дальнейшего получения токена client_id=pet-app — PetApp ранее зарегистрировался в Яндекс OAuth, получил идентификатор клиента и теперь передает его в запросе. Остальные параметры в случае Яндекс OAuth необязательны, они могут браться из профиля клиента PetApp, но покажу основные: redirect_uri — URL, на который Яндекс перенаправит пользователя после того, как тот разрешит PetApp доступ. scope — это как раз запрашиваемые права В доке Яндекс ID основной сценарий описан как OAuth 2.0, поэтому здесь запрашиваются просто права из списка: login:info login:email. Если бы использовался протокол OIDC (как у Google, например), то мы бы передали в scope слово openid и запрашиваемые данные: scope=openid profile email 3️⃣ Яндекс показывает страницу логина и возможно запрос разрешений 4️⃣ После успешного логина Яндекс редиректит обратно в PetApp на тот самый redirect_uri 5️⃣ Этот запрос принимает PetApp (обычно его бэк, но зависит от реализации), в нем он получает код подтверждения: code=SOME_AUTH_CODE 6️⃣ Получив код авторизации, PetApp отправляет POST запрос в Яндекс на эндпойнт /token с только что полученным кодом SOME_AUTH_CODE 7️⃣ Яндекс возвращает access-токен и refresh-токен. В случае OIDC обычно возвращается еще id_token с данными пользователя. Яндекс ID не возвращает id_token, у них для получения данных пользователя нужно использовать отдельный запрос на /info с access-токеном. 8️⃣ Приложение PetApp отправляет запрос на /info с access-токеном, находит или создает внутреннюю учетку для этого пользователя и связывает ее с аккаунтом Яндекса. После этого PetApp уже создает свою сессию для пользователя: например, выдает собственную cookie/JWT и дальше работает с пользователем как со своей внутренней учетной записью. ✏️ Таким образом OAuth 2.0 выделяет основные эндпойнты: 🔴Authorization Endpoint — нужен, чтобы отправить пользователя на сервер авторизации и вернуть приложению-клиенту код авторизации. 🔴Token Endpoint — нужен, чтобы обменять код авторизации на access-токен. 🔴В OIDC в ответе от /token добавляется еще id_token и UserInfo Endpoint — для получения данных профиля пользователя. Пример апишки провайдера можно посмотреть в доке Яндекс OAuth или VK ID или Google (повторюсь, у них как раз есть OpenID Connect). OAuth 2.0 / OpenID Connect используется не только для работы с публичными провайдерами, но и для внутрикорпоративного доступа. В качестве внутрикорпоративного провайдера может выступать например Keycloak. Keycloak — настоящий OpenID Connect Provider. У него есть все нужные эндпойнты (authorization endpoint, token endpoint, userinfo endpoint) плюс обычно он отвечает сразу за группы, роли, права, и в access-токен сразу может вкладывать группы и роли пользователя, которые затем будут анализироваться разными внутренними приложениями для определения того, что разрешено этому пользователю. Ещё у меня был пост про организацию доступа с помощью access и refresh токенов. Чтобы не перегружать пост, я совсем не затронула тему безопасности и специальных параметров, которые передаются в запросах OAuth 2.0 для верификации участников. Поставьте 🦆, если нужно это разобрать в отдельном посте. Сталкивались ли вы с вопросами по OAuth 2.0 / OIDC на собесах или с реализацией на практике?

Сегодня технический #женя_есть_вопрос Привет, с некоторых пор работаю системным аналитиком и вроде всё хорошо, но в последний раз на собеседованиях посыпалась на теме Oauth 2.0, вроде рассказала какую-то базу, но кажется человек, который меня собеседовал не то хотел услышать, можешь пожалуйста рассказать что требуется знать по этой теме или что почитать толкового и понятного, что надо знать про flow, и про связь OAuth 2.0 и OpenID Connect, я рассказала, что OpenID Connect — протокол аутентификации, потому что я так про это и читала в нескольких источниках, но кажется явно что-то не понимаю. Привет! Ты все верно сказала про авторизацию и аутентификацию. Сложно, конечно, судить, что хотел услышать конкретный собеседующий, возможно про разницу OAuth 2.0 и OpenID Connect, но скорее подробно про флоу, что ты понимаешь, как это устроено. OAuth 2.0 — это фреймворк авторизации. Он отвечает на вопрос: "Можно ли этому приложению получить доступ к ресурсу от имени пользователя?" То есть результатом работы OAuth 2.0 является выдача токена доступа. OpenID Connect (OIDC) — это надстройка над OAuth 2.0 для аутентификации. То есть OIDC использует OAuth 2.0 flow, но добавляет выдачу id_token — токена аутентификации, с помощью которого можно узнать, кто этот пользователь (и отдельно получить данные его профиля). Представь, что ты разрабатываешь приложение для доставки корма домашним животным и хочешь добавить возможность пользователям подключать свой Яндекс.Календарь, чтобы твое приложение могло затянуть из него даты покупки корма. Плохой вариант: предложить пользователю ввести у тебя в приложении логин и пароль от Яндекса, а твое приложение сходит с ними в Календарь. Тут и пользователь не согласится и вообще опасно: это же полный доступ к акку пользователя. OAuth 2.0 решает это так: Пользователь логинится в Яндексе Яндекс спрашивает: «Разрешить PetApp читать календарь?» Пользователь соглашается. Яндекс выдает PetApp специальный токен доступа. PetApp ходит с этим токеном в Яндекс Календарь API, при этом PetApp не получает пароль пользователя. 🐼 В OAuth 2.0 выделяют следующие роли: 🔴Resource Owner — владелец ресурса, обычно это пользователь. Например: Олег, владелец Яндекс.Календаря и пользователь PetApp. 🔴Client — приложение, которое хочет получить доступ. В нашем примере это PetApp 🔴Authorization Server — сервер, который умеет логинить пользователя и выдавать токены. Например: Яндекс OAuth 🔴Resource Server — API, к которому нужен доступ. В примере это Яндекс.Календарь Олега. Когда PetApp нужно просто разрешение читать календарь пользователя, достаточно OAuth 2.0. Но если мы хотим, чтобы пользователи логинились в нашем PetApp через учетку другого сервиса (кнопка "Войти через Google"), то обычно для этого используют OIDC, чтобы получить еще данные пользователя. То есть с точки зрения пользователя: OAuth 2.0 — это «Дай приложению PetApp доступ к моим данным» OpenID Connect — это «Войди в приложение PetApp через мой аккаунт» Но некоторые провайдеры (например, Яндекс) реализуют логин через внешний аккаунт не через протокол OpenID Connect, а через OAuth 2.0 + отдельный эндпойнт получения данных пользователя ⬇️

Порядок сообщений, DLQ, graceful shutdown, spike нагрузки — на каждый вопрос есть минимум два рабочих ответа📎 Витя Михайлов, Backend Lead Garage Eight, и Женя Янченко, руководитель разработки и автор канала @jane_yanchenko, разложили по полочкам карточкам 5 вопросов про брокеры со стороны RabbitMQ и Kafka соответственно. Все ответы перед тобой, а разбор последнего ждет в комментариях ;-) #GarageEight_разработчикам

В последнее время я много писала про Кафку, и ко мне пришли из компании Garage Eight с предложением совместного поста. Вот что у нас получилось ⬇️

В субботу ходила на «Сезон кода» — летнее мероприятие Т-Банка. Правда, я опять прошляпила запись на экскурсию по офису, так что не смогу показать вам его фотки( UPD. Фото уже выложили в комментах 🔥 Прошлый раз мне очень понравилось, так кроме докладов было много прикольных игр на стендах. В этот раз было целых три потока докладов, но учитывая, что это был первый по-настоящему солнечный день после долгого перерыва, я решила часть времени просто почиллить в гамаке у воды 🏖 Сходила на два доклада: 🟡 Про подходы к обновлению конфигурации от Кати Липониной из Т-Банка. О чем доклад: у микросервисов есть конфигурация (хосты, пароли, настройки, feature-флаги и т.д.). Конфигурация обычно хранится отдельно от кода. Когда в конфигурации происходят какие-то изменения, нужно, чтобы сервисы подхватили эти изменения. Сначала Катя напомнила теоретические подходы, потом рассказала про то, как они реализовали это в своей распределенной системе с учетом требований к согласованности. Очень бодрый доклад, мне понравился! 🟡 Хардкорный доклад по JVM от Владимира Воскресенского из Сбера. Очень крутой доклад про то, как «под капотом» работает Java, похожий на доклады Алексея Шипилёва. Владимир рассказал, что такое прогрев, какие JIT компиляторы есть в JVM, наглядно показал разницу в скорости выполнения кода интерпретатором и двумя JIT-компиляторами. Я чувствовала себя прямо как на интересной лекции в университете. Пообщалась на стенде про инженерные метрики. В Т-Банке собирают огромное количество метрик разработки (время до мерджа, время до деплоя на прод, степень сложности кода, использование ИИ и др.) Вот что показалось мне наиболее интересным и перекликающимся с моим опытом: ➡️ Lead time (время от коммита фичи до деплоя на прод) мало зависит от ИИ, намного больше зависит от процессов: использование ИИ увеличивает throughput задач, то есть разрабы начинают генерить больше кода. Но вот чтобы дальше этот код быстрее доставлять на прод нужно работать с процессами. И это 100% жиза, я большой фанат организации процессов и знаю на практике, как они влияют на скорость доставки и состояние команды. ➡️ На основании данных корпоративного мессенджера они построили social graph, с помощью которого определили центр знаний, то есть к кому приходит больше всего вопросов. Угадайте, кто это? Ответ: бэкендеры Ну, как бэкендер, я не удивлена 😂 ➡️ ИИ часто используют там, где запутанный сервис. Тоже кажется логично. Когда это твой сервис от и до, ты сам выстроил архитектуру в нем и написал львиную долю кода, то дописать в нем новую фичу — чистое удовольствие. Когда это чей-то чужой запутанный сервис, пусть электронный мозг разбирается 😂 ➡️ Качество кода в тех репозиториях, где активно используется ИИ, не упало. Потому что ребята ревьюят то, что написал ИИ. Еще познакомилась и очень приятно пообщалась с devops-инженером из компании YADRO. Рассказал, что у них активный найм уже довольно продолжительное время, плюс берут студентов-стажеров. Возможно, вам есть кому это рассказать) Кормили вкусно, вообще организация мероприятия на высшем уровне. Рада, что сходила 😊 Если были тоже, поделитесь впечатлениями в комментах. В комментах выложу задания A/B тестов с одного из стендов: два экрана приложения, надо предположить, было ли улучшение конверсии в варианте Б. Я нифига не продуктовый аналитик, ошиблась в двух случаях из трех 😃

Привет. Очень сочувствую, что ты сейчас в такой ситуации. Согласна, что в 2020-2023 был тот самый "рынок соискателя", найти работу было легче, многие знакомые находили без накрутки. Сейчас ситуация с поиском ощутимо сложнее. Давай обсудим несколько вариантов. ➡️ Первый: найти любую официальную работу разработчиком. Как ты и сказал, в большинстве крупных компаний сейчас проверяют трудовую. Но есть компании, где этого все еще не делают. Опыт у тебя есть, пусть он без оформления, но работу ты делал и про свои задачи и победы рассказать сможешь. Тимлид, с которым ты будешь общаться, увидит, что ты решал реальные проблемы. Если идешь этим путем, то на hh нужно бить по площадям: делай резюме со стеком и достижениями, пиши там то количество опыта, которое считаешь нужным, и откликайся на все вакансии. Не на 20-30 штук, а на все. Лимит откликов на hh — 200 в сутки. Часть компаний сразу откажет, многие попросят трудовую, но останутся те, которые позовут на собес. Даже если проект окажется не очень, поработаешь там полгода-год, получишь опыт новых задач и найдешь вариант лучше. Через 2-3 итерации уже будешь в команде мечты. ➡️ Второй: "в хорошую команду под своим именем без накрутки опыта". Дело в том, что до бума 2020-го года не-студенту без опыта тоже было довольно трудно найти первую работу разрабом, особенно в регионах. Знаю это на собственном опыте: я перешла в разработчики из менеджеров проектов еще до 2020. Поэтому я бы предложила рассмотреть путь с оффлайном. Крупные компании часто проводят мероприятия, где можно пообщаться с разрабами и с HR. Особенно подойдут хакатоны, их устраивают в том числе чтобы присмотреть себе талантливых сотрудников. Если ты не в Мск/Спб/Екб, это тоже работает, есть местные митапы. Знаю, что некоторые этот способ хейтят, но я работу разработчиком так и нашла: пошла на мероприятие для студентов (не будучи студентом), там подошла пообщалась к HR, и меня позвали на собес. Не на сеньора, конечно, а на джуна, но позвали же. Потом на других мероприятиях я так же знакомилась с HR и обменивалась контактами. Конечно, скорее всего придется сделать несколько попыток, но одна из них может оказаться успешной. Также у крупных компаний бывает целенаправленный найм джунов. Главное — узнать об этом (из соцсетей компаний, от знакомых) и успеть податься. Активно общайся со всеми знакомыми из ИТ и регулярно узнавай новости про найм в их компании. Учитывая твой опыт с профилированием, анализом heap dump и др. мне прямо хочется рекомендовать тебе сходить в Т-Банк, потому что они любили такое на собесах у джавистов спрашивать. У них много мероприятий (например, завтра иду на "Сезон кода" в Питере). Но трудовую они проверяют, поэтому нужно с HR пообщаться про вакансии для начинающих. Если ты живешь в регионе, можно посмотреть на hh, у каких местных компаний есть вакансии, и прийти к ним в офис. Да, может быть неловко, могут отправить писать на почту, а можно и пообщаться с HR и потом попасть на собес к техлиду. ➡️ Третий: получить профильное образование. Тебе всего 26 лет. Если ты еще не заканчивал магистратуру, можно рассмотреть поступление по ИТ-специальности, чтобы официально быть студентом и участвовать в программах для студентов. Увы, нет простого пути, когда у тебя мало опыта. Но я знаю примеры, когда люди устраивались благодаря упорству и настойчивости. Обычно первым местом не была компания мечты, но уже второе/третье — то, которое хотелось. Уверена, что у тебя получится устроиться, если задействуешь все способы. Ребят, что порекомендуете в такой ситуации?

Сегодня новый #женя_есть_вопрос В этой рубрике обычно обсуждаем рабочие ситуации и карьерные вопросы, но иногда бывают и технические. 📍Задать свой анонинимый вопрос можно тут: https://forms.gle/SPE6NEALG9vcnF3s7 Привет, Женя! Мне 26 лет. Мучает тема накрутки и интересно узнать твое мнение и мнение из комментариев к ответу в последующем:) Я попал на проект через шадоу-мод на позицию синьора. Да, это плохо, обман итд, но мне это было нужно, жизненная ситуация. Первый месяц мне было трудно из-за того, что впервые вникал в айтишные процессы и одновременно в бизнес-логику проекта. Но потом примерно через два месяца все сильно поменялось. Постепенно помимо закрытия своих задач, я начал находить серьезные баги в проекте (с sql-запросами в цикле, многопоточкой, с транзакциями). Начал видеть архитектурные проблемы. Я спорил с синьорами из команды, объясняя им почему многопоточный код, который они написали, некорректен и что он будет ломаться под нагрузкой. К тому же я профилировал сервисы на проде через JFR(искал тормоза), читал heap dump после падения сервиса по ООМ и исправлял утечки памяти и еще много чего другого, что джуны обычно, наверное, не делают на старте карьеры. Тут важно обозначить, что я вышел на работу не после курса от гикбрейнс через полгода. Я посвятил активному обучению 2 с половиной года: проходил джавараш (все 50 уровней), читал чистый код/архитектуру, Java Concurrency), по сетям, по операционным системам итд, писал пет проекты. И все 2 с половиной года я занимался не по пару часов в день, а практически каждый день почти все свободное от работы время. Это только Java и ее экосистема. У меня и до джавы есть бэкграунд с программированием и не только. Но когда я вышел на рынок, то обнаружил, что не могу устроиться на работу джуном и расти потихонечку. Практически всем компаниям нужен минимум мидл. Тогда через некий промежуток времени я догадался, что не пройду через фильтры и накрутил опыт, чтобы пробиться. И даже после накрутки я обнаружил, что не могу попасть на собеседование, где смог бы рассказать о своих знаниях и навыках(настоящих, без обмана). Даже когда удается выйти в личку с рекрутером, то получаешь вопрос с ходу "а в трудовой опыт зафиксирован"? Да, у меня нет опыта в трудовой, и, что уж тут, даже незафиксированный мой опыт - около полугода. Но у меня есть настоящие крепкие знания и навыки, которые уже сравнимы с некоторыми синьорами "на бумаге". Я очень пробивной в плане изучения чего-то нового в технологиях, довольно легко разбираюсь в чем бы то ни было, стараюсь инженерно мыслить, а не просто крудошлепить. Умею общаться с людьми, никогда не инициирую конфликты. Но мне закрыт путь в хорошую команду под своим именем без накрутки опыта и без страха, что легенду раскроют. Как будто бы, в нынешних условиях я могу найти работу только если наткнусь на рекрутера, который не попросит трудовую. Как быть в таких условиях рынка? Как пробиться через "нужен опыт в трудовой"? Пару лет назад нужно было всего-то решиться накрутить опыт и гладко рассказать легенду, трудовую почти не спрашивали, насколько мне известно. А сейчас повально просят трудовую и ГПХ с ИП уже не прокатывают. Есть ли реальные способы пробиться и попасть в команду с реальной оценкой инженерных компетенций, а не через подсчет количества лет опыта в трудовой? Сори за полотно, крик души:))

Идемпотентный консьюмер В постах про Кафку я упоминала, что консьюмер может повторно получить и обработать одно и то же сообщение (и это не баг), поэтому обработку лучше делать идемпотентной. Идемпотентность означает, что многократное повторение операции даст тот же эффект, что и однократное. Предлагаю обсудить чуть детальнее, как сделать обработку идемпотентной. ➡️ Сначала я бы посмотрела на характер сообщений: возможно, сообщения уже обладают "встроенной идемпотентностью", потому что содержат актуальное состояние, а не действие. Например, текущее количество бонусных баллов у пользователя: { "userId": "1", "bonusBalance": 5000 } Если консьюмер обработает такое сообщение дважды и дважды выполнит SET bonus_balance = 5000, то итоговое состояние останется тем же: 5000 бонусов. Можно провести аналогию с HTTP-методом PUT: повтор одного и того же запроса должен приводить к тому же целевому состоянию ресурса. ✔️ Для снапшотов важен порядок: нельзя после нового состояния применять старое. Поэтому к таким сообщениям лучше добавлять поле version и обновлять состояние только если версия из сообщения новее текущей версии в БД: { "userId": "1", "bonusBalance": 5000, "version": 2 } ➡️ Другое дело, если сообщение несет информацию о каком-то событии, например, начисление бонусов: { "userId": "1", "operationType": "CREDIT", "amount": 1000 } Смысл события: начислить пользователю 1000 бонусов. Если обработать его дважды, то пользователь получит 2000 бонусов вместо 1000. Для таких сообщений сделать обработку идемпотентной нам поможет дедупликация, то есть фильтр дублей. Для её реализации обычно используют уникальный идентификатор messageId/eventId. По смыслу это похоже на Idempotency-Key в REST-запросах. Уникальный идентификатор может быть бизнесовым (например, идентификатор платежа) или техническим (специально сгенерирован на продюсере или до него для дедупликации). Однажды в качестве ключа идемпотентности мы взяли комбинацию трех бизнес-полей. Аналитики пообщались с бизнесом, со смежниками, всё выглядело логично. А потом уже в процессе эксплуатации выяснилось, что в одном специфическом случае такая же комбинация полей повторяется у связанной сущности. Для нашей логики это были разные сущности, и ключ перестал подходить. Попросили ребят на передающей стороне генерировать для нас технический айдишник. ✔️ Это важный момент на этапе проектирования интеграции: что именно мы защищаем от дублей? Если важно не обработать дважды конкретное сообщение, подойдет технический messageId от продюсера. Если важно не создать второй платеж, то нужен paymentId из системы-источника. Теперь, когда у нас есть уникальный идентификатор, мы можем фильтровать дубли сообщений. Например, поле operationId является ключом уникальности. 🔴Если обработка сводится к вставке записи в одну таблицу БД, можно сделать дедупликацию так: ✅ добавить индекс уникальности на поле operation_id, содержащее ключ идемпотентности ✅ при добавлении записи если такой operation_id уже есть, то ничего не делать (INSERT INTO ... ON CONFLICT DO NOTHING) 🔴Если кроме вставки в таблицу с operation_id, нужны изменения в других таблицах, то делаем всё в одной транзакции. Общая схема: 1. Консьюмер получил сообщение из Кафки 2. Открываем транзакцию 3. Пытаемся вставить запись с operation_id 4. Если вставка прошла, значит это первое получение сообщения, выполняем бизнес-логику. Если получили конфликт уникальности — это дубль, бизнес-логику пропускаем. 5. Коммитим транзакцию БД 6. После этого коммитим оффсет в Кафку ⚡️ Важно! Если бизнес-логика долгая, например, включает в себя большие расчеты, отправку запросов в другие сервисы и тому подобное, то не нужно ее выполнять тут же до коммита оффсета. При стандартных настройках если консьюмер долго не запрашивает новые сообщения, его выгонят из консьюмер группы, и партицию могут отдать другому консьюмеру (история про захлебнувшихся консьюмеров). В случае долгой обработки лучше просто сохранить сообщение, закоммитить оффсет, а саму обработку выполнить отдельным процессом. Такой подход называют inbox pattern.

Привет! Это просто жиза на 100% 💋 Ты не одна, очень много людей сталкиваются со стрессом на собесе от лайвкодинга, и я в их числе. Сначала хочу сказать про коллегу: фраза "Ты меня пугаешь, почему ты тупишь на элементарных вещах" мягко говоря очень неприятная. Неудивительно, что она тебя расстроила и усилила тревогу. Так нельзя говорить людям! Да мало ли, что у человека случилось перед вашим созвоном. Даже если ты лид, и в твои обязанности входит оценка сотрудников, это не дает права на такие комментарии. В конце концов зарплату платят за решение задач бизнеса и рабочий код в продакшене, а не за лайвкодинг на созвонах. Теперь про собесы. Ты права, традиционно рекомендуют проходить побольше собесов, отложив "компании мечты" напоследок, тогда натренируешься, и страх уйдет. Но мне не очень нравится этот совет, потому что это сколько переживаний придется натерпеться на реальных собесах, пока страх уйдет? Поэтому предложу другие техники. На самом собесе: ➡️ Перед тем, как писать код, порассуждать На рассуждение "раскачаться" проще и быстрее. Рассуждения всегда ценились на лайвкодинге. А сейчас некоторые интервьюеры просят очень подробно рассказать алгоритм еще до написания кода: что, почему, какой результат будет на каждом из шагов итерации. Скорее всего в целях защиты от читерства, да и посмотреть на ход мыслей. Когда пишешь сам код, тоже можно комментировать, что именно ты делаешь, это может помочь и тебе снизить нервозность и интервьеру увидеть, что ты не списываешь. ➡️ Разрешить себе писать "по-джунски" Есть понятие production-ready кода. Когда я только начинала работать, я не понимала, что это значит, но потом с опытом осознала: код чаще читают, чем пишут, фичи развивают, поэтому привыкаем писать так, чтобы было легче читать, поддерживать, траблшутить. Но на собесе мысли типа "надо написать не просто рабочее решение, а красивое, сеньорное" будут только добавлять стресса. Полностью нормально написать сначала "страшненький" код, а потом улучшить его. Можно так и прокомментировать: — Немного нервничаю, так что пока напишу "в лоб", потом улучшу — Немного волнуюсь, так что сейчас напишу псевдокод, потом переведу в код — Синтаксис уточню, но идея такая... Подготовка к собесу: ➡️ Записать на листик твой алгоритм действий на лайвкодинге и прикрепить его у монитора. Причем добавить туда шаги рассуждения вслух. Например: 1. Читаю задачу 2. Задаю интервьюеру уточняющие вопросы, чтобы убедиться, что я правильно поняла задачу 3. Придумываю самое простое брутфорс решение и сразу его озвучиваю 4. Озвучиваю недостатки этого решения 5. Предлагаю вариант лучше 6. Спрашиваю у интервьюера, ок ли реализовывать этот вариант 7. Уточняю граничные случаи ... N-2. Прохожу по коду, проговаривая что тут происходит и проверяя логику N-1. Беру пример и прохожу по коду с конкретными значениями переменных, как бы дебажу его в голове Шаги у тебя могут отличаться, тут важно, чтобы в момент стресса ты не думала "что делать, а если я не смогу написать", а смотрела в этот листик и делала только конкретный шаг. Определенность снижает тревогу. ➡️ Потренироваться на мок-собесах Тут тоже можно двигаться поэтапно: 1️⃣ Включать запись экрана и вслух решать задачи 2️⃣ Решать на созвоне с другом (даже если он вообще не из ИТ). Скидываешь ему заранее пул задач, вы созваниваетесь (лучше с камерой), он дает тебе задачу из пула. Ты смотришь на свой алгоритм, который мы составили на предыдущем шаге, и движешься по нему. Друг просто слушает и смотрит. 3️⃣ Мок-интервью с другом из ИТ, где он сыграет роль интервьюера: будет задавать вопросы, отвечать на твои. 4️⃣ Мок-интервью за деньги с ребятами из 🌎, 📦 и др. Комбинация списка шагов и тренировок с наблюдателями поможет наработать навык. На реальном собесе волнение останется, и это нормально. Но благодаря навыку и списку ты будешь знать, что делать и чувствовать себя увереннее ❤️ 📍Задать свой анонинимый вопрос можно тут: https://forms.gle/SPE6NEALG9vcnF3s7

Всем отличных длинных выходных! Вчера написала ответ на новый #женя_есть_вопрос и решила не откладывать, а опубликовать несмотря на нерабочую пятницу :) Женя, здравствуйте! Недавно здесь задавали вопрос про собеседования, поэтому я тоже решила написать, как раз в тему. Как перестать бояться лайв-кодинга? Кто-то скажет нужно просто несколько раз пройти через это, и всё пройдёт. Но в моей ситуации мне кажется это не сработает. Каждый раз, когда кто-то хочет понаблюдать за моими действиями, даже неважно, идёт речь о кодинге или о моём хобби (рисование, вязание и т.п.), я начинаю жёстко тупить. В голове мартышка с тарелками, руки не слушаются, и всё в таком духе. Пару лет назад была позорная ситуация на работе. Коллега попросил расшарить экран и написать функцию. И в тот самый момент, когда я понимаю, что за мной наблюдают, я забываю всё к чёрту. Элементарно не могу вспомнить синтаксис этой самой простой функции. Коллега опешил и сказал, что я его пугаю, и он не понимает, почему я так туплю на элементарных вещах, потому что он ранее читал мой код, в том числе довольно сложные вещи, а тут он видит такое. Я и сама не знаю, как это объяснить. С того момент мало что изменилось. У меня срабатывает такая же реакция, если кто-то подходит и начинает смотреть. Ей богу, будто в душу лезут. В ближайшее время предстоит проходить собеседования, а сейчас, насколько я понимаю, везде требуют лайв-кодинг (особенно в крупных компаниях). Раньше данная практика будто бы была не особо популярна, я устраивалась чисто за счет теории (обычно устное собеседование с вопросами) и тестового задания без вот этого всего. И я просто не знаю, что делать со своим страхом. Боюсь, что завалю много собеседований именно из-за этого.