Пробное Senior C# собеседование (мок-интервью)

Подготовка к собеседованию на C# Developer

Транскрипция видео:

  • Привет Меня зовут Алексей Добро пожаловать на собеседование Расскажи пожалуйста чем DN Core отличается отка и Какие преимущества представляют 12 он насколько я знаю это перва frw он только под Windows работает принципиальная идея практически не отличается единстве [музыка] не могу сказать не могу ответить на этот вопрос Как вы используете и реализуете аутентификацию и авторизацию в микросервисной архитектуре для того чтобы представить пользователя для того чтобы получить ему токены или ки для авторизации мы запрашиваем

    00:00:00 - 00:01:39

  • аутентификацию на какой-либо сервис При этом предоставляя клемы если права доступа к каким-то методам сервиса допустимы то для текущих клеймо то пользователь проходит также авторизацию и его запрос выполняется альте напрямую когото или токен и идёт в этот сервис с ними Да не обязательно он может получать кути или токен авторизации у какого-то стороннего сервиса который как раз и будет ему предоставлять вот все токены ки и ну и конечно те сервисы которые на которых пользователь собирается авторизоваться они должны будут иметь

    00:00:59 - 00:02:57

  • доступ К данным чтобы проверить что токены они действительны Спасибо тогда давайте к следующему вопросу перейдём Объясните принцип работы паттерна медиатор и Приведите пример его применения рада Каковы преимущества и недостатки использования контейнеров таких как доке в приложения в сразу в частности приложение по Frame при этом у нас используется виртуальная машина где-то используются lxs контейнеры если мы будем использовать докер мы получим потерю производительности то есть будет запущен докер

    00:01:59 - 00:03:42

  • контей контейнере или в виртуальной машине и да и всё это будет поднято на реальной машине Таким образом мы получим громадную потерю производительности для виртуально Ну из-за того что каждый каждая сущность работает в своём слое Вот так А если не брать Вот именно контейнер докер а просто про контейнеризации приложений дот невских В чём плюс и минус такого подхода плюсы в том что мы можем ть контейнеры и если запустилась в одном месте то запустится и в других это первое для меня например Это очень важно а второе - это то что

    00:02:55 - 00:04:29

  • развёртывание занимает уже гораздо меньше времени если мне допустим на приходится хостить что-то руками переклад тут я могу написать БАД файл который будет неудобно деплоить приложение недостатки скажем так с которым я наверное успел столкнуться это некоторая изолированность докер среды от реальной сети То есть можно иметь некоторые трудности при подключении к докер контейнерам из реальной сети то есть но тут надо разобраться просто один разок и будет уже проще в будущем Хорошо спасибо как бы вы управляли состоянием

    00:03:42 - 00:05:25

  • транзакций между несколькими сервисами транзакции SQ Да вообще в целом то есть смотрите у нас есть допустим платёжная какая-то система есть наш интернет-магазин где мы не знаю там скины для игр продаём и вот мы должны получить в один сервис что пользователь начал оплату редирект нуть его наш платёжный шлюз оттуда получить ответ что всё хорошо прошло пополнить его баланс в какой-то своей финансово своей системе в финансовом сервисе оттуда передать на то что в систему где которая скинами торгует то что У пользователя теперь

    00:04:33 - 00:05:41

  • есть этот баланс и можно скин ему купить списав при этом баланс есть у нас такая транзакция которая не в прямом смысле SQ ная транзакция а просто вот один единый какой-то платёж одно действие покупка скина и она разбивается на несколько сервисов вот как бы предложили разбить со да то есть сообщени у нас проходит от одного сервиса к другому да да Ну как вариант это использовать брокер сообщений и через управление им можно будет это сообщение таким образом транслировать на несколько микросервисов сразу наверное самый такой

    00:05:08 - 00:06:25

  • Явный вариант это использовать именно брокер сообщений можно использовать также вкручивание шины USB сообщени чтобы она как раз управляла всеми сообщениями в потоке она могла бы перенаправлять сообщения логировать и перенаправлять одно и то же сообщение в несколько микросервисов сразу то есть использование паттер USB Давайте перейдём с вами к практическому занятию вот я уже скинул его описание в попрошу вас ознакомиться с ним нать не обязательно сейчас писать именно Прямо от начала до конца все сервисы просто

    00:05:46 - 00:07:22

  • как бы вы подошли к этому и может быть успеем что-то реализовать за оставшееся время систе рования да Для начала так у нас все сообщения будут поступать именно вот в этот Интерфейс Да да у вас какая-то система должна быть сво сообщения читаю задание и подумаю вопрос по последнему предложению теоретическими ошибками что считать это по бизнес логике То есть например пользователь вот в нашем случае Да пришёл покупать скин пошёл в какое-то средство для оплаты а средство для оплаты ответи 500 ошиб 5 или 44 то есть

    00:06:35 - 00:08:02

  • у нас нен способ оплаты это критическая ошибка так хорошо и нам сейчас именно надо разработать архитектуру приложени Да и как описывать её или так так давайте тогда порассуждаем как вариант это первое отсылать сообщение в очередь которое будет именно очередью для логирования в случае если допустим запрос у нас какой-то не проходит мы отправляем в очередь сообщений сообщение о том что запрос не прошёл и он должен будет попасть зачитать у нас будет продюсером какой-то сервис который будет отправлять

    00:07:28 - 00:09:17

  • сообщение в очередь А косю у нас будет Как раз сервис логирование мы таким образом использую очередь решаем пункт номер два логичнее будет поместить логи в SQL базу данных ну я такой подход практикую и он будет достаточно быстрый для того чтобы просматривать очень большое количество логов поэтому тут бы Я использовал базу данных причём Чем выше у него скорость обработки Селект запросов тем лучше про Я сбд имею в виду насколько я понимаю постгрес Сейчас занимает достаточно неплохие позиции в этом плане

    00:08:22 - 00:10:08

  • Угу Так и нам надо реализовать механизм оповещения [смех] значит сообщение будет в 64 формате скорее всего Нам надо будет только 64 расшифровывать на стро сервис логирования так и Ну хотя наверно пока что этого достаточно будет потому что у нас может не проходить какие-то спеси возможно нам придётся логировать сообщение поскольку по унию спецификации там используется то есть как раз тоже спецсимвол помешает А просто экранирование не подойдёт кронирование А что это за механизм Ну это когда мы например в том

    00:09:16 - 00:11:23

  • же косой хотим написать что-то и мы пишем вот здесь вот например хотим кавычку вывести чтобы нам не заканчивать здесь видите получается ошибка заканчивать року та СШ и у нас выводится теперь Hello кавычка для разработки механизма так который позволит нам отправлять логи систему можно отправлять их через брокер сообщения у нас получается что если сообщение нам надо знать Есть ли ошибка в сообщении можно выполнить это как то есть если сообщение ошибочно нам надо пометить его как ошибочно чтобы оно попало помимо всего в

    00:11:15 - 00:13:14

  • другую очередь от продюсера что поте по ошибочным сообщения можете пример привести то есть сообщение [музыка] которое отправил сообщение в другую очередь то есть это э будет реализовано в функционале продюсера получается сообщения с ошибками или вообще с логами с любыми они будут приходить в очередь сообщения То есть какую-то шину или они будут по к нам приходить они будут попадать в брокер сообщений и будут [музыка] зачитываться сервисом логирования как Угу А что тогда подразумевается под методом тот метод который будет

    00:12:37 - 00:14:33

  • считывать сообщения из шины Да это будет лишний Ну вот наверное вот также то есть Гер куда будут приходить ошибки будет обрабатывать эти сообщения Ну и отправлять Соответственно по имейлу или ещё что-то хотите добавить Или можем завершать наверное можно завершать Ой как как впечатление хочется спросить скажем так стрес хотя это всего лишь пробный Да это не настоящей интервью да это пробные [музыка] и всё равно ты волнуешься Тем не так или иначе и если подумать Скорее всего я бы принял сейчас другие технические решения А я

    00:14:10 - 00:15:57

  • уже увидел что я немножко плаваю в брокерах сообщений да то есть я не знал пересыла все ли хедер или нет Это первое Второе тут у меня возникли вопросы да из отправлять или нет то есть сейчас я вижу что если это будет два разных канала сообщений то наверно нам не нужен в целом я вижу что есть по крайней мере Куда мне развиваться если где-то сомневаешься значит здесь надо поиз учать часть Это точное вывод по теоретическим вопросам конечно желательно Да знать все новинки быть в курсе тот же 12 он уже вот-вот

    00:15:18 - 00:16:55

  • практически вышел уже там куча статей куча видео про него про его функциональность Она изначально раньше была тоже как только появлялись какие-то нюансы новости Вот это показывает твоё понимание как специалиста Что ты не просто приходишь и делаешь задачки А то что ты развиваешься ки в сервисах там был тоже вопрос ки Они работают только на уровне VIP приложения и в куда-то в сервисы они обычно не пробрасывается поэтому обычно используют gvt token который точно так же с клеймами совсем проходит то про что

    00:16:10 - 00:17:23

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

    00:16:46 - 00:18:09

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

    00:17:27 - 00:18:39

  • понимание тому человеку который ждёт тот кто интервьюер Понимание где мы находимся находимся да да И если вдруг что-то непонятно мы можем сразу же спросить по именно прочтём контексту человека который интервью у него будет сразу же мгновенно в голове и плюс Это действует ещё как такая психологическая раскачка перед ответом то есть большинству программистов тяжело рассуждать вслух о чём-то рассказывать ещё и думать при этом и соответственно здесь мы начинаем так с лёгкого этапа просто читаем вслух и таким образом

    00:18:04 - 00:19:09

  • речевой аппарат свой запускаем грубо говоря про базу данных Да есть варианты когда и я тоже работал с такими компаниями когда закидывают логи в SQL базу данных но мне почему-то кажется что намного лучшим вариантом будет ш тот же который вотка используется то есть такая более специализированная база данных ш Да можно по ек найти там рассказывать собственно это буква л в слове екш ещё один момент про vbp вот сервис vbp который принимает сообщение в микросервис для логирования опять же если он у нас принимает сообщение из

    00:18:36 - 00:20:00

  • шины то непонятно зачем ему wbp функциональность Ну это я уже немножко поплыву Понятно бывает Главное чтобы на собеседовании настоящем такого не было либо быстро прошло И соответственно Да в таких системах Когда у нас скорее всего будет большой поток сообщений Да всё-таки система логирования то лучше в не использовать потому что забивается очень быстро у нас пропускная способность Вот и мы можем потерять логи что не очень хорошо вот система с логами должна быть такой прям отказ устойчивой практически на высшем

    00:19:18 - 00:20:43

  • уровне вот что ещё в общем хотелось бы отметить что лучше подходить из ряда топ да то есть сверху вниз мы изначально какую-то Верхне уровневую архитектуру придумываем а потом уже идём в глубь всё ниже и ниже нежели по каждому вопросу сразу же углубляться потому что во-первых мы можем не успеть Да всё рассказать мы можем зациклить на там первых двух вопросах и два остальных мы вообще просто не учтём соответственно получим за них ноль баллов или даже там минусы смотря кто как оценивает Вот а если

    00:20:01 - 00:21:06

  • рассказать верхний уровень Сначала вообще в целом про весь подход то охватывает ешь непосредственно в каждый момент про b64 Честно говоря я так и не понял до конца зачем его использовать Ну то есть я понимаю что чтобы от экра чтобы от спецсимволов избавиться но для этого подходит также экранирование то есть мы можем через ш Да И вот угловые скобочки экранировать и любые другие спецсимволы ха тут могу пояснить теперь он Говорить нельзя да А могу пояснить что в спецсимволов могут быть не только Ну знаки кавычек Да это могут быть ещё

    00:20:34 - 00:21:56

  • решётка может быть процент по-моему одиночные кавычки ещё квадратные скобки То есть тут Их дофига будет всяких разных на примере сейчас как раз было видно да что угловые скобки не надо на самом деле экранировать И если мы это сейчас запустим то Вот все наши угловые скобки все квадратные скобки и прочее оно всё нормально закодировал без экранирования Понятное дело что это экранирование применимое к функции cons wline которая просто вот такую строку принимает что если мы сделаем строку такую или вот такую Вер батим да то у

    00:21:14 - 00:22:20

  • нас несколько другие появятся символы для экранирования но суть в чём в том что мы можем экранирования избавиться от любых спецсимволов и нет смысла кажется конвертировать 64 и обратно это Чуть более трудоёмкая кажется операция чем спецсил экранировать Ну и про ты уже сам сказал это кажется было не очень нужным вот здесь у нас было поле дополнительное Да что касается плюсов прям очень классно было когда на теоретических вопросов ты сказал Не знаю но после этого продолжил рассказывать как ни в ЧМ не бывало один вопрос

    00:21:47 - 00:23:01

  • ответил что не знаеш Да а второй пошл дальше спокойненько рассказывать сбиваются и прям ВС начинают руки опускаться Вот хорошо Что такого нет Надо уметь делать ошибки да то есть если не знаешь лучше сразу прямо об этом сказать а здесь чтото выдумывать лучше подход такое что вот эти вот слова не знаю лучше не говорить наверно такую фразу сказать что не сталкивался с таким но и продолжить вот какие-то свои рассуждения что я думаю что здесь скорее всего вот так если я не пра то поправьте Это лучше воспринимается чем просто

    00:22:24 - 00:23:37

  • сказать я не знаю Да я не знаю работает хорошо если это один раз максимум два раза за собеседование потому что это сохраняет вам время сохраняет настрой то есть вместо того чтобы тормозить на каком-то вопросе что-то выдумывать мы говорим Не знаю и идём дальше примерно с тем же темпом и ещё понравилось что в процессе обсуждения ты говорил Давайте порассуждаем Понятно ли я выразился или нет уточняющий вопрос по ходу задавал Это намного лучше чем когда человек берёт задачу и затыкается и просто вот

    00:23:00 - 00:24:08

  • молча сидит Сам в себе варится тут вообще непонятно что у него там происходит происходит ли вообще что-то у него в голове собеседование - это такое место где нужно разговаривать да я ещё читал что рекомендовали на собеседованиях какой подход А если не знаешь но ты можешь рассуждать на эту тему это будет даже лучше чем ты знаешь и ты ответишь на этот вопрос да дадада Потому что тут уже имеет значение то что ты умеешь логически рассуждать Ты не просто Зазу где-то ответы Ты можешь решать какие-то задачи и для бизнеса это как раз

    00:23:35 - 00:24:57

  • первоочередно а не знание каких-то ответов да да полностью согласен на этом пожалуй всё что ж вот наше пробное собеседование и подошло к концу Огромное спасибо Павлу за участие и тебе за просмотр Надеюсь это было интересно и полезно А если есть идея как улучшить формат пиши в комментариях Если хочешь потренироваться с нами подписывайся на рассылку в комментарии ниже И ещё я как наверное и ты больше технарь чем маркетолог Поэтому если тебе понравилось пожалуйста помоги с раскруткой канала как напиши комментарий Поставь лайк

    00:24:16 - 00:25:33

  • подпишись на канал и поделись с друзьями ка

    00:24:55 - 00:25:04

Менторы

Специалисты своей области, которые смогут помочь вам

  • Нигма Нурия
    Нигма Нурия

    Middle .Net Developer

  • Сущенко Татьяна
    Сущенко Татьяна

    Senior Product Manager

  • Гудков Денис
    Гудков Денис

    Middle Python Developer

  • Курочкин Константин
    Курочкин Константин

    Ведущий программист

  • Гудман Макс
    Гудман Макс

    Backend Software Engineer (PHP)

  • Гребенкин Антон
    Гребенкин Антон

    Senior .NET/C# developer

  • Ахназаров Фёдор
    Ахназаров Фёдор

    Middle DevOps Engineer | Tbilisi, Georgia

  • Шорохов Дмитрий
    Шорохов Дмитрий

    Middle C# .NET

  • Жуков Александр
    Жуков Александр

    Senior PHP-разработчик

  • Мазикин Павел
    Мазикин Павел

    Middle python developer

© 2024 HireGuru. Сделано в Санкт-Петербурге с hireguru.ru