If I would have to guess:

1. Some programmers lack diverse language exposure. It’s hard to see things wrong with the language when you don’t know that better things exist.

2. Some programmers are mere code monkeys. They barely analyze the problems in front of them, let alone something like how their programming language could be better.

3. Few people are particularly critical. They see benefits and features, not shortcomings. It is hard for them to shift into that mode of thinking if the interview isn’t going that way.

4. At least around here, being overly critical is seen as a fatal personality flaw. Instead of being ‘that insightful developer that is always looking for better ways of doing things’ (like some areas I’ve lived), they are ‘that asshole that hates everything’. Even people who can think of things they hate in the language might defer in an interview setting to seem less acerbic.

I would imagine that the question is so hard to answer during an interview because it’s:

1. Really unexpected,

2. Requires a lot of thinking, and a thinking in a very different way from the one used during an interview,

3. Is hard to answer in general in a short amount of time (unless prepared before the interview).

1. It’s unexpected

Unexpected questions are truly hard, especially in a stressful context. Imagine the following dialog during an interview:

‒ What’s the difference between HashSet<T> and List<T>?
‒ The hashset is optimized in a way that the search for an element is very fast. For example if you’re using set.Contains() within a loop lots of times, moving the set from list to hashset may make things faster.
‒ How do you create a read only property?
‒ I use a field marked as readonly as a backing field for a property which has only a getter.
‒ What is the usage of sealed?
‒ You use it for classes which must not be inherited.
‒ What’s the last time you’ve seen a dentist?
‒ What?!

2. It requires a lot of different thinking

When you’re asked general interview-type questions, you’re using your memory to recall what you’ve learnt from books or from your practice about the language and the framework. You may think a bit in order to find an answer, but not too much.

On the other hand, the question about the five things you hate requires a deeper thinking. You can’t just recall something you’ve learnt from books, and you can’t find anything by analogy. Instead of being passive, you have to be critic and find what could be unpleasant in the language you use.

3. It requires time

Frankly, I have my list of five (actually more) things I hate about C#, but I thought about it over a long period of time. A few things are from the .NET Framework 2 era; most issues I listed for .NET Framework 2 are no longer valid because they were removed, some with LINQ and all this functional programming stuff, others with dynamic programming. I’m not sure if, without preparing this question, I would be able to find all the five elements during an interview.

I think it’s difficult because of the word five. And to a lesser degree, because of the word hate.

Five? What if you only come up with four? Have you failed to answer the question? What if you have more than five? Now, on the spot, you have to figure out which of those are the best five to use.

Hate is a very negative word. It’s the kind of negativity that people are told to avoid in interviews. Moreover, I think it would sound odd to a lot of people to have that many things they “hate” about a language they’ll be spending all day programming in. Some people might even think it’s a trick question: If they actually do come up with five things, they’ll be disqualified for hating C# too much to program well in. Unfortunately, this kind of perverse trick question is not unheard of in interviews.

Instead, you could ask What would you improve about C# if it were up to you? This allows the interviewee to answer with any number of things. This phrasing also trades the negativity of the word “hate” for the relatively positive “improve.”

• Most candidates aren’t that deeply involved with more than one language or paradigm in order to contrast. I haven’t worked with another object-oriented language for over 5 years now, and the one I had been working in (PowerBuilder), I had a lot of peeves with. Most guys fresh out of college are (or think they are) hot stuff at one, maybe two languages, and have received “exposure” to three or four more (meaning they completed at least one homework assignment requiring it but less than a full semester course studying it). That’s not enough knowledge or experience to really know what’s wrong with the language. Get a job in the real world, and that focus narrows considerably; you learn a lot more about the language that gets you the paycheck than any other, and in the process, you come to accept what the language won’t do, or does in a weird way, to the point where you couldn’t remember doing it differently.

• Most C#-savvy candidates who compare it to Java/C/C++ are pretty happy with it. C# was designed from the ground up to do a lot of things better than Java (events, callbacks, the graphics library, database work). Java in turn was designed to be easier to use, and so more focused on correct code, than C++. I’ve yet to meet a C# programmer who wants to go back to C++ in any environment where blistering performance and near-circuit-level control aren’t critical necessities.

In other words, See-Sharpers have it pretty good, all things considered.

Here’s my list:

• Lambda statements not watchable/evaluatable. Calls to named methods can be plugged into VS’s QuickWatch. So can expressions. But lambdas? Nope (at least not in VS2010). Makes debugging Linq chains a real chore.

• Optional parameter values for reference types other than string can only be null. if I were creating an overload stack, I might want to use other defaults. I might be able to default one value based on a property or simple expression based on another parameter. But I can’t. So the value of not having to create an overload stack (which is minor with a refactoring assistant like ReSharper to handle the boilerplate) is diminished when the options for the optional parameters are so drastically limited.

• C# is becoming old enough to have serious legacy code problems. Code originally written for 1.1 would cause anyone used to 4.0 to cringe in horror. Even 2.0 code misses out on a lot. In the same time, third-party libraries have come in that make things like ADO.NET seem woefully primitive (and much of ADO.NET’s “connected model” is now a big anti-pattern). Yet, for backwards-compatibility, .NET schleps along support for all this old, bad code, never daring to say something like “ArrayList was a crappy way to do it, we’re sorry we ever put it in and we’re taking it out; use List instead and if you absolutely need a list of varying types, declare it as List<Object>.

• Seriously limited switch statement rules. Probably one of the best things I could say about PowerBuilder is that the Choose Case statement (equivalent to switch) allowed Boolean expressions based on the variable. It also allowed switch statements to fall through even if they had code. I understand the reasons why that second one is disallowed (it’s more likely to be done unintentionally than on purpose) but it would still be nice from time to time to write a statement like:

  switch(someInt)
  {
      case < 0: //all negative values enter here
         //...
         break;
      case 0: 
         //...
         break;
      case 1:
         //...
         //no break; continue through to the code for > 1
      case > 1 // all positive values enter here (including 1)
         //...
         break;
  }
  

• No INumeric interface. If it’s a number, you can do math with it. In many cases the actual method doesn’t have to care about exactly which types are plugged in; precision is the caller’s responsibility. Yet it’s not possible to create a generic method or class that can only accept number types as the GTP.

I’d suggest that part of the problem is fear of giving a bad answer — you say you hate X, interviewer loves X or thinks your reason for hating X is idiotic, saying that you think it’s fine may seem the less controversial option.

It’s also probably something that most people haven’t really given a lot of thought about; they have current problems and past problems, past problems that were caused by the langauge are over with and so people mainly think of the solution and not the problem as that was more significant, and few will have a current problem caused by the language.

For an interview I would ask for only 1 or 2, but I agree, if you can’t name any limitations of the tool you use, then you probably don’t know it very well. We ask this exact question about SSIS and it really helps separate the wheat from the chaff; everyone we have hired who answered this question well turned into a great employee. We need people who have actaul advanced knowledge not someone who has looked at it a couple of times. And I’ll bet that is what you want too.

I think it is a valid question and the fact that so many couldn’t answer it is just an example of how poor many of the candidates for jobs really are. If someone isn’t analytical enough to be able to figure out some limtitations of the tool, how are they ever going to be analytical enought to solve difficult programming problems?

It comes down to like you said lack of in depth experience with C# and/or lack of exposure to other languages. I’ve interviewed a number of developers who considered themselves senior who couldn’t answer some questions that even a light scratch at the surface of C# should have revealed to them.

Without enough digging, you’re not going to reach the limits of the language and wish that they were gone. My top five in case anyone’s wondering

1. Immutable objects require a lot of ceremony to create (as opposed to a functional language where objects are immutable by default).
2. Metaprogramming is difficult to do. Compare type emit to Lisp macros. (Compiler Services will help a lot with this going forward).
3. Extension methods are great…extension properties and extension operators (specifically implicit and explicit operators) would be better.
4. Explicit Casts are resolved at compile time instead of run-time.
5. No Sequence Matching it’s so much cleaner than function overloading.

I think in his round about way he’s saying; if you think it is broken you probably don’t understand why it is as it is. There may be a hole in your knowledge.

Ironically, interviewers who think they are quoting “the great Joel” by using that as an interview question are probably rather missing the point.

They might be reluctant to answer because they might be under the impression that if they can list 5 things they hate about a language the interviewer might turn round and say ‘Oh, we’re looking for C# ‘ninjas’ and you don’t seem to like the language’, or ‘Why did you apply for the job if you don’t like the language?’.

Interviewees are under a lot of pressure to remain positive during interviews.

Because languages shape the way we think. By using C# everyday, you have taken the habit of thinking and designing your code in a way that naturally works around the problems of the language.

You now do it without thinking, without even knowing that you do it. This is why it is so difficult to point out what the bad things are. No doubt that the day when you started learning C#, you found a lot of issues, but now you don’t see them anymore. Habits are powerful things. Thought habits, even more.

The positive side of this is, if you find it difficult to list the flaws in C#, it must be because you are a good C# programmer, you like the language, and use it more than other languages.

But if you want to become more able to see the flaws in C#, you have to change your way of thinking. Learn more programming languages, and become used to them. Aim for the most different possible languages. You are used to static typing? Try Python or Ruby. You are used to object-oriented and imperative? Haskell is another world entirely.

And when you come back to C#, you will be like, “Why do I need one hundred lines of C# to do this simple thing that’s just one line in Haskell?”. You will hate a lot of things about C#.

• C# does not have non-nullable reference types.
• No algebraic data types.
• No string interpolation.
• Syntax is overly verbose everywhere.
• No macro system.
• Type inference is limited.
• No regexp literals.
• No structural typing.
• Poor support for immutability.
• C# structs are error-prone.
• Standard collections library is very limited.
• Can’t define constraints on parameters of constructors.
• Can’t program generically with constraints on math operators.
• No ‘newtype’.
• No array slicing, no range literal.
• Functions do not list the side-effects they can do as part of their type. 🙂

(Of course no language can have everything. Language design is extremely difficult, and adding every feature into the same language cannot work. Different tools for different purposes.)

Yes, the question is difficult to answer well, especially during an interview. But people that can answer it prove that they have thought about it, that they have some perspective.