So, you stumbled into recruiting? How did that happen? Just yesterday, you were a software developer happily rampaging around in your code base, and today you learn that you get to pick who will join the team in the future? Scary? Don’t worry, somebody obviously trusts you to be up to the task, and, since you are reading this, you are also a conscientious person who wants to do the job right and honour the trust bestowed on you.

So how do you do it? Your first interview is tomorrow, and you need a jump start. Well, in that case my suggestion would be: Don’t waste time reading this article, but read How To Hire The Best People You’ve Ever Worked With by Marc Andreessen, followed by Five Essential Phone Screen Questions by Steve Yegge. These are my two favourite-of-all-time articles on recruiting. They are old, so you might call them classics - except that “classics” implies that they are somewhat well-known and popular, and I don’t really know if they are. In my estimation, they deserve to be, and they are closely followed by the more recent How To Hire by Henry Ward, which I have already talked about in a previous article.

Andreessen

So what makes these articles so special to me? I will start with Andreessen’s article, How To Hire The Best People You’ve Ever Worked With. I recommend it so highly because it provides great orientation by answering the question: “Which qualities exactly should we look for in candidates?” What might be surprising to many - it was surprising to me, at least - is that Andreessen starts out with intelligence, but only to dismiss it as secondary. Intelligence, in his experience, is a bad predictor for success, therefore, we should not make it the criterion when hiring. Apparently, some very intelligent people had things always come easy to them, and never learnt to push hard for something they want.

Drive

Therefore, we should focus more on drive, because it is a much better predictor of success. Drive is obviously something that Andreessen values highly (and we should, too):

“I define drive as self-motivation – people who will walk right through brick walls, on their own power, without having to be asked, to achieve whatever goal is in front of them. People with drive push and push and push and push and push until they succeed.”

If you think of Joel Spolsky’s famous Smart, And Gets Things Done mantra, drive definitely covers the “gets things done” part. I think it is rather obvious why this is a desirable quality in a candidate: You don’t want your new colleague to tinker around forever, but to deliver complete solutions.

Curiosity

The second quality to look for, according to Andreessen, is curiosity. Is the candidate doing anything that is not directly related to her daily work? Is she up to date with current trends in the industry? The reason you should prefer curiosity to intelligence is that learning is so essential in our fast-paced field. If you stop improving, you stop being good. You become an expert beginner. And you do not want expert beginners on your team. Curious people know that they are never done developing and improving, and it gives them joy to learn new things.

Ethics

Additional to drive and curiosity, Andreessen also advises us to select for ethics. You have to be able to trust the people working with you, and if they are unethical, you cannot trust them. Your work atmosphere will suffer, ideas will not be discussed openly, and people will watch out what they say to whom.

Unfortunately, ethics are hard to test for in a one or two hour job interview. However, honesty is part of ethics, and Andreessen gives a very practical piece of advice to aim at honesty: Pick a subject you know in depth, ask increasingly difficult and detailed questions about it until the candidate does not know the nanswer, and watch what happens.

“They’ll either say they don’t know, or they’ll try to bullshit you. Guess what. If they bullshit you during the hiring process, they’ll bullshit you once they’re onboard.”

So, if you hear the words “I don’t know” (sparingly), that’s actually good sign. If, instead, the candidate tries to wiggle his way out of the situation, and his explanations become more and more cloudy and vague, then this should be a big and loud alarm bell ringing in your ears.

Drill down

This is one of the best pieces of advice on recruiting I have ever come across, and I follow it regularly. Once, I asked a rather young, pretty confident candidate with a hot-shot, seen-it-all kind of attitude about data structures in java.util (which is an idea I got from the second recommended article, by the way). He could name some - lists, sets, maps -, so I drilled down into hash maps, asking him how a hash map roughly worked, and how he would implement a hash map if it was not there already. It was unbelievable what he was trying to serve me before he finally gave in and admitted - well, no not admitted, he didn’t admit anything. He would not condescend that far. But, at least, he implied that he did not really know. He kept claiming that the hash map is just there, isn’t it? Like it was a primitive data type that is built into the language. When I didn’t accept that answer, he alluded that my question was not really practically relevant, because, after all, the hash map is already there, right? To cut a long story short, this was a very revealing moment, and no, we did not hire him in the end.

Summarizingly: Dive deep until the candidate runs out of answers, and see how he behaves. That will tell you a lot.

During the remainder of his article, Andreessen gives advice on how to design the hiring process, which, while certainly worth reading, I will not repeat here. Suffice it to say that he recommends doing basic skills tests, which is exactly what my second recommendation is mainly about.

Yegge

Steve Yegge’s blog posts are hilarious, and a mere joy to read. But that is not all, because they are tremendously insightful, as well. In The Five Essential Phone-Screen Questions, Steve (who was formerly with Amazon and is now with Google) describes the following, not too uncommon situation: Somebody in the company does a telephone interview with a candidate, and the candidate is invited for personal interviews in the office. However, in the personal interviews, it becomes evident very quickly that the candidate is nowhere near eligible to be hired. Steve’s question is: What went wrong during the phone screen, and how can we avoid this situation?

This article deserves credit first and foremost because it presents a very handy set of questions, spread across five areas, that filter out candidates who would most certainly not make it past Steve’s personal interview. The five areas are (quoted from the original):

1. Coding. The candidate has to write some simple code, with correct syntax, in C, C++, or Java.
2. OO design. The candidate has to define basic OO concepts, and come up with classes to model a simple problem.
3. Scripting and regexes. The candidate has to describe how to find the phone numbers in 50,000 HTML pages.
4. Data structures. The candidate has to demonstrate basic knowledge of the most common data structures.
5. Bits and bytes. The candidate has to answer simple questions about bits, bytes, and binary numbers.

Different companies will probably come up with different areas. However, Steve gives us very reasonable criteria that your area should meet. The five areas above were chosen because they are:

• Universal: Every software engineer should know them, regardless of experience.
• Quick: You can work through each area in one to five minutes and get a good enough impression if there is some knowledge there, or if there is a total vacuum (which is all we want to know for now).
• Predictive: Each area is actually relevant, and if a candidate struggles here, he will also struggle on the job.

The first area, coding, was not really a surprise, because we have long been doing that in my company, as well. However, when Steve published his article in 2004, he was probably way ahead of his time. It is also worth noting that he did that over the telephone, with the candidate reading out his solution (i.e., source code) character by character. When I imagine this, I feel thankful that there are collaborative online editors nowadays. Anyway, Steve gives some good examples of coding exercises that you can use during a remote interview, so you might want to check them out.

Object-oriented design, the second area, shows if the candidate can juggle abstract concepts and model a real-world situation in terms of OO terminology. Steve gives some rather amusing examples of candidates failing royally in this part, my favourite one being:

For example, you may find a candidate who decides that a Vehicle class should be a subclass of ParkingGarage, since garages contain cars. This is just busted, and it’s un-fixable in any reasonable amount of training time.

I think the OO design part can be helpful because you can “watch the candidate think” as her solution evolves, so that you get a feeling for her problem solving and abstraction abilities.

The third area, scripting and regexes, is a lot about pragmatism. When asked to find all the telephone numbers in a certain format in 50,000 files, does the candidate write a 2000 line Java program, or does he use Unix command line tools? I do not always use this kind of question, but it can give you a good impression of the “general computer literacy” of a candidate.

Data structures, area number four, is indisputably relevant for every software development position, even if you work only with high-level scripting languages. What is the difference between a list and an array? How does a hash table work? What is the average time to retrieve an element in each of the above? If a candidate cannot at least answer basic questions like this, you’ll be in for a lot of training if you decide to hire him. It’s not entirely impossible that this might still be a good decision, but you have to be aware of the time you will have to put in.

The last area, bits and bytes, might be a bit controversial, but Steve gives some good reasons why he includes this area in phone screens. For example, even in high-level scripting languages, you should know about integer overflows, because they can cause very nasty and catastrophic bugs. Even in high-level languages, you will occasionally deal with the binary representation of numbers. What are bitwise logical operators and what do they do? How can you store many boolean variables in just one numeric variable, and how do you operate on this variable? How much memory do various types of numbers take?

Steve concludes his post with a very amusing set of interview excerpts, along with his predictions on how and where the candidate would fail. Also, he wrote a related article describing one entire on-site interview that Steve did, which gives more insight into how he uses his questions.

Ward

I have already mentioned it: How To Hire by Henry Ward is not (close to) a decade old like the other two. But like Andreessen’s article, it provides excellent big-picture orientation on what hiring in tech is all about. While Steve Yegge’s article teaches you to test for hard skills and knowledge, the other two posts emphasize the softer - and no less important - aspects to watch out for. Henry gives six hiring heuristics:

1. Hire for Strength vs Lack of Weakness
2. Hire for Trajectory vs Experience
3. Hire Doers vs Tellers
4. Hire Learners vs Experts
5. Hire Different vs Similar
6. Always pass on ego

For each heuristic, he gives very good reasons and explanations. Especially the first point, Hire for Strength vs Lack of Weakness, was an eye-opener for me, because I had always thought that consensus hiring was rather a good thing. See my full discussion in Should You Hire by Committee or Should You Not.

Question lists

If you have to lead your first job interview tomorrow, and you have no clue where to start, these three articles can take you a long way. After reading them, start you own list of interview questions in various areas, along with coding exercises, OO design scenarios, etc. There are a couple of good interview question lists out there, like the Epic List of Interview Questions, or this one for soft skills.

However, always keep in mind: A good interview is a conversation, not an interrogation. This should especially be true for an on-site interview, where you are not that pressed for time. The best way to get a conversation flowing is to show true interest in the candidate, just like they show true interest in your company. After all, they might have travelled a long distance to speak to you on that day, and probably even sacrificed some of their precious vacation days to make it possible. The least we, as interviewers, can do is to treat them with interest and respect, and to make them feel comfortable and welcome.