infinite?

Infinitely, because the use of "x--" returns the value of x before decrementing x (locally), and hence nextLevel( n ) always returns the original value of n?

Shame this took so long to crack - should have got this straight off from my C++ days.

--x should do the trick.

x--

It will be an infinite loop !

Unless you define nextLevel this way :

Func<int, int> nextLevel = new Func<int, int>(x => --x);

nextLevel will always return level...

infinite... should be --x instead of x--

Infinite. If you change the nextLevel func to Func <int,> nextLevel = new Func <int,> (x => --x);

        var x = 10;


        x = x++;


        Console.WriteLine(x);

what will be printed ? ;)

weblogs.asp.net/.../...2B002B00-and-C2300.aspx

I expect that lambda bodies, like bodies of other methods, use copies of the arguments passed in (copies of value-type arguments or of references, but not copies of objects), so running nextLevel(level) has no side effects outside of itself--i.e., it decrements its local copy of level (x), not level itself. So Rafal is right.

Whoops! Didn't see that level is set to what the lambda expression evaluates to.

Ditto what others said about --x vs. x--.

x => x-1 would also work. It's the return value that matters, not the decrement.

Resharper actually identifies it as a redundant decrement...

I don't think it would make a good interview question. Good interview questions aren't about catching people out. A good developer might be caught out by some code, but would have unit tests that aren't.

I think this is a classic case of unreadable code dressed up as clever code. What's the point?

@Jonty

IMO the reason this is a good interview question is when you hire a new person, you are going to have them maintaining a bunch of code that they didn't write, and that there is a good chance that they would "have done it differently". That's how this works. So, when the developer is confronted with code that they aren't familiar with, how do they work through the code, and figure out what it does. Do they have critical thinking, and reasoning skills. They don't have to get it right, the goal isn't to see if they get it right, but rather to watch how they reason, and talk through it.

Obviously a unit test, or the debugger could get the answer, and it's good to use tools to solve the problems efficiently, but as developers, we are problem solvers, and you want to exercise those skills in an interview as well as the candidates technical skills.

Horrible interview question...

Its the kind of thing that will catch 90% of developers out there on the spot, but 90% of the people who got caught would find it within 1 minute with a debugger running, if it came up at work in real life. Plus the whole x--, --x thing is left over from the C/C++ days it really serves no purpose in C# code compared to the much simpler x += 1 construct..

So it filters out people with something that is totally outside of real world usuage, that would easily be resolved in the real world, without testing their true understanding.

I agree that this is a bad question if it is strictly to see how good of a language lawyer the candidate is. However, I can see it being useful for watching how someone goes about solving a problem as Bryan pointed out.

Damn, my comment got flagged as spam :) I just wanted to say: this is how Ayende will stop being Ayende eventually. By embarrassing himself to the point of not making his bold opinions public anymore.

I think the more appropriate interview question would be: This code causes an infinite loop. Why?

To me, ALL interview questions are valid. Whether or not they're GOOD questions has less to do with the question than with how the interviewer uses the answer. In this example, if the interviewer's simply trying to gauge level of factual knowledge, and you get a plus for right and a minus for wrong, then it's a bad question. On the other hand, if the interviewer is using the question to evaluate the developer's thinking processes, it's a perfectly valid question.

Now consider - if that's what the interviewer is doing, everyone who says "You're never going to see that in production code, so it's a terrible question, and you're just prejudicing the interview process against anyone who's never done C" is totally off-base: the candidate who's never done C is AT AN ADVANTAGE, because he gets to show off his thought processes, and the interviewer will be able to accurately evaluate the candidate's problem-solving process. A developer who's got the entire language down cold, though, will just spit out the answer, and will have to sit through another (and maybe another, and another) question before the interviewer can get the information he wants.

Don't discard questions out of hand because you THINK you know the way in which the interviewer is going to use them. Just because the question strikes you as contrived, artificial, or pointless, doesn't mean it really is - the interviewer may just be doing more than you give him credit for.

The purpose of interview questions is this: i want a view into how the candidate thinks and solves problems in a pressure situation.

In that vain, this question is useful from the perspective of how a candidate deals with things like pointless questions or a fool in a 'management' role. Does he/she stay composed?

As a candidate I respect problems like the counterfeit coin, anagrams, etc as they are implicitly respecting me in asking them. Questions like these throw the bozo bit on the employer and raises more red flags than it clears.

11 times ?

I would

Func <int,> nextLevel = new Func <int,> (x => x - 1);

and have no issues with increment/decrement precedence.

The purpose of interview questions is this: i want a view into how the candidate thinks and solves problems in a pressure situation.

In that vain, this question is useful from the perspective of how a candidate deals with things like pointless questions or a fool in a 'management' role. Does he/she stay composed?