The title seems to intentionally misrepresent the retraction to push an agenda (or the author has some issues with basic logic)
The retraction is that the strong/definitive proof that "the camel has two humps" was fabricated/exaggerated.
The converse - that it has one hump hasn't been proven. From the quote, Richard Bornat doesn't say that they re-crunched the numbers and now there is proof of one hump.
The camel has gone back to having an unknown number of humps
In the absence of that paper, we had plenty of reasonable hypotheses about the ability to program. Like “Put 10,000 hours into it, and you’ll master it.”
Or “It follows a distribution similar to other skills involving mathematics.”
The paper presented an unusual hypotheses, that there was this sharp distinction between those who can program and those who never will, and that this distinction was somewhat orthogonal to other measures of scholarship. So for example, one might be a good architect but never get good at programming no matter how much one tried.
You’re right we haven’t disproven this hypothesis, but given its novelty, the burden of proof is on "the camel has two humps." With the paper retracted, we do not presume it has an unknown number of humps, we presume that skill writing programs is going to be similar to other skills we observe.
As this article observes, unusual outcomes in attempting to teach programming may just as easily be explained by the fact that in a young field, we may not know how to teach programming.
If we’re going to chase ‘humps,’ perhaps we should look for unusual distributions in the skill of teaching programming. We may be terrible at it, and perhaps the skill we are really observing is the skill of learning to program in spite of didactic and structural obstacles.
Or perhaps the people who understood recursion in a week had been writing code since they were 12, and those that didn't were new to it. Or something else we haven't thought of, that is still not innate aptitude. Or the people who understood recursion easily will not be the same people who understand, say, continuations easily.
Still, I'd assume that with programming like I assume for most skills (music, athletics, lawyering, foreign language, whatever), some people start out with more aptitude than others, and find it easier than the others. I wouldn't assume it's a markedly more pronounced or separated distribution in CS/programming than for other things though.
(Also, I have actually been programming since I was 12, and additionally believe I do have some aptitude for it that makes it easier for me than for some others, I'm pretty good at it -- and I still remember how hard it was for me to understand pointers in Pascal when I first learned them, which seem so straightforward to me now I have no idea why it was challenging at first! And I'm glad I had good teachers in formal coursework.)
I didn't understand what all the fuss about recursion was about for it to require more words than "a function that calls itself". Sounded trivial to me. Later I understood that a number of implementation details make the technique a bit special.
The concept itself still sounds trivial to me though.
Meanwhile, it's taken for granted that not everyone can be a doctor, dentist, or lawyer. You don't see doctors telling people that anyone can "learn to med," but programmers see nothing wrong with devaluing their profession in the eyes of the masses by telling them that anyone can learn to do what they do, or worse, that it's easy, and that we shouldn't assume anything else until its proven otherwise.
Programmers are far too egalitarian for our own good and our increasing marginalization and stagnant wages are the inevitable consequences.
I think saying 'everyone can program' is not the same as 'everyone can be a programmer'. Similar to how saying 'everyone can (learn to) take care of their teeth' is not the same as 'everyone can be a dentist'.
Anyone can learn when they have a cold, and what to do about it. In the same way, anyone can learn to write a simple program.
Not everyone has the dedication and skill to become a great MD, and the same applies to being a programmer.
I agree. The confounding factor (I'm stating the obvious, I know) here is that it's hard to determine what makes a "programmer", whereas there is a very clear set of criteria for what makes a lawyer or doctor.
Although it's always tough to compare fields, I do think that some ways of measuring the skill set and educational requirements for a software developer do place it in one of the most rigorous fields out there.
Majoring in computer science at a reputable university (I don't mean an elite one, I just mean one that requires the standard curriculum) typically requires two years science and engineering track calculus (not the easier one year, slower paced track available to econ or bio majors at some universities). Physics is often a requirement, as is an additional year of upper division mathematics (differential equations, calculus based probability), along with some classes that intersect with mathematics had have a heavy computing component, such as numerical analysis which generally involves computational methods to solve mathematical problems that aren't amenable to closed form solutions, or mathematical algorithms that require so many iterations that they aren't practical to solve by hand, optimization, graph theory. Then you add in compilers, operating systems, and other demanding electives. And keep in mind, CS or other Math/Physics/Eng students typically must take a far more substantial general curriculum in humanities than humanities students must take in quantitive fields. We don't get out of writing papers the way they get out of difficult math.
People often point out that a field like law requires a three year grad degree, but honestly, in many ways, I think is is like comparing people who run at a 8 minute mile pace for 70 minutes vs people who run at a 6 minute mile pace for 40 minutes. You can't just compare the time spent, you have to compare the rigor of that time. Attrition rates for computer science are typically high even in elite schools, including at the graduate level (elite law schools, by contrast, often have attrition rates below one half of one percent, and many of the students come from fields like history or poly sci - nothing wrong with those fields, they are interesting, but they really don't have anywhere near the same attrition rates as CS or related majors). And if you do get a grad degree, then I'd say you've honestly gone through something much more difficult if you did it in Math/CS/Eng/PhysicalScience.
Of course, you don't have to strictly major in CS or a related field to be a programmer, but consider what it takes to get through the google interviews. Try out some of the medium to difficult questions from "cracking the coding interview", and think about the poise, communication skill, analytical ability, and coding ability it takes to do a good job on these question sin 45 minutes at a white board (as an unsuccessful google interviewee myself, I assure you you are expected to make substantial progress on these problems, and medium to difficult is surely fair game!) You could get to this through self-study or formal education, but either way, it most definitely is not a low barrier to entry.
Ok, not everyone works at google, and many of us work on crud apps. However, I have yet to see the mythical "simple crud app" that people refer to when they talk about how most programmers don't have hard jobs. These apps usually don't have deep algorithmic complexity, but they are hard to work with. You often inherit a difficult and poorly documented code base that you need to follow through, logically, with a fine toothed comb. You often have to get up to speed with a new framework, or an older one that uses deprecated methods during an era of substantial churn. You need to tease out often elaborate business logic and calculation pipelines from analysts or other non-technical workers that they have trouble communicating to you. And you of...
You are misinterpreting what the paper said and what I am saying in order to oil the axe you are grinding.
First, one can dispute “programming ability is distributed in two humps” without implying that “everyone can program.”
Second, your proposition isn’t even a consistent proposition. If programming talent really is rare, then being egalitarian won’t have any effect on wages: Some people can, some cannot, and the free market will quickly sort out that you cannot build pyramids with thousands of unskilled programmers.
If wages are stagnant, one possible explanation is that more people can program than you would care to admit. Which explains why you are ranting about spreading the myth that programming ability makes you a special, delicate flower. If you can socially engineer people into not becoming programmers, you believe there will be more money for you.
What you fail to realize is that as an industry, “a rising tide lifts all boats.” The more talented people there are, the larger the pie we get to share. More programmers equals more software, equals more tools, equals more companies, equals more hardware, equals more demand for software, and so it goes until software has finished eating the world and it becomes a mature, stagnant industry.
If you feel your wages are not rising as quickly as you like, perhaps you should look into other possible causes, such as a lack of skill in negotiation, or choosing to be an employee instead of an entrepreneur, or wage-fixing by companies with no-hire policies, or the practice of handing out paper stock options in lieu of cash for startup employees.
>First, one can dispute “programming ability is distributed in two humps” without implying that “everyone can program.”
Yes, but people are disputing “programming ability is distributed in two humps” despite there being clear evidence of that being the case, and no evidence to contradict it. The distribution has not changed, or been retracted. Only the unsupported notion that the distribution is innate and unchangable.
I did not ask you to explain anything. I said your explanation is not representative of what is happening. And the clear evidence is the paper in question. Read the "retraction". They do not suggest the bimodal distribution is incorrect, but that they should not have suggested it was inherent and unchangable, when the evidence does not support that.
His test is not a very good predictor: most of those who
appear to use a model in the pre-course test pass the end-of-course exam but so do many of those who do
not. And it doesn’t predict the level of performance, as we discovered when we tried some deeper statistical
analysis (Bornat et al., 2008). But the phenomenon is real and the prediction it makes is reproducible,
as Dehnadi showed in a meta-analysis in his thesis (Dehnadi, 2009). That meta-analysis is summarised
in (Dehnadi et al., 2009).
But that’s not all. It’s not enough to summarise the scientific result, because I wrote and web-circulated “The
camel has two humps” in 2006. That document was very misleading and, because web documents persist, it
continues to mislead to this day. I need to make an explicit retraction of much of what it claimed. Dehnadi
didn’t discover a programming aptitude test. He didn’t find a way of dividing programming sheep from
non-programming goats. We hadn’t shown that nature trumps nurture. He had, however, found a predictive
phenomenon, though he had no explanation of it.
How do you read these paragraphs, or what part of the retraction supports the "two humps" claim and how do you understand that claim?
I don't know how I could make it any clearer than what you quoted. What do you think "But the phenomenon is real and the prediction it makes is reproducible, as Dehnadi showed in a meta-analysis in his thesis" means? Or "We hadn’t shown that nature trumps nurture. He had, however, found a predictive phenomenon, though he had no explanation of it."?
> Programmers are far too egalitarian for our own good
The guild that is infamous for exalting the "leet", nurturing cliques, and projecting disdain towards n00bs, laypeople and "idiots" is too egalitarian?
> our increasing marginalization and stagnant wages are the inevitable consequences.
IMO, our increasing marginalization and stagnant wages are the consequences of programming being not that hard (as far as the general demands of the industry). Programming is not exceptional or arcane, it's just new and with tooling and pl advancements making it easier and easier to meet industry demands, it's only natural that wages will stagnate.
> it's taken for granted that not everyone can be a doctor, dentist, or lawyer.
I am pretty sure everyone could be a lawyer if they wanted to be. The couple of lawyers I have talked to about it say that it is all about hard work not smarts or any special skill.
I think that's an answer which has fallen victim to the spotlight problem. They've forgotten what it's like to not be a lawyer and thus think "anyone can do this". I often feel similarly about machine-learning, until I try to explain it to someone who has no background in the subject and realize all the things they don't know.
There are litterally dozens of millions of doctors.
In France we even have to artificially limit the number of doctors (numerus clausus).
The studies are really long and you have to be hard working but, still, they are easy enough that too many students would succeed without an artificial cap.
A doctor is as fairly well defined upper-echelon level of a particular skill path. A programmer is a generic term for someone who writes code. If there were a more general push for medical literacy, it would be entirely equivalent, and I would say justified, to say "You too can learn to give medical care!" If we had well defined titles for categories and skill levels for programming, the equivalent to "You too can be a doctor!" would be something like "You too can be a [senior lead on a complex software project]!".
Also, let's not forget that sometimes the truthfulness of the assertion takes a back-seat the the desired effect it will have. Very often we tell children "You can be a doctor" when at certain points we know the likelihood of that is very, very small (for any number of reasons, such as aptitude, circumstance or history). The urging may not make them become doctors, but if it makes them expand their ambition and try for a hard goal, the end result may well result in a better outcome for them, regardless of whether they indeed become doctors.
I don't know. I think the high intelligence of doctors has more to do with the fact that it's a very desirable occupation and so they can afford to only choose the best applicants for medical school, not because it inherently requires great intelligence.
I know several elderly and accomplished medical professors who claim that they would not have been accepted into medical school under today's conditions. They got in during a time when it was very much easier academically (but harder financially).
There is an agenda to please retain groups of people. But yeah, I don't think it's about logic, I think the situation has just become a symbolic issue for powerful groups that feel like they're doing the right thing.
Politics. Science is always better accepted when it conforms or is spun to conform to the current zeitgeist. So it with bad science, no science and pull out of someone's ass (pseudo) science.
And right now the zeitgeist in tech is to increase diversity.
By this rhetorical implication, you're saying that not only are current demographics in tech (majority male, white, upper middle class) that way because those demographics are more skilled than other demographics, but also that any studies implying as such as stomped out by political pseudoscience proposing less effective diversity measures.
And of course, I can't ask you for a source that studies are getting stomped out by political pseudoscience, because those sources will also have been stomped out. So I should instead ask you: how did you get this impression?
I do apologize. I didn't imply any privilege here and apologize if I came off as trying to treat this is a privilege perspective. My confusion comes from the rhetorical implication that current demographics in computer science are that way because those demographics are somehow just better at it than others, and also that any proof of this us stomped out by political pseudoscience. I'm asking where gp gets this impression.
I'm also curious what you mean by 'all studies should do so'. Do what, exactly? Analyze the demographic of white heterosexual upper middle class differently? I'm sure that might be interesting, but it's already a very specific demographic that fits class, sexuality, race, and gender identity. What other categories are being neglected that are skewing the view of demographic majorities in the technology industry?
I was explaining the OP why there is spin. And why spin is taking that shape.
And that was all there was to my post. But since you are playing Tipper Gore to my Dee Snider:
Why I get that impression - because science is also political. As are the people that do it, write for it, fund it and so on. We people are stupid, biased, and conformist. We fall in line. We do what will bring us money or social capital. We twist our reality to fit the desired outcome. We shred to pieces papers we disagree with, but only skim the one that confirm out initial assumption. We love to offer post facts justification how we were right all along.
I am from former communist country - I know how whipping science and arts to fit the party line is done. I have seen it.
In the west it is not different just subtler. People are more afraid of being on the wrong side of society, than being wrong.
That is how the world works.
And with tech powerhouses like Japan, China, Taiwan and South Korea and India that both produce, utilize domestically and export a lot of tech talent - I am not sure how white is tech.
>And with tech powerhouses like Japan, China, Taiwan and South Korea and India that both produce, utilize domestically and export a lot of tech talent - I am not sure how white is tech.
You're correct there. I was under the impression one would be focusing mostly in the oh so legendary Silicon valley.
Other than that, thanks for your generosity with your perspective. If I could have another question, what do you consider the warning signs of a psesudoscience or bad science being used for political gain? Also, how do you tell when a methodology is found flawed because of political gain vs a methodology is found flawed because it is flawed and in bad science?
Here is a thought experiment - lets publish two bogus papers. One that claims the holocaust victims are twice as high as the current accepted consensus, and one that claims that the victims are twice as low.
If science was apolitical they both would be laughed away.
My opinion is that in the real world - both will gain acceptance at the fringes, but while one of the papers will just be burried and ignored, the other will be career ending move and will be shredded, and careers will be launched disproving it.
Same will be with any paper that perpetuates the white dominance narative and tries to disprove it.
There are bigger penalties in going in one of the possible directions of the accepted truth.
So we have built in conformation and confirmation bias in system.
And the antivaxer paper is stellar example of using pseudoscience for political gain.
With diversity in tech - you lose nothing by spinning any fact into pro diversity argument.
>The title seems to intentionally misrepresent the retraction to push an agenda (or the author has some issues with basic logic)
Almost certainly the former. Notice the dismissal of scientific evidence because they dislike the implications. Every study on the subject has shown clear racial IQ differences. That is not "pseudo-science". Arguing about why that observation exists is fine, but pretending the observation itself must be wrong because it hurts ones feelings is not reasonable.
>The retraction is that the strong/definitive proof that "the camel has two humps" was fabricated/exaggerated.
It isn't even that. The bimodal distribution is very clearly there, the "retraction" is just to the claim that this is an innate characteristic. Something which was widely repeated, but which the actual paper never even claimed.
>The camel has gone back to having an unknown number of humps
It still has two humps, we just don't know why. But we never knew that in the first place.
Bipolar depression rapidly gives way to mania if you try to treat it like unipolar depression with standard antidepressants. The chances of this happening are greatly increased if you've never been diagnosed as bipolar. It happened to someone I know, and it was pretty ugly. The jackass behavior is an unfortunate part of the medical condition. It's common for the shame felt after coming down from a manic episode to throw you right back into depression. You can search for "ssri mania" if you want to learn more, it's a well-known phenomenon.
I'm going to second what possibility said. Bipolar depression is a very different animal from standard clinical depression. Mania is ugly, it turns someone you know into someone you don't.
Until recently we were living with a maniac who didn't need SSRIs to go manic. It is astonishing how ugly it gets, I've still got a broken mirror on the floor in the other room that we haven't cleaned up yet.
2. I still wonder why around 30% of people with programming experience who have applied to a job when I was recruiting couldn't solve FizzBuzz[1] or string reverse. All of them either University MSc or years of programming experience.
The article hints at using the wrong teaching methods.
[1] Given the written instructions: '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”.'
The problem is that Fizzbuzz and string reversing are a kind of trick questions. Either you have already done them or not. Good people will fail at trick questions very easily in interviews.
Since they don't represent real work and aren't statistically significant, why are we using them? They are merely adding random noise in the interview process.
Even a simple programming question can stump someone not trained in it. I've seen people who (supposedly) have computer science degrees fail on FizzBuzz.
In the end, it makes some sense to "talk shop" about programming issues. If they can't follow, it's probably not a good idea to hire them.
From this thread you'll find people that will reject someone with 10 years of experience because of failing Fizzbuzz in the conditions of an interview. It's not always used to talk shop. What I say is that there are things that are probably more statistically significant that questions with gotchas.
So? I've interviewed people with graduate Computer Science degrees who couldn't program a for {...} loop. Blew my mind, but it happened enough times that it doesn't surprise me any more.
Going to echo this sentiment: I think the only way FizzBuzz is a trick question is if you aren't familiar with the modulus operator, in which case I think it fair to say you haven't spent much time programming.
That being said, I'm assuming the failure mode we're discussing is 'flailing at the whiteboard and would never make any progress given infinite time' and not 'wrote an off-by-one error that a unit test would catch.'
Even if you've never heard of the modulus operator, it's still easy, eg in Python:
fizz = 3
buzz = 5
both = 15
for i in range(1, 101):
if i == both:
print "FizzBuzz"
both += 15
fizz += 3
buzz += 5
elif i == fizz:
print "Fizz"
fizz += 3
elif i == buzz:
print "Buzz"
buzz += 5
else:
print i
If you can't write your own modulo function if don't understand the fundamentals of integer/floating point operations. Or are unaware of ceil and floor functions.
And if the candidate trips up, this gives you an opportunity to walk through a virtual compile-debug-test cycle.
When I asked these kinds of questions I would execute the program in my head, and tell the candidate things like "your reverse() methods moves some stuff around, but the end result appears the same as before". Or "this fails with ArrayIndexOutOfBounds on line X". Typically it only took a few minutes to find the bug and fix it, and I learned about how the candidate solves problems.
> I find it unlikely that good people will fail to do string reversing if they haven't seen it before.
I've seen this for people that were hired and proved excellent.
Everyone can do Fizzbuzz or reverse a string on the job. Much less can do it correctly the first time, on a whiteboard, in a job interview.
When you hire a carpenter, you don't ask him to hit a nail with a plastic hammer while you watch.
Certainly you can learn Fizzbuzz and string reversing, meaning that you could be a false positive in the interview. Assuming that you are interviewing experienced devs and you use the test as a kicking-off point for discussing any errors rather than as an opportunity for calling the candidate an idiot, you are unlikely to hit false negatives.
Even in these circumstances I've had a decent proportion of candidates never able to even begin to outline some code, let alone get far enough in to enounter "tricks" or "pitfalls". These are candidates I'm comfortable assuming have not learned to code.
That blows my mind. I believe you it's more like what are people learning with these degrees?
I code for fun mostly and I feel like even my 'basic' level knowledge should be able to outline code for a simple problem like fizzbuzz or string reversal.
Go read up on the origins of FizzBuzz. It was intended to filter out the non-coders, despite what their resume might say. That was Spolksy's problem: BS in CS, resume otherwise looks good, get them in for a tech interview and they simply bomb.
Mind still blown? Yeah, well, it happens more than you think. Varying definitions for "SDET" are out there, but I think most would agree that an SDET should be able to code. I've had SDETs with Microsoft on their resume that couldn't even match curly braces, let alone write something that would compile and work.
So I use FizzBuzz or an equivalent. I tell the candidate up front that it should take them single digit minutes. I offer points for creativity if they find it too simple. And once in a while a candidate with ten years experience shows up who can't do it. Glad we didn't start with that red/black tree implementation, then.
It is crazy, and thankfully not all that common. But I've observed it often enough to never trust a resume. Granted, far more often with SDETs[0] than "regular" devs, but I've seen a few of the latter that would struggle with or outright fail FizzBuzz. The craziest part, though, is that most worked someplace else previously. Did they outright lie about previous roles? I wouldn't believe they lied, but I'm certain they blatantly exaggerated.
[0] Why more common with SDETs? My theory is that SDET is easier to fake, and if your SDET "development" consists of var foo=FindUIElement("bar");foo.click(), then FizzBuzz could give you trouble.
So I work right now supporting a recruiting team with technology project management/data analysis and I can definitely agree with never trusting a resume. I've learned most of the time people don't actually know they're exaggerating, they tend to be unaware of how limited their skill set is.
When presented with a trivial programming task in an interview, I'm partly questioning whether there's something deeper I'm missing or if it's a basic challenge like "did you ever write any code yourself?". That's why some might perceive it as a trick question.
In my experience if a tech hiring person is playing with "trick" questions during an interview you should very quickly start wondering if this would be a place you really need to work.
Yes this happens, some developers overthink things and think meta then meta then meta. This makes it especially tricky to do surveys ("what does the question really mean?") with developers from my experience.
When this happens to me, people in the interview tell me something like "This is easy, are there strings attached I can't see?"
It's because some interviews try to have you solve hard problems, expecting you to have a solution ready in 5 minutes, whereas in the real world you'd consult literature for that.
Whatever happened to, "he seem to be able to code, let's try it for a couple weeks"?
Happened to me twice where everything was fine and then after having been interviewed by 5 or more people, one of them has a bad feeling, and you're not given a chance to prove yourself in a probationary period. Situations like that made me wonder if freelancing is a better path.
Never had cause to reverse a string but have needed to reverse an array. Never had cause to do something like fizzbuzz but have needed modular operator (actually both in the same function) but if I had never had reason to validate barcodes of differing lengths and validate the check-bit, I would probably fail on fizzbuzz too. In fact I probably would fail today if asked, who has time to remember something that useless, and that easy to look up?
Fizzbuzz or string reverse aren't something to remember. They are small logic puzzles that programmers should be able to easily figure out in an interview, even if they have never heard of them. Unless, perhaps, the candidate gets so stressed that they lock up and fail to think straight, which is of course totally plausible.
I would like to learn and understand how you think you would fail on FizzBuzz if you get these instructions [1]:
'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”.'
[1] if stuck on modulo I usually suggest to assume there is a function divisible
I have a terrible memory and struggle to be confident, I would probably just not manage to write anything under interview conditions. When I first learned about fizzbuzz I did it and wondered what all the fuss was about, it's not a complicated logic puzzle, just that I'm used to writing code while connected to the Internet, my brain simply doesn't try to remember things I know I can look up in 1 second.
I disagree. What's tricky about a naive solution for FizzBuzz? The only argument I could think of is "well it uses modulo which isn't all that standard". Not knowing modulo (or "how do I check if a number can be divided by another number") is a very bad sign (imo)...the rest is printing stuff, branching, a loop, methods/functions and getting a program to run (+maybe TDD). Those are all rather fundamental building blocks.
Not sure how FizzBuzz is a 'trick question'. Given these instructions at an interview:
'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”.'
It spells out in words what needs to be written in code.
String reverse is: Write a method/function that returns the reverse of it's argument. Would be interested to learn how these are trick questions.
If the solution is fine, I ask were they see problems. Some mention UTF-8/16. I'm happy if someone tells me this is tricky and there is a working solution in library X or they would google for a solution that works with UTF-8/16.
If you're a programmer, you can write FizzBuzz. Whenever I do a first technical screen, I always start with FizzBuzz - explicitly telling the interviewee it's just to warm them in before we get to the real stuff. No trick there.
>The problem is that Fizzbuzz and string reversing are a kind of trick questions.
They are the exact opposite. They are practical, very simple, introductory questions. Fizzbuzz is literally "do you know what a loop and a conditional are?".
String reversal at least involves a backwards loop, which isn't that hard, but you don't use often in practice. I'd guess there are 10x as many for-of loops as for i = 0...loops in our codebase, and 10x as many for i = 0...loops as backwards loops in our code base. I think Swift may be removing C-style for loops, even (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...). Of course you can still express it using a while-loop, but this reflects the frequency of certain types of code.
On the one hand, I'm tempted to say everyone should be able to do that, on the other hand, they do feel like a type of programming that isn't super common in a lot of applications. FizzBuzz is probably a bit better in that regard.
Not necessarily a backwards loop, it can be done just fine with a simple recursion too. If a candidate can't do either, well, this is a task explicitly to weed out those candidates.
Seriously? The sum total of my undergrad programming experience was a Fortran/Matlab course and I was able to write a FizzBuzz implementation when I first heard about it. As an outsider, the idea of a professional programmer not being able to write a FizzBuzz implementation sounds as ridiculous as a pharmacist who couldn't tell you what sudafed was for or a mechanic who couldn't replace an oil filter.
It's perspective. By the end of interviewing 6 or 7 people, YOU know those questions and all the paths to answers cold. You not only know the questions and answers, you know all the ways thinking about those problems is connected to other problems. So, WHO could possibly not know that? Possibly you, before you put together your list of interview tech questions.
.. but these two always come up as suggestions. So much so that anyone googling "what questions to expect during a programming interview" ought to be able to come up with canned answers to them.
A priori you might expect to find that there were lots of candidates who could do string reversal and fizzbuzz but nothing else. This doesn't seem to be the case.
That's right. Mostly they test whether people have taken the time to prep for an interview. That has some value, but maybe not the value the interviewers intended.
I like the kinds of interviews where you assign a coding problem before the interview and review the code, or where debugging is part of the tech interview.
So you think given the instructions in an interview:
'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”.'
people should not be able to write the code? Just by hearing the answer 6 to 7 times ("By the end of interviewing 6 or 7 people") someone knows the answer?
"Possibly you, before you put together your list of interview tech questions."
No actually given the instructions I could write the code in one go. So I'm mystified as why someone applying to a developer position could not do this in your opinion.
[0] has quite interesting discussion about the FizzBuzz exercise.
It feels a little like a window to the programmers mind. Some of them are disturbed by the simple repetition and come up with obfuscated or infective solutions etc.
How do you ask people to "solve FizzBuzz" and how do you know they've solved it?
I'm asking because if you do a whiteboard test then it's easy enough to get things wrong on both sides of the interview. Humans are just not as accurate as compilers, not even for the simplest of things.
Besides that there's always nerves, misunderstandings, cultural differences etc. In one place I interviewed they asked me to write a factorial method in Java. I assumed they wanted a recursive method, because, factorial, right? Classic recursive example. So I gave them a recursive factorial in Whiteboard Java™. I turned around from the whiteboard to see the interviewers staring at me, their mouths hanging open. And not in a good way. It turns out all they wanted was to see if I could write a simple loop. Instead of marvelling at my amazing recursion powers, they got the impression I was needlessly flashy and probably had my head up my arse. Also, seeing them staring I completely panicked and I totally screwed the iterative version: the loop went up instead of down, I was adding where I should be multiplying... a shambles.
So they didn't hire me.
Shit happens in interviews and it's not because "Johnny can't program". It's because "Johnny can't pass a programmign interview" (or at least many of them).
I usually do them online with an editor like etherpad.
I tell people they can use the language I hire (Ruby,JS,Java) but I'm fine with other languages or pseudo code.
I tell people I don't care about semicolons or braces, I don't hire them for being a compiler.
Factorial I also use sometimes. Recursive is fine with me if it works, I've seen many people to go the recursive way - hey it's factorial - and then screw up. I sometimes ask people to do an iterative solution, or I ask if the recursion went flawless to write it as tail recursion.
Compilers don't just catch syntax errors though - they also show up logic errors, that may be too subtle to see on a whiteboard. That's true even with very simple programs.
You can definitely step through your program by hand and follow the logic etc, and you should totally be able to do that, but most programmers will not be in the habit of doing this. And neither should they, because it's slow, tedious and error-prone to hand-simulate your algorithms, or even just your for-loops. Not to mention recursive, or larger stuff.
I guess what I'm saying is that programmers are used to "lean on the compiler" and you don't have that on a whiteboard exercise, so it's a bit artificial.
[Full disclosure: I'm in the habit of hand-simming my stuff especially in the last year where I've been developing a grammar induction algorithm, so I'm not worried that I'll have to stand on a whiteboard and not know how to step through a loop, but I still think it's not very useful to make people do that).
They were expecting an iterative solution, so giving them a recursive one came across as a bit snotty. As it should.
What language did you do your high-school level stuff in? I assume it wasn't Java, because in Java there are no good reasons to use recursion (it provides iterative primitives, unlike say Haskell, Prolog, Lisp etc) and there are good reasons not to (its compiler doesn't (or didn't) do tail-call optimisation).
Not to mention, any language without pattern matching is a bit shit for teaching recursion anyway: you tend to miss the point because of all the bookkeeping.
Pascal and lisp-like language that was created for teaching purposes in our school. Still, recursion was among the first procedural programming topics, right after procedures themselves, if I remember correctly.
Pascal and lisp-like? What school was that, or rather -when was that?
Recursion is generally considered hard by most programmers, hence why my interviewers thought I was showing off. You can google a bit and see that people do indeed have trouble getting their heads around it.
>2. I still wonder why around 30% of people with programming experience who have applied to a job when I was recruiting couldn't solve FizzBuzz[1] or string reverse. All of them either University MSc or years of programming experience.
take a world 100m running champion and ask him to run the 30m with making 360 deg rotation left on each 3rd step and rotation 360 deg right on each 5th step... That would be such a fun, like a drunken duck...
This retraction shows we have to be extra critical of things that reinforce our beliefs. Working as a programmer, it can be easy to believe that some people just aren't cut out for it. That doesn't mean a publication written using official-sounding words and methods that happens to match this belief is true at all.
But the retraction is super terrible. Imagine someone writes an article which makes a lot of sense, now that person writes a retraction which simply says "oh I was in great mental and psychological trouble when I wrote that".
No, if you want to retract it, then make a case why this is not true. We don't believe that article because we trust the author.
Did you look at the actual retraction? It explains what the original data demonstrated and references further work by him, his student, and other researchers that helps show what the test can and can't show.
I have a really good way of separating candidates into those who will be successful and those who won't - During the interview I ask how they became interested in computer science, programming, etc as well as asking them to provide information on "pet projects" or other significant work they've accomplished.
If someone describes staying up all night as a 13 year-old because they had to finish the code they were working on, that's someone who was passionate about programming before they found out it's one of the better paying professions.
If someone points to finished projects (especially side projects or OSS), then they also have the ability to focus. If someone points to a bunch of barely started projects, they might have great ideas but in a business you also need to execute.
So ... passion and focus, plus a reasonable amount of domain knowledge will make a great employee.
How do you know your method works? Have you compared it side-by-side with other methods, including a control where you decide to hire or not completely at random?
If someone describes staying up all night as a 13 year-old
So, you're explicitly selecting by class background and upbringing? This particular metric also tends to select against women, if you have any applying.
I know a lot of women who were up all night at 13 years old to write code they just had to finish. Gender bias is about those people getting passed over for jobs, not code-boot-camp churn-outs.
I never said everyone not meeting this "rule of thumb" should be discarded ... And the hypothetical 13 year-old was only one example of "displaying passion".
Not just class, but age. Those of us who grew up in the 70s or 80s were much less likely to have a PC in the house as a child. High-speed internet wasn't commonly available until I entered college (and even then, it wasn't something found in homes - just offices and colleges).
I can remember on two occasions bosses of mine who helped kids with some form of homework assignment. If your dad (or mum) isn't technical then you are less likely to get an early start.
"If someone points to a bunch of barely started projects, they might have great ideas but in a business you also need to execute."
I'm not disagreeing, because I agree that side projects show passion, but I'm not sure a lack of side projects necessarily points to a worse employee. Someone could be a great developer in an enterprise environment, from where they obviously wouldn't be able to show you code snippets, but have no side projects because they might have other hobbies.
Ironic, since the "people clinging to it" seem to have read and understood the retraction and you seem to be repeating a deliberately misleading headline. The two humps are still there, the retraction was only of the claimed innateness of this distribution, not of the distribution observed.
Perhaps the people in these comments have had many programming experiences working with people who have great trouble coding, no matter how patiently we explain something to them. As a result, programming workplaces are often structured so one 3x programmer looks after a group of -0.5x programmers, cleaning up after them, while another group of 2x programmers are siloed off doing some real work, unencumbered by any -0.5x programmers and not threatened by the 3x programmer. This is the double hump in action.
Despite working in these types of place, I still got a shock, though, when I started doing freebie work on open source software and worked out that such an aptitude-less programmer was managing a large open source project developing a programming language. Perhaps some people doubting the double hump are from places like Google where all engineers are vetted via Computer Sciences degrees, and they don't have repeated everyday experience of it.
Psychologists would reject any kind of test that doesn't come out as more or less normally distributed out of hand. A common complaint about oddball tests such as the Meyers-Briggs test or Hubbard's OCA is that they have not been validated to "behave well".
This may well be to due the fact that psychologists have been using parametric statistics instead of nonparametric statistics. In a lot of cases us nonparametric types have given up a little statistical power for "cheap and cheerful" methods that are harder to get wrong.
Psychs and medicals find it very expensive to treat thousands and thousands of patients correctly and carefully observe the results. This is why those Cochrane reviews for the case for almost any drug or other treatment are so depressing -- maybe they need all the statistical power they can get.
I think you have that wrong. One major criticism of Meyers-Briggs is that it measures things that are normally distributed, and assigns them categories.
For an easy example of why (if true) this would be a valid criticism, consider IQ, which is normally distributed. I will give you an IQ test and assign you into one of two categories: smart or dumb. If you are below the median, you're dumb, if you're above the median, your smart.
It should be obvious why this makes little sense; the large number of people very close to the median are divided in two and put in the same category of those with either very low or very high IQs.
To assign people to one of two categories, one would want to see a distinct bimodal distribution, then there would be a small number of people for whom which distribution they belong to is ambiguous, and the majority could be confidently assigned to one or the other.
>All teachers of programming find that their results display a 'double hump'. It is as if there are two populations: those who can [program], and those who cannot [program], each with its own independent bell curve. 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. None of it works, and the double hump persists. We have a test which picks out the population that can program, before the course begins. We can pick apart the double hump. 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.
>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 can't learn to program: between 30% and 60% of every university computer science department's 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.
emphasis:All teachers of programming find that their results display a 'double hump'. It is as if there are two population
emphasis: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
So the disparity has presented itself in all known historical forms of pedagogy. Some have learned while others haven't, some have even learned with entirely self-directed pedagogy.
When a array of teachers has been giving it their all for decades but the disparity remains, should we really blame the teachers?
I agree, in that I think there is always room for improvement.
What I think needs to be criticized is a tendency to go on these wild goose chases searching for a magic factor that will explain everything, when there are other obvious factors nearly staring us in the face that we don't want to address.
So, this discussion reminds me a lot of discussions in logic programmig circles about why so many programmers can't learn to program in Prolog, no matter what. There's papers dedicated to the question, people who had done research on the question back in the '90s when Prolog was still popular (yeah, it was, google it). The verdict: no verdict. Some few special and magical people seem to be able to learn to program in Prolog, but the majority can't.
Well then, why not set the bar for who can program and who can't on who can code in Prolog, rather than who can write FizzBuzz? If the point is to sort out the men from the goats, or whatever uncle Joel said we're trying to sort out, surely using Prolog as the sorting tool would leave many, many fewer "real programmers" than FizzBuzz. Hell, we could even combine the two: FizzBuzz in Prolog! See how well you can do at that, internets!
And why stop at Prolog? There's languages that are way, way harder to program in! Hey, if you're a Real Programmer you should be able to write FizzBuzz in, dunno, Ook. Brainfuck. Leboge? Mondrian? Perl, even?
Or maybe, I don't know, we can start asking people to show us what they can do instead of trying to find things they can't? Does that make sense to anyone else? I'd personally love it if people who want to hire me took the time to check out my github and the git repository I'm serving off my public server, in order to get an idea of the things I have already done (and so demonstrably can do) rather than trying to catch me with my pants down in front of a whiteboard.
Look. I write a lot of code. I go over a lot of code I've written. I'm an idiot 80% of the time, but the other 20% of the time I figure it out, fix my bugs and go to town. It works, OK? If interviews can't appreciate this balance then they 're useless.
I think that people are completely misinterpreting the article and the retraction in this thread, whether willingly or not.
I don't think anyone is seriously questioning the fact that some people have more aptitude or intelligence than others. That's pretty commonly accepted fact. However, the general belief is that intelligence follows a roughly Gaussian (bell curve) distribution, and that it's roughly continuous. Mechanistically, one can imagine that intelligence is a convolution of genetic and other factors that are so thoroughly mixed that there are no discrete steps.
The theory behind a two-humped camel model of aptitude or intelligence would then be that some magic x-factor is so significant that it splits the underlying distribution in two, into the "cans" and the "can nots".
While the existence of such an x-factor would be a really interesting finding, it wouldn't change the underlying fact that some people have more innate ability to program than others, just like some people have more innate ability to be doctors or lawyers or concert pianists than others. It would just tend to make that difference much starker.
What it also wouldn't change is the fact that innate ability doesn't always correlate to success in a given career, or in life. Many other factors other than innate ability, such as drive and ability to collaborate with others, affect whether someone is going to be successful at their job. Also, people can learn. Even someone who doesn't have innate talent can become very skilled, if they work really hard at it.
So, even if the study were valid, which it's not, the finding itself is more of an academic interest than an excuse to start treating coding job interviews as a "sword in the stone" test of whether you've got "it" or not.
So, this article talks about the retraction of the 2006 paper, which the authors admitted had some failings.
However, I fail to see much discussion about the subsequent paper [1] that addressed these failings and featured improved experiments that seem to still uphold the hypothesis.
135 comments
[ 3.0 ms ] story [ 233 ms ] threadThe retraction is that the strong/definitive proof that "the camel has two humps" was fabricated/exaggerated.
The converse - that it has one hump hasn't been proven. From the quote, Richard Bornat doesn't say that they re-crunched the numbers and now there is proof of one hump.
The camel has gone back to having an unknown number of humps
Some sources even go as far as saying there is no camel involved at all, and might have never been.
Or “It follows a distribution similar to other skills involving mathematics.”
The paper presented an unusual hypotheses, that there was this sharp distinction between those who can program and those who never will, and that this distinction was somewhat orthogonal to other measures of scholarship. So for example, one might be a good architect but never get good at programming no matter how much one tried.
You’re right we haven’t disproven this hypothesis, but given its novelty, the burden of proof is on "the camel has two humps." With the paper retracted, we do not presume it has an unknown number of humps, we presume that skill writing programs is going to be similar to other skills we observe.
As this article observes, unusual outcomes in attempting to teach programming may just as easily be explained by the fact that in a young field, we may not know how to teach programming.
If we’re going to chase ‘humps,’ perhaps we should look for unusual distributions in the skill of teaching programming. We may be terrible at it, and perhaps the skill we are really observing is the skill of learning to program in spite of didactic and structural obstacles.
It is anecdotal evidence, but there are people with innate ability.
Also - natural distribution makes the one hump camel the default hypothesis.
Still, I'd assume that with programming like I assume for most skills (music, athletics, lawyering, foreign language, whatever), some people start out with more aptitude than others, and find it easier than the others. I wouldn't assume it's a markedly more pronounced or separated distribution in CS/programming than for other things though.
(Also, I have actually been programming since I was 12, and additionally believe I do have some aptitude for it that makes it easier for me than for some others, I'm pretty good at it -- and I still remember how hard it was for me to understand pointers in Pascal when I first learned them, which seem so straightforward to me now I have no idea why it was challenging at first! And I'm glad I had good teachers in formal coursework.)
The concept itself still sounds trivial to me though.
Programmers are far too egalitarian for our own good and our increasing marginalization and stagnant wages are the inevitable consequences.
Although it's always tough to compare fields, I do think that some ways of measuring the skill set and educational requirements for a software developer do place it in one of the most rigorous fields out there.
Majoring in computer science at a reputable university (I don't mean an elite one, I just mean one that requires the standard curriculum) typically requires two years science and engineering track calculus (not the easier one year, slower paced track available to econ or bio majors at some universities). Physics is often a requirement, as is an additional year of upper division mathematics (differential equations, calculus based probability), along with some classes that intersect with mathematics had have a heavy computing component, such as numerical analysis which generally involves computational methods to solve mathematical problems that aren't amenable to closed form solutions, or mathematical algorithms that require so many iterations that they aren't practical to solve by hand, optimization, graph theory. Then you add in compilers, operating systems, and other demanding electives. And keep in mind, CS or other Math/Physics/Eng students typically must take a far more substantial general curriculum in humanities than humanities students must take in quantitive fields. We don't get out of writing papers the way they get out of difficult math.
People often point out that a field like law requires a three year grad degree, but honestly, in many ways, I think is is like comparing people who run at a 8 minute mile pace for 70 minutes vs people who run at a 6 minute mile pace for 40 minutes. You can't just compare the time spent, you have to compare the rigor of that time. Attrition rates for computer science are typically high even in elite schools, including at the graduate level (elite law schools, by contrast, often have attrition rates below one half of one percent, and many of the students come from fields like history or poly sci - nothing wrong with those fields, they are interesting, but they really don't have anywhere near the same attrition rates as CS or related majors). And if you do get a grad degree, then I'd say you've honestly gone through something much more difficult if you did it in Math/CS/Eng/PhysicalScience.
Of course, you don't have to strictly major in CS or a related field to be a programmer, but consider what it takes to get through the google interviews. Try out some of the medium to difficult questions from "cracking the coding interview", and think about the poise, communication skill, analytical ability, and coding ability it takes to do a good job on these question sin 45 minutes at a white board (as an unsuccessful google interviewee myself, I assure you you are expected to make substantial progress on these problems, and medium to difficult is surely fair game!) You could get to this through self-study or formal education, but either way, it most definitely is not a low barrier to entry.
Ok, not everyone works at google, and many of us work on crud apps. However, I have yet to see the mythical "simple crud app" that people refer to when they talk about how most programmers don't have hard jobs. These apps usually don't have deep algorithmic complexity, but they are hard to work with. You often inherit a difficult and poorly documented code base that you need to follow through, logically, with a fine toothed comb. You often have to get up to speed with a new framework, or an older one that uses deprecated methods during an era of substantial churn. You need to tease out often elaborate business logic and calculation pipelines from analysts or other non-technical workers that they have trouble communicating to you. And you of...
First, one can dispute “programming ability is distributed in two humps” without implying that “everyone can program.”
Second, your proposition isn’t even a consistent proposition. If programming talent really is rare, then being egalitarian won’t have any effect on wages: Some people can, some cannot, and the free market will quickly sort out that you cannot build pyramids with thousands of unskilled programmers.
If wages are stagnant, one possible explanation is that more people can program than you would care to admit. Which explains why you are ranting about spreading the myth that programming ability makes you a special, delicate flower. If you can socially engineer people into not becoming programmers, you believe there will be more money for you.
What you fail to realize is that as an industry, “a rising tide lifts all boats.” The more talented people there are, the larger the pie we get to share. More programmers equals more software, equals more tools, equals more companies, equals more hardware, equals more demand for software, and so it goes until software has finished eating the world and it becomes a mature, stagnant industry.
If you feel your wages are not rising as quickly as you like, perhaps you should look into other possible causes, such as a lack of skill in negotiation, or choosing to be an employee instead of an entrepreneur, or wage-fixing by companies with no-hire policies, or the practice of handing out paper stock options in lieu of cash for startup employees.
Yes, but people are disputing “programming ability is distributed in two humps” despite there being clear evidence of that being the case, and no evidence to contradict it. The distribution has not changed, or been retracted. Only the unsupported notion that the distribution is innate and unchangable.
Please cite this "clear evidence" you speak of.
But that’s not all. It’s not enough to summarise the scientific result, because I wrote and web-circulated “The camel has two humps” in 2006. That document was very misleading and, because web documents persist, it continues to mislead to this day. I need to make an explicit retraction of much of what it claimed. Dehnadi didn’t discover a programming aptitude test. He didn’t find a way of dividing programming sheep from non-programming goats. We hadn’t shown that nature trumps nurture. He had, however, found a predictive phenomenon, though he had no explanation of it.
How do you read these paragraphs, or what part of the retraction supports the "two humps" claim and how do you understand that claim?
The guild that is infamous for exalting the "leet", nurturing cliques, and projecting disdain towards n00bs, laypeople and "idiots" is too egalitarian?
> our increasing marginalization and stagnant wages are the inevitable consequences.
IMO, our increasing marginalization and stagnant wages are the consequences of programming being not that hard (as far as the general demands of the industry). Programming is not exceptional or arcane, it's just new and with tooling and pl advancements making it easier and easier to meet industry demands, it's only natural that wages will stagnate.
I am pretty sure everyone could be a lawyer if they wanted to be. The couple of lawyers I have talked to about it say that it is all about hard work not smarts or any special skill.
Also, let's not forget that sometimes the truthfulness of the assertion takes a back-seat the the desired effect it will have. Very often we tell children "You can be a doctor" when at certain points we know the likelihood of that is very, very small (for any number of reasons, such as aptitude, circumstance or history). The urging may not make them become doctors, but if it makes them expand their ambition and try for a hard goal, the end result may well result in a better outcome for them, regardless of whether they indeed become doctors.
I know several elderly and accomplished medical professors who claim that they would not have been accepted into medical school under today's conditions. They got in during a time when it was very much easier academically (but harder financially).
The hypothesis there was that time spent on assignments and grade obtained are two essentially independent variables.
[1] http://www.joelonsoftware.com/articles/HighNotes.html
And right now the zeitgeist in tech is to increase diversity.
You don't want to be the subject of the next Two Minutes Hate?
And of course, I can't ask you for a source that studies are getting stomped out by political pseudoscience, because those sources will also have been stomped out. So I should instead ask you: how did you get this impression?
In fact, all studies should do so to avoid endless blathering on the Internet.
I'm also curious what you mean by 'all studies should do so'. Do what, exactly? Analyze the demographic of white heterosexual upper middle class differently? I'm sure that might be interesting, but it's already a very specific demographic that fits class, sexuality, race, and gender identity. What other categories are being neglected that are skewing the view of demographic majorities in the technology industry?
And that was all there was to my post. But since you are playing Tipper Gore to my Dee Snider:
Why I get that impression - because science is also political. As are the people that do it, write for it, fund it and so on. We people are stupid, biased, and conformist. We fall in line. We do what will bring us money or social capital. We twist our reality to fit the desired outcome. We shred to pieces papers we disagree with, but only skim the one that confirm out initial assumption. We love to offer post facts justification how we were right all along.
I am from former communist country - I know how whipping science and arts to fit the party line is done. I have seen it.
In the west it is not different just subtler. People are more afraid of being on the wrong side of society, than being wrong.
That is how the world works.
And with tech powerhouses like Japan, China, Taiwan and South Korea and India that both produce, utilize domestically and export a lot of tech talent - I am not sure how white is tech.
You're correct there. I was under the impression one would be focusing mostly in the oh so legendary Silicon valley.
Other than that, thanks for your generosity with your perspective. If I could have another question, what do you consider the warning signs of a psesudoscience or bad science being used for political gain? Also, how do you tell when a methodology is found flawed because of political gain vs a methodology is found flawed because it is flawed and in bad science?
If science was apolitical they both would be laughed away.
My opinion is that in the real world - both will gain acceptance at the fringes, but while one of the papers will just be burried and ignored, the other will be career ending move and will be shredded, and careers will be launched disproving it.
Same will be with any paper that perpetuates the white dominance narative and tries to disprove it.
There are bigger penalties in going in one of the possible directions of the accepted truth.
So we have built in conformation and confirmation bias in system.
And the antivaxer paper is stellar example of using pseudoscience for political gain.
With diversity in tech - you lose nothing by spinning any fact into pro diversity argument.
That isn't even the current demographic. Indian and Chinese people are more disproportionately represented than white people are.
I'd be really surprised if that was the case and I'd like to see your data, please.
Camel has gone back to be assumed to be typical gaussian camel as for many camels we don't know much about.
Almost certainly the former. Notice the dismissal of scientific evidence because they dislike the implications. Every study on the subject has shown clear racial IQ differences. That is not "pseudo-science". Arguing about why that observation exists is fine, but pretending the observation itself must be wrong because it hurts ones feelings is not reasonable.
>The retraction is that the strong/definitive proof that "the camel has two humps" was fabricated/exaggerated.
It isn't even that. The bimodal distribution is very clearly there, the "retraction" is just to the claim that this is an innate characteristic. Something which was widely repeated, but which the actual paper never even claimed.
>The camel has gone back to having an unknown number of humps
It still has two humps, we just don't know why. But we never knew that in the first place.
http://webcache.googleusercontent.com/search?q=cache%3Aretra...
2. I still wonder why around 30% of people with programming experience who have applied to a job when I was recruiting couldn't solve FizzBuzz[1] or string reverse. All of them either University MSc or years of programming experience.
The article hints at using the wrong teaching methods.
[1] Given the written instructions: '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”.'
The "trick" is the first hump - a goat.
Even a simple programming question can stump someone not trained in it. I've seen people who (supposedly) have computer science degrees fail on FizzBuzz.
In the end, it makes some sense to "talk shop" about programming issues. If they can't follow, it's probably not a good idea to hire them.
That being said, I'm assuming the failure mode we're discussing is 'flailing at the whiteboard and would never make any progress given infinite time' and not 'wrote an off-by-one error that a unit test would catch.'
string reversing in place trick: stopping at the middle else it's an identity function.
Any time you spend with Fizzbuzz, you could spend it on more complete quizzes, discussing past experiences, taking references etc.
When I asked these kinds of questions I would execute the program in my head, and tell the candidate things like "your reverse() methods moves some stuff around, but the end result appears the same as before". Or "this fails with ArrayIndexOutOfBounds on line X". Typically it only took a few minutes to find the bug and fix it, and I learned about how the candidate solves problems.
I find it much more likely that the fizzbuzz failers are the students who wanted to copy my programming projects in undergrad.
I've seen this for people that were hired and proved excellent.
Everyone can do Fizzbuzz or reverse a string on the job. Much less can do it correctly the first time, on a whiteboard, in a job interview. When you hire a carpenter, you don't ask him to hit a nail with a plastic hammer while you watch.
Even in these circumstances I've had a decent proportion of candidates never able to even begin to outline some code, let alone get far enough in to enounter "tricks" or "pitfalls". These are candidates I'm comfortable assuming have not learned to code.
I code for fun mostly and I feel like even my 'basic' level knowledge should be able to outline code for a simple problem like fizzbuzz or string reversal.
Mind still blown? Yeah, well, it happens more than you think. Varying definitions for "SDET" are out there, but I think most would agree that an SDET should be able to code. I've had SDETs with Microsoft on their resume that couldn't even match curly braces, let alone write something that would compile and work.
So I use FizzBuzz or an equivalent. I tell the candidate up front that it should take them single digit minutes. I offer points for creativity if they find it too simple. And once in a while a candidate with ten years experience shows up who can't do it. Glad we didn't start with that red/black tree implementation, then.
[0] Why more common with SDETs? My theory is that SDET is easier to fake, and if your SDET "development" consists of var foo=FindUIElement("bar");foo.click(), then FizzBuzz could give you trouble.
Same here.
When this happens to me, people in the interview tell me something like "This is easy, are there strings attached I can't see?"
Whatever happened to, "he seem to be able to code, let's try it for a couple weeks"?
Happened to me twice where everything was fine and then after having been interviewed by 5 or more people, one of them has a bad feeling, and you're not given a chance to prove yourself in a probationary period. Situations like that made me wonder if freelancing is a better path.
'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”.'
[1] if stuck on modulo I usually suggest to assume there is a function divisible
How can you expect to be a professional software developer if you can't get some specs, then develop a solution?
If someone perceives "FizzBuzz" to be a "trick" question, he's exactly the kind of person FizzBuzz question should weed out as fast as possible.
'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”.'
It spells out in words what needs to be written in code.
String reverse is: Write a method/function that returns the reverse of it's argument. Would be interested to learn how these are trick questions.
If the solution is fine, I ask were they see problems. Some mention UTF-8/16. I'm happy if someone tells me this is tricky and there is a working solution in library X or they would google for a solution that works with UTF-8/16.
They are the exact opposite. They are practical, very simple, introductory questions. Fizzbuzz is literally "do you know what a loop and a conditional are?".
On the one hand, I'm tempted to say everyone should be able to do that, on the other hand, they do feel like a type of programming that isn't super common in a lot of applications. FizzBuzz is probably a bit better in that regard.
Programming is all about abstraction. And fizzbuzz is an abstraction of a huge range of programming work.
Namely:
go through this data
pull out bits, based on these conditions
then do something with it
Some version of that underlies the vast majority of programming work.
A priori you might expect to find that there were lots of candidates who could do string reversal and fizzbuzz but nothing else. This doesn't seem to be the case.
I like the kinds of interviews where you assign a coding problem before the interview and review the code, or where debugging is part of the tech interview.
'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”.'
people should not be able to write the code? Just by hearing the answer 6 to 7 times ("By the end of interviewing 6 or 7 people") someone knows the answer?
"Possibly you, before you put together your list of interview tech questions."
No actually given the instructions I could write the code in one go. So I'm mystified as why someone applying to a developer position could not do this in your opinion.
It feels a little like a window to the programmers mind. Some of them are disturbed by the simple repetition and come up with obfuscated or infective solutions etc.
[0] http://c2.com/cgi/wiki?FizzBuzzTest
I'm asking because if you do a whiteboard test then it's easy enough to get things wrong on both sides of the interview. Humans are just not as accurate as compilers, not even for the simplest of things.
Besides that there's always nerves, misunderstandings, cultural differences etc. In one place I interviewed they asked me to write a factorial method in Java. I assumed they wanted a recursive method, because, factorial, right? Classic recursive example. So I gave them a recursive factorial in Whiteboard Java™. I turned around from the whiteboard to see the interviewers staring at me, their mouths hanging open. And not in a good way. It turns out all they wanted was to see if I could write a simple loop. Instead of marvelling at my amazing recursion powers, they got the impression I was needlessly flashy and probably had my head up my arse. Also, seeing them staring I completely panicked and I totally screwed the iterative version: the loop went up instead of down, I was adding where I should be multiplying... a shambles.
So they didn't hire me.
Shit happens in interviews and it's not because "Johnny can't program". It's because "Johnny can't pass a programmign interview" (or at least many of them).
I tell people they can use the language I hire (Ruby,JS,Java) but I'm fine with other languages or pseudo code.
I tell people I don't care about semicolons or braces, I don't hire them for being a compiler.
Factorial I also use sometimes. Recursive is fine with me if it works, I've seen many people to go the recursive way - hey it's factorial - and then screw up. I sometimes ask people to do an iterative solution, or I ask if the recursion went flawless to write it as tail recursion.
You can definitely step through your program by hand and follow the logic etc, and you should totally be able to do that, but most programmers will not be in the habit of doing this. And neither should they, because it's slow, tedious and error-prone to hand-simulate your algorithms, or even just your for-loops. Not to mention recursive, or larger stuff.
I guess what I'm saying is that programmers are used to "lean on the compiler" and you don't have that on a whiteboard exercise, so it's a bit artificial.
[Full disclosure: I'm in the habit of hand-simming my stuff especially in the last year where I've been developing a grammar induction algorithm, so I'm not worried that I'll have to stand on a whiteboard and not know how to step through a loop, but I still think it's not very useful to make people do that).
What language did you do your high-school level stuff in? I assume it wasn't Java, because in Java there are no good reasons to use recursion (it provides iterative primitives, unlike say Haskell, Prolog, Lisp etc) and there are good reasons not to (its compiler doesn't (or didn't) do tail-call optimisation).
Not to mention, any language without pattern matching is a bit shit for teaching recursion anyway: you tend to miss the point because of all the bookkeeping.
Recursion is generally considered hard by most programmers, hence why my interviewers thought I was showing off. You can google a bit and see that people do indeed have trouble getting their heads around it.
take a world 100m running champion and ask him to run the 30m with making 360 deg rotation left on each 3rd step and rotation 360 deg right on each 5th step... That would be such a fun, like a drunken duck...
No, if you want to retract it, then make a case why this is not true. We don't believe that article because we trust the author.
Here's the retraction: http://www.eis.mdx.ac.uk/staffpages/r_bornat/papers/camel_hu...
If someone describes staying up all night as a 13 year-old because they had to finish the code they were working on, that's someone who was passionate about programming before they found out it's one of the better paying professions.
If someone points to finished projects (especially side projects or OSS), then they also have the ability to focus. If someone points to a bunch of barely started projects, they might have great ideas but in a business you also need to execute.
So ... passion and focus, plus a reasonable amount of domain knowledge will make a great employee.
So, you're explicitly selecting by class background and upbringing? This particular metric also tends to select against women, if you have any applying.
I can remember on two occasions bosses of mine who helped kids with some form of homework assignment. If your dad (or mum) isn't technical then you are less likely to get an early start.
I'm not disagreeing, because I agree that side projects show passion, but I'm not sure a lack of side projects necessarily points to a worse employee. Someone could be a great developer in an enterprise environment, from where they obviously wouldn't be able to show you code snippets, but have no side projects because they might have other hobbies.
Despite working in these types of place, I still got a shock, though, when I started doing freebie work on open source software and worked out that such an aptitude-less programmer was managing a large open source project developing a programming language. Perhaps some people doubting the double hump are from places like Google where all engineers are vetted via Computer Sciences degrees, and they don't have repeated everyday experience of it.
This may well be to due the fact that psychologists have been using parametric statistics instead of nonparametric statistics. In a lot of cases us nonparametric types have given up a little statistical power for "cheap and cheerful" methods that are harder to get wrong.
Psychs and medicals find it very expensive to treat thousands and thousands of patients correctly and carefully observe the results. This is why those Cochrane reviews for the case for almost any drug or other treatment are so depressing -- maybe they need all the statistical power they can get.
For an easy example of why (if true) this would be a valid criticism, consider IQ, which is normally distributed. I will give you an IQ test and assign you into one of two categories: smart or dumb. If you are below the median, you're dumb, if you're above the median, your smart.
It should be obvious why this makes little sense; the large number of people very close to the median are divided in two and put in the same category of those with either very low or very high IQs.
To assign people to one of two categories, one would want to see a distinct bimodal distribution, then there would be a small number of people for whom which distribution they belong to is ambiguous, and the majority could be confidently assigned to one or the other.
>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 can't learn to program: between 30% and 60% of every university computer science department's 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.
http://blog.codinghorror.com/separating-programming-sheep-fr...
emphasis:All teachers of programming find that their results display a 'double hump'. It is as if there are two population
emphasis: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
So the disparity has presented itself in all known historical forms of pedagogy. Some have learned while others haven't, some have even learned with entirely self-directed pedagogy.
When a array of teachers has been giving it their all for decades but the disparity remains, should we really blame the teachers?
The search space of possible ways of teaching programming is so large, and the field so young, that I'm not convinced we're anywhere near optimal.
What I think needs to be criticized is a tendency to go on these wild goose chases searching for a magic factor that will explain everything, when there are other obvious factors nearly staring us in the face that we don't want to address.
It's the opposite of Occam's razor.
Well then, why not set the bar for who can program and who can't on who can code in Prolog, rather than who can write FizzBuzz? If the point is to sort out the men from the goats, or whatever uncle Joel said we're trying to sort out, surely using Prolog as the sorting tool would leave many, many fewer "real programmers" than FizzBuzz. Hell, we could even combine the two: FizzBuzz in Prolog! See how well you can do at that, internets!
And why stop at Prolog? There's languages that are way, way harder to program in! Hey, if you're a Real Programmer you should be able to write FizzBuzz in, dunno, Ook. Brainfuck. Leboge? Mondrian? Perl, even?
Or maybe, I don't know, we can start asking people to show us what they can do instead of trying to find things they can't? Does that make sense to anyone else? I'd personally love it if people who want to hire me took the time to check out my github and the git repository I'm serving off my public server, in order to get an idea of the things I have already done (and so demonstrably can do) rather than trying to catch me with my pants down in front of a whiteboard.
Look. I write a lot of code. I go over a lot of code I've written. I'm an idiot 80% of the time, but the other 20% of the time I figure it out, fix my bugs and go to town. It works, OK? If interviews can't appreciate this balance then they 're useless.
I don't think anyone is seriously questioning the fact that some people have more aptitude or intelligence than others. That's pretty commonly accepted fact. However, the general belief is that intelligence follows a roughly Gaussian (bell curve) distribution, and that it's roughly continuous. Mechanistically, one can imagine that intelligence is a convolution of genetic and other factors that are so thoroughly mixed that there are no discrete steps.
The theory behind a two-humped camel model of aptitude or intelligence would then be that some magic x-factor is so significant that it splits the underlying distribution in two, into the "cans" and the "can nots".
While the existence of such an x-factor would be a really interesting finding, it wouldn't change the underlying fact that some people have more innate ability to program than others, just like some people have more innate ability to be doctors or lawyers or concert pianists than others. It would just tend to make that difference much starker.
What it also wouldn't change is the fact that innate ability doesn't always correlate to success in a given career, or in life. Many other factors other than innate ability, such as drive and ability to collaborate with others, affect whether someone is going to be successful at their job. Also, people can learn. Even someone who doesn't have innate talent can become very skilled, if they work really hard at it.
So, even if the study were valid, which it's not, the finding itself is more of an academic interest than an excuse to start treating coding job interviews as a "sword in the stone" test of whether you've got "it" or not.
However, I fail to see much discussion about the subsequent paper [1] that addressed these failings and featured improved experiments that seem to still uphold the hypothesis.
[1] http://www.eis.mdx.ac.uk/research/PhDArea/saeed/SD_PPIG_2009...