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

60

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

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

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

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

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

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

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

ОБНОВИТЬ

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

Мэтт Кашатт
источник
8
Я думаю, вы не знаете, что такое «абстракция», потому что LINQ не имеет к этому никакого отношения.
Эйфорическая
8
«Я уверен, что в мире JAVA есть что-то сопоставимое». На самом деле, LINQ - это одна из немногих вещей, которые есть в .NET, а в Java нет.
Эйфорическая
42
@ Euphoric - разве LINQ не отвлекает работу нижнего уровня от таких задач, как, например, сортировка и фильтрация? Я вполне уверен, что, objectCollection.Where(oc=>oc.price > 100)к примеру, за этим будет дополнительный код . Разве это не было бы использованием абстракции? Может быть, вы можете сказать мне, что мне здесь не хватает. , ,
Мэтт Кашатт
37
Всегда есть шанс, что они просто не понимают LINQ и не видят ценности в его изучении. Функциональные аспекты его написания очень сильно отличаются от императивного программирования. Как подрядчик, я только в 2009 году видел «старших» разработчиков Java, которые недостаточно понимают SQL, чтобы писать сложные запросы, поэтому они тратят недели на оптимизацию кода, который переносит все данные на сторону Java, и фильтруют его с помощью кода Java вместо того, чтобы база данных делает это. Незнание широко распространено в индустрии разработки программного обеспечения.
18
Если вы понимаете LINQ, но ваши интервьюеры не понимают, вы лучше, чем они. Установите свои достопримечательности выше.
Джей Базузи

Ответы:

74

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

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

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

Карл Билефельдт
источник
4
@MatthewPatrickCashatt Вы не можете редактировать и продолжать в отладчике внутри методов, содержащих операторы linq. Недостаточно выключения, чтобы я им не пользовался; но это было главной причиной, по которой я некоторое время колебался.
Дэн Нили
3
+1, особенно за второй абзац. Это полностью относится ко мне, так как я был бы совершенно недоволен работой над кодом C # без возможности использовать LINQ.
Арсений Мурзенко
5
Существует также тот факт, что в дополнение к негерметичной абстракции часто наблюдается снижение производительности. Вы обмениваетесь простотой использования на точность, и эта потеря точности часто включает в себя детали, которые могут ускорить процесс. И чем дальше вы удаляетесь от источника, тем больше деталей теряете и тем выше вероятность того, что эти данные важны для производительности.
Jmoreno
6
+1, но это также может работать в другую сторону. Если кто-то скажет мне, что они не наняли меня, потому что я использую Yacc для создания парсеров вместо того, чтобы катать свои собственные, тогда я все равно не хочу работать.
Спенсер Рэтбун
5
@MatthewPatrickCashatt: этот ответ (и мой комментарий к нему) относятся не только к LINQ, но и к общим утверждениям. Но для LINQ вот выдержка из C # 4.0 / 5.0 в двух словах, говорящая о проблемах производительности с LINQ. Возвращаясь к общему мнению: во многих случаях снижение производительности будет стоить того, 5% +/- не имеет значения. Но иногда это будет больше, а иногда даже 0,1% недопустимо. Если вы не думаете, что когда-либо может быть проблема, или эта производительность предназначена только для таких компаний, как Google ....
jmoreno
29

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

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

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

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

jfrankcarr
источник
2
Спасибо jfrankcarr. Я подозревал, что это может иметь место - были вопросы об открытии и закрытии datareaders!
Мэтт Кашатт
2
+1 за вызов MVC "новый материал". Заставил меня смеяться вслух. Это было с 70-х годов. Возможно, вы имели в виду MVVM, который по сути является MVP (вариант MVC), который использует привязки.
14
@ GlenH7 Я думаю, из контекста было довольно ясно, что он имел в виду продукт «ASP.NET MVC», а не базовую концепцию Model-View-Controller.
Carson63000
4
@ GlenH7 - я говорил исключительно в контексте линейки продуктов .NET и Visual Studio и модных слов Microsoft.
jfrankcarr
6
Боже мой, действительно ли есть магазины, которые считают Linq «новым»? Он существует уже более 4 лет. Я могу понять, что не догнал ожидающих выполнения задач, не использовал dynamic/ ExpandoObject/ и т. Д., Или не заботился об Azure и всех других облачных технологиях ... Я даже могу понять, что продолжаю использовать представление старой школы WebForms. сам движок в MVC или Web Forms, или написание кода WPF / WinRT без MVVM ... но Linq? Если вы этого еще не поняли, пришло время бросить работу в качестве разработчика .NET.
12:00
16

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

RalphChapin
источник
12
Честно говоря, хотя я вижу основную мысль, я не думаю, что Линк скоро уйдет. Linq2SQL, да, они устарели в пользу гораздо более мощного EF. Но сам Linq является основой для стольких блестящих новинок в последних 3-х выпусках .NET, что если бы они устарели, они бы отменили половину своей новой технологии персистентного уровня, такой как Azure и EF, не говоря уже о нанесении вреда практически каждому ORM. там и много обработки списка в памяти, кроме того.
KeithS
6
подождите ... "в ужасе отойти от старой устаревшей технологии, потому что она работает" ... WTF. Пришли ли мы к тому, что рабочие вещи, которые проверены, проверены, понятны и понятны, и зрелы, НЕ хороши.
gbjbaanb
7
@ gbjbaanb - Нет. Но - как анекдот - вы бы хотели, чтобы врач диагностировал ваши боли в груди с помощью рентгенографии грудной клетки, потому что этот метод «опробован, проверен, понятен», или вы хотите использовать МРТ, которая новее, но поставляется с более высоким разрешением , лучший прогноз и больше информации? Никто не говорит, чтобы отвернуться от классических принципов здесь; наоборот. Видите ли, LINQ (в качестве примера) построен на этих принципах. Я думаю, как уже упоминали другие, именно изучение частей, составляющих LINQ, и его правильное использование вызывают такие моменты «WTF», как ваши.
Мэтт Кашатт
2
@MatthewPatrickCashatt: зависит, если бы врач не был обучен читать результаты МРТ, я бы взял рентген, а не угадывал диагноз. Если бы я заболел в затоке, я бы предпочел иметь доктора, который мог бы поставить диагноз только с помощью стетоскопа, а не справиться без новейших инструментов.
gbjbaanb
2
@MatthewPatrickCashatt Я понимаю вашу точку зрения, но уравновешивающим фактором является то, что вы не хотите следовать всем трендам только потому, что они новее. Я с радостью буду следовать новой технологии, которая вписывается в одну из двух категорий. 1. Это волнует меня, и я готов потратить на это свое свободное время. 2. Это доказывает, что оно действительно лучше, и кажется, что оно продлится достаточно долго, чтобы оправдать инвестиции. Тенденции, которые не вписываются в одну из двух категорий, в лучшем случае являются азартной игрой.
TimothyAWiseman
15

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

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

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

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

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

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

Telastyn
источник
1
Хорошие моменты. Согласитесь на расходы, которые вы упоминаете, и это хорошее уточнение. В более широком смысле, однако, разработка собственных классов, с которыми новые сотрудники не могут быть знакомы, поскольку они не существуют вне организации, представляет те же проблемы в дополнение к стоимости первичной разработки.
Мэтт Кашатт
2
@MatthewPatrickCashatt - О, конечно. Таким образом, этот доморощенный код должен почти всегда прилагать больше усилий для той же победы, но это не обязательно. Как и во многих других случаях, стоимость / вознаграждение должны быть оценены и предпочтительны , а не следовать слепо.
Теластин
@Telastyn Самодельный код также хорош, так как вы знаете, что он делает, и можете исправить это в любой момент. Кроме того, вы можете оптимизировать для конкретных обстоятельств на основе вашего собственного использования, а не в среднем для всех.
Хоукен
13

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

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

Джон Вигли
источник
+1 - а также рассказать им, о чем вы знаете, спросить их, что они делают и на чем они специализируются.
Кирк Бродхерст,
12

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

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

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

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

gbjbaanb
источник
2
Я согласен с этим, но я заметил гораздо больше людей, которые используют это отношение, чтобы отвергать хорошие идеи, которые они просто не понимают (например, тестирование, шаблоны проектирования, ORM). Поэтому, хотя я согласен с тем, что быть в хорошей форме для команды - это хорошо, важно понимать, что вы, возможно, лучше, чем остальная часть команды, и должны найти единомышленников, для которых хорошее знание - это неплохо. абстракции.
Уэйн Молина
1
@WayneM конечно, но ОП - фрилансер, так что на самом деле не имеет значения, является ли он богом кодирования, если только они не готовы нанять его на постоянной основе, чтобы поддерживать код, тогда остальная часть команды не понимает (хм) ему нужно делать то, что они хотят, а не то, что он хочет.
gbjbaanb
1
@WayneM также многие люди использовали бы что-то похожее на то, что вы только что сказали, чтобы продвигать свои идеи перед другими (быть уверенными, что те, с кем они разговаривают, просто не понимают этого). В конце концов обе стороны предвзяты, но ОП собирается получить работу, а не выиграть грандиозную войну DIY / абстракции. У каждого будет свое мнение, но кто-то должен преодолеть это; Я предполагаю, что это не будет работодатель в этом случае. :(
Хоукен
10

У тех, кто не использует 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 и подобные методы расширения довольно сладкий. Интервьюер, который не видит смысла, может даже не пытаться заставить вас проявить способность к чему-либо еще; они предположат, что у вас его нет, и пойдут дальше.

Keiths
источник
Почему бы вам просто не написать свой запрос как var resultList = inputList.Select(i=>i.Property).Intersect(otherInputList.Select(o=>o.Property));? Возможно, я это испортил, но суть в том, что у LINQ есть лучшие способы выполнения запроса, о котором вы упоминали выше (.Join () - это другой способ). Я понимаю, что есть способы использовать LINQ, которые могут быть не такими умелыми, как другие, но это не значит, что вы должны полагаться на эти плохие реализации.
Мэтт Кашатт
4
@MatthewPatrickCashatt Я не думаю, что его смысл в том, чтобы утверждать, что LINQ всегда неэффективен - хотя вы всегда можете выполнить заданный запрос LINQ, некоторые применения дают лучшую производительность за час разработки, чем многие подходы, не связанные с LINQ. Скорее всего , это может быть относительно легко написать запрос LINQ , который является неэффективным и не понимают его, потому что недостатки не столь вопиющим.
Джон Ханна
3
@JonHanna: Возможно, что еще важнее, ценность абстракции значительно снижается, если нужно изучить, какой код «действительно делает», чтобы определить, какие необычные, но правдоподобные сценарии могут привести к тому, что производительность будет на много порядков хуже ожидаемой. Если при переходе от одной структуры данных к другой код будет работать в 10 000 раз медленнее, возможность такого изменения без изменения какого-либо другого кода не всегда может быть полезной.
суперкат
1
@supercat: да и нет. Тот факт, что знание того, как что-то делается в сторонней реализации, имеет решающее значение для понимания последствий для производительности и предотвращения неэффективности, не означает, что библиотеки, в которых содержатся эти инструменты, имеют меньшую ценность. Это две стороны одной медали; знать природу реализации, и вы можете использовать ее с помощью нескольких нажатий клавиш вместо того, чтобы час тратить свои собственные. Но вы должны знать обе стороны, и стереотипный фанат Linq, который думает, что это идеально, ничего плохого, используйте его, потому что, скорее всего, нет.
KeithS
@KeithS: Мне кажется, что в Java и .net очень не хватает одной вещи - это стандартный способ задавать объектам или коллекциям разные вещи о себе. Например, код, который получает перечисляемую коллекцию, может выиграть от знания того, может ли когда-либо измениться количество элементов и / или последовательность существующих элементов, известно ли, что число элементов является конечным или бесконечным (или неизвестным в любом случае), и знает ли коллекция, сколько в ней предметов. Такие технологии, как LINQ, часто должны делать предположения о таких вещах, которые могут или не могут быть правильными, и ...
суперкат
10

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

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

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

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

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

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

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

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

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

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

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

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

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

Подобный недавний опыт
источник
6

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

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

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

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


1 один магазин зашел так далеко , как строить свой собственный довольно примитивный инструмент сборки!

dasblinkenlight
источник
2
Все ваши замечания хорошо сформулированы, но я должен дать вам некоторое представление о последнем интервью: интервьюер настаивал на том, что LINQ "осуждается". Я спросил: «Разве вы не имеете в виду, что MS больше не будет вкладывать средства в Linq-to-SQL, но что Linq-to-Entities будет рядом», и он ответил, что он имел в виду то, что сказал: LINQ «осуждается» нет, я не думаю, что он слишком много знал о LINQ или настаивал на его использовании.
Мэтт Кашатт
1
@MatthewPatrickCashatt Если кто-то запутал LINQ для LINQ2SQL с точки зрения устаревшей технологии, я придумал какой-то глупый повод покинуть интервью раньше и никогда не перезванивал этой компании. Если это действительно так, вы должны быть довольны тем, что они вас не нанимают :)
dasblinkenlight
1
100% уверен, что это так. На самом деле, я не мог удержаться от того, чтобы посылать ему какие-то ссылки, чтобы указать ему правильный путь по предмету, не как удар, так как я не получил концерт, а потому, что я действительно чувствовал смущение за него и надеялся, что смогу помогите ему не совершать одну и ту же ошибку дважды;).
Мэтт Кашатт
4
Тогда, похоже, это связано не столько с технологическим стеком, сколько с тем, что вы его исправили. Люди не любят, когда их исправляют. Это просто человеческая натура. Когда люди принимают решения, например, нанимают людей, 99% будут следовать своей интуиции. Они зависят от того, вызвали ли вы их положительные или отрицательные эмоции. Исправление его, возможно, заставило его чувствовать отрицательные эмоции. И тогда он связывает этот негатив с ситуацией.
кодер
1
Я не знаю, как хеш-таблицы работают внутри. Подобные глубокие технические тесты отбрасывают людей с практическим обучением, которые, тем не менее, являются хорошими кандидатами. Требовать от людей низкого уровня знаний, которые они никогда не будут использовать, мне не нужно. Принципы дизайна стали намного важнее!
Tjaart
4

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

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

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

Ян
источник
3

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

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

Уэйн Молина
источник
Вы можете добавить LINQ в пул модных слов, содержащий Nhibernate и т. Д. Я бы не стал этого делать. На самом деле, я думаю, модные слова иллюстрируют нашу неспособность объяснить абстракции в правильные выражения.
AndreasScheinert
Вы говорите о том, чтобы «идти в ногу со временем», и я думаю, что обратное будет гораздо более уместным. Многие полезные концепции были обнаружены и использовались в прошлом, например, DSL. Мы должны улучшить наше общение и понимание концепций, таких как то, что нам не нужно изобретать новые модные слова для старых концепций.
AndreasScheinert