| WIKI | FAQ | Tech FAQ | |
 http://csua.com/feed/ | |
| ||||||
| 5/25 |
| 2007/3/30-4/2 [Computer/SW/Languages/C_Cplusplus, Computer/SW/Languages/Java] UID:46149 Activity:nil |
3/29 http://www.codinghorror.com/blog/archives/000781.html Coding Horror, Programming and human factors by Jeff Atwood. \_ An interesting link from that page, a test to seperate out people who can never learn to program. With serious scientific paper. http://www.codinghorror.com/blog/archives/000635.html \_ I love this: "To write a computer program you have to ... accept that whatever you might want the program to mean, the machine will blindly follow its meaningless rules and come to some meaningless conclusion." |
| 5/25 |
|
| www.codinghorror.com/blog/archives/000781.html turning away lots of programmers who can't write a simple program: After a fair bit of trial and error I've discovered that people who struggle to code don't just struggle on big problems, or even smallish problems (ie write a implementation of a linked list). So I set out to develop questions that can identify this kind of developer and came up with a class of questions I call "FizzBuzz Questions" named after a game children often play (or are made to play) in schools in the UK. An example of a Fizz-Buzz question is the following: Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz". Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes. Ive also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution. had a similar experience hiring entry-level programmers: A surprisingly large fraction of applicants, even those with masters' degrees and PhDs in computer science, fail during interviews when asked to carry out basic programming tasks. For example, I've personally interviewed graduates who can't answer "Write a loop that counts from 1 to 10" or "What's the number after F in hexadecimal?" Less trivially, I've interviewed many candidates who can't use recursion to solve a real problem. anyone who lacks them probably hasn't done much programming. Speaking on behalf of software engineers who have to interview prospective new hires, I can safely say that we're tired of talking to candidates who can't program their way out of a paper bag. If you can successfully write a loop that goes from 1 to 10 in every language on your resume, can do simple arithmetic without a calculator, and can use recursion to solve a real problem, you're already ahead of the pack! Between Reginald, Dan, and Imran, I'm starting to get a little worried. I'm more than willing to cut freshly minted software developers slack at the beginning of their career. But I am disturbed and appalled that any so-called programmer would apply for a job without being able to write the simplest of programs. That's a slap in the face to anyone who writes software for a living. vast divide between those who can program and those who cannot program is well known. I assumed anyone applying for a job as a programmer had already crossed this chasm. Apparently, FizzBuzz style screening is required to keep interviewers from wasting their time interviewing programmers who can't program. test as being too easy - in my experience it is genuinely astonishing how many candidates are incapable of the simplest programming tasks. Maybe it's foolish to begin interviewing a programmer without looking at their code first. At Vertigo, we require a code sample before we even proceed to the phone interview stage. And our on-site interview includes a small coding exercise. Nothing difficult, mind you, just a basic exercise to go through the motions of building a small application in an hour or so. Although there have been one or two notable flame-outs, for the most part, this strategy has worked well for us. View blog reactions Comments In case any readers don't know how to complete that test, here's a solution in VBScript. Echo i End If Next James on February 27, 2007 01:38 AM Very very common, alas. I once interviewed a candidate for a VBA job (yes, you can stop booing for the peanut gallery) whom I asked to swap two variable contents without using a temp variable. Well, I can't do it in VBA, but if you let me use Excel I can put the values in two cells and swap the cells' contents using a third cell. We hired the guy who said, well, "if they're integers, then I'd do it by a=a|b, b=a^b, a=a^b. Toepopper on February 27, 2007 01:49 AM I've been making a decent living from programming for over ten years, and if I may say so, I write some damn good code. However, I have never *once* used - or had call to use - recursion to solve a problem, since I learned about it at university. Or is it simply that people program in different ways for different problem spheres? loop have no career as some kind of programmer ahead of them. Does that mean that every one of those people who do program but don't use (say) recursion is a bad programmer? Or is it that you can't rely on any one testing method (like writing simple programs) to prove either way that the person can program effectivley or not? The most obvious way to decide - for me - is to run through these tests, emply the person you like the best and then look at the code they've produced after a week. The bottom line is, you can always learn to pass interview tests of any kind - that doesn't mean you can program or not. AndyToo on February 27, 2007 02:00 AM I think the above solution is not elegant. Echo "Buzz" End If because it covers the "both" case automatically. OK you have to care about line breaks which I don't know in VBS (never used that crap, thank goodness). shenpen on February 27, 2007 02:05 AM I think the use of recursion probably depends on the particular field that you code in. As a web developer I also have very little cause to use it. The only time I use it is when I need to search through the file system. James on February 27, 2007 02:08 AM Isn't the code for that .. copied it from somewhere :P VibhavSharma on February 27, 2007 02:09 AM There's a cynical voice in my head that says "because no-one has ever asked them to". Where I work we spend a long time looking before we hire someone, because it's so hard to find them. We use a walk-through test that has a sequence of "questions" leading to a simple app and are willing to argue the toss (I was hired despite arguing that the test had significant flaws: "why would I do that? " when they wanted me to code a solution that led to the next question). I fear that any take-home or pre-interview component would lead to plagarism or "helped" solutions, so we make candidates perform in front of us. James on February 27, 2007 02:11 AM Sorry, but if someone were to ask me how to swap two variables w/o a temp variable I'd ask them to give me a good reason why. Not being able to answer that particular question certainly doesn't preclude someone from being a good programmer. That'd be like asking a C# programmer how to do modulo 16 using only a logical and. Michael Reiland on February 27, 2007 02:18 AM shenpen: As you point out, your solution doesn't handle line breaks. Mike Miller on February 27, 2007 02:18 AM shenpen, for shame. I don't think I've ever interviewed a programmer quite that bad, but I did have a conversation with a contractor I was replacing once: I'd introduced a class into the monster spreadsheet he'd been maintaining and he looked at it and remarked "I wish I knew how to do that". He was picking up about GBP400 a day (call it about $650 at that time) for this. As I'm about to start looking for a programmer I shall be able to implement my long-cherished plan of asking candidates to submit a page or so of what they consider to be "good code". I don't mind if they wrote it or not, I want to see if we agree on the look of "goodness". If we get that far, I can find out if we agree on why it's good. This is nasty but it's technically a one-liner: 1upto(100) { |n| puts n % 3 == 0 ? "fizz" : n } Mike Woodhouse on February 27, 2007 02:19 AM WOW! I can't believe there are people out there applying for jobs in software that cannot write a fizzbuzz program. Mike Miller on February 27, 2007 02:23 AM James: it's amusing to me that any reference to a programming problem-- in this case, FizzBuzz-- immediately prompts developers to feverishly begin posting solutions. The mechanical part of writing and solving FizzBuzz is irrelevant. It's the ones we can't rerach-- the programmers who don't read anything-- that we have to give the FizzBuzz test to. Jeff Atwood on February 27, 2007 02:36 AM My point is that what you're asking for isn't "domain knowledge" strictly speaking. Using an XOR to swap two variables w/o a temp variable is only really... |
| www.codinghorror.com/blog/archives/000635.html academic paper, which proposes a way to separate programming sheep from non-programming goats in computer science classes-- long before the students have ever touched a program or a programming language: All teachers of programming find that their results display a 'double hump'. Almost all research into programming teaching and learning have concentrated on teaching: change the language, change the application area, use an IDE and work on motivation. We have a test which picks out the population that can program, before the course begins. You probably don't believe this, but you will after you hear the talk. We don't know exactly how/why it works, but we have some good theories. I wasn't aware that the dichotomy between programmers and non-programmers was so pronounced at this early stage. But evidently it's common knowledge amongst those who teach computer science: Despite the enormous changes which have taken place since electronic computing was invented in the 1950s, some things remain stubbornly the same. In particular, most people cant learn to program: between 30% and 60% of every university computer science departments intake fail the first programming course. Experienced teachers are weary but never oblivious of this fact; brighteyed beginners who believe that the old ones must have been doing it wrong learn the truth from bitter experience; and so it has been for almost two generations, ever since the subject began in the 1960s. You may think the test they're proposing to determine programming aptitude is complex, but it's not. Here's question one, verbatim: Read the following statements and tick the box next to the correct answer. a = 20 b = 10 This test seems trivial to professional programmers, but remember, it's intended for students who have never looked at a line of code in their lives. The other 12 questions are all variations on the same assignment theme. The authors of the paper posit that the primary hurdles in computer science are.. Thus, we start by testing the very first hurdle novice programmers will encounter: assignment. once at the beginning, before any instruction at all, and again after three weeks of class. The striking thing is that there was virtually no movement at all between the groups from the first to second test. Either you had a consistent model in your mind immediately upon first exposure to assignment, the first hurdle in programming-- or else you never developed one! The authors found an extremely high level of correlation between success at programming and forming a consistent mental model: Clearly, Dehnahdis test is not a perfect divider of programming sheep from non-programming goats. Nevertheless, if it were used as an admissions barrier, and only those who scored consistently were admitted, the pass/fail statistics would be transformed. in the first-test consistent group only 6 out of 27 (22%). We believe that we can claim that we have a predictive test which can be taken prior to the course to determine, with a very high degree of accuracy, which students will be successful. This is, so far as we are aware, the first test to be able to claim any degree of predictive success. the draft paper (pdf), which was remarkably entertaining for what I thought was going to be a dry, academic paper. It's filled with interesting insights like this one: It has taken us some time to dare to believe in our own results. It now seems to us, although we are aware that at this point we do not have sufficient data, and so it must remain a speculation, that what distinguishes the three groups in the first test is their different attitudes to meaninglessness. Formal logical proofs, and therefore programs formal logical proofs that particular computations are possible, expressed in a formal system called a programming language are utterly meaningless. To write a computer program you have to come to terms with this, to accept that whatever you might want the program to mean, the machine will blindly follow its meaningless rules and come to some meaningless conclusion. In the test the consistent group showed a pre-acceptance of this fact: they are capable of seeing mathematical calculation problems in terms of rules, and can follow those rules wheresoever they may lead. The inconsistent group, on the other hand, looks for meaning where it is not. The blank group knows that it is looking at meaninglessness, and refuses to deal with it. Everyone should know how to use a computer, but not everyone needs to be a programmer. But it's still a little disturbing that the act of programming seems literally unteachable to a sizable subset of incoming computer science students. Evidently not everyone is as fascinated by meaningless rules and meaningless conclusions as we are; Jeff Atwood on July 15, 2006 02:33 AM I wonder if there's another variable at play. Perhaps the students who scored with a consistent view had already been exposed to programming. When I was in college, I remember the students in my classes who had trouble were ones who were entirely new to programming. The rest of us had either been in programming classes previously or had been coding for fun since we were kids. Chris on July 15, 2006 03:13 AM The interpretation of the results of the above assignment test make me feel angry. I am not a teacher but I am confident that I can teach (in less than 15 minutes) any person smart enough to be admitted to a computer science class how to pass the above test. The results speak volumes about the utter ignorance of educators regarding the nature of human knowledge and how to acquire it. It is a tremendous act of injustice to blame the students and not the teachers. Now if a student is *unwilling* to learn the material then that is another question. But to blame the poor education methods on students willing to acquire the knowledge is just ridiculous. How is this teaching being done, would changing the teaching method affect the results? Anbal Rojas on July 15, 2006 06:00 AM Anibal, yes changing the teaching methods would definitely change the results somewhat. Maintaing 100% accuracy with humans is nigh on impossible. I look forward to the follow up work that will be done on it. Unfortunately most computer science departments are not in the position to turn away students, so I think the best application of this(if it turns out to work well in all institutions) would be for streaming the class into honours students and pass students. Generally in CS Education Research you'd need a multi-institutional, longtitudinal study to have fully verified results, so I guess we'll wait and see what comes out of it. Des Traynor on July 15, 2006 06:41 AM I liked the paper, but the acedemic snobbery in Section 5 pissed me off no end: "The consistent group seem to be much easier to teach. We speculate that they divide into two groups: the very successful ones find programming easy and may perhaps be those who ought to follow a conventional computer-science education, with lots of formal content; " Poor software engineers, doomed forever to management discipline, UML, and a lack of formalism, all in a job that they'll never enjoy! Andrew Shebanow on July 15, 2006 09:02 AM I would add 'indirection' as hurdle number 3 between recursion / iteration and concurrency. Anyway, I observed of my fellow students that, whether expressed as explicit pointers or references, or as reference semantics, many of them simply never got the concept of indirection. Mike Dimmick on July 15, 2006 09:18 AM Programming ability is not known to be correlated with age, with sex, or with educational attainment Uh, it is known to be correlated with sex. namehere on July 15, 2006 10:23 AM I'm by no means an expert but I've been teaching high school computer science for 14 years. I did link a comment to this post and to the orginal study, because I find both fascinating. Over the years, I've had actually three groups of students. The good news, since I'm teaching high school, it gives them an opportunity to find out which group they belong in without shelling out any money. The funny part is the high number of parents who are upset that their student isn't in th... |