It’s OK to verify skills in an interview
0

It’s OK to verify skills in an interview

Philip Walton: Interviewing as a Front-End Engineer in San Francisco

Walton reacts to the types of questions he got interviewing for front-end developer positions with Internet companies. He was asked lots of abstract questions and few questions about the practicalities of front-end development. I think that it’s a mistake to focus too much on a skills match when interviewing candidates, but I also think that you should verify the skills candidates claim to have in the interview process. In other words, a company that mostly uses Python shouldn’t be afraid to hire Ruby developers, but they should make sure that those Ruby developers really can program in Ruby. Front-end skills are more generalized, and it seems crazy not to interview front-end developers about those skills.

Let’s talk about interviewing programmers
6

Let’s talk about interviewing programmers

Lately, I’ve been interviewing a lot of developers. Not phone screens, but in house interviews that we use to decide whether to hire someone who’s passed the first round. In addition to trying to figure out who the good candidates are, I’m also trying to get better at interviewing.

If you’re getting started with interviewing programmers, there are a couple of must-read articles. The first is Steve Yegge’s article, The Five Essential Phone-Screen Questions. This article is incredibly well-known and I assume everyone has already read it.

The second is Joel Spolsky’s The Guerrilla Guide to Interviewing. He recommends asking an “impossible” question (as anyone who worked at Microsoft probably must). I never ask these kinds of questions. Other than that, I think he’s got it right. You want to know if they can code, if they can design something, and how well they think.

One thing that stands out to me, though, is that none of his questions tell you what kind of team member the candidate will be. This is a major deficiency as far as I’m concerned.

Basically, at the end of an interview, the one question I want answered is, “Will it suck to work with this person?” As Joel points out, it’s important to hire smart people who get things done. It’s also important to hire people who won’t make the people around them miserable. I want to hire people who are flexible enough to adapt to the company culture and open-minded enough to recognize other people’s good ideas. I also want people who are patient enough to bring other people up to speed on their work.

There are a few questions that I’ve settled into asking almost everyone. I don’t worry about people finding me on Google and knowing in advance that I’ll ask these questions because I’d just as soon they come in already knowing the answers.

I almost always lead off with, “Tell me your timeline of programming languages.” I want to know how long they’ve been programming and how many languages and platforms they’ve used in their career. All things considered, I generally prefer programmers who’ve worked extensively with multiple languages. This question is also an easy way to find out which people started programming early in life.

Next, I usually ask them about some experience from their résumé, I’ll pick a project and drill down to find out what the project was, what role they played, and how well they can explain what they worked on.

I then ask them some questions about teamwork. I’ll ask them to tell me something they learned from another developer. Many people talk not about technical concepts but about habits of work, and either sort of answer is fine. If they can’t tell me something that they’ve learned from someone else, that’s a big red flag.

I ask them to tell me something that they’ve changed their mind about when it comes to software development. If you can’t remember changing your mind about anything, you may be too stubborn to work well on a team. It turns out that lots of people have changed their mind about the ternary operator. It’s polarizing.

I will generally ask candidates how they test their own code, to find out what kinds of automated testing they use (or don’t use).

The last question I have started asking almost everyone is to tell me something that they would rewrite if they were given time. It’s a good way to get someone to talk about something they feel strongly about and also to find out what they see as good and bad code. It’s also telling if they want to rewrite something someone else wrote rather than something they wrote.

I’ll also ask a few questions about why they’re looking for a job and what interested them about the company just to get a sense of how interested they are in the position. And of course I ask them if they have any questions for me.

There are three other areas that I think are important to hit, and this is the area where I’m still working on my technique. Those are coding, design, and problem solving. The trick is to fit all of it into the short window that I usually have for the interview. At worst, if multiple people are interviewing the candidate, you should make sure that at least one person will be hitting each of these three areas.

The ideal programming question as far as I’m concerned should be simple enough to solve in a couple of minutes, and be deep enough to have multiple solutions. The best questions have at least a brute force solution and an elegant solution. You can gauge the candidates on which they come up with. I refuse to ask the famous Fibonacci sequence question. There are better alternatives. That said, if you are interviewing for programming jobs, you should be able to write a program that prints the Fibonacci sequence using a loop or using recursion. Someone will ask you to do so.

Design questions are discussed comprehensively in Steve Yegge’s article, which I linked to previously. The goal is to determine whether the candidate understands object-oriented design. The model should be simple enough that you can get past the classes and get into talking about the methods on those classes.

Finally, I think it’s good to ask a question that tests the candidate’s problem solving skills. They should be able to list possible solutions and discuss the pros and cons of each of them. I’m going to write a separate post about this type of question later.

Interviewing over Skype
2

Interviewing over Skype

This week I did a phone screen interview over Skype, with video. I was so pleased with how it went that I never want to do a regular phone screen again. I am not a big fan of interviewing people over the phone or being interviewed over the phone.

The biggest problem with doing technical interviews over the phone is that when you ask hard questions, the subject of the interview has to think about their answer, and may even need to write things down to get their answer together. When you’re talking on the phone, nothing is conveyed. There’s an awkward silence punctuated by the interviewer letting the interviewee know that it’s OK that they’re not talking while they think about it. People get more nervous, and I think it hurts the quality of their answers.

When you have video up and running during the interview, the visual contact makes pauses seem less awkward. That’s a plus.

The other problem that Skype solves is that it provides text chat as well. Some questions are a lot easier to ask when you can paste some code into the chat window and ask the person you’re interviewing to look at it. On phone screens, I’ve been known to email things to the other person during the interview, but having the text chat running alongside the Skype call is really useful.

And finally, when you have video you can get a sense of the other person’s body language. I find I really miss that in regular phone screens.

The Skype interview went so well that I’m going to suggest it for all of my phone screens in the future. Using the phone for phone screens seems archaic.

One criteria for evaluating software developer candidates
16

One criteria for evaluating software developer candidates

I’m often thinking about what qualities make for a good software developer. One attribute that I think may be important is the capacity to keep the details of a large system in your head. What I mean is, the ability when someone brings up a new feature, to quickly know exactly how it should be implement in the context of the existing system. Or, to be able to recall where the code is in the system that performs some function that needs to be added to some other part of the system. These days, between search tools and the code navigation capabilities built into the better development tools, there are lots of ways to find things in a large body of code, but I think that having a mental map of a system remains valuable. I also think that having this ability may signify the presence other valuable traits that a developer should possess. After all, it’s not fundamentally different from having a good working knowledge of the Java collections framework or the popular Ruby gems or the massive number of PHP string functions.

Two questions for Friday afternoon:

  • Am I correct in assuming this is something you should look for in developers?
  • What questions would you ask in an interview to find out whether someone possesses this quality?
Interviewing programmers on philosophy
2

Interviewing programmers on philosophy

Today I took a survey on Object Oriented Concepts. Two computer science researchers are trying to determine how divorced the theory they teach is from the day to day practices of professional programmers. Here’s the introduction:

You have done some programming for fun, or you are a professional that has been on one of those $2000 a day professional development courses, or read the latest book, or subscribed to the current in-RSS feed, so you know how you’re supposed to write good code. But do you actually write code the way you’ve been told is The Way, or do you ignore the theory and follow the tried and true practices learned the hard way in the School of Hard Knocks, the way that really works?

We’re researchers. We know what we teach and we know what all the research papers/books say, but you write the code – you know what really works and what’s just so much theory. Here’s your chance to tell us what you know.

If you’re a programmer, you may want to take the survey. I’m sure the researchers would appreciate it.

I’m so enamored with it that I think I’m going to post my answers to each of the groups of questions here, just because I wanted to add more detail and also because I think they’re interesting points of discussion.

What the survey really made me think, though, is that programmer interviews should center more on questions of philosophy. Obviously after an interview you should know whether the person you interviewed can program, but it’s also helpful to know whether you’d actually want to let that person touch your code. I think philosophical questions could extract more information that pertains to both. They also measures the thinking skills of the candidate, and their ability to communicate effectively.

Here’s one of the questions from the survey: “When working on a class, is its depth in the inheritance hierarchy important to you?”

That’s something that someone who thinks about programming could really chew on. If a candidate doesn’t even know where to start on the answer, that tells you something about them immediately. Or perhaps they answer in great detail, but their answer is the opposite of yours, and you don’t find their argument in favor of their side convincing. Do you really want to sit in meetings with this person for the next few years having this same discussion over and over? Do you want them refactoring your code because your way is different than theirs?

After responding to the survey, I want to ask other people these types of questions. They drive right at what’s important in finding good team members.

Cool idea: homework assignments for job interviews
4

Cool idea: homework assignments for job interviews

I just read a job listing for a couple of Perl programmers, and in addition the job description and the basic requirements of the job, it included two homework assignments. One was to explain why you’d use a certain programming construct in Perl, and another to explain how you’d solve a big refactoring problem that the employer must need to solve.

There are two objectives for any interview: to determine whether the person is qualified for the position in question and to determine whether the person is a good fit for the organization. The second is the easiest for me. After interviewing someone, I almost always know whether I’d enjoy working with them and whether they have the enthusiasm requisite for the job. The first is more difficult. I’ve tried a number of approaches in that regard, and I’ve not been satisfied completely with any of them.

The one I rejected first is the “trivia question” interview. I’ve been on the receiving end of this one more often than I’ve inflicted it on others. Basically you ask obscure questions with very specific answers and see if the person knows them. This is not useful for determining whether someone can develop software. I’ve also tried asking essay-type questions, like, “Explain how branches are used in the version control system of your choice.” I never feel entirely comfortable testing people that way, though. I think it’s perfectly valid and useful, but I don’t enjoy it.

Lately I’ve tried to go with what I’d call the interrogative questioning style, reviewing the person’s work experience with them. I ask them to describe projects they’ve worked on, digging deeper and deeper into the details to make sure that they really did what they claimed and figuring out whether they understand the things they claim to. I think this approach is very solid and I would encourage others to adopt it.

Another common approach (that I’ve been subjected to but haven’t used) is to ask problem solving questions that the interviewee must solve in real time. Long ago I interviewed with amazon.com and the interviewer asked questions in that vein. I think it’s effective but it’s very stressful, particularly when the interview is a phone interview. You have to take time to think about the answers, and it’s not pleasant to just sit there and think when you’re on the phone with someone.

The homework assignment is a form of the “problem solving” approach and augments the interrogative approach (or any other approach) very well. It lets the person solve the problems on their own time with all of the tools available to them that they normally have. (Asking someone to solve a problem while sitting in front of strangers and without the use of Google, books, or even having their hands on a keyboard is artificial and stressful.) By giving the assignment, the depth of their answer not only tells you something about their problem solving skills, but also about their degree of interest in the position. If they show up with a poor answer, either they aren’t qualified or they don’t care enough to deserve the job.

I’m eager for the opportunity to try out this approach.

How to Interview a Programmer

How to Interview a Programmer

How to Interview a Programmer is a link that’s making the rounds. It’s of interest to me because hiring and getting hired is a huge part of a programmer’s career. If I’m going to work with someone, I always want to be part of the interview process so that I can make sure we don’t wind up with someone that will be challenging to work with due to lack of skills or personality fit. Besides, I’m egotistical to think that I do a good job at interviewing, and often assume that other people will screw it up. I was pleased to see that my interviewing technique was described almost perfectly by one of the roundtable participants:

Chuck Allison: I talk to them. I get a feel for them. I always ask about what they’ve done. I have found that by discovering what a person is excited about technically, you can learn a lot of important things about them. In the past I’ve asked people to describe a project that was especially interesting to them, or that was challenging and successful. On occasion I’ve asked what they’ve done that they’re the most proud of. This usually reveals the depth of one’s understanding and mastery. It also gets them to turn on the fire hose verbally, and you can sit back and get most of the answers you need.

He gets right at what I go for. I want to know what the applicant is passionate about. If they aren’t passionate about writing good software, then they probably won’t get the job. I’m sure there are plenty of people out there who just do the computer thing for the money that do a good job, but I take a pass on them. The odds are just so much lower that you’ll get someone good going that route than if you go with the person that can’t imagine themselves doing anything else.

Another thing I’ve resolved to do in the future is always ask people to bring code to interviews. I’ve seen too much nightmare inducing code produced by people who I would have guessed to be good developers to skip this step. I want to see a coding standard, internal consistency in design, and an acceptable level of attention to detail in a person’s code.