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

В подкасте 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 совершенно не по теме.}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Большинство кандидатов не настолько глубоко связаны с более чем одним языком или парадигмой, чтобы противопоставить себя . Я не работал с другим объектно-ориентированным языком уже более 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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