Мой поиск работы C# программистом в Нью-Йорке

imageЯ безработный! Теперь у меня будет время написать свою статью на Хабр! Эта мысль пришла ко мне значительно раньше страха перед предстоящими собеседованиями. Итак, мой контракт с инвестиционным банком в Нью-Йорке не был продлен, что явилось небольшой неожиданностью для меня. Мне предстояло съездить в давно запланированный отпуск и сразу по возвращению окунуться в процесс прохождения собеседований. После приятных мыслей о том, как много у меня теперь свободного времени на: домашний open source, Arduino и Хабр; стало приходить понимание, что прохождение собеседования — это отдельный навык, которого у меня нет. Я программист со стажем, работаю им со 2-ого курса, начинал с подработки на исследовательский институт, поработал 2 года в разработке игр, потом около 7 лет в компании, занимающейся аутсорсингом. Эта компания перевезла меня в Нью-Йорк и потом отпустила работать в тот самый банк. Последние серьезные собеседования я проходил 8 лет назад! Я постараюсь рассказать вам о том, каким я вижу процесс поиска работы С# WPF программиста в среде инвестиционных компаний Нью-Йорка. Здесь нет никакой морали — это просто моя история.

Звонок


Время подходит, уже без пяти минут. Музыка выключена, жена спряталась со своим ноутом в спальне, гарнитура подключена к сотовому телефону… Звонок: “Здравствуйте, я хотел бы задать вам пару вопросов по C#...”. “Что? Вот так вот просто, даже не представился? Он будет делать из меня гриль следующие полчаса, а я даже не узнаю как его зовут” — вот, что подумал я после такого начала телефонного интервью.

Процесс интервью на позицию программиста в инвестиционные компании обычно состоит из двух этапов: получасовое телефонное интервью и серия личных встреч. Телефонное интервью — это входной фильтр. Грубо говоря, работодатель не хочет тратить свое время на недостойных, поэтому их стараются отсеять на этапе телефонных интервью. Всю организацию интервью на себя взяла агент. Это обычная практика: работодатель сообщает о незакрытых позициях своим авторизованным агентам, а те уже ищут программистов на рынке ну или спамят им через linkedin. В итоге, программист не ведет переговоры напрямую с потенциальными работодателями — это делает агент, начиная с организации собеседований и заканчивая размером компенсации и датой выхода на работу.

Незнакомец продолжает: “первый вопрос для разминки — чем отличается ref от out?”. А я не знаю. Я программирую на C# 8 лет, и это звучит как простой вопрос, но я действительно не знаю, отличаются ли они. Возможно, это из-за того, что я не пользовался ими. Ну ладно, я лукавлю — я пользовался методом Dictionary.TryGetValue, а там значение возвращается через out параметр. А ref я встречал используя COM из C#. Но мне всегда казалось, что обе эти вещи: возврат значений через параметры и COM — вещи неправильные, архитектурно плохо продуманные и нуждаются в безальтернативном обосновании при их использовании. Я не помню, что я ответил Незнакомцу, но все последующие собеседования я отвечал правильно.

Квадрипликация


imageПочти все вопросы, которые мне задали за пять собеседований, очень детально разобраны в книге Рихтера “CLR via C#”. С этой книгой только одна проблема — прочитав ее очень трудно отвечать на вопросы коротко, потому что вы знаете всё. Вопрос, находящийся на вершине моего хит-парада и очень качественно разобранный в этой книге: “чем отличаются события от делегатов?”. Популярность этого вопроса сильно повысило одно собеседование в офисе.

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

Но это собеседование нарушило все рамки, меня успели поспрашивать четверо, и длилось интервью почти четыре часа! Собственно все четверо задали вопрос про события и делегаты. Отвечая на вопрос четвертого, я достал лист бумаги с написанным мной кодом добавления и удаления подписчиков события при ответе третьему, и у четвертого не возникло дежавю, в отличии от меня. У них был какой-то потертый офис, я все равно не хотел у них работать. Кстати, отвечая на этот вопрос вы неизбежно переведете разговор в мир многопоточности, потому как половина ответа: события имеют потокобезопасную подписку и отписку.

Многопоточность


Эта тема для вопросов — самая любимая. Отчасти потому, что вопросы по многопоточности — самые сложные. Вот набор вопросов, которые мне в той или иной форме задали почти на всех собеседованиях:
  • Что такое lock?
  • Как разрешать deadlock’и на C#?
  • Какие еще средства синхронизации вы знаете?

На самом деле у всех этих вопросов была одна цель — собеседующий хотел, чтобы я рассказал все, что знаю о многопоточности. На вопрос про lock надо сказать и про Monitor, а также из чего состоит структура, ассоциированная с синхронизированным объектом. А вот я не представлял, что делают методы Monitor.Wait и Monitor.Pulse до того, как начал готовиться к собеседованиям. Нужно было рассказать про средства синхронизации пользовательского уровня и уровня ядра, и про гибридные не забыть (Monitor, кстати, гибридное средство). А еще класс Mutex в C# — практически бесполезная вещь. Моя задача всегда была в том, чтобы времени было меньше, чем я могу сказать на тему многопоточности, в частности в C#.

В этой теме я всегда говорил, что едва ли в реальном проекте возникнет необходимость использовать эти средства синхронизации. Всегда, когда возможно, надо использовать высокоуровневую библиотеку Task Parallel Library. Я встретился с непониманием такого замечания на двух интервью. Выяснилось, что обе организации имеют свои собственные библиотеки для работы с многопоточностью. Обе организации не были в курсе, что Task Parallel Library доступна в .NET Framework 3.5. Эти интервью я не прошел, и это к лучшему.

Singleton


Да-да! Меня попросили написать singleton! Я был уверен, что это плохой вопрос для собеседования. Все знают на него ответ. Это просто трата времени.

Это было интервью на позицию в довольно интересную команду. Команда новая, в канадском инвестиционном банке, который планирует расширить свой бизнес в США. У них есть небольшая часть кода на С++ на серверной стороне (вычислительные библиотеки и кое-какая оптимизированная логика вокруг них). Мне нравятся такие проекты, я люблю разные платформы и языки и чувствовал, что уже засиделся на C#. Все шло гладко до этого вопроса про singleton: я уже поговорил с менеджером и казалось произвел приятное впечатление. Кроме того, оба: и менеджер, и собеседующий программист — русские. Я не националист и не испытываю положительных иллюзий относительно своей национальности, просто работать с русскими мне ментально проще. Я их понимаю, даже если не поддерживаю. И тут на тебе — они всерьез считают, что у меня могут быть проблемы с singleton’ами.

Я написал singleton, и после этого мне показали, как увлекательны бывают эти singleton’ы. Меня спросили является ли мой singleton потокобезопасным и попросили сделать его таковым. Тут мне пришлось вспомнить про блокировку с двойной проверкой (double-checked locking). Мы даже обсудили популярность этого подхода в связи с его интересными приключениями в языке Java. Java еще появится в этой истории.

Это нам не задавали


C# 4.0 — нет, не слышали. Так и не были заданы интересные вопросы по последним нововведениям в языке C#. Я очень ждал вопросов про то, что такое ковариация и контрвариация или dynamic и зачем они нужны. Я не должен был этому удивляться — я и сам на работе не использовал С# выше 3.0 и .NET выше 3.5. Просто еще очень мало из инвестиционных организаций перешло на C# 4.0, а многие все еще на C# 2.0.

Мне почти не задавали вопросов по WPF. Был один и довольно серьезный. Как показать таблицу со столбцами, количество которых определяется в ходе работы программы? Есть много способов сделать это, но основная сложность в том, чтобы сделать это не смешивая view и model и без code behind. Я как-то делал это с помощью ITypedList.

“Это не собеседование”


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

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

Позиция, на которую меня приглашали не WPF и даже не C# — это Java позиция. У меня практически не было интервью. Был разговор о жизни с начальником моего знакомого, Робертом. Роб, увидев мое напряжение в середина разговора, сказал: “Расслабься, это не собеседование — мы просто говорим о жизни. Я полностью доверяю Майклу — если он говорит, что ты хорош, то это не ставится под сомнение, тем более твое резюме говорит за тебя. Так когда ты хотел бы начать работу?”. Это было мое первое успешное интервью.

Гонка


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

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

Я стал ждать официальных бумаг от моих знакомых с Java позицией и от любителей singleton’ов на позицию C# WPF. Я называю это гонкой предложений. Агентская контора (они отправляли меня на позицию C#) звонила мне каждое утро, нередко поднимая меня с кровати, с заверениями, что все идет хорошо, и что вот-вот я получу контракт. Я упомянул им, что у меня наклёвывается другое предложение и поднял немного заработную плату, они обо всем договорились с будущим работодателем. Их рвение дошло даже до того, что в одно утро агент взял с меня обещание, что, если я получу контракт в течение 24 часов, то я подпишу его и не продолжу торговаться с другим потенциальным работодателем. Прошло 24 часа — контракта не было, наступила пятница.

Велосипед


imageВ конце недели в пятницу около 4 часов вечера мне позвонил мой знакомый и сказал, что все бумаги готовы и что я получу их в течение вечера. Все так и случилось. В течение выходных я заполнил все бумаги, а в понедельник утром уже сдавал отпечатки пальцев. И вот теперь я — программист на Java! На мой выбор повлияли две вещи: во-первых, мне дали возможность поменять язык программирования, без каких-либо жертв с моей стороны, это чего-то стоит и это аванс мне; во-вторых, этот работодатель ближе к моему дому. До него на велосипеде добираться быстрее, чем на метро — всего 30 минут. Когда я сказал об этой причине агентам, они смеялись, и ответили, что я веселый шутник. Кстати, они были готовы прислать контракт на C# позицию в понедельник утром.

В понедельник я выхожу на работу. Домашний open source продвигается очень медленно, Arduino и паяльник я даже в руки не брал, но зато первую статью на Хабр я написал!

Раскроем имена


Мало ли кому интересно:
Геймдев — я работал в creat studios 1 год и еще 1 год до этого работал в фирме, которую creat поглотил.
Компания, занимающаяся аутсорсингом — это DataArt.
Банк, в котором мне не продлили контракт — Credit Suisse.
Банк, страдающий квадрипликацией — Royal Bank of Canada.
Банк, предложивший C# позицию — TD Securities.
С понедельника я — программист на Java в Bank of America / Merrill Lynch.
Метки:
Поделиться публикацией
Комментарии 194
  • +43
    грустно все-таки менять C# на Java…
    • +15
      Главное что бы человек был хороший ;)
      • +7
        А я поменял с удовольствием.
        • 0
          А интересно, почему с удовольствием?

          Не ради забавы спрашиваю, а реально хочется узнать, что такого вы нашли в Java (ну кроме её распространённости на большее количество платформ), чего не было в C#. Дело в том, что я сейчас тоже Java-программист, который перешёл с другого языка, правда с C++, и мне почему-то Java и большой радости не испытываю — Java мне всё больше и больше представляется огромным костылём (хотя могу быть и не прав), с помощью которого пытались решить одну проблему, а наплодили кучу других… Я как бы через ваш ответ оценю ещё и C#, поскольку «программировал» на нём только чисто академически (считай не программировал).
          • 0
            У Java всё есть определённые преимущества перед C++: переносимый байт-код, что позволяет распространять модули в собранном виде (да и вообще относительно легко построить модульную систему), практическое отсутствие Undefined Behavior, быстрая компиляция, наличие рефлексии, развитая инфраструктура, тысячи хороших протестированных библиотек. Но толковых шаблонов, конечно, не хватает.

            Много писал на Java, немного на C#. Как язык C# неплох и местами удобней Java, но инфраструктура мне, честно говоря, не очень нравится. Для java есть хорошие бесплатные IDE, отличные инструменты вроде maven и gradle, куча открытых отличных библиотек. Мне кажется, инфраструктура и распространённость Java выигрывает у C#. Да и из Linux работать с Java как-то проще. Но это субъективные ощущения, с этим можно поспорить при наличии адекватной статистики.
            • 0
              Спасибо за ответ. Я примерно так и предполагал, что уход от привязки к MS привнёс новый положительный опыт. Могу даже присоединиться и сказать, что у меня те же ощущения: Linux однозначно для разработчика наилучшая среда :)

              Но вот чего меня напрягает в java, так это непонятные синтаксические ограничения (я бы даже назвал их тупыми — но не дорос наверное такое говорить). Я сейчас не говорю о том, что в ней нет множественного наследования (и я даже в какой-то мере понимаю почему), но вот почему нет синтаксиса передачи метода в функцию (приходится писать уродский делегат), почему нельзя в не-static внутреннем классе определять static переменные и функции, почему в конце концов нет простого способа передавать простые типы в функцию по ссылке (вроде бы в том же C# есть ключевое слово reference или ref), ну и у меня таких «вопросов на разобрать» накопилось достаточно… Да, я понимаю, что многое из того, что я хочу — это только синтаксический сахар (как тот же enum, который относительно недавно появился, или for(:)), но почему его нет в самом языке? Неужели в C# так же? Или всё же намного лучше?

              P.S. Пожалуйста, не сравнивайте Java с C++ цитатами из первой главы книги «Философия Java»… Про вот эту переносимость модулей, например, без компиляции я уже наслышан — и это откровенная ложь. Для того, чтобы это понять достаточно просто взглянуть на сектор мобильных ОС, где Java в принципе присутсвует только на Android, да и там всё под неё пересобирать нужно. А отгадайте, на каком языке чуть ли не из коробки можно программировать под все актульные на сегодня платформы. Вот и получается, что Java вся такая переносимая, пока не столкнёшься с инфраструктурой, где она совершенно не представлена… Ну и про рефлексию, которой в C++ нет, тоже забудьте (в самом языке её нет, но есть тот же QMetaObject)…

              P.P.S. А шаблонов да, не хватает…
              • 0
                ООП-изм головного мозга создателей Java очень многих удручает. Мне также сильно не хватает простых человеческих функций, не связанных неестественными узами ООП. C++ — мультипарадигменный, позволяет выбирать ту парадигму, которая наиболее подходит в конкретной ситуации. И это, я считаю, очень разумно.
                Потребность в изменяемых входных параметрах лично у меня возникает редко (есть способ их имитации через массив с одним элементом, но это скорее хак). Enum и foreach появились достаточно давно, ещё во времена 1.5, т. е. ~9 лет назад. Enum-ы, кстати, в java весьма замечательные.

                В C# гораздо больше синтаксического сахара. За это его кто-то больше любит, кто-то наоборот. Я воздерживаюсь, отношусь к обоим понимающе.

                Эккеля не читал, поэтому все совпадения случайны, я описываю лишь свой собственный опыт. Переносимость модулей — абсолютная реальность, просто Android — это не совсем Java, у него своя экосистема (поэтому, собственно, Oracle судился с Google). В секторе бизнес и веб-приложений (т.е. java SE и java EE) всё прекрасно переносится: код, скомпилированный на одной машине и ОС прекрасно живёт на других машинах и ОС без перекомпиляции.
                • 0
                  Ну насчёт сроков появления — честно даже не знаю откуда у меня ощущение, что «недавно»… Ну это не суть технического обсуждения.

                  Я не про Экеля вообще, а про любую книгу «начАл» имел ввиду.

                  У меня насчёт переносимости Java свой и не самый приятный опыт: оказалось, что на машине OpenJDK был (с ними-то Оракл вроде не судится — значит там всё нормально должно быть), а если учесть, что он на тех же Ubuntu из коробки поставляется, то можно довольно серьёзно огрести со своим приложением…

                  И мне правда немного непонятна эта истерия по поводу экономии времени на перекомпиляцию: ну потратилось ну часов 5 на полную перекомпиляцию проекта (ну это что-то серверное например), ну и? Главное, чтобы компиляция происходила запуском одного скрипта (как в C++ Boost — скачиваешь архивчик на 70-80 Mb, а он потом на 1.5 — 2 Gb библиотек разворачивается, и всё это запуском одного скриптового файла). Всё равно львиная доля времени потом уходит на тестирование развёрнутой инфраструктуры, чего и при применении Java избежать не удасться. Да и потом, нафига полная перекомпиляция проектов, если как правило половина бинарников было до этого сделано. Тут, мне кажется, главное не думать о том, как бы время на компиляции сэкономить, а как его не экономить на проектировании и разделении проекта на обособленные модули.

                  Ну ладно, спасибо ещё раз за ответы.
                  • 0
                    На самом деле мне после опыта функциональных и динамических языков очень часто не хватает интерпретатора, иногда хочется поиграться со своим кодом, вообще избежав компиляции :)
                    • 0
                      только прошу вас, не пишите свой Groovy!!! :)
        • +7
          И я поменял с удовольствием. Дело тут не столько в языках. Объективно C# обогнал Java, тут еще даже lambda вычисления не подтянули.
          Но вот Linux после Windows субъективно очень приятен, после командной строки много кликать даже как-то напрягает. ИМХО.

          Автор — удачи, максимум через полгода все будет гладко!
          • +5
            У меня был противоположны опыт. С Java ушел на C#, потом быстро вернулся и ни сколько не жалею.
          • +8
            Нет. Очень весело! Можно много нового узнать! Точнее, это неизбежно. Я знал на что шел — мой домашний open source как раз на Java.
            Через некоторое время начинаешь замечать в коллегах ограниченность взглядов. Их незачто винить — они просто не знают как бывает в других языках.
            Это похоже на переезд в другую страну — другой язык, другая культура, другие люди, другие машины. Это весело!
            • +1
              Имею опыт и в том, и в другом. Практика показывает, что со временем уже не важно на чем писать; важны проекты и задачи, которые необходимо решать.
            • +3
              >>Тут мне пришлось вспомнить про блокировку с двойной проверкой (double-checked locking).

              Жесть какая… Есть же Lazy ну или хотя бы про статический конструктор.
            • +3
              Успехов вам на Java-поприще! (*а я ушёл ковырять android*)
              • +7
                Созрел вопрос про уровень английского. Насколько хорошим должен быть инглиш для официального трудоусройства в штатах?
                • +1
                  У меня друг устроился с Upper Intermediate, но это скорее исключение из правила, думаю.
                  • +2
                    Как такового минимума нет. Можно совершенно не знать языка, чтобы легально работать. Документы за вас могут заполнить клерки за определённую плату.

                    Но среди программистов это не популярно. Реальный абсолютный минимум — понимание печатного текста, но таких программистов обычно нанимают удалённо, чтобы они трудились вне США. Так проще и дешевле, если нужны именно такие программисты. В команде обычно хотят видеть людей, которых можно понять, не переспрашивая по пару раз.
                    • 0
                      Для того чтобы понять техническое задание или техническую идею — эдванс вряд ли нужен.
                      Или все-таки нужен?
                      • +1
                        Я думаю понятия уровня английского субъективны. Важно и нужно знать, понимать и уметь говорить на техническом языке, ведь он будет использоваться чаще всего. На втором месте — разговоры о жизни (чтобы понравится тому же менеджеру например). Здесь достаточно обычного «среднего» уровня.
                        • +1
                          Язык нужен в первую очередь, чтобы нормально общаться в рамках рабочего процесса.

                          Как вы объясните коллеге/начальнику почему вы выбрали такое-то решение или такой-то процесс? Как напишите отчет? Предложение? Отстоите свою точку зрения? Убедите кого-то?

                          Разговоры о жизни — это дело второе, к работе мало относящееся, за них вам не платят.
                          • +2
                            Я согласен. Язык очень нужен. Все мои представления об уровнях (Intermediate, Upper ...) пошли прахом, как только я начал ездить в Нью-Йорк в командировки. Эти акценты не описаны в учебниках, им вам не покажет ваш препод нэйтив-спикер. Особенно радуют британцы — они думают, что их английский самый настощий и поэтому не делают скидок.
                            Язык надо учить и как можно больше. Но падение самооценки неизбежно при переезде.
                            • 0
                              Да, акценты/диалекты — то, к чему сложно подготовиться заранее на занятиях.
                              В мою первую зарубежную поездку, в Британию, я ехал с лучшим в своей университетской группе английским, и после многомесячной переписки с партнёром-британцем.
                              В аэропорту меня встретил таксист с настолько резким фермерским диалектом, что я не мог разобрать ни одного слова, серьёзно. Гадал — «это точно английский? если это английский, тогда какой язык учил я??» Действительно, самооценка очень падает :-)
                              Не знаю, как обстоит дело в США, но в Британии разнообразие традиционных диалектов на сравнительно небольшой территории меня не перестаёт поражать.
                              См.тж.: www.youtube.com/watch?v=dABo_DCIdpM
                                • 0
                                  This video contains content from Channel 5, who has blocked it in your country on copyright grounds.
                                  Sorry about that.

                                  • +1
                                    а если попробовать поискать
                                    scottish elevator 11th floor
                                    или типа того? у меня просто данное видео играется без проблем соответвенно можно накидать кучу линков но не факт что пойдут у вас. на крайний случай могу мылом выслать ;-)
                          • +1
                            Хорошее знание языка упрощает жизнь тебе в первую очередь, а остальные обычно подстраиваются. Тем более, в таких городах как Нью Йорк.
                            Поэтому это в твоих же интересах знать язык достаточно что бы понимать и уметь общаться, пусть даже и исключительно для обсуждения технического задания.

                            Если человек на собеседовании себя неуверенно ведет из-за языка, то они первые в списке на «Вы нам не подходите». Ведь первое правило на почти всех собеседованиях — держаться уверенно, это многие любят.
                            Агенты могут продолжать говорить обратное, конечно, но у них другая работа.
                            • 0
                              Уже для поиска работы понадобится. Вернее для всех переговоров и интервью. Когда сам начинал искать работу в Штатах, очень боялся, что не видя собеседника при разговоре по телефону ничего не пойму. И было действительно трудно первое время. Потом вкатываешься в тематику разговоров, и понимать/говорить становится проще, но телефон действительно уровень помогает повысить. Впрочем, потом, когда начинаешь общаться на тему отличную от трудоустройства, понимаешь языковой перекос :)

                              Более или менее приличный разговорный английский необходим, т.к. мне, например в трёх первых местах отказали после интервью с причиной «low communication skills». Я думаю из-за того, что стеснялся что-то не правильно, а в результате мой английский выглядел хуже, чем есть. Кстати, американцы довольно терпимы к плохому языку, если ты показываешь себя профессионалом и хорошим коммуникантом вообще.
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • –2
                              Washington is the capital of United States! Damn, you're not in UK!
                            • +11
                              лет ми спик фром май харт
                          • 0
                            C#, Java… это всего лишь инструменты…
                            Не стоит так близко все воспринимать!
                            Вот если бы вы были, скажем, пианистом, и переучились на ударные по воле судьбы — я бы по сочуствовал :)
                            • +2
                              >Вот если бы вы были, скажем, пианистом, и переучились на ударные по воле судьбы — я бы по сочуствовал :)
                              Кстати не особо сложно переучится: мыслить и двигаться «асинхронно» пианисты умеют, в голове ритм держать тоже :-)
                              • +8
                                Пианино, барабаны… «это всего лишь инструменты...» ;)
                              • –3
                                Я, конечно, возможно и нудный, но программировать на C# 8 лет и не знать самых базовых азов? Возможно в этом кроется причина того, что контракт «неожиданно» не был продлён?
                                • –6
                                  Я имею в виду непонимание разницы между ref и out.
                                  • +21
                                    С учетом того, что использовать out/ref считается не очень хорошей практикой, разницу можно было и подзабыть.
                                    • +3
                                      Мне почему-то кажется, что плохая практика — это когда out используют для возврата несколько результатов, а вот классическая реализация поиска значения в Dictionary через TryGetValue мне кажется идеальной. Без нее сперва приходилось бы выяснять присутствует ли значение в словаре (первый поиск), и лишь потом получать его значение (второй поиск). Либо реализовывать метод, который выдает null для несуществующего ключа (а это самая настоящая плохая практика).
                                      • 0
                                        Да, это один из немногих случаев когда стоит использовать out/ref, но и тот уже реализован в стандартной библиотеке. Как и int.TryParse. Кстати питоновский dict.get(key, value_if_not_found) мне больше нравится.
                                        • +2
                                          Всё от задачи зависит. Мне очень нравится выражение вида if (dict.TryGetValue(«key», out value))…
                                          Если встает необходимость реализации чего-то подобного TryGetValue — тут только 3 пути — генерить Exception, возвращать какой-нибудь default, или out параметр, а сам метод возвращает bool.
                                          С value_if_not_found, ведь, какая беда. Если в dictionary присутствуют значения, совпадающие с value_if_not_found, то можно сделать ошибочный вывод о том, что значения по ключу в списке нет, попытаться его туда добавить и получить exception.
                                          • 0
                                            А вариант возвращать структуру вроде { Success, Value } или Nullable чем не подходит?
                                            • 0
                                              Т.е. вы хотите сказать, что введение новых сущностей в виде специальных структур, написание специального кода для их возврата + написание кода на вызывающей стороне для их передачи в виде аргументов и анализа возвращенного результата пахнут лучше, чем изящная конструкция вида

                                              String value;
                                              if (dict.TryGetValue(«key», out value)) ...?

                                              Nullable ближе, но не вижу в нем особых преимуществ.
                                              • +2
                                                Я хочу сказать что говоря
                                                тут только 3 пути
                                                вы имели в виду
                                                я знаю только 3 пути
                                                .
                                                • 0
                                                  Т.е. тот факт, что Nullable-вариант позволяет использовать в качестве значений Dictionary исключительно структуры, а оба ваших вариант предполагают создание нового экземпляра структуры при каждом вызове, вас настолько не смущает, что вы предлагаете эти варианты в качестве полноценных способов? Можно придумать еще десяток неполноценных вариантов, а смысл?
                                                • 0
                                                  Nullable ближе, но не вижу в нем особых преимуществ.
                                                  Да, Nullable сам по себе не очень интересен и даёт лишь возможность представить отсутствие значения. Однако при наличии должной поддержки со стороны языка и библиотек монадический код с Maybe становится весьма приятным.

                                                  Псевдо-код на Scala:
                                                  def process(req: HttpReq): HttpResp =
                                                      req.param("id").flatMap( Model.byId ).map( toJsonResponse ).getOrElse( NotFound )
                                                  

                                                  Псевдо-код на Haskell:
                                                  import Control.Monad (liftM)
                                                  import Data.Maybe (fromMaybe)
                                                  
                                                  process :: HttpReq -> HttpResp
                                                  process req = fromMaybe NotFound $ getParam "id" req >>= findModelById >>= liftM toJsonResponse 
                                                  
                                                  • 0
                                                    hot fix для Haskell:

                                                    orElse = flip fromMaybe
                                                    process req = (liftM toJsonResponse $ getParam "id" req >>= findModelById) `orElse` NotFound
                                                    

                                                    В этот раз Scala понятнее и лаконичнее получилось.
                                          • +5
                                            … либо реализовывать нормальные кортежи и паттерн-матчинг. а там уже и до монад недалеко =)
                                            • +1
                                              Или, как в нормальных языках, возвращать Option<V> (тем более что есть структуры и оверхед минимальный).
                                              • +1
                                                Nullable есть, просто методы писались ещё до его введения.
                                                • +1
                                                  Ну а как разобраться, в словаре по ключу действительно null, или это Nullable отработал?..
                                                  • +1
                                                    public struct Nullable<T> where T : struct
                                                    • +1
                                                      Да, понятно, с классами такое не прокатит. Спасибо.
                                                • 0
                                                  Мне кажется, что экзорцизмы вида TryGetValue и TryParse появились из-за отсутствия нормальной поддержки алгебраических типов данных.

                                                  Тот же TryParse мог спокойно выдавать аналог хаскелевского Some.

                                                  В текущей постановке максимум, чем это можно заменить — что-то вроде ParsingResult с полями IsParsed и Value. Тоже тот еще геморрой — в условие спокойно не запихнешь все равно, out лучше.
                                            • 0
                                              Сложно согласиться. Чем больше работаешь и чем больше получаешь опыта, тем «выше» уходишь в абстракции от деталей реализации.

                                              Да, безусловно, базовые вещи важны, но я бы (на месте тех, кто собеседует) взял в команду людей, которые умеют мыслить абстрактно, могут сразу представить себе на уровне архитектуры решение задачи, но затрудняются сказать разницу между ref/out; чем тех, кто на зубок знает любой ответ из серии «вопросы на .net разработчика», а на любой архитектурный вопрос отвечают «ну нам надо создать папочку controllers и сделаем 9 слоёв». Особенно когда эти люди с опытом работы +5 лет и кучей сертификатов.
                                            • +3
                                              >… но программировать на C# 8 лет и не знать самых базовых азов? Возможно в этом кроется причина того, что контракт «неожиданно» не был продлён?

                                              Вас ширина пальцев не напрягает? В дверной проем проходят?
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                              • +4
                                                Я как начал читать, сразу подумал, что это кто-то из ДатаАрт :)
                                                • +1
                                                  А я даже конкретного человека заподозрил :) Более того, каково было моё удивление, когда это оказался именно он :)
                                                • +14
                                                  А вот если бы ты, Владимир, прошел внутренний курс по многопоточности в DataArtе, то double-checked locking там включен в программу!
                                                  • 0
                                                    Т.е. DataArt специально готовит сотрудников, готовых к собеседованиям к конкурентам?
                                                    Выключаю тролль-режим.
                                                    Да, курсы в DataArt — общественно полезная вещь. Я не умел извлекать для них пользу для себя и не ходил на них. Тем не менее, про double-checked locking я знал.
                                                    • 0
                                                      Вообще по multithreadingу был годный курс, и заочный при том.
                                                  • +17
                                                    Вы не поверите, но на вопросе «Напишите синглтон» отсеивается довольно большой процент кандидатов.
                                                    • +6
                                                      За этим утверждением может быть больше, чем кажется на первый взгляд. Половину «отсеившихся» может просто не устроить количество внимания, уделямого синглтонам или другим идиомам с неоднозначной, мягко говоря, репутацией.
                                                      • 0
                                                        Обычно если задают подобный вопрос, то наиболее вероятно, что человек берётся на проект, где используются паттерны. И в таком случае нужен такой человек, который сможет разобраться в коде, где применяются синглтоны, фасады, прокси и иже с ними.
                                                        Если человек по каким-то своим религиозным убеждениям отрицает паттерны, то на данную вакансию он не подойдёт, зачем тратить на него время?
                                                        Вообще, в нормальных конторах, вопросы обычно задают из областей, имеющих непосредственное применение в практике этой компании.
                                                        Спросили про многопоточность — нужен многопоточник. Спросили про UI, JS, jQuery — нужен человек для работы с интерфейсами.
                                                        • +1
                                                          Лихое обобщение. Вот есть, например, оператор goto, законная часть языка программирования. Если человек считает широкое использование goto плохой практикой, это не значит, что он скопом отрицает и весь язык, но если его про этот goto настойчиво спрашивают, это сигнал. Кто-то предпочтет сразу уйти, чем ввязываться в дискуссию зачем, почему, кому оно так надо и уж тем более соглашаться разгребать и плодить такой код.

                                                          нужен такой человек, который сможет разобраться в коде, где применяются синглтоны
                                                          Вот-вот-вот, об этом и речь.
                                                          • +1
                                                            >Вот-вот-вот, об этом и речь.

                                                            Есть ещё и другое объяснение. Вполне возможно, что спрашивающий хочет услышать о плюсах и минусах синглтона. Если же пациент даже не слышал ничего об этом паттерне, то как можно с ним работать? Надо же знать, когда можно применять паттерн, а когда он вреден.
                                                            Поэтому не надо думать, что если вас спросили про синглтон, то в проектах придётся иметь с ним дело. Может быть, что как раз наоборот.
                                                            • 0
                                                              Если занудтствовать, то изначально речь шла про написать, а не рассказать.

                                                              Если же пациент даже не слышал ничего об этом паттерне, то как можно с ним работать?
                                                              Почему нельзя работать со специалистом, если он умеет думать, учиться и решать задачи? Не знает, как правильно готовить синглтоны, т.к. не применяет их, можно показать реальный код того же самого double-checked locking, обрисовать ситуацию его использования и попросить поразмышлять, зачем оно так сделано, можно ли сделать иначе, встречались ли подобные задачи раньше и как они решались? А то может получиться, как в статье — контора про Task Parallel Library не слышала, зато изобрела свой велосипед и будет теперь пытаться всех на него пересадить.
                                                      • +1
                                                        В свете описанной статьи я даже не могу считать себя программистом на c#, я просто не знаю названий общепринятых паттернов программирования, но блин посмотрел гугл,… я этим постоянно пользовался, причем с самого начала правильным методом — иннициализация статического объекта сразу при объявлении (тонкости уровня double check locking… не ведал).
                                                        • +1
                                                          Ну дурацкий же вопрос, хуже может быть только требование наизусть перечислить параметры какого-нибудь стандартного метода. Для любого языка можно быстро нагуглить статью, в которой будет написано, как его реализовать и на что обратить внимание. И в реальной жизни оно так и делается: нагуглил, реализовал, протестировал и забыл.

                                                          А если хотите проверить навыки проектирования, правильнее будет спросить что-то вроде «Что такое синглтон, зачем он нужен, какие проблемы с ним связаны»
                                                        • +30
                                                          Примерный уровень предложенных зп можно озвучить если не секрет?
                                                          • +1
                                                            С этим поможет ресурс www.glassdoor.com
                                                            • +1
                                                              Позволю себе ответить за автора.

                                                              Есть забавный сайт — salary.com. Согласно его данным годовой оклад разработчика на Java в NY составляет около 100к$. В банковской сфере еще +10-20% добавляют, Ссылка: swz.salary.com/SalaryWizard/Java-Developer-Salary-Details-New-York-NY.aspx
                                                              • 0
                                                                Интересно, а это до вычета налогов, или после?
                                                                По ссылке пройти не удалось, оно у меня не открывается :(
                                                                • +6
                                                                  Все цифры, касающиеся зарплаты, в Северной Америке — до налогов. Налоги — зависят от множества факторов типа семейного положения, детей и т.п., так что посленалоговая сумма от одного случая к другому может прилично отличаться.
                                                                • 0
                                                                  У программиста в финансах в Нью-Йорке $120K — это стартовый уровень. Разумеется, до налогов.
                                                              • +7
                                                                Вы теперь Java-банкир! Поздравляю!
                                                                • +2
                                                                  creat это прям кузница кадров ;)
                                                                  • +1
                                                                    В моем случае это не creat. Это скорее все-таки был DataArt.
                                                                  • +1
                                                                    Стыдно признаться, я и с G+ разобраться не могу. А он, в отличие от в общем-то ненужного и безболезненно удаляемого фейсбука, нужен.
                                                                  • +1
                                                                    а почему геймдев бросили?
                                                                    • 0
                                                                      Я не автор, но геймдев, — это жестокие спурты. Не всем подходит.
                                                                      • +3
                                                                        Извините, жестокое что?
                                                                        • 0
                                                                          Спурт. Также применяется при описании некоторых практик в разработке.
                                                                      • +1
                                                                        Ну я был молод. Попросил зарплату $800 (у меня была $400), мне дали $600. Я обиделся, а два других работодателя предложили $1000.
                                                                        Я тогда был студент еще — мне все было интересно, C# и .Net появились не так давно.
                                                                        Вообще от геймдева очень положительные впечатления. Там очень сильное коммьюнити.
                                                                      • 0
                                                                        Хотелось бы небольшой апдейт по статье по части документов и налогов. Являетесь ли вы резидентом США, если нет какую визу используете, как получали? Что с налогами?
                                                                        Спасибо.
                                                                        • +1
                                                                          Совершенно очевидно, что у автора есть какой-то вид разрешения на работу. Жареные факты по получению виз: www.uscis.gov. По большому счету, какая разница? Работодателю, по большому счету, пофиг. В форме I-9 все написано.

                                                                          С налогами у него все так же, как у всех. Или Вы думаете, автор для налоговой чем-то отличается от всех остальных? Резидентом для налоговых становится любой человек, кто прожил больше 180 дней календарного года в стране.
                                                                          • 0
                                                                            Человек решил поделиться информацией, за что ему большое спасибо. Мне же еще интересны аспекты, которые я описал выше, если автор что-то и про эти вещи расскажет, то ему еще больший респект. Может быть в отдельной статье, на хабре куча статей про дауншифтинг, и не так уж и много про работу в западных компаниях.
                                                                            • +1
                                                                              По визам:
                                                                              — основная рабочая виза H1-B. Позволяет работать на любого работодателя через процедуру h1b transfer. Требует sponsorship — т.е. нужно найти работодателя, который готов для вас сделать эту визу. На год выделяется квота в размере 65 000 (может меняться). Квота обновляется с 1 апреля, тогда же компании могут начинать искать кандитатов и подавать заявки. Реально визой можно пользоваться с 1-го октября (въехать в страну и начать работать). Виза, а точнее H1-B статус, даётся на 3 года. Можно получить 2 раза подрят без перерыва.

                                                                              — ещё один тип виз — L1. Часто используется, когда у компании есть представительство в США и они привозят своих сотрудников. Не позволяет менять работодателя, но супруг(а) может работать (по H1-B — нет).

                                                                              С точки зрения налогов — кто прожил больше 180 календарных дней, тот становится налоговым резидентом. Если нет, есть определённые схемы как с этим быть (подробностей не знаю) и по какой ставке платить. Налоги для налоговых резидентов одинаковые, разницы между типами виз нет. Есть налог страны, штата и города (может быть ещё какая-то парочка местных). Если с первым всё просто, то с другими зависит от конкретного места жительства. Ставки налогов легко можно найти в поисковике.
                                                                          • +2
                                                                            Небольшого апдейта не получится. Это тема на целую статью. Я подумаю, что можно с этим сделать :)
                                                                            Но вот люди наверху правильно отвечают.
                                                                          • +4
                                                                            Эти команды занимаются одними и теми же проектами, делая и переделывая один и тот же функционал.
                                                                            Какое уныние…
                                                                            • 0
                                                                              В чём то есть и свои плюсы. К примеру то что осталось на уровне костылей, тут можно уже реализовать «красиво». Или то что не удалось реализовать там, так как текущая структура уже не могла этого позволить, тут можно заложить в начале. Ну или то что делалось там в 3-4 подхода, так как не всегда можно предвидеть всё, тут можно сделать в 1-2.

                                                                              В чём-то всё таки есть плюсы. Ведь чем больше делаешь, тем больше развиваешься и тем больше хочется отмотать время назад и тот или иной кусок кода, переделать.
                                                                              • +2
                                                                                Ну так-то так, но ведь и озвереть можно, реализуя одно и то же несколько лет кряду.
                                                                            • 0
                                                                              А зимой у вас не холодно, на велосипеде на работу?
                                                                              • 0
                                                                                Судя по Википедии, зимой температура в среднем не опускается ниже нуля. Так что вполне можно кататься на велосипеде весной-летом-осенью, а также и зимой в термокостюме без проблем (при должном на то желании).
                                                                                • +1
                                                                                  Да температура мало о чем говорит, если честно. Я живу в Ирландии, тут зимой редко бывает ниже нуля. Но при этом — дубак тот еще, т.к. влажность 100%, и ветер сильный.
                                                                                  • +2
                                                                                    > Я живу в Ирландии, тут зимой редко бывает ниже нуля. Но при этом — дубак тот еще, т.к. влажность 100%, и ветер сильный.
                                                                                    Так это же погода Нью Йорка! Океан рядом, поэтому влажность и ветерь в силе.
                                                                                  • 0
                                                                                    Фактическая температура очень сильно отличается от ощущаемой. В NYC может приключтся снежная буря при температуре около нуля. При этом в Альпах или Татрах при -15 будет гораздо приятнее и «теплее».
                                                                                  • +2
                                                                                    У нас в Сибири :) ещё в -20 на велосипеде на работу было нормально. А вот в -25 борьба за предотвращение обморожений уже перевешивала остатки удовольствия… ;)
                                                                                    • +3
                                                                                      Я зимой не буду ездить. Я, на самом деле, вообще еще не ездил на работу на велосипеде никогда в жизни. Это моя мечта. Я почти ее реализовал на предыдущем месте: оформил пропуск в хранилище великов, получил доступ в душ в фитнесс-клубе и ждал весны. Но контракт закончился…
                                                                                      • 0
                                                                                        Зря ждал) Я в питерский датаарт всю зиму катаюсь, до -15 отлично. Если температура ниже то уже не очень комфортно)
                                                                                        • +1
                                                                                          Женя, да ты маньяк )
                                                                                    • 0
                                                                                      Смелый шаг — вот так взять и поменять язык. С другой стороны у вас огромный опыт в C# и Джава дастся легко, да и в ней много чего интересного, а это знания, развитие, а значит все хорошо.
                                                                                      • +1
                                                                                        На мой взгляд, все истории со «сменой» языков программистом по своей сути имеют аналогию со сменой транспортного средства водителем. В случае C# и Java по большому счету речь идет об «автомобилях» практически одного класса. В конечном итоге, задачей водителя является доставить груз из точки А в точку Б и его профессионализм определяется не тем, насколько ты хорошо осведомлен каким количеством болтов прикручена крышка бака в твоей колымаге, а в целом способностью сделать свою работу хорошо и в срок и пониманием, что вот на этом много и далеко не увезешь, а на этом вот агрегате зря вы по полю для гольфа ездите — ему место на гоночной трассе.
                                                                                      • 0
                                                                                        В тунеле нет возможности проехать на велосипеде?)
                                                                                        • +1
                                                                                          Если ехать со скоростью потока — то теоретически можно проехать и потом получить люлей от полиции. А вообще он довольно узкий (картинка) и в добавок платный.
                                                                                        • +1
                                                                                          > а в понедельник утром уже сдавал отпечатки пальцев.
                                                                                          А кому сдавали? Это именно тот банк требует? Как часто такое практикуется у работодателей в США?
                                                                                          • 0
                                                                                            В банках всегда нужно сдавать отпечатки. А еще бывает тест на наркотики, довольно часто.
                                                                                            • 0
                                                                                              Почти все крупные финансовые конторы это делают. Обычная практика.
                                                                                              Так же часто пробивают через ФБР, проверяют прошлые места учебы и житья, тест на наркотики и прочее.
                                                                                              • 0
                                                                                                >Так же часто пробивают через ФБР
                                                                                                А у них это легально?
                                                                                                • +2
                                                                                                  Вы же на это соглашаетесь и даёте разрешение.
                                                                                            • +1
                                                                                              Интересная история.
                                                                                              А еще класс Mutex в C# — практически бесполезная вещь.
                                                                                              Ну, не скажите, я его использую, например, для отслеживания случая запуска более чем одного экземпляра приложения одновременно… Или для проверки того, что не запущено обновление/установка приложения одновременно с самим приложением… Очень удобно.
                                                                                              • 0
                                                                                                Согласен. И это единственное его здравое применение. В других случаях лучше использовать средства синхронизации пользовательского уровня, а не уровня ядра.
                                                                                                Кстати, даже в этом случае можно попробовать обойтись системным семафором. А он подешевле мьютекса. Согласны?
                                                                                                • 0
                                                                                                  Чем семафор дешевле мутекса-то, если оба ядренные?
                                                                                                  • 0
                                                                                                    Ядерные, да. Но это ведь не все. На сколько я понимаю, семафор имеет меньше данных ассоциированных с ним. Например, он не поддерживает рекурсивность, а мьютекс поддерживает. Это потери и памяти и скорости. Хотя вот меня учили не судить без профайлера, но тем не менее — кажется, что семафора достаточно и он чуть-чуть легче.
                                                                                                    • +1
                                                                                                      В моем случае с парой-тройкой мьютексов эти отличия погоды не делают)
                                                                                              • +2
                                                                                                Я ещё не дочитал статью, но уже понял, что меня сегодня собеседовали люди её прочитавшие! Позиция такая же, вопросы были те же! Я не зубрил Рихтера перед собеседованием и успешно завалил его. Сейчас думаю, что это к лучшему — пусть парни ищут себе нового коллегу 4-ый месяц…
                                                                                                • 0
                                                                                                  Добавлю, я проходил немало интервью и в лучших местах тоже было что-то вроде разговора о жизни без всяких синглтонов, на любые косяки с которыми можно получить исчерпывающий ответ через пять секунд гугления.
                                                                                                  • +1
                                                                                                    Не совсем соглашусь, особенно если дело касается упомянутой в статье многопоточности. Там баги с корректностью и производительностью настолько неуловимые и часто — тяжело исправляемые, что просто необходимо знать что пишешь в момент написания (а не использовать гугл по факту, когда тормозит или падает раз в неделю).
                                                                                                    Например, мне сегодня сначала предлагали конструкцию i++ обернуть в lock вместо использования Interlocked. Причем об Interlocked человек вообще не знал. А ведь таких аспектов — десятки, потом за такими людьми приходится ужасный код разгребать.
                                                                                                    • 0
                                                                                                      Если видно, что человек может учиться, хватит и 30 минут, чтобы объяснить как нужно делать, знание алгоритмов важнее.
                                                                                                      • 0
                                                                                                        К сожалению, 30 минут не хватит, чтобы объяснить все косяки, которые можно допустить в многопоточных приложениях. И это хорошо, если приложение ложится под SIMD, тут все более-менее просто. Если же алгоритм сложнее — то тут нужны очень сильные навыки многопоточности. Их и за год не выучишь, не то что за 30 минут.
                                                                                                        • +1
                                                                                                          Согласен, знание сложных ньюансов можно получить только с опытом.
                                                                                                          Но не вижу ни одной причины, по которой не стоит работать с человеком, если он хорошо соображает, но имеет мало опыта.
                                                                                                          • 0
                                                                                                            Стоит, безусловно. Но на должности и зарплате junior или middle, в зависимости от результатов собеседования.
                                                                                                            Бывает же люди, которые вообще не знают многопоточность и кое-как знают C# — хотят на senior и оклад $4k — $5k.
                                                                                                      • +1
                                                                                                        Эти баги постижимы и решаемы. Тут проблема в другом, человека заворачивают на мелочах и совершенно не интересуются его способностями к нахождению решений.

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

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

                                                                                                          Одной способности решать проблемы — мало. Важна способность по максимуму не допускать проблемы. А это гораздо сложнее.
                                                                                                          • +1
                                                                                                            Да, ясновидение мало кому подвластно.
                                                                                                            • 0
                                                                                                              Мне очень жаль что понимание предметной области вы сравниваете с ясновидением. Ошибки многопоточности можно месяцами не замечать и они могут очень дорого стоить, если руководствоваться принципом «будет проблема — погуглим» вместо изучения предметной области для минимизации числа ошибок.
                                                                                                              • 0
                                                                                                                Я решу подобную проблему в приемлемый срок, я в своей способности найти решение не сомневаюсь. Но я никогда и никому не буду давать гарантию, что я не совершу ошибок или совершу минимальное, заранее оговоренное их число. Тут у вас передо мной конкурентное преимущество.
                                                                                                                • 0
                                                                                                                  Если найдете — решите, но часто бывает что вы даже понять что проблема существует — не можете. Я тоже гарантии не даю, все ошибаются. Просто те, кто не знает предметной области — делают это не в пример чаще.
                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                            • 0
                                                                                                              Каверзные вопросы — да, не совсем показатель. Но базу знать надо. Если человек говорит что i++ надо оборачивать мьютексом, а не через примитив ЦП делать — это уже флаг отсутствия знания многопоточности.
                                                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                • 0
                                                                                                                  А вот тут я вообще не понимаю проблемы. А почему такой вопрос не может возникнуть? Для меня это стандартный вопрос на собеседовании.
                                                                                                                  От junior'а как раз таких знаний не требуется, а когда берешь senior'а — он должен это знать. И поверьте — многие вообще такие ответы выдают, что от одной мысли о разгребании такого кода — становится жутко.
                                                                                                                  Да и стаж ни о чем не говорит — можно несколько лет работать и постоянно развиваться, а можно 20 лет на попе просидеть и не узнавать ничего нового.
                                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                    • 0
                                                                                                                      Я говорил про вопрос о многопоточности. Как сделать правильно конкурентный инкремент.
                                                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                        • 0
                                                                                                                          ЦП — центральный процессор. Interlocked — как раз разворачиваются в примитивы процессора.
                                                                                                                          Но целовек предлагает сделать:

                                                                                                                          _mutex.WaitOne();
                                                                                                                          _i++;
                                                                                                                          _mutex.Release();

                                                                                                                          Это, извените, недопустимо.
                                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                            • +1
                                                                                                                              Печаль в том, что таких много. Сегодня только собеседовал человека, у которого штук 15 сертефикатов MS по резюме, но при этом он не знает даже что такое IDisposable, или как работает using и т.д. Не говоря уже об архитектуре и тому подобном.

                                                                                                                              У нас не очень большая компания, поэтому HR смотрит только по резюме, по резюме он нам очень даже подходил.
                                                                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                • 0
                                                                                                                                  Да, мы про Россию, в штаты я бы сам был рад бы пособеседоваться. Вопросник как раз сейчас придумываем.
                                                                                                                      • 0
                                                                                                                        К слову — открыл статью по ссылке — там описаны элементарные вещи. Problem solving же в отрыве от скилла недопущения этих проблем — мало что значит.
                                                                                                                        А то выйдет: «ну да, в алгоритме баг, да, мы потеряли деньги и время, ща я баг нашел и уже исправил его, я же problem solver. Ну и что что подобный баг был неделю назад? Я же их решаю!»
                                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                          • 0
                                                                                                                            Нет людей, которые пишут код без ошибок. Но если человек не знает ничего о предметной области, он допускает в разы больше ошибок, о чем и речь. В многопоточном коде это очень критично.
                                                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                              • 0
                                                                                                                                Тут да, может некорректно выразился. Я имел ввиду — что надо знать многопоточность, при написании многопоточного кода. В особенности — если задача не ложится под SIMD.
                                                                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                  • 0
                                                                                                                                    Лучше, но только со снижением позиции и ЗП. Я бы брал, но у меня в отделе просто нет вакансий на мидлов сейчас.