I opened this up because I saw the title and thought, "hmm that's strange, isn't string just an alias for String"? I'm pretty sure every C# dev I know would say the same. Then again if I was asked a trick question like this in an interview I might scratch around for some/any difference I could think of!
It's one of those things that after a few years you look at and wonder why there's string and String, int and Int32, you google it, you find out it's simply an alias.
I have been working in C# for 2 weeks, and Googled this last week. I think it's kinda the difference between being interested in making things work, and understanding how the language works.
It is also that moment of self doubt. You assume there "must" be a difference since the interviewer implied there is, so in order to contradict the interviewer (or call them "wrong") you have to be 100% sure.
I'm sure many people would prefer to get the wrong answer in interview than imply the interviewer's premise is wrong. That's why trick questions are dumb in interviews, they ignore the power dynamics in play and how someone will be judged if they seemingly "fight the interview process" (by calling the question(s) flawed).
In normal conversation I'd likely call it an alias (without 100% certainty) but in an interview I'd prefer to be wrong than to imply the interviewer's question is flawed.
TL;DR: All the blogger proves is that they're a bad interviewer, not that they're interviewing bad programmers.
This a great weeder question. Asking questions like this are often signs that:
(A) The interviewer doesn't know how to interview since they are wasting time asking questions that tell them very little about the candidate.
(B) The interviewer might be the type of interviewer who likes "trick" questions which can be a sign of someone who more interested in proving that they know something the interviewee doesn't.
Remember, the candidate is interviewing you/your company.
It's just an alias, but the way I use it is different. When declaring variable I opt for `string` but of course you should probably user `var`. But when calling method bound to the class, I would use `String`, i.e `String.format()`, etc
I don't see the point of this as an interview question unless the context includes the interviewee with their internet connected device in hand and obvious encouragement to find the right answer rather than recall it from memory.
It's particularly bad because there is no important fact to remember and imagination will fill in. An interview is high stress. What is valuable is the ability to Google under stress and the question and context will tend not to measure it.
Definitely has an air of trick-questionness about it (which I'm not a big fan of) - I think that it could be better rephrased as either:
"When would you use string as opposed to String?" or "Why do you think that the corelib int Convert.ToInt32(double value) method has this name and return type?"
These are more open; allow the candidate to explain that there's little practical difference between string and System.String; that it comes down to coding style; that there are aliases for int to System.Int32, which are probably VC++ showing through a bit (both the fixed size integer types and the underlying problem that made them necessary/useful); that it helps non-.NET consumers know what "int" means etc etc.
IMO it's still not a great interview question though (once you verify that the developer knows the basics) - I think that a lot of devs wouldn't know the ins and outs of this, simply because they'll hardly ever need to appreciate the difference (ie put it in your coding standards that they need to use one and they can forget that the other exists almost entirely).
I like your way of phrasing the question, I think I'll start asking it that way, starting tomorrow: we're interviewing a chap for a mid-level dev position.
Like I said on the blog, I don't think it's a good question, I just keep asking it out of scientific curiosity, more than anything else.
If you come to C# with a Java background you may easily be fooled to think it is similar to int and Integer or boolean and Boolean in case you are not aware that .NET has a unified type system. And, by the way, I hate these aliases because they mess up the look of the code - not only the syntax highlighting color which is easy to change, but now there are lower and upper case type names. Soooo ugly!
Whilst it is a shitty idea for a question I'm not sure I could hire a .NET dev that didn't know this simple fact. Type aliases are common in many languages, not just .NET. Being unable to answer this question, or even make a correct guess at it (it's not exactly hard), suggests a larger problem with the candidate.
There is a lot of misinformation around this as well. I've had a developer tell me that the difference is that string is immutable while String is mutable- this person was otherwise a pretty savvy and productive developer. I wonder how many bugs are out there where he was expecting a mutable object...
Pretty terrible (but harmless) interview question. It reminds me of a pointless question I was asked once: name the 4 access modifiers in Java. That was the day I learned about "package-private".
Apart from knowing the language (c#, vb whatever) well, take a look at the underlying framework. Newcomers omit that part most of the time. Might help with lots of decisions.
- The importance of .Net framework for your program. What happens when you double click on a .Net exe? What happens at the start of a web application? Is the framework is always there or started per app?
- Spend some time with ildasm. Learn what a manifest is. What is it good for. What is Intermediate Language (IL)?
- Difference between reference and value types. Heap and stack.
- What is garbage collection? How the garbage collector is working? IDisposable pattern.
- Why generic classes are important? What was there before them?
- Static vs. instance method calls.
- Passing object references around and keeping a reference (hence preventing GC, especially important for Desktop apps with improper use of events and references)
- For desktop devs: UI thread, background threads, patterns to pass data between these two.
- Basic OO. Virtual methods, overrides, new keyword, interfaces.