Tech-Interview Riddles

An anonymous submitter writes "A computer engineering student at UC Berkeley has made a comprehensive archive of riddles from technical interviews. Very challenging and loads of fun. Also useful for interview preparation."

Comments

Why do interviewers use "riddles"?

[Turing Machine]

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

[cwikla]

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

[JamieF]

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

These tech interview questions are STUPID

[JamieF]

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

[MeerCat]

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

Re:One of my favorites

[The Cat]

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