I REALLY don't want to screw up this interview.

February 8, 2007 12:38 PM

What are some generic "technical interview" questions you've received? Help me land my dream job!

I've been asked back for a second interview at a company I'd REALLY like to work for. I'm a mechanical engineering major, but the job is focused more on the computer side of virtual instrumentation, and so on. They mainly look for EE's or computer science people, but ME's run a close second.

At the first interview, I got 1 software and 1 hardware question in the 'technical' part. The software question was along the lines of finding a missing number in a randomly sorted array, but it was more focused on the general problem solving than writing any code. The hardware question involved building a system to measure temperature in another room.

I obviously did well enough to get the second interview, but with preparation I felt I could have done better. I know I will be receiving similar questions, so can you think of any good background research I should do, or example questions you've faced at an interview in the past? I'm in the process of Googling everything, and learning things like basic sorting algorithms and such (I couldn't remember how to bubble sort), but I wanted to get the Green's opinion too.

posted by cebailey to Work & Money (21 answers total)

The gotcha question on my most recent interview was this:

I have 100 coins, I flip them randomly, count the number of heads (x), and then pick any x coins out of the pile. Without looking at the coins, how can I make both piles contain the same number of heads?
posted by nomisxid at 12:47 PM on February 8, 2007

Hey, I was a mechanical engineering major (different specialty) who went through a few technical interviews. Some of them asked for pretty detailed knowledge in the field that I'd be working in (like, what's the difference between SISO and MIMO systems? What are the advantages and disadvantages of describing a system as a "black box" or modeling it from first principles? etc), but most of them were looking for reasoning skills over the actual correct answer.

A friend of mine (MechE) was once asked:
"You are trying to determine the maximum height from which a light bulb can be dropped before it breaks. You have only two light bulbs and a 100 story building. Assume that, if a lightbulb is dropped and doesn't break, it isn't weakened at all. Design a testing procedure that minimizes the number of separate drops you must make."
posted by muddgirl at 1:09 PM on February 8, 2007

Company I used to work for asked this one:

4 people on one side of a river who need to row accross a river. They row in 1, 2, 5, 8 minutes respectively.

There's one rowboat, two people in the boat, max. If two people are in the boat, the slowest rower has to row. So, if the 8 and 1 are in the boat, it will take 8 minutes to cross. If the 5-2 are together, it will take 5, and so on...

Obviously, the boat needs to get back accross the river as well (someone needs to row it back).

They have 15 minutes to get everyone accross the river - how do they do it?

There are no tricks, it's just logic and math. Obviously, this is a very specific question from one company, and if this thread turns into riddle-time it won't help you. But to solve the above you need some measure of outside-the-box thinking, which is what most of these are designed to guage. So just adjust your framework a bit if you get one of the riddle-type interview questions.

Another company I heard about simply asks - "How many barbers are there in Chicago?" Obviously, there's no right answer, it's all about how you break it down (I'm assuming 3mill people in Chicago/half are men/25% of them are bald so don't need barbers/and so on...)

Good luck. If you take the right approach these interviews can be kinda fun...
posted by jtajta at 1:11 PM on February 8, 2007

Not exactly technical questions, but some tech companies have been known to ask:

1.) How do they make M & M's? (They don't expect you to know; just to be able to confidently make up things on the spot)

2.) Why are manhole covers round? (If they were square, they could fall down the hole and hurt someone. Also, round covers fit in the hole in any direction.)
posted by fvox13 at 1:14 PM on February 8, 2007

On my first interview

"whats too stop you finding a better job in three months time and leaving us for it?"

the answer is of course absolutely nothing, but the only way i could think to respond was to say, if such a situation did occur i hoped to have proved myself a valuable employee who they try to keep hold of.

and of course the old classic.. "what are youre flaws?" I always say im pedantic as i like stress to motivate me.

or procrastination is another good one as no one really fucking cares these days.

good luck.
posted by complience at 1:18 PM on February 8, 2007

I also like these questions.. thought up by kids.

*How do you put a giraffe into the refrigerator? Correct answer: Open the refrigerator door, put the giraffe in, and close the door. This question tests whether or not the candidate is doing simple things in a complicated way.

*How do you put an elephant in the refrigerator? Incorrect answer: Open the refrigerator door, put in the elephant, and close the door. Correct answer: Open the refrigerator door, take out the giraffe, put in the elephant, and close the door. This question tests your foresight.

*The Lion King is hosting an animal conference. All the animals in the world attend except one. Which animal does not attend? Correct answer: The elephant. The elephant is in the refrigerator, remember? This tests if you are capable of comprehensive thinking.

*There is a river notoriously known for it's large crocodile population. With ease, how do you safely cross it? Correct answer: Simply swim across. All of the crocodiles are attending the Lion King's animal conference. This questions your reasoning ability.
posted by complience at 1:21 PM on February 8, 2007

There are 100 lockers in a row, with 100 people lined up. All of the lockers start off closed.

Person 1 switches the state of every locker.
Person 2 switches the state of every 2nd locker
Person 3 switches the state of every 3rd locker
...
up to person 100.

Which lockers will be open/closed at the end of this exercise?


What becomes more important than the correct answer here is you talking out your line of thought for why and how you are arriving at that answer.
posted by twiggy at 1:22 PM on February 8, 2007

I was asked a lot of general physics questions when I interviewed for the JPL. Not only how, but why. Unfortunately, I can't remember any of the questions offhand, but I was amazed at how poorly I was able to explain why physical principles I learned about in high school work.

For the job I currently have (avionics), I had to go through a quick technical interview. Four questions, one each for knowledge on aeronautical, mechanical, electrical, and software engineering. These were more specific, with no "why" questions. For example: what factors go into the design of a Molex connector? (conductivity of the material, contact surface area, contact pressure). What are major differences regarding exceptions between C, C++, and Java?

I was on the other side of the fence just a couple months ago as an interviewer for the company. One of my coworkers, an RF engineer, told me about an interview he gave to a "fresh-out" graduating senior who was looking for a EE job. She couldn't answer even the most basic Ohm's Law questions he gave. So, I guess my best advice would be to read up on your freshman physics and general engineering courses.
posted by backseatpilot at 1:49 PM on February 8, 2007

bakseatpilot has a great point - at one interview I had to analyze a circuit diagram and describe how I would solve a mechanics problem.
posted by muddgirl at 2:44 PM on February 8, 2007

i thought the main reason manhole covers are round is so you can role them.
posted by alkupe at 3:29 PM on February 8, 2007

sorry roll
posted by alkupe at 3:29 PM on February 8, 2007

I applied for an embedded software development position, and was asked to identify the major current paths through a moderately complex circuit diagram. The only way I was able to answer this was just because I just happened to know from being an electronics hobbyist that BD139 and BD140 transistors had a moderately high power rating, which gave me a clue where to start looking.

Second interviews are more about finding out who you are than any kind of initial question-based weeding-out process. If you've got through the first filter, they're already considering you seriously; and if you're basically competent and keen, you'll be in with a good chance.

The best thing you can brush up on, for a second interview, is not so much what you know, as how you present. If you're able to relax (and a good interviewer will help you with that) and pay close attention to what's being said, and pause for a moment's reflection before answering anything, you'll be fine.
posted by flabdablet at 3:40 PM on February 8, 2007

My advice is there is not much you can do to prepare. Don't try to memorize algorithms or cram new information in, it'll only throw you off. Answer the questions honestly and verbosely, admit when you're not sure- but also mention whenever this is the case what you would do to address your uncertainty, such as "well, I like this site ____ for getting information on algorithms or known solutions" or such and such is a really good resource, I'll bet I'd find out more there" or the like- and stay upbeat. The rest is just a matter of chance, and don't worry too much about it. The only other thing you can do is to think honestly now about why you want this job, what you're hoping to do, so that if asked you can speaking honestly and intelligently about it because it'll be sincere.

There are three types of questions you'll get in any technical interview:

1. Rote questions. These are things like "what are the 7 blah of the bleeh?" This is just a test to ensure you have some basic grasp of core material. Not something you'd see in a 2nd interview, and usually something done in a phone screen to weed out those who aren't yet qualified.
2. Practical questions. Sounds like you've gotten these already. These are things like "analyze this circuit diagram" or "design an application to do X". These are to test your basic practical abilities to do your job function: they are real world, they are specific to the type of work you're doing, and they shouldn't be "trick questions". They may be open ended and involve things like the interviewer switching up needs or parameters on you, they may involve pseudo code or actual code, etc.
3. Fuzzy questions. These are the questions like the "what kind of animal would you be?" or "What do you look for in an employer?" kinds of questions, with no "right answers. They may also be puzzle/riddle questions, where the problem is not actually easily solved/solvable or applicable to your potential job, they are just trying to see if you can come up with good and/or multiple ideas, as well as get a sense/intuition as to the type of employer/co-worker that you'd be. I suspect in a 2nd interview, you'll mostly see these.

These last type of questions in the hands of a bad interviewer are sometimes bogus as they don't necessarily address any real value, and are just "gotcha's!" for an insecure interviewer who needs an ego boost. But in a 2nd interview, they'll probably be about sensing your longer term goals, your motivations, and your underlying character, as well as finding out what kind of thinker and learner you are under the hood. You can't really prepare for these questions, just be honest and be yourself, and let things fall where they may.
posted by hincandenza at 3:49 PM on February 8, 2007

Many CS graduates manage to finish school without a deep understanding of pointers or recursion. This has been noticed in the industry and questions testing candidates' knowledge of these subjects are used rather frequently to separate the excellent from the not excellent. (Example actual MSFT interview question I was asked: permute a string in place.) So IMO time spent brushing up on these concepts is a good investment.

Aside from that, the best advice I've heard for technical interviews is to think out loud. The interviewer is likely to be primarily interested in understanding how you attack problems. They are interested in such questions such as these: Do you start coding right away or do you ask questions to clarify the question? Do you consider corner cases in your design? Do you consider testing? Do you evaluate the efficiency of your algorithm? Correctly? Can you think of a better one? And so on. Assuming you are a careful and diligent engineer, talking through the problem can give a interviewers the sense that you could be a good fit into the team even if you don't manage to permute the string in place under time pressure in the interview or have all the domain specific knowledge they are seeking.

Good luck!
posted by harmfulray at 4:57 PM on February 8, 2007

The question that I used to weed people out was always the first and simplest one: "Tell me about yourself." It is amazing the stuff that people will say! Questions like these not an excuse to mention how stressed you are or give an autobiography or even ramble aimlessly about hobbies/family/philosophy, but rather an opportunity for you to say who you are and why you are the best candidate for the job.

Also, expect to be able to say something that proves your resume. If you went to the University of Albatross, you'd better be able to say something intelligent about the place. The world can be a remarkably small place at times, and you never know whether the interviewer's kid goes there. If this job involves any licenses or certificates, bring photocopies.
posted by ilsa at 5:42 PM on February 8, 2007

But ilsa- doesn't that reflect more on you as the interviewer than on the candidate? Seems like all you'd end up evaluating is people who have well-rehearsed responses to that question, or people who are natural speakers. But how much does that matter in a highly technical job? After all, we don't spend every working hour performing for other people- especially in a technical capacity, where we might spend hours alone working on a problem, only interacting with other people in fits and spurts.

Someone's ability to market and pitch themselves is a very edge talent in these types of fields, and one that rarely helps in day to day technical work. Just as a baseball GM doesn't care if his #3 hitter with a .325 batting average and .660 slugging percentage is a poet laureate or good public speaker, a good interviewer will understand what the position is for, and whether rehearsed or off-the-cuff self-promotion is a desirable skill. In some cases, this is a skill that correlates closely to critical skills in that job function- but when someone is doing software coding for virtual instrumentation, I don't think "is a good interviewee" is itself a critical skill.

A good hiring manager will understand that everyone has shortcomings, some more quickly visible than others, and that it is your responsibility as a hiring manager to determine what you really need, and therefore how to best evaluate each candidate's ability to meet that need. The poor speaker might demonstrate incredible creativity at algorithm design or code elegance, so why would you not hire them just because they didn't give you a 30-second soundbite answer to a question they'll never be asked again in their entire work career at your company?


Besides, "Tell me about yourself" is a far too broad and open-ended question. Clearly, ilsa lacks the ability to properly define a problem statement with a clear goal, and outline the work flow into discrete manageable chunks. No hire!!! :)
posted by hincandenza at 5:58 PM on February 8, 2007

Why are manhole covers round?

Manhole covers are round because the holes they cover are round.
posted by deadmessenger at 6:05 PM on February 8, 2007 [1 favorite]

Whats the answer to the rowboat one? I can't get it, dammit.
posted by Touchstone at 1:48 AM on February 9, 2007

Touchstone: With four people to move, and two rowers going across at a time, and one rower coming back, it's going to take five crossings to get everybody to the other side.

The slowest crossing is inevitably going to take eight minutes. If we're going to spend eight of our fifteen allowed minutes on that crossing alone, we need to fit four more crossings into the seven remaining minutes.

If the five minute rower is involved in one of those four, we've got three more crossings to fit into two minutes, which can't work; so the five minute rower must go over in the same crossing as the eight minute rower, and neither of those rowers is allowed to come back.

That means that their trip can't be the first one, or there would be nobody to bring the boat back. So the first trip has to be the one- and two-minute rowers going across together.

Both the solutions that satisfy those constraints fit inside the allowed time.
posted by flabdablet at 5:36 AM on February 9, 2007

doh! thanks very much.
posted by Touchstone at 5:26 AM on February 11, 2007

You're not going to be able to "study" all the possible questions that will be thrown at you. As harmfulray pointed out, they're (if competent interviewers) looking for your thought process and problem-solving approach more than a "correct" answer.

What will you do if they throw you a question you have little or no idea how to answer? If you become flustered or just say "I have no idea," that's bad. They want you to consider it calmly and rationally and articulate your thinking, or at least describe how you would go about finding out the answer in a real-world situation. So that might actually be a good thing to practice. Find a friend who knows a lot about a field you know nothing about, have him ask you a technical question about that field, and then try to respond as if you were in an interview.
posted by staggernation at 5:07 PM on March 8, 2007