How do I interview a senior developer without pissing him off?

Question

I'm a mid/seniorish level developer myself. I've interviewed many junior level developers, fresh out of college looking for their first job. So I've read up on things like Joel's Guerrilla Guide to interviewing - http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html and I agree that it's a great way to structure that in-person meeting.

A lot of the stuff in there seems more geared towards junior devs just getting started in their careers. Asking the guys to sketch out some code, for example. Is this kind of stuff relevant for when interviewing a Senior developer? Would it be insulting to ask these kinds of questions to somebody who boasts building entire Enterprise systems on his resume?

Answer 1

Do you know that he is a senior developer (i.e. is he an internal candidate)? I think that all external candidates should go to some basic questions, as people often lie... erm... i mean exaggerate on their CVs.

The rest should then be geared more towards whatever you are hiring of course.

Answer 2

I agree with Michael, unless you are already sure this person is competent as a senior developer, you need to ask him some technical questions. Just because someone has been doing this for 10 years, doesn't mean they are any good at it. I've worked with people that had been programmers for years, and they were horrible at it.

Answer 3

Just ask questions related to what the candidate is expected to do.

In other words, if you expect a candidate to write software then they should NOT be insulted when you ask them to sketch out some code (maybe not FizzBuzz, but something a little meatier :).

If they're interviewing for an Architect-type role, make sure you ask them architect-y questions.

Remember: an interview goes both ways. It's a bit disingenuous to ask someone to write FizzBuzz on a whiteboard during the interview and expect them to write BigTable on their first day :).

Answer 4

Ask the basic questions! You won't piss anyone off. If they do get pissed off, you don't want them to work for you. Senior Developers like anyone else want to make a good impression, and they will be happy to answer your basic questions. You probably don't want to ask them in a condescending manner, and you can even apologize for their simplicity before you ask them, but I can tell you that I have hired more than one senior developer based on wonderful high-level discussions, only to find out that they didn't know what a hashtable is. Once we started asking even senior developers these basic questions, I was pretty amazed how many we could quickly weed out.

Answer 5

I'm only a senior wannabe but I think it is very important to also asks basic questions to a senior developer (about pointers, bits and bytes, regex...). A CV may contains a lot of impressive achievements but it doesn't mean the produced code is of good quality.

I would also recommend you to review in detail (code, screenshots,...) one of the system he developed.

Answer 6

I think Jeff's description of what they did at his old place was really good - they made them sit down and build a really simple app using the same tools that they would be using if they got the job. I think this is far better than mindbenders or puzzle questions that they may already be familiar with, and it will reveal far more about their approach to real work.

Don't be afraid to make them show their stuff - good candidates are desperate to show you what they know and this is an excellent, non-contrived exercise to put them through.

Two options - with Google and without Google. If you want to really test them, tell them they can't refer to anything online. Or tell them to see how far they get on their own, but then allow them online access.

I suggest you stay in the room the whole time and see what they do; you can have conversations about little things then and really get a feel for how they tick. for a senior position I think this would be a really good use of a day for both of you.

Remember, it is really hard to get rid of people so it's much better to risk offending someone than to accept a bad candidate. I did, and it made my life and that of my team really miserable for three months.

By all means make this a second interview exercise, if you want to be sure they're worth the effort

Answer 7

When I've interviewed people I always asked to see a portfolio. I'm amazed by how few people can or will scrape anything together. So many would show up with nothing at all! I want Show & Tell. Not just Tell.

Answer 8

Some people are very good at BSing and make what I call BS hopping all their life, going from one company to the other and bailing out right before the company is about to find out they are totally incompetant.

Senior or not, ask the basics, first, and don't apologize. If she reacts aggressively, don't hire her.

I once interviewed what seemed like a very competant software engineer with 20 years experience, recommended by one of our technical director to which I've had a lot of respect. 45 minutes into the interview I had a hitch and decided to ask the basic set of programming questions anyway. We apologized before asking a very simple programming question about "finding a specific character in a string" and to our disbelief... the guy couldn't write a single line of code. After a minute of awkward silence he tried to BS his way out by saying it was too easy, that he couldn't write code on paper and whatnot.

Had we asked this question first without discrimination, the interview would have been much shorter. We later found out that the director didn't really recommend him but rather simply dropped a résumé that looked interesting to HR who assumed it was a recommendation.

In conclusion, as Joel said, always ask programming questions when interviewing programmers. That's what you will be paying her for in the next few years so she better be good at it.

Answer 9

I always ask what they personally delivered on the projects they worked on, as distinct from the "we" that you often hear. Helps to identify anyone who might have been flying under the radar.

Answer 10

When I was on the other side of the desk, being interviewed, I was rarely asked technical questions. I think the companies that I worked for (large banks, entertainment/hospitality, energy/utilities) wanted to make sure that I was technical to some degree - yes; but looking back at those days, I think, mainly, they were looking for a personality fit. The wrong person on a programming team can destroy everything. Technical people can learn anything - in the correct environment.

Answer 11

Way back when I was a mainframe COBOL programmer I did a telephone interview with some guy who proceeded to ask me a bunch of questions he apparently dug out of some textbooks. One question had to do with calculating block sizes for VSAM files (after I told him I had not worked much with VSAM -- I was a DB2 and IMS/DB guy). I cheerfully told him that I didn't have a clue. Another really nifty question (my favorite) was what the difference was between an implicit and explicit scope terminator. Again, I had no clue (turns out the implicit scope terminator is the period and the explicit scope terminator is the END-IF in an If statement). There were some others. It was like judging how well a person could speak English based on whether they could answer arcane grammar questions.

I had been coding COBOL for 12 years at that point and had passed a number of interviews where they asked me to put code on whiteboards, and had been responsible for developing and maintaining some fairly large applications, including one where I was the sole developer maintaining a system used to track stolen vehicles, wanted and missing persons, and deliver criminal history information for law-enforcement agencies statewide. I probably had somewhere in the vicinity of a couple hundred thousand lines of code under my belt, and their conclusion was that I couldn't program in COBOL.

Answer 12

Think about the communication in the situation of an interview. How well does the candidate explain things, what level of terms do they use, are you finding his answer interesting or appealing or is it standard boilerplate? There are many things to look for even in coding a simple little problem.

Another thought with some of these basic questions is that there may be a story there about "How this one time at band camp..." that can be entertaining as well as give an idea of what the person may be like on the job.

I think it would be more insulting if you respond in a derogatory manner like, "What kind of crap answer is that?" That can test one's patience as well as be a sign for some folks that this may not be where they want to work if things go bad.

Answer 13

I always start out with a few basic technical questions no matter what the supposed experience of the developer. You'd be surprised by how many "senior" people can't answer them. Also, always make sure to ask a programming question of some sort as well. I know that sometimes people can blank trying to code in front of a whiteboard and it's definitely a different environment from sitting in front of a computer but even a simple question can give you great insight into the candidate.

I've been interviewed at places that gave me a laptop not connected to the network, a simple editor, and a command line prompt with acces to man pages and asked me to write a program that took some arguments and and did some basic processing of that data. I thought it was a great idea and having a compiler and the ability to run a few tests to validate your input is perhaps closer to a real world scenario. All of that said, trying to figure out if someone will be able to write good maintainable code is a very challenging task. I've also interviewed at places that asked for sample code which can be a bit tricky sometimes if most of a developer's work has been at companies where they are unable to provide you samples of the code for legal reasons and they don't spend a lot of time contributing to open source projects or hobby coding. It's also hard to know if they actually wrote all of the code they give you themselves. I prefer a simple in-person coding question to remove any complications or doubts.

After some basics, depending on how they answer you may get a sense of how good they are and might choose to cut off some of the basic technical questions a bit early and ask some more difficult questions or probe more deeply on certain topics. Also, you may be worried about offending a "senior" developer but any good developer worth hiring shouldn't be offended by these sorts of questions. You might on the other hand give some experienced developers doubts about your company and whether or not you do a thorough job screening candidates if you don't cover some of the basics so keep that in mind as well.

Answer 14

I'd like to add that you should always have a prospective candidate type something for you. Preferably some code, of course, but I can think of at least one hiring disaster that would have been completely avoided if I would have seen the candidate type some code, any code, during the interview process. I don't think the Fizz Buzz problem is too simple at all. There is a dangerous class of people who can talk like they invented OOP and would probably make very good academics but, for whatever reason, are entirely unable to translate that wealth of conceptual knowledge into living, breathing code. I believe you can see that disability unfold before your eyes even with a problem as simple as Fizz-Buzz. A sharp programmer will (accounting for nervousness) smoothly write a simple, clean implementation of Fizz-Buzz, while the one you don't want to hire will poke at the keyboard with two clumsy fingers, reach for the backspace key two or three times for each character they type, will get confused once or twice, and may attempt to derail the programming exercise by engaging you in another theoretical conversation during the process. I also believe you will discover, if you observe closely, whether or not the candidate enjoys the idea of coding (you can tell that from your conversations) or also is thrilled by the actual practice of programming, which you should be able to see from how they interact with a simple exercise.