Joel on Software

This page houses my notes from Joel Spolsky's blog.

Craftmanship

When software is built by a true craftsman, all the screws line up. When you do something rare, the application behaves intelligently. More effort went into getting rare cases exactly right than getting the main code working. Even if it took an extra 500% effort to handle 1% of the cases.

Craftmanship is, of course, incredibly expensive. For a shrinkwrapped software company, though, this level of craftsmanship is precisely what delights users and provides longstanding competitive advantage, so I'll take the time and do it right.

Things You Should Never Do, Part I

Don't rewrite from scratch!

Netscape made the single worst strategic mistake when they decided to rewrite the code from scratch in version 5.0. This version was never released!

Programmers always want to throw away the code and start over. They think the old code is a mess because it's harder to read code than to write it. Old code has been used and tested. The "little hairs" on code are often bug fixes. When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes.

Architectural, efficiency, and style problems can all be solved without throwing away the code.

In addition, there's no reason to believe you'll actually do a better job than the first time.

The Phone Screen

  1. Career History
    • Get the candidate comfortable and loosened up.
    • Look for problem solvers (people who get things done) and passion (people who care about stuff they did).
    • Ask about technology (in detail) and politics (challenges).
  2. Technical Problem
    • How would you design a data structure or a block of code to do x? Where x is something kind of big and complicated.
    • Talk about the code, time-space tradeoffs, performance, etc.
    • Smart people can generally tell if they’re talking to other smart people by having a conversation with them on a difficult or highly technical subject.
  3. Questions for Interviewer
    • Has the candidate done their homework?

Example technical questions:

  • How might you design a program that lets people play Monopoly with each other over the Internet?
  • What would be a good data structure for a photo editor?
  • How would you implement code to operate the elevators in a high rise?
  • How would you implement the rendering engine of a web browser?

The Guerrilla Guide to Interviewing

People are the most important part of a software project. So hire the right programmers!

  • Always try to have at least six people interview each candidate that gets hired, including at least five who would be peers of the candidate.
  • If even two of the six interviewers thinks that a person is not worth hiring, don't hire them.
  • Each interview should consist of one interviewer and one interviewee, in a room with a door that closes and a whiteboard.

You're going to see three types of people in your interviews. Those who lack even the most basic skills, "maybes" who seem like they could contribute something, and brilliant superstars who write lisp compilers for fun, in a weekend, in Assembler for the Nintendo DS. The trick is telling the difference between the superstars and the maybes, because the secret is that you don't want to hire any of the maybes. Ever.

If you're on the fence about a candidate, say "no." It's much, much better to reject a good candidate that to accept a bad candidate. Don't lower your standards no matter how hard it seems to find those great candidates.

You're looking for people who are smart and get things done. Create a situation where someone can show you how smart they are. Let them do the talking, give them open-ended questions and problems. Hire people with aptitude, not a particular skill set.

Before the interview, read over the candidates resume and jot down an interview plan. Here's a typical plan:

  1. Introduction
    1. Put the candidate at ease. e.g. Ask about their flight.
    2. Spend 30 seconds telling the person who you are and how the interview will work.
    3. Reassure candidate that we are interested in how they go about solving problems, not the actual answer.
  2. Question about recent project candidate worked on
    • For college kids, ask about senior thesis or favorite course.
    • For experienced candidates, talk about their most recent assignment from their previous job.
    • Ask open-ended questions and sit back and listen.
    • Look for passion, clarity, and leadership.
  3. Easy programming question
    • Everybody will solve the problem, but there will be variation in how long it took to solve. Smart people will program like it's their native language.
  4. Long pointer/recursion question
  5. Are you satisfied?
    • Inevitably, you will see a bug in their function. So where's the bug?
  6. Do you have any questions?

At the end of the interview, leave about five minutes to sell the candidate on the company and the job.