What is a good non-programming question to ask a candidate during a job interview?
I'll post my two favorites below, but I'd like to hear others.
Clarification: By "non-programming," I mean you are not asking them to solve a problem by writing or describing code.
In an industry where some say fifty percent of what you know is obsolete in five years, what do you do to stay current?
I guess the answer might involve some sort of programming response, but:
Give an example of a time when you messed up. What did you learn from that?
Tell me about a situation in the past when you had a serious disagreement with one of your co-workers. How did you deal with that?
How would describe the difference between a Hub, a Switch, and a Router to your Grandmother? If they do OK there, then ask them to describe the difference to me.
The idea of the question is to understand if they can communicate/relate things well and then ultimately if they have a decent notion of these very common devices.
What websites/blogs do you read on a regular basis. When have you disagreed with a point the blogger was making and why?
Describe the most challenging situation you have had with a customer and how did you resolve the situation?
(or choose 'co-worker' or 'class partner' if you choose)
Since we're so often stereo-typed as socially awkward, uncommunicative loners, I ask questions about their hobbies & interests - can all they do is code, or do they have 'a life'?
I also ask more general business questions... do they have a feel for the business of their customers/clients/users?
Good coders are two-a-penny. Good developers who can communicate with, understand and empathise with their clients are somewhat less abundant.
Describe to me (a particular project) you worked on.
Preferably it is a project you're not familiar with already. If the interviewee can't describe the project to you, (s)he will likely not be very good at communicating ideas to co-workers, management, or customers.
I think it's important to ask at least one really generic question to give them a bit of space to breath and speak freely. Through this you can find out quite a bit out about them! Oh yes and make them talk about other hobbies and how they got "into" programming! Did they do it before University? What are they most proud of? (programming-wise)
I believe the developer aside from being able to code has to be:
Therefore I ask questions around those qualities. For example it's great to see how they talk about their previous job. Who is responsible for that project which did not go that well. How they describe the process of the software development. Etc
What else is their job going to entail? Try to consider some of the soft, social skills that their role might require (or might one day require) - working as part of the team, helping marketing describe the product, deal with supporting customer, demonstrating with the business development team, team lead, mentoring, handling an HR issue.
My favourite one is actually "why are you leaving your current job? why are you here for this one?" You can lead that on to all manner of other places, and you get a decent grip of the morals, ethics and outlook of the candidate.
What was the last programming language you learned? How did this compare to language X?
When you run into a coding challenge that you cannot solve, where do you go for help? Where do you do ongoing watercooler style research for programming projects you are involved with?
In interviews I always get "Why are you looking to leave your current job?" I usually just say something along the lines of "I want more responsibility and I am looking for better opportunities". I never say anything negative about my current job.
You have a bowl with 200 fish in it. Of these fish 99% are not guppies. How many fish should you remove so that 2% of what remains are guppies. Show your work.
This is about confusing requirements. It is said this way to change perspectives multiple times during the same question. It is meant to see if they can figure out what is really going on.
You would be surprised how many people get it wrong.
Do you change your own oil?
The idea here is to see if the applicant like to 'get his hands dirty', and figure out problems for himself. Obviously, you are not interviewing a mechanic, but good programmers (and engineer-types in general) seem to like to figure out how things work.
Edit: Wow, people really seem to react strongly to this. I thought it was a clever question when I was first asked it in an interview. So, someone suggested, "Tell me about haw you get your hands dirty." I'd like to get more specific. How about, tell me about the first time you took apart a VCR? Does that work? I think its too broad to just ask how people like to dive into things.
I've got a couple from my experience of doing team-building
What are your career plans for the next couple of years?
Tells about the things that are important to the developer. Helping him out with these things could motivate him beyond what salary could do.
How often do you make mistakes?
Ability to learn is proportional to the amount of mistakes made and learned from.
How would you approach the task of... [put some new tech thingie that he clearly does not know, i.e.: add circuit breaker for our DAL]
Developer's flow of thoughts will tell, how he normally would deal with new problem, if challenged with one (development is about unexpected challenges after all).
There is no best answer here. Some tend to ask about time they have and the other task constraints (showing management qualities of team-leader), some ask for tech details (good specialists) and some tend to surprise by going straight to the point and showing more knowledge and experience than you would expect (must-hire-now)
What's the most interesting project you've ever worked on? If they remember their past projects, they're more likely to remember their future projects. The better their memory, the better they'll be at maintaining their code (fewer 'why did I do THAT' statements). Plus, you'll get an idea about how passionate they are about coding: do they immediately start telling you about project x, or do they stare at you like you're speaking Greek?
What do you do in your free time? People who code in their free time are more likely to code well, but that's just based on personal experience, I can't back it up.
I always give some office-like scenarios I've been through such as dealing with non-technical people, dealing with hardware / hosting problems and I analyse if the person I'm interviewing would do sometihng better that I did in the past.
If so, he/she is almost hired. I guess the bottom line is that programming is easier to learn than having a good relationship with others or knowing how to deal with stressful situations
Getting someone to tell you what they think are their biggest weaknesses or areas they need to improve in/on
My answer is always that I procrastinate, as I am doing now answering this question!
Why did you leave your previous job?
(Or "why do you want to leave?", if they are currently employed.)
As an interviewer, I want to get at the story behind the resume. If I see someone who has hopped around from job to job, I want to figure out why. The most common explanation is that the candidate talks a good enough game to get hired, but is a poor employee - either not very competent or has other issues (hard to get along with, poor attitude, bad work habits). If they don't fit that profile, then I want to figure that out.
On the other end of a spectrum, if someone has been in a previous job for a long time that is usually a good sign, but not always - it could be that they were in a seriously dysfunctional organization and were good at playing politics, or worked for an employer that was very slow to clear out dead wood.
Unless you are such a superstar employer (via pay, prestige, or both) that you can lure good people away from your competition, your best shot at making really good developer hires is to snap up talented people who have been let go through no fault of their own (usually due to a business failure, takeover or big reorganization), or who are looking to make a big career transition. The tricky part is separating these few precious kernels of wheat from the oceans of chaff.
How do you handle it when a customer/co-worker asks for something that is technically impossible?
Ask them "Do you know what a 'kickback' is?", then wink a couple of times. ;)
I'd ask them what they do in their spare time. If they say "dunno really... play some games or something", then they may not be very motivated. If, on the other hoof, they launch into an enthusiastic description of their latest project or adventure, then they are more likely to be committed / motivated.
What's your favorite movie? I ask this question anytime I interview something. There's no wrong answer and it's a great conversation starter.
Or if you are in New England, you can always go: "So how'bout them redsox?"
How did you get started programming
I tend to lean towards people who either picked it up for fun, or some other personal motive other than Hey I can use a computer, I want to make games, I'll learn programming, but oh gee, I'm stuck in IT
How long would it take you to pick up [Language X]
Glancing at their resume I'll come up with a language they don't have any experience in, and see how comfortable they are with programming basics. An wise developer would understand that transitioning languages is largely related to syntax and function names. Yes, doing it properly means fully understanding the range of the language.
"Describe project X and your role in it." Project X is whatever appears to be the most substantial project on their resume. This question serves a few purposes for my interview loops (detailed below)
This is all based onthe assumption that people will put projects they are proud of and contributed to at the top of their resume. I'm not concerned with people who don't
What sort of computer setup do you run at home? OS, distro, networking setup, etc.
Most geeks are happy to describe their systems, and it tells me a lot about their enthusiasm for computers and their technical know-how.
Bonus points for multiple computers, PVR, SAN, security (wifi), etc. (Not just because it's cool, but because this experience is relevant to most programming jobs.)
I like asking logic questions that require the candidate to demonstrate they can think through a problem in a logical progression. These questions don't have right or wrong answers - there is a continuum of answers.
For instance, the classic is you have a balance scale able to tell which of two objects is heavier. You have 9 objects of the same size and shape. One of the objects is heavier than the others - by comparing the weights of the object using the balance scale, how few steps can you use to determine which of the objects is heavier.
Its a good test - the candidate might come to a quick conclusion that uses more steps than needed (this tells you they are more concerned about schedule than getting the best answer), or they can stubbornly continue to work the problem until they feel they've reach the absolute lowest number of steps (which tells you they will probably choose perfection over timeliness).
I always ask what non work projects they have recently worked on. Programmers who love their work always have something to talk about. Those who are just in it for the money usually do not.
Why do you want to work here? - This can usually tell you whether they know anything about your company and whether they can communicate properly.
What do you do when your away from the computer. - Good for telling if they ever get off a computer and also help open up a bit.
I would use a technical test to gauge their technical skills and use the interview time to determine if they worth having in the office.
How did you clean your room when you were a child?
This often matches up with how they currently approach tasks. Not that any answer is particularly bad (such as "I didn't" or "I only did it when I was told" or "I just threw everything under the bed"). We work with some great developers who gave answers like these. But it does seem funny to see that it still shows through in how they get things done.
Tell me about a time when did something wrong. After they give the example, ask how they went about fixing the problem and what they learned from it.
Two things:
I. I like to ask people (especially those with some experience in industry) to consider the dimensions of: 1) "those people that they've worked FOR" (aka bosses / managers / chain-of-command / etc.); and 2) "those people that they've worked WITH" (aka peers / co-workers / etc.) and then tell me about positive and negative experiences that they've had in both dimensions.
I'm looking here to see what kind of people they like (and dislike) working with, what kind of environmental factors influence them, etc. And I can pattern-match against our own operation to see if their comments raise issues or concerns.
I find it to be a thought-provoking question that tends to get people giving a pretty liberal amount of information.
II. I like to ask them to tell me what I'd see in performance reviews that they've had in the past listed as positive attributes and also listed as negative or things that need to be worked on.
The point here is to try to get the candidate to fess up to things are are areas in which they think themselves that they need to work on.
What do you read to keep up on the latest developments in software engineering?
"Mention three common design patterns and explain them!"
People who know design patterns are one stage further than the "I've learned C++ in a 3-weeks-course" guys.
My all-time favorite questions are ones that allow me to assess how the applicant approaches solving a problem. (This is somewhat of a variation on Joel's Guerilla Guide "Impossible Question") It gives me insight into how they think (big-picture vs. detail oriented) and what resources they would use to find information they need. Typically I use variation on the following
Tell me how you would determine: - how many gas stations are needed in a 1-square mile area of downtown L.A. - how many ATMs you would place in the 3 largest Las Vegas casinos. - the fastest 5 routes from Point A to Point B.
My variation on this is to tell them up front there is no wrong answer to the question. And along the way, I ask some clarifying questions to give me more information, based on their responses. I found I get more useful information about how the person approaches problem solving, their perspective of new problems they face, and how they go about learning things needed to get the job done.
Tell me about a piece of software that you wrote that you personally use.
See how they handle deliberately awkward and challenging issues (which helps see how they may react in the workplace).
"If I told you this interview wasn't going well, what would you do?"
Or pull in a technical writer and ask them to explain a technical concept to them. That way you can see how good they are at communicating concepts to a less technical co-worker.
(disclaimer: I'm a technical writer! That's TECHNICAL writer, not technical WRITER!)
My favorite...
"What's the smartest thing you've done in the past year."
Why are man hole covers round? and how many man hole covers are there in the continental united states.
I like to know what type of developer I have in front of me. I always admire those that can go beyond their own way of looking at a problem. Understanding how others try to solve a problem is many times needed and usually hard.
I found the following question to be quite revealing, regardless of the actual answer (beware, people try to play games trying to look what they are not, but is normally easy to tell by the examples they give):
What is harder, write code or read code.
"Tell us about the coolest thing you ever worked on" - the response will give you a good idea of their level of enthusiasm/passion for the field and should let you see the candidate's technical communication skills at their best. We like people who can use diagrams effectively, so provide a whiteboard or at least lots of paper&pens.
I believe in designing the interview questions for the specific position instead of using predefined off the shelf ones.
Some examples:
historical questions: For a job in a big established company a candidate would need to adjust to company policies and strict codes. Talking about candidate time in high school (which is usually more rebellious years) can give hints toward his attitude to authority. Army service on his resume can be another good point of reference.
Designed Task: A position I we were hiring for required a fast learner. In the interview process I required the candidates to write a simple program. 4 candidates did well, writing some 20 lines of c++ code. During the interview I showed the candidates 2 lines of code that achieve the same task, using STL, and asked each to describe what the code does. I started explaining the different STL constructs until the candidate would recognize that the code is equivalent to the sample he just programmed. The best candidate I interviewed got the idea in less then 2 minutes and had fun doing it. The others took around 10 minutes. the worst ones never got it.
I see from your CV that you have always worked alone/unsupervised/in a group. How do you think you would cope if you were in an environment where you work in a group/heavily supervised/alone? (delete as applicable) Why are you switching to a different type of working environment, do you think your work is suffering because of your current environment?
The first choise was asked of me when coming from a background of being sole developer in 3 companies for 10 years and then moving to a company with 40+ developers over 10 programming groups.
Very relevent question, and I'm now happy in my new job with a large group of programmers :)
If they are coming from a large company that would possibly have their own hardware/software support for the company pcs and networks, ask them if they have ever gotten into trouble with the IT department for fixing their own PC problems without raising a helpdesk issue.
If they have then it shows that they enjoy messing about with things and solving their own issues rather then relying on others to provide them with solutions to the simpler problems.
What do you want to do in our company/project?
Question is good both in abstract form and after I have described what we are doing here and which are options. Gives me a hint what would motivate candidate and in which way. And, I could be sure that this one would be answered honestly. Also, gives a candidate a chance to speak to me in a free form.
Variation, "What do you want to do after 6/12/24 months"
"Are you familiar with the employment laws that restrict the types on non-work related question I am allowed to ask you?"
In the same vein as the 'manhole covers' question I've had the following question asked in an interview:
How many gas stations are there in the United States?
I think the goal is to see if the applicant is able to reason, using very little input and come up with a plausible way of solving a problem. Obviously no one knows the answer to that question exactly but you can come up with a guesstimate and describe how you got to it.
How do you plan on bringing value to this company?
Now given the circumstances of the interview you may not always be able to be this direct. However, giving a candidate an opportunity to tell you exactly how they could impact your bottom line is the whole point of the interview. Why waste the interviewee's and your time posing nonsensical riddles that have nothing to do with the job they would be doing? Would you decide not to hire them if they could clearly explain how they could produce double their salary in a year if they couldn't tell you how many gas stations there are in the US?
What do you know about us?
Companies mostly have websites and there is information out there about the firm. How much research have they done before turning up? Are they motivated to work for this company or is this one of a bunch of form letters thrown out to whatever openings they could find? Might not be make or break (not going to reject someone based on not knowing all about the firm they applied to) but if you have to choose between closely matched candidates, which would you rather hire? The candidate who saw the job add or the candidate that bothered to research the company?
What gets you excited about coming to work in the morning, and what makes you dread coming to work in the morning.
The one I always liked is...
How would you go about building me a house?
Many times the answer starts off with things like it a strong foundation is important. The problems is, how can you build my house if we haven't even determined what I want (i.e. number of bedrooms and bathrooms, kitchen size, one story or two, basement, etc)?
What are your goals? I like people who are goal oriented, people who are, are almost guaranteed to be passionate about something. Then you expect to hear that their goals are inline with the job you are hiring them for. This applies to any job, not just programming.
What's the coolest thing you've done in the past five years, your biggest braggable?
Lets you get a sense of the the scope of their accomplishments
Lets you see them get excited about something (hopefully!)
Might let you get to see a side of them you haven't seen yet, as their answer might not have anything to do with IT
Those who failed and managed to move on are good candidates. At least, they are honest and they can handle failures, and they those who are resilient.
What do other people find irritating about you?
I've used this question in interviews for two purposes:
(1) Determine if a candidate is receptive to open criticism (positive or negative) and see how they respond to the criticism
(2) Determine if a candidate will answer questions that may expose them or put them at risk.
When candidates "spin" the answer to this question to make it positive, I give them a lower score. For instance, "my coworkers always say that I irritate them by being a hard worker or always on task..." In my opinion, this is not answering the question.
I'd ask the candidates if they have an account here on Stackoverflow. If they do, I'd ask them to tell me their nicknames on SO. I would then check out their profile, the questions they posted and the answers they gave to other people's questions. I think that would give me a fairly good knowledge of the candidates' abilities ;-).
Tell me about the toughest bug you've ever fixed. I like this question because it forces the interviewee to talk in depth about detailed technical topics and make them understandable. I want to know that someone I hire will be able to describe a difficult bug, why it's broken and how they will fix it. Also you can tell how in-the-trenches someone has been.
I like to ask this:
"When reviewing someone else's code, what is your biggest pet pieve?"
If you get answers like, formatting, or not following coding conventions, that is a red flag. I really like the people who talk about lack of exception handling, saw tooth code, long run on functions, etc.
The other thing I like to ask is dependent on how long they've been programming. If I see someone who has made a transition from one major language/framework to another... for instance from VB6 to VB.NET, I like to ask how they made the jump (books, classes, etc) and also to describe any hurdles they had to overcome when doing it.
Some people answer that question in a way that makes clear that even though they are writing VB.NET code, they still use VB6 methodologies, and they don't follow good OO practices. I stay clear from those people.
My favorite question is "What makes a good application/program?", which doesn't have an exact right answer, but I've always been surprised how many candidates lock up when they get asked that because they are more concerned about appeasing the reviewer then actually thinking about the question and giving their opinion. It ends up revealing a lot..
I think I only got, 'Meets or exceeds the clients requirements and is maintainable' once.. and a lot of panicked 'it's fast?' answers...
I've used this at least once: "Emacs or vi?"
I don't really care what the answer is, but a blank stare would not be reassuring!
What was your biggest development screw-up, and what insight did you gain from it?
"You've told us why we should hire you. Why do you want to work with us?"
One guy actually had to look at his notes to see where he was interviewing before answering. If they're excited to be a part of your company, they will have a good answer (and will know the name of your company without checking their notes).
What steps did you take when the business unit / customers of your project insisted you reduce time spent on requirements gathering, and how did you explain to them why they were missing certain features or had bugs that were the result of the inappropriate requirements analysis?
We have all faced this situation, and if the candidate says that this has "never happened to me" then you need to move on to the next candidate.
After completing your first coding assignment, your technical lead says, ‘The code looks good, but please replace [X] with [Y].’ You go back to your desk and you give the solution a lot of thought and you decide that your original solution – [X] – is the right approach. How do you go about convincing your lead that he should retract his request and you should move forward with the [X] implementation?
Wait for answer...
What if, after your attempt(s) to convince your lead, he responses with, ‘Sorry, Newbie. I don’t care. Do it my way.’ What do you do?
Do you read The Daily WTF?
Have you ever had your work published there?
Ask some design questions: eg How would you design a dayplanner.
Personally, I like this question "How would you proceed a project if you are given a non-specific requirement?"
I ask the interviewee to describe one of their favorite technologies, frameworks, product. I ask them to describe the motivation of the technology, its architecture and theoritical background and the ideas behind the design.
For example, if the interviewee had experience in Spring Framework, questions would be:
-How the Spring implements AOP behind the scene?
-What is the motivation of IoC (or DI)? What is the benefit? What problems it solved?
After a dozen of interviews with potential programmers, I found the above question effective to evaluate not only the interviewee's ability to communicate efficiently but to learn and apply the technology with depth of understanding, which indicate how well he/she makes design decisions.
I seek programmers who can make sensible design decisions with supporting rationales. I do not prefer programmers who are only interested in make the code work and only knows how to use the API of the technologies. Such programmers are using technologies blindly and they are likely to make bad design decisions.
On my second interview ( i was really beginner) i have been asked:
If you have 9 balls and one is heavier than the rest how to pinpoint the heavy one by using the balance only twice?
i was asked about it because i gave many invalid answers for php questions and it seems that interviewer wanted to help me a little. This is good question to test agility of solving and understanding problems by programmer
i think its good to ask a non-programming questions during an interview
all things being equal (with regard to coding skill), the answer could be the deciding factor between two candidates
my favorite is: "An angry customer rings the office, they say: “my website is down, you said you were going to fix it yesterday!” You don’t know anything about this client or their work – what would you do?
its basically a test on customer service. you are looking for answers like: "i'd apologize to the client", "i'd tell the client i will look into it and get back to them in 20 minutes", etc
i have more information about my hiring techniques here: Hiring Programming Staff
--LM