7 ms·
Damn right. Even worse than whiteboarding random algorithms are logic puzzles. I can sort of see how implementing my own hash table fits into a dev job, but I
by potatolicious 14y ago
Damn right. Even worse than whiteboarding random algorithms are logic puzzles.
I can sort of see how implementing my own hash table fits into a dev job, but I why manhole covers are round, or light bulbs in a room has absolutely nothing to do with anything relevant in our field.
People who use logic puzzles as proxies for anything in an interview have my everlasting scorn.
- smoyer 14y agoLogic puzzles are definitely useful ... how else can the interviewer feel superior (after all, he/she already knows the answer and has probably forgotten how they came by that answer).
- rdtsc 14y agoIf I was given a logic puzzle I would ask them "so how many times in the last year this company had to solve this particular puzzle here?".
- tiziano88 14y agoI think that question about why manhole covers are round is more of a urban legend than anything else. Or it might be a question asked to someone applying for a non-technical role, to see how they reason about the issue (though it is most definitely not the best question to achieve so).
- jkimmel 14y agoEntirely an informational note, but the manhole-covers question actually originated at Microsoft if I recall correctly. There are several references to it around the web, and at least one primary source confirmation by an interviewer that he used the question on multiple occasions [1]. That said, the fact that it was first introduced by a highly successful company doesn't lend it any merit in my book. [1] http://blogs.msdn.com/b/bgroth/archive/2004/09/27/235071.aspx http://blogs.msdn.com/b/bgroth/archive/2004/09/27/235071.asp...
- rallison 14y agoAnecdotal, yes, but I have actually been asked the manhole cover question in an interview. Even if it started out as an urban legend, it does appear to be in use in the wild now.
- ghurlman 14y agoI was asked that question during an interview for a technical role at Microsoft. Granted, it was 13 years ago at this point, but they did really ask stuff like that, and probably still do.
- AdamTReineke 14y agoI haven't heard of those silly questions in the intern interview circuit. (2 at-school, 4 on campus)
- potatolicious 14y agoMy impression is that they are no longer in vogue - for a few years when I was in college (2004-ish) they were all over the place. Our industry is extremely faddish, even when it comes to interviewing... You can still see them in some places I believe. I've heard anecdotally that Microsoft is still a fan of them.
- hkmurakami 14y agoLogic puzzles test how much the candidate prepared for logic puzzles. It implicitly tests how much the candidate "wants the job", but it also has the effect of turning away the stars who have options. As the best continue to have more and more options available to them where the team members understand that this kind of interviewing is counterproductive, companies that continue to use puzzles will end up with candidates that need them, instead of the candidates that they need.
- qu4z-2 14y agoI dunno. I enjoy solving puzzles. Maybe I'm not a star :)
- nonamegiven 14y agoMy current job, they asked me one of those. I pretended to think about it for about 15 seconds, then asked for the answer (it had an answer). The guy said "You want me to tell you?" I said "yeah." I've been here a year.
- misiti3780 14y agohaha
- nazgulnarsil 14y agothe ability to just go with the already existing answer rather than constantly working everything out from scratch is quite an underrated skill IMO.
- msluyter 14y agoRe: hash table. I've been asking candidates to basically implement HashMap (for java positions) (without simply using Hashtable). It's an ongoing experiment. Although I've been told that this is a common question, I've actually never seen anyone do very well at it, and I have mixed feelings about it. On the one hand, it gets at some important java concepts: hashCode() and equals() and the relationship between them. Depending on how they go about it, you can also get into issues of runtime complexity, memory/speed tradeoffs, etc... It's a deep question that offers a lot of room for exploration. On the other hand, as mentioned, people usually do fairly poorly at it, and so my fear is that it's simply too difficult. I mean, I'd even be satisfied with solutions storing key/value pairs in a list -- inefficient, but workable -- but it's fairly rare that folks even get that close.
- danielweber 14y agoThe point of any question isn't whether they get it right or wrong. The point is how they work through it. I've been perfectly happy with people who didn't get the "right" answer to some question.
- smackfu 14y agoI would be surprised if many people knew hashing algorithms at all.
- msluyter 14y agoTo clarify, you don't need to implement a hashing algorithm for this question. (Using hashCode() suffices). And you don't even have to implement a hash table. As I mentioned, a working linked list of key/values would probably be an above average answer, if it came with the understanding of the big-O performance characteristics.
- ig1 14y agoLogic puzzle as the name implies are puzzles that can be solved using logic; typically deduction which neither of your given problems are. It's important to make this distinction because skills like deduction are actually critical to developers, i.e. identifying the source of buggy behaviour.
- bearmf 14y agoI really don't understand why manhole covers or stars in the universe puzzles are considered "logic puzzles". Logic questions are not of the form "why?" and "how?". Their structure boils down to "is this statement true or not?"
- antoko 14y agoIt is a poor choice of word. I'd suggest the reason for calling them "logic" is that the process by which you explain what you're thinking and why to the interview gives them an insight into your ability to use logic. The puzzles themselves are categorically NOT logic puzzles.
- bearmf 14y agoYes, you need a little logic. But for those puzzles it is (arguably more) important to know some key facts about the world which form a basis for your reasoning. I don't know, maybe reasoning based on wrong facts will satisfy some interviewers. Say, I can assume that half the stars in the universe are visible from earth and that there is only one galaxy and reason from that. The basis is clearly false, but I will be able to show off my "logic".
- krutulis 14y agoIf the motive is laziness or the objective is to trick or intimidate a candidate, then I agree that the method deserves scorn. But I disagree with your position the technique is never reasonable. I like to hire people who know more than I do, and in this circumstance puzzles occasionally help learn about a person. As a candidate I'm not particularly good at solving puzzles in this kind of situation, but I'm not bothered when people present them because the discussion and interaction about the puzzle matters more to me than getting the answer. As an interviewer it is important to ask questions that a candidate cannot answer to see how they react. Since I'm a slow thinker myself, I must sometimes resort to "unfair" questions. I don't expect an answer, I expect a reaction. After establishing a friendly rapport, finding common technical background, presenting an "unfair" puzzle, and discussing the puzzle a bit, then a discussion like this is golden: Candidate: "Do you believe my ability to solve this puzzle indicates how well I could do this job?" Me: "No. Though I often enjoy puzzles, I'm not particularly quick with them myself." Candidate: "Then why ask a question like this?" Me: "Because I want to see how you react when you don't know an answer right away. In your case, I had to resort to tricks."
- derefr 14y ago> As an interviewer it is important to ask questions that a candidate cannot answer to see how they react. In the context of an interview, that would just make me horribly frustrated--because my default response to not knowing the answer to a question, nor even being able to perceive a method to resolving my ignorance, is to go out and research the problem. Whether on the Internet, or by asking my coworkers, or finding an expert, or just running actual experiments and seeing a pattern in the large pile of data generated, this is usually "the" way to get a problem solved, and what I spend nearly 80% of each working day doing. I don't rely on "sudden gusts of inspiration blowing through me" to solve problems, because the time that could take to happen is unbounded, and it can't be made to scale, unlike research, which can be delegated as you please. But obviously, research is a tool entirely taken away from you in an interview. The only thing you can do to find out more about the problem is to ask the interviewer themselves--at which point you're basically playing a game of 20 questions, where instead of getting all the data you'd realistically expect in response to each query, you get dealt out precise quantities of informational entropy to string you along. This contrived situation is not one that applies to the average day in the workplace, and being made annoyed by it is no useful measure of how one reacts to real non-obvious problems.
- AdamTReineke 14y agoMy all-time favorite interview was one when I was interviewing for an SDET intern position at Microsoft. That interview (one in a day of four interviews) featured a great progression: logic puzzle, code the fixed input solution, code the n input solution, test your solution. The puzzle was (apologies to the interviewer, but it IS a common puzzle) the eight ball and balance problem, where one ball is heavier than the other seven and you need to use a balance scale to find the lightest of the balls in the minimum number of weighs. I'd heard of the puzzle but never worked it out. I initially jumped to the 3 weigh solution, but the interviewer challenged me to keep looking, so I kept thinking and I found the 2 weigh solution. He then asked me to write code that could solve the 8 ball problem. Pretty straightforward. Once I finished that, he had me adopt it to be able to handle [edit: any number of] balls. This tested my ability to abstract my code. Finally, he asked how I would go about testing the program and we talked through that. I cannot wait to steal that progression when I end up doing technical interviews someday.
- Jabbles 14y agoAnyone who's studied information theory would destroy that puzzle though. In the same way that someone with a physics degree would perform way above average on a "count the stars" question. Or someone whose dissertation was on computational biology would excel at a string-matching algorithm question. It is an example of the interviewer (or company/process) mistaking a specific problem as representative of all problems. Presumably they're looking for someone with "general problem solving skills", rather than "knowledge of astrophysics".
- pseut 14y agoYou can interpret the response more broadly, though. In this case, it was probably pretty apparent that the person hadn't worked through the problem before, so it is indicative of problem-solving and attitude. If he'd recited the answer from memory that usually comes across and then you have to pick something from a different area. If, as an interviewer, you literally can't find a problem that the interviewee hasn't already thought about, (i.e., he or she knows about computational biology, astrophysics, information theory, etc and none of this was obvious from their resume and previous positions) that can also be a good sign.