Why doesn’t anybody ask me to code a unit test in an interview?

Why doesn’t anybody ask me to code a unit test in an interview?

Interviewing people for your company is one of the most important jobs you will do. You need to make the best call you can in a limited amount of time. The job interview isn’t a 100% accurate tool for predicting success, but it’s the best one we have. Sadly across the industry our interviewing techniques are dated. Ideally we have an up to date toolbox of interviewing techniques. Improve your interviewing skills with these three concepts.

Pay attention to the candidate.

This may seem like simplistic advice. There are levels of attention, strive to be totally present in the interview.

Get out of your normal chair and take notes.

When you are in your work chair, your body and mind are ready to work. That means checking email, instant messages and the web. Even if you avoid these obvious mistakes while conducting and interview they will still be pulling at you.

Reprogram your attention by just moving. Sit in your own “guest chair”. I like to sit on the desk while candidates are working at the white board. I am not hovering over them, but neither am I lounging while they work.

Adjust your questions to challenge but not overwhelm the candidate.

As you gage the experience and expertise of a candidate, try to keep them working. You don’t want to totally stump them and you don’t want to bore them with your easy questions. It takes a little work, but good interviewers can make all their interviews challenging.

If you are sure it’s a no hire make sure the candidate leaves happy.

You are going to interview a lot of people and hire a few. That means you will cut loose more people than you hire. If you have a good sense the interview is going poorly switch gears. Ideally the candidate leaves you office feeling like you challenged them and they did a good job. This might mean giving some real softball questions to weak candidates.

There are some good reasons to do this. In a team interview you may be the only “no” in the loop. You don’t want a candidate that doesn’t know a specific technology to give up when they might be a star in other areas. For people who are just completely under-qualified you want them to feel like you treated them fairly. That way they don’t badmouth your company and recommend their friends interview with you.

Ask technical questions that are relevant to the job.

Software jobs tend to ask a lot of the same questions that were useful 20 years ago. I don’t know how many people are still asking candidates linked list questions. If a tester working in my organization is writing test code with linked lists I would be shocked. I expect testers to leverage high level code to get a lot of tests done efficiently.

Your interview should evolve with technology.

If your team is programming ASP and JavaScript then ask the candidate to solve a typical problem from your world using up-to-date tools. To some extent coding is coding, but asking twenty year old questions isn’t good. It makes you look like a dinosaur and it might make a strong candidate look weak because they learned a different language than you in college.

We have to solve messy problems at work, ask them messy technical questions.

Being able to write efficient, elegant C code is a great skill. But the kinds of “computer science” questions I see a lot of have many problems. First, people who studied them in college might have memorized the algorithms and seem good, but then fail to be able to solve real problems. Second, people can and do study up on common questions. You don’t want someone with such a limited toolbox. Third, they don’t map well to the problems you are solving every day.

Really good interview questions have many “correct” answers and a good candidate will be able to show off a variety of skills solving them. You will also be able to spot general areas of weakness better and delve into them.

Don’t rely on pass/fail questions.

There are a lot of questions that require a leap of intuition to solve. Just because someone didn’t make the leap in the limited amount of time for the interview doesn’t mean much. It’s ok to ask some very short questions that assess a general skill level. Just don’t rely on questions with a “clever” answer.

A good example of a skill level question might be “write a sql select to join these two tables.” It’s short, and it’s pass fail. A common example of a “leap of intuition” question is a question about testing light bulbs you can’t see with switches you can. I won’t give away the answer but there is no systematic approach to solving it. You just have to “think outside the box” and come up with the one and only answer the interviewer is hoping for.

Those questions are poor predictors of problem solving ability. Some people get them right away, others who are very smart never do. Make sure your questions have a way to keep making incremental progress with a systematic approach. After all, that’s what we do in our jobs every day.

Leverage diversity.

If you work at Microsoft then the formal interview process here helps a lot with this. If you interview for another company, make sure you are leveraging the diverse talents on your team for interviews. Even if your company has a good process, make sure you implement it well.

This means technical interviews should be a minimum of four hours for the candidate and they should see at least 4 people with diverse questions and ways of thinking.

Cover “soft skills” equally with technical skills.

Asking questions like “tell me about a time when you…” are really good predictors of future behavior. Make sure someone on your team is going to be asking these questions. All technical interviewers in an interview will get you people who are technically great, but probably lacking some core attribute your team prizes.

Make sure soft skill questions get equal time with technical ones.

Probe for weaknesses and hand those off to the next interviewer to expand on.

You will probably only spend an hour with a candidate. Try to make a note of what you perceive weaknesses are and work with the rest of your team to probe the candidate more deeply. Sometimes this flushes out a weak candidate. Sometimes the follow up questions are met strongly by the candidate and you can stop worrying about that area.

Communicating with your team during the process is important. Don’t hand a candidate off until the next person has feedback of some kind to go off.

Face your own biases.

If a candidate doesn’t seem to understand your questions you have to ask a tough question. Is it a weak candidate or just someone I am not in tune with? Differences in culture can magnify even the smallest communication problems. When you perceive a weakness in a candidate be honest with yourself and make sure the weakness isn’t a bias in yourself.

A candidate that doesn’t understand your questions may just be lacking cultural context to interpret your body language. A candidate that doesn’t seem forceful enough or who seems too forceful may just be triggering your biases. I work with some excellent people from various cultures who don’t conform to the norms I am used to.

Don’t rob yourself of excellent talent for stupid and possibly illegal reasons.

Create a winning team by paying attention to how you interview.

Take a hard look at your interviewing practices. It’s vital we get this right in order to build strong teams. Strong teams deliver great software and that’s what we all want.

Special Thanks to Patent Analyst David Andrews for collaborating with me on this essay.