5 ms·

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

by jwatte 10y ago

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.

jfoutz 10y ago
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.
- fao_ 10y ago
  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.
  - vonmoltke 10y ago
    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.
    - fao_ 10y ago
      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.
  - dghf 10y ago
    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 :)
    - fao_ 10y ago
      Yes. EOF is 0, so it will grab all the characters as digits, for the length of the file up until an EOF.
collyw 10y ago
There is plenty if grunt work that would be fine for a junior developer (he says grunting away at getting our data into Salesforce).

by jwatte 10y ago

jfoutz 10y ago

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.

fao_ 10y ago
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.
- vonmoltke 10y ago
  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.
  - fao_ 10y ago
    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.
- dghf 10y ago
  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 :)
  - fao_ 10y ago
    Yes. EOF is 0, so it will grab all the characters as digits, for the length of the file up until an EOF.

collyw 10y ago

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