|
Indeed. Lines 2-4 are obsolete. How inefficient! 
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)
|
|
|
|
|
John Simmons / outlaw programmer wrote: This is basic programming stuff.
Only for those who have a notion what the processor actually does.
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.
|
|
|
|
|
Which is basic knowledge for us old guys.
I haven't personally seen any (production) .Net code that uses shift left/right, but its use was somewhat frequent in some unmanaged C++ code I've been involved with.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Just read and convert the input from some binary file format and then press it into .Net structs/object. As soon as you leave the beaten path of serializing/deserializing from and to XML, you will have to do a good share of bit twisting.
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 had to use bit shifts when I built an email processor to manually decode Base64 to regular binary. The non-programmers gave me puzzled looks when I described it as bit-twiddeling.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
