C# interview question

[Spacecadet]

You guys will be arguing for the re-introduction of Sinclair Basic GOTO statements next.

They have their uses

 

[VectraMan]

Doing things a certain way just because that's the way you've always done them (and is the only way you know how to do them) can lead to some fairly counter-intuitive solutions and unreadable code.

Sounds like you agree with me now. If you're going to come up with new and creative solutions, you need to know all the tools you have at your disposal. The sort of programmer that's confused by basic language features, or dismisses them as irrelevant because they've not had to use them before, isn't going to be the sort of programmer to do that. They're going to be the sort of programmer that gets by with copy and paste and reproducing work they've done before.

On that basis, it's a pretty good interview question. And remember, this is a contractor forum. We're meant to be experts.

 

[Gentile]

Sounds like you agree with me now. If you're going to come up with new and creative solutions, you need to know all the tools you have at your disposal. The sort of programmer that's confused by basic language features, or dismisses them as irrelevant because they've not had to use them before, isn't going to be the sort of programmer to do that. They're going to be the sort of programmer that gets by with copy and paste and reproducing work they've done before.

On that basis, it's a pretty good interview question. And remember, this is a contractor forum. We're meant to be experts.

I don't know where you got the mistaken idea that I was agreeing with you from. C# is full of legacy features that are there only for support of solutions built in days gone past, not because they're actually used by anyone any longer. There's a difference between having the intelligence to come up with novel and innovative solutions to current problems, and stockpiling obscure knowledge merely for the sake of it. You get people in all walks of life that focus on knowledge over intelligence; usually (though not always) it's because they don't possess the latter, and are trying to make up for their deficiencies by focusing on the former instead.

The fact that the best example of when you would actually use this particular operator in today's world is that it's "a way to multiply by 16" (when of course x * 16 is a much more readable way to achieve that same outcome), indicates that this particular feature falls firmly into the "arcane knowledge merely for the sake of it" category.

Contractors aren't just meant to be niche experts. We're meant to be people that get things done. Part of that involves seeing the bigger picture, and not just nit-picking or getting bogged down in meaningless minutiae as a means to its own end. As Joel Spolsky says, unless you're smart and get things done, you're no good to anyone in this game. It's amazing how many of those 'smart' people that ask trick questions in interviews can't get a solution delivered on time, within budget, and with all of the features that users needed it to contain.

 

[Jaws]

I have used the bit shift operator before in order to extract red/green/blue values which if I remember correctly are stored as a 32 bit values in windows. Beyond that never.

 

[Gentile]

I have used the bit shift operator before in order to extract red/green/blue values which if I remember correctly are stored as a 32 bit values in windows. Beyond that never.

That's at least a valid use case, although there is a set of utilities in the System.Drawing.Color namespace that would have allowed you to achieve that outcome much more readably and quickly, leaving you more time to concentrate on the more bespoke parts of the wider solution you were working on. The utilities provided even allow you to convert between named colours like "DarkRed" and their Hex or Dec equivalents, or constituent RGBA components thereof.

 

[adubya]

If you've used C before then you'd be familiar with those bitwise shift operators

 

[Durbs]

Contractors aren't just meant to be niche experts. We're meant to be people that get things done. Part of that involves seeing the bigger picture, and not just nit-picking or getting bogged down in meaningless minutiae as a means to its own end. As Joel Spolsky says, unless you're smart and get things done, you're no good to anyone in this game. It's amazing how many of those 'smart' people that ask trick questions in interviews can't get a solution delivered on time, within budget, and with all of the features that users needed it to contain.

This is true and is why these kind of geek pub quiz interviews are a waste of everyones time. Its just a piss poor style of interview, I left there with them knowing absolutely nothing about me, what I can do or what I have done. It went ok but what does that prove? Am I good at C# or did I spend the weekend on dotnetinterviewquestions.com?

All these people saying its a good question to prove xxx, its not. I had a great interview last week, went through every project on the cv, asked me to explain from begining to end how user requirements were gathered, how it was designed, why i'd used a particular pattern, any issues encountered, how it was delivered, how I handed it over to the business. At each stage asking 'proper' questions like "sounds like you had problems at that stage, tell us how you went about relaying that to the stakeholders". Now THAT is an interview, they knew exactly how I delivered projects at the end of it.

I'd guess the kind of person who can recite the bumper book of C would struggle with the latter kind of interview.

 

[VectraMan]

That's at least a valid use case, although there is a set of utilities in the System.Drawing.Color namespace that would have allowed you to achieve that outcome much more readably and quickly, leaving you more time to concentrate on the more bespoke parts of the wider solution you were working on. The utilities provided even allow you to convert between named colours like "DarkRed" and their Hex or Dec equivalents, or constituent RGBA components thereof.

If you were working on a bitmap, you wouldn't want to be calling a function every pixel just to convert the colour. That'd be hideously slow. And how is typing g=(i & 0xff00)>>8 a lot slower than having to go searching for utility functions in the API? I'd have known exactly what to type, and as it's using basic language features, I'd reasonably expect any competent programmer looking at my code to be able to understand it.

I agree with what everybody is saying about how focusing on small technical details is a stupid way of conducting an interview, but if an interview does have a technical component, then expecting you to know the basics isn't unreasonable. And it appears Durbs has been caught out by not knowing his chosen subject as well as he might. Not hiring somebody because they don't know one tiny detail would be silly, but an interview is about building an overall impression of a person and their abilities.

And this is not an obscure C# feature. A quick search reveals the same bitshift operators are in C, C#, C++, Java, Javascript, Python, VB, PHP, Perl, F# (as <<< and >>>), Go, and those are just the ones that spring to mind. The only "major" language that seems to have something different is Pascal. What does it say about the breadth of your knowledge if you have no clue about something that's been a fundamental part of computer languages for 40 years?

I'm curious, do C#ers know what 5 % 3 returns? Or for that matter, the difference between i++ and ++i?

 

[russell]

If you claim to be a computer programmer and don't understand basic binary operations then you are an embarrassment to the profession.

 

[adubya]

This is true and is why these kind of geek pub quiz interviews are a waste of everyones time. Its just a piss poor style of interview, I left there with them knowing absolutely nothing about me, what I can do or what I have done. It went ok but what does that prove? Am I good at C# or did I spend the weekend on dotnetinterviewquestions.com?

All these people saying its a good question to prove xxx, its not. I had a great interview last week, went through every project on the cv, asked me to explain from begining to end how user requirements were gathered, how it was designed, why i'd used a particular pattern, any issues encountered, how it was delivered, how I handed it over to the business. At each stage asking 'proper' questions like "sounds like you had problems at that stage, tell us how you went about relaying that to the stakeholders". Now THAT is an interview, they knew exactly how I delivered projects at the end of it.

I'd guess the kind of person who can recite the bumper book of C would struggle with the latter kind of interview.

Then again, if you're going in an interview for a C# programming gig and someone starts banging on about relaying to stakeholders one might wonder "WTF?".