String vs. string in C#
manyrootsofallevilrants.blogspot.com
manyrootsofallevilrants.blogspot.com
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.
So he's probably only interviewed juniors.
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.
(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.
Direct link to Skeet's answer: http://stackoverflow.com/a/215422
I just stick with `string` everywhere.
I find there is some kind of "logic" to this idea :D
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.
"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.
:-)
- 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.
- Why strings are immutable?
etc.