Classical musicians.

Of course there will be relatively few areas where early involvement is even considered in a candidate. How many 9 year old lawyers do you know?

But it's an exceptional and unusual field. Many professional non-classical musicians start much later, and still do okay - although it's a much more brutally selective field than software development.

Edit: I see no evidence that starting late makes it impossible to be a good developer, and plenty that an early start is irrelevant. Any reasonably intelligent graduate should be able to learn to be at least averagely competent at basic code grinding. It might take a few years, but there's nothing inherently magical about the process.

This is correct about 99.999% of the time. The exception is when extreme levels of talent and interest are simultaneously involved.

Barry Tuckwell, one of the great virtuoso French hornists of the 20th century, started playing at 14 and was playing professionally within six months.

Hermann Baumann, another virtuoso French horn soloist, started playing when he was 17.

Anyway, I think that interest in programming before college is a likely indicator of independent interest and self-directed learning. I know a lot of folks majoring in CS or trying to get into development simply because it's a lot more lucrative than many other professions. Many(not all) of these folks don't have a genuine interest in programming which makes it unlikely that they will be effective developers.

Every 9 year old.

Of course these arbitrary criteria to filter junior programmers add no value, but are another symptom of how broken the entire business is.

I can also tell you that most the lawyers, bankers, consultants and doctors at my university will have been doing work experience + shadowing from around 14-15 years old. The even more ambitious ones will have been doing slightly more enterprising things (entering school/local/national entrepreneurial competitions), or reading around their interests, or joining/running societies.

When looking at the most successful people I know around me, what becomes apparent is that they started way earlier than everyone else. Look at Zuckerberg, he wrote Synapse when he was 16. It's unlikely you'll hire a Zuckerberg, but when someone started coding is a pretty reliable heuristic for how dependable they'll be in the job. Think of it as hiring a senior analyst to do an junior analyst's role, if you will...

Case in point, I'm a PhD dropout from a top 15 math program in the US - I did not really code at all to any serious degree. After pouring a lot of time & effort, even after starting, I became very good at what I do. I have encountered plenty of people in the profession who have become solid to very good developers, including a former grad school colleague. The people have come from all sorts of walks of life, from college dropouts to sales.

Also to contrast, I have also worked with not great developers who have CS degrees. A degree does not tell me if you are passionate about what you do, or if you retained any knowledge from schooling - nor does various indicators that you have coded prior.

> ...people can learn if they put their minds to it.

Sure. I never said that it isn't possible to learn. All I'm saying is that there is a correlation when you consider the population in aggregate.

I'm sure the civil engineering industry (to continue my example) would be happy to accept somebody who started to learn later in life. However, given that it takes years to learn engineering if you start at the beginning of the knowledge tree (say, arithmetic), why should coding be any different (say, your first "Hello, world!")?

Since the current education system puts the learning of the beginning of this knowledge tree many years apart, it makes sense that the acquisition of competence at the other end is also years apart. Hence, if you follow the regular education system to learn software engineering, someone who started early will be years ahead of you. This is common in our field because the current education system is so far behind. Therefore, employers in our industry (as opposed to other industries) value those who started early more, and this is reasonable behavior.

> After pouring a lot of time & effort...

Right - and people who pour in a lot of time & effort are correlated with people who started early. This does not necessarily exclude people who pour in a lot of time & effort at other times.

Asking this may be trite but: do you have evidence to back that assertion up? Why couldn't we say that about other professions?

I may still not be understanding you, but my own experience, when I learned programming as part of an EE degree (first language was C with lots of pointer manipulation) was that concepts like indirection are a lot simpler to pick up de novo than Partial Differential Equations, Fourier Transforms and other college-level math concepts are, even with 12 year grade school background.

"ideally they'll have been programming since before college"

Lot's of people get into computer programming as a second career. Rich Hickey, who created the Clojure language, studied music when he was in college. Later, when he was working at a music studio, he got serious about writing code in C++, and from that experience he developed his opinions about the flaws of object oriented programming, and the possible benefits of immutable data.

Your remark says a lot about the hunger for stereotypes in the tech industry. As if everyone is suppose to follow the same path to a career in computer programming.

With my prior employer, I briefly had the privilege of working with one of the smartest and most driven junior devs I've ever encountered, who'd been a professional figure skater in a past life and was fresh out of a Ruby bootcamp. This was a Node shop, and I've never seen anyone else go so quickly from zero to fully productive in a new stack. If the various dysfunctions of that organization included a prejudice toward long-term hobbyists, I still wouldn't have.

I'm saying that early coding implies a higher probability of having useful experience in a junior dev (i.e. straight out of college). You seem to be suggesting that I think that the probability of someone having useful experience is lower without early coding. But I don't think that at all; I don't care whether useful experience comes before or after college.

I think the "before college" comment is mostly meant as "self taught" rather than literally "before the age of 18".

It is absolutely the case that a good developer will have perhaps a few interviews, and then pick the best offer available. Meanwhile, a marginal developer will go to interviews for months until something sticks. Thus, of the candidates I actually see, I expect the ratio to be perhaps 50:50 whereas perhaps 95% of all engineers are actually qualified for their jobs.

When a "senior software engineer" candidate can't read ten integers from a text file and print their sum after 45 minutes in front of the language of their choice, I have to assume that I'd have an equally bad experience working with that candidate in the future, and pass.

The article leans too heavily on "great developers are sticky," which may or may not be true, but the above dynamic is the main reason we have coding screens for programming jobs.

Nobody has shown me a better way of screening that actually works any better, and the cost of a mishire at the senior level is high, so on we go with the tools we have, primitive as they may be.

I don't think i could type that off the top of my head. Sure, the normal java stuff public class Foo { ... blah blah blah ...}. Integer parsing with Integer.parseInt(...); do the sum in a loop, couple minutes maybe. But i have to look up references.

File because one of the constructors overwrites whatever is there there, and the Reader family because i can never remember what i need in the stack. I don't think i've had to open a file this year.

I guess it's better to just type in everything you know, then explain what you're looking up and why. But really at my desk, I'd instantly know what i needed to look up and go look that up before typing. Rather than local javadocs, i'd google for FileReader. But in an interview i'd feel bad.

Ah yes, and after actually doing it, i'm an idiot, and there's a nice convenience method that is perfect. Files.readAllLines.

Also, figuring out the package prefixes without an IDE kind of sucks.

Google has ruined me.

But yeah. stock linux + jvm and no internet connection? maybe 15 minutes? 5 minutes to figure out where the javadocs are, another 5 to find the docs. 5 for typing. Eh, maybe another 5 for remembering the weird path conventions for javac.

I'm kind of embarrassed it would take me that long.

edit

Oh gosh. you wouldn't have ctrl mapped to caps lock. I'd look like a complete moron.

Ideally if you chose Java, the person would let you handwave the actual library calls. Or you'd pick something saner. In Javascript, off the top of my head -

  const fs = require('fs');

  const sum = fs.readFileSync("filename").toString().split(",").map(x => parseInt(x)).reduce((acc, i) => i+acc, 0)

In C, in a handful of minutes (and with no reference):

  #include <stdio.h>
  int read_and_sum_ints(const char *filename, int n)
  {
      FILE *fd = fopen(filename, "r");
      int c = getc(fd);
      int sum = 0;
      while (n-- > 0 && c) {
          int m = 0;
          while (c && c != '\n' && c != '\r')
              m = (m*10 + (c - '0'));
          sum += m;
      }
      fclose(fd);
      return sum;
  }
  int main(int argc, char **argv)
  {
      print("%d\n", read_and_sum_ints("foo", 10));
      return 0;
  }

Furthermore, we did almost all system interactions through a platform-independent middleware interface. So, while I, for example, knew what a semaphore was and how to use it I could not remember the standard Linux interface for semaphores because we used the platform-independent API for ours.

Expecting people to remember APIs off the top of their heads is ridiculous. Some do, some don't. The people who don't aren't lesser engineers just because they don't.

    use std::io::prelude::*;
    use std::fs::File;

    fn main() {
        let mut s = String::new();
        File::open("numbers.txt")
            .unwrap()
            .read_to_string(&mut s);

        let sum = s.lines()
                   .map(|l| l.parse::<i32>().unwrap())
                   .fold(0, |acc, i| acc+i);
        println!("{}", sum);
    }

But I was referring more to the fact that c is set exactly once in line 4 (`int c = getc(fd)`), outside of the nested loops, and never touched again. So if it's not initially a NULL, newline or CR, it never will be, and the inner loop will never exit.

To me whether you start programming before college is like graduate from Stanford, you may or may not be good, it will make me more likely to interview you, but not more likely to give you the job.