gregbo (gregbo) wrote,

  • Mood:
The following is a simple C programming language implementation of the Unix cat program, which (among other things), writes what it reads from the standard input to the standard output.

#include <stdio.h>

#define TRUE 1

int main()
        int c;

        while (TRUE) {
                c = getchar();
                if (c == EOF) {

This program is "correct" -- it does what it claims to do. However, there is (at least) one problem with the program that an interviewer might hold against a candidate. It is the "c == EOF" condition. There is a school of thought that says that the arguments should be reversed, because if someone accidentally uses a "=" instead of "==", the program will not work correctly, even though the compiler will not detect any errors. (FYI, EOF is a constant that when encountered in a file stream such as provided with getchar(), indicates that the end of the file has been reached.)

Why is this an issue? Because many reference books, including K&R, the definitive text for the C programming language, is full of examples where <variable> == <constant> is used. Someone who's used K&R for years, and never allowed such a mistake to get into production code, might actually miss out on a job opportunity because not realizing (or knowing about this), plus perhaps a couple of other mistakes made due to nervousness or some other random thing, might make them a less desirable candidate.

Where does one go to find out about such issues? I don't ever remember seeing code implemented in the "safe" way before 1992. When I first saw it, I thought it looked unusual. Possibly, this issue is discussed on the usenet group comp.lang.c, or it may be in another C programming book. But when someone is focusing on this issue, what issues aren't they focusing on that might be critical to getting a job, or doing the job they're hired for? Suppose they aren't protecting their code against fraudsters? What would a customer say, when presented the choice of protection against fraud vs. safeguarding against a mistake that "might happen?"
Tags: career

  • Ciena interview

    I had an onsite interview at Ciena a couple of weeks ago for a Senior Systems Test position. Long story short — I didn't get the job. I think they…

  • ProtonMail test

    I took a test from 7-9am this morning from ProtonMail, a secure email provider based in Geneva, Switzerland, that has an office in SF. The test was…

  • IBM interview

    I had an interview loop yesterday at the IBM Silicon Valley Lab facility with several people from the Cloud Network Services group. Four engineers…

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.