3 ms·

My major at my college has a class that asks these kinds of questions on tests. It's widely considered to be one of the most difficult and painful weed out cour

by tel 17y ago

My major at my college has a class that asks these kinds of questions on tests. It's widely considered to be one of the most difficult and painful weed out courses in the major. We were asked to describe how we would make an elephant fly, how much oil is used to make all the french toast for waffle house in a day, and other silly questions. We were also asked to rewrite non-linear equations in new units, design simple industrial scale chemical processes, and generally do the kinds of problem solving engineering trains you to do. These kinds of problems are relevant when done properly. The ability to reason with enormous quantities, think logically and out-of-the-box at once, make consistent complex plans, and, finally, explain these things to another person are often instrumental for solving problems and building new things. Those who passed and enjoyed this class are easy to pick out: they've been breezing through all of the upper level problem solving and group-based classes. At the same time, I think something like that bike-for-the-blind answer is genius. Sometimes it does come down to rejecting the question or, perhaps better, redefining it in a way that is creative and useful. Who knows how well interviewers are prepared to respond to these answers though?

jerf 17y ago
"These kinds of problems are relevant when done properly." Yes, if done with the correct expectations. The real problems arose in that it is also a bit of a test for the interviewer too, in that the interviewer must understand the point of the questions, one which far too many of them failed. In the worst case, which happens far too often, you're sitting there trying to mind read the interviewer for the expected response: "How much does the plane weigh? I'd ask Boeing." "Nope, you can't." "What, why? The reason why that's not possible might factor into the answer...." "No, you just can't." "Well, I'd ask a librarian." "All the librarians are dead." "What, why?" "Doesn't matter. Do something else." "Well, I guess I could find a scale that might be able to handle the weight..." "No." "Why?" "You just can't." And so on... (Because, honestly, "I'd ask Boeing or a librarian" really is the answer. Ask a better question next time.) However, in the end my real problem with this style of questioning isn't that. It's the opportunity cost in the interview. While you're dicking around with the question of how much a plane weighs, you could be talking about their previous projects, or doing a programming problem, either one of which will teach you far more per unit time than a brain teaser. If you really want a brain teaser, ask a non-trivial programming problem. Anyone still asking these brain teasers might just as well yell out that they don't care about at least one of "your time" or "their time". I don't need to filter people out based on their plane weighing skills. I want to know if you're going to spew cross-site scripting attacks into my websites, or if you're going to spew spaghetti code into my codebase because you can't do decent functional breakdowns, or if you think "var3" is an acceptable variable name, or if you're incapable of requirements analysis (the only thing those riddles tangentially touch, but not good enough for my tastes), or any of several other problems I've detected in interviews. There's better ways of obtaining all that information.
timwiseman 17y ago
"These kinds of problems are relevant when done properly." Agreed, but they have to be done properly, which is quite hard to do.

by tel 17y ago

jerf 17y ago

"These kinds of problems are relevant when done properly." Yes, if done with the correct expectations. The real problems arose in that it is also a bit of a test for the interviewer too, in that the interviewer must understand the point of the questions, one which far too many of them failed. In the worst case, which happens far too often, you're sitting there trying to mind read the interviewer for the expected response: "How much does the plane weigh? I'd ask Boeing." "Nope, you can't." "What, why? The reason why that's not possible might factor into the answer...." "No, you just can't." "Well, I'd ask a librarian." "All the librarians are dead." "What, why?" "Doesn't matter. Do something else." "Well, I guess I could find a scale that might be able to handle the weight..." "No." "Why?" "You just can't." And so on... (Because, honestly, "I'd ask Boeing or a librarian" really is the answer. Ask a better question next time.) However, in the end my real problem with this style of questioning isn't that. It's the opportunity cost in the interview. While you're dicking around with the question of how much a plane weighs, you could be talking about their previous projects, or doing a programming problem, either one of which will teach you far more per unit time than a brain teaser. If you really want a brain teaser, ask a non-trivial programming problem. Anyone still asking these brain teasers might just as well yell out that they don't care about at least one of "your time" or "their time". I don't need to filter people out based on their plane weighing skills. I want to know if you're going to spew cross-site scripting attacks into my websites, or if you're going to spew spaghetti code into my codebase because you can't do decent functional breakdowns, or if you think "var3" is an acceptable variable name, or if you're incapable of requirements analysis (the only thing those riddles tangentially touch, but not good enough for my tastes), or any of several other problems I've detected in interviews. There's better ways of obtaining all that information.

timwiseman 17y ago

"These kinds of problems are relevant when done properly." Agreed, but they have to be done properly, which is quite hard to do.