|
I've seen lots of bitshifting in c#. Very common in image processing.
|
|
|
|
|
For what it's worth, I've got some production C# code that handles TCP/IP communications that uses << and >> on occasion for endian-ness conversions, bit field extraction, and so on.
Software Zen: delete this;
|
|
|
|
|
I'd have to rack my brain to do this.
Not that I don't know how, it's just been over 10 years since I last had to do bit shifting.
No doubt someone fresh from college would do it off the top of their head because it's only been 6 months for them and would give them an advantage in test conditions.
|
|
|
|
|
What is this supposed to be testing? Programming ability or knowledge of C# / C++ / whatever other language share this syntax?
It looks like this is trying to testing the latter and is not hugely usefull. If you can get the correct answer then that is great, if not then that does not mean anything.
If this is testing for programming language knowledge then this is potentially usefull.
(and yes, I can work this out - assuming the correct answer is 0x5555AAAA.)
|
|
|
|
|
Knowing how to code C# syntactically, doesn't mean sh*t in the real world, in and of itself.
I am more interested that my fellow engineers know how to solve complex problems, and you can't really take a f***ing test for that, now can you.
I am strongly against organized testing, as I have seen it prove nothing really, time and time again.
We have fired more Engineers from our shop because they could not design, let alone implement, basic problem solving solutions, versus their ability to do basic C# fundamental tasks (you can learn this sh*t, duh).
I don't think you can learn problem solving, I think you are born with that - true problem solving.
In summary, syntax and code fundamentals you can learn (if they are not retarded), but problem solving is hereditary. I am more interested in one's ability to problem solve, then the proper way to concatenate a bloody string
|
|
|
|
|
Slacker007 wrote: I am strongly against organized testing
Says the person who identifies themselves as a slacker. 
It was broke, so I fixed it.
|
|
|
|
|
This misnomer is by design, because I am anything but a slacker, thus, the reason I chose this to be my online name. I also like James Bond films, and I am not bad-ass enough to be a super spy, so I threw in the "007" for good measure.
|
|
|
|
|
No insult intended, just found the irony between the statement and your online ID was humorous. 
It was broke, so I fixed it.
|
|
|
|
|
S Houghtelin wrote: No insult intended
Did not take it as such. 
Cheers.
|
|
|
|
|
Specifically:
Well, you get to look at it with a bit of perspective : Rshift followed by Lshift of the same amount simply introduces as much zeroes as in the the shift on the right of your initial number. This means the first three operations neutralize in this case. So you simply XOR the last four 5 with F, which gives A (A5 pattern is commonly used to test memory, since both are made up of alternating 0 and 1's, that are swapped when XORed with F, so result of F-XORed A5 is always 5A).
More generally:
This is testing your logic, and how you can use your brain to solve something. You will probably never use it if you do not do low level, but sometimes it helps to solve complex situations to have a analytic mind.
|
|
|
|
|
virang_21 wrote: Where in real world application am I going to use this ?
Your question, young Padawan, tells me that close to the hardware you programmed have not yet. Look at a processor's instruction set you must and such logical instructions find you will. Learn to use them and address calculations and bit masking you fear must not.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
I once was asked in an interview to write a simple function, and later the interviewer asked me about two features he said he hadn't previously seen at all: one was 'Yoda conditions' and the other was designing the loop in such a way that the end condition was a comparison to 0.
The latter was based on the knowledge that in assembler, comparisons to 0 are typically slightly faster than comparisons to a constant. The former was to make the compiler shout out in case of an accidental typo (writing '=' rather than '==').
After a couple of days, I was told to be overqualified for the job 
Nowadays, I'd do neither: the first is sufficiently covered by compiler warnings, the second is a kind of optimzation that a good compiler can usually do just as well, and often better. Moreover, not having to care about either makes it easier to write clean, readable code, and that is the most important thing in the long run.
I'm telling this because these kind of optimizations I used are just as obsolete nowadays as bit-twiddling, unless you really, really need to optimze your performance, and know for a fact (i. e. you have actually measured) that the compiler doesn't already optimize the code sufficiently. In C++ you can use bitfields; I am not sufficiently familar with C# to know what can be used here to provide a reasonably high-level API.
But, even if you do need bit manipulations, within a given project those should be encapsulated in just a handful of functions that take at most an hour or two to implement and test - so it's still entirely senseless to test a candidate on that kind of know-how 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: But, even if you do need bit manipulations, within a given project those should be encapsulated in just a handful of functions that take at most an hour or two to implement and test - so it's still entirely senseless to test a candidate on that kind of know-how
No. Please spread them out as redundantly as possible, and don't use any enumerations. Use magic numbers and obfuscate the lines in as many different ways as you can think of.
Stefan_Lang wrote: After a couple of days, I was told to be overqualified for the job
Happened to me too, but the interview was about using stacks. I think the interview was over when I told him that I learned on a microprocessor that could have 15 stack pointers at the same time if needed. The one remaining register would have to be the program counter.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
We seem to enjoy reducing our individuality down to an abstract number that we can then use to simultaneously stroke our ego and feel inferior in a pointless comparison with other abstract numbers.
And of course, the bean counters love their pigeon holes in which to categorize us to determine our salaries, title, benefits, and work.
Marc
|
|
|
|
|
With this level of English and deep meaning you can easily write a novel or two.
Zen and the art of software maintenance : rm -rf *
Maths is like love : a simple idea but it can get complicated.
|
|
|
|
|
That abstract number is our salary, and - at least in western cultures - we never really talk about that lest we feel inferior
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
That's one of those question that make it clear that the recruiter (or whoever is interested in your score) has no idea what to ask so he makes up artificial challenges. It doesn't matter at all if you can clearly predict the outcome of code that wouldn't pass a code review.
|
|
|
|
|
This question tests your ability to use the bit-manipulation operators. You would use such code when writing comms protocols or device drivers, and lots of other places. If you haven't seen code that does a lot of bit manipulation, maybe your experience, and thus your mastery of C#, isn't as great as you thought it was.
|
|
|
|
|
Even if the future task of an applicant was to write device drivers, writing and testing the handful of bit-encoding and -decoding functions that are truly required shouldn't take more than 5% of the total time, more likely less than 1%.
It would be more useful (and more objective) to test the applicant's typing speed than that!
P.S.: and if that company has any significant fraction of development in the area of device drivers, they should already have a ready to use library for the encoding and decoding, and thus no need for any developer who knows her way around bit manipulations
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I'm sure this question was less than 5% of the coding test, and less than 1% of the interview, so it might even have been an appropriate question by this measure.
Coding questions don't measure ability very well, but they do quickly exclude a particular kind of poseur, who can't code a lick. It felt very strange to me when I discovered that people who know absolutely nothing about programming apply for programming jobs, but it has happened to me.
It's also a problem that there aren't any measures that are better than coding questions. There aren't any tests of developer skill that can be successfully applied in a short interview.
|
|
|
|
|
I never found 'code this' type of tasks to be very useful in an interview, since there's simply not enough time for a task that would tell you something useful about the applicant's real coding skills.
However, analyzing a given piece of code can be quite good, since you can hide some subtleties and special techniques that you care about in the code and then wait to see what the applicant can find out about it.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
If you are writing a general ledger then no, it's not that relevant other than demonstrating a basic knowledge of boolean algebra and numerical anaysis (i.e. truncation and how it affects accuracy). If the job was embedded, especially bare iron, it's a core competency and if you missed it you better go back to selling shoes on a website.
Any time you interface to a foreign app or device it's quite likely you'll come across situations like that. Even if it's C#, when you build that production line tester that interfaces to scales, spectrometers and time of flight sensors you'll have to know boolean operations.
And if you don't understand boolean operations, how do you build SQL queries or LINQ statements?????
|
|
|
|
|
JackPeacock wrote: If the job was embedded
I've done my share of embedded coding, and never had any need to use bit manipulation functions. Those were encapsulated in the low level actuator and sensor drivers. And that was just a fraction of the code. Yes, in a team of ~10 devs, one engineer (not a CS guy) worked on that level. But most of his time was spent adjusting the timings, or fixing the functionality that wasn't quite working the way it was intended (or simply on higher level stuff), not fiddling with bits. Once the bit-manipulating code was in place, it hardly got changed anymore.
What I'm saying is that even where you really need these operations, they only take up a very limited fraction of the total development work! I don't really see how it could ever be so important to make it a criterion for an applicant.
JackPeacock wrote: And if you don't understand boolean operations, how do you build SQL queries or LINQ statements?????
Well, first of all you need to understand that bit operations go quite a way beyond simple boolean logic in the same way that evaluating exponentials manually goes way beyond simple addition: You can develop the understanding of one from the other - but that doesn't mean it's the same level of knowledge.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Best east west deli stews an antelope. (10)
modified 23-Nov-16 4:26am.
|
|
|
|
|
Wildebeest (anagram of best + e(ast) + w(est) + deli leading to a creature often found on the plains of Torbay).
Slogans aren't solutions.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
