3 ms·

I was about to say the exact same thing: I'd probably walk out of an interview if remembering how to read stdin was part of it, because it comes up maybe once e

I was about to say the exact same thing: I'd probably walk out of an interview if remembering how to read stdin was part of it, because it comes up maybe once every couple of years in real work, better to just Google it. Don't tailor from-memory standard library questions to bits of code that almost nobody ever has to use.

sophacles 13y ago
I think that is sort of the point of the article though (or at least one of the points...). Dealing with stdin/stdout is not uncommon in itself, though it is probably rare in java. Choosing the right tool for the job is kind of important in most aspects of software, so doing a simple script in say python or a few lines of C or whatever is important - it shows a familiarity with the environment, not just the language(s). For example: Whenever I'm dealing with a data processing pipeline I tend to design things as if they would be used from a unix command line. I tell the team to make their classes etc as if they would be wrapped with a simple chunk of code to parse a text stream then serialize to it later. During the course of testing, I almost always will then write those tools to allow simple command line pipes to push test data around. It helps prevent reliance on certain toolsets and certainly helps stop us from conflating bugs in our code with bugs or operator error about a pipeline framework. Later we can go back and more closely integrate with the chosen operating environment, if performance demands it. On the other hand going from a situation where code is written to the environment and migrating to another environment can be very daunting, difficult and error prone.
torrent-of-ions 13y ago
It depends. If the job is Unix/Linux based then I'd say you definitely should know how to do stdio.
cbsmith 13y ago
> Don't tailor from-memory standard library questions to bits of code that almost nobody ever has to use. So seriously? You almost never need to read & write to streams?
- bermanoid 13y ago
  No. I almost never need to read from stdin, as I said. Again, most of us write real apps, not command line utilities.

sophacles 13y ago

I think that is sort of the point of the article though (or at least one of the points...). Dealing with stdin/stdout is not uncommon in itself, though it is probably rare in java. Choosing the right tool for the job is kind of important in most aspects of software, so doing a simple script in say python or a few lines of C or whatever is important - it shows a familiarity with the environment, not just the language(s). For example: Whenever I'm dealing with a data processing pipeline I tend to design things as if they would be used from a unix command line. I tell the team to make their classes etc as if they would be wrapped with a simple chunk of code to parse a text stream then serialize to it later. During the course of testing, I almost always will then write those tools to allow simple command line pipes to push test data around. It helps prevent reliance on certain toolsets and certainly helps stop us from conflating bugs in our code with bugs or operator error about a pipeline framework. Later we can go back and more closely integrate with the chosen operating environment, if performance demands it. On the other hand going from a situation where code is written to the environment and migrating to another environment can be very daunting, difficult and error prone.

torrent-of-ions 13y ago

It depends. If the job is Unix/Linux based then I'd say you definitely should know how to do stdio.

cbsmith 13y ago

> Don't tailor from-memory standard library questions to bits of code that almost nobody ever has to use. So seriously? You almost never need to read & write to streams?

bermanoid 13y ago
No. I almost never need to read from stdin, as I said. Again, most of us write real apps, not command line utilities.