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.

Answer: Leaky Fanboys (43 Votes)

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.

Answer: Code-osaurs (12 Votes)

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

Think you know why abstractions are taboo? Disagree with the opinions expressed above? Bring your expertise to the question at Stack Exchange, a network of 80+ sites where you can trade expert knowledge on topics like web apps, cycling, patents, and (almost) everything in between.

Matt, how long have you been working as an IC? Your approach to finding out why you weren't getting the jobs is the right one, but it surprises me that you fell into this trap in the first place. Always remember:

It's not about what you think is best, it's about what they want.

I run my own firm as well (in a totally different field) and the very first hard lesson you learn in business is that what you think is best or correct is only relevant if the client is willing to actually place complete trust in you as an expert. Most clients aren't willing to take that step, however irrational that may seem in the face of them hiring an outside expert. Most clients want you to do the job they want done, the way they want it done. They don't understand your new-and-better way, and there's nothing more uncomfortable to a businessperson than feeling like they're out of control of a situation. If you can bring in some clever twist without actually doing anything really different than the way they want things done, yay. But stick to the program.

Rarely you get a client who really does want an outside expert to come in and show them a new, better way. But I'd guess that's 1-in-50, at least in my field. A pleasant exception, to be relished when you stumble upon one.

So don't be terribly surprised that companies are rejecting you because you're proposing something different than what they already use. That's the way it works. Your job, as a contractor, is to find out what the client wants, determine if you can do that (their way), and then sell yourself to them on that basis if the answer is "yes".

This is business. It isn't about "showing them a better way". It's about solving their problems in a way that makes them feel comfortable. No more, no less.

The best thing about these articles is that I learn something new and interesting every time.

Hmm.

While there is some oblique technical information, I find that the questions and discussions they engender are overwhelmingly social. How do I learn, how do I integrate/ingratiate myself, how do I work with others, how do I communicate effectively - stuff like that. They're wrapped up in technical encounters, but the underlying issues are never technical. I mean, the answers here boiled down to "resistance to change" [edit: and "the customer is always right," as SinclairZX81 points out above], which could apply to a law firm having a preference for secretaries who take notes in shorthand rather than typing on laptops or a landscaping firm being resistant to a combined mulch and fertilizer product.

Then again, I have a set of peers (Microsoft MVPs, etc) who I IRC with that probably keep me passively updated on all this stuff, so I'm at least peripherally aware of a lot that I wouldn't be if I only relied on my own reading/research.

The best thing about these articles is that I learn something new and interesting every time.

Hmm.

While there is some oblique technical information, I find that the questions and discussions they engender are overwhelmingly social. How do I learn, how do I integrate/ingratiate myself, how do I work with others, how do I communicate effectively - stuff like that. They're wrapped up in technical encounters, but the underlying issues are never technical. I mean, the answers here boiled down to "resistance to change," which could apply to a law firm having a preference for secretaries who take notes in shorthand rather than typing on laptops or a landscaping firm being resistant to a combined mulch and fertilizer product.

Then again, I have a set of peers (Microsoft MVPs, etc) who I IRC with that probably keep me passively updated on all this stuff, so I'm at least peripherally aware of a lot that I wouldn't be if I only relied on my own reading/research.

I left the industry to enter finance. I keep a technet sub for fun and play with VS express and the full versions when I can take the time to get a semester of classes in and get my free MSDNAA copy. My roommate is a DBA, so when I read about stuff like this, we then get to discuss it over sunday breakfast and come up with random examples to make things work and see how useful it is IRL.

I then also get to see interview pitfalls and discuss it with people I know who are looking for jobs. Thus, I get a huge amount of benefit from these articles that probably isn't representative of the population as a whole. But I definitely appreciate it.

[SNIP]It's not about what you think is best, it's about what they want.[/SNIP]

Bingo! This is true across IT. It's a real challenge NOT to go to an interview and attempt to "blow them away" with your ideas. This is true whether applying for a job or a contract. It's not always a mistake but my experience has taught me to do my utmost to learn what the client (or employer) really wants before suggesting that I have better ways to accomplish their goals (that comes after I've got the job!).

LINQ and EF are both incredibly complicated, and the organizations may not want to have a lot of code to maintain using these super-abstraction layers. You may understand it, but does anyone else? I tried to read Lerman's book on EF recently, and even though I knew Hibernate fairly well, I was baffled. LINQ is a good idea, but looks like syntactic mush in code.

Super-abstractions have a tendency to collapse under their own complexity. I predict EF will join CORBA, XML, and other technologies that are too abstract and bloated for their own good. Microsoft's COM is another super-abstraction (language-independent, reusable objects) that was so complicated it didn't really become practicable until .NET simplified it greatly. (These sorts of technologies tend to have a leading evangelist like Don Box or Julie Lerman, who do nothing but study these things day in and day out, but even with their definitive explanations, the technologies are hard for mere programmers to grasp.)

LINQ and EF are both Microsoft technologies, and any organization would have to be worried about their churn of obsolescence. LINQ is already being deprecated in favor of EF in the Visual Studio tools, accoring to Lerman. (And EF is in flux.) Meanwhile, ADO.NET (and ODBC) just work, and will keep working for a long time. I can't blame anyone for being gunshy about the latest new shiny great Microsoft thing, since MS has a habit of abandoning things quickly. And, love it or hate it, JDBC has been rock solid for a long time and won't be abandoned soon.

What usually happens is that there are hundreds of ideas, even good ones, and the most practical and usable ones survive. It's not bad that MS hires a lot of smart people to come up with these ideas, but it doesn't mean every idea will be widely adopted.

I am a Java programmer and I many times in a interviews I am asked which stack of technologies I usually work with. Of course I always try to give honest answers but sometimes companies just want to hear that you use X over Y so they can hire you.

That happens a lot with ORMs and DI frameworks, I prefer pure Hibernate over JPA+Hibernate but many times the interviewer ask something like "But you know that Hibernate is not a Standard?" and that is a trap question: You can say that even if JPA is not a standard you prefer Hibernate because it was first and more mature OR you can say that you prefer standars (even if the underlying framework is Hibernate) because they are well supported and java shops tend to be very rooted to one thing or another.

A example was a company that banned Hibernate from almost all his projects when they lost one to other company that used JDBC directly. If you ask any programmer from that company most of them will tell you "Hibernate is slow", "In this company nobody uses Hibernate, it is not efficient" etc.

Same happens with Struts and Web Development. It is so rooted in older companies that they won't use anything else, even for new projects, but I find it very aged for web development.

[SNIP]It's not about what you think is best, it's about what they want.[/SNIP]

...my experience has taught me to do my utmost to learn what the client (or employer) really wants before suggesting that I have better ways to accomplish their goals (that comes after I've got the job!).

Yep. I've found that to be an excellent strategy as well. Get the job based upon being able to do it "their way" (and be truthful about that), and then broach the idea of a "better way" once I'm in the door. Not as a, "your way is wrong, we should do it this way" sort of thing, but rather, "Hey, I was thinking, and it occurs to me that we might get this done a little better by doing ("x"). What do you think about that?"

If they say no, then we keep on with the original path. No harm, no foul. But by showing them that I'm actively engaged in trying to make the solution better, and (most important) by giving them the opportunity (and control) to make the decision, I find I get "my way" a lot more often than if I'd come into the interview and told them "I have this newer, better way to solve your problem."

The commenter above who pointed out that these sorts of questions are "people problems" rather than technical problems was spot-on. And that's the way it is in business. 80% of the project is people issues, at least at first. Neglect that at your peril.

In a large organization, changes can only be implemented gradually, so suggesting radically new ideas in an interview is likely to scare your prospective employers off. Even if what your proposing is not radical at all, but is completely over the head of the interviewer, you lose. Unless the new ideas are currently fashionable and the interviewer has already decided they want to jump on that bandwagon.

From the other side of the table one I can say that I am not biased against abstraction technologies, in fact I tend to prefer folks that are versed in them as many forms of abstraction remove the developer's opportunity to screw something up horribly (Managed languages mostly removing the ability to clobber memory, LINQ removing the possibility of SQL Injections, many frameworks making you opt out of CSRF protection, etc.), but then I am a appsec guy so that biases my view considerably. That said, one of the things I constantly look out for in an interview is someone who chooses their toolkit based on what they are comfortable with rather than what is actually optimal for the job, and a heavy focus on abstraction technologies can easily give that impression.

Expanding on that, if the interviewer doesn't understand how some form of abstraction technology is actually better, they may end up with "the wrong tool for the job" impression even if it they are wrong to have done so. In the example of LINQ, novices tend to write horribly inefficient code, which has created a bias among a lot of .Net folks that LINQ is slow (rather than people who don't know what they are doing create crappy implementations, which is generally true of all programming technologies) and thus many interviewers have a strong bias against it (never mind that well done PLINQ is significantly faster than the competition).

When interviewing half of the process is getting a handle on the folks asking the questions, what their needs and knowledge set is, and tailoring your answers to them. That doesn't mean necessarily not mentioning an abstraction technology, but rather demonstrating you don't need it and making the case for why you think it might be the route to go anyway.

That said, one of the things I constantly look out for in an interview is someone who chooses their toolkit based on what they are comfortable with rather than what is actually optimal for the job, and a heavy focus on abstraction technologies can easily give that impression.

This is an extremely important point.

Just because a tool is new and cool doesn't mean it's the right choice for the job. And in 20 years of developing, I've seen a lot of the "cool" tools turn into nightmares down the road.

LINQ, when wielded cautiously and with deliberation, can be a great tool. But I've seen a lot of LINQ code written that basically takes SELECT * FROM dbo.GiantTable and then uses LINQ to filter the results in memory because the programmer knew LINQ, or used it as a shortcut, instead of thinking about performance and scalability.

One of the nice things about EF is that it allows you to get away with this and does a pretty good job of optimizing your queries for you before it hits the DB. But it also takes programmers (particularly junior level programmers) further away from the kinds of issues they need to think about on larger projects, and that concerns me.

As an interviewer, I would be cautious about a programmer who is so happy evangelizing their hammer that they assume your project is a nail.

This may not even apply to your situation, but a lot of times if someone goes on and on about an abstraction, library, or framework I tend to get the impression that they're not very experienced or technical. We have no problems with using some of these, but if the interviewer is asking questions and the answers all tend to be "well with X it just takes care of that for me" then it sets off red flags.

The central lesson from the authors experience is one that is being widely missed by the fashions of the software technology industry. Companies that use software in their business are primarily interested in their business not in the next great thing in software technology. Even when those fashionable great things have some real value, it is rarely enough to justify disrupting an existing software base. Even in the case where there would be real value to that kind of effort, businesses that depend on their software to achieve business results on schedule, are slow to accept the risks inherent in any substantial disruption of their software base.Another view on the problem is that a business is interested in what a new employee is going to do for them. That effort will start with understanding their business and how their software environment works. They want somebody who is will be a quick starter doing work the way their software group does work. They are usually not looking for somebody whose main interest is the latest talking point from Microsoft marketing unless that talking point happens to be on their agenda and that skill is the one that they are particularly looking for.

EF Is complicated, but LINQ is just an extension of the C# language that allows for access to a wide variety of data sources. Heck you can use LINQ with XML!

That said, it is generally preferable that people have an understanding of how technology operates underneath the hood. Knowing how LINQ is implemented (it isn't that complicated! A few hours of reading and a Channel 9 video or two and you'll understand it!) means one will also understand potential pitfalls.

The same is generally true of any technology. If someone is using a higher level feature, I always prefer they understand how that feature works. No abstraction is air tight, leaks always occur, knowing how to patch up those leaks (or preferably avoid them in the first place) is immensely valuable.

I think being turned down for a job on the basis of using abstractions is ultimately good for the candidate. I wouldn't want to work anywhere that had a general policy that deemed all abstractions to be bad. That's not just an argument for not using LINQ but also any framework.

I personally use LINQ all the time because it's concise and flexible. The resulting code is often clearer and therefore easier to maintain. With PLINQ it's trivial to parallelise code.

Clearly if you don't understand what's going on 'behind the scenes' then you can get yourself into a bit of a mess. But that would also be true for a developer that didn't understand to pre-calculate as much as possible outside of a loop to keep the inner-loop code as optimal as possible.

I have been at the other end of this argument, having come from the 8bit world, and also written highly optimal 3D graphics engines (that fit into the 1k instruction cache of a Playstation for example); but those days are over for today's large applications.

Of course it's still possible to create applications like these without abstract techniques but it's significantly more difficult for developers to keep this in their heads.

Ultimately a program isn't just your way of communicating instructions to the CPU, it's also your way of communicating with yourself and other developers on your team. If code is unnecessarily complex just to maintain some kind of closeness to the metal then that makes development more difficult for the team.

The argument that junior programmers don't understand what's going on, and therefore they shouldn't use the abstractions is the wrong way to think about it. Any development house worth their salt would have code-reviews, and a senior developer should be reviewing and mentoring junior staff of the best approach.

Write the code first, make it work, profile, optimise when you realise its performance is problematic.

In my opinion, if we want to use the multicore machines of the future to the fullest extent we will need much higher levels of abstraction than LINQ so it's time to get involved.

I too have suffered the same fate as the Questioner and in the end it boiled down to one point, by babbling about a technology we sound too technical and arrogant.

Companies want people that can communicate well and adapt to their environment. There are many valid reasons to use of X or Y and by focusing on one piece of technology we only show inflexibility and incomprehension of matters.

Even mentioning a specific implementation when they directly ask about a project can be a job killer.

My advice would be to always focus on the project management side of things and not on the technologies used when discussing such matters. One needs to be open to the job technical needs, be them wrong or right choices.

Even if their current employees are snobbish, the new guy trying to argue about such matters is being no less. You have to prove your worth to them before they start taking your advise seriously.

These abstractions are normally recent technology and as such the focus of said disputes.

You have the current team doing n-tier because it works for all of them and then you have the new guy "trying to be smart" arguing that the technology that only he knows about is the way to go just because. Even if he has no intention of sounding as such.

I think it has a lot to do with the existing code base and methodology that the company has, and the tendency for over enthusiastic newcomers to try to evangelize everyone to use their cool new toy. I've seen this person, I've been this person, and the most important thing to realize is 1) just because something is cool and "new" doesn't mean it's the answer to everything and 2) when all you have is a hammer, everything looks like a nail. Perhaps the solution is to present LINQ as an alternative, while still demonstrating that you are comfortable and familiar with the alternatives (like traditional DALs). FWIW, I'm an MS SQL guy and think that some of the elements of LINQ are really cool, but when push comes to shove I'll resort to a DAL because it's common, it's well-established and it works.

While there is some oblique technical information, I find that the questions and discussions they engender are overwhelmingly social.

And are social issues not worthy of discussion and learning? I submit that more people need to learn about social mores and interactions - and I'm not just talking about nerds here. We all benefit when we can communication with each other with a high degree of understanding and accuracy.

While there is some oblique technical information, I find that the questions and discussions they engender are overwhelmingly social.

And are social issues not worthy of discussion and learning? I submit that more people need to learn about social mores and interactions - and I'm not just talking about nerds here. We all benefit when we can communication with each other with a high degree of understanding and accuracy.

While there is some oblique technical information, I find that the questions and discussions they engender are overwhelmingly social.

And are social issues not worthy of discussion and learning? I submit that more people need to learn about social mores and interactions - and I'm not just talking about nerds here. We all benefit when we can communication with each other with a high degree of understanding and accuracy.

"Resistance to change" is often more more of a technical, social question than a philosophical denial of anything new. If at my work we were to change our existing code base it would be an enormous amount of effort. We're talking millions of lines of code involving C#, ASP.NET, some VB6, some PHP, some SQL originally written for SQL Server 2000 now running on 2005 and 2008 (and soon Azure) for various products, and even some mySQL. We're also talking applications that support a media company's largest revenue stream in a highly competitive market (advertising). The risks far outweigh the benefits of using only one solution over the others purely because it's "better." Where it's possible to use LINQ, the C# devs do so, mostly on new development but sometimes as an upgrade to existing code. The same goes for newer SQL methods for me. On new development I use them. When modifying existing code, when possible I straighten out bad schema, or upgrade stored procedures to newer methods and design practices like getting rid of inelegant bitmasks and comma separated strings being passed to the proc, converting RBAR to set based solutions, unnecessary dynamic SQL, overly complicated wrapper procs, etc. By the time everything is on the same page, there will be some other new/better/novel way of doing the same old tasks to start using.

A lot of times people the term LINQ is used to (incorrectly) refer to LINQ-TO-SQL. Now I can see how some people shy away from LINQ-TO-SQL, it's hard to properly use in an n-tier environment. But straight LINQ against objects? Well then it almost seems crazy not to use it. There are exceptions of course, because I've seen 200 line LINQ statements and that makes me a sad puppy.

But to find a subset of data used for iteration or a single piece of data? Oh hell yes.

I took over a development team about two years and have implemented both LINQ and EF into the environment and I found more of my junior levels were having trouble with the implementation but eventually embraced it. EF allows for sever level code to access simple data without the barrier of the DBA, the end result is that when you create a new project 90% of your stored procedures are gone your models\classes are already built from EF dbContext generator which also gives you and your DBA more time to work on more complex code. I probably won't write another project without LINQ and EF.

Where I've worked, the business has almost always been interested in minimizing development time over nearly everything else. Abstraction helps get me there, and LINQ (typically querying against Entity Framework) is something in the toolbox that I'm happy to utilize. Like any tool, it doesn't solve every problem and it can be misused, but that's not a valid reason to write it off.

If I walked into an interview at a .NET shop that said I shouldn't use it, I would write that place off and go looking elsewhere.

RivetGeekWil wrote:

I think it has a lot to do with the existing code base and methodology that the company has, and the tendency for over enthusiastic newcomers to try to evangelize everyone to use their cool new toy. I've seen this person, I've been this person, and the most important thing to realize is 1) just because something is cool and "new" doesn't mean it's the answer to everything and 2) when all you have is a hammer, everything looks like a nail.

I worked three years in Silverlight and fell in love with XAML only to see the iPhone and iPad come out and destroy it, so I've learned all about how not to chase Microsoft's latest fad. That said, LINQ has been out for half a decade now and it's not new. I don't need the ghost of Steve Jobs to love it for my customers to benefit from it. Since I progressed as a developer beyond .NET 2.0 in 2009, it has become an essential part of how I solve business problems with my code.

If by now LINQ is not in use in a .NET project then that means the developers are all stuck in an ancient version of the framework or the software itself is stuck in an ancient version of the framework. I'm happy to modify aspects of my coding style/naming conventions/etc to mesh with a team and its existing code base, but if my primary work would be in legacy code or legacy ideas then I would burn out quickly.

A company that writes software with the motto of "we've never done it that way, so we'll never do it that way" will probably find themselves blown away by a competitor.

Put emotions in the bin (where is their place when judging technology). And stick to simple reasons (as they tend to be most probable )

When you use ANY abstraction, or in fact ANY technology and in fact ANY knowledge. You increase learning cure for anyone who will deal with your work. For programmers that mean that your BOSS, your COPROGRAMMER, TESTER, (sometimes) CUSTOMER, and even PR department will need to know the same piece of knowledge, technology, abstraction.

Stuff that cut off development time is very good. But if it do the job.

If you save 10 days on your work but team as whole need to spend 20 days on learning, its 10 days longer than without using your trick...

That is even more important when its only project you will do for such organization, or if project will be given to independent team for further maintenance.

[SNIP]It's not about what you think is best, it's about what they want.[/SNIP]

Bingo! This is true across IT. It's a real challenge NOT to go to an interview and attempt to "blow them away" with your ideas. This is true whether applying for a job or a contract. It's not always a mistake but my experience has taught me to do my utmost to learn what the client (or employer) really wants before suggesting that I have better ways to accomplish their goals (that comes after I've got the job!).

Having said that, if you want to be able to program with LINQ then not getting the gig is not a bad outcome.

If you save 10 days on your work but team as whole need to spend 20 days on learning, its 10 days longer than without using your trick...

With this way of thinking you never try anything new, because it's always "faster" to do it the old way. For something like LINQ, the amount of time invested in learning it is earned back incredibly rapidly because it is such a time saver.

I think there's something deeper at play that you as the interviewee may not have realized. Let me set the stage a bit...

I've been programming for right around 30 years, about 20 of that "professionally". For probably half that time part of my job has been to interview candidates, and that has been more and more a part of it over the years, so I've learned quite a lot about how to ask "good" questions that get to important truths without being direct.

What these people MAY have been getting at with you is whether you are a carpenter who can use a compound miter saw but can't cut the same clean angles with a hand saw and a protractor.

In other words... I've interviewed SO many people who on the surface appear to be competent... they have experience with Hibernate (since most of my work has been on the Java side the last decade) but when you ask them what an outer join is they haven't the faintest clue. Now, that person can probably get quite a bit done with just their Hibernate skills... but without knowing the underlying basics there will ALWAYS be situations they aren't equipped for.

Moreover, you also many times run into people that CAN'T work at the lower level. I don't know you obviously, but you may be the type of person who is fine with LINQ, but without it you're virtually useless because your brain just can't function at a lower level. Again, I don't know if that's you or not, but many people certainly fall in that category.

I spent something like five years of my life straight doing nothing but Assembly. That was YEARS ago and I haven't even looked at Assembly recently. More than that, I don't think I'd WANT to do that type of work again... but that's fundamentally different from someone who COULDN'T do it... it's also different than someone who can be working with a high-level abstraction but in their mind is actually seeing the lower levels that they know have to be down there.

When a Windows developer drags a window around the screen, is he the kind that can picture in his mind's eye all the messages that are flying around and entering the message pump loop, how they get dispatched, etc? I don' t mean can they accurately describe it all, but can they have a rough idea of what's going on? Or is he the kind of developer that knows that when he sets the Moveable property to true then the user can drag the window around and that's all he knows and all he WANTS to know? Because the guy seeing those details, even if only subconsciously, is a FAR superior developer 999 times out of 1000, guaranteed.

That's the sort of thing that, assuming these were good interviewers interviewing you, they were probably trying to get at and may have been why you were rejected... and by the way, it doesn't mean they were RIGHT, it just means that you may have missed the subtlety and didn't adjust your answers accordingly, which is a difficult skill to master for anyone being interviewed (although as much as it sounds like you've done it you probably do have that skill and maybe just missed it this time... it happens!)

I won't answer the original question, but, from my experience, I have two very different views to express on abstractions.

1) Abstractions are cool, until you forget the basics. I see it every day with Hibernate and various other ORMs: these abstractions are useful, but the new generation of programmers have never used anything else, they don't know what it takes to design and optimize an SQL query, they mistake pure memory data models with database/ormed/ehcached data models. ORMs are (too) complex, and put in the wrong hands, they cause more problems than they solve. I've never used Linq, but from the wikipedia article, although it seems an interesting technology, I suspect it can be abused and misunderstood in the same ways. <-- this was the answer from the architect

2) My organization uses a handfull of frameworks and abstractions. We are on tight schedules, and every time we try to venture on new grounds, it ends up badly: bugs, delays, mistakes, need of consulting time, etc... Our technology bag might be aging a bit, but we're comfortable with it, we have our experts, we can solve any problem. We will need to evolve, that's for sure, and I'm not sure yet how it will happen, but one thing is sure: we won't recruit someone just because he's bragging about technology X or Y. We don't need new technologies, we have some real work to do. <-- that was the anwser from the project director

All good abstractions function by covering up complexity, replacing it with a simpler and easier layer.

That's a really great idea in theory - but the problem is, the complexity is still there. Just because you can't see the abstraction doesn't mean it has gone away, and the fact that you cannot see it will really bite you in the ass if there is ever a problem. Fixing a complicated problem is like trying to cook a nice curry while blindfolded if there is an abstraction layer in the way. It can be done, but it's really really slow and frustrating.

On the other hand, sometimes an abstraction provides massive benefit, and sometimes they are really stable. For example, C is basically an abstraction on top of Assembly, and C is much nicer to work with and it's stable/well understood.

If an abstraction layer is fairly new (less than 5 years old) or has a history of bugs then I won't touch it with a 10 foot pole. If it's stable and older than 5 years, then I'll consider using it.

If you are a competent programmer, then you should be able to work without any abstraction layer. It might seem like more work in the beginning, but understanding what is going on will usually pay off in the long run, because when there are bugs you will understand them and the fix will take minutes instead of days.

Basically, it's a choice that needs to be made on an individual basis, but in general it is better to error on the side of not using abstractions than the other way around. Also, if you are working in a team of programmers then everybody needs to work at the same abstraction layer, so you can work with each other's code.

Another thing to keep in mind, if you write your own abstraction layer instead of using somebody else's abstraction layer, then you will understand what's going on and be able to fix bugs easily. Obviously this is really hard work, but it can pay off in the long run. If there are no stable/mature third party abstractions available, then I'd rather write my own than trust something new.

What are we talking about here? LINQ as in the language extension? Or LINQ-to-SQL/LINQ-to-Entities? If the former, you not only miss out on productivity, but also an important way of thinking about code. If you use C# are a purely procedural language, you miss out on a large part of what it has to offer. The functional paradigm that it offers in the form of LINQ can not only be hugely helpful in writing concise, readable code quickly, but also makes you a better programmer in general by teaching you to think in a new way. Yes, you have to learn it but if you're opposed to learning you have no business in the coding business to begin with. Avoiding LINQ as a rule results in lower quality code, period.

If we're talking about the SQL kind, then there's both good reasons to use and and not to use it. Well, the reasons not to use it boil to down to two, really:

1. Performance. This is the big one and one where it's not hard to run into the limitations. Entity Framework in particular can be quite slow. Not only does it carry a significant overhead, its bigger crime is not really its own, but it makes a programmer lazy and hides the complexity of what goes on underneath. When you need to fetch a customer and his orders, for example, it's *so* easy to just .Include(c => c.Orders) but the resulting SQL can be horrendous. Even worse, when the programmer doesn't have the foresight to Include relations and instead just lazily loads everything with the well known n+1 query problem as a result.

2. Leaky abstractions. This one is not that important, but it can definitely bite you. The most common mistake is to use something in the query that can't be translated to SQL, causing a runtime exception. It's sometimes hard to judge what you can and can't use, or what parts of the query it will translate to SQL and what parts it will do before or after the query.

The other big benefits of LINQ-to-Entities aside from productivity are also two-fold:

1. Refactorable. You don't have to worry about changing something about your data model because either your changes will carry over to your queries automatically or you'll get a build error. If you don't use LINQ queries, your queries will be either string blobs in code, or stored procedures in your database. Renaming a property can break queries in a way that you won't notice at build time. There's solutions to this, you could for example include your database as a SQL Server Data Tools (SSDT) project and write your queries as stored procedures, and they will get verified for syntax at build time. But it's definitely more work than with LINQ.

2. Testable. This one doesn't get mentioned much and maybe I'm wrong in this, but I like being able to easily unit test my queries too. With LINQ, you can simply test against an in memory collection as a 'database' instead of a SQL database.

My experience in my latest project with EF is that it's nice but it also has many quirks. Part of that is that it's a framework that tries to do *everything* and spreads itself too thin. I would like a LINQ based ORM that focuses on performance and the strengths of LINQ without all the enterprise-y bullshit like extensive support for inheritance.

In the end, my project uses EF to generate the database (code-first) and keep it in-sync with the datamodel, and also for updates/inserts as they're not as performance critical for us. We still have LINQ queries in some places, but for the most parts any new queries I write are plain SQL and we use the micro ORM Dapper for executing them, which is quite powerful. The performance difference isn't merely academical and is quite noticeable. Yes, you can do a lot better with EF than we did in terms of performance, through compiled queries but it's still not nearly as fast as Dapper. I'm still convinced a LINQ based ORM could get nearly as fast as Dapper if it made it its focus, but alas, that's not the case with EF.

LINQ wouldn't be around unless those using SQL weren't a bit frustrated...I'm kind of the opposite on this, not using LINQ indicates to me you don't know the fundamentals of the query language, or the fundamentals of .NET collections and that there needs to be a bridge between those two domains.

There is no reason not to use it... you can stick it in anywhere you would the low level ADO.NET stuff.

I definitely agree with the others that high level APIs/abstractions are all well and good but they come and go. If you don't have a firm grasp of the fundamentals you're fairly useless as a developer on a complex project because if something goes wrong you won't have the tools and knowledge to analyse and fix the problem in a timely manner. Furthermore if you do know the fundamentals and how the underlying technologies work you'll be able to understand and use any of these 'abstractions' and actually will be capable of evolving with the times.

By over emphasizing a specific abstraction you're giving the interviewer the impression that you're *not* a well rounded developer and would only be comfortable coding using that abstraction. In their position I would pass as well. It has absolutely nothing do with being taboo and is silly to even suggest that. If they wanted LINQ or pancake cooking knowledge they would have put it in their job requirements.

Just remember that abstractions (at least in the java world) are a dime a dozen and everybody and their grandmother either has a favorite one, wrote one or is writing one. If all you can do is use one.. well...

In my opinion abstractions like LINQ are good when necessary. The problem is that they tend to be tested in small and controlled scenarios, and when you use them in large projects they tend to show up their limitations and inherent problems, those which are very tied to the way they are designed and cannot be avoided if you don't have the control of the internal layers they are based in, and for that you have sometimes to look a lot of documentation about how does it work internally, so it ends up being a neverending story. I think that if you instead use a simpler technology you have more control and you can also measure times and optimize the code which is causing problems.

I think that things based on simple and basic technologies tend to work marvels. I agree that you have to create a code base and to study a lot in order to cover a lot of technologies, but when you do this you are able to create more simple and robust things and in less time.

I know a lot of guys that spend all the day speaking about a lot of technologies they know, but when you put them in charge of a project they spend ages developing it, whereas if you put in charge a capable developer s/he would develop it in days.

I'd like to think that things in life happen because of a reason, I mean if you show any interest and respect about your work you will end up being a good worker, and knowing the basics and the internals (not spend all the day bragging about all the technologies you know) is a matter of showing interest and respect about your work.

LINQ and EF are both incredibly complicated, and the organizations may not want to have a lot of code to maintain using these super-abstraction layers. You may understand it, but does anyone else?

The Questioner is a contractor; that makes the statement in bold above extremely important. Maintenance and enhancement of whatever the contractor develops may be done by staff or other contractors. The employer has to take the long view. I've been facing this at work where, speccing out a new system we want to build, my CTO reminds me that, to a certain extent, he needs to be able to get commodity labor to maintain and extend it.

The apprehension toward technologies viewed as "new" may reflect a business constraint with regard to the skill level of commodity programmers the company generally relies on.

One thing that is very important is to use the technologies that work for the company, that the company has chosen.

I used to work for a place where the devs would pick up on every cool new tech that came out - and now, they have a codebase that is full of every kind of obsolete and incompatible code - some bits are exported as COM+, some ATL, some VB, some .NET 1.1, some .NET 4, a bit of java in the corner, some HTML in there, some bits of GUI are old WPF, others are VB, others are MFC with some SGML and at least 1 Silverlight project around. The DB access is mostly OLEDB, but there's a fair bit of ADO, ADO.net, some ODBC, some RDO and DAO. Basically it s mess of unmaintainable code.

I'm sure someone is right now saying they need to refactor a load of the old stuff into the very latest cool new technology... and adding even more crap to it.

This is one reason not to go with any abstraction layer that comes along. Its much nicer to work on a clean codebase, not one polluted with yesterday's fad, even if that means you don't get to work on today's latest hyped-up fashion.