Sites like this make me sad. For some reason it reminds me of an article I recently read in the New Yorker about Magnus Carlsen and his comments about how widespread use of chess software and databases is ruining human chess, because people have started to think like the computers. Too much reliance on information, less on originality.
Based on my experience, A lot of tech interviews in large companies nowadays are mostly done by young people who have limited understanding of what a good employee is (because more tech savvy guys don't want to waste time with interviews) and who therefore keep asking rote questions like: "how do you shuffle a deck of cards", or (my favorite) "What is the 'mutable' keyword do?" and string matching the answer to the right one in their minds. This in turn has affected the interview preparation process, consisting mostly of memorizing the answers to the rote questions.
Which (as the architect in The Matrix said) has led the would-be coders, inexorably, here and similar sites.
> Too much reliance on information, less on originality.
I dunno -- if there's a giant, fairly-comprehensive question bank, and you can quickly reproduce from memory a good answer to each question, isn't it just possible you've actually learned the material?
Do people actually ask this. I can't understand if it should be, "What the the mutable keyboard 'do'". I'm not sure of any mutable keywords by the name of "do". Or did you mean "What does the 'mutable' keyword do". Again, I'm not familiar with any popular programming languages with the keyword mutable. If they are just asking for the definition of mutability, that seems a strange question for a technical interview.
From my experience most of these interviews at these big tech companies have these kind of questions. And they suffer from having inexperienced engineers conducting the interviews. I think this is a big, untalked about problem with regard to why tech companies have such a lack of talent.
Kinda sorta... code golf is all about making the smallest solution, which is an interesting challenge, but not one you'd necessarily want to use in practice. Most of the winning answers have a high degree of obfuscation.
True, that's what the definition of codegolf is but that particular site actually allows more than just codegolf (including puzzles that would be given on interviews). The name is not encompassing of what the site is about (I'm sure they've been discussing this problem on the meta).
It depends on the type of technical interview. If it's the sort of drivel that HR throws at coders then the less in the world the better. There are circumstances where this would be beneficial however. For my Google internship interview I searched for examples of the questions they'd ask both to put myself at ease and also to practice.
I didn't go searching for questions so I could recite the answer during the interview, but instead to instead give myself a mental warmup. It's akin to sports people stretching before they run a race.
Whether the questions themselves are indicative of strong future performance is another question entirely, but at the very least I do enjoy the majority of Google's interview questions. Analytical and algorithmic puzzles are entertaining and I think it's those sorts of people that Google are filtering for.
That article is way too vague to be of any use. There are a handful of small studies that show less-than-optimal results for pre-exercise stretching when we're talking about running.
Soccer, basketball, dancing, weight lifting, rock climbing, none of these have anything to do with those results, and you should talk to people who have been doing the activity for years about how to be healthy, not about.com.
I was wrong; there hasn't yet been a causal relationship established between pre-exercise stretching and increased injury (though some studies do suggest such a relationship).
The studies do agree in general, however, that stretching before exercise does NOT reduce the chance of injury.
I think this project would be far more useful as a computer-science-version of Project Euler (http://projecteuler.net/). People could then compete on full, working implementations of common interview questions in a variety of languages, that must execute on e.g. Codepad (http://codepad.org/), rather than posting what seem to be really wishy-washy, hand-wavy answers to puerile questions.
Then, perhaps with strong moderation, only questions that demand some compromises should be accepted. e.g. implement a container that can be traversed both forwards and backwards. What are the complexities of your container? How could you improve X, and what would the cost be? etc.
I think that's a good idea but I don't know if it would work. Some of these questions would take a TON of work to actually complete. I think people are answering them in the way they would answer it in an interview.
One of the questions is 'Design a Twitter-like social network web application'. This is obviously not a small or quick project. I'm guessing Google asks this in the hopes of getting a hand-wavy answer and analyzing you based on that. I'm not saying your idea shouldn't happen (it would make an interesting site) but I don't know that it would work for all the questions.
What's the goal of this site? I'm not sure I'd want to ask someone a question that they may have already read the answer to. When I interview someone, I want to know what they actually know or can figure out with hints, not whether they have Googled for the right list of questions.
Edit: oh, even worse, it tags them by the company that asks the question. Great. I'm sure those companies will appreciate having to come up with brand new questions for each candidate. And candidates will really be better off getting in based on memorized answers, then finding themselves unable to solve the actual problems in the job. (sarcasm)
Wouldn't hitting Google be the sensible option to answer a question that you are pretty sure that other developers are likely to have encountered before?
So you might as well test how well people can Google rather than solving a problem by themselves... :-)
It's pretty easy to tell when a candidate has the answer memorized, and it is pretty easy to push them to explain their answer beyond what sites like this give. If they can't tell you things about how their answer would scale, what the tradeoffs are, why they used data structures they did, and what they'd do with slight modifications to the question, they probably won't just skate through the interview.
I think "XOR Swap" sums up my opinion on most Tech Interview Questions.
The only question I would ever ask about the XOR Swap trick would probably be "Give 3 reasons never to use this" (assuming you are in a language as least as high level as C).
Hm, I thought the reason for not using it is hardware-related (if your CPU is multi-issue, the dependencies between the three assignments kill performance). What are the language-specific reasons?
1) It obfuscates (the most obvious thing, but still worth mentioning).
1) It is incorrect if you swap a memory location with itself (which many algorithms, like sorts, can end up doing without meaning to).
2) It is always slower on any modern optimising compiler than using a temporary in Java, C and C++ (a strong claim to make, but I stand by it. That's why I list specific languages where I know about the internals). Modern compilers use "flow" techniques for temporary variables. A swap will usually compile away to the compiler internally relabelling which value is in which register, and therefore no code at all.
Most of the good candidates I have interviewed prepare a lot for interviews already so I doubt this helps them much. All of the bad candidates I have interviewed do no prep work at all so this won't help them either.
I agree with you. If the point of "prep" for an interview is memorizing and reviewing stuff you haven't used in years, and will likely never use while you're employed at the place where you are interviewing, then it's largely meaningless. It's just cramming for an exam, instead of meaningfully understanding and using concepts. And don't get me started on "brain teasers," which don't tell you anything at all meaningful about a candidate.
Better questions work something like this: what's the most challenging technical problem you had to solve in your last job? Why was it so challenging? What did you have to learn to solve it?
Or you could just ask good interview questions that don't require knowledge of computer science trivia, like asking the candidate to write a program that plays hangman.
Of course, depending on the application computer science "trivia" could actually be part of the job requirement. E.g. if you're trying to build a scalable web service, maybe it really is important for the candidate to know when to use a heap.
I think a more or less unequivocally bad interview question is how to figure out if a linked list ever loops back using constant space. Maybe I'm just extrapolating my own stupidity, but I don't think that's the sort of thing people can reliably be expected to discover for themselves on the fly, so you'll just end up filtering out folks who haven't heard the answer to the question already.
No offense to ankur, but his hash function is the silliest hash function ever. It looks intelligent and reasonable and is the kind of answer I would trust if I didn't know better. But what kind of hash function is injective? If I wanted to store arbitrary doubles into his hash table I would need a zettabyte (that is a billion terabytes) of memory. Ooops. I should be able to warn people about that somehow.
I welcome sites like this. By spreading the answers to these largely contrived questions, perhaps we can get employers to move to methods which actually reveal one's ability to get stuff done and create value.
Based on my experience, A lot of tech interviews in large companies nowadays are mostly done by young people who have limited understanding of what a good employee is (because more tech savvy guys don't want to waste time with interviews) and who therefore keep asking rote questions like: "how do you shuffle a deck of cards", or (my favorite) "What is the 'mutable' keyword do?" and string matching the answer to the right one in their minds. This in turn has affected the interview preparation process, consisting mostly of memorizing the answers to the rote questions.
Which (as the architect in The Matrix said) has led the would-be coders, inexorably, here and similar sites.