C# Interview Question

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

Hope this isn't too far off subject...

The following was recently proposed (not by me) as a question for
prospective job candidates. "Review the method below and say what gets
returned." Apparently, this came straight off some website for "C# Interview
Questions." The answer they gave is "tryfinally ". The reality, this won't
even compile because you can't return from a finally block. Personally, I
wouldn't put a return anywhere inside a try/catch/finally block just for
readability reasons.

I'm curious, are people finding such contrived questions on interviews?

Thanks,
Randy
static private string test1()
{
string s = string.Empty;
try
{
s += "try";
return s;
}
catch
{
s += "catch";
}
finally
{
s += "finally";
return s;
}
return s;
}

[Author]

On Jun 19, 1:21*pm, rbDeveloper
<rbDevelo...@di scussions.micro soft.comwrote:

Hope this isn't too far off subject...

The following was recently proposed (not by me) as a question for
prospective job candidates. "Review the method below and say what gets
returned." Apparently, this came straight off some website for "C# Interview
Questions." The answer they gave is "tryfinally ". The reality, this won't
even compile because you can't return from a finally block. Personally, I
wouldn't put a return anywhere inside a try/catch/finally block just for
readability reasons.

I'm curious, are people finding such contrived questions on interviews?

Thanks,
Randy

static private string test1()
{
* * string s = string.Empty;
* * try
* * {
* * * * s += "try";
* * * * return s;
* * }
* * catch
* * {
* * * * s += "catch";
* * }
* * finally
* * {
* * * * s += "finally";
* * * * return s;
* * }
* * return s;

}

The purpose of this example was to test if the candidate knows that
the finally block is always executed. But like you said, it won't
even compile and even if it compiles, it is still a bad example for
this testing purpose.

[Peter Morris]

I was asked to write a small program that chose 6 random non-repeating
numbers between 1..48 (lottery example). I found it very difficult. Not
because the logic was hard, but because they gave me a pen and paper and I
hadn't held a pen in about 5 years :-)
--
Pete
=============== =============== ===========
I use Enterprise Core Objects (Domain driven design)
http://www.capableobjects.com/
=============== =============== ===========

[Arved Sandstrom]

"Peter Morris" <mrpmorris at gmail dot comwrote in message
news:e0******** ******@TK2MSFTN GP04.phx.gbl...

>I was asked to write a small program that chose 6 random non-repeating
numbers between 1..48 (lottery example). I found it very difficult. Not
because the logic was hard, but because they gave me a pen and paper and I
hadn't held a pen in about 5 years :-)

If an interviewee responded to a question like that by saying that he or she
would do a Google search using keywords like "C# random number range" (which
approach would lead them to using System.Random in about 15 seconds), and
used one of about a dozen half-elegant approaches (*) to ensuring that the
final result set is non-repeating (i.e. not expecting the PRNG to do that),
I'd pass 'em with flying colours. I don't expect an in-depth mathematical
analysis unless the candidate is interviewing for, say, the NSA...

As long as someone demonstrates that they know the concepts, and can rapidly
locate the APIs and learn them, that's all I expect. For example, I don't
imagine I've had a serious use for random numbers more than maybe a
half-dozen times in over 25 years of coding, so I'm not about to retain the
random number generation APIs for every language I use.

AHS

* It would be a temptation to change the problem to selection of 1..N
non-repeating numbers in the range 1..N (e.g. 2 non-repeating values between
1..48 inclusive, or equally well 43 non-repeating numbers between 1..48
inclusive) and see how the interviewee adapts to this situation.

[Jeroen Mostert]

Peter Morris wrote:

I was asked to write a small program that chose 6 random non-repeating
numbers between 1..48 (lottery example). I found it very difficult. Not
because the logic was hard, but because they gave me a pen and paper and I
hadn't held a pen in about 5 years :-)

Reminds me of the old C++ exams in school. Everything had to be written down
to the last semicolon, and points would get deducted for the tiniest
syntactical slip-up. Unsurprisingly, scores were generally not high;
students were spoiled rotten by such things as full-screen editors and
compilers you could invoke with a single keypress.

Incidentally, your question is a two-liner in C# 3.0:

Random r = new Random();
var numbers = Enumerable.Rang e(1,48).OrderBy (i =r.Next()).Take (6);

It would be a one-liner in a proper functional programming language. :-)

Of course, the follow-up question might be to do the same trick for numbers
in between 1 and, say, int.MaxValue. This solution doesn't fare very well
for that case.

--
J.
http://symbolsprose.blogspot.com

[news.broadpark.no]

"Author" <gn********@gma il.comwrote in message
news:6c******** *************** ***********@w1g 2000prd.googleg roups.com...

>The purpose of this example was to test if the candidate knows that
the finally block is always executed. But like you said, it won't
even compile and even if it compiles, it is still a bad example for
this testing purpose.

It's a bit more complicated than that. The finally block is executed after
"s" has been pushed for return. Thus it would return "try" and not
"tryfinally ".

Eirik

[Jon Skeet [C# MVP]]

rbDeveloper <rb*********@di scussions.micro soft.comwrote:

Hope this isn't too far off subject...

The following was recently proposed (not by me) as a question for
prospective job candidates. "Review the method below and say what gets
returned." Apparently, this came straight off some website for "C# Interview
Questions." The answer they gave is "tryfinally ". The reality, this won't
even compile because you can't return from a finally block. Personally, I
wouldn't put a return anywhere inside a try/catch/finally block just for
readability reasons.

Well, you certainly can't do it from a finally, but there are plenty of
times when it makes sense to do it from try and catch. In particular,
"trying" to parse something and returning a default value if an
exception is thrown is relatively common in my experience - and I find
returning directly in each case to be more readable than the
alternatives.

I'm curious, are people finding such contrived questions on interviews?

My last interview was entirely about problem solving - great stuff.
Haven't come across little technical things like that, although I
*have* set people questions which tested more fundamental things (like
picking which types out of about 10 very common ones are value types).

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Jon Skeet [C# MVP]]

news.broadpark. no <et******@broad park.nowrote:

The purpose of this example was to test if the candidate knows that
the finally block is always executed. But like you said, it won't
even compile and even if it compiles, it is still a bad example for
this testing purpose.

It's a bit more complicated than that. The finally block is executed after
"s" has been pushed for return. Thus it would return "try" and not
"tryfinally ".

You're assuming semantics for an invalid situation though. The code
doesn't compile - that's the answer. If the rules were changed to allow
it to compile, the semantics could be chosen to return "try" or
"tryfinally ".

In Java, for example, the code *is* valid (except for the unreachable
return at the end of the method) and "tryfinally " is returned. If C#
allowed returning from a finally block there's no reason the same
semantics couldn't be chosen.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Rudy Velthuis]

Arved Sandstrom wrote:

* It would be a temptation to change the problem to selection of 1..N
non-repeating numbers in the range 1..N (e.g. 2 non-repeating values
between 1..48 inclusive, or equally well 43 non-repeating numbers
between 1..48 inclusive) and see how the interviewee adapts to this
situation.

Simply create an array with the values 1..48 and shuffle it. Then it
doesn't matter what N is, as long as it is in range. <g>

--
Rudy Velthuis http://rvelthuis.de

"Marry me and I'll never look at another horse!"
-- Groucho Marx

[.\\\\axxx]

You'd think people responsible for interviews would at least actually
try out their examples to see if they compiled! Under pressure of
interview many (I guess) would assume that it compiled, and therefore
come up with the (incorrect) answer of try..finally.

I personally detest any tech questions at interview. When interviewing
I always explain very carefully what the expectations are - the
candidate must be able to understand what their techincal abiolities
need to be. I also point out that they are on probation for a period,
and that I will check up on them, and I will 'let them go' if they
appear to have exaggerated their abilities.

I have ony ever had to let one person go - he went on from his
position of senior developer to be I.T. Manager elsewhere - surprising
when you think he couldn't figure out th problem in code he had
written where he had used the letter 'O' instead of a zero, in about
six out of twenty statements. (he also brought in pirated development
software, developed in versions of the language we didn't yet support
etc. etc.

I _have_ had people subsequently call back and say that they didn't
think they had the skills required for the job on offer; in one case
we actualy took on the applicant as a trainee - and she turned out to
be a great asset.

I also hate those psychological profile tests - I did one once,
immediately after a two hour interview, and was so p*ssed off at this
being sprung on me that I randomly selected the answers, completing it
in three minutes instead of the allowed hour. I got the job!