Does it really gauge one's ability to code ?
-
Knowing how to code C# syntactically, doesn't mean shit 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 fucking 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 shit, 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.
-
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.
-
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. :thumbsup:
It was broke, so I fixed it.
-
I did an IKM assessment for C# and some of the questions are so odd it makes one wonder does it really gauge one's ability to code ? You are given a program and 5 outputs and you have to choose right one. One of the question was what is the value of x after running this code ?
int x=0x0000FFFF; x=x>>4; x=x<<4; x=x|0x0000000F; x=x^0x55555555;Where in real world application am I going to use this ? I scored 76 out of 100. Last time I took .NET 4.5 test I scored 88. How does it help someone understand my ability to write code for actual application ?
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
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
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
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, 2013I 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
-
No insult intended, just found the irony between the statement and your online ID was humorous. :thumbsup:
It was broke, so I fixed it.
S Houghtelin wrote:
No insult intended
Did not take it as such. :thumbsup: :) Cheers.
-
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
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
I did an IKM assessment for C# and some of the questions are so odd it makes one wonder does it really gauge one's ability to code ? You are given a program and 5 outputs and you have to choose right one. One of the question was what is the value of x after running this code ?
int x=0x0000FFFF; x=x>>4; x=x<<4; x=x|0x0000000F; x=x^0x55555555;Where in real world application am I going to use this ? I scored 76 out of 100. Last time I took .NET 4.5 test I scored 88. How does it help someone understand my ability to write code for actual application ?
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
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.
-
Somebody who is good in bit-shifting isnt long-term qualified for the stupidity and annoyance C# and XAML. :~
Press F1 for help or google it. Greetings from Germany
Don't see what XAML has to do with it. I write C# to interface with hardware, do a lot of bit manipulation, and I've never used XAML in my life.
-
This is basic programming stuff. They want to see if you can do the math. Do you know what the answer is?
".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, 2013I'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.
-
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, 2013I've seen lots of bitshifting in c#. Very common in image processing.
-
I did an IKM assessment for C# and some of the questions are so odd it makes one wonder does it really gauge one's ability to code ? You are given a program and 5 outputs and you have to choose right one. One of the question was what is the value of x after running this code ?
int x=0x0000FFFF; x=x>>4; x=x<<4; x=x|0x0000000F; x=x^0x55555555;Where in real world application am I going to use this ? I scored 76 out of 100. Last time I took .NET 4.5 test I scored 88. How does it help someone understand my ability to write code for actual application ?
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
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.
-
I did an IKM assessment for C# and some of the questions are so odd it makes one wonder does it really gauge one's ability to code ? You are given a program and 5 outputs and you have to choose right one. One of the question was what is the value of x after running this code ?
int x=0x0000FFFF; x=x>>4; x=x<<4; x=x|0x0000000F; x=x^0x55555555;Where in real world application am I going to use this ? I scored 76 out of 100. Last time I took .NET 4.5 test I scored 88. How does it help someone understand my ability to write code for actual application ?
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
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?????
-
Indeed. Lines 2-4 are obsolete. How inefficient! ;P
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)
-
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 fucking 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 :wtf: 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 :doh:
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)
-
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
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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)
-
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)
-
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)
-
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 :wtf: 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 :doh:
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 :doh:
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 :WTF:
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 fucking 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. -
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.