Take the 2-minute tour ×
The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It's 100% free, no registration required.

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".

share|improve this question
26  
This is unreasonable, so it is best to assume the worst case scenario based on the information at hand. FACT: Large organizations where software is a cost center and are not led by Engineers at the C-level will retain low quality engineers and drive away high quality engineers. You do not need to know anymore information than that. This is almost invariably a universal rule. –  maple_shaft Feb 25 '13 at 17:52
22  
I would say that you should be able to tell a lot about the quality of the engineers by the questions that they ask you. –  17 of 26 Feb 25 '13 at 17:57
8  
Treat all of your candidate companies equally. I've interviewed at well-known companies who I thought would would have it together but didn't and obscure companies who surprised me and really did. –  Blrfl Feb 25 '13 at 18:20
31  
Putting "fact" in bold doesn't actually make it a fact. It's still your opinion. –  nadyne Feb 26 '13 at 6:20
12  
You often don't want to actually test their programming capabilities - that's your job. You want to find out their project management skills. There are plenty of perfectly safe questions that bring out the red flags of project management, like if overtime is common, team structures, recent projects, education of the heads of dept, etc. –  Muz Feb 26 '13 at 8:54

7 Answers 7

up vote 52 down vote accepted

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.

share|improve this answer
10  
Seconded. I have had success with asking about the architecture, design, and hard problems in the software ("what are your biggest technical challenges right now?" is a good entry point). As an interviewer I take positive note when candidates ask, and engage in, those kinds of questions with me. Most candidates that I've interviewed haven't done this. –  Monica Cellio Feb 25 '13 at 17:46
1  
Good advice. I think that's the core of what I'm trying to figure out; whether or not I'm joining a smart team that cares about what they're doing. –  ConditionRacer Feb 25 '13 at 18:55
5  
+1 for a way to get the type of information you want about a company while providing the same to them about you. –  Dan Neely Feb 25 '13 at 21:56

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.

share|improve this answer
6  
Also, you have come to the interview prepared to answer technical questions (hopefully). Your interviewer has had to do a whole lot of preparation of an entirely different kind. –  DJClayworth Feb 25 '13 at 17:32
5  
+1 on "surprising interviewers is bad". There are a lot of safe questions, though. My favorite interview went along the lines of discussing voice processing with a potential boss... since it was a company selling DSP devices, the boss talked about it as if it were a hobby. Try to instead find a tangent to the interview that a skilled person would love to talk about and an unskilled person would not feel excited about. –  Muz Feb 26 '13 at 8:59
1  
+1: Feel free to ask questions, but not technical programming questions. –  deworde Feb 26 '13 at 11:28

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.

share|improve this answer
7  
Big +1 for the first paragraph. I was going to write an answer but yours sums it all up. Coding may be a proxy test of doing their job for coders, but it would be a terrible test for the managers even if they come from a dev background. –  MrFox Feb 25 '13 at 18:04
4  
I have known quite a few "A Players" that were just D programmers with A level Corporate Politics skills. –  ReallyTiredOfThisGame Feb 25 '13 at 18:46
3  
@Chad By "A Players" do you mean good managers, or high-fiving guys who leveraged their core competencies to find their inner synergies? –  MrFox Feb 26 '13 at 16:47

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.

share|improve this answer
2  
I disagree with the last sentence of your first paragraph - that you would like to get an idea of the quality of the software they build (rest of the sentence is fine). This could immediately be misconstrued as criticism of a company's product, of which the interviewer most likely has a pretty strong professional & personal investment. They would be put on the offensive, in my opinion - and besides, you should have done your homework so you already have an idea of the quality of work they've produced. –  NoCatharsis Feb 26 '13 at 5:55
1  
@NoCatharsis Most companies don't distribute their source code. I'd phrase it as "I'd like to get an idea of the environment I'll be working in", but if a senior dev gets defensive about showing you an example of the existing codebase, that's a major warning sign. –  deworde Feb 26 '13 at 11:26
1  
@NoCatharsis I'd rather hire people who are interested in finding weaknesses and improving them than people who are interested in saying the perfect answers in an interview. –  enderland Feb 26 '13 at 12:50
1  
Four of the last five companies I've worked for would have had to say 'No' to the request to view source code; for various reasons beyond the control of the person giving the interview. –  Rob P. Feb 26 '13 at 16:51

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.

share|improve this answer

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.

share|improve this answer
1  
Well I'm guessing. It's mentioned in the FAQ. workplace.stackexchange.com/faq#how-should-i-answer . You just need a thick skin until you get used to the rules. ;) –  Simon O'Doherty Feb 28 '13 at 15:57

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.