Is it reasonable to quiz the interviewer during technical interviews?

Question

I am interviewing with a few companies right now as a software developer. Some of them are well known so I have no doubts about the quality of their engineers. Some however, are less well known, or are companies who's primary product is not software. For these companies, I want to make sure that I am moving to a company who values quality software and employs experienced engineers.

In these cases, is it reasonable during technical interviews, to quiz the interviewer as well. I don't mean, "What kind of source control do you use". I'm thinking more like "Write an efficient algorithm to copy this singly linked list".

Answer 1

Presumably, you are trying to determine how likely it is that you will be working with smart people if you take the job. Plenty of large software companies that hire large numbers of really smart people have individual groups and divisions populated by mediocre developers, after all. Going by the size and/or reputation of the company is a relatively poor way to determine this.

It makes far more sense to ask the interviewer about the development environment (source control, build management, etc.) and about the particular software that the group you'd be working in develops. Most interviewers will be quite happy to do things like diagram the data flows of the product you'd be working on, discuss the high-level architecture, or discuss how various technologies are used in addition to answering basic questions about how source code is controlled and how builds are managed. This sort of architecture discussion tends to be much more illuminating about the type of work you're likely to be doing than would the interviewer's explanation of how to reverse a linked list. You can see whether the types of problems you are going to be asked to solve are likely to be problems you'll find interesting, whether the match of technologies and architectural approaches makes sense to you, etc. And you can more easily drill down into areas of concern (i.e. "Why does it take X hours to do Y?") that can show where the group is likely to have deficiencies.

Trying to quiz an interviewer is unlikely to be helpful for you if your intention is to get the job. Even if the interviewer can answer your questions, you'll be taking away from the time they have to determine whether they're completely convinced that you'd be a good hire. And most interviewers are going to be put off by that sort of question. Since there are much better questions that you could be asking about the particular application(s) that you'd be working on, there is really no benefit to trying to ask this sort of trivia question.

Answer 2

You can, and although I could answer these questions in the interview, I would not look favourably on a candidate who tried.

For one, an interview is usually quite a short time, (we typically do an hour), it's hard enough to get a good assessment of a candidate in that time, attempting to solve the candidates trivia just eats into that time.

Aside from that, I'd not advise it because in general, surprising your interviewers is bad, making them feel stupid is bad and I would question the wisdom of "experienced engineers need to be able to write efficient algorithms to copy this singly linked list".

Stick to the environment questions, they give a fairly good indication as to the quality values of the company.

Answer 3

There are team leaders/managers who don't/can't write code, but have done a great job of assembling a quality team and creating a thriving environment. You wouldn't want them to turn the tables and ask you a question about creating a budget.

There are other indicators to identify how many "A" players they have:

1. Company/product reputation
2. Salary (May be more of a reflection of the local job market)
3. Overview of their design and development process. Give them the Joel Test if you wish.

If they have one engineer out of a hundred who inteviews you and happens to know the answer to your questions, you may not have learned much.

Answer 4

Instead of asking an interviewer to perform tedious programming tasks during the interview, maybe you could ask if they make any open source contributions and/or if they have any sample code you can legally view. Explain you'd like to get an idea of the quality of the software they build, and coding style they employ, etc.

I've had interviewers show me company code. I've viewed a company's open source code before going to an interview. I've had interview programming tasks that included writing an implementation of an interesting interface they had designed, trying to get it to pass unit tests they had written. These all help get a feel for the quality and style of code the company writes, without annoying them or creating not-fun work for a busy interviewer.

Answer 5

I'm not sure you're going to get what you want out of that quiz.

I'm figuring that a significant majority of the interviews out there fit a profile of:

• a manager or the hiring manager is somewhere close to first in line for the interview
• you may interview with a secondary manager who is a peer to the first, or the manager's manager (depending on the organization's process)
• you may, after some number of managers, have a peer interview or a team interview

Certainly, there are companies that break this model, and do peer interviews first or something even more creative. But in my experience, the list above is pretty typical. Dealing with the overhead work of initially finding candidates is often relegated to mid level managers since they can make the context switch easily and have a pretty good basis for judging what they want and need.

I point this out, because I don't know about you, but I don't see is as ideal for my boss to know as much if not more about the nitty gritty details of how to do my job than I do. He's hiring me to be his expert. If he wanted to be the expert, he wouldn't bother to hire me. So I'm confused on why you want your manager to be able to answer something as nitty gritty as efficient algorithms to copy singly linked lists.

I think if you find a manager who can answer this question, right off the top of his, with no hemming and hawing about how long it's been since he did this kind of work... then you have found a manager who is likely to micro-manage you - his head is more in your job than his own.

Instead, I would advocate for making enough inquiries to see if you have a good management culture and one in which a good software developer can thrive. My top ten of management requirements for software engineers would be:

• interested in the day to day problems of software engineers, good sample question - "what have been some recent problems your team has had to work through?" then look for the degree of passion and engagement and whether he's misusing terms.

• basic knowledge of the craft, and core processes, with strong understanding of the purpose of the software - "what is your current project? Can you give me examples of what software process you used and how your team makes use of it?" - no lifecycle or process ever works exactly how the books/websites say it should... so how has the team customized it to fit their needs? "what's a software lifecycle?" is a very bad sign, but if there's an answer, do you agree with it? For example - "we found that 2 week sprints didn't give us time to fully test, so we moved to 3 weeks and hope to improve automated test efficiency this year" might be OK. But "we found that we can't test in a sprint, so we're delaying all integrated testing until the end of the project" is a danger sign that both the manager and the team are in the dark on the goal of this particular lifecycle.

• Has a solid plan, not just a hazy vision for developing his team's skills - "what's your policy on continuing education?" is a standard question, but don't let him get away with "our company offers X dollars a year, you're free to submit an application, more corporate HR provided blather" - push a bit. How many people too training last year? What does he see as gaps in the team? What works better for the organization - conferences, college classes, bootcamps? What does he do to keep himself up to date, what are his bare minimum expectations for his team? How does the team do knowledge sharing?

• has his gang's back in a corporate battle - no team will ever totally win (or we'd all be working in offices which are 10/10 on the Joel Test), but how does this guy get his team's back in the software team meets Corporation that Does Other Things conflict. A particular area is requirements elicitation and bug fixing - those are usually the two areas where things don't ever work to complete satisfaction, and where the manager has to be an active participant to make sure the team is optimally productive, while users aren't going nuts. How does this work, what role does the manager play in resolving conflict and setting expectations.

If you get to a peer....

So, I realize that in at least some contexts, you have the option to talk to a peer. I really still wouldn't ask a very "quiz-like" question that could come off as slightly offensive.

But I would aim to engage in a serious discussion that shows you that you're talking to someone smart. This has 2-way benefit - when two people have an intelligent, interesting discussion, both usually walk away thinking "that guy was smart, helpful and fun to work with" - which is exactly the response you want to evoke as well as recieve when you do a peer interview. As a manager, this what I usually aim for when setting up a peer interview with one of my people (and being a clever manager, I send the smart, charismatic people on my team... not the dull, conversationally-impaired, frustrating to talk to people - you can meet them after you sign on the dotted line...).

A quiz is likely to evoke a bland answer, a question about current challenges and recent gotchas is likely to evoke a serious discussion that will show you what it's like to work with this person. So I'd ask:

• what's the big unknown or problem on your team today? - and then look to get involved in the solution - "have you tried...?", "what about?", "hmm... I've never worked with that, tell me more..." - are all good follow ups.

• what was the best lesson learned from your previous project? (and "blink, blink... we don't do lessons learned or really any closure on our projects" is another very bad sign) - and the follow up - "what are you doing about it on this project?" is another one - after all, you want to find a culture that actively improves upon previous mistakes, as well as being a group of people smart enough to critique their own work...

These are both really just hooks - jumping off points to drill down into something solidly technical. The goal being to come as close to a real work-day discussion that will tell you if this guy is smart enough and fun enough to work with that you'll enjoy working there and thrive on the experience.

Answer 6

In my experience, it is pointless to ask architectural questions to the interviewer. I have worked on humongous architectures which took me days to get comfortable with. I wouldn't bother explaining something complicated to a person I am interviewing. One thing I really love to ask in interviews is "how do you solve business problems ?" If the interviewer speaks the truth, most of the times that answer reveals a lot of things including how happy/content you will be at the job. That is of course, if you want to be a good software engineer. I have interviewed a dime a dozen lazy blokes who just wanted a job to pay their bills.
With time, I have learnt, one doesn't always get to work with people who s/he can look up to. The greatest technical people who have interviewed me were always only bothered about how I 'thought through' for a solution to a given problem. I do the same. Look at how a person can think through a problem. If the interviewer is bent on you to show your memory skills of how well you remember the api, I would be skeptical.

Answer 7

If you're goal is something other than getting hired it might. You can however get at what they know subtly without putting the screws back on them. Like asking for clarity when they're being vague about something you suspect they probably didn't know before Googling for interview questions the night before for instance.

But the important thing to remember is that while interviewing really is and should be treated as a two-way sell, you're the one selling talent and they're the ones selling opportunity. Mucking with that it is understandably going to annoy people.