Tech-Interview Riddles

Why do interviewers use "riddles"? by Turing+Machine · 2002-07-23 15:53 · Score: 5, Insightful

What's up with using this type of question for interviews, anyway? Sure, they can be fun, but they're perfectly useless as far as telling whether someone can actually write solid code. 9 times out of 10, all they tell you is whether the interviewee has heard that one before.

To interviewers: Do you really think that the answers to these questions don't spread through the entire department within 15 minutes after your first interview? I realize that "knowing the answer" makes you feel smarter than the prospective employee in some sense, but how about actually doing your job for a change?

Re:Why do interviewers use "riddles"? by Brant · 2002-07-23 16:07 · Score: 3, Insightful

You've got to use the right questions. As someone else has pointed out, there's a great web site called techinterview.org that has similar questions. They talk about something called the "aha factor". If something has a high aha factor, then you'll only get it if you've heard the question before. These aren't very useful as interview questions.

If something has a low aha factor, then it's a useful question even if they've heard it before. The idea is to watch the interviewee's reasoning process, not to make sure they get the right answer. When I interview people, I ask these types of questions. I find it an invaluable probe of their ability to reason and think logically.

One of my favourites is this:
"How many trailing zeroes are there on 100! (100! = 100x99x98x97x...x3x2x1)."

Try it. It's reasonably straightforward to get, but you have to show an understanding of factoring and multiplication to get it. The answer is on techinterview.org if you want to check yours.

Scott
Re:Why do interviewers use "riddles"? by Stinking+Pig · 2002-07-23 16:08 · Score: 3, Insightful

Those points are true if you're hiring a contractor to come in, do a job, and get out. They are not true if you're hiring a flexible team player who is going to handle a demanding job which is guranteed to throw new challenges on a daily basis.

If you're hiring the latter type of person, you want to know how they'll react to not knowing the answer in a high stress situation. I've done a lot of interviewing for sales engineering positions, and I can tell you some good ways to not get hired when this question comes up:
a) lie, convincingly or otherwise
b) go silent
c) act like a teenager trying to ask for a date.

The proper response for me at least is to say "I don't know, but based on these things I do know, this is what I think." I choose people for the way they think in addition to what they know, because that tells me something about what they'll be able to learn.

That said, most interviewees never make it to a question like that because they get stumped on my initial tech question after "how are you and where did you work before":

"Describe in as much detail as you are comfortable using exactly what happens from a network perspective when you use that laptop to visit a web site. I'm looking for which packets go where."

If you tell me about ARP, DNS, and HTTP and you can name the port numbers and transport layers, that's fine. DHCP, load-balancing, firewalls, SSL, proxy servers, server-side processors, databases, that's all extra credit. If you can't talk about these things, you're not yet ready for a professional career in this industry.

--
"Nothing was broken, and it's been fixed." -- Jon Carroll
Re:Why do interviewers use "riddles"? by MayorQ · 2002-07-23 16:15 · Score: 2, Insightful

True, while these questions do not answer "Can this candidate code well?" they can provide insight into how the candidate thinks. They are merely "thinking" questions and are only useful if the candidate thinks outloud. It lets you see how they think and how they attack a problem. Are they being logical? If they can logically put several thoughts together, they can code in most any language. Learning syntax is a given.

- MayorQ
Re:Why do interviewers use "riddles"? by Turing+Machine · 2002-07-23 16:27 · Score: 3, Insightful

Would you guys feel comfortable going to a lawyer or doctor who'd been hired on the basis of his answer to a bunch of "brain teasers", or would you opt for the doctor or lawyer who'd, oh, I don't know, actually been asked questions about law and medicine?

Asking about TCP/IP is fine. Asking about sorting algorithms is fine. Asking "how would you lay out a data structure to represent this problem?" is fine.

Asking goofy questions about the shape of manhole covers is idiotic (especially since the "official" answer to that question is dead wrong).
Re:Why do interviewers use "riddles"? by Anonymous Coward · 2002-07-23 18:25 · Score: 1, Insightful

Microsoft may ask riddles in interviews, but most interviewers are not looking for "official" answers. In fact, the actual answer should be irrelevant. Instead, the interviewer is getting you to work while they watch how you respond to the situation. They are more interested in *how* you think than if your answer matches.

When I interviewed, the interviewers were interested in and impressed by my creative, non-standard answers and the questions that I asked of them. It didn't matter that I didn't give the "standard" answer on most of the questions. What did matter was my emotional reaction to a difficult problem, my approach to solving the problem, and the questions that I asked of them.

Also, interviewing isn't restricted to HR. At MS, the individual employees (managers and individual contributors) across the company are involved in interviewing and they each come up with their own questions.

You can focus on code centric questions, but will that person still perform well if they move to writing specs, managing people, or developing an advertizing plan?
Re:Why do interviewers use "riddles"? by cwikla · 2002-07-23 19:07 · Score: 4, Insightful

The problem with "light bulb" questions is that people tend to like to come up with their own ones, which usually tend to be crappy, or ones, as earlier mentioned, that someone stumped them on, and now they think they are clever for knowing the answer. Even "technical" questions sometimes fall into this one.

Some experiences in my past:

A couple of years ago I was asked: How many gas stations are there in the US?

My answer: I don't know, I'd probably check a search engine.

After I insisted that I couldn't come up with an answer on my own, I was informed that they were looking for people who "think out of the box" and only people that hazarded a guess made it to level two interviews.

I laughed, and explained that if someone I was interviewing made up some bullshit answer with absolutely no backing I'd be afraid that would carry over to their real work and it was a silly prerequisite. Knowing where and how to find an/the answer can be even more useful then making up an unfounded answer. Lots of smart people out there. Lots of stuff already been done.

Hmmm, come to think of it I never did get a second interview.

Or the time I was asked to come up with a string hash function. So I quickly threw together a loop just adding all the bytes, shifting some bits each iteration. Simple, not great, not perfect, but a decent 10 cent solution. I was then walked through the "correct" answer that covered, number of bits in byte being used, average word length, etc, etc...and told this was the "correct" answer. Researching later, I believe the solution was either in a Knuth book, or was another Microsoft tidbit. But I'm sure the interviewer would have come up with the solution independently given the same question in the interview...

Finally, my FAVORITE is being asked some hard technical question. You ponder, you falter, and come up with some sort of a solution, but aren't quite satisfied it. Of course the interviewer then informs you it's a problem they are currently working on and they are trying to come up with something themselves. Seems like you should be paid contractor rates at least for that part, no?

I find that having people talk about their work, explain what they did, and WHY they did it pretty much can measure a candidate against your bullshit meter in a matter of minutes.
Re:Why do interviewers use "riddles"? by JamieF · 2002-07-23 21:55 · Score: 4, Insightful

>You can focus on code centric questions, but will that person still
>perform well if they move to writing specs, managing people, or
>developing an advertizing plan?

Good, experienced developers should be really good at writing specs since they know what level of detail is needed. In fact I think they stand a better chance of writing an implementable spec than an Analyst who has never coded.

As for managing people or developing an advertising plan, those are totally different skill sets from development. Have you ever worked with a manager who totally sucked as a manager but was a really smart developer? I have, several times. It's painful, and it drives home the point that managing well takes skill.

The idea that you can just dump a bunch of smart people onto any problem and outperform a bunch of experienced people who aren't quite as smart strikes me as terribly naive. Or, in Microsoft's case, conceited: it's pointless to learn from the past because we're all smarter than they were. So we'll get it right the first time and come up with a more clever solution on our own than if we just READ A DAMN BOOK. And so you get badly designed, bug-ridden software that solves problems that were already solved better 10 years beforehand. Oops.

Perhaps if you're truly working on something novel it would clearly be better to have smart people than not smart people, but in that case it's not possible to hire for experience anyway so it's not germane to this discussion.

You want good ads, hire someone who's good at doing ads. You want a good manager, hire a good manager. Or, train someone who is partway there. But don't just throw bright young people at any task and assume that they'll do better than an experienced person. I've worked in companies where that was the explicit philosophy and it's a disaster. After a few nightmare projects that smart manager might figure out some techniques that a less smart manager took a lifetime to develop, but that less smart manager wrote it all down in a book 30 years ago. Don't you wish the smart manager had read it BEFORE their first project as a manager?

Show me a chess club that can beat Marines at paintball and maybe you'll change my mind.
Re:Why do interviewers use "riddles"? by rsmah · 2002-07-24 01:42 · Score: 2, Insightful

A couple of years ago I was asked: How many gas stations are there in the US? My answer: I don't know, I'd probably check a search engine. This is why this is a good interview question. It provides insight into whether the prospective candidate is willing to think about answers to questions with very little available or non-obvious information. I wouldn't hire you because you refuse to THINK. To "correct" answer is to use information that you know (i.e. population of the US) to come up with a "common sense" answer. For example: 200mil people in the US => about 100 mil cars @ $1 gas/car/day => $100 mil in sales/day => $30 bil sales/yr @ $1mil/station => 30,000 stations. Sanity check... that's 1 station for every 200,000/30 => 7,000 people...perhaps a bit too low. Fudge up to maybe 60,000 stations. This is probably correct to an order of magnitude. But that doesn't even really matter. The *point* of these questions is to guage whether or not the person can *think* or not. End of story.
Re:Why do interviewers use "riddles"? by sql*kitten · 2002-07-24 02:38 · Score: 3, Insightful

In other words, either "I'm too stupid to remember stuff I've looked up fifty times" or "I'm so inexperienced that I haven't looked those up very much." If you don't KNOW that SMTP is 25 and HTTP is 80, I don't want you working on my mail or web servers.

Without looking it up, tell me the ports for all the kerberos daemons. Or x400.

You forget - or perhaps are too inexperienced yourself to realize - that there is a lot more to the IT industry than the web or even the internet. Someone could be a highly skilled Unix administrator, and have never run a web server in a production setting. For example, how many public web servers are there running on Dynix? Not many I'd wager, but that particular Unix is common in transaction processing. Have you even heard of Dynix? Memorizing lists of ports is the hallmark of a wannabe.
Re:Why do interviewers use "riddles"? by cwikla · 2002-07-24 05:14 · Score: 2, Insightful

I take the exact opposite view. With no information available I see it as Garbage in, Garbage out. If you were working for me, I'd rather you admitted ignorance (not stupidity) to the problem at hand, and the answer, "I don't know, let me go research it", is a much more "correct" answer to me.

Too bad you wouldn't hire me... It would be fun just making stuff up all day!

Re:One of my favorites by Horizon_99 · 2002-07-23 16:09 · Score: 2, Insightful

Doesn't matter, the variable will be renamed along with the others.

Now I get a gold star right? ;)

Re:One of my favorites by gmack · 2002-07-23 16:09 · Score: 3, Insightful

Is the answer .. nothing?

You shouldn't have to special case that since it's just another variable name.

Interviewing at Microsoft by shird · 2002-07-23 17:06 · Score: 2, Insightful

This is a great site for more information on interviewing at Microsoft. It has some sample questions, study materials and testimonials etc.

--
I.O.U One Sig.

Spoiler: 100 prisoners and a light bulb by Anonymous Coward · 2002-07-23 18:02 · Score: 2, Insightful

This was a nifty riddle, I never saw it before, and I do think it's appropriate for the programming mind set.

Essentially the prisoners have to come up with some programs for themselves. They become little finite state machines with an unlimited number of internal states, one input bit, and one output bit. Then the jailer picks one prisoner at a time, randomly, and lets the prisoner run his state machine.

First I noticed that there aren't enough different truth tables for 100 prisoners, which led me to think about the state machines.

Then I looked around for some kind of protocol where prisoner #1 could signal that he had rendez-voused with the lightbulb, and then hand off a notional "token" to prisoner #2, and so on for 100 prisoners, eventually to make a token ring. That wasn't working out very well. I got up to 4 prisoners that way, and I wasn't coming up with a general mechanism.

Then I thought: okay, try client-server, make one prisoner the "boss" with one program, and 99 other prisoners are "drones" with a second program.

That worked out pretty well!

The next problem is communicating the strategy to the prisoners:

"Okay, all you mugs, listen to me, because I was a smart guy on the outside!"

"You, KILLER, you are the BOSS. It's your job to keep the count. Whenever you go in that room -- if the lamp is on, you turn it off, and you make another tally mark on your roster. If the lamp is off, you leave it off. When you get to 99 tally marks, you tell the warden that everyone's been in there, and we can all go".

"All the rest of you joes, listen up. If you go in the room, and the lamp is off, you turn it on -- but ONLY ONCE. JUST ONCE. After you do that, you never touch the lamp again. Ever. I don't care how many times you go in the room."

"All you joes -- if the lamp is already on, don't touch it. Leave it on. That just means that someone else turned it on and Killer here hasn't seen it yet. If the lamp is off, and you touched it before, leave it the hell off! Cause if you turn it on again, Killer's count is gonna get messed up, and we're all going to die."

"Killer, you got pencil and paper? Good. Maybe you want to tell Numbers here to do the counting instead? It doesn't matter who does it, as long as we all agree RIGHT NOW who's going to keep the count. Because if you blow the count -- either we are going to be waiting here forever, or you are going to pipe to the warden too soon and we'll all fry."

"Any questions?"

(One of my buddies has to be pre-arranged to ask this): "Yeah! What if I go in the room and the light's already on? What do I do?"

"Answer: you do nothing! You turn around and walk out! If you haven't turned on the light for yourself yet -- this doesn't count."

Q: What if I turned on the light and the jailer calls me back and it's still on?

A: "Same as above ... you do nothing! You turn around and walk out! Look at it this way. All you joes are never going to turn the lamp off. Ever. That's Number's job. And each of you joes are going to turn on a dark lamp and make it bright exactly ONCE in your life. Just ONCE. No more, no less. If you can count up to 1, you can do this. Numbers has to count to 100, and I know he can handle that. And we'll all be out of here eventually."

Then we train the guys using a couple of decks of playing cards, and a lamp, so they can see how it works.

100 Prisoners and a Light Bulb by Dan+Crash · 2002-07-23 18:20 · Score: 3, Insightful

Well, I came up with a solution, but somehow it just seems inelegant to me. Any other solutions out there?

100 prisoners in solitary cells. There's a central living room with one light bulb; the bulb is initially off. Everyday, the warden picks a prisoner at random, and that prisoner goes to the central living room. While there, the prisoner can toggle the bulb if he or she wishes. Also, the prisoner has the option of asserting the claim that all 100 prisoners have been to the living room. If this assertion is false (that is, some prisoners still haven't been to the living room), all 100 prisoners will be shot for their stupidity. However, if it is indeed true, all prisoners are set free and inducted into MENSA, since the world can always use more smart people. Thus, the assertion should only be made if the prisoner is 100% certain of its validity. The prisoners are allowed to get together one night, to discuss a plan. What plan should they agree on, so that eventually, someone will make a correct assertion?

* SPOILER *

.

* SPOILER *

.

* SPOILER *

.

* SPOILER *

The rule is: Turn on the light if it's off, unless you've already done this once, in which case, do nothing.

The day all 100 of you meet, designate one person to turn off the light. Have them count each light they turn off. When they reach 100, they will know everyone else has been out already, and can safely demand their freedom.

(Of course, assuming the warden really does pick someone at random, he could pick the same person every day, forever. Or not pick one person, every day, forever. Either way, there's no guarantee you're ever getting out.)

--
He who refuses to do arithmetic is doomed to talk nonsense.

Re:whee this is better than games magazine by The+Dark · 2002-07-23 18:29 · Score: 2, Insightful

It doesn't matter if there is a tail in the first 20, if there is then it becomes a head, so you end up with 19 tails in the first 20 and 19 tails in the next infinity.

--
sig's not here

These tech interview questions are STUPID by JamieF · 2002-07-23 18:35 · Score: 5, Insightful

Am I the only one who thinks this interviewing technique is retarded?

Because Microsoft does something most definitely isn't a reason to emulate it. Microsoft isn't exactly known for producing well designed software, nor software that reuses proven patterns or algorithms that solved known problems 20 years ago. Better to hire a bunch of 21 year old college grads who can solve word problems from 8th grade algebra, and pretend that Microsoft invented computers! Whee.

When I hire developers I want them to be good developers, not promising young interns. My interview questions typically involve technology questions, process questions, some theoretical PROGRAMMING questions, and some social / communication questions. I'm not saying that hiring smart people is a bad idea, but ignoring skills and only looking at generic problem solving ability is a recipe for unbelievably bad code. It's like hiring musicians based on measured hearing sensitivity and reflexes. OK, maybe that matters if you want to figure out which 5 year old is going to be a prodigy, but hand them an instrument and the noise that comes out is going to sound like ASS.

Examples of things that "smart" developers I've worked with before have totally missed:
- the existence of more efficient data structures than arrays
- generalizing code into reusable chunks (functions, objects, whatever)
- regular expressions
- the difference between "client" and "server"
- the reason for using descriptive variable names
- collection libraries with built in sorting ("whatcha workin' on?" / "coding up a quicksort algorithm" / "in a J2EE app!?!?")

You can't just get this from reading a book, either, although that definitely helps. You have to have some degree of EXPERIENCE too: at least a few projects, and some awareness of things like performance tuning, security, coding for maintainability, etc.

I would use these "tech interview questions" only for hiring interns or recent college grads where the expectation is zero experience, zero clue, zero skill, and a correspondingly low salary. After all you're investing in someone. But for someone that commands a market rate developer salary in the high five figures, screw the brain teasers - just spend a couple of hours grilling them on skills, experience, discipline, etc. They will respect you big time in return because they know when you extend an offer that they won't be working with a bunch of dumb-asses who can get the explorers across the river without being eaten by the headhunters but who can't code their way out of a soggy paper bag.

Re:These tech interview questions are STUPID by MeerCat · 2002-07-23 22:15 · Score: 4, Insightful

Precisely why companies end up with the wrong employees. My usual answer to these questions is "Sorry, the interview ends here, you failed", or (if I feel like baiting them) to "think outside the box" eg the bridge/flashlight/limited time issue "so, one guy is lighter than the others and they realise they can cross together, or they wait til their eyes adjust to the darkness and they're fine, or they check their watch and realise they have more time than they thought". If the interviewer says "no, wrong answer" I tell them they've missed "the big picture" and they need to "free their minds from the imagined constraints", and then ask them what we're doing next...

On a similar note, I do NOT want to hire staff who can put a list of obscure C++ operators in order of precedence, I want to hire those who say "well, I'd look it up if need be, but to make sure the next guy reading my code doesn't get confused I'd simplify the expressions with braces"... bingo - instant pass !

Interview questions should be open, not closed.

--
T

--
I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best

Re:One of my favorites by The+Cat · 2002-07-23 19:18 · Score: 5, Insightful

I've caught some really bright people with it.

So, what's the point again? Proving people aren't as bright as they think? Making people sit there and squirm because they really need a job, are nervous anyway, and have some "three cups and a white marble" puzzle standing between them and feeding their kids?

I don't get it. My first question would be "why don't we just hire the bright people and get back to work?"

You can see where this has led Microsoft by g4dget · 2002-07-23 20:02 · Score: 3, Insightful

Yes, these questions look exactly what Microsoft optimizes for: employees who are really "smart" in a Mensa-sort-of-way. Too bad that programming isn't about being "smart", it's about craftsmanship, taste, engineering tradeoffs, tradition, experience, and long-term dedication. And, not surprisingly, those are areas where Microsoft is sadly lacking.

Using riddles by DustMagnet · 2002-07-24 01:54 · Score: 2, Insightful

I've given more interviews than I've taken. Once I asked a programmer a kind of programming riddle. It was a simple one to learn if he understood that readability was usually more important that optimization. (You know that don't you?)

The guy freaked. He started complaining that it was unfair and things like that. The funny part was I wasn't judging based on what answer he gave, but how he answered the question. He could have done well, by just rambling about the tradeoffs between different answers. Hell, he could have picked any answer and still got the job, but to lose it over a single question. That was unacceptable.

Where I work, things are often unfair. You can't freak out about it, or you're lost. He was the only person we interviewed for the job. We didn't hire anyone.

--
'SBEMAIL!' is better than a goat!!

Why I Failed My Microsoft Interview by JohnnyO · 2002-07-24 02:16 · Score: 2, Insightful

I'm not sure if this question is on the page or not, as I can't access it. (Slashdot effect anyone)

Anyway, during my Microsoft interview when I was an undergrad, they asked me the following question, which I got "wrong"

You have a 7kg bar of gold (assumed rectangular). Your employee gets paid 1kg of gold a day for seven days (because apparently Microsoft people don't get the weekend off). What is the minimal number of cuts to make such that you can pay him 1kg every day?

I came up with some creative solutions, such as:

Cutting in 3/4 section, stacking the sections, and recutting, so one cut breaks two pieces.
Cutting a cosine wave into the bar which just brushed the edges with period 7.
A whole bunch of other ideas, all of which were "wrong".

Anyway, after much back and forth, he basically hinted away that the answer he wanted was to cut the bar into sections of 1kg, 2kg, and 4kg. Then you give him 1kg the first day, then on the second day, give him the 2kg and ask for the 1kg back, etc etc. (ie binary arithmetic basically)

Personally, this seemed like the stupidest answer ever to me, in that you were making the assumption that your employee would a) not spend any of the gold you gave him and b) bring it back to work with him the next day.

Long story short, I didn't get the job, but I think that it shows that people are too fixated on what they think is the "right" answer to something like this, when in reality, there are other solutions.

I could also add some good natured Microsoft bashing about how they make stupid assumption like this in code, but then you wouldn't have anything to reply with :)

Re:Microsoft interview questions by ch-chuck · 2002-07-24 02:20 · Score: 2, Insightful

Man, that's great. But isn't this backwards:

"whichever computer gets a blue screen of death first will win the fortune for its owner."

To work, shouldn't it be "whichever computer gets a BSOD first will lose the fortune for it's owner." ??

--
try { do() || do_not(); } catch (JediException err) { yoda(err); }

Re:Microsoft wasn't responsible dumbass by Anonymous Coward · 2002-07-24 04:33 · Score: 1, Insightful

I've seen a windows system, fresh off of install (nothing added in, all drivers detected by windows), with no hardware problems, crash in under 20 minutes.

the same system ran Linux for a month without rebooting.

I didn't think anything of it at the time. I should have video taped it..........

Bingo! Nice Solution by ASeed · 2002-07-24 07:33 · Score: 2, Insightful

I would call it "the Bingo solution"...

- You are asuming that everyone has paper and pencil (or similar instruments).
- They have to be careful (not to loose the count of the days so that incorrect info is transmited)
- If the prisoners were taken at a regular pattern, they would never go out, but the text says "Everyday, the warden picks a prisoner at random" so there in no regular pattern.

The first days:
In average, in the first 100 days one should be picked in his own day, so himself and the next one who visits the room know that he has been there. Both can tell about it if they are chosen in that day.

The last dyas:
Probably, the last days before freedom many of them have their "bingo cards" almost complete and they are waiting for the last to be chosen to visit the room in his own day.

--

--
ACid

26 of 747 comments (clear)