Ответьте на вопрос "Почему вы хотите заниматься с ментором?" Лучший комментарий получит 1 бесплатное занятие с ментором Solvery (стоимостью до 3000 руб.)

Классное интервью, очень необычные вопросы на самом деле. В основном на Ютубе мок интервью с какими-то дурацкими вопросами, а тут как взаправду

Очень интересно. Спасибо.

28:17 - значение 1 не по этому)))) а из-за того, что параметр i - будет постоянно 0 на входе (он у тебя глобальный i замаскирует локальным) и break вообще не появится - ты лучший))) второе подряд задание лажает

Антон, красава. Лайк за смелость)

@Solvery Cобеседующий достаточно серьезный разработчик. Да, забыл про интернирование и про то что хранится размер в отличии от массива и про GC.Collect() и какое отношение Inner Join имеет к Foreign Key непонятно. Но почти все ремарки были по делу.

Чувак на фоне звёзд как айтишный танос

20:37 - Не правильно!!! Метод Call() - запускает таску (асинхронно) после инициализации таски запустится слип на 2000 что раньше запустится Delay(100) или Sleep(2000) вопрос, но они будут выполнены асинхронно а потом "await call;" пролетит без ожидания тут натянут 4 ответ - Метод Call() запустится асинхронно сразу

@yuryermolov13

2 ай бұрын

Вот я с вами согласен. Но есть много обсуждений на эту тему и согласно им await вообще не обязан создать поток. Если задача выполнилась мгновенно, а 100мс это +/- оно, то до создания потока может вообще дело не дойти и тогда Call() выполнится синхронно.

какие шилдты, троелсон потом рихтер

а где записаться на другие эвенты?

@Solvery

Жыл бұрын

Добрый день! Можно записаться тут events.solvery.io/tech-interview-fest

Ребят, а вы свои задачи проверяли в рантайме? У вас там ошибки, лол.

Довольно такие интересные вопросы, но не уверен что это надо спрашивать джунов, а кого нить выше уровня от мидла хотя бы что ли

7:25 нет бы посмотреть внимательно, но нет, надо же сразу дать ответ, типа ты шаришь. И в итоге облежаться. После этого реальный собес можно сворачивать по сути. Придет такой в компанию и заруинит что-нибудь таким подходом. Ему же будет западло сказать, что он не знает или не уверен, что он делает сейчас, поэтому он сделает дичь и проект весь ляжет через неделю. Вроде два высших образования у человека, а таких вещей не понимает, ведь не 20 лет ему.

20:53 : Как раз таки поток будет выделяться из пула для завершения метода Call, так как основной поток мы усыпили и ответ от Таска не был сразу, что он готов. Так что ответы составлены очень неграмотно . Вообще после неправильного ответа на первый вопрос, многие бы тех. интервьюверы в реальном мире уже бы интервью закончили. Это уровень начинающего, но точно не того, кто претендует сегодня на позицию junior.

@VINKOS

6 ай бұрын

1 вопрос, можно просто тупануть) Не одобряю отметание кандидата на 1 вопросе. С асинронностью согл на половину, главное было сказать поведение, там очивидно какое оно, но вот ответы рил не оч составлены. Я бы сказал что он тянет более чем на джуна, не понимаю твоей оценки что он стажер, может только если ты джуну не собрался платить более 1к баксов (ну или 700-800 минимум), имхо

37:00 -- интернирование

@Excalib

Жыл бұрын

потом вспомнил уже:))) Спасибо

@ocamlmail

Жыл бұрын

@@Excalib Интересное собеседование, задачи интересные. Вопрос про асинхронный фрагмент -- правильно ли я понимаю, что await call будет синхронным, точнее соотв. задача (task) отработает к моменту завершения сна? А с энумератором вообще классный вопрос, я мозг сломал. Поковыряю эту задачу на sharplab.

@Excalib

Жыл бұрын

@@ocamlmail я думаю терминологией я ввел в заблуждение зрителей и Антона, если упростить то я ожидал услышать такой ответ: "При var call = Call() метод уже вызовется и создаст таску в результате, но так как операция внутри метода длится около 100мс, то сначала выполнится метод не смотря на то что дальше вызывается Thread.Sleep(2000)" этой задачкой проверяется понимание async await, я показал конкретный пример где await по сути не нужен, да ситуация выдуманная, но показывает насколько человек действительно понимает async await, а не просто пишет эти слова на автомате)

@Excalib

Жыл бұрын

если подумать то метод выполняется асинхронно, но в то же время функционал await не идет по ветке асинхронного выполнения(внутри стейт машины), он идёт по ветке синхронного выполнения, если задача уже выполнена, то ей присваивается статус и на этом все, поэтому я и сказал что "синхронно" чем запутал всех

@stefano_schmidt

Жыл бұрын

@@Excalib если прописать вывод в консоль id потока после await.Delay() в методе, то id будет отличаться от id в Main методе. Вы на видео сказали, что поток на выполнение Task не будет выделяться

Как этот чел спутниками управлял ? алле ?!?!?

@user-pb2zv3ib7h

7 ай бұрын

он же сказал в начале, работаю в мандарине, до этого в банке работал, из под пива скорее всего

это реально собес для джуниора? народ вообще перестал разграничивать вопросы для джунов мидлов синьеров

Ведущий смеётся когда человек говорит что он не помнит ответ, нуу... Очень не приятный интервьюер

@artemkashuba7935

8 ай бұрын

+

@benjaminBTN

8 ай бұрын

Очень приятный интервьюер, а смеётся он добродушно и в основном вместе с проявлением улыбки у оппонента

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

@kokosiki40

8 ай бұрын

хуйню какую-то как обычно спрашивают, главное знать best practice для технологий, а проверить наверное только тестовым такое можно, и то там много ограничений из-за времени и объема тестового.

Я не понимаю зачем везде про этот сборщик мусора спрашивают?! Особенно про то как он работает. Он же автоматический и работает сам по себе. Единственное, что можно сделать это вызвать Dispose, но и это всего навсего указать для сборщика, что можно удалить объект сразу после его использования, а удалит его сборщик все равно когда посчитает нужным. В рамках "он есть, я знаю" все, что нужно про сборщик мусора знать. :)

@adrew4

5 ай бұрын

То, что он работает сам по себе не означает что можно игнорировать логику его работы. Есть memory leak, есть переполнение, есть этапы сборки мусора. Каждый сбор мусора сопровождается приостановкой main thread операций зачастую, потому что таков паттерн сборки мусора. Когда вы убираете параллельно - это неэффективно. Вы должны понимать в какой момент времени это произойдет, какие будут последствия, почему программа выделяет все больше памяти линейно от времени ее жизни и так далее. Это отличает хорошего программиста от новичка, это нужно знать. И надо понимать какой обьект вообще попадет под сборку, по вине программиста многие обьекты живут до момента пока приложение не закроется. От ваших действий зависит сколько приложение в итоге будет хавать памяти, и будут ли лаги, грубо говоря. Например в играх, если происходит сложный GC, картинка просто виснет на экране монитора. И программист имеет влияние на эти процессы, если понимает как с этим работать, и как это происходит. Каждый этап сборки - это работа с участками памяти, и если человек шарит, он может оптимизировать сборку, просто написав код правильно в той или иной ситуации, чтобы она отрабатывала определенным образом. В целом, есть как минимум 3 этапа сборки, когда в памяти обьекты гоняются из кучи в кучу. Для Junior не понимаю почему задают этот вопрос, но специалист уровня выше все таки должен знать это, я уверен. Особенно если пилят приложение нацеленное на перформанс. Dispose увы не единственный момент, когда вы можете влиять на эти процессы, есть еще финализаторы, неправильное использование которых повлечет двойную сборку обьекта, сборщик сначала переместит обьект в дальний угол, условно, а соберет гораздо позже, вместе с другими "тяжелыми" обьектами, и много чего еще есть, думаю имеет смысл изучать самостоятельно, при желании. Совокупность этих знаний позволяет менеджерить обьекты самостоятельно, писать код правильно, который будет работать быстрее. Это не бесполезные знания, так что вы ошибаетесь. Чел ваще в целом для джуна нифига себе рассказал инфы, про стек, кучу, не все сеньоры знают как это в принципе работает 🤣🤣 Я знаю таких блин сеньоров, которые бы завалили самый первый таск из этого интервью.

@ashimovroman

5 ай бұрын

@@adrew4 Много слов, тем не менее, я прочитал 2 раза на всякий случай. И мне показалось, что Вы таки не убедительны. Все, что Вы описываете это все демагогия и в некоторых вещах не относящееся к c#пу, по моему мнению, и вот по чему: 1. Согласно документации Microsoft, Вы описываете, управление памятью, которое включает в себя: - автоматическое управление памятью, - очистка неуправляемых ресурсов, - сбор мусора. Кроме второго дефиса, ВСЁ работает на "АВТОМАТЕ"! И даже второй дефис никак не управляет памятью, как я и говорил ранее, а ВСЕГО ЛИШЬ СООБЩАЕТ GC о состоянии объекта и GC все равно САМ РЕШАЕТ когда ему уничтожить объект, после финализации, которую он все равно САМ ДЕЛАЕТ!!! (Это про Dispose) Отвлечемся... Ибо наше мышление ассоциативно ;-) В авто, где установлена АКПП, мне АБСОЛЮТНО не надо знать и понимать по какой там заложенной, заводом изготовителем логике, при каких условиях, переключаются передачи. Мне нужно знать ТОЛЬКО "PRND"! А на МКПП мне НУЖНО ЗНАТЬ И ПОНИМАТЬ, когда переключать передачи, при каких оборотах двигателя, и как работать сцеплением, и т.д. и т.п.! В общем C++ это МКПП, а C# это АКПП, в работе с памятью. По-этому, я предполагаю, что Вы, СИПЛЮСПЛЮСНЫЙ СТАРОВЕР :-) Без обид сам на нем учился!

@adrew4

5 ай бұрын

@@ashimovroman это все конечно хорошо про Microsoft, но как вы будете профилировать приложение, если не будете понимать в какой момент происходит выделение мусора и его сборка. Тогда можно не знать вообще ничего, ни про стек, ни про кучу. Зачем? Какая разница? Оно же само делает - это ваш аргумент. Но, я не пытаюсь убедить кого либо) Куда поместить обект в кучу или стек тоже решаете не вы а среда, по сути то)) Но, все эти тонкости начинают иметь смысл, повторюсь, когда речь идет о "performance". Вы не понимаете зачем нужно знать о GC, а я не понимаю почему люди задают такие вопросы в конечном итоге 😂 Отвлечемся от финализаторов, хоть в ваших словах и есть неточность, повлиять на это можно, но.. Для меня все это просто и естественно, я например люблю поиграть в игры, и когда я наблюдаю очередной статер который наглухо вырубает весь мой fps на секунду времени а в логах написано об очередной сборке мусора в 200-300Мб, то невольно начинаешь задаваться вопросом как такая большая компания смогла выстроить архитектуру которая настолько неумело создает утечки памяти и бесконечный мусор(конечно я понимаю почему, это риторический вопрос), и такое часто происходит в момент прицеливания, что просто выводит из себя порой. Часто это еще на frametime влияет, и так далее. В софте это будет проявляться как жор памяти на протяжении всей жизни приложения. Если пишите бек, серв может повиснуть на секунду, две, три, в зависимости от железа. И если бизнес это устраивает - то окей, я не против чтобы люди не знали о GC, но для себя я сделал однозначный вывод, что для меня профессионал своего дела однозначно должен либо знать как эти процессы происходят, либо стремится к этому. По моему мнению это однозначно влияет на качество финального продукта. И я не то, чтобы предполагаю, я знаю на 100% что влиять на это можно, о чем неоднократно написал выше. Для вас все это не аргумент. Меня просто слегка взволновал ваш комментарий, и я увидел в этом себя 5 лет назад. Оттого и написал, но я ни в коем случае не пытаюсь вам, или кому либо доказать иную точку зрения. И я не против, если вы считаете иначе. Флаг в руки)) В данном случае, я скорее удивился, что люди до сих пор задаются подобными вопросами и скидывают документацию Microsoft)) т.к. для себя я уже ответил на этот вопрос довольно давно, и понимаю профит этой информации.

@ashimovroman

5 ай бұрын

@@adrew4 А вы знаете "в какой момент происходит выделение мусора и его сборка"? Не знаю чем вам не угодила документация разработчика, но вот из неё: Сборщик мусора автоматически освобождает память, выделенную управляемому объекту, когда этот объект больше не используется. Однако невозможно предсказать, когда будет происходить сборка мусора. Еще: "Механизм оптимизации сборщика мусора определяет наилучшее время для выполнения сбора, основываясь на произведенных выделениях памяти." Dispose и Finalize не управляют GC на прямую. И оптимизация, про которую вы все твердите, касается правильного, грамотного и рационального использования памяти и написание кода в целом. А вопрос конкретно как знания про поколения и этапы GC помогают разработчику?

@adrew4

5 ай бұрын

@@ashimovroman вы хотите чтобы я рассказал вам теорию? Потрудитесь сами найти информацию по данному вопросу. Но, коль уж вы спросили, хотя очевидно, что сейчас это уже просто перешло в демагогию, сборка мусора выполняется в момент, когда требуется аллоцировать больше памяти под задачи, либо когда обьем мусора достигает определенного значения. Можно управлять сборкой и в ручном режиме, для этого есть метод GC.Collect с явными указаниями о немедленной сборке в качестве аргументов метода. Вы бы все это знали, если бы хотя бы немого интересовать процессами, а не пытались спорить в комментариях. Предсказать когда будет сборка это сложить 2+2, можно явно указывать лимиты на обьем мусора в мегабайтах, для всего этого есть api. Finalize так-же можно отменить, при условии, что вы позаботились об этом ранее. В дополнение ко всему, есть еще unsafe, и тогда подобные фичи имеют колоссальное значение. Если вы не понимаете зачем это нужно, это не значит что это не нужно никому в принципе. Этот диалог уже просто абсурден. Рассуждать о GC прочитав две строчки из wiki Microsoft мне кажется это странно. Вероятно и никаким профайлером не пользовались, иначе бы не задавали таких вопросов. Можем вернутся к обсуждению, когда вы тоже будете в теме тех вопросов, о которых спрашиваете. Но, насколько я понимаю, этого не произойдет.

Такие знания на джуна, смех просто, на старт мидла тем более. По ASP вообще ужас наблюдал. С такими знаниями разве что на стажера, и то спорно будет.

@validationerror3830

5 ай бұрын

GC джуну нахер не нужен

@air47

5 ай бұрын

@@validationerror3830 где я что-то сказал про GC