Вопросы C#/.NET junior на собеседовании

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

Что требуют знать?

И что требуют уметь делать?

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ребят. В связи с короновирусом решил подработать. Могу подготовить к собесу всех , включая сеньоров(на работе часто этим занимаюсь). Если интересно ищите al322se в телеграмме.

Норм списочек.
10.4 iclonable — зачем? Кто сейчас это старье использует в реальной жизни?)

Спасибо, составил его давно, когда готовился к собеседованию на middle-уровень.
Это часть core, Не знаю кто использует.

Пару вопросов есть, не знаю, правда джуновые ли. Но все равно интересно, ответишь ли.
Выполняются ли async методы в отличном от вызывающего метод потоке ?
Работает ли конверсия типов только на типах, у которых есть какая-то иерархия ?
Каким должен быть a и b, чтобы выполнялся код (a и b — числа)

a < b false
a > b false

Каким должен быть a и b, чтобы выполнялся код (a и b — числа)

a < b false
a > b false

Я чего-то не понял полета мысли. Ну, a=b, и что дальше? О_о

А кто сказал что можно только адекватные вопросы?)

Ок, а если
a >= b false
a <= b false
Тогда какие a и b ?

это слишком банально, если честно.

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

Я иногда задавал вопрос — напишите Where из Linq. 5 лет назад этот вопрос ставил в тупик где-то 25%-30% интервьюируемых.

Звучит как тривиальная задача. referencesource.microsoft.com/...​rable.cs,44b8532e11187695. Или не подразумевалось Lazy выполнение?

IEnumerable<T> Where(IEnumerable<T> source, Predicate<T> predicate){
    foreach (T item in source){
        if (predicate(item)){
            yield return item;
        }
    }
}

пропущен this перед source, а так — думаю что после первого уточнения с примером кода вопрос был бы засчитан :)
Безусловно, в .net framework это же написано намного сложнее, но я не хотел в это углубляться.

пропущен this перед source, а так — ты бы прошел :)

Сори, я на C# не писал уже лет шесть, но до сих пор помню, что при обращении к аргументам функции this писать не надо. И еще большой вопрос, кто кого будет собеседовать и кто пройдет, а кто нет.

Безусловно, в .net framework это же написано намного сложнее, но я не хотел в это углубляться.

Какому-то кодерку в редмонде нужно было найти способ оправдать свое существование, а мне не нужно

Имелось в виду
IEnumerable<T> Where(this IEnumerable<T> source, Predicate<T> predicate)
чтобы потом написать что-то вроде
list.Where(item => item.Amount > 0)

ага, но это this перед IEnumerable, а не перед source. Ждем объяснений эксперта зачем писать this перед source.

Полегче на поворотах, дружище. Коллега Антон прекрасно понял что имелось в виду — и this написан перед source в сигнатуре метода (который, к тому же, должен быть статическим), потому что where в linq это extension method который как раз пишется.

За отношение — низачет.

Сложно признать, что хотел поумничать, но апазорился? И таким людям доверяют собеседовать джунов? :(

Где? Я написал все правильно, а вот ты накосячил в 2х местах и додумал за меня то, что я не говорил (см ответ коллеги, где this написан перед source на той же строке). Опять таки, прямо над твоим ответом есть ответ человека, не прикидывающегося дурачком, где все написано правильно.

Ты вообще не написал ни строчки кода, только лажевые коменты.

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

Вот клоун, еще прошелся и все свои сообщения поправил, но у меня ж в email копии лежат, так что можешь не стараться.

см ответ коллеги, где this написан перед source на той же строке)

У коллеги this написан перед IEnumerable, а не перед source. Разницу видишь? Нигде в моем коде нельзя писать this перед source.

Цитирую тебя где ты апазорился как нуб:

пропущен this перед source

нотариально заверенный скриншот?

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

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

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

Где в условии задачи было написано про static?

В условии задачи написано where из linq. если ты не знаешь что это такое (а это extension method, которые по определению статические) и как используется, то это твои проблемы, клоун.

Опять таки — коллега выше уже все правильно написал, но ты, похоже, вообще необучаем. Посмотрел бы уже ответ Anton Taranov (который тоже пропустил статик, но который правильно написал для чего нужен this)

Мы с коллегами с нетерпением ждем код, в котором

this перед source

Да хватит уже тупить. В условии задачи написано «where из linq».

Where в linq это экстеншен метод, которые по определению статические.

Коллега выше все правильно понял и правильно написал this после моего комментария, а ты все еще прикидываешься дурачком.

Такой срач на ровном месте, причем я ведь изначально написал, что «после первого уточнения вопрос был бы засчитан», но похоже трещина в самолюбии клоуна уже была сделана.

Отправлен в игнор. Напиши мне в приват в какой команде сидишь чтоб я случайно туда не забрел.

Еще один показательный пример того, что в амазоне нужно тщательно выбирать команду 🤣

Ну люди с таким агрессивным отношением как Артем редко проходят собеседования.

Я почему-то думаю что когда завтра вобью его фамилию в phonetool то не найду ее там :)

Справедливости ради, я это сделал и вижу что Артем сидит относительно недалеко.

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

Бывает. Ну и это же был не единственный вопрос на собеседовании, так, дать кандидату немного размяться :)

Но пример действительно показательный, т.к. никакого рокет сайенса тут нет, а много фич языка задействуются.

Я скорее о том, что разработчик, который применял фичу языка и понимает как она устроена может не въехать в то, что от него хочет собеседующий. Но, да, разные вопросы помогают сформировать целостную картинку.

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

К счастью, задачи чисто на язык у нас не задаются, но даже тут это бы сработало.

более чем тривиальная задача, в идеале проверяющая знание человеком что такое ienumerable, yield, extension methods и predicate, но я просил чтобы кандидат написал хотя бы любой вариант, который приходит в голову.

Меня вообще зачем-то понесло в сторону IQueriable и построения выражений поэтому и написал про нетривиальность. Но то такое.

Тут больше понимание на то, как yield генерится в стейт машину.
И как сделать eager проверку на null но lazy итератор. Не думаю, что это вопрос на джуна конечно, но интересно)

Работает ли конверсия типов только на типах, у которых есть какая-то иерархия ?

Чё?

Кстати, там, похоже, компилятор какие-то хаки делает docs.microsoft.com/...​numeric-conversions-table. Но это уже фича компилятора, а не языка.

Выполняются ли async методы в отличном от вызывающего метод потоке ?

Не на джуна вопрос, имхо.

Выполняются ли async методы в отличном от вызывающего метод потоке ?

Не на джуна вопрос, имхо.

Да ладно! У нас даже HR и QA это знают.

А на следующий вопрос (который просто грех не задать) «Приведите примеры, в каких случаях да, а в каких случаях нет, а главное, зачем?» они тоже ответы заучивают?
Асинхронное программирование вообще тема сложная для джунов, имхо. Это как дифференциальное исчисление учить в 5м классе.

Асинхронное программирование печаль у дотнеитчиков даже среднего по рынку профиля синиора. Вижу постоянно много косяков использования async/await и незасинхронизиртванный код регулярно, особенно там где асинхронные делегаты. Причём это массово. Тут хватает практических вопросов как понять умеет девелопер в него или нет. Теорию просто заучивают, но это тоже элементарно выкупается. Это касается впринципе любой области — если собеседующий не по такому же принципу готовится к интервью(читает популярные вопросы про многопоточность и рихтера) то он всегда пробьёт ваш практический опыт и поймёт нужен ты ему или нет.

Теорию просто заучивают

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

ЗЫ: даже если она «короткая и непрактичная и чтобы только собеседование пройти» всё равно ок очень надо.

Надо прочесть и понять Рихтера, CLR via C#, и тогда можно будет иногда и погнобить самих интервьюеров.

А так, все тоже что и не джунам: LINQ, как linq работает, что такое yield, extension methods, expression trees, интерфейсы, классы, наследование, генерики, перегрузка операторов, как правильно реализовывать IDisposable (финализатор есть? а если найду?), async/await, конкурентные коллекции, PLINQ, Task<> и его использование, примитивы синхронизации (опционально), домены, эвенты, как сделать утечку памяти в дотнете, что такое nullable, зачем нужно, ref/out параметры, когда используются, боксинг, чем дженерики для рефернс типов отличаются от дженериков для велью, что такое дотнет стандарт, portable assemblies, чем .net core отличается от .net framework, какие могут быть проблемы с портированием приложения на линукс, решарпер или visual studio :), быть в курсе приятных мелочей последних C#-ов: ?., упрощенная запись методов, конструкторов, свойств, таплы, вложенные функции и т.д.

Вот только чисто C#/.net не сильно интересен, нужно будет хотя бы какие-то туториалы поделать еще по WPF (оно еще живо?) или ASP.NET Core, для того чтобы практически применять.

ужас, сколько задротской фигни надо выучить

да нет, это не надо учить, если понимание есть оно само приходит

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

Оно так сделано не просто так. Вместо того, чтобы много лет писать одни и те же неудобные костыли, намного приятнее взять уже готовый лаконичный функционал, встроенный в язык или платформу. Если кажется, что оно ниоткуда не следует, значит вам просто не попадались ситуации в которых это нужно использовать. Что довольно странно, учитывая что выше перечислены в основном весьма базовые вещи.
Рекомендую книгу C# in Depth — в ней описана эволюция C# по версиям с примерами того, что приходилось делать программистам в определенных ситуациях, пока нужную фичу не ввели в очередной релиз языка.

Еще интересная Framework Design Guidelines, которая дает мотивацию тех или иных советов (хотя она тоже подустарела уже, наверное).

І потім в роботі використовувати від сили 10% від цього.

Якщо потім працювати над розробкою тестів по знанню С#, то знадобиться майже все. :)

Как можно в работе использовать 10% возможностей языка? (в моем списке около половины, если не больше, это фичи языка-платформы)

От така багата і універсальна мова — цей C#.

В звичайних англійській мові сотні тисяч різних слів, але словарний запас дорослого нейтівспікера 20-30 тис. слів, а всякі іномовні отримують рівень С1 уже при словарному запасі в 8000 слів, постійно використовуючи при цьому для спілкування пару тисяч слів.

Это сравнение неуместно: если убрать из того списка пункт про кроссплатформу, то получится база, необходимая для уровня A1. И это не язык богатый, а библиотеки, написанные на этом языке. Впрочем, относительно богатые, потому что у java/javascript-сообщества библиотек побольше, по причине втюхивания java/frontend на курсах вайти/вузах в подавляющем большистве.

Якби це була база, типу рівень А1, то без цього не можна було б обійтись при написанні програм. А так, то там половина штук, яких не було в більш ранніх версіях C# і ще третина, яка була завжди, але використовувались далеко не завжди.

Hello World можно написать не зная и не понимая вообще ничего из того списка. Написать такой Hello World и утверждать знание C# на элементарном уровне нельзя. Все перечисленное до .NET Standard появилось 6 лет назад, всякие упрощения в 7.0 — 1 год назад, на изучение которых уйдет от силы 1-2 часа. Выучить весь список и утверждать знание C# тоже нельзя, его недостаточно.
Допустим, я могу общаться на английском языке только через Present Simple. Я знаю английский на элементарном уровне?
Или когда я зазубрил 8000 слов на английском языке? Теперь-то я точно знаю английский уровень на уровне C1. К сожалению, слово is не входит в эти 8000 слов.
Сравнивать разговорный язык и язык программирования неуместно.

Ну а сам .net з’явився не 6 років тому, а 16. І що по вашому на ньому хелло ворлди писали 10 років, поки не вийшли такі необхдні «базові речі» без яких прямо ніяк не можна працювати?

Та можно и на Java писать. И на Go. И на C# 2.0. Речь об удобстве и о количестве клацаний по клавишам.

Ну так, більшість із пізніших введень це синтаксичний цукор. В деяких випадках він полегшує програмування, в деяких може ускладнити читання коду. В деяких областях взагалі не потрібна була ні базова функціональність ні її переробка, так як в роботі не було таких проблем, на які націлена ця функціональність, через те, що С# мова універсальна, якою пишеться широкий спектр програм (на відміну від, наприклад, Матлабу, хоча навіть в Матлабі не все кожному потрібно, хто на ньому пише).

— Почемꙋ мы не использꙋѥмъ ꙋстарѣлый варїантъ рꙋсскаго ꙗзыка, вѣдь полꙋчаѥтсѧ ​этѣ​ ​новыꙗ​ правописанїꙗ, поꙗвившїѥсѧ въ новомъ рꙋсскомъ ꙗзыкѣ, не ѻбѧзательны?
— Не надо утверждать о знании C#, не зная базовые «новые» возможности 6-летней давности.
— Мой пример выше про возможность написать программу уровня Hello World не понимая вообще все из выше перечисленного.

C# - не богатый и не универсальный. Совсем недавно введенный private protected давно существовал и это не синтаксический сахар. Целый кластер обрезанных позаимствованных фич — тот же обрезанный generic еще со времен 2.0. И есть вещи, которые не целесообразно писать на этом языке.

Ну по перше C# відноситься до універсальних мов програмування. Це по класифікації, яку дають МІТ на одній з перших лекцій по Computer Science (де мови діляться на універсальні/спеціалізовані, високорівневі/низкорівневі), по цій класифікації С# високорівнева універсальна мова програмування.

Ну і як там в останніх фреймворках if, while, for, switch ще по старому працюють, чи це вже староруські слова? :)

Я не очень представляю, над чем нужно работать, чтобы НЕ использовать минимум 70% из вышеперечисленного.

Ну 70-80% я понял из списка) остальное как то так)))) ASP разве спрашивают ? WPF?Я понимаю это будет плюсом, но я думаю это уже на позицию full stack junior надо такие вещи понимать)

Мой совет для дотнетчиков —
CLR via C# для глубины
C# in a Nutshell — для языка

Если эти книги прочтены и поняты, то знание c# и .net будет уже далеко не джуновским

Я как раз начал Рихтера читать) уверен у меня все получится!)

Надо прочесть и понять Рихтера, CLR via C#, и тогда можно будет иногда и погнобить самих интервьюеров.

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

Спорить не буду — я все же дотнетом занимался довольно давно (4е издание вышло в 2013, как раз последний год когда я писал на C# в продакшене. Все что после это было просто примеры из блогов, чтобы совсем уж не забывать).

Рихтер пишет местами спорные вещи (например меня никогда не нравился его совет использовать дотнетовские названия типов, место C#-повских), но для начала все равно будет полезен. Я не думаю, что там что-то фундаментально устарело, хотя про дотнет кор там скорее всего ничего нет :)

Какую книгу(-и) сейчас советуют вместо Рихтера?

Мне сложно сказать по поводу книг — не читаю последнее время.

Дело не в том что Рихтер пишет спорные вещи, а в том что с момента издания его последней книги .net развернулся на 180 градусов и больше половины книги CLR via C# уже Legacy — (GAC/Application domains/Маршалинг между доменами).
Кроме глобальных изменений мало ощутимых пользователю — появление нового компилятора,SDK, gc, jit и новой модели хостинга приложений(подгрузка зависимостями, развертывание запуск).
Есть и принципиальные изменения в базовых понятиях в последних версиях clr и компилятора —
значимые типы были наделены полной семантикой reference типов. Refference типы становятся по-молчанию не nullable. Появляются новые примитивы, а для них другой low level api — (пример — вместо string продвигаеться новый тип UTF8String).
Что касается памяти — GC с его проблемами уже выглядит тоже как не совсем актуальные темы для разговоров с его борьбой с утечками и тому подобное — теперь выделяем память на стеке в коде и используем unsafe инструкции из Managed кода(без unsafe и тому подобное).
Поменялся подход для работы с буферами — вместо Streams повсеместных, продвигаеться Span, Memmory и Slices.
С появлением low alloc апи начали появляться новые требовательные к производительности и памяти возможности для работы с растром, графикой написанные на C#(то что всегда до этого делалось на C++ и вызывалось через P\Invoke) и тому подобное. Дотнет сстал нацелен на другой класс задач похоже, другие требования и т.д. то куда он развивается, а все(или большинство) о чем написано у Рихтера в последнем издании на этом фоне меняется либо теряет актуальность в той или иной мере.
К чему я это — если на интервью приходит человек и интервьюер или кандидат начинают с любимых вопросов чем отличаются классы от структур и начинают обсуждать, что одни ссылочные другие значимые — это не совсем как бы уже и так всё.

Это не значит, что Рихтера или другую книгу по C# читать не нужно. Начинающему специалисту обязательно нужно 1-2 книги прочесть чтобы понять как работает платформа. Да и много проектов все еще на Full Framework и там эти знания более, чем актуальные.

Ну это спорный вопрос очень. Рекоммендация читать Рихтера по-умолчанию, да еще и новичкам, очень спорная и сомнительная, я бы предпочел более актуальные источники информации — например хороший вопрос зачем сейчас .net-чику джуну разбираться как работает GAC, который был разработан как технологиях, когда интернет был медленным HDD стоил дорого, а софт распрострянялся на CD-ROM — те аппаратные моменты уже даже умерли, которые диктовали подобные решения 20 лет назад, с вероятностью 99% джуну эти знания никогда не пригодятся, кроме как ответить на вопрос, что такое GAC — как он работал все равно никто знать не будет — так как реально потребности пользоваться уже давно нет, а поддержка в новых версиях этих вещей например в том же .net core полностью выпилена. Тоже самое касается потоков и примитивов синхронизации — на деле все знают, что такое семафор из википедии, но кроме разработчиков веб серверов это никому не надо на практике, а что такое TPL.DataFlow как аналог высокоуровневый никто не знает — если надо распаралелить типичные вычисления «под семфором» с i\o — то будут писать циклы, какую-то арифметику считать — вот это основной негатив такой модели образования дотнетчиков возрощеных на Рихтере. Люди не умеют практически правильно пользоваться .net, а оттачивают знания в теоретических вещах по такой литературе.

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

а что такое TPL.DataFlow как аналог высокоуровневый никто не знает

Это грустно, конечно, но дело не Рихтере, как мне кажется.

TPL.DataFlow

К сожалению, Microsoft имеет привычку иногда подзабивать на проекты, и Dataflow кажется подзабитым экспериментом, судьбой чем-то напоминающим Rx. Буду рад ошибаться, впрочем. А вот Task<> и async/await торчат везде.

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

По хорошему если разобраться семафор, CountdownEvent для .NET задач слишком низкоуровневый инструмент и пользователями фреймворка используються приблизительно одинаково — практичеки никогда :) если используються, то от незнания что аналогичный Data parallelism решаеться из коробки готовым и удобным выскоровневым API — через Parallel.ForEach, но все это не имеет поддержки асинхронного API. А вот TPL.DataFlow как раз и был сделан для этого(поддержка асинхронного апи на высоком уровне для Data parallelism) — просто популярностью не пользуеться потому, что люди вместо взять готовую билиотеку решают эти задачи как попало, написание кучи лишнего кода. Если все подсумировать изложенное — люди не умееют практически пользоваться фреймворком, а заучивают низкоуровневые вещи характерные для C/C++ разработки и проводят по ним интервью, а впоследствии не умеют использовать возможности фреймворка, потому что это считаеться стандартом и об этом писал Рихтер и другие.

Без обид, но спор уже идет с каким-то Рихтером в голове, а не с книгой. Я открыл честно украденное 4е издание — упомянутые тобой Parallel.For, ForEach, Invoke есть в оглавлении, страница 713. Потом идет PLinq

Страница 700 — рассказ про таски.

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

Я так понимаю, что Dataflow популярностью не пользуется, потому что в 80% случаев достаточно вариантов producer-consumer с bounded queue или continuation tasks а если идет выход за границы процесса (что, в принципе, is a must для случаев когда мы начинаем пилить пайплайны), то dataflow, насколько я понял, ничего из коробки для этого не содержит.

Ладно — у нас явно проблемы с пониманием друг друга и то, что вы пишете скорее отстаиваете свою позицию(что Рихтер хороший кейс для обучения) и спорите со мной постоянно на новые\старые тезисы — аргументируя это тем что то ли dotnet как и раньше, только еще не вышли фичи, то ли они не нужны широко :) Это бесполезное занятие — как по мне определяющими есть другие моменты вокруг, которые вы не уловили похоже в моих репликах.

Я так понимаю, что Dataflow популярностью не пользуется, потому что в 80% случаев достаточно вариантов producer-consumer с bounded queue или continuation tasks а если идет выход за границы процесса (что, в принципе, is a must для случаев когда мы начинаем пилить пайплайны), то dataflow, насколько я понял, ничего из коробки для этого не содержит.

Странно, что вы так смело судите о надобности\ненадобности технологий, с которыми, судя по всему, никогда не работали. :)

Могу предложить вам решить следующий кейс, есть 100 штук объектов в коллекции, надо применить какую-то логику, которая обращается к базе или веб-сервису и убедиться, что, как под семафором, одновременно это обрабатывается не более чем в 10 параллельных веток вычислений, при этом это асихнронный код и после выполнения этих операций управление переходит без блокирования потока в вызывающий и возвращает валидное состояние — предложите решение на .net с использованием примитивов concurrent collections или любых других апи — если по вашему это можно решить элегантано без задействования этой библиотеки.


          var ids = Enumerable.Range(1, 100);
          var httpClient = new HttpClient();
      
          var actionBlock = new ActionBlock<int>(i => httpClient.DeleteAsync($"http://something.com/{i}"), 
new ExecutionDataflowBlockOptions(){MaxDegreeOfParallelism = 10});

          ids.ForEach(i => actionBlock.Post(i));
          await actionBlock.Completion;

Так, навскидку, у SemaphoreSlim есть метод WaitAsync, который позволяет довольно просто и эффективно решить поставленную задачу. Наверное, пример не совсем удачный.

Как вариант, но получиться так же как если использовать Linq vs циклы для сортировки. Думаю, что выбор очевидно в чью пользу будет, если касается вопроса удобства и простоты использования.

Я в свое время такую штуку немного допилил sergeyteplyakov.blogspot.com/...​2015/07/foreachasync.html. Получилось еще проще, чем с TPL Dataflow.

await ids.ForEachAsync(
    id => httpClient.DeleteAsync($"http://something.com/{id}"),
    maxDegreeOfParallelism: 10
);

Написал свой аналог DataFlow, а почему готовое решение не взял?

Та я много чего писал 😊. Сегодня довольно часто использую DataFlow, но это из-за того, что в проекте его интенсивно использовали до меня. Раньше меньше его использовал. Что мне не нравится — это исключения. Из недавнего: если финальный блок бросает исключение все предыдущие продолжают работать. И нужно использовать хаки чтобы их остановить. На самом деле не хаки, а просто токен закенселлить, но все равно дополнительные телодвижения когда хочется чтобы все просто быстро отвалилось.

можно на ты, если удобно :)

Отличный пример, подумаю на досуге.

Я косвенно сужу по популярности dataflow по количеству статей с его упоминанием в том же msdn и по активности в репозитории (github.com/...​.Threading.Tasks.Dataflow), ну и я не говорю что dataflow не нужен вообще, а что, зачастую, подобные фреймворки это оверкилл и более простые инструменты решат задачу не намного хуже.

Могу предложить вам решить следующий кейс, есть 100 штук объектов в коллекции, надо применить какую-то логику, которая обращается к базе или веб-сервису и убедиться, что, как под семафором, одновременно это обрабатывается не более чем в 10 параллельных веток вычислений, при этом это асихнронный код и после выполнения этих операций управление переходит без блокирования потока в вызывающий и возвращает валидное состояние — предложите решение на .net с использованием примитивов concurrent collections или любых других апи — если по вашему это можно решить элегантано без задействования этой библиотеки.

В свое время ради прикола запилил полный набор примитивов синхронизации для nodejs, асинхронных и неблокирующих (блокирующие в принципе нельзя), предосталвяющих API на промисах. После этого такие задачки кажутся детскими.

Мне не нравится этот код. Я так понимаю, элементы из исходного IEnumerable копируются во внутреннюю очередь в ActionBlock, какой смысл в этом если в любой момент времени больше 10 элементов там все равно не нужно? Почему нельзя считать 10 элементов, запустить их обработку и по мере завершения функций обработки считывать новый элемент и отправлять его дальше на обработку.

Предположим гипотетический случай, когда кол-во элементов в IEnumerable у нас бесконечно, что сделает этот код?

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

Обработать пачку в 10 элементов и подождать их или не допускать обработки более чем в 10 логических потоков это две разны вещи — а там где есть асинхронное обращение к i\o еще и случае такого алгоритма обработки он будет вполне вероятно значительно медленней из-за наличия critical path в нем. Семафоры работают иначе.

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

Предположим гипотетический случай, когда кол-во элементов в IEnumerable у нас бесконечно, что сделает этот код?

Свалится out of memmory exception.
Если серьезно, как напишешь в логику клиента проход по этому enumerable так и будет работать — энумератор остаеться на стороне клиента, а не библиотеки. Можешь размер буфера настроить и если буфер переполнен прийдется делать логику для балансирования самому.
Этот кейс больше смахивает на реактивную обработку событий, а не Data parallelism — так что бери Rx с Linq синтаксисом лучше.

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

Как-то так. Обработку исключений можно улучшить (как минимум, добавить try на вызов action чтоб синхронные исключения работали так же как и синхронные, подумать о том как обрабатывать исключения самого IEnumerable), но лень писать.

static async Task ParallelForEachAsync<T>(IEnumerable<T> source, Func<T, Task> action, int maxDegreeOfParallelism)
{
  HashSet<Task> currentTasks = new HashSet<Task>();

  foreach (T item in source)
  {
    if (currentTasks.Count >= maxDegreeOfParallelism)
    {
      Task completedTask = await Task.WhenAny(currentTasks);
      if (completedTask.Status != TaskStatus.RanToCompletion)
      {
        break;
      }

      currentTasks.Remove(completedTask);
    }

    Task newTask = action(item);
    currentTasks.Add(newTask);
  }

  await Task.WhenAll(currentTasks);
}

Вариант — ок(справдливости ради отмечу, что из многих велоссипедов сущеествующих для этой задачи выглядит весьма симпатично). Для простой обработки последовательности асинхронных делегатов будет проще DataFlow. Хотя мотивация написать свой экстеншин для задачи и дорабатывать его, вместо взять готовое решение на уровне фреймворка потому, что api в стиле producer/consumer не нравиться мне выглядит такой же странной. Можно было просто завернуть в аналогичный экстеншин обращение к DataFlow api — и не париться о деталях реализации низкоуровневой шаблонной задачи, а писать продакшин код.

Что-то еще меня смутило вчера в этом коде, сейчас посмотрел доку — так и есть — перед обращением к actionBlock.Completion нужно сначала вызвать actionBlock.Complete, без этого Completion не зарезолвится и этот кусок кода будет вечно ждать.

msdn.microsoft.com/...​y/hh160304(v=vs.110).aspx

А вот TPL.DataFlow как раз и был сделан для этого(поддержка асинхронного апи на высоком уровне для Data parallelism) — просто популярностью не пользуеться потому, что люди вместо взять готовую билиотеку решают эти задачи как попало, написание кучи лишнего кода.

Если я правильно помню, эта изначально была левая библиотека (а не часть bcl) и она не прошла через нормальный дизайн ревью в MS (а тогда дизайн bcl держали на высоком уровне, сейчас уже не торт), побочный эфект — реально упоротый API. Я ее использовал на нескольких проектах в свое время. Она отлично работала, но это использовать ее — была боль. Названия классов и методов придумывались какими-то раками под коноплей. Я на следующий день после написания кода не мог вспомнить какой класс мне надо будет юзать для той же задачи, приходилось перечитывать документацию.
Сементика кода, котоырй использует DataFlow очень плохо чувствовалась, это реально был write-only код.

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

В итоге получилось решить задачу с DataFlow, но написать свои костыли было бы в разы быстрее.

Не хочу спросить с очевидно работающим профессионалом в этой области, но все же, видимо, у нас разные крайности — я рекомендовал вещи которые считаю базой, хотя, безусловно, могли подустареть, а ты сразу идешь с cutting edge (например ne-nullable references, версия языка с которыми еще даже не релизнута).

Кроме глобальных изменений мало ощутимых пользователю — появление нового компилятора,SDK, gc, jit и новой модели хостинга приложений(подгрузка зависимостями, развертывание запуск).
Есть и принципиальные изменения в базовых понятиях в последних версиях clr и компилятора —
значимые типы были наделены полной семантикой reference типов.

что это значит? Вот это? docs.microsoft.com/...​emantics-with-value-types

в таком случае я бы поспорил со словами «наделены» — для них такая возможность добавлена, которую надо явно запрашивать используя соответствующие ключевые слова.

Refference типы становятся по-молчанию не nullable.

C# 8.0 еще даже не вышел

Появляются новые примитивы, а для них другой low level api — (пример — вместо string продвигаеться новый тип UTF8String).

который невозможно найти в msdn: social.msdn.microsoft.com/...​&emptyWatermark=true&ac=4

Что касается памяти — GC с его проблемами уже выглядит тоже как не совсем актуальные темы для разговоров с его борьбой с утечками и тому подобное — теперь выделяем память на стеке в коде и используем unsafe инструкции из Managed кода(без unsafe и тому подобное).

и статическая хеш-таблица будет теперь память освобождать и gc стал обходиться без рутов?

Поменялся подход для работы с буферами — вместо Streams повсеместных, продвигаеться Span, Memmory и Slices.
С появлением low alloc апи начали появляться новые требовательные к производительности и памяти возможности для работы с растром, графикой написанные на C#(то что всегда до этого делалось на C++ и вызывалось через P\Invoke) и тому подобное.

это круто

Дотнет сстал нацелен на другой класс задач похоже, другие требования и т.д. то куда он развивается, а все(или большинство) о чем написано у Рихтера в последнем издании на этом фоне меняется либо теряет актуальность в той или иной мере.

Но не все

К чему я это — если на интервью приходит человек и интервьюер или кандидат начинают с любимых вопросов чем отличаются классы от структур и начинают обсуждать, что одни ссылочные другие значимые — это не совсем как бы уже и так всё.

Без тонны in/reference value это все еще так. Сама идея того, что одно на стеке другое в куче никуда не девается

Не хочу спросить с очевидно работающим профессионалом в этой области, но все же, видимо, у нас разные крайности — я рекомендовал вещи которые считаю базой, хотя, безусловно, могли подустареть, а ты сразу идешь с cutting edge (например ne-nullable references, версия языка с которыми еще даже не релизнута).

Дело не в крайностях — вот надо только новое учить. Учить надо вещи, которые можно применить для актуальных задач правильным образом.

что это значит? Вот это? docs.microsoft.com/...​emantics-with-value-types
в таком случае я бы поспорил со словами «наделены» — для них такая возможность добавлена, которую надо явно запрашивать используя соответствующие ключевые слова.

:) Можете не соглашаться — паралельный пример в .net 1.0 тоже была распаковка упаковка, а потом появились generics. Упаковки\распаковки и объектного полиморфизма в принципе по-умолчанию тоже вполне хватало если следовать такой логике, ведь Generics тоже требовали использования других ключевых слов, хотя оба инструмента используються для решение одного класса задач.
В случае generics это безопасность типов, в случае с ref struct это сокращение аллокаций(которое до этого ограничевалось областью локальных значимых переменных).

C# 8.0 еще даже не вышел

Зато есть на MSDN.

и статическая хеш-таблица будет теперь память освобождать и gc стал обходиться без рутов?

Обычно я и мои коллеги не сталкиваются с memmory leaks или проблемами с managed памятью, когда работаю со статической коллекцией — меня волнует ее размер и я понимаю, что она будет жить пока жив домен или хост — возможно у вас есть более удачные примеры где надо понимание GC оптимизаций, что бы справиться со статической хеш таблицей .
Для того что бы понимать жиззненный цикл обьекта, не обязательно знать токности оптимизации GC или работы финализатора с поколениями — оптимизации возникают обычно в совершенно других классах задач, с которыми люди работают на куда более низком уровне, другими требованиями в плане SLA и т.д. И здесь разработчики MS решили, что им будет проще сделать апи с минимальными аллокациями(о которых у Рихтера ничего не найдете) для этих задач — чем следить за тем насколько правильно в их обьектах реализова Dispose паттерн или оптимизировать gc stw паузы :)

Без тонны in/reference value это все еще так. Сама идея того, что одно на стеке другое в куче никуда не девается

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

Те примеры, за которые мы зацепились далеко не полный список концептуальных изменений, если копануть глубже и начать рассматривать все, что уже включёно в платформу как стандарт — fdd/scd развертывание, type forwarding, multiple target compilation, symbol tree analysis, новые апи компилятора и т.д. Начать разбираться с этим то сама по себе организации работы с кодом, класс повседневных проблем будет куда более широким чем то о чем писал Рихтер и было актуально 10 лет назад.

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

Это довольно специализированные инструменты с большим количество ограничений, к примеру:

The goal of keeping a ref struct type as a stack-allocated variable introduces several rules that the compiler enforces for all ref struct types.

You can’t box a ref struct. You cannot assign a ref struct type to a variable of type object, dynamic, or any interface type.
You can’t declare a ref struct as a member of a class or a normal struct.
You cannot declare local variables that are ref struct types in async methods. You can declare them in synchronous methods that return Task, Task or Task-like types.
You cannot declare ref struct local variables in iterators.
You cannot capture ref struct variables in lambda expressions or local functions.

Безусловно, это крутые вещи и знать о них полезно, но дихотомия ref/value никуда не девается, потому что это, в принципе, философское различие — у одной вещи концептуально есть/может быть identity, а у другой нет (не должно), из которого вытекают особенности размещения в памяти: хип или стек и работы с ними.

Roslyn — да, это был большой шаг вперед. type forwarding — возможно это что-то новое с тем же именем, но TypeForwardedToAttribute был в дотнете очень давно.

Это довольно специализированные инструменты с большим количество ограничений, к примеру:

Если вдуматься в смысл эти ограничений, станет ясно — что это запрет на любые ссылки из этих структур на heap. Такая структура не производит холостых аллокаций и безопасна для интенсивных CPU-bound вычислений, не забивает стека вызова мусором и не создает нагрузки на GC — т.е. такими структуры и должны быть.
Если для разработчика это ограничения — тогда не понятно зачем ему вообще использовать структуру, а не взять класс — ведь ему нужен доступ на heap из структуры так или иначе, толи что бы ссылаться напрямую из свойст на heap для внутреннего состояния, толи что бы сохранить состояние замыканием(через heap), или пробросить в другой поток например в продолжении i\o-bound асихнронной операции — тоже через heap.
По поводу сферы применения это действительно надо не в каждом высокоуровневом приложении, эти подходы делались в основном, что бы исправить архитектурные гепы в .NET и заменить старое неконкурентноспособный api в тех сфера где MS сейчас активно борется за рынок.
github.com/...​ob/master/docs/roadmap.md

type forwarding — возможно это что-то новое с тем же именем, но TypeForwardedToAttribute был в дотнете очень давно.

Раньше это был просто мапинг типов в метаданных, сейчас это built-in механизм для вызова кода собранного под разные платформы, который может использовать platform specific api где-то внутри и как такового никакого маппинга не требует.

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

А если бы она началась и шла в русле нашей нынешней беседы 🍻, что я бы, скорее всего, написал в отзыве что видимо произошел misleveling человека и надо его-ее оценивать как на уровень-два выше.

p.s. Вот этот комментарий меня смутил сразу, и я решил уточнить

Refference типы становятся по-молчанию не nullable.

MSDN Magazine пишет что не становятся, наверное прагма будет или еще что-то такое :)

To avoid overwhelming developers with warnings as soon as they start using the C# 8.0 compiler, instead Nullability support will be turned off by default—thus no breaking change. To take advantage of it, therefore, you’ll need to opt-in by enabling the feature.

А если бы она началась и шла в русле нашей нынешней беседы 🍻, что я бы, скорее всего, написал в отзыве что видимо произошел misleveling человека и надо его-ее оценивать как на уровень-два выше.

А я всего лишь описал случаи, когда для переменной типа структуры будет вазван boxing. :)

вернемся тогда к оригиниальному моменту который вызвал подспорье.

Надо прочесть и понять Рихтера, CLR via C#, и тогда можно будет иногда и погнобить самих интервьюеров.

и это не какое-нибудь интернирование строк, работа с weak reference/GCHanlde или особенности вызова в clr .call virt. а совершенно базовые вещи по Рихтеру :)

Не совсем понял последнее предложение, но, если мне память не изменяет, интернирование, gchandle, weak references — это все было в Рихтере. Понятное дело, что того, чего в природе не существовало на момент выхода книги там не будет.

И вообще — много ли проектов на .net core? потому что из того, что я вижу, для .net framework почти все актуально. То, о чем ты говоришь, это специальные случаи, которые в ежедневной практике большинство программистов просто не увидит, по причине ненадобности.

Безусловно, Рихтер неидеален (и, к тому же, по языку я рекомендовал другую книгу, которая мне до сих пор нравится), и если топикстартер попросит, то можно набросать список глав которые можно пролистать вместо чтения, но, опять таки, есть системный подход, когда в получении знаний есть какая-то организация, а есть подход «левша-самоучка, который нахватывается знаний из блогов». Я сторонник системного подхода и советую изучать так, как я изучал это. Безусловно, чтение того же ayende.com тоже помогало сильно, равно как и блоги Липперта и прочей C# тимы, но я считаю что туда стоит идти уже с базой, чтобы базу корректировать.

Данные вопросы действительно задаются и «не джунам». На собесах часть из перечисленного(примерно 50%) не спрашивают — все-таки делают скидку, что кандидат на джуна. Вопросы немного проще. А вот на мидла спрашивают и не такое %)

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

что лучше — Ява или СиШарп?

Или чай, или остров, или чай на мотоцикле на острове

— Ты кого больше боишься за рулем?
— Солдат.
— А еще кого?
— Мотоциклистов.
— А еще?
— Пьяных.
— А женщин не боишься?
— О! Женщина за рулем — это пьяный солдат на мотоцикле. ©

Чем структура от класса отличается.
... И хватит.

Точно ООП, синтаксический сахар, поверхностно CLR, GC, GAC, .NET, отличие reference/value type, отличие интерфейса от абстрактного класса, виртуальные/абстрактные члены, что может/не может быть в интерфейсе, дженерики, переопределение/перегрузка, сигнатура, делегаты/ивенты, IDisposable, boxing/unboxing, какие-то простые задачки — в духе поменять местами строчки в двухмерном массиве, sql (distinct, joins, group by, возможно with). Плюс теория по тем технологиям, которые указаны в требованиях по вакансии.

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

Я понял, что надо раз 3,5,7 может 10 собеседования пройти , и уже будешь знать что спрашивают, что надо ещё подтянуть и тд.
Спасибо

я прошел с третьего раза. Правда семь лет назад)))

7 лет назад были совсем другие требования :) Сейчас они выросли. Значительно. В силу огромной конкуренции и низкой самооценки самих кандидатов: для них главное — попасть. А там хоть даром готовы работать. Вот и требуют поэтому работодатели яйца единорога и кровь девственниц собранную в лунную ночь верхом на грифоне :) Что характерно: немного изучив рынок, невооруженным взглядом видна катастрофическая нехватка мидл и сеньор позиций. Так откуда ж эти мидлы возьмутся, если никто даже месяц обучить не хочет несчастных джунов?:)) Все хотят сразу 0,5 −1+ год опыта коммерческой разработки и английский уровня переводчика:) . Так это... Вы ж брать на работу не хотите, где опыт получить? А это ваши проблемы — где-то возьмите и потом приходите:)))) Все это напоминает цикл while ;)

ну английский уровня переводчика от девелопера никто не требует. А вообще, как я понимаю эти 0,5-1+ год это компенсация за отсутствие профильного образования. Ибо курсы дают отдельные выдержки, заточенные прежде всего как раз на то, чтобы проскочить интервью.

Так откуда ж эти мидлы возьмутся, если никто даже месяц обучить не хочет несчастных джунов?:))

Так джунов хватает и с головой) значит проблема немного в другом. Конкуренция высокая у низкоквалифицированных джунов, которые три месяца на курсы походили и считают, что их должны теперь с руками оторвать. Если человек по совести отучился 3 года в нормальном профильном ВУЗе, то сейчас через курсы при компании так же беспроблемно войдет в айти.

А насчет выросших требований, теорию неплохо спрашивали и тогда, на своем первом собесе я рассказывал в деталях первые 5 НФ. Нафига это джуну вопрос конечно десятый, но тем не менее, знаний нужно было достаточно

Данным отзывом Вы полностью перечеркнули мотивацию людей, которые не имеют «профильного» образования.Я согласен с Вами. Курсы это Г. Но ведь есть люди, которые занимаются самообразованием. Учатся сами или с ментором. И значит, по вашей спецификации у них нет шансов без образования? Я возьму конкретный пример: у меня нет профильного ИТ образования. Но это не мешает мне изучать C# и технологии (уже 8 месяцев как). И, значит я по Вашей же классификации я уже «априори» низкосортный джун (поправка, кандидат на джуна), которых пруд пруди? Для протокола: у меня три высших образования. Но да, конкретно в ИТ области — нет.

Шансы есть всегда. Просто без профильного образования на этапе поиска первой работы их меньше. Есть неплохие шансы устроиться на курсы при компании, но запрыгнуть сразу «на борт» будет сложнее.

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

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

Ну или еще один вариант — пытаться через знакомых попасть на собеседование.

Знаете и тут Вы немного ошибаетесь. Но однозначно правы в том, что резюме приходят сотни. Однако ошибка (я беру в пример опять же себя лично), что нужны какие-то «левые» действия (по-мимо отправки резюме) что бы попасть на собеседование. И уж тем более, через «знакомых». Я могу вам доказать, (опять же, на своем примере и если Вам это интересно), что Вы немного все-таки ошибаетесь. Но через приватное сообщение, да бы не афишировать.:)

Я говорю о повышении вероятности и все

Хорошо. Вы наверное имеете ввиду такое понятие, как «рекомендация». Да, конечно с ней шансы выше. Здесь даже спорить не нужно:)

Сколько людей — столько и мнений.
Критика это хорошо. Я прислушиваюсь ко всем мнениям, и делаю вывод свой уже.
На счёт курсов, не согласен, курсы это хорошо, курсы курсам рознь. Я закончил курсы(6 мес по C#), сейчас все учу и повторяю, разбираюсь в чем не разобрался, читаю Рихтера, и готовлюсь к собеседованию. Они мне дали очень много, и ментор мой поверил в меня и дал мне большой толчок для понимания и освоения этого языка!
И чем больше я понимаю, тем больше мне нравится программирование, мне хочется знать больше, больше языков и технологий.! И у меня нет профильного ИТ образования, но я только задаю себе вопрос, почему я не учил это раньше?!))
Я думаю что даже на собеседовании, если видят, что человек старается, что есть желание, стремлении и горящие глаза, это может сыграть 50% уже прохождения интервью. Но знать конечно должен хоть половину вышеперечисленного у кого-то в коментах.
Вера одного — сильнее неверия тысячи!

Оставьте иллюзию. Всем все равно стараетесь Вы или нет и Ваши горящие глаза так же по боку. Это бизнес. Важны только Ваши скилы. (первое же Ваше собеседование подтвердит мои слова).
А вот вопрос, почему я не учил это раньше? я так же себе задаю:)
А вот Рихтера я бы не рекомендовал. Мало того, что он устарел безбожно, так еще и довольно сложный для понимая новичком. Но тут, как Вы сказали: сколько людей....

Все получится, «Лупайте сю скалу!», просто надо понимать что язык/фреймворк не самоцель, а цель это иметь возможность решить поставленную задачу используя их. В мое время это было так:

"
вакансия 1. c#/wpf
вакансия 2. c#/asp.net/немного html/css
вакансия 3. c# и unity
знание wcf (надеюсь оно уже здохло) приветсвуется, ms sql тоже в плюс"

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

Майндсет «решение задач с использованием языка/технологии» поможет в будущем. Да, я не знаю как работает nodejs, но я видел уже большое количество подобных вещей раньше, и знаю что там ожидать и куда смотреть. Хорошие коллеги, несколько десятков код ревью и я буду писать достойный код на ней тоже. Не советую быть «разработчиком на C#», советую быть разработчиком, который использует C#.

Конечно, на родине где нужны гайкозакручиватели с этим посложнее.

Горящие глаза или их отсутствие могут быть как плюсом так и минусом. Мы недавно не приняли кандидата который ± решил все задачи, но общий вердикт команды был «there is nothing exciting about him».

Спасибо!
Просто C# это мой вход в ИТ!) а дальше буду изучать другие технологии и все остальное. И все получится)

А можете ещё сказать какие вопросы задают на собеседовании junior full stack developer (для back-end учу asp.net и python). Буду благодарен за помощь

Сходите на собеседование и узнаете. Процент того, что Вас возьмут с «первого же раза» очень мал. В интернете много примеров вопросов. Но я Вам повторю святую истину — собеседование это лотерея. Могут спросить сколько будет 2+2 и сразу получите оффер, а могут сказать взять тройной интеграл методом факториала, попутно спрашивая о смысле ядерных реакций по английски :) При этом никому уже не будет интересно, что лауреат нобелевской премии в области химии — ярлык уже висит — НЕ ЗНАЕТ :) Ну, не повезло просто. Поэтому — рассылайте резюме (если готовы) и вперед пороги оббивать:) Иначе — никак.
ПС. Тут кто-то на форуме из джунов говорил, что у него было 10 (!!!) собеседований в разных конторах, пока его взяли. 3 очных и 7 в скайпе.:)

Им же ж ещё на само собеседование позваться надо...

Конечно. Я думаю, что позовут :)

Підписатись на коментарі