Some of the most obnoxious interviews I’ve been in are when I am asked to describe when I might use the C++ keyword “volatile” and what it means. Honestly, does this say anything about my competence as an engineer? Isn’t that why I spent $50.00 on the C++ reference book sitting on my book shelf (by the way, I did answer the question correctly)?

I also don’t agree with this interviewing technique of making me “think on the spot.” This is not real engineering. No one is asked to design a controller for a memory device in 10 minutes.

Basically here, I am disagreeing with Joel. I think the latter two “passion for technology,” and “attitude” are the important things to interview for. I think he was right when he said not to interview for experience. I would add to that, not interviewing for intelligence. This can be gleaned from a resume or transcripts. Anyone graduated with an MS or higher with a reasonable GPA can be considered intelligent. In fact, I have felt nearly insulted at times when interviewing and the interviewer asks me some basic programming question. In my mind I’m thinking “didn’t I learn that in CS 101?” Basically, if I am called onsite to interview then I assume you recognize there is some level of intelligence and it is adequate for your needs. The real question is whether or not I can solve problems.

So now that I’ve said what I don’t think is important, let me offer some suggestions for what IS important in my mind. I appreciate when interviewers ask detailed questions about my past projects and or research. This shows they care about my ability to solve problems. That’s what engineering is all about after all. It is not about my ability to recall all the C++ keywords on the spot. I think we can all agree that that does not make a good programmer.

After initial screening, during the interview process, the goal should be to find out how good an engineer I am. How well can I solve problems? The kind of problem doesn’t matter. A good engineer is characterized by how well he can take what he knows and combine that with what he doesn’t know, but will find out, to solve a problem. This information can be discovered by discussing in detail my previous work. When I say “discussing in detail” I mean very literally have the applicant draw block diagrams on the board. Ask them to write down UML diagrams and schematics. Ask them to describe the thought process and the approach to solving the problem. And for software engineering please ask about their coding style, and debugging techniques they have used. These may be just as important as how well they solve problems.

Lastly, there are things I want to say about these greuling interviews. As I have interviewed often the process goes like this. Fly 1000 miles somewhere (often at a very inconvenient time since I had other things going on). Pick up a rental car and try to navigate a foriegn city. Get to my hotel late at night and try to get some sleep. Wake up at 5:00 a.m. so I can get ready and have enough time to navigate the foreign city again. Now I’m at the site and begin interviewing. Somehow I’m supposed to answer technical questions even though I’m dog tired, and I need to have the presence of mind to ask good questions which I will probably forget anyway since I’m interviewing with 8 people in one day. Aside from me being interviewed, I am also interviewing them as a potential employer. That means that in spite of all that’s going on, I need to make some sort of judgments about this place and the projects and people here. After interviews I have to navigate the strange city again back to my hotel, or maybe straight to the airport for another 1000 mile trip home most likely arriving at a very awkward hour.

My point is that, being an interviewee is very taxing. Keep that in mind. Also keep in mind in interviewing that the employer is also being judged. I remember one place I interviewed with in which one gentlemen bad-mouthed the other places I had interviewed with. I immediately formed a negative opinion and it was easy to decline their offer.

I hope some of my rambling has been useful for seeing things from the other side of the interviewing table.

[JPD: Thanks for the comments, Justin. You would be shocked at the number of people who come into interviews with what seem like ideal pedigrees and yet perform miserably in very basic questions: reverse a string in the language of your choice, help me understand the architecture of a major coding project you worked on, etc. Divining which candidates will work out for your company is such an important thing, and is hardly a science. I hope you do well in your interviews!]

After that, I met individually with four of the department heads from various areas. One was the head of Engineering, one was the head of Finance, one was the COO, and last was the head of the HR department. During the interviews they asked a lot of questions, none of which were technical (this was for the CIO role). They asked many situational questions or “how would you do this” or “how would you respond to this”. I answered them and thought that I gave good answers.

After the individual interviews were completed, we met as a group again. The CEO then asked each of the department heads that I interviewed with how I did in the interview with them. They were honest and candid about what they liked and didn’t like about me. That was interesting being in an interview and being critiqued and given feedback on the interview in a large group setting. Then came the intelligence test. The department heads discussed with the group what questions they asked me and then they asked me to summarize my response to each of the questions. This may not seem a big deal, but when you just spent several hours answering questions (sometimes the same questions) and then trying to remember exactly what you said, it is not that easy. What I realized after a few minutes is that the department manages wrote down a summary of my answers and if I strayed from what I was repeating back they would let me know. So I ended up having to summarize hours of answers in front of 12 people. I suppose I did ok because they offered me the job, but I decided it was not the right job for me for some other reasons.

This was a very interesting interview technique and I have never forgotten it. I use this in my interviews I do now and find that it does help me know if people can remember well and if they are paying attention.

I agree, you probably don’t want to spend the whole interview answering questions, because you need to find out about the candidate. On the other hand, if you aren’t willing to spend at least some of the time answering questions that are important to the person being interviewed, you aren’t going to get the good candidates. Especially when the market is good (like right now), the good people usually have other options, too. If you can’t give them good, honest, satisfactory responses to the questions that will influence their decision of where to work, they will likely go somewhere that they are more comfortable that they know what they are getting into.

You probably won’t sign someone on if they don’t (or can’t) answer your questions, so you probably shouldn’t expect them to sign on if you won’t spend at least part of the time answering theirs. Just my two bits as one who has sat on the other side of the interview desk (not with the Church, though) in the not-so-distant past.

[JPD: Agree 100%, Doug. We should always spend time answering questions, but just not cut ourselves short by spending too much time. I usually try to leave 5-10 minutes for questions in an hour long interview.]

And now, long after the fact, I realize that those three qualities will take you far no matter what the job or task.

Say what you will, but the spirit of revalation played a big part in my hiring decisions. There were some I just knew would either make it or not, but not based on anything they said. That happened more than once and it was a great comfort to me, knowing that I have “the ultimate source code” on my side.

Tom