What point did you prove with bubble-sort? Was the list already nearly-sorted?

 It sounds like it would have been like this:"Next step - we sort it"."How?""It doesn't matter. You just sort it. I'd use the inbuilt sort function"."OK, but we still want to know you can sort a list.""OK ... sigh ... what algorithm? Quicksort? Bubblesort? Mergsort?""We don't care.""Um, OK, if you want me to roll my own sort algorithm, but don't care about performance, let's do it this way ..."
 So the point is, "don't ask me to solve extremely common and easy-to-explain problems, because someone else has already written good solutions?" What are the alternatives? Questions about things nobody uses? Questions that are hard or lengthy to explain?The best alternative I've heard about is something like a trial period, internship, or culinary "stage." That's a big investment for both parties to make without even finding out if someone can write and debug a simple program to solve a well-defined and familiar problem.
 It's kind of a big deal that you pick the right algorithm. From what I can gather, the interviewer didn't care what algorithm was used, as long as the candidate could implement it.This is kind of silly, and the candidate decided to be a smart-ass and rub it in by demonstrating a really bad algorithm.They should ask "well, what do you think the trade-off should be? Given that, what's the best algorithm you know for this set of trade-offs?".Interviewing is hard to get right, because it's confrontational. Bad candidates want to fool you. Looking at the total system, the best bang for your buck is getting better candidates to apply. I've met very few managers who do anything other than a piss-weak job at getting good resumes onto their desk. They often throw a rough job description to a some liberal ars major in HR, who puts the ads up then tries to prune down the candidates who's buzzwords don't match the requirements.
 Often interviewers don't care about something that seems important because we know that one of the other interviewers has already tested it.There've been times where I've had a candidate code up a solution and I didn't care whether he got the solution right or not. Because other interviewers had already given him coding & algorithm questions, and I figured their feedback would show whether or not he could do that. I was looking for familiarity with JavaScript language features and DOM APIs, and how he approached a vaguely-specified problem and what design choices he made. That was the part that hadn't been tested in earlier interviews.Interviewing doesn't have to be confrontational. When we're trained, we're told that our job is to get the candidate to show us their best side. That aligns with the interests of both good and bad candidates. It's just that good candidates will be able to show us a really good side, while bad candidates simply don't have that ability. Then it's up to the hiring committee to set a really high bar and only accept candidates that have demonstrated it.
 Scarily close to the actual conversation!
 Really? The interviewer asked you to implement a sort on a problem that had nothing to do with sorting?

Search: