Basic skills

How is it that someone can have a four page resume and not be able to program their way out of a paper bag?

I just don’t get it.  I truly do not understand this.  At least, I can’t comprehend fluffing up a resume and then walking into a shop known for (relatively) brutal interviews.  Wouldn’t you expect to get creamed?  Or do these people just continue to interview, and eventually get lucky with a weak group?

It’s not like I’m making unreasonable demands, like “Write me a word processor, or a compiler, here’s a whiteboard pen and go to it.”  Simple loops, a little logic, some debugging skills; I’m not asking for much.  I’ll understand mis-spelled keywords, the forgotten curly-brace, even a bug or two.  But to be totally off the map?  When I talk to a carpenter about a job, I expect to see competence around driving nails and measuring and sawing.  This is not that different: Count from 1 to 100, print that.  C’mon.

It is correspondingly difficult not to feel near unalloyed pride in ones’ own ability to write something simple and working.  “Look, I can do a binary search!”  It works: See, there are unit tests.  A hollow yay.  I want to work with people who can do that, and better.


This entry was posted in Rantage. Bookmark the permalink.

0 Responses to Basic skills

  1. JohnN says:

    I dunno, man… Binary search is pretty hard.

    (From Wikipedia):
    “Binary search is one of the trickiest “simple” algorithms to program correctly. A study has shown that an astounding 90 percent of professional programmers fail to code a binary search correctly after a whole hour of working on it, and another study shows that accurate code for it is only found in five out of twenty textbooks. (Kruse, 1999)”

    (From “Programming Pearls”):
    “I’ve assigned this problem [binary search] in courses at Bell Labs and
    IBM. Professional programmers had a couple of hours to convert the
    above description [of binary search] into a program in the language of
    their choice… the end of the period, most programmers reported
    that they had written correct code for the task. We would then take
    30 minutes to examine their code….In several cases, and with over
    100 programmers, the results varied little. 90 % of the programmers
    found bugs in their programs.

    I was amazed: given ample time, only about 10 percent of professional
    programmers were able to get this small program right. But they
    aren’t the only ones….Knuth points out that while the first binary
    search was published in 1946, the first published binary search
    without bugs did not appear until 1962.”

  2. landon says:

    Yes, a bug-free binary search is hard, certainly in an interview situation. Before I asked this I sat down and wrote it (and in fact, had the same bug that the author of Programming Pearls had). Took about 15 minutes to test and get right.

    On the other hand, I’m not looking for perfection in an interview; basic functionality or “close to the idea” is good. Getting edge conditions and screw cases wrong are par for the course. But not even having a clue, or getting a completely blank stare: Nope. You have a degree, you should have at least *heard* of binary search.

  3. William Mayo says:

    Slight side-tangent (Feel free to disregard): What is the minimum that someone should have, sans degree, sans experience, to even look for drudgework and apprenticeship? Where do you start with as “Trainable”?

    Due exposure: I have a somewhat vested interest in learning where to aim myself.

  4. landon says:

    Read books. That’s pretty much how I did it. Coursework will give you hints and motivation, but that’s about it.

    I’d say:

    (1) Know most of the stuff in a good algorithms book. The books by Sedgewick are okay., but you can do better (e.g., the “white book” by Rivest et al).

    (2) Know C. You probably know Java, but you should be comfortable in a real systems programming language. (Ten years ago I would have said, “Know an assembly language, too.” I still think this is true, but I won’t make the demand unless I’m interviewing someone for a position that will need it). I learned C by reading K and R and doing the exercises; this won’t make you an expert, but it’ll get you started.

    [Some of you are screaming: “Learn C++ instead.” You could. It’s a monster. If you found a good safe subset of it, fine. But C++ tends to hide a lot of the very low-level stuff you need to pay attention to in systems programming.]

    (3) Know how to debug. There are three kinds of problem solving that are common in programming Design (APIs, abstractions, etc.), figuring out how to do something algorithmically, and then finding out where you screwed up. They’re all important. [I probably left out a few, but these are the biggies].

    (4) Find an interest and dig deep. I’m far more likely to hire someone with a passion for X, even when I’m interviewing them for Y, because someone digging deeply into X will ultimately find commonality other things. (Games are a great example of this. The implementation of a language would work, too, e.g., LISP or Haskell or something).

    You won’t find any decent books for #3, and the books for #4 will vary,

    My son’s waking up – gotta go….

  5. landon says:

    I should add that knowing “all” of the “white algorithms book” would pretty much make you an expert. For starters: Trees, hash tables. lists, and “big O” notation. Add things like hulls, searching, sorting. You don’t need B-trees.

    Reading the source code to an operating system is good, too. Something approachable, like Comer’s stuff, or Lion’s notes on v6 Unix (quite dated, but still interesting and small).

  6. Keith says:

    Sweet, I learned useful stuff in CS1 then.