I don’t think it’s the use of abstractions per se that’s objectionable. There are two other possible explanations. One is that abstractions are all leaky at one time or another. If you give the impression, correct or not, that you don’t understand the underlying fundamentals, that might reflect poorly in an interview.

The other possible explanation is the fanboy effect. If you talk excitedly about LINQ, and repeatedly bring it up in an interview with a company who doesn’t use it and has no current plans to do so, that gives the impression that you would be dissatisfied or even disgruntled working with older technologies. It can also give the impression that your enthusiasm for one product has blinded you to alternatives.

If you truly think you would be happy in a non-LINQ shop, try asking about what they do use, and tailor your answers accordingly. Show them that while you prefer LINQ, you are competent using whatever tools are at hand.

Some .NET programmers, particularly those coming from either a classic VB/ASP or a C++ background, don’t like new stuff like LINQ, MVC and Entity Framework.

Based on what I’ve observed, the ex-VB’ers in this group are likely to still be using a data access layers and other code originally written 10+ years ago. They’ll also use old buzzwords like “n-tier” and the like and not really understand anything at all about anything beyond .NET Framework 2.0 nor are they wanting to learn anything about it.

The C++’ers tend to be academically oriented programmers who love coding cool algorithms, even if it means re-inventing the wheel. They hate depending on anything they didn’t hand code themselves. A few of these people also delight in making interviewees feel inferior, especially those with a less traditional background.

You’re likely to run into organizations like this when you’re interviewing. But, you’ll also run into some who are using newer methods. Don’t let a few bad interviews throw you off.

Microsoft has a long history of coming out with hot new technologies and then forgetting about them 5, 10, or 20 years down the road. LINQ might look like another one to some people. They’ll note that Microsoft cannot deprecate SQL, but LINQ could be following Silverlight. So you could be seeing paranoia resulting from hard experience, or just people who’ve been left behind by modern technology and who resent it.

Doesn’t it make sense to pull code “off the shelf” if it accomplishes the same goals without extra cost?

There’s always an extra cost.

The learning curve for off the shelf stuff is always there. The pain of getting updates (and dependencies) is always there. The inability to screw around with the guts is always there.

For LINQ, the first only really applies. Many people consider the ‘weird’ looking code to be hard to read and harder to debug. The sql-like syntax is pretty much persona-non-grata every professional gig I’ve worked since it came out. LINQ to SQL (and other data sources) have a number of gotchas and limited optimization options.

These are the general arguments against 3rd party tools and LINQ specifically. All that said, LINQ is a damned useful tool and should be preferred in most situations. Crying Not Invented Here, and abstractions should not be favored smacks strongly of Cognative Dissonance.

They don’t know/can’t learn LINQ, but they’re “obviously” good developers, so LINQ must not be worthwhile. It’s a common trap.

Something else you should consider is that your enthusiasm for a cool new technology can simply make people feel uncomfortable and not want you around. You’re not “empowering” them, because it’s you who knows this technology, not them. Even if they themselves don’t realize it, they may be seeking candidates who reinforce what they’ve already invested so much time into.

You want to present an attitude that says, “Whatever you’re doing, I want to help you achieve it”, rather than giving a subtext that says, “You might be doing things in a bad way, and having me around will prove it.”

My take on this (and TBH I’m guessing because none of us can tell what those interviewers were thinking) is that often you go to an interview to explain why they should hire you to fit in with their team, their way of working.

You can be the perfect developer, a rock start code god, but that means absolutely nothing if what you want to do (emphasised by you talking excessively and too enthusiastically about some cool technology gubbins) simply tells them about you, and that you would not fit in with what they want. If they have an old-style data-access system, that cannot be upgrade for whatever reason, they do not need someone who’d forgotten how to maintain it. If they are developing new stuff, and you really really want to put that cool new tech everywhere, then its obvious they will have a big issue with future code maintenance and/or staff training.

As a freelancer, this is much more of a problem that if they were hiring a permie. With a permie, training and development of new ways of working are not bad things, within the scope of existing code and practises – you’ll be there for a long while to make things better. With a freelancer, they really don’t give a hoot what you want, you’re there solely to do their job the way they want it done, and its not your job to do anything else. (disagree – become a permanent employee)

Its probably got nothing to do with LINQ itself, I’ve rejected a candidate who turned up and explained how much better everything would be written in Haskell. We don’t do Haskell. The same applies for any tech that isn’t used by the company, usually its not a problem if you mention it as something good. The problem comes when you are too enthusiastic and keen on it.

There is one valid concern I’ve heard from those who don’t use Linq, and it’s one I take to heart: “Just because you can’t see the implementation doesn’t mean it isn’t expensive”.

Take the following snippet:

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

The LINQ-initiated here are cringing. Why? Because just because this code looks nice and elegant doesn’t mean it’s not horrendously inefficient. Count(), with a predicate, evaluates every element of its parent enumerable, and sums up the times the predicate returned true. So, not only is this N^2 (when inputList and otherInputList are of roughly equal cardinality N), it’s the absolute worst-case N^2; EVERY element of otherInputList is traversed for EVERY element of input. Instead, the first step is to use Any() instead of Count, because that’s really what you want to know, and it will quit as soon as the answer’s known to be “yes”. Setting up a HashSet that stores distinct values of otherInputListObject.OtherProperty might help you out too; access becomes O(1) instead of O(N), so for an initial linear setup cost you reduce the entire operation to linear worst-case complexity instead of quadratic best-case complexity.

Thus we see that these nice elegant methods have serious costs behind them, and if you don’t know what those costs are, you can very easily code an O(my G-D)-complexity algorithm into your prospective employer’s high-performance central file servicer or main landing portal page the next time they might need a tweak. Firing you after you do that doesn’t undo what you did, but not hiring you if they think you’d do it would prevent it. So, to avoid this, you have to prove them wrong; discuss what those methods do (meaning you have to know yourself) and their complexity, and how to arrive at the answer in an efficient (NlogN or better) time.

Another concern is the good old “When your only tool is a hammer” argument. Put yourself in the place of the interviewer interviewing this Linq fanboy. The candidate likes Linq, wants to use it, thinks it’s the best thing ever. It might even seem that the candidate couldn’t code without it, since every programming problem given was solved with Linq. Well what happens when it can’t be used? Plenty of .NET 2.0 code still out there, that if it were upgraded would require painful upgrades to servers, user workstations, etc etc, all so you can use your fancy extension methods. As the interviewer, I’d try to get you to show that you could code an efficient sort or use the 2.0 sorting methods if you had to, no matter how much I might agree with you that the Linq libraries and similar extension methods are pretty sweet. An interviewer who doesn’t see the point might not even bother trying to get you to show aptitude for anything else; they’ll assume you don’t have it and move on.

This one got a bit long, but it might be helpful to someone so I’ll let it be.

I actually encountered something similar, going through a little over 20 interviews last month (a mix of phone and face to face). There definitely was something unexpected going on that I couldn’t quite put my finger on.

One of the things I noticed though was that the things that have usually been the center-point of the interview cycles of the past five or six years were decidedly not discussed or given short shrift. Things like the fundamentals of OOP analysis / design, patterns (design and architectural both), some of the more advanced / abstraction oriented .net features (including lambdas or LINQ specifically, generics, serialization / data binding, and similar), and even the usually hot topic of favored methodology (no one seemed to care much about agile vs waterfall or what flavor of agile) and tools or choice of ORM or preferred means of collaboration or source control management. In some cases not mentioned at all, in almost all cases apparently not of concern.

What did receive focus, in multiple interviews and various unrelated firms in unrelated industries, were along these lines:

• A strange fixation on outdated / outmoded conventions and “back to stone ages” limitations. Like developing a primitive web app in VS2003 with a list of absurd restrictions further forbidding the usage of explicit features extent within that era of .net…as if that is a real gauge of a modern developers ability…the ability to remember the paradigm and limitations of 9 years ago further crippled by unrealistic / arbitrary constraints. Another place was very dogged on the subject of custom collections, circa pre-generic collections. Another place dinged a code sample of a class model I scrawled out because I didn’t use cascaded constructors (they seemed unaware of the support for property initialization on declaration, which was sufficient to the need). Another place was big on delegates and did not like my response that I used to declare them frequently but I practically never need to declare them anymore thanks to Action<> and Func<>.

• Extreme focus on specific implementation details in a microcosm and / or configuration settings, even in the case of technologies that focus on being platform or protocol agnostic (i.e…the whole point is to NOT be fixated on a specific implementation or particular usage but rather on reuse / re-purposing / extensibility / as needed integration).

• Willingness to spec out / supervise / code review / and otherwise spool off work to and from an off shore team, and non-coding skills related to doing so.

• Usage of specific versions of products / platforms / modules / etc. To a sometimes absurd degree; “So…you’ve used versions 1, 2, and 4? But not 3, eh? Hmmm…{annotates your resume with “no v3!!!}”. Degree of usage did not seem to matter; only that you have or have not used something at all, and the specific thing that they are asking for also…no substitutions seemed to count, even of a more widely used and fully featured competing product.

• A far greater amount of focus on “how well will you fit onto our team” over “are you actually any good as a software developer” or “do you have the skills and experience to add value to the company and help us deliver a quality product” or even “are you a dangerous idiot who will come in and wreck shop”. In some cases, my resume was just taken as a given, and even the so-called “tech screen” or technical interview was a personality assessment far more than a skills assessment. Even for relatively short term contract positions where you would be there and gone again before two seasons have changed.

• Companies this time around seemed to have much less of a focus on solving specific technical problems, starting new green-field or big 2.0 development projects, or getting a specific product to market to capitalize on an emergent trend or opportunity, or the usual big kickoffs. A repeating theme that I noticed at at least 15 of the places was that a small group of 3-5 developers, mostly survivors of the market crash in 08, were able to grind out a product over the course of the last 3 years or so and found some success or their company as a whole is booming and they are hiring on new folks to keep up with increasing feature demands or to address / overcome the design flaws they built in to these systems, or to take over the aforementioned platforms to free up the core team that built it to do “other projects”. The details differed and there were exceptions, but that was the general lay of the land this time around.

But…if there’s one thing I know about this business it’s that it is cyclical. The next time I’m looking for a new gig, I wont be surprised if the game has changed yet again. You just have to remain mentally flexible, do some active listening, avoid making absolute statements if they are unnecessary but don’t be a weasel either, and don’t come off as being either one-dimensional (you come of as an idiot or a zealot, neither desirable) or as being too good (it can be threatening and cost you a gig).

Just adjust your approach, and try to give a more measured response next time…mention a few different ways you might approach a problem…but even if it is rote knowledge for you act as if you are actually thinking about it and reasoning it out on the spot. It seems more humble and less intimidating or offputting that way.

Of course, Murphy’s Law being what it is, the very next interview after you stop being “passionate about my current favorite technology guy” and adopt a more balanced / beard-stroking stance is the gig that you would have gotten had you been the crazed zealot guy. 😉

I think you are drawing a false conclusion, because your set of samples is too limited. Although I have seen a fair share of IT shops with strong aversion to anything “not invented there”¹, none of them would disqualify candidates based on their preferences in the technology stack: they were rightfully convinced that they could teach the right candidate to use their home-grown libraries.

I seriously doubt that the company banned the use of LINQ outright. More likely, they wanted you to show them your skills at a deeper level.

For example, one way to figure out if you know your hash tables is to ask you to implement a primitive one on a whiteboard. This simple exercise reveals a surprising amount of data about your knowledge to the reviewer: he instantly learns if you know about hash code / equals, and what you know about hash collisions. At the same time, it is hard to imagine someone in their right mind re-implementing a hash table, because Microsoft did so good of a job at it. Same goes for many algorithms, such as sorting and searching: interviewers often would like to know if your background is enough to understand low-level interactions, rather than checking that you have a working knowledge of .NET libraries.

It is a near certainty that they would insist on you using library implementations rather than your own once you are hired to work for their company. But during the interview they would push you toward the low level code to gain better understanding of your true abilities.

¹ one shop went as far as building its own rather primitive build tool!

I think you’re making some mad generalisations there of the “I saw a black cow in Scotland, so all Scottish cows are black” type.

If I interviewed you I’d be disappointed if you couldn’t answer my linq questions.

Linq is a tricky one though, a lot of people see it as voodoo which is unfair as it’s actually very simple and all the more clever for it.

To play devil’s advocate, the reason is many developers just don’t care about new things and think everything has to be solved with homegrown (usually inferior) tools. There’s nothing wrong with using abstractions. Hell, there usually is no good reason not to use those abstractions.

It sounds like you just interviewed with a poor developer that doesn’t keep up to date with things and takes the hammer and nail approach to everything. These are the types of developers that don’t know anything about helpful open source tools like NUnit, or NHibernate, or the various IoC containers; the ones who try to solve every problem with a massive stored proc in the database; the ones that know absolutely nothing about MVC despite it being out for several years now.