C# interview question

[Gentile]

I see your difference engine & raise you one abacus.

I see your abacus, and call you with my Sieve of Eratosthenes.

[VectraMan]

I was interested by your comment earlier in the thread that "<<4 is a faster way to calculate *16". I'm always trying to expand my knowledge, and I was interested enough in what you said that I built a quick test harness that could run both of those calculations X many times in different threads. .

I wish I hadn't said that as it's confused this whole argument. When I was writing highly optimised assembler graphics code, then yes shifts were a good way of speeding it up, but I'd probably never do it in C++ and certainly not C# for the reasons mentioned.

But the question is assuming you know that << means a bit shift, then is it reasonable to assume that anybody with a basic knowledge of computers and how they work would know that bitshifting left on an integer value has the same outcome as multiplying by a factor of two? All code has to be written assuming a reasonable amount of knowledge on the part of a maintainer, and there are pleanty of other languages features that aren't used that often. How often do you use do...while? I bet not very often (neither do I), but would you be concerned about a programmer using that trick?

[Gentile]

I wish I hadn't said that as it's confused this whole argument. When I was writing highly optimised assembler graphics code, then yes shifts were a good way of speeding it up, but I'd probably never do it in C++ and certainly not C# for the reasons mentioned.

But the question is assuming you know that << means a bit shift, then is it reasonable to assume that anybody with a basic knowledge of computers and how they work would know that bitshifting left on an integer value has the same outcome as multiplying by a factor of two? All code has to be written assuming a reasonable amount of knowledge on the part of a maintainer, and there are pleanty of other languages features that aren't used that often. How often do you use do...while? I bet not very often (neither do I), but would you be concerned about a programmer using that trick?

The thing is, developers aren't just a bag of tricks and magical incantations to Make Stuff Happen. The most essential skill we need is to be capable of turning client goals into elegant solutions, within a timescale that's short enough to matter. There's no acid test for that ability that's better than giving them a small, abstract problem to tackle within a reasonable amount of time (less than half an hour) using the same real development environment that you'll expect them to use on the job. You can ask them about all the out-of-context syntax and obscure programming "tricks" as you call them all day long, and you'll still never identify those people that have a propensity for navel-gazing and/or amusing themselves with obscure code to the detriment of actually Getting Things Done.

Of course, asking questions like "what is an abstract class?" and "do you know what a Singleton is?" are good pointers to some of the knowledge required to exercise that ability in C#, just as testing drivers on the Highway Code is a good pointer for rudimentary driving knowledge (as opposed to skill). But, most importantly, you need to see them actually drive before you can know if they're any good or not. If you discount or alienate any good driver before you get to the stage of seeing how they handle a wheel by asking obscure questions about carburettors, chances are you'll end up recruiting someone that knows everything about the minutiae of how engines work, but quite possibly nothing about driving.

[Bunk]

@Willapp: I'd still disagree with your conclusion 1), since I don't think a good C# developer needs to know in detail what the compiler will do with their code any more than a good driver needs to know what the carburettor in the engine of the car they happen to be driving will do to achieve the optimum mix of fuel and air when they press the accelerator. And I wouldn't ask a question like this in a test, except perhaps in an effort to identify candidates that would mistakenly think it was a good idea to use that operator in production code written in a high-level language.

In your car analogy though, I'd say the users were the drivers and developers were the mechanics/car-builders.

[Gentile]

In your car analogy though, I'd say the users were the drivers and developers were the mechanics/car-builders.

In my analogy, the driver is the developer, with "ability to drive" being the skill you are trying to assess, and the end user is someone that requires to be taken from A to B without wishing to know the details of how to drive themselves.

Like all analogies, it depends on context: you can take an analogy too far, or apply the same analogy to many different and unrelated problems.

[Willapp]

@Willapp: I'd still disagree with your conclusion 1), since I don't think a good C# developer needs to know in detail what the compiler will do with their code any more than a good driver needs to know what the carburettor in the engine of the car they happen to be driving will do to achieve the optimum mix of fuel and air when they press the accelerator. And I wouldn't ask a question like this in a test, except perhaps in an effort to identify candidates that would mistakenly think it was a good idea to use that operator in production code written in a high-level language.

But the whole point of a test is to ascertain the candidate's depth and breadth of knowledge over the subject area, in this case C#, and since bit shifting is a part of the language it's a valid question to ask. We can never know what the client does with the answers given, and maybe you're right that they would see someone answering this correctly as a red flag, but I highly doubt it. Given two candidates who answer all other questions equally, but one answers the bitshift question correctly while the other does not, it is evidence that one candidate has a greater depth of knowledge than the other and any client is likely to view this as a Good Thing.

Whether this, in turn, translates into a better ability to deliver the client's results is a different issue and if the answer is "not necessarily" then it raises questions as to the point of technical tests at all. Obviously clients use them as part of a larger screening process but at some point a decision has to be made and it's quite possible that the only thing separating two candidates is their test score, meaning the candidate who knew about bitshifting could get chosen over the one that didn't

My point is that more knowledge can never be a bad thing, and if it helps me to get work then I will assimilate all the knowledge that I can in the hope that it sets me apart from my competitors. Being satisfied that not knowing something is okay seems a bit defeatist to me unless you're happy for other candidates to get roles instead because they've gone the extra mile to learn more.

[BrilloPad]

So to summarise this thread, we're agreed that:

1) A good developer really should know what the bit shift operator is and what it does, and even be able to demonstrate such knowledge under test conditions.

2) A good developer should never use said operators in production code unless it actually aids in understanding what the code is trying to achieve, such as with image manipulation etc. It should not be done to prove how cool and knowledgeable one is, or under some misguided notion of 'optimization' since modern compilers will tend to produce the same output anyway (or may even be able to optimize code better if the developer isn't trying to interfere).

I disagree with 1) - at least for IB developers. Anyone who bothers to know that stuff is unlikely to be able to cope with a hairy great trader tearing them out a new you-know-what.

[Gentile]

But the whole point of a test is to ascertain the candidate's depth and breadth of knowledge over the subject area, in this case C#, and since bit shifting is a part of the language it's a valid question to ask. We can never know what the client does with the answers given, and maybe you're right that they would see someone answering this correctly as a red flag, but I highly doubt it. Given two candidates who answer all other questions equally, but one answers the bitshift question correctly while the other does not, it is evidence that one candidate has a greater depth of knowledge than the other and any client is likely to view this as a Good Thing.

Whether this, in turn, translates into a better ability to deliver the client's results is a different issue and if the answer is "not necessarily" then it raises questions as to the point of technical tests at all. Obviously clients use them as part of a larger screening process but at some point a decision has to be made and it's quite possible that the only thing separating two candidates is their test score, meaning the candidate who knew about bitshifting could get chosen over the one that didn't

My point is that more knowledge can never be a bad thing, and if it helps me to get work then I will assimilate all the knowledge that I can in the hope that it sets me apart from my competitors. Being satisfied that not knowing something is okay seems a bit defeatist to me unless you're happy for other candidates to get roles instead because they've gone the extra mile to learn more.

No, the whole point of interviews in the real world is to determine whether the person you're interviewing can produce meaningful solutions within reasonable timescale and budgetary constraints. I think you might be thinking of the differing goals of schools and universities if you conversely believe the point is to merely assess knowledge for the sake if it.

[louie]

In your car analogy though, I'd say the users were the drivers and developers were the mechanics/car-builders.

I agree, the end user is the driver. I would much rather hire a developer who understood how a computer functions and some low level details, which you are exposed to when using C for example. Developers that only know higher level "managed" virtual machine languages are destined to write sub par code. Imagine a piece of code you wrote was called 1 million times every second?

[Gentile]

I agree, the end user is the driver. I would much rather hire a developer who understood how a computer functions and some low level details, which you are exposed to when using C for example. Developers that only know higher level "managed" virtual machine languages are destined to write sub par code. Imagine a piece of code you wrote was called 1 million times every second?

I don't need to imagine it. The test harness I mentioned earlier did exactly that.