From your about page azat:<p>"My primarily fields are Ruby on Rails, NodeJS, JavaScirpt, Backbone, HTML, CSS and of course PHP!"<p>Now I'm sure your a great guy, but there are a lot of people out there with that exact set, or nearly that exact set, of technologies who can't program. They can take a page and hack it to do what they want, they are 'cooks' not 'chefs.' Did I mention there are a lot of them? And if someone is looking for a programming position, and they see a resume that is full of these platform things, one of the questions they will jot down is "be sure they can actually program" on their to do list for the interview.<p>Back in the 90's there were a ton of people who put 'web site programmer' on their resume but it meant they had used a copy of Pagemaker, not that they actually <i>knew</i> what the HTML spec had in it, so if you couldn't express it in Pagemaker they couldn't do it. Those interviews would start with things like "style this page using <some HTML or CSS feature>." It was a winnowing question to separate the tool users from the folks who knew what actually happened.
> Yes, 10 years ago it did matter which function to use, because memory and CPU were expensive. Not anymore!<p>entirely wrong. if a candidate doesn't understand the difference between a linked list and a random access array, the difference between a hashmap and a b-tree, there's a good chance they're going to be making some pretty fundamental mistakes.<p>O(n^2) is still bad, no matter how much modern CPU and memory you throw at a problem.
As the interviewer, the question I'm trying to answer is "Can you fulfill a role we need fulfilled?" There's no direct way to determine the answer to that. However, a necessary-but-not-sufficient condition for a broad range of development positions is "Can you write code in any language to sort/reverse/find elements within an array".<p>The details will vary by interviewer and by role, but the basic idea is the same: if you are incapable of doing this, nothing you say in other interview portions will fool me into thinking we can hire you.<p>See <a href="http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html" rel="nofollow">http://www.codinghorror.com/blog/2007/02/why-cant-programmer...</a>
This is sort of well-worn territory. It's been addressed with greater detail, data, and eloquence several times over. Threatening to puke about a commonplace whiteboard question really just comes off as obnoxious.<p>I don't see what the problem is with just memorizing the answers to these boilerplate questions. That way, you can be proactive about your response when asked. You can even just use your knowledge of the question to anticipate and disarm the interviewer's boring whiteboard exercise. But I guess being plaintive and edgy is as good a method as any to get to the front page of HN, right?
C programming interview questions are effective at detecting good generalist skills. I'm consistently surprised at how many people struggle with parsing an int from a string in C. Not that someone would ever do this on the job, but these questions are sort of the CS equivalent of math problems.
<i>Another sad thing, which I gladly didn’t see that much (but there still were a few interviewers) in the Bay Area compared to the East Coast, is asking terms, function names, definitions, slang, etc. Expecting people to remember functions’ syntax is a sin in itself! All this leads to hiring people with good memory vs smart people. That’s especially wrong when all these information is only a Google search away. And being smart can’t be acquired or substituted with search engine results.</i><p>I hate this, and have run afoul of it multiple times[1] over the past few years. I once had an East Coast company decide I didn't "know Unix" because I couldn't regurgitate the POSIX API over the phone.<p>[1] My focus has always been on East Coast/Midwest companies
There's something else questions like these reveal - how you react to inquiries you consider "beneath you". Do you get annoyed? Do you preach? Do you adopt a condescending attitude? You might be able to do the tech work, but part of the job might be having to interact with various departments who just aren't as gosh-darned smart as you. How do you react when questioned about such 'trivial' matters? Do you lose your cool? You might not be a great fit for the culture of the org then.
First, boredom is a problem of depth and duration.<p>Second, these are not hard questions. Bubble sort should be a slam dunk.<p>A few years back, we used a quiz that had the same divisive effects as fizzbuzz does today:<p>"Write, in your favorite language, a bit of code to reverse the bits in a word." This led to an astonishing fail rate amongst applicants that claimed to have a list of technologies on their resume.
> When is the last time you had to write your own array sorting function or function that performs search in an array?<p>About a month ago I wrote a merge sort routine in JavaScript where the comparison function is a person. There is no library function for this, because the response is asynchronous.<p>> There is always a function for that in a high-level languages like Ruby (index), JavaScript (indexOf) or Python (index).<p>These functions don't do what your interviewers asked. Python's index won't give you duplicates, and it's at least equally non-trivial to use JavaScript's indexOf with two arguments in a loop as it is to use a hash, and the algorithmic complexity of the former is much worse, so why would you do it?<p>> Another sad thing, which I gladly didn’t see that much (but there still were a few interviewers) in the Bay Area compared to the East Coast, is asking terms, function names, definitions, slang, etc. Expecting people to remember functions’ syntax is a sin in itself!<p>On this point, I agree.
You'd be surprised at how many people fail the question "reverse this linked list", and of the people who pass that, how many fail the question "now do it without using recursion".<p>"Stupid" interview questions exist for a reason. They filter out a lot of people.
How about everybody that criticizes these questions, post their alternatives for determining candidates. It seems like everyday there are posts on HN criticizing these hiring techniques, but rarely does anybody post any alternatives.
Generally speaking, it's a good practice for interviewers to turn whatever problem they are working on into a simplified interview question and give it to the interviewee. This way they'll know if the candidate can solve problems that they'll <i>actually</i> face if they get the job.<p>Interview questions related to finding shortest path, min/mix of whatever, finding x numbers that sum to y etc.. will only tell the interviewer if the candidate has prepared academically for the interview.<p>In the end, the interviewer will probably end up hiring the wrong person. A person who has done his/her homework but cannot solve the simplest scalability problem.
When I interviewed at Google, they had me implement a basic regex parser in C on a whiteboard. I think that's a much better way to separate the wheat from the chaff.
It's a boring problem, but it reveals the candidates' comfort/experience with programming, approach to problem solving, and background knowledge of CS concepts. Those are things I'd want to know when hiring a candidate. These questions are used to determine competency.<p>If these are the only questions being asked in an interview, that is cause for concern. But they are useful for weeding out underqualified candidates.
Knuth wrote Volume 3 <i>just</i> about searching and sorting, so there must be some interesting and challenging questions on the subject that could potentially be used in interviews.<p>Not that quizzing people on random pages from TAOCP is a good technique, I'm just pointing out that if you're looking for a series of increasingly complex questions to ask in an interview, searching and sorting is a rich area.