I, too, use simple tests - often as questions in a telephone interview .. but sometimes face-to-face. I figured they'd be viewed as archaic skills, and some of my colleagues have commented to that effect in the past. I believe, however, that programmers are more effective if they understand the machine they're programming. So: a sample of my simple questions:
- What is significant about the number 255?
- How does a computer store a floating-point number?
- Using a bitwise boolean operation, what is 6 & 3?
- How are parameters typically passed in to a function call?
- Describe the implementation of a linked list
- What is recursion?
- What is the stack; what is the heap; and how to they differ?
- What is packing or alignment in data structures?
- What is an atomic operation? Describe a typical use of one
I found that 8/10 candidates comprehensively fail to demonstrate an understanding at this level - and that none ever answered all correctly.
So why can this be? Schooling.
When I were a lad .. our school bought a Commodore PET. I imagine they felt the new technology might benefit in some educational way - but I reckon they didn't know what to do with it. So they gave it to the head of maths. I guess they figured it was a big calculator. We started a computer club and pretty soon we were learning about algebraic logic and iteration using BASIC computer programs. Before the year was out, we knew far more than the teacher and had progressed to writing routines in 6502 assembler. I seem to recall the 2nd cassette port at address 826 was a safe location for such code. By the time I left school, I knew by heart all the powers of 2 up to 65536 and could do simple hex arithmetic in my head.
These days, as far as I can tell (from questions asked at open days) "IT" is no more ambitious than learning how to format paragraphs in Word, or sum a column in Excel. This is appalling for two big reasons: Firstly, it is just button-pushing. There is no skill in knowing where the "centred" option is for paragraph justification; it does not foster creativity or organised thought. Secondly it is very application-specific. Now I know you've got to start somewhere, and arguably the most common software is a sensible place to start, but does it really have to be Microsoft? Let's face it, despite their many (many) faults, Microsoft have invested a lot of money in usability to ensure their products are intuitive and easy to use. So how can spending lesson after lesson poking at it be justified (not left or right or centred .. just reasonable .. OK)?
Basically, no-one teaches computer programming in school. It's a shame, because it can be a vehicle for all sorts of subject matter. It's also a shame because I find it very hard to get the "right" candidate.
6 comments:
I couldn't write down the matrix required for rotating a point in 3D space let alone solve the sine, cosine or other formulas that are plugged into that matrix. But I have written my own 3D game engine. I can't show you on paper how to compute the distance between two latitude and longitude points, but I write map software for a package delivery company.
But how can that be? This is not trivial programming but according to you and the author of the article, I don't know how to program because I can't add in hex or solve a bitwise boolean operation in my head. I argue that a good Software Engineer doesn't need to know how to solve these problems on a piece of paper. THAT IS WHAT COMPUTERS ARE FOR!
As a Software Engineer, problem solving skills are 80% of software engineering. The syntax of programming and programming well is the difference between a good programmer and a great programmer.
I don't need to know the mathematics for rotating a point in 3D space. But as a Software Engineer, I do need to know how to find that formula, how to implement it in code and where to use it.
I was passed over for a job because I couldn't "Write a function to compute the moving average of a stock price." Heck, I didn't even know what a "moving average" was. But when I got home I sat down and 20 minutes later I had a nifty little recursive function that answered the question. Why couldn't I do that in the interview? Because in the interview I didn't have the resources I would normally have while on the job. A good Software Engineer knows how to use those resources to solve programming problems.
Off of the top of my head, I don't know the answers to your questions 3 and 9. And I really don't care...
Does that make me a bad programmer?
Well, Mr. Anonymous¹, not necessarily. It does depend, however, on what environment you're programming in. If, for example, you were engaged in writing code for an embedded system - say, a mobile phone - then more low-level knowledge is required.
I was complaining not about programmers, but schooling. And the apparent dying of an art.
FWIW, in general, I tend to hire on the strength of aptitude and eagerness to learn - rather than existing knowledge.
¹ from Hawthorne, New Jersey? G'waan .. what's yer name?
Raymond,
Sorry but you were complaining about programmers, albeit via schooling.
Secondly, the type of environment I am programming in doesn't mean squat. The mapping software I write includes desktop app's and server side event processing as well as embedded programming for handheld devices and java phones.
I didn't know any embedded programming(heck, I didn't know anything about cartography either!) or java when I started this job. But today I am one of 4 Software Engineers that are considered THE expert programmers for our suite of mapping and delivery software.
Imagine how things would have turned out if, during my job interview, I had been asked "What is the result of the bitwise operation '6 & 3'?"
Still don't know, still don't care...
I don't have a Google account so I can only post as anonymous.
Respectfully,
Bob Smith, Columbia, MD.
Bob,
I guess this is a discussion that could run and run.
I say that if for example you don't know the difference between an array of 32 BOOL values and a double-word bitfield in C, then you're not going to be very memory efficient (128 bytes .vs. 4 bytes) This kind of thing could make or break a phone's firmware.
Sure, modern, high-level languages do away with the need to know a lot of this stuff .. and if you're happy and successful, then that's great.
You say you've gone from not knowing anything about cartography or Java to achieving some status in your field. I hope I'd have hired you. If you'd demonstrated the desire to learn, I probably would have. I'd have still asked the low-level questions, tho'.
BTW: 6 & 3 == 2 ;^)
(Nice discussion folks.)
Oh, right, I should add something more, shouldn't I?
Well, I got my very first ever job straight from uni (having studied, of all things astrophyics, not reknowned for its high programming content) into software engineering beating 'proper' CS grads. I even remember at the interview the people bemoaning the lack of programming being taught at _uni_ back then.
Still, at least there is Bangalore, eh?
(ps: I could have answered your questions! Although I would probably quibble on some of them. Or expand a bit too much, as they are slighty open ended, no?)
What Bob said, though, modern languages are used as an abstraction from the machine they are programming. Even down to the phone/embedded level. (Hey, that is what buying a good compiler will help with! Not all the way, but it will help.)
I think there is a distinction between 'IT' and 'CS'.
Oh, and lastly, if you think things are bad when you wander in to a school open day with your computer knowledge, imagine the horror at someone versed in mathematical sciences looking at the text books these days...
straytaoist,
well done: you get full marks. The questions are deliberately open-ended. Quibbling is much more fun and shows a broader subject knowledge. We used some "broken program" tests, too: I was never interested in getting the right answer; hearing the thought processes was much more informative.
Even in high-level languages, though, some knowledge of how the machine works is required. Take this example:
String first = "some text";
String second = "some text";
if (first == second) {
System.out.println("equal");
}
else {
System.out.println("different");
}
This was one of our Java questions: what does this print and why.
You'd have got the job .. oh, hang on: we tried that one, didn't we? Hmm .. back to the drawing board ;^)
Post a Comment