Почему использование абстракций (таких как LINQ) так запрещено? [закрыто]

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

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

Главное, по словам интервьюера, заключалось в том, что я слишком склонялся к использованию абстракций (таких как LINQ), а не к более низкоуровневым, органически выращенным алгоритмам.

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

Итак, теперь у меня остался вопрос: если мы должны «стоять на плечах гигантов» и использовать доступные нам абстракции (например, LINQ), то почему некоторые люди считают это табу? Разве не имеет смысла выводить код «с полки», если он выполняет те же цели без дополнительных затрат?

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

Я не хочу сосредоточиться на LINQ здесь. Я уверен, что в мире JAVA есть что-то сопоставимое, я просто хотел бы знать, почему некоторым людям настолько не нравится идея использовать абстракцию, которую они сами не написали.

ОБНОВИТЬ

Как отметил Euphoric, в мире Java нет ничего похожего на LINQ. Итак, если вы разрабатываете в стеке .NET, почему бы не всегда использовать его? Возможно ли, что люди просто не до конца понимают, что это делает?

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

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

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

Некоторым программистам .NET, особенно разработчикам классического VB / ASP или C ++, не нравятся новые вещи, такие как LINQ, MVC и Entity Framework.

Исходя из того, что я наблюдал, бывшие VB'еры в этой группе, вероятно, все еще будут использовать слои доступа к данным и другой код, изначально написанный более 10 лет назад. Они также будут использовать старые модные слова, такие как «n-уровень» и тому подобное, и вообще ничего не поймут ни о чем, кроме .NET Framework 2.0, и при этом они не захотят что-либо узнавать об этом.

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

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

Microsoft имеет долгую историю выпуска новых горячих технологий, а затем забыла о них через 5, 10 или 20 лет. LINQ может показаться кому-то другим. Они отметят, что Microsoft не может отказаться от SQL, но LINQ может следовать Silverlight . Таким образом, вы можете видеть паранойю, возникающую в результате тяжелого опыта, или просто людей, которые остались позади от современных технологий и которые возмущаются этим.

Разве не имеет смысла выводить код «с полки», если он выполняет те же цели без дополнительных затрат?

Там всегда за дополнительную плату.

Кривая обучения для готовых вещей всегда там. Боль получения обновлений (и зависимостей) всегда здесь. Неспособность облажаться с кишками всегда есть.

Для LINQ действительно применимо только первое. Многие люди считают, что «странно» выглядящий код трудно читать и труднее отлаживать. Подобный sql синтаксис в значительной степени индивидуален для каждого профессионального концерта, с которым я работал, с момента его выхода. LINQ to SQL (и другие источники данных) имеют ряд проблем и ограниченных возможностей оптимизации.

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

Они не знают / не могут выучить LINQ, но они «очевидно» хорошие разработчики, поэтому LINQ не стоит того. Это обычная ловушка.

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

Вы хотите представить позицию, которая говорит: «Что бы вы ни делали, я хочу помочь вам достичь этого», вместо того, чтобы дать подтекст, который говорит: «Возможно, вы делаете что-то не так, и присутствие меня будет Это."

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

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

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

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

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

Возьмите следующий фрагмент:

var resultList = inputList.Where(i=>otherInputList.Count(o=>o.Property == i.OtherProperty) > 0);

LINQ-инициированные здесь съеживаются. Почему? Потому что тот факт, что этот код выглядит красиво и элегантно, не означает, что он не ужасно неэффективен. Count () с предикатом оценивает каждый элемент его родительского перечислимого и суммирует время, когда предикат вернул true. Таким образом, это не только N ^ 2 (когда inputList и otherInputList имеют примерно одинаковую мощность N), это абсолютный худший случай N ^ 2; КАЖДЫЙ элемент otherInputList просматривается для КАЖДОГО элемента ввода. Вместо этого первым шагом является использование Any () вместо Count, потому что это действительно то, что вы хотите знать, и он завершится, как только будет получено, что ответ «да». Настройка HashSet, в которой хранятся различные значения, также otherInputListObject.OtherPropertyможет вам помочь; доступ становится O (1) вместо O (N),сложность в худшем случае вместо квадратичной сложности в лучшем случае .

Таким образом, мы видим, что за этими хорошими элегантными методами стоят серьезные затраты, и если вы не знаете, каковы эти затраты, вы можете очень легко кодировать алгоритм O (my GD) -сложности в высокопроизводительный центральный файловый сервер вашего потенциального работодателя. или главная страница портала приземления в следующий раз, когда они могут нуждаться в настройке. Увольнение после того, как вы это сделаете, не отменяет того, что вы сделали, но не нанимает вас, если они думают, что вы это сделаете, это предотвратит это. Итак, чтобы избежать этого, вы должны доказать, что они не правы; обсудите, что эти методы делают (что означает, что вы должны знать себя) и их сложность, и как получить ответ в течение эффективного (NlogN или лучше) времени.

Другая проблема - старый добрый аргумент «Когда твой единственный инструмент - молоток». Поставьте себя на место интервьюера, берущего интервью у этого фаната Linq. Кандидату нравится Linq, он хочет использовать его, думает, что это лучшая вещь. Может даже показаться, что кандидат не сможет написать код без него, так как все проблемы программирования решаются с помощью Linq. Что происходит, когда его нельзя использовать? По-прежнему существует множество кода .NET 2.0, и если бы он был обновлен, потребовалось бы болезненное обновление серверов, рабочих станций пользователей и т. Д. И т. Д., И все это, чтобы вы могли использовать свои необычные методы расширения. Как интервьюер, я постараюсь показать вам, что вы могли бы кодировать эффективную сортировку или использовать методы сортировки 2.0, если бы вам пришлось, независимо от того, насколько я мог бы согласиться с вами, что библиотеки Linq и подобные методы расширения довольно сладкий. Интервьюер, который не видит смысла, может даже не пытаться заставить вас проявить способность к чему-либо еще; они предположат, что у вас его нет, и пойдут дальше.

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

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

Тем не менее, я заметил, что то, что обычно было центральным в циклах интервью за последние пять или шесть лет, решительно не обсуждалось и не рассматривалось. Такие вещи, как основы анализа / проектирования ООП, шаблоны (и дизайн, и архитектура), некоторые из более продвинутых / ориентированных на абстракцию функций .net (включая, в частности, лямбды или LINQ, обобщения, сериализация / привязка данных и т. П.), И даже обычно горячая тема предпочтительной методологии (казалось, никто не заботился о гибкой и водопадах или о том, что такое гибкая гибкость), а также об инструментах, выборе ORM или предпочтительных средствах совместной работы или управления исходным кодом. В некоторых случаях не упоминается вообще, почти во всех случаях, очевидно, не вызывает беспокойства.

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

• Странная фиксация устаревших / устаревших соглашений и ограничений «назад в каменные века». Как разработка примитивного веб-приложения в VS2003 со списком абсурдных ограничений, еще более запрещающих использование явных возможностей в той эпохе .net ... как будто это реальная мера способности современных разработчиков ... способность помнить парадигма и ограничения 9-летней давности еще больше подорваны нереальными / произвольными ограничениями. Другое место было очень упорным на предмет коллекций на заказ, около предварительных коллекций. В другом месте был приведен пример кода модели класса, который я вычеркнул, потому что я не использовал каскадные конструкторы (они, казалось, не знали о поддержке инициализации свойств при объявлении, что было достаточно для этой необходимости).

• Чрезвычайное внимание к конкретным деталям реализации в микромире и / или настройках конфигурации, даже в случае технологий, которые направлены на то, чтобы быть независимыми от платформы или протокола (т. Е. Весь смысл в том, чтобы НЕ зацикливаться на конкретной реализации или конкретном использовании, а скорее на повторное использование / повторное назначение / расширяемость / по мере необходимости интеграции).

• Готовность специфицировать / контролировать / пересматривать код / ​​и иным образом перекладывать работу на и из оффшорной команды, а также навыки некодирования, связанные с этим.

• Использование определенных версий продуктов / платформ / модулей / и т. Д. Иногда до абсурда; "Итак ... вы использовали версии 1, 2 и 4? Но не 3, а? Хммм ... {комментирует ваше резюме" no v3 !!!} ". Степень использования не имеет значения; только то, что вы что-то использовали или не использовали вообще , и конкретную вещь, о которой они просят, также ... никакие замены, казалось, не учитываются, даже более широко используемого и полнофункционального конкурирующего продукта.

• Гораздо больше внимания уделяется тому, «насколько хорошо вы будете вписываться в нашу команду», «действительно ли вы хороши как разработчик программного обеспечения» или «у вас есть навыки и опыт, чтобы повысить ценность компании и помочь нам обеспечить качество продукт "или даже" вы опасный идиот, который придет и разрушит магазин ". В некоторых случаях мое резюме воспринималось как само собой разумеющееся, и даже так называемый «технический экран» или техническое собеседование были оценкой личности, а не оценкой навыков. Даже для относительно краткосрочных контрактных позиций, где вы были бы там и ушли снова, прежде чем два сезона изменились.

• Компании в этот раз, казалось, уделяли гораздо меньше внимания решению конкретных технических проблем, запуску новых «зеленых» или крупных проектов развития 2.0, или выводу на рынок конкретного продукта, чтобы извлечь выгоду из возникающего тренда или возможности, или к обычным крупным стартовым сделкам. , Повторяющаяся тема, которую я заметил, по крайней мере, в 15 местах, заключалась в том, что небольшая группа из 3-5 разработчиков, в основном выживших после краха рынка в 08 году, была в состоянии отобрать продукт в течение последних 3 лет или около того. и нашли некоторый успех, или их компания в целом процветает, и они нанимают новых людей, чтобы не отставать от растущих требований к функциям или устранять / преодолевать недостатки дизайна, которые они встроили в эти системы, или захватывать вышеупомянутые платформы для освобождения до основной команды, которая создала его для «других проектов».

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

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

Конечно, закон Мерфи, который является тем, чем он является, следующее интервью после того, как вы перестанете быть «увлеченным моим нынешним любимым технологическим парнем» и примете более сбалансированную / бодрящую позицию, - это концерт, который вы бы получили, если бы вы были безумны фанатик. ;)

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

Я серьезно сомневаюсь, что компания полностью запретила использование LINQ. Скорее всего, они хотели, чтобы вы показали им свои навыки на более глубоком уровне.

Например, один из способов выяснить, знаете ли вы свои хеш-таблицы, - попросить вас реализовать примитивную таблицу на доске. Это простое упражнение показывает удивительное количество данных о ваших знаниях рецензенту: он мгновенно узнает, знаете ли вы о хэш-коде / равных и что вы знаете о хеш-коллизиях. В то же время трудно представить, чтобы кто-то в здравом уме реализовал хэш-таблицу, потому что Microsoft так хорошо с ней справилась. То же самое касается многих алгоритмов, таких как сортировка и поиск: интервьюеры часто хотели бы знать, достаточно ли вашего опыта для понимания низкоуровневых взаимодействий, вместо проверки наличия у вас практических знаний о библиотеках .NET.

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

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

Если бы я взял у вас интервью, я был бы разочарован, если бы вы не смогли ответить на мои вопросы о linq.

Linq - хитрый, хотя многие люди считают его вуду, что несправедливо, потому что на самом деле это очень просто и тем более умно для него.

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

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