Why the question “give five things you hate about C#” is so difficult to answer during an interview?

Question

In podcast 73, Joel Spolsky and Jeff Atwood discuss, among other subjects, "five things everyone should hate about their favorite programming language":

If you’re happy with your current tool chain, then there’s no reason you need to switch. However, if you can’t list five things you hate about your favorite programming language, then I argue you don’t know it well enough yet to judge. It’s good to be aware of the alternatives, and have a healthy critical eye for whatever it is you’re using.

Being curious, I asked this question to any candidate I interviewed. None of them were able to quote at least one thing they hate about C#¹.

Why? What's so difficult in this question? It is because of the stressful context of the interview that this question is impossible to answer by the interviewees?

Is there something about this question which makes it bad for an interview?

---

Obviously, it doesn't mean that C# is perfect. I have myself a list of five things I hate about C#:

• The lack of variable number of types in generics (similar to params for arguments).
  Action<T>,
  Action<T1, T2>,
  Action<T1, T2, T3>,
        ⁞
  Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>
  Seriously?!

• The lack of support for units of measure, like in F#.

• The lack of read only properties. Writing a backing private readonly field every time I want a read only property is boring.

• The lack of properties with default values. And yes, I know that I can initialize them in the parameterless constructor and call it from all other constructors. But I don't want to.

• Multiple inheritance. Yes, it causes confusion and you don't need it in most cases. It's still useful in some (very rare) cases, and the confusion applies as well (and was solved in C#) to the class which inherits several interfaces which contain methods with the same name.

I'm pretty sure that this list is far from being complete, and there are much more points to highlight, and especially much better ones than mine.

---

^{¹ A few people criticized some assemblies in .NET Framework or the lack of some libraries in the framework or criticized the CLR. This doesn't count, since the question was about the language itself, and while I could potentially accept an answer about something negative in the core of .NET Framework (for example something like the fact that there is no common interface for TryParse, so if you want to parse a string to several types, you have to repeat yourself for every type), an answer about JSON or WCF is completely off-topic.}

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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?

Answer 5

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

Five asks for no more, no less. 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, since precisely five are requested.

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. This kind of perverse trick question is not unheard of in interviews.

Instead, you could ask Are there any things you dislike about C#? or What would you improve about C# if it were up to you? Questions like this allow the interviewee to answer with any number of things. This phrasing also trades the negativity of the word "hate" for the less negative "dislike" or the relatively positive "improve."

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

This question is best asked over a beer rather than in interview session. Since it might start argument between interviewer and the interviewee. Which is the interviewee try hard to avoid.