Hacker News Reader

Comment by barrkel | Hacker News Reader

Everybody's weak the first time they do something for reals; that's not really what I'd classify as a weak programmer, but rather junior.

When interviewing a junior, ideally they'll have been programming since before college and are actually intermediate devs in disguise. But when actually hiring a confirmed junior, you look for a spark of intelligence but also go in on the understanding that (a) their potential is unknown, and (b) there are only so many juniors you can allocate across teams and maintain productivity. Juniors are a speculative investment.

View on HN

Why is it ideal that a candidate has been coding since before they were in college? I understand wanting people who have an interest in the job, but how many other industries feel that the only good candidate is one whose been involved in it since they were a child? Sports are the only one that come readily to mind

Now that there is a push to get all kids coding in school, this criterion will have to be tightened: I wouldn't be surprised to see: "had first PR merged into a Github project before college".

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

Right, it's along the lines of people declaring that the only good programmers are the ones who have outside projects regardless or whether 8-12 hours a day of programming at a job is enough to sap anyone of creativity

If you work 8-12 creativity sapping hours, the pay better be good..

> how many other industries feel that the only good candidate is one whose been involved in it since they were a child? Sports are the only one that come readily to mind

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?

Sadly true. If you haven't been practicing since before puberty, you will never be a professional classical performer.

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.

I started programming around the beginning of high school and then stopped at the end of high school and became a car salesman. 8 years later I went back to school and got a CS degree and am thriving. So, I did have some early experience, but given the gap I feel like I'm more closely aligned with a late starter.

> Sadly true. If you haven't been practicing since before puberty, you will never be a professional classical performer.

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.

> How many 9 year old lawyers do you know?

Every 9 year old.

"The contract stated I had to wash the dishes but did not detail the quality expected and is therefor unenforceable".

> Why is it ideal that a candidate has been coding since before they were in college?

Imagine if civil engineering students were taught arithmetic for the first time at college. Firms would favor applicants with an interest from a much younger age, no?

The problem with software engineering is that understanding it well is as fundamental as understanding arithmetic. We teach arithmetic from the age of around six, yet we expect that starting to code only at college is somehow equivalent.

The problem with software engineering is that understanding it well is as fundamental as understanding arithmetic

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 think I might not have made myself clear enough, sorry. Let me add some context to what I meant:

The problem with software engineering is that understanding [things like indirection] well is as fundamental [to software engineering] as understanding arithmetic [is fundamental to civil engineering].

I presume that this assertion, then, is uncontroversial?

Indirection may be fundamental to programming, but it is a fairly self-contained concept that in my experience can be grokked quickly. The math required for an engineering degree is based on arithmetic, algebra, trig and calculus, all of which are taught over a period of years.

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.

This is a quite unintelligent response - people can learn if they put their minds to it.

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.

You seem to have assumed that I exclude anyone who did not code before college as incompetent, but I never said anything like this. I only assumed the context of the regular "attempted to become competent through college" route.

> ...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.

Why is it ideal that someone has been coding before college? Simply because they have that many more years experience than everyone else. You may even be able to argue that coders are amongst the only people who have a non-negligible likelihood of starting the practice before college, I could believe this is the case.

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...

About this:

"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.

This is very true, and I say that as someone who has been programming since age six.

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 think you've reversed my premise.

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.

So is Rich Hickey self-taught (I don't know)?

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

For a fresh recruit, lack of experience is expected and will be trained away. Nobody who is looking for fresh/junior developers ought to expect anything else. But most needs aren't filled by a junior developer.

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.

So...

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.

Honestly? This seems more complex than necessary.

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;
  }

Given that I'm currently just an intern, I would expect both junior and senior developers to be able to do this.

I wouldn't be able to do that off the top of my head because, in my C experience, I hardly ever read files. Everything we did was reading from or writing to memory buffers.

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.

I agree people shouldn't have to remember APIs, but you should at least have a vague idea of roughly how to go about reading a file and parsing numbers from it.

If the first character in file "foo" isn't a null, a newline or a carriage return, your program will enter an infinite loop at line 9 :)

Yes. EOF is 0, so it will grab all the characters as digits, for the length of the file up until an EOF.

The value of EOF is platform-specific, but is commonly -1. I'm fairly sure it's never 0.

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.

As long as we're posting code/golfing (and since I've been lots of file parsing lately and it's fresh):

    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);
    }

Let's be fair, Java I/O -blows-. The whole stream, reader, buffered, file, blah blah blah, multiple levels of abstraction on top of the basic "Look, it's a file, let me read it", is what is getting you there.

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)

EDIT: Node, specifically, and with the spoken caveat that devoid of context of how it's being used, you're just going to let it block; were it a real application you'd use the async variant of readFile.

There is plenty if grunt work that would be fine for a junior developer (he says grunting away at getting our data into Salesforce).

I don't know why it's so important to see a junior developer's work before college. A junior is supposed to have near 0 experience, it's more important that they can demonstrate problem solving skills and willingness to learn.

Eh? I don't think it's important to see a junior dev's work before college. But if someone has been coding from a young age, if they've been self-taught, it's a very promising sign - they're self-motivated and are likely to stay up to date on tech - and a bonus is you're effectively getting a more experienced dev for the price of a junior dev (though in reality people should recognize this and bid their price up).

I disagree, whether a young developer have projects to show before college is near irrelevant to if they'll become a better developer as a professional. It doesn't automatically translate to self motivated, the only thing it shows is the candidate has early exposure to some technology. To my experience most people start programming from a young age are because they have family members in this profession and were asked to learn programming from a young age. I'm not saying there aren't any really due to interest and motivation, I just haven't met any yet.

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.

I've met several self-taught programmers with very bad habits that had to be unlearned and missing fundamentals (writing O(N-squared) algorithm and not understanding why not to). Not all self-taught programmers are this way but it's not an unambiguous green flag.

Reply on news.ycombinator.com