I am an independent contractor and, as such, I interview 3-4 times a year for new gigs. I am in the midst of that cycle now and got turned down for an opportunity even though I felt like the interview went well. The same thing has happened to me a couple of times this year.

Now, I am not a perfect guy and I don't expect to be a good fit for every organization. That said, my batting average is lower than usual so I politely asked my last interviewer for some constructive feedback, and he delivered!

The main thing, according to the interviewer, was that I seemed to lean too much towards the use of abstractions (such as LINQ) rather than towards lower-level, organically grown algorithms.

On the surface, this makes sense--in fact, it made the other rejections make sense too because I blabbed about LINQ in those interviews as well and it didn't seem that the interviewers knew much about LINQ (even though they were .NET guys).

So now I am left with this question: If we are supposed to be "standing on the shoulders of giants" and using abstractions that are available to us (like LINQ), then why do some folks consider it so taboo? Doesn't it make sense to pull code "off the shelf" if it accomplishes the same goals without extra cost?

It would seem to me that LINQ, even if it is an abstraction, is simply an abstraction of all the same algorithms one would write to accomplish exactly the same end. Only a performance test could tell you if your custom approach was better, but if something like LINQ met the requirements, why bother writing your own classes in the first place?

I don't mean to focus on LINQ here. I am sure that the JAVA world has something comparable, I just would like to know why some folks get so uncomfortable with the idea of using an abstraction that they themselves did not write.


As Euphoric pointed out, there isn't anything comparable to LINQ in the Java world. So, if you are developing on the .NET stack, why not always try and make use of it? Is it possible that people just don't fully understand what it does?

  • 8
    I think you don't know what "abstraction" is, because LINQ has nothing to do with it.
    – Euphoric
    Aug 10, 2012 at 18:31
  • 8
    "I am sure that the JAVA world has something comparable" Actually, LINQ is one of the few things, that .NET has and Java doesnt.
    – Euphoric
    Aug 10, 2012 at 18:32
  • 42
    @Euphoric--Does LINQ not abstract away the lower level work of tasks such as sorting and filtering for example? I am quite that sure that there would be some extra code behind objectCollection.Where(oc=>oc.price > 100) for example. Would that not be a use of an abstraction? Maybe you can tell me what I am missing here. . . Aug 10, 2012 at 18:37
  • 37
    There is always the chance that they just don't understand LINQ and don't see the value in learning it. The functional aspects of writing it are very very different from imperative programming. As a contractor I have as recently as 2009 seen "senior" Java developers that don't understand SQL enough to write advanced queries so they spend weeks optimizing code that brings all the data to the Java side and filters it with Java code instead of having the database doing it. Ignorance is rampant in the software development industry.
    – user7519
    Aug 10, 2012 at 22:39
  • 18
    If you understand LINQ but your interviewers don't, you're better than they are. Set your sights higher.
    – Jay Bazuzi
    Aug 10, 2012 at 23:07

11 Answers 11


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.

  • 4
    @MatthewPatrickCashatt You can't do edit and continue in the debugger inside methods containing linq statements. It's not enough of a turnoff that I don't use it; but it was the main reason I hesitated in doing so for a while. Aug 10, 2012 at 19:30
  • 3
    +1, especially for the second paragraph. It totally applies to me, since I would be completely unhappy to work on a C# code without being able to use LINQ. Aug 10, 2012 at 20:00
  • 5
    There's also the fact that there is frequently a performance hit in addition to the leaky abstraction. You are exchanging ease of use for precision, and that loss of precision frequently includes details that would make things faster. And the further removed you are from the source, the more details you loose and the greater probability that those details are important to performance.
    – jmoreno
    Aug 10, 2012 at 20:20
  • 6
    +1 but it can also work the other way. If someone tells me they did not hire me because I use Yacc to build parsers instead of rolling my own, then it isn't somewhere I want to work anyway. Aug 10, 2012 at 20:22
  • 5
    @MatthewPatrickCashatt: this answer (and my comment on it) are not specific to LINQ, but general statements. But for LINQ, here'san excerpt from C#4.0/5.0 in a Nutshell, talking about performance problems with LINQ. Back to generalities: in lots of cases the performance hit will be well worth it, 5% +/- being irrelevant. But sometimes it will be larger and sometimes even .1% is unacceptable. If you don't think there can ever be an issue, or that performance is only for companies like google....
    – jmoreno
    Aug 11, 2012 at 4:05

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.

  • 2
    Thanks jfrankcarr. I suspected that this may be the case--there were questions about opening and closing datareaders! Aug 10, 2012 at 19:08
  • 2
    +1 for calling MVC "new stuff." Made me laugh out loud. It's been around since the 70's. You may have meant MVVM which is essentially MVP (an MVC variant) that uses bindings.
    – user53019
    Aug 10, 2012 at 19:43
  • 14
    @GlenH7 I think it was pretty clear from context that he meant the product "ASP.NET MVC", not the basic concept of Model-View-Controller. Aug 10, 2012 at 22:05
  • 4
    @GlenH7 - I was speaking entirely within the context of the .NET and Visual Studio product line and Microsoft's product buzzwords.
    – jfrankcarr
    Aug 10, 2012 at 23:08
  • 6
    Good god, are there really shops that think of Linq as "new"? It's been around for over 4 years already. I can understand not having caught up to task awaiters, or to the use of dynamic/ExpandoObject/etc., or to not caring about Azure and all of the other cloud stuff... I can even understand continuing to use the old-school WebForms view engine in MVC or Web Forms itself, or writing WPF/WinRT code without MVVM... but Linq? If you haven't figured that out yet, it's time to quit your job as a .NET developer.
    – Aaronaught
    Oct 21, 2012 at 1:00

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.

  • 12
    Honestly, while I see the basic point, I don't think Linq's going away anytime soon. Linq2SQL, yes, they deprecated it in favor of the much more powerful EF. But Linq itself is the foundation for so much other shiny newness in the last 3 .NET releases that if they deprecated it they'd be undoing half of their new persistence-layer tech like Azure and EF, to say nothing of crippling practically every ORM out there and a LOT of in-memory list-processing besides.
    – KeithS
    Aug 10, 2012 at 22:01
  • 6
    wait... "terrified to move away from old, outmoded tech, because it works"... WTF. Have we come to the point where working stuff that is tried, tested, understandable and maintainable, and mature is NOT good.
    – gbjbaanb
    Aug 10, 2012 at 22:50
  • 7
    @gbjbaanb--No. But--as an anecdote--would you want a doctor to diagnose your chest pains with a chest x-ray because that method is 'tried, tested, understandable' or would you want an fMRI that is newer, but comes with higher resolution, better prognosis and more information? No one is saying to turn away from classic principles here; quite the opposite. You see, LINQ (as an example) is built upon those principles. I think, as others have mentioned, it is the learning of the parts that make LINQ and it's proper use that cause the 'WTF' moments such as yours. Aug 11, 2012 at 2:59
  • 2
    @MatthewPatrickCashatt : depends, if the doctor has not been trained to read the fMRI results, I'd take the x-ray rather than have him guess at a diagnosis. If I got ill in a backwater, I'd rather have a doctor who could diagnose with nothing more than a stethoscope than be unable to cope without the ultimate in latest tools.
    – gbjbaanb
    Aug 12, 2012 at 23:17
  • 2
    @MatthewPatrickCashatt I see your point, but a balancing factor is you don't want to follow every trend just because it is newer. I'll happily follow a new tech that fits into one of two categories. 1. It excites me and I'm willing to spend my free time on it. 2. It proves itself to actually be better and seems like it will last long enough to make it worth the investment. Trends that do not fit into one of the two categories are a gamble at best. Oct 22, 2012 at 17:16

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.

  • 1
    Good points. Agree on the costs that you mention and it's a good clarification. More broadly, however, developing homegrown classes with which no new employees can be familiar because they don't exist outside of the organization presents the same challenges in addition to the cost of primary development. Aug 10, 2012 at 20:10
  • 2
    @MatthewPatrickCashatt - Oh absolutely. That home-grown code should thus almost always be more effort for the same win, but is not necessarily. Like many other things, the cost/reward should be estimated and the best practice preferred, not followed blindly.
    – Telastyn
    Aug 10, 2012 at 20:21
  • @Telastyn Home-grown code is also nice since you know what it does and can fix it at a moments notice. Also, you can optimize for specific circumstances based on your own usage, not an average of everyone's.
    – Hawken
    Oct 21, 2012 at 2:22

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."

  • +1 - as well as telling them what you know about, ask them what they are doing and what they specialise in. Oct 23, 2012 at 6:49

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.

  • 2
    I agree with this, but I've noticed a lot more people that use this attitude to dismiss good ideas that they just don't understand (e.g. testing, design patterns, ORMs). So while I agree that being a good fit for the team is a good thing, it's important to realize that you might be better than the rest of the team and should find like-minded individuals where it isn't a bad thing to know good abstractions. Aug 11, 2012 at 0:50
  • 1
    @WayneM sure, but the OP is a freelancer, so it really doesn't matter if he is a coding god, unless they're prepared to hire him permanently to maintain code the rest of the team doesn't understand (hmm) then he needs to do what they want, not what he wants.
    – gbjbaanb
    Aug 12, 2012 at 23:03
  • 1
    @WayneM likewise a lot of people would use something similar to what you just said to promote that their ideas over someone else's (being confident that who their talking to simply doesn't get it). In the end both sides are biased, but the OP is about getting hired, not winning the grand DIY/abstraction war. Everyone will have their own opinion, but someone's got to get over it; I'm guessing it won't be the employer in this case. :(
    – Hawken
    Oct 21, 2012 at 2:30

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.

  • Why wouldn't you just write your query as var resultList = inputList.Select(i=>i.Property).Intersect(otherInputList.Select(o=>o.Property));? I might have botched that, but my point is that LINQ has better ways of executing the query you mention above (.Join() is another way). I realize that there are ways to use LINQ that might not be as proficient as other ways, but that doesn't mean you have to rely on those bad implementations. Aug 10, 2012 at 22:40
  • 4
    @MatthewPatrickCashatt I don't think his point is so much to claim that LINQ is always inefficient - while you can always beat a given LINQ query, some uses give better performance per developer-hour than many non-LINQ approaches. Rather, it can be relatively easy to write a LINQ query that is inefficient and not realise it, because the inefficiencies aren't as blatant.
    – Jon Hanna
    Aug 11, 2012 at 11:51
  • 3
    @JonHanna: Perhaps more to the point, the value of an abstraction is greatly reduced if one must examine what code is "really doing" to determine what uncommon-but-plausible scenarios might cause performance to be many orders of magnitude worse than expected. If changing from one data structure to another will cause code to run 10,000 times slower, the ability to make such a change without altering any other code may not always be a good thing.
    – supercat
    Aug 13, 2012 at 17:26
  • 1
    @supercat: yes and no. Just because knowledge of how something is done in a third-party implementation is critical to understanding performance implications and avoiding inefficiencies, doesn't mean the libraries that encapsulate these tools have less value. It's two sides of the same coin; know the nature of the implementation, and you can use it with a few keystrokes instead of an hour rolling your own. But, you have to know both sides, and the stereotypical Linq fanboy who thinks it's perfect, nothing wrong, use it for everything likely doesn't.
    – KeithS
    Aug 15, 2012 at 17:03
  • @KeithS: One thing I think is sorely missing in both Java and .net is a standard means of asking objects or collections various things about themselves. For example, code which receives an enumerable collection might benefit from knowing whether the number of items and/or the sequence of existing items could ever change, whether the number of items is known to be finite or infinite (or not known either way), and whether the collection inherently knows how many items are in it. Technologies like LINQ often have to make assumptions about such things that may or may not be correct, and...
    – supercat
    Aug 15, 2012 at 17:12

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"1, 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.

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

  • 2
    All of your points are well made, but I should give you some color around the last interview: the interviewer insisted that LINQ was being "deprecated". I asked, "don't you mean that MS will no longer be investing in Linq-to-SQL but that Linq-to-Entities will be around" and his reply was that he meant what he said: LINQ is being "deprecated" so, no I don't think that he knew too much about LINQ or would insist upon it's use. Aug 10, 2012 at 18:58
  • 1
    @MatthewPatrickCashatt If someone confused LINQ for LINQ2SQL in terms of the technology being deprecated, I'd made up some silly excuse to leave the interview early, and never called that company back. If that was indeed the case, you should be happy about them not hiring you :) Aug 10, 2012 at 19:30
  • 1
    100% certain that was the case. In fact, I couldn't resist sending him some links to set him on the right path on the subject, not as a jab since I didn't get the gig, but because I actually felt embarrassed for him and was hoping that I could help him to not make the same mistake twice ;). Aug 10, 2012 at 19:47
  • 4
    Then this appears to have less to do with the technology stack and more to do with the fact that you corrected him. People don't like to be corrected. It's just human nature. When people make decisions such as hiring people, 99% will go with their intuition. They go by whether or not you caused them to feel positive or negative emotions. Correcting him may have caused him to feel negative emotions. And he then associates that negativity with the situation.
    – coder
    Aug 13, 2012 at 13:33
  • 1
    I don't know how hashtables work internally. Deep technical tests like that throw out people with practically minded training that are good candidates nonetheless. Requiring people to have low level knowledge they will never use seems unnecessary to me. Design principles have become much more important!
    – Tjaart
    Oct 22, 2012 at 15:00

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.

  • You may throw LINQ into a buzzword pool containing Nhibernate etc... I would not do that. Actually I think buzzwords exemplify our inability to explain abstractions into proper expressions. Oct 23, 2012 at 9:05
  • You are talking about 'keeping up to date' well I think the inverse wOuld be very much more appropriate. Many useful concepts have been discovered and used in the past, for example DSL's . It is up to us to improve our communication and grasp of concepts such as that we don't need to invent new buzz words for old concepts. Oct 23, 2012 at 10:23

Not the answer you're looking for? Browse other questions tagged or ask your own question.