Iyfjky

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

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. — Feb 25 '13 at 17:52
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. — Feb 25 '13 at 17:57
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. — Feb 25 '13 at 18:20
Putting "fact" in bold doesn't actually make it a fact. It's still your opinion. — Feb 26 '13 at 6:20
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. — Feb 26 '13 at 8:54

score 58 · Accepted Answer · 2013-02-25 20:38:19Z

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.

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. — Feb 25 '13 at 17:46
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. — Feb 25 '13 at 18:55
+1 for a way to get the type of information you want about a company while providing the same to them about you. — Feb 25 '13 at 21:56
@Justin984 What this man says is true. If you look at big companies got to where they are now, look at where they started. Valve, Microsoft, etc... They had a small team of very talented programmers, but again they were small at the time. — Feb 26 '13 at 15:30

Michael 4,7461423 · Answer 2 · 2013-02-25 17:24:54Z

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.

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. — Feb 25 '13 at 17:32
+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. — Feb 26 '13 at 8:59
+1: Feel free to ask questions, but not technical programming questions. — Feb 26 '13 at 11:28

user8365 · Answer 3 · 2013-02-25 17:45:48Z

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:

Company/product reputation

Salary (May be more of a reflection of the local job market)

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.

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. — Feb 25 '13 at 18:04
In the first point you seem to assume he would be asking someone who would be his superior, not a coworker. — Feb 25 '13 at 18:12
I have known quite a few "A Players" that were just D programmers with A level Corporate Politics skills. — Feb 25 '13 at 18:46
@Chad By "A Players" do you mean good managers, or high-fiving guys who leveraged their core competencies to find their inner synergies? — Feb 26 '13 at 16:47

Brian 20112 · Answer 4 · 2013-02-25 21:51:03Z

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.

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. — Feb 26 '13 at 5:55
@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. — Feb 26 '13 at 11:26
@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. — Feb 26 '13 at 12:50
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. — Feb 26 '13 at 16:51

bethlakshmi 70.4k4136277 · Answer 5 · 2013-02-26 15:48:10Z

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.

Erik Reppen 2,99021217 · Answer 6 · 2013-02-27 02:54:48Z

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.

happybuddha 4,31152752 · Answer 7 · 2013-02-26 14:22:51Z

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.

hmm, this wasn't useful ? Cool. I would be greatly enlightened if whoever down voted can tell why this dont help ? — Feb 26 '13 at 22:15
Thanks Simon. I never knew I couldn't be anecdotal. I can never understand what could be better than anecdotal incidents. — Feb 28 '13 at 15:39
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. ;) — Feb 28 '13 at 15:57
Got'ya. But just in case someone does read the FAQ, it states : Please note that answers should be backed up either with a reference, or experiences that happened to you personally....but am on my way to thicken up my skin. lol. cheers :) — Mar 5 '13 at 15:08

Rob 1,628316 · Answer 8 · 2018-02-14 14:44:42Z

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

Always try to find out as much as you can prior to applying for a job.

Check Blogs, Stock performance, DnB, GlassDoor, etc.

Try to get an Informational Interview, sometimes the owner or management has time for this (so you get to know a bit about who you are working for, instead of meeting HR or an immediate superior). It's not a "Job Interview", it's a grillin' just like you asked for. Don't expect an answer about being hired or even for them to be hiring; it sure works out great if they know another place that is hiring and provide a specific contact, that's a great in.

Next up is when that call comes in, in the first place, ask if they are the ones whom will be interviewing; if not ask if the person is available to call you back, failing that say you'll need to find out about the next time you can get a day off, as you've had a few interviews recently ...

If it's just some lackey 'bulk calling' to see how much cattle they can round up don't get caught in the snare; particularly if your prior research pointed to problems or turnover.

If the balls in your court don't pass it to the opposition. Many times I've let the call go to the answering machine (or VM) and found that if I call them after I would have arrived home from work (very late afternoon) or during first break the next day that they are far more malleable; if not you'll have to find out about time off, and call them back.

Sometimes they're a bit excited until you explain that this is the first chance during business hours to call, you received the call when you got home and returned the call on your first break - see that they are completely satisfied and happy, then go with a couple of key questions.

Sometimes they've spent all day messing with everyone and they know they're coming to the end of the list, if they don't quit messing and start listening they'll hire no one.

If they don't know that's the best: "... well thanks anyways"; watch them turn on a dime 'No, hang on a sec. ...'.

Either way everyone else's efforts will have taken their toll without you being the bad guy. They can't be too big a wheel because not only would they have people to call without ever reaching out to you, but you can be certain that they don't pay too much - even if they do pay a lot they probably want more than an average workload or are trying to combat turnover.

There's really little need for them to reach out to strangers, that's probably why you're getting the 3rd Degree too; they would already have people on layoffs or the so-called 'perfect person' whom submitted a CV months ago. Also everyone has contacts at and from School.

Many places like fronting with nothing on the table but moose pie - don't get sucked in.

Many places run a business that way, they rake you over the coals to get in so they know you'll be happy with a lowball and infrequent small raises for years - thus the turnover. The company has debt they want paid to cover poor management and big losses, it's your contribution hard work and some of your paycheck that fuels the business.

This applies mostly to the biggest businesses whom are expert in manipulating and negotiations, and the smallest businesses whom claim either not to be able to afford or think they can shrug and claim ignorance - but the last few dozen people all told them the same, cost of living is X, plus I want to save Y% per month so you pay $Z.

It depends upon the Market.

If you choose a career where there's too many people with Student Loans to pay off or that kind of job simply doesn't pay much but has a lot of people interested in it (think Post Office) then you're paddling upriver.

If you're the one who's going to fix everything and turn it all around, combined with a severe shortage of talented people in your field, then they may well let you walk (at their peril) or they'll know not to mess around - this time, or when you reapply in a few years.

Know your business, education is key along with interview experience; you will be able to smell your way through the first call and interview and know if they ought to hire you the next time they call, or if you must bend for them.

Everyone needs to get onboard, if there's too much competition or sheep they'll be looking to pull the wool over your eyes and keep you from the future you deserve to earn.

This answer has little to do with the question asked. Nowhere in the question did the OP say anything about being cold-called, which the bulk of your answer addresses. — Feb 14 at 17:28
@shoover - My answer is nothing about being cold-called, it's about researching places that you think you are interested in and how to leverage the ability to ask questions prior to taking time off work to attend one or more interviews; presumably they call you after reading your resume. I've never heard of employers randomly calling people to determine if they would like to work for the company. What has been your success doing that? — Feb 14 at 18:18

score 58 · Accepted Answer · 2013-02-25 20:38:19Z

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.

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. — Feb 25 '13 at 17:46
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. — Feb 25 '13 at 18:55
+1 for a way to get the type of information you want about a company while providing the same to them about you. — Feb 25 '13 at 21:56
@Justin984 What this man says is true. If you look at big companies got to where they are now, look at where they started. Valve, Microsoft, etc... They had a small team of very talented programmers, but again they were small at the time. — Feb 26 '13 at 15:30

Michael 4,7461423 · Answer 10 · 2013-02-25 17:24:54Z

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.

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. — Feb 25 '13 at 17:32
+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. — Feb 26 '13 at 8:59
+1: Feel free to ask questions, but not technical programming questions. — Feb 26 '13 at 11:28

user8365 · Answer 11 · 2013-02-25 17:45:48Z

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:

Company/product reputation

Salary (May be more of a reflection of the local job market)

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.

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. — Feb 25 '13 at 18:04
In the first point you seem to assume he would be asking someone who would be his superior, not a coworker. — Feb 25 '13 at 18:12
I have known quite a few "A Players" that were just D programmers with A level Corporate Politics skills. — Feb 25 '13 at 18:46
@Chad By "A Players" do you mean good managers, or high-fiving guys who leveraged their core competencies to find their inner synergies? — Feb 26 '13 at 16:47

Brian 20112 · Answer 12 · 2013-02-25 21:51:03Z

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.

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. — Feb 26 '13 at 5:55
@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. — Feb 26 '13 at 11:26
@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. — Feb 26 '13 at 12:50
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. — Feb 26 '13 at 16:51

bethlakshmi 70.4k4136277 · Answer 13 · 2013-02-26 15:48:10Z

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.

Erik Reppen 2,99021217 · Answer 14 · 2013-02-27 02:54:48Z

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.

happybuddha 4,31152752 · Answer 15 · 2013-02-26 14:22:51Z

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.

hmm, this wasn't useful ? Cool. I would be greatly enlightened if whoever down voted can tell why this dont help ? — Feb 26 '13 at 22:15
Thanks Simon. I never knew I couldn't be anecdotal. I can never understand what could be better than anecdotal incidents. — Feb 28 '13 at 15:39
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. ;) — Feb 28 '13 at 15:57
Got'ya. But just in case someone does read the FAQ, it states : Please note that answers should be backed up either with a reference, or experiences that happened to you personally....but am on my way to thicken up my skin. lol. cheers :) — Mar 5 '13 at 15:08

Rob 1,628316 · Answer 16 · 2018-02-14 14:44:42Z

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

Always try to find out as much as you can prior to applying for a job.

Check Blogs, Stock performance, DnB, GlassDoor, etc.

Try to get an Informational Interview, sometimes the owner or management has time for this (so you get to know a bit about who you are working for, instead of meeting HR or an immediate superior). It's not a "Job Interview", it's a grillin' just like you asked for. Don't expect an answer about being hired or even for them to be hiring; it sure works out great if they know another place that is hiring and provide a specific contact, that's a great in.

Next up is when that call comes in, in the first place, ask if they are the ones whom will be interviewing; if not ask if the person is available to call you back, failing that say you'll need to find out about the next time you can get a day off, as you've had a few interviews recently ...

If it's just some lackey 'bulk calling' to see how much cattle they can round up don't get caught in the snare; particularly if your prior research pointed to problems or turnover.

If the balls in your court don't pass it to the opposition. Many times I've let the call go to the answering machine (or VM) and found that if I call them after I would have arrived home from work (very late afternoon) or during first break the next day that they are far more malleable; if not you'll have to find out about time off, and call them back.

Sometimes they're a bit excited until you explain that this is the first chance during business hours to call, you received the call when you got home and returned the call on your first break - see that they are completely satisfied and happy, then go with a couple of key questions.

Sometimes they've spent all day messing with everyone and they know they're coming to the end of the list, if they don't quit messing and start listening they'll hire no one.

If they don't know that's the best: "... well thanks anyways"; watch them turn on a dime 'No, hang on a sec. ...'.

Either way everyone else's efforts will have taken their toll without you being the bad guy. They can't be too big a wheel because not only would they have people to call without ever reaching out to you, but you can be certain that they don't pay too much - even if they do pay a lot they probably want more than an average workload or are trying to combat turnover.

There's really little need for them to reach out to strangers, that's probably why you're getting the 3rd Degree too; they would already have people on layoffs or the so-called 'perfect person' whom submitted a CV months ago. Also everyone has contacts at and from School.

Many places like fronting with nothing on the table but moose pie - don't get sucked in.

Many places run a business that way, they rake you over the coals to get in so they know you'll be happy with a lowball and infrequent small raises for years - thus the turnover. The company has debt they want paid to cover poor management and big losses, it's your contribution hard work and some of your paycheck that fuels the business.

This applies mostly to the biggest businesses whom are expert in manipulating and negotiations, and the smallest businesses whom claim either not to be able to afford or think they can shrug and claim ignorance - but the last few dozen people all told them the same, cost of living is X, plus I want to save Y% per month so you pay $Z.

It depends upon the Market.

If you choose a career where there's too many people with Student Loans to pay off or that kind of job simply doesn't pay much but has a lot of people interested in it (think Post Office) then you're paddling upriver.

If you're the one who's going to fix everything and turn it all around, combined with a severe shortage of talented people in your field, then they may well let you walk (at their peril) or they'll know not to mess around - this time, or when you reapply in a few years.

Know your business, education is key along with interview experience; you will be able to smell your way through the first call and interview and know if they ought to hire you the next time they call, or if you must bend for them.

Everyone needs to get onboard, if there's too much competition or sheep they'll be looking to pull the wool over your eyes and keep you from the future you deserve to earn.

This answer has little to do with the question asked. Nowhere in the question did the OP say anything about being cold-called, which the bulk of your answer addresses. — Feb 14 at 17:28
@shoover - My answer is nothing about being cold-called, it's about researching places that you think you are interested in and how to leverage the ability to ask questions prior to taking time off work to attend one or more interviews; presumably they call you after reading your resume. I've never heard of employers randomly calling people to determine if they would like to work for the company. What has been your success doing that? — Feb 14 at 18:18

Search This Blog

Iyfjky

Is it reasonable to quiz the interviewer during technical interviews?

8 Answers
8

Your Answer

Post as a guest

8 Answers
8

8 Answers
8

Post as a guest

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

Category

Random preview

Is it reasonable to quiz the interviewer during technical interviews?

8 Answers 8

Your Answer

Sign up or log in

Post as a guest

Post as a guest

8 Answers 8

8 Answers 8

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

8 Answers
8

8 Answers
8

8 Answers
8