Чому на питання "дай п'ять речей, які ти ненавидиш про 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 #) до класу, який успадковує кілька інтерфейсів, що містять методи з однаковою назвою.

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

^{¹ Кілька людей критикували деякі збори в .NET Framework або відсутність деяких бібліотек у рамках або критикували CLR. Це не рахується, оскільки питання стосувалося самої мови , і хоча я потенційно міг би прийняти відповідь про щось негативне в ядрі .NET Framework (наприклад, щось на зразок того, що для загального інтерфейсу немає TryParse, тож якщо ви хочете проаналізувати рядок на кілька типів, вам потрібно повторити для кожного типу), відповідь про JSON або WCF абсолютно не є темою.}

Якщо мені доведеться здогадуватися:

1. Деяким програмістам не вистачає різноманітної мови. Важко зрозуміти, що з мовою не так, коли ти не знаєш, що кращі речі існують.

2. Деякі програмісти - просто мавпи коду. Вони ледве аналізують проблеми, що стоять перед ними, не кажучи вже про щось на зразок того, як мовою програмування могло бути краще.

3. Мало хто особливо критичний. Вони бачать переваги та особливості, а не недоліки. Їм важко перейти в такий спосіб мислення, якщо інтерв'ю не піде так.

4. Принаймні тут, надмірно критично сприймається як фатальний недолік особистості. Замість того, щоб бути "тим проникливим розробником, який завжди шукає кращих способів робити справи" (як деякі райони, в яких я жив), вони "той мудак, який ненавидить усе". Навіть люди, які можуть думати про речі, які вони ненавидять на мові, можуть вважати, що інтерв'ю не виглядає менш виразним.

Я б міг уявити, що на це питання важко відповісти під час інтерв'ю, оскільки це:

1. Дійсно несподівано,

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

3. Важко відповісти за короткий проміжок часу (якщо не підготуватися до інтерв'ю).

1. Це несподівано

Несподівані питання справді важкі, особливо в напруженому контексті. Уявіть такий діалог під час інтерв'ю:

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

2. Це вимагає багато різного мислення

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

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

3. На це потрібен час

Чесно кажучи, у мене є список з п'яти (насправді більше) речей, які я ненавиджу щодо C #, але я думав про це протягом тривалого періоду часу. Кілька речей - з епохи .NET Framework 2; Більшість проблем, які я перераховував для .NET Framework 2, більше не дійсні, оскільки їх було видалено, деякі з LINQ та всіма цим функціональним програмуванням, інші з динамічним програмуванням. Я не впевнений, чи не підготувавши це запитання, я зміг би знайти всі п’ять елементів під час співбесіди.

Я думаю, що це важко через слово п’ять . І в меншій мірі через слово ненависть .

П’ять ? Що робити, якщо ви придумали лише чотирьох? Ви не змогли відповісти на запитання? Що робити, якщо у вас більше п'яти? Тепер, на місці, ви повинні розібратися, хто з них є найкращими п'ятьма для використання.

Ненависть - дуже негативне слово. Це той негатив, якого люди говорять уникати в інтерв'ю. Більш того, я думаю , що це буде звучати дивно багато людей , щоб мати , що багато речей , які вони «ненависті» про мову вони будуть витрачати весь день програмування в Деякі люди можуть навіть думати , що це питання з підступом :. Якщо вони на насправді дійсно приходять З п’ятьма речами вони будуть дискваліфіковані, щоб ненавидіти C # занадто багато, щоб добре програмувати. На жаль, подібного питання викривленого трюку не можна почути в інтерв'ю.

Натомість ви можете запитати, що б ви покращили щодо C #, якби це залежало від вас? Це дозволяє опитуваному відповідати на будь-яку кількість речей. Це словосполучення також торгує негативом слова "ненависть" щодо відносно позитивного "покращити".

• Більшість кандидатів не мають такої глибокої участі у більш ніж одній мові чи парадигмі, щоб протиставити . Я не працював з іншою об'єктно-орієнтованою мовою вже більше 5 років, і тією, в якій я працював (PowerBuilder), у мене було багатопіїв с. Більшість хлопців, котрі вийшли з коледжу, є (або вважають, що вони є) гарячими предметами на одній, можливо, на двох мовах, і отримали "виставу" ще на три-чотири більше (це означає, що вони виконали принаймні одне домашнє завдання, яке вимагає цього, але менше, ніж повний семестр звичайно її вивчаючи). Цього недостатньо знань чи досвіду, щоб дійсно знати, що з мовою не так. Влаштуйтеся на роботу в реальному світі, і ця спрямованість значно звужується; ви дізнаєтесь набагато більше про мову, яка отримує вам зарплату, ніж будь-яка інша, і в процесі цього ви приймете, щоб прийняти те, що мова не зробить, або робить дивно, до того моменту, коли ви не могли згадати робити це по-іншому.

• Більшість кандидатів на C # -savvy, які порівнюють його з 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 зараз є великою антидіаграмою). Однак, для зворотної сумісності. використовуйте Список замість цього, і якщо вам абсолютно потрібен список різних типів, оголосіть його як List<Object>.

• Серйозно обмежені правила заяви оператора перемикання . Напевно, одна з найкращих речей, яку я могла сказати про PowerBuilder, - це те, що оператор Select Case (еквівалент комутації) дозволяв булеві вирази на основі змінної. Це також дозволило операторам комутатора провалюватися, навіть якщо вони мали код. Я розумію причини, через які цю другу заборонено (це скоріше це буде зроблено ненавмисно, ніж спеціально), але все одно було б час від часу писати заяву на зразок:

  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;
  }

• Немає інімерного інтерфейсу . Якщо це число, ви можете займатися математикою. У багатьох випадках фактичний метод не повинен дбати про те, які саме типи підключені; точність - відповідальність за абонента. Однак створити загальний метод або клас, який може приймати лише типи чисел як GTP, неможливо.

Я б припустив, що частина проблеми - це страх дати погану відповідь - ви говорите, що ненавидите Х, інтерв'юер любить Х або вважаєте, що ваша причина ненависті Х - ідіотська, кажучи, що ви вважаєте, що це добре може здатися менш суперечливим варіантом.

Це, мабуть, і те, про що більшість людей насправді не задумувались; У них є поточні проблеми та минулі проблеми, минулі проблеми, які були спричинені мовою, закінчились, і тому люди в основному думають про рішення, а не про проблему, як про те, що було більш суттєвим, і мало хто матиме поточну проблему, спричинену мовою.

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

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

Це зводиться так, як ви сказали, відсутність глибокого досвіду роботи з C # та / або відсутність впливу інших мов. Я взяв інтерв'ю у ряду розробників, які вважали себе старшими, які не могли відповісти на деякі запитання, які навіть легка подряпина на поверхні C # повинна була їм виявити.

Не вистачивши копання, ви не збираєтесь досягти меж мови і бажаєте, щоб їх не було. Моя п’ятірка на випадок, коли хтось цікавиться

1. Незмінні об’єкти потребують великої кількості церемонії для створення (на відміну від функціональної мови, де об'єкти є незмінними за замовчуванням).
2. Метапрограмування зробити важко. Порівняйте тип випромінювання з макросами Lisp. (Послуги компілятора дуже допоможуть у цьому напрямку).
3. Методи розширення чудові ... Властивості розширення та оператори розширення (конкретно неявні та явні оператори) були б краще.
4. Явні касти вирішуються під час компіляції замість часу виконання.
5. No Sequence Matching - це набагато чистіше, ніж перевантаження функцій.

Я думаю, у своєму раунді про те, як він говорить; якщо ти думаєш, що це зламано, ти, мабуть, не розумієш, чому це так і є. У ваших знаннях може бути дірка.

За іронією долі, інтерв'юери, які думають, що вони цитують "великого Джоеля", використовуючи це як питання інтерв'ю, ймовірно, досить не вистачає суті.

Вони можуть неохоче відповідати, тому що вони можуть мати враження, що якби вони зможуть перерахувати 5 речей, які вони ненавидять про мову, інтерв'юер може обернутися і сказати: «О, ми шукаємо C # 'ніндзя», і ви не здаєтеся подобається мова "або" Чому ви подали заявку на роботу, якщо мова вам не подобається? ".

Опитані опиняються під сильним тиском, щоб залишатися позитивними під час інтерв'ю.

Тому що мови формують те, як ми думаємо . Використовуючи C # щодня, ви взяли за звичку думати і конструювати свій код таким чином, що, природно, вирішує проблеми мови.

Тепер ти робиш це, не думаючи, навіть не знаючи, що ти це робиш. Ось чому так важко вказати, що таке погані речі. Не сумнівайтеся, що в той день, коли ви почали вивчати C #, ви знайшли багато питань, але зараз їх більше не бачите. Звички - це потужні речі. Мисливі звички, навіть більше .

Позитивною стороною цього є те, що якщо вам важко перелічити вади в C #, це повинно бути, тому що ви хороший програміст на C #, ви любите мову та використовуєте її більше, ніж інші мови.

Але якщо ви хочете стати більш здатним бачити вади в C #, вам доведеться змінити свій спосіб мислення. Дізнайтеся більше мов програмування та звикніть до них. Прагніть до найрізноманітніших можливих мов. Ви звикли до статичного набору тексту? Спробуйте Python або Ruby. Ви звикли до об'єктно-орієнтованого та імперативного? Хаскелл - це цілий інший світ.

І коли ви повернетесь до C #, вам стане так: "Навіщо мені потрібно сто рядків C #, щоб зробити цю просту річ, що є лише однією лінією в Haskell?". Ви будете ненавидіти багато речей про C #.

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

(Звичайно, жодна мова не може мати все. Мовний дизайн надзвичайно важкий, і додавання кожної функції в одну і ту ж мову не може працювати. Різні інструменти для різних цілей.)

Так, на питання важко відповісти добре, особливо під час співбесіди. Але люди, які можуть на це відповісти, доводять, що вони подумали про це, що мають певну перспективу.