Greetings from New Jersey! The Recruiting Road Indicate has started its second week. If you are curious last week,
Windows 7 Pro, I interviewed 42 candidates for 30 minutes each, led 3 meet-the-company presentations, and hosted 2 candidate dinners for Microsoft employees and alumni. WOW. I’m tired just writing all of that.
So it’s week 2 of the street trip, and I thought that I would continue my interview tips series—as I could write these for weeks! Last time, I talked about the top traits we look for in an interview. Today, I wanted to talk about problem solving questions. Why do we ask them - and how should a top candidate answer?
I myself do not ask any technical coding questions in an interview. I keep things a bit more vague (that’s my tricky way of saying I’m not super technical), but that doesn’t mean I don’t want technical answers. For instance, I like to ask many open ended questions. I like to see how people think, and open ended problem solving and design questions are the way to go.
Some good questions are “design a product for a certain type of user” or “test a product” or “come up with some features that would be key in creating a product.” Think of things like “Design a cell phone for a child” and “test a soda vending machine.” Here are some hints as to why we ask those questions, and hopefully some tricks that will help you answer those questions:
1. Get Really Specific: When asked a question such as “test a vending machine,” think of as many possibilities as you can. This isn’t a one sentence answer. Talk until the interviewer says to stop. We want your thought process. Come up with as many ideas as possible … this way you can build off other ideas and exhibit that you are really detail oriented.
2. Ask Clarifying Questions: If you are asked to “design a remote control for a television for a grandmother,” ask a lot of follow up questions; the interviewer will answer. Questions to ask include: who is the target age group?, how many staff do I have?, what is the price point?, how much time do we have?, etc. This shows you are thinking and not just jumping into creating a product without any background info. There is no right answer; the interviewer will make up answers (i.e. the age of the user is 12) as they go along.
3. Use the Product Lifecycle as a Guide: A great interviewer at Microsoft that I know used to ask a fun question. He would ask, “What flavor cheesecake would you make for the Queen of England?” Now, he doesn’t want to have you say “Strawberry”… The point of this question is to see if you are familiar with the software development lifecycle. You would first do research on what the queen likes and understand how much time you have until she eats the cake. Then you would make a test cake, have people try it out, make any adjustments to it, do some more research, and make the final product. The flavor doesn’t matter. It’s just your thought process getting there.
4. Talk Out Loud: Don’t just think of an answer or write through a problem and then 20 minutes later say, “The answer is 43”. Talk it out; a lot of times that’s when the good solutions come. Share with us what you are thinking …. Maybe we can help you out if you are stumped, but we won’t know that unless you tell us.
5. What’s at the Core of the Problem?: Most interviewers really don’t need to know how you would build a refrigerator for someone in their teens, so think about the question and determine what they really want to know. More likely than not, we want to hear how you think, what assumptions you made, if you ask questions, if you bring a creative approach, etc. It’s not the answer that matters; it’s how you get there. So take your time, and determine what they are looking for. It’s not a race.
Well, my lunch break is over--- 6 more interviews to go today. Maybe some of my candidates will see these tips prior to their interview. I hope so.
-Janelle