Почему на вопрос «дай пять вещей, которые ты ненавидишь в C #», так сложно ответить во время интервью? [закрыто]

32

В подкасте 73 Джоэл Спольски и Джефф Этвуд обсуждают, среди прочего, «пять вещей, которые каждый должен ненавидеть за свой любимый язык программирования»:

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

Будучи любопытным, я задал этот вопрос любому кандидату, у которого я брал интервью. Никто из них не смог процитировать хотя бы одну вещь, которую они ненавидят в C # ¹.

Зачем? Что такого сложного в этом вопросе? Именно из-за стрессового контекста интервью респонденты не могут ответить на этот вопрос?

Есть ли в этом вопросе что-то плохое для интервью?


Очевидно, это не значит, что C # идеален. У меня есть список из пяти вещей, которые я ненавижу в C #:

  • Отсутствие переменного количества типов в дженериках (аналогично paramsдля аргументов).
    Action<T>,
    Action<T1, T2>,
    Action<T1, T2, T3>,
          ⁞ Серьезно ?!
    Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>

  • Отсутствие поддержки единиц измерения, как в F #.

  • Отсутствие свойств только для чтения. Запись вспомогательного private readonlyполя каждый раз, когда я хочу, чтобы свойство только для чтения было скучным.

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

  • Множественное наследование. Да, это вызывает путаницу, и в большинстве случаев она вам не нужна. Это все еще полезно в некоторых (очень редких) случаях, и путаница применяется также (и была решена в C #) к классу, который наследует несколько интерфейсов, которые содержат методы с тем же именем.

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


Few Несколько человек раскритиковали некоторые сборки в .NET Framework или отсутствие некоторых библиотек в каркасе или раскритиковали CLR. Это не считается, так как вопрос был о самом языке , и хотя я мог потенциально принять ответ о чем-то отрицательном в ядре .NET Framework (например, что-то вроде того, что нет общего интерфейса для TryParse, так что если Вы хотите разобрать строку на несколько типов, вы должны повторить себя для каждого типа), ответ о JSON или WCF совершенно не по теме.

Арсений Мурзенко
источник
52
Why the question “give five things you hate about C#” is so difficult to answerПотому что это вопрос списка, и злой мод закроет его как «
неконструктивный
6
@ Яннис Ризос: хорошая мысль. Кстати, при вводе этого вопроса в заголовок, переполнение стека предупреждает, что «вопрос, который вы задаете, кажется субъективным и, вероятно, будет закрыт».
Арсений Мурзенко
5
Возможно, пространство памяти вашего мозга для того, чтобы ненавидеть языки программирования, в основном заполнено аспектами других языков, с которыми вам приходится иметь дело.
whatsisname
9
Возможно, потому что большинство людей не ненавидят. Ненависть - довольно сильное слово для большинства людей. Судя по списку действительно, очень тривиальных вещей, которые вы «ненавидите» в C #, чувак, я бы очень не хотел быть рядом с вами, когда есть какая-то причина действительно ненавидеть что-то. Я подозреваю, что ваша голова взорвется. Я также подозреваю, что составление списка затруднительно для большинства людей, так как вам пришлось очень напрягаться, чтобы составить список, и у вас было несколько дней, чтобы подумать об этом.
Данк
19
Вы заметили, что все элементы в вашем списке были о том, что чего-то не хватает, а не что-то сделано неправильно На мой взгляд, вы не смогли ответить на вопрос интервью. Каждый может перечислить функции, отсутствующие в языке, и объявить это причиной ненависти, но наиболее ненавистным языком будет тот, который обладает всеми функциями.
Стилгар

Ответы:

42

Если бы мне пришлось угадывать:

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

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

  3. Мало кто особенно критичен. Они видят преимущества и особенности, а не недостатки. Им трудно перейти к такому образу мышления, если интервью не пойдет так.

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

Telastyn
источник
22
Что касается № 2, мы предпочитаем Software Simians , сэр.
toniedzwiedz
@ Том подумал, что это пан программист .
Стефано Борини
9
@Telastyn не должно быть пять пунктов пули в вашем ответе?
Бен Джексон
# 4 - это то, что сразу пришло мне в голову, особенно в рабочих средах, которые стремятся использовать C #. Учитывая обычное собеседование и советы по поведению на рабочем месте, вопрос об этом во время собеседования может показаться приманкой для выявления «плохого отношения», из-за которого они не хотят нанимать этого человека. В отличие от судебного преследования, собеседование при приеме на работу вряд ли будет эффективной защитой. ;-)
Dronz
35

Я полагаю, что на вопрос так сложно ответить во время интервью, потому что это:

  1. Действительно неожиданно,

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

  3. Трудно ответить вообще за короткий промежуток времени (если не подготовлено до собеседования).

1. Это неожиданно

Неожиданные вопросы действительно сложны, особенно в стрессовом контексте. Представьте следующий диалог во время интервью:

- Какая разница между HashSet<T>а List<T>?
- Хешсет оптимизирован таким образом, что поиск элемента очень быстрый. Например, если вы используете set.Contains()внутри цикла много раз, перемещение setиз списка в hashset может ускорить процесс.
- Как создать свойство только для чтения?
- Я использую поле, помеченное как readonlyвспомогательное поле для свойства, которое имеет только геттер.
- Какое использование sealed?
- Вы используете его для классов, которые не должны быть унаследованы.
- В последний раз вы видели дантиста?
- Какая?!

2. Это требует много другого мышления

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

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

3. Это требует времени

Честно говоря, у меня есть список из пяти (на самом деле больше) вещей, которые я ненавижу в C #, но я думал об этом в течение длительного периода времени. Несколько вещей из эпохи .NET Framework 2; большинство проблем, перечисленных для .NET Framework 2, больше не действительны, потому что они были удалены, некоторые с LINQ и всем этим функциональным программированием, другие с динамическим программированием. Я не уверен, смогу ли я без подготовки этого вопроса найти все пять элементов во время интервью.

Арсений Мурзенко
источник
3
Я думаю, что вы в целом правы, но программирование на определенном языке в течение достаточного времени просто заставит вас ненавидеть определенные «особенности» этого. Как какой-то список совпадений. Или, по крайней мере, у меня есть один для каждого языка / платформы, которые я когда-либо использовал. Или, может быть, я просто избалован и придирчив.
К.Стефф
2
@ K.Steff: «Хит-лист» - идеальное название для него :). Конечно, я могу думать о более чем пяти проблемах даже с моей любимой платформой; если вы спросите меня о языке, который мне не нравится, но был вынужден использовать (например, Java или Python), я, вероятно, мог бы работать часами: P.
Тихон Джелвис
1
Сможете ли вы легко запомнить те вещи, которые вы ненавидите в языке, будет зависеть от того, насколько неприятны «особенности» по сравнению с другими вещами, с которыми вам приходится иметь дело. Например, большая часть моей работы связана с взаимодействием с определенной (и особенно ужасной) внешней системой и ее API. Большинство жалоб по поводу C # / .NET бледнеют по сравнению с ними и оказываются в глубине души.
Дэн Лайонс
Замечательно, что вы можете отслеживать «список совпадений» для каждого языка / платформы и носить его с собой, поскольку вы программируете на определенном языке в течение «достаточного времени». Тогда есть другие, которые просто не удосуживаются заняться этими проблемами после программирования на «достаточно времени». То, что делают другие, - это найти решение проблем в своем списке попаданий, и им больше никогда не придется беспокоиться о проблеме списка попаданий, потому что они заставили ее исчезнуть. Если это было достаточно проблематично, чтобы нести список, то они должны были подумать, что это достаточно проблематично, чтобы найти время, чтобы решить их по своему вкусу.
Данк
21

Я думаю, что это сложно из-за слова пять . И в меньшей степени из-за слова ненависти .

Пять ? Что если вы придумаете только четыре? Вы не смогли ответить на вопрос? Что если у тебя больше пяти? Теперь, на месте, вы должны выяснить, какие из них лучше всего использовать.

Ненависть это очень негативное слово. Это тот тип негатива, которого людям советуют избегать в интервью. Более того, я думаю , что это будет звучать странно много людей , чтобы иметь , что многие вещи , которые они «ненависти» о языке они будут тратить весь день программирования в Некоторые люди могут даже думать , что это вопрос с подвохом:. Если они на самом деле действительно приходят в случае с пятью вещами они будут дисквалифицированы за то, что ненавидят C # слишком сильно, чтобы хорошо программировать. К сожалению, этот вид извращенного трюка не является неслыханным в интервью.

Вместо этого вы можете спросить, что бы вы улучшили в C #, если бы это зависело от вас? Это позволяет интервьюируемому ответить с любым количеством вещей. Эта фраза также обменивает негативность слова «ненависть» на относительно позитивное «улучшение».

Kyralessa
источник
2
Ваше мнение против «пятерки» хорошее - многие люди, вероятно, будут иметь совокупность вещей, которые им не нравятся в разной степени, но единственный способ, которым они могли бы решить, какие вещи представляют пятерку лидеров, - это оценить все, что может быть близко. Если у кого-то недавно возникли проблемы с чем-то, что обычно вызывает небольшое раздражение, ему, возможно, придется немного подумать, чтобы выяснить, действительно ли он должен войти в пятерку лидеров, или это просто пришло в голову, потому что это было проблемой совсем недавно. Кроме того, C # настолько переплетен с .NET, что трудно сказать, в чем виноват. Например ...
суперкат
1
... Я бы сказал, что все языки должны гарантировать, что если конструктор сгенерирует, частично сконструированный объект получит Disposed, но при отсутствии требования о том, что все языки его применяют, можно утверждать, что языки, которые это делают, будут вызывать ложные ожидания. Таким образом, может быть неясно, следует ли винить в C # или CLS трудность предотвращения утечек ресурсов при сбое конструктора C #.
суперкат
14
  • Большинство кандидатов не настолько глубоко связаны с более чем одним языком или парадигмой, чтобы противопоставить себя . Я не работал с другим объектно-ориентированным языком уже более 5 лет, и тот, в котором я работал (PowerBuilder), у меня было многомозоли с. Большинство парней, только что закончивших колледж, (или думают, что они есть) являются горячими учениками на одном, может быть, на двух языках, и получили «воздействие» еще на три или четыре (это означает, что они выполнили хотя бы одно домашнее задание, требующее его, но менее чем за полный семестр). конечно изучаю это). Недостаточно знаний или опыта, чтобы действительно понять, что не так с языком. Получить работу в реальном мире, и этот фокус значительно сужается; вы узнаете намного больше о языке, который приносит вам зарплату, чем любой другой, и в процессе вы начинаете принимать то, что язык не будет делать или делает странным образом, до такой степени, что вы не могли вспомнить делать это по-другому.

  • Большинство опытных кандидатов на C #, которые сравнивают его с Java / C / C ++, очень довольны этим . C # был разработан с нуля, чтобы делать много вещей лучше, чем Java (события, обратные вызовы, графическая библиотека, работа с базами данных). Java, в свою очередь, была разработана, чтобы быть более простой в использовании и, таким образом, более ориентированной на правильный код, чем C ++. Я еще не встречал программиста на C #, который хотел бы вернуться к C ++ в любой среде, где быстрая производительность и управление на уровне цепи не являются критически необходимыми.

Другими словами, у See-Sharpers это неплохо, учитывая все обстоятельства.

Вот мой список:

  • Лямбда-операторы не подлежат просмотру / оценке . Вызовы именованных методов могут быть подключены к QuickWatch VS. Так могут выражения. Но лямбды? Нет (по крайней мере, не в VS2010). Делает отладку цепей Linq настоящей рутиной.

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

  • C # становится достаточно старым, чтобы иметь серьезные проблемы с унаследованным кодом . Код, изначально написанный для 1.1, заставит любого, кто привык к 4.0, ужаснуться. Даже код 2.0 пропускает многое. В то же время появились сторонние библиотеки, которые делают такие вещи, как ADO.NET, ужасно примитивными (и большая часть «подключенной модели» ADO.NET теперь является большим анти-паттерном). Тем не менее, для обратной совместимости .NET поддерживает всю эту старую, плохую программу, никогда не осмеливаясь говорить что-то вроде: «ArrayList был дурацким способом сделать это, мы сожалеем, что когда-либо вставили его, и мы принимаем используйте его вместо List, и если вам абсолютно необходим список различных типов, объявите его как List<Object>.

  • Серьезно ограниченные правила оператора switch . Вероятно, одна из лучших вещей, которые я мог бы сказать о PowerBuilder, это то, что оператор Choose Case (эквивалентный switch) допускает логические выражения на основе переменной. Это также позволило переключать операторы switch, даже если у них был код. Я понимаю причины, по которым этот второй вариант запрещен (это скорее будет сделано непреднамеренно, чем преднамеренно), но время от времени было бы неплохо написать следующее утверждение:

    switch(someInt)
    {
        case < 0: //all negative values enter here
           //...
           break;
        case 0: 
           //...
           break;
        case 1:
           //...
           //no break; continue through to the code for > 1
        case > 1 // all positive values enter here (including 1)
           //...
           break;
    }
  • Нет INumeric интерфейса . Если это число, вы можете сделать математику с ним. Во многих случаях реальный метод не должен заботиться о том, какие именно типы подключены; Точность - это ответственность вызывающего абонента. Тем не менее, невозможно создать универсальный метод или класс, который может принимать только числовые типы в качестве GTP.
Keiths
источник
3
«Большинство опытных кандидатов на C #, которые сравнивают его с Java / C / C ++, очень довольны». Это было мое мышление. В C # ненавидеть особо нечего, поскольку он позволяет вам сосредоточиться на решении бизнес-проблемы, а не на решении технической проблемы. Самым большим недостатком языка является то, что я не могу использовать строки ресурсов в тестах переключения, потому что они являются технически переменными, а не константами.
Стивен
4
Немного о дженериках и контейнерах - Полезный пример с супер и неясностью с расширениями в дженериках ? объясняет это немного. Назначение Bag<Fruit> bag = Bag<Huckleberry>будет означать, что вы можете сделать то, bag.add(new Watermelon())что не может удержать его.
4
+1 для не числовой. Редкий, но раздражающий.
13
Предположим, Thing<out T>есть статическое поле, доступ к которому осуществляется как методом экземпляра, так и статическим методом. Если a Thing<Cat>передается методу, который ожидает a Thing<Animal>, и этот метод вызывает вышеупомянутый экземпляр и статические методы для Thing<Animal>ссылки, то к каким статическим полям должно быть доступно эти методы?
суперкат
11

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

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

jmoreno
источник
7

Для интервью я бы попросил только 1 или 2, но я согласен, если вы не можете назвать какие-либо ограничения используемого вами инструмента, то вы, вероятно, не очень хорошо его знаете. Мы задаем этот точный вопрос о SSIS, и это действительно помогает отделить пшеницу от плевел; все, кого мы нанимали, кто ответил на этот вопрос, хорошо превратились в замечательного сотрудника. Нам нужны люди, обладающие актуальными знаниями, а не те, кто смотрел на них пару раз. Держу пари, что ты тоже этого хочешь.

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

HLGEM
источник
1
+1 Пятерка пугающая, по этой причине 1 или 2, вероятно, получат больше ответов.
Лоран Кувиду
2
Ненависть сильно отличается от ограничения ......
mattnz
4

Все сводится к тому, что, как вы сказали, недостаточно глубокого опыта работы с C # и / или недостаточного знакомства с другими языками. Я взял интервью у ряда разработчиков, которые считали себя старшими, которые не могли ответить на некоторые вопросы, которые могли бы показать им даже легкую царапину на поверхности C #.

Без достаточного количества копаний вы не достигнете границ языка и не захотите, чтобы они исчезли. Моя пятерка на случай, если кому-то интересно

  1. Для создания неизменяемых объектов требуется много церемоний (в отличие от функционального языка, в котором объекты неизменны по умолчанию).
  2. Метапрограммирование сделать сложно. Сравните тип emit с макросами Lisp. (Услуги компилятора очень помогут в этом).
  3. Методы расширения хороши ... свойства расширения и операторы расширения (особенно неявные и явные операторы) были бы лучше.
  4. Явные приведения разрешаются во время компиляции, а не во время выполнения.
  5. Без согласования последовательностей это намного чище, чем перегрузка функций.
Майкл Браун
источник
Я согласен с вашими первыми двумя пунктами, но я содрогаюсь при мысли о расширении неявного преобразования.
CodesInChaos,
3

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

По иронии судьбы, интервьюеры, которые думают, что они цитируют «великого Джоэла», используя это в качестве вопроса для интервью, вероятно, скорее упускают суть.

Ян
источник
Я бы сказал, что это не всегда так. Например, Дуглас Крокфорд говорит в «JavaScript: Хорошие части», что вам следует избегать определенных функций языка, и я не думаю, что он подразумевает, что они «слишком хардкорные», чтобы их использовать.
Стефф
10
Я думаю, что он говорит обратное - если вы думаете, что платформа никак не сломана, вы недостаточно хорошо это знаете. То есть его смысл в том, что хорошо придерживаться одной платформы, если вы не ослепляете ее недостатки.
Тихон Джелвис
3

Они могут неохотно отвечать, потому что у них может сложиться впечатление, что, если они могут перечислить 5 вещей, которые они ненавидят в языке, интервьюер мог бы повернуться и сказать: «О, мы ищем C #« ниндзя », и вы, похоже, не выглядите». «Мне нравится язык» или «Почему вы подали заявку на работу, если вам не нравится язык?».

Интервьюируемые находятся под сильным давлением, чтобы оставаться позитивными во время интервью.

Джеймс
источник
если я ненавижу что-то на языке, это не значит, что я ненавижу язык. На этот вопрос <del> can </ del> тоже нужно ответить положительно. Зачем нам нужен HTML5, если мы ничего не ненавидим в HTML4? :)
e-MEE
3

Потому что языки определяют то, как мы думаем . Используя C # каждый день, вы привыкли думать и разрабатывать свой код таким образом, который естественным образом решает проблемы языка.

Теперь вы делаете это, не думая, даже не зная, что вы делаете это. Вот почему так сложно указать, что плохого. Без сомнения, в тот день, когда вы начали изучать C #, вы обнаружили много проблем, но теперь вы их больше не видите. Привычки - сильные вещи.Мысли, даже больше .

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

Но если вы хотите стать более способным увидеть недостатки в C #, вы должны изменить свой образ мышления. Узнайте больше языков программирования и привыкните к ним. Стремитесь к самым разным языкам. Вы привыкли к статической типизации? Попробуйте Python или Ruby. Вы привыкли к объектно-ориентированному и императивному? Haskell - это совершенно другой мир.

И когда вы вернетесь в C #, у вас возникнет вопрос: «Зачем мне сто строк C #, чтобы сделать эту простую вещь, которая всего лишь одна строка в Haskell?». Вы будете ненавидеть много вещей о C #.

  • C # не имеет необнуляемых ссылочных типов.
  • Нет алгебраических типов данных.
  • Нет строковой интерполяции.
  • Синтаксис слишком многословен везде.
  • Нет макрос системы.
  • Тип вывода ограничен.
  • Нет литералов регулярных выражений.
  • Нет структурной типизации.
  • Плохая поддержка неизменности.
  • C # структуры подвержены ошибкам.
  • Стандартная библиотека коллекций очень ограничена.
  • Не могу определить ограничения на параметры конструкторов.
  • Не может программировать в общем случае с ограничениями на математические операторы.
  • Нет «нового типа».
  • Нет нарезки массива, нет литерала диапазона.
  • Функции не перечисляют побочные эффекты, которые они могут сделать как часть их типа. :)

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

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

Eldritch Conundrum
источник
+1. Отличный момент. Действительно, многие вещи, которые я на самом деле ненавижу в C #, происходят из-за того, что другие языки не имеют таких же недостатков. Отсутствие реальных кортежей (то есть невозможность делать (a, b) = this.something();как в Python) - это первое, что приходит мне в голову.
Арсений Мурзенко