c# interview question

[=?Utf-8?B?U3RldmUgQnVnZGVu?=]

Hi,

I recently had an interview where I was asked a number of questions on C#.
Unfortunately I didn't get the answers from the test and find that one of
them is still niggling me.

It was something like this:

Consider the following code:

int i = 0;
Console.WriteLi ne("The value is: " + i);
Console.WriteLi ne("The value is: " + i.ToString());

Which would you use to write an integer to the console and why would it give
better performance?

I said I would use: Console.WriteLi ne("The value is: " +
i.ToString());

But I can't think why this should give a performance advantage. I can only
guess that the compiler should be able to realise that a string is required
from the integer for the line not using the ToString() method and generate
the same MSIL.

Can anyone please enlighten me?

Best Regards,

Steve

[Mark Rae]

"Steve Bugden" <St*********@di scussions.micro soft.comwrote in message
news:88******** *************** ***********@mic rosoft.com...

I didn't get the job by the way. I narrowly missed out by a few percent on
the passmark and this question is one that cost me.

Perhaps you can take comfort in the fact that you probably wouldn't want to
work for a company like that anyway... I know I certainly wouldn't!

[DeveloperX]

On 12 Mar, 10:13, "Mark Rae" <m...@markNOSPA Mrae.comwrote:

"Peter Bradley" <pbrad...@uwic. ac.ukwrote in message

news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

One thing's for sure, if you (or rather your prospective employers) need
to worry about performance at this level, then they're using the wrong
language.

I couldn't agree more!!! What an utterly pointless and irrelevant
question...

Having been on both sides of the interview process many times over the
years, if you want to find out whether the prospective candidate is a good
developer or not, the most useful question is "Tell me about your last
development project"... You'll know in probably less than a minute if you
want to hire the person or not...

I don't know, I think there's something to be said for making sure a
candidate could/would take a stab at answering it. I imagine the
interviewer was less interested in the performance, but more
interested in showing the candidate understood boxing and overloaded
methods.
More importantly (hopefully) they were testing to see how the
candidate responds to a question they don't immediately know the
answer to. I mean if you just say "No idea" I probably wouldn't be too
impressed. In the first instance I'd like to see the developer show
some of that problem solving ability we're supposed to be known for.
If they at least had a stab at it, asked questions, even if they
didn't get there in the end I'd still respect the fact they tried.
Further if the candidate didn't get to the answer I'd take the time to
explain the answer and then see if they absorbed that information.
After all most programming questions can be answered with a quick
Google these days, it's whether they could take what they found on
Google, comprehend it and turn it into a solution.
I'd also say I would take a different approach to interviewing at
different levels. A junior candidate would be about potential, a
senior candidate about delivery and the questions would vary for both.

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Mike Schilling wrote:

"Steve Bugden" <St*********@di scussions.micro soft.comwrote in message
news:60******** *************** ***********@mic rosoft.com...

>Hi,

I recently had an interview where I was asked a number of questions on C#.
Unfortunatel y I didn't get the answers from the test and find that one of
them is still niggling me.

It was something like this:

Consider the following code:

int i = 0;
Console.WriteLi ne("The value is: " + i);
Console.WriteLi ne("The value is: " + i.ToString());

Which would you use to write an integer to the console and why would it
give
better performance?

By definition, they mean exactly the same thing, so it doesn't matter which
one you use.

No, they don't mean the same thing. The result is the same, but that is
something completely different.

(If it were possible for "i" to be null, the first one would
be better, since it could never cause a null reference exception, but a
value type can't be null.) The analyses in other posts in the thread aren't
about the difference between these two statements, they're about what IL a
particular version of the compiler happens to generate.

Analysing the IL code is a way to find out how the compiler interprets
the code. It reveals that the code is equivalent to:

int i = 0;
Console.WriteLi ne(string.Conca t((object)"The value is: ", (object)i));
Console.WriteLi ne(string.Conca t("The value is: ", i.ToString()));

If these people
expect you to know that off the top of your head, they're idiots. Likewise,
if these people think that the difference between the two sets of generated
IL cause any measurable difference in performance, they're idiots.

Knowing how the compiler interprets the code is important in order to
avoid things like unintended conversions and boxing.

It's true that this example will not give a measurable difference in
performance, but the code demonstrates a difference in performance that
would be measurable in other situations. If you box a value type once,
it doesn't make a noticable difference, but if you do it in a loop that
runs a million iterations, there will be a difference.

The question is not intended to find out how you would optimise the
given code, as that code is in no need of optimising, but it's intended
to find out if you are aware of what the code is doing, and if you would
know how to optimise it in a situation where it would be needed.

>

>I said I would use: Console.WriteLi ne("The value is: " +
i.ToString() );

But I can't think why this should give a performance advantage. I can only
guess that the compiler should be able to realise that a string is
required
from the integer for the line not using the ToString() method and generate
the same MSIL.

Can anyone please enlighten me?

Best Regards,

Steve

--
Göran Andersson
_____
http://www.guffa.com

[=?Utf-8?B?U3RldmUgQnVnZGVu?=]

Hi,

From the previous reply:

>If these people
expect you to know that off the top of your head, they're idiots. Likewise,
if these people think that the difference between the two sets of generated
IL cause any measurable difference in performance, they're idiots.

I didn't get the job but I do feel a lot better now :-)

Thanks to everyone for the interesting answers.

Best Regards,

Steve.

"Mike Schilling" wrote:

>
"Steve Bugden" <St*********@di scussions.micro soft.comwrote in message
news:60******** *************** ***********@mic rosoft.com...

Hi,

I recently had an interview where I was asked a number of questions on C#.
Unfortunately I didn't get the answers from the test and find that one of
them is still niggling me.

It was something like this:

Consider the following code:

int i = 0;
Console.WriteLi ne("The value is: " + i);
Console.WriteLi ne("The value is: " + i.ToString());

Which would you use to write an integer to the console and why would it
give
better performance?

By definition, they mean exactly the same thing, so it doesn't matter which
one you use. (If it were possible for "i" to be null, the first one would
be better, since it could never cause a null reference exception, but a
value type can't be null.) The analyses in other posts in the thread aren't
about the difference between these two statements, they're about what IL a
particular version of the compiler happens to generate. If these people
expect you to know that off the top of your head, they're idiots. Likewise,
if these people think that the difference between the two sets of generated
IL cause any measurable difference in performance, they're idiots.

I said I would use: Console.WriteLi ne("The value is: " +
i.ToString());

But I can't think why this should give a performance advantage. I can only
guess that the compiler should be able to realise that a string is
required
from the integer for the line not using the ToString() method and generate
the same MSIL.

Can anyone please enlighten me?

Best Regards,

Steve

[DeveloperX]

On 12 Mar, 10:45, "Mike Schilling" <a...@newsgroup .nospamwrote:

"Steve Bugden" <SteveBug...@di scussions.micro soft.comwrote in message

news:60******** *************** ***********@mic rosoft.com...

Hi,

I recently had an interview where I was asked a number of questions on C#.
Unfortunately I didn't get the answers from the test and find that one of
them is still niggling me.

It was something like this:

Consider the following code:

int i = 0;
Console.WriteLi ne("The value is: " + i);
Console.WriteLi ne("The value is: " + i.ToString());

Which would you use to write an integer to the console and why would it
give
better performance?

By definition, they mean exactly the same thing, so it doesn't matter which
one you use. (If it were possible for "i" to be null, the first one would
be better, since it could never cause a null reference exception, but a
value type can't be null.) The analyses in other posts in the thread aren't
about the difference between these two statements, they're about what IL a
particular version of the compiler happens to generate. If these people
expect you to know that off the top of your head, they're idiots. Likewise,
if these people think that the difference between the two sets of generated
IL cause any measurable difference in performance, they're idiots.

I said I would use: Console.WriteLi ne("The value is: " +
i.ToString());

But I can't think why this should give a performance advantage. I can only
guess that the compiler should be able to realise that a string is
required
from the integer for the line not using the ToString() method and generate
the same MSIL.

Can anyone please enlighten me?

Best Regards,

Steve- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Sorry but that just isn't true.
The IL shows perfectly the different behaviours of the two lines. The
first will box into an object, call Concat(object, object) which
internally will call Concat(string, string). The second only calls
Concat(string, string) Any internal compiler optimisations would have
to honour that behaviour. So the IL disassembly shows exactly what the
difference between the two lines of code are and would not be markedly
different regardless of whether you compiled it under VS or say Mono.
The OP wanted to know what the difference was based on his interview
and he got several good answers.

Regarding performance. One is more performant than the other. Running
the above example won't yield a noticable difference in speed, doing
so with a more complex example in a tight loop over millions of
iterations would. I don't see why you'd use the less performant, less
dotnet (read strongly typed is good) approach and I don't understand
this sort of backlash against trying to make your code run as quickly
and efficiently as possible. The method Go() at the end of this post
shows the second loop runs 5-10pc quicker than the first loop.

As for whether anyone should know that off the top of their head, I'd
expect them to know about boxing and what problems it can cause and
I'd expect them to be able to ask the right questions to get to the
answer even if they needed help to do so.

And good luck on future interviews Steve.

private static void Go()
{
int s1 = System.Environm ent.TickCount;
string s;
int c;
for(c=0;c<10000 000;c++)
{
s = "The value is:" + c;
s = string.Empty;
}
int s2 = System.Environm ent.TickCount;
for(c=0;c<10000 000;c++)
{
s = "The value is:" + c.ToString();
s = string.Empty;
}
int s3 = System.Environm ent.TickCount;
Console.WriteLi ne("{0}\n\r{1}\ n
\r{2}",s1.ToStr ing(),s2.ToStri ng(),s3.ToStrin g());
Console.ReadLin e();
}

[Jon Skeet [C# MVP]]

On Mar 12, 1:41 pm, "DeveloperX " <nntp...@operam ail.comwrote:

<snip>

Regarding performance. One is more performant than the other. Running
the above example won't yield a noticable difference in speed, doing
so with a more complex example in a tight loop over millions of
iterations would. I don't see why you'd use the less performant, less
dotnet (read strongly typed is good) approach and I don't understand
this sort of backlash against trying to make your code run as quickly
and efficiently as possible.

One word: readability. The most readable code often isn't quite the
most performant, but most of the time it doesn't matter. When offered
the choice between:

Console.WriteLi ne ("i="+i);
and
Console.WriteLi ne ("i="+i.ToStrin g());

I know which one I find more readable - the one with less fluff. Does
it perform less well? Slightly - in a way which isn't going to matter.
Is it less type-safe? No.

In short, I'd use the first version, even though it's slightly less
performant. In most cases, developer/maintainer time is much more
important than CPU time.

Jon

[Samuel R. Neff]

I would love it if every person I interviewed went into enough
technical detail to provide a basis for evaluation when talking about
their last project. However, I've found that more often then not it's
like pulling teeth to get technical details out of candidates (which
sometimes is reason enough to end the interview). Most of the time
people talk about the project and what it does and rarely offer up
technical details about what they did in the project or how the wrote
it or why they made the decisions they made.

I do have a list of trivia questions I bring to interviews for when I
need to I ask them, but I always prefer candiates that can talk well
enough about their jobs and theoretical projects that I don't have to
ask trivia. Usually if I drop to the trivia, it's just to confirm
that they're not worth hiring--or if I get someone that's really cocky
I ask them a particular question that nobody ever gets right (related
to boxing).

Sam
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.


On Mon, 12 Mar 2007 10:13:06 -0000, "Mark Rae"
<ma**@markNOSPA Mrae.comwrote:

>"Peter Bradley" <pb******@uwic. ac.ukwrote in message
news:%2******* *********@TK2MS FTNGP05.phx.gbl ...

>One thing's for sure, if you (or rather your prospective employers) need
to worry about performance at this level, then they're using the wrong
language.

I couldn't agree more!!! What an utterly pointless and irrelevant
question...

Having been on both sides of the interview process many times over the
years, if you want to find out whether the prospective candidate is a good
developer or not, the most useful question is "Tell me about your last
development project"... You'll know in probably less than a minute if you
want to hire the person or not...

[Laura T.]

There is a more subtle difference.
The boxed version needs to allocate an object that non boxed version does
not.
For example, in your Go, the first loop would allocate 10000000 "extra"
Int32 objects.
Sometimes this behavior can make a difference.

"DeveloperX " <nn*****@operam ail.comha scritto nel messaggio
news:11******** **************@ c51g2000cwc.goo glegroups.com.. .

On 12 Mar, 10:45, "Mike Schilling" <a...@newsgroup .nospamwrote:

>"Steve Bugden" <SteveBug...@di scussions.micro soft.comwrote in message

news:60******* *************** ************@mi crosoft.com...

Hi,

I recently had an interview where I was asked a number of questions on
C#.
Unfortunately I didn't get the answers from the test and find that one
of
them is still niggling me.

It was something like this:

Consider the following code:

int i = 0;
Console.WriteLi ne("The value is: " + i);
Console.WriteLi ne("The value is: " + i.ToString());

Which would you use to write an integer to the console and why would it
give
better performance?

By definition, they mean exactly the same thing, so it doesn't matter
which
one you use. (If it were possible for "i" to be null, the first one
would
be better, since it could never cause a null reference exception, but a
value type can't be null.) The analyses in other posts in the thread
aren't
about the difference between these two statements, they're about what IL
a
particular version of the compiler happens to generate. If these people
expect you to know that off the top of your head, they're idiots.
Likewise,
if these people think that the difference between the two sets of
generated
IL cause any measurable difference in performance, they're idiots.

I said I would use: Console.WriteLi ne("The value is: " +
i.ToString());

But I can't think why this should give a performance advantage. I can
only
guess that the compiler should be able to realise that a string is
required
from the integer for the line not using the ToString() method and
generate
the same MSIL.

Can anyone please enlighten me?

Best Regards,

Steve- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Sorry but that just isn't true.
The IL shows perfectly the different behaviours of the two lines. The
first will box into an object, call Concat(object, object) which
internally will call Concat(string, string). The second only calls
Concat(string, string) Any internal compiler optimisations would have
to honour that behaviour. So the IL disassembly shows exactly what the
difference between the two lines of code are and would not be markedly
different regardless of whether you compiled it under VS or say Mono.
The OP wanted to know what the difference was based on his interview
and he got several good answers.

Regarding performance. One is more performant than the other. Running
the above example won't yield a noticable difference in speed, doing
so with a more complex example in a tight loop over millions of
iterations would. I don't see why you'd use the less performant, less
dotnet (read strongly typed is good) approach and I don't understand
this sort of backlash against trying to make your code run as quickly
and efficiently as possible. The method Go() at the end of this post
shows the second loop runs 5-10pc quicker than the first loop.

As for whether anyone should know that off the top of their head, I'd
expect them to know about boxing and what problems it can cause and
I'd expect them to be able to ask the right questions to get to the
answer even if they needed help to do so.

And good luck on future interviews Steve.

private static void Go()
{
int s1 = System.Environm ent.TickCount;
string s;
int c;
for(c=0;c<10000 000;c++)
{
s = "The value is:" + c;
s = string.Empty;
}
int s2 = System.Environm ent.TickCount;
for(c=0;c<10000 000;c++)
{
s = "The value is:" + c.ToString();
s = string.Empty;
}
int s3 = System.Environm ent.TickCount;
Console.WriteLi ne("{0}\n\r{1}\ n
\r{2}",s1.ToStr ing(),s2.ToStri ng(),s3.ToStrin g());
Console.ReadLin e();
}

[DeveloperX]

On 12 Mar, 14:51, "Jon Skeet [C# MVP]" <[e-mail] wrote:

On Mar 12, 1:41 pm, "DeveloperX " <nntp...@operam ail.comwrote:

<snip>

Regarding performance. One is more performant than the other. Running
the above example won't yield a noticable difference in speed, doing
so with a more complex example in a tight loop over millions of
iterations would. I don't see why you'd use the less performant, less
dotnet (read strongly typed is good) approach and I don't understand
this sort of backlash against trying to make your code run as quickly
and efficiently as possible.

One word: readability. The most readable code often isn't quite the
most performant, but most of the time it doesn't matter. When offered
the choice between:

Console.WriteLi ne ("i="+i);
and
Console.WriteLi ne ("i="+i.ToStrin g());

I know which one I find more readable - the one with less fluff. Does
it perform less well? Slightly - in a way which isn't going to matter.
Is it less type-safe? No.

In short, I'd use the first version, even though it's slightly less
performant. In most cases, developer/maintainer time is much more
important than CPU time.

Jon

I agree it's type safe, but the former passes an int and a string as
object parameters and the latter two strings to string parameters.
Given the choice I'd rather use the most accurate signature available
for what I want to do, in this case concat two strings. Ok, string
concatenation probably isn't the best example as it's really simple
and I do take your point on readability. I personally think I prefer
the ToString version as it's obvious that I want the int's string
representation. Imagine this example:

int i=1;
int j=2;
Console.WriteLi ne("My value is: " + i + j);
Console.WriteLi ne("My value is: " + (i + j));
Console.WriteLi ne(i + j);

Suddenly I get
My value is: 12
My value is: 3
3

So if a developer simply removed the string literal the intention of
the line of code changes.

[Mike Schilling]

"DeveloperX " <nn*****@operam ail.comwrote in message
news:11******** **************@ c51g2000cwc.goo glegroups.com.. .

On 12 Mar, 10:45, "Mike Schilling" <a...@newsgroup .nospamwrote:

>"Steve Bugden" <SteveBug...@di scussions.micro soft.comwrote in message

news:60******* *************** ************@mi crosoft.com...

Hi,

I recently had an interview where I was asked a number of questions on
C#.
Unfortunately I didn't get the answers from the test and find that one
of
them is still niggling me.

It was something like this:

Consider the following code:

int i = 0;
Console.WriteLi ne("The value is: " + i);
Console.WriteLi ne("The value is: " + i.ToString());

Which would you use to write an integer to the console and why would it
give
better performance?

By definition, they mean exactly the same thing, so it doesn't matter
which
one you use. (If it were possible for "i" to be null, the first one
would
be better, since it could never cause a null reference exception, but a
value type can't be null.) The analyses in other posts in the thread
aren't
about the difference between these two statements, they're about what IL
a
particular version of the compiler happens to generate. If these people
expect you to know that off the top of your head, they're idiots.
Likewise,
if these people think that the difference between the two sets of
generated
IL cause any measurable difference in performance, they're idiots.

I said I would use: Console.WriteLi ne("The value is: " +
i.ToString());

But I can't think why this should give a performance advantage. I can
only
guess that the compiler should be able to realise that a string is
required
from the integer for the line not using the ToString() method and
generate
the same MSIL.

Can anyone please enlighten me?

Best Regards,

Steve- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Sorry but that just isn't true.
The IL shows perfectly the different behaviours of the two lines. The
first will box into an object, call Concat(object, object) which
internally will call Concat(string, string). The second only calls
Concat(string, string) Any internal compiler optimisations would have
to honour that behaviour.

Why, when they result in identical behavior? C# is a high-level language,
not assembler.

So the IL disassembly shows exactly what the

difference between the two lines of code are and would not be markedly
different regardless of whether you compiled it under VS or say Mono.
The OP wanted to know what the difference was based on his interview
and he got several good answers.

Regarding performance. One is more performant than the other. Running
the above example won't yield a noticable difference in speed, doing
so with a more complex example in a tight loop over millions of
iterations would.

Can you demonstrate that? Seriously, build a test and tell us the results.