Elliott C. Back: Internet & Technology

How to hire the best

Posted in Computers & Technology, Deals & Savings, Education, Science by Elliott Back on August 4th, 2005.

The infamous Mark Jen has posted his take on Joel’s hiring essay. Basically, Joel makes the argument that hiring the absolute best programmers is the best thing for a software company, because superb programmers are investments that more than pay for themselves. It’s basically an argument of averages–everyone can build software, but the few companies that can build great software are few and noticeable. To give a concrete example:

When everyone is making ugly square mp3 players, a stylish mp3 player with rounded edges and careful design will be king.

A coworker and I were discussing this yesterday and today. Obviously, when hiring candidates for positions, we want good ones. However, we go beyond the code of hiring the best of the best–we actually do what we say here. If there’s a candidate that you can’t respect as an equal or greater skill, a candidate who doesn’t appear to possess basic skills, or who is any way lacking is simply not good enough. A company shouldn’t hire someone that limps over the corporate minimum bar to fill a position.

Until there’s someone you find who can leap over a bar twice as high with ease, you don’t want to fill that position. So, don’t make your interviews easy. If you’re doing an interview, make it moderately challenging for someone of your level. Include a “screener” technical question that you think anyone with similar skills and general knowledge should be able to easily answer. Some good interview question choices include:

  • Tell me if there are two numbers in an array that sum to x
  • How do hashmaps work? How would you hash a string?
  • Generate permutations of x
  • Reverse a c string
  • Write a tree to linked-list function
  • Write an efficient recursive function to garbage collect memory
  • Describe how a compiler works.
  • Give an overview of DNS, TCP, filesystems, process scheduling, pipelining, or some other high-level CS topic

Once you’ve passed them through an easy coding question and another general question, you can start to interview them based on their resume, because you know that they’ve met a minimum requirement to do their job. If you’re impressed at the end, hire them. Otherwise, why bother? The negative cost of hiring someone who doesn’t impress you and your teammates is greater than the benefit of filling that vacant position.

Update:

I just noticed Shelly’s comment on this old hiring posts. It reads:

That is the worst interview question I’ve heard of. It is guaranteed to discriminate in favor of a certain type of developer, and not necessarily a good one.

No wonder you people can’t find good engineers. You don’t know how to interview worth a damn. You’re looking for code monkeys, but interviewing engineers. I had a feeling this was what was happening when I talked with someone who interviewed at Microsoft and the same thing happened. Absolutely silly questions-and yes, very biased. Your HR department has done a poor job.

Asking somebody how to do code the strstr function. I’d hire the person who looked at you like you were daft and said, “I’d use the function built into the language. Now what _job_ is it you want me to do?”

I just have to add to the conversation, and point out that asking for an interviewee to code any basic function like that is industry best practice. It’s the absolute lowest bar. Sure, if you actually can code, then these questions will seem ridiculous, but otherwise? You don’t hire a programmer who can’t write code, so you need to see if they can write code. Shelley would rather have interviews, I guess, that go like this:

Interviewer: So, you can code basic functions, do recursion, handle arrays, right?
Shelley: You bet I can! And more!
Interviewer: Fantastic–just had to check.
Shelley: Let’s move onto more interesting things…

Nope, it doesn’t work like that, because we can’t trust you to tell us the truth. Your abilities have to be assessed. Unfortunately, in another comment, Shelley goes on to say:

Any interview that resorts to having the interviewee code is a bad interview. Shows that your staff is too inexperienced to know how to interview.

She also makes a big hand-waving pseudoscientific argument about long term / short term memory with regards to coding. See, the thing is, the most basic part of this kind of job description is writing code. Sure, we create systems, do designs, model databases, and create relational object oriented structures, but then a software developer sits down and implements. Writes code. You wouldn’t believe how many people cannot write a function to reverse the elements of an array, in any language.

Here’s your challenge:

O readers, show your might. I’m going on vacation this weekend, but when I come back, I want efficient implementations of strstr, is_anagram, atoi for any base, and edit_distance. Log the time it takes you to write each one, too. Remember–these are basic interview “crawl over the bar” questions…

This entry was posted on Thursday, August 4th, 2005 at 11:09 pm and is tagged with stylish mp3 player, process scheduling, careful design, recursive function, interview question, concrete example, c string, great software, yesterday and today, pipelining, technical question, coworker, general knowledge, mark jen, mp3 players, software company, hash, programmers, garbage, array. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback.

5 Responses to “How to hire the best”

  1. [...] I was reading a blog the other day and in it the author mentioned the fact that a lot of programmers don’t know how to reverse an array in their language of choice. Not by using a library or language method like we have in ActionScript but the acutal programatic task of reversing an array. [...]

  2. Brock Hamper says:

    I want nothing more than to become a great senior programmer. I love the work. I love learning new things. Gaining a spot there probibly won’t happen. What Shelley says inspired me to even bother to post. So there are at least two people in the world that get *churned* by the way Joel and the owner of this blog relate to the world. I get so sick of hearing the hiring philosophy of dev groups that normally I don’t read much of it nor bother to post.

    I’d love to hear it but I know I never will. Hell will freeze-over the day a team of developers say;

    “dude, we like you. we can tell you want to excel. we can tell you want to be here. we can tell you have the brain power to do this work. The senior developers on the team have already written functions for about everything we ever need to do, like reversing an array and porting a tree to a linked list. we know that you understand the basics of what needs to happen in these functions. It’s OK that you can’t write them for verbatim on the white board for us. You’ve explained the important parts and showed us code and work you have done. Most people don’t retain things that they don’t use everyday. There has been a lot of code written in the world and rather than spending $75/hr for you to yet again write the stuff that has been done a billion times, one of your first priorities is to learn our libraries and learn our design patterns and architecture. Mostly in the beginning as our newest team member – you will use your knowledge (and continue to gain knowledge) of our design, architecture and libraries – to hunt down and fix bugs. We will support and nurture your learning in our mutual work so that as we grow as a team, we all learn more and especially how to work well together. The real skills you need are being able to manipulate the language. Understand sound system design and computer science basics. but mostly, have the combined intelligence to take all these pieces and put solutions together that meet spec and are cost efficient.

    Larry Wall in the camel book has one of the best lines ever in any programming book. He says that a programmer wants to write and keep good libraries so he or she NEVER has to put their brain through the torture of doing the work for a second time. Why do you demand supermen when the real world is made up of mortals?

    I have been trying to “do better” at interviewing. I have been trying to be able to write certain functions “cold”. I study something. I completely understand what I have studied. In a programming environment I can rewrite the function in question. Can I go to the white board and write it “cold”? NO. I just don’t work that way. Being in the right environment, a little reference and little Zen and I’m there. I can do the work.

    I’m not sure I’ve presented any kind of argument that sways anyone. In a way that’s part of the problem. The developers out there have this “every programmer MUST be superman and we ONLY hire supermen”. Everyone is competing to be the “superist” superman. And then you go on to say you work on teams. But one of the base aspects of a “good team” is a diverse group of people with varied strengths. So what I’m trying to drill down to here is that, the illness is being transmitted by doctors. You developers that say hire only the best and strongest are just perpetuating the illness. You don’t believe that there is a problem so you can’t possibly see the problem. Yet you are all living in a controlled hermetic sphere where everyone agrees with each other. And while you are engaging in your self important chatting in the hall, doing the one-upmanship game, you mention can’t find any good developers. It makes me want to slam my head against my keyboard.

    I can’t be of help to you nor can I break into your circle of resistance because I can’t walk up to a freaking white board and write a priority cue. Despite the fact that tests and past work and on and on have proved that I have a make up that makes me excel at this work. Part of me is glad that it is hard for me to retain verbatim being able to reverse an array. I wouldn’t want to be the kind of person that “belongs” in your world. I would be missing out on parts of the picture. I would be closed to other possibilities and options. You have seen the enemy and it is YOU. You are driving away people with a closed supremist attitude.

  3. [...] e you’re a rising sophomore? What classes have you taken? Read this article here: [...]

  4. Mark Jen says:

    Hi, nice post and I’m glad to hear that there are others in the industry and appreciate how crucial it is that a candidate in the IT industry knows how to code.

    I’m not going to attempt the coding questions because I have seen all the different solutions (depending on memory/processing time requirements) many times. Besides, I like the thrill of trying to figure out a neat coding question in real-time during an interview. It’s always a fun challenge – I might be sick, but I actually look forward to it :)

    Also, Hi Alvin! Congrats on your position at AutoDesk, I know someone who left AutoDesk recently and joined up at TechSmith. If you want to catch up, you can find my contact info over at my blog :)

    As far as whether coding questions are still good for upper level hires, I say heck yes. If you want to be a dev lead, you better know how to dev. If you want to be a VP of engineering, you better have quite an impressive history of developing and shipping awe-inspiring products. What happens when you hire a manager to lead an engineering team but he/she doesn’t know the first thing about writing code? Oftentimes, you get Dilbert scenarios – no joke.

    I’m generalizing here, I’m sure there are a handful of non-technical dev managers out there; but in general, I’m not going to be one to go against the odds, not when it’s an engineering team/product group/company at stake…

    Thanks for the great post!

  5. Alvin says:

    i found those posts and (much – i didn’t read it all) of the discussion in mark jen’s post quite interesting. (side note – i *think* my cousin knows mark jen… and he critiqued my resume before when he was at microsoft – small world). i agree in general – you have to ask a coding question to make sure they can handle the basics and *especially* for an entry level position. upper level? well that’s a different scenario because they should have experience already. perhaps not explicitly code, but definitely discuss problems that he/she may have to work through, like in pseudocode.

    and it’s interesting that i got my internship at autodesk through a phone interview with no coding question. they unfortunately couldn’t make it to campus for their reguarly scheduled interviews with cornell candidates, but nonetheless 6 of us got summer positions at autodesk, and the 6 of us have definitely been productive and useful (or so is my impression ^_^).

    … and i will NOT code those little functions you challenge me to code, for i was a 211 ta and have proved my worth already… haha

Leave a Reply

Powered by WP Hashcash