4 ms·

Have you ever interviewed programmers? Have you ever attended a job interview? (1) This is an interview question, he's not asking you to be a professional stdi

Have you ever interviewed programmers? Have you ever attended a job interview? (1) This is an interview question, he's not asking you to be a professional stdin->stdout copier (2) this isn't a micro optimisation problem: > The first question on the quiz is a triviality, just to let the candidate get familiar with the submission and testing system (3) A surprising number of programmers can't program. Basic warmup questions are a good thing and can save a lot of your time http://blog.codinghorror.com/why-cant-programmers-program/ http://blog.codinghorror.com/why-cant-programmers-program/ (4) Even if this isn't his attempt, there's genuine depth to even this problem. If you do the obvious a = get_byte() while a != EOF: send_byte(a) a = get_byte() There's a surprising amount of work going on behind the scenes that you can dive into discuss how I/O works, when would you do this using blocking vs. non-blocking I/O, when should you do your own buffering or let the language/library do it for you. But it's short enough to get started to get to those points very quickly. (5) I wouldn't hire/not hire someone based on style alone, but you can get a pretty good feel for it from short programs that actually work. If the tasks or snippets on which you interview are too short to be complete programs, you miss a lot of organisation and "shape of the code" kind of stuff from their style. (6) Interviews are tough as an interviewee. Professional programmers aren't professional job interviewers and often it can be hard to read their mind to see what they are looking for in a particular question. "It's open ended, take it where you like" usually doesn't mean what it says on the tin. As far as going from "here's a question" to "here's an answer" with little ambiguity this is one of the better FizzBuzz type questions I've seen.

Jtsummers 13y ago
> (3) A surprising number of programmers can't program. This reminded me of the interview for my first job. I was basically between a rock and a hard place so part of what follows was clearly, in retrospect, a bad sign, but the choice between job and no job but $20k in debt to cover, I took the job. The shop was a C shop, embedded systems. When I went in to interview I was virtually a shoo-in (just learned I'd misspelled this for years as shoe-in) for the job due to a college classmate already working there and recommending me. The code segment was straightforward. It presented several "implementations" in C of functions to swap the values in two variables. That is: int x = 10; int y = 20; swap(x,y); // after this point x == 20 and y == 10 should be true void swap(int x, int y) { int t = x; x = y; y = x; } Now, that obviously won't work in C. One of the implementations was correct, 3 were wrong (like the above snippet). I was asked which were wrong, why they were wrong, which was correct. I answered them all (note: this was a week 2 or 3 programming assignment when I took a course using C as an undergrad, it really seemed obvious to me), and the interviewer was surprised. I was told, "You're the first person to get all these questions correct." Like I said, warning signs. Alarm bells should have been going off. If the interviewer tells you that, that means that your colleagues couldn't answer those questions. That only occurred to me about 4 weeks later once I'd finished all my reading and project familiarization and was getting into really working with my new peers.
ojbyrne 13y ago
My initial impulse would've been #!/bin/sh cat
- threedaymonk 13y ago
  You can go one better: just symlink cat and avoid an unnecessary exec.

Jtsummers 13y ago

> (3) A surprising number of programmers can't program. This reminded me of the interview for my first job. I was basically between a rock and a hard place so part of what follows was clearly, in retrospect, a bad sign, but the choice between job and no job but $20k in debt to cover, I took the job. The shop was a C shop, embedded systems. When I went in to interview I was virtually a shoo-in (just learned I'd misspelled this for years as shoe-in) for the job due to a college classmate already working there and recommending me. The code segment was straightforward. It presented several "implementations" in C of functions to swap the values in two variables. That is: int x = 10; int y = 20; swap(x,y); // after this point x == 20 and y == 10 should be true void swap(int x, int y) { int t = x; x = y; y = x; } Now, that obviously won't work in C. One of the implementations was correct, 3 were wrong (like the above snippet). I was asked which were wrong, why they were wrong, which was correct. I answered them all (note: this was a week 2 or 3 programming assignment when I took a course using C as an undergrad, it really seemed obvious to me), and the interviewer was surprised. I was told, "You're the first person to get all these questions correct." Like I said, warning signs. Alarm bells should have been going off. If the interviewer tells you that, that means that your colleagues couldn't answer those questions. That only occurred to me about 4 weeks later once I'd finished all my reading and project familiarization and was getting into really working with my new peers.

ojbyrne 13y ago

My initial impulse would've been #!/bin/sh cat

threedaymonk 13y ago
You can go one better: just symlink cat and avoid an unnecessary exec.