Does it really gauge one's ability to code ?
-
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'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)
-
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, 2013For 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;
