C# Interview Question

[rbDeveloper]

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]

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]

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]

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.Range(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.

 

[news.broadpark.no]

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]]

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 [C# MVP]]

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.

 

[Rudy Velthuis]

* 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>

 

[.\\\\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!

 

[Arne Vajhøj]

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 would not.

It is a fundamental requirement for a programmer to be able to
go from a problem to an algorithm that solves the problem.

Not all problems will be googlable, so the ability to use
Google is insufficient.

The interviewee must be able to come up with *a* solution.

Nothing wrong in searching Google to see if there are a better
solution out there.

I don't expect an in-depth mathematical
analysis unless the candidate is interviewing for, say, the NSA...

The described problem does not require high math skills to solve
just some basic logic.

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.

That I agree with.

Memorizing API's are not that useful.

Arne

 

[Arne Vajhøj]

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.

You are not the only one with that kind of experience.

And it does cost money to get people in and kick them out again.

Because there are a small but still significant number of bullshitters
around, then I think it is fair to check the people a bit.

BTW, check out http://thedailywtf.com/Articles/SkillsEquals(null).aspx !

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.

Developers that realize that there are so much they do not know have
huge potential for getting better.

Developers that think they know everything will never learn anything
and are likely useless and will certainly become useless after some
time.

I also hate those psychological profile tests

Yep. They are completely misplaced for all real developer jobs.

I can understand that they use them for manager, project manager
and other jobs where people skills are important.

But compilers are not effected by developers personality.

And you do not need a psychological profile test to spot those
that will not fit into a team.

Arne

 

[Arved Sandstrom]

I would not.

It is a fundamental requirement for a programmer to be able to
go from a problem to an algorithm that solves the problem.

Not all problems will be googlable, so the ability to use
Google is insufficient.

The interviewee must be able to come up with *a* solution.

Nothing wrong in searching Google to see if there are a better
solution out there.

I may not have expressed myself well. What I meant was, the stated problem
is amenable to using functions/library routines, that implement basic PRNGs,
that are available in many (if not most) programming languages. I consider
it reasonable for a programmer not to recall exactly what the
functions/routines are for language X, and therefore to do some research to
find out what they are. By Google I also mean searching APIs and flipping
through books.

I also believe that an interviewee should be able to come up with *a*
solution. Sometimes that solution is, "I don't know how to do it right now,
I'll research the problem and find out". Something that working programmers
do all the time.

The described problem does not require high math skills to solve
just some basic logic.

Not if the interviewee is allowed to use library functions provided by the
language in question, no. I wouldn't expect your average programmer to write
a PRNG from scratch. We may be talking at cross-purposes here - I'm guessing
you also do not expect a typical programmer to remember the integer
constants for an effective linear congruential generator, say.

That I agree with.

Memorizing API's are not that useful.

Always subject to caveats. There's obviously a subset that you do expect
people to know, another subset that they are aware exists and can locate
very rapidly, and then the other 90%+ that they should be able to search
effectively.

 

[rbDeveloper]

Thanks all!

 

[Arne Vajhøj]

I may not have expressed myself well. What I meant was, the stated problem
is amenable to using functions/library routines, that implement basic PRNGs,
that are available in many (if not most) programming languages. I consider
it reasonable for a programmer not to recall exactly what the
functions/routines are for language X, and therefore to do some research to
find out what they are. By Google I also mean searching APIs and flipping
through books.

I also believe that an interviewee should be able to come up with *a*
solution. Sometimes that solution is, "I don't know how to do it right now,
I'll research the problem and find out". Something that working programmers
do all the time.


Not if the interviewee is allowed to use library functions provided by the
language in question, no. I wouldn't expect your average programmer to write
a PRNG from scratch. We may be talking at cross-purposes here - I'm guessing
you also do not expect a typical programmer to remember the integer
constants for an effective linear congruential generator, say.

I think part of the reason we have a different angle is that you seem to
consider the RNG part the essential part while I consider the "pick
without duplicates" to be the essential part.

Arne

 

[parez]

You are not the only one with that kind of experience.

And it does cost money to get people in and kick them out again.

Because there are a small but still significant number of bullshitters
around, then I think it is fair to check the people a bit.

BTW, check outhttp://thedailywtf.com/Articles/SkillsEquals(null).aspx!

That was funny.. fortunately for me, I havent' met the darren type..

Developers that realize that there are so much they do not know have
huge potential for getting better.

Developers that think they know everything will never learn anything
and are likely useless and will certainly become useless after some
time.


Yep. They are completely misplaced for all real developer jobs.

I can understand that they use them for manager, project manager
and other jobs where people skills are important.

But compilers are not effected by developers personality.

True. But other people/developer are. I think this is more useful in
smaller companies where I think the interaction between developers is
more than what it would be in bigger companies.

And you do not need a psychological profile test to spot those
that will not fit into a team.

Yea.If it is obvious.

 

[Arved Sandstrom]

Arved Sandstrom wrote: [ SNIP ]

Not if the interviewee is allowed to use library functions provided by
the language in question, no. I wouldn't expect your average programmer
to write a PRNG from scratch. We may be talking at cross-purposes here -
I'm guessing you also do not expect a typical programmer to remember the
integer constants for an effective linear congruential generator, say.

I think part of the reason we have a different angle is that you seem to
consider the RNG part the essential part while I consider the "pick
without duplicates" to be the essential part.

Arne

That's true. Or to be more precise, I see this as two independent tests. In
the first, the programmer exhibits some reasonable knowledge of random
numbers, and is able to find/choose a reasonable solution in this respect.

Second, the programmer picks without duplicates - your emphasis. After
stumbling across this
(http://www.programmersheaven.com/mb/Algorithms/101722/101722/ReadMessage.aspx),
which contains the statement "My problem is that when I am picking a set of
6 numbers I am wracking my brains to find a way to make it pick only 6
unique numbers...", I'll concede that maybe not everyone is going to see
this as straightforward.

AHS