What is the point in examining software-engineers about data structures and algorithms during job interviews, while everybody knows that in real life we hardly bother about all these things?

On your update: In recruiting there are several methods of testing a candidates validity. One of the things a company will try to do with a new candidate is to figure out if a candidate has the skills to perform in the job. The are literally hundreds of ways to do it but in this stage, as it's not the only requirement for a candidate, they all tend to be based on exclusion. In your example the company basically states that a candidate needs to at least know how to create an algorithm from scratch. In many of these tests a skilled interviewer is not so much testing your proficiency in memorizing a certain algorithm but will ask you they reasons why it works faster or slower. The explanation is in this case more important than the answer as it brings up your understanding of algorithms in general. Any candidate could of course memorize all the reasoning behind it. The example you mentioned is also used as a simple blanket test to really ask; "Do you know how to program?". Fizz Buzz is that same kind of test basically saying, show me that you can code. In some cases it's also about showcasing your coding process to the interviewer. On a note from the interviewer side; I've done some recruiting and interviewing and a simple Fizz Buzz test already excludes half of the candidates. A simple tool to make sure you're actually talking to people who can code. Your question about if candidates should feel regret for having to learn this; basically no. Yes; a algorithm test should not be the only thing you are tested on. Yes; there is more areas, even outside of coding, you need to be judged upon. But as a simple test to make sure you know how to code and at least some understanding of algorithms it does the job. Of course there are ways around this and this method, like almost any other out there, is not foolproof but it is a good enough method to get the job done.

I see passionate developers who can't do well on data structure&algorithm coding questions, but they can still be valuable developers who get things done, especially in small start-ups. I also see developers who can do well on coding questions, but they contribute mediocrely in large companies. I think the way software engineers get interviewed in US is sort of like the college entrance exam in China. People who do good in the exam have a higher chance of being smart, but it's by no means a perfect selecting mechanism. But I understand the reason behind this way of selecting talents: so far it probably has the best chance of telling quality software engineers from mediocre ones. But I don't think it's perfect.

Short version, if a candidate can't explain the difference between things he or she has absolutely been taught about, there's zero chance that candidate can make good decisions when the business is on the line. To go a little deeper, if you have to choose a sorting algorithm, do you really think it's acceptable to read all the pages and learn what you need for a useful decision on a deadline?

There is a certain cargo-cultish behavior when it comes to evaluating programming skills. I don't know about you but, in my college, most of the computer science exams were focused on algorithms and data structures. My database exam, for instance, had questions about normal forms, not on how you manage a pool of connections to the database (which is a much more important skill in real life). Also, in highschool, same shit: every computer science class had some (more basic) algorithms they played like a broken record. I remember I learned to compute the matrix determinant using some fancy method I don't even remember whose name it bears - some important guy - in a highscool class modestly titled "the basis of computer science". So it is not surprising that, given the amount of brainwashing one receives during the educational years, what makes a good programmer becomes synonym with "do you know how to write a sort using only a pen and a paper" - whoever asks you this question probably had to do this for an exam. Oh, btw, the next time an interviewer asks you about sorting you should ask them in return to point out what is wrong with "almost every implementation of merge sort": http://googleresearch.blogspot.fr/2006/06/extra-extra-read-all-about-it-nearly.html

Richard gave a very good answer, and I'd like to add an additional viewpoint that I have as an interviewer. Asking interview questions about data structures and algorithms is an efficient way to separate the unwashed masses with their credentials on their resume from the real candidates who can fill the job. People who claim that they are software engineers because they "know how to program" without understanding how to build a robust and bug-free software system typically can't answer questions about searching a binary tree or implementing an efficient sorting algorithms. Real software engineers understand how to build efficient and reliable software systems. They design their systems to solve specific business needs rather than just hacking together something that works. Software engineers know how to build and optimize the software solution for the employer's needs, whether that is speed, usability, or something else. An interviewer can pick out if a candidate thinks like a software engineer by watching how the candidate solves data structure and algorithm problems. It's an easy way to separate the unwashed masses from the people who can actually do the job.

I very negatively react to the UPD part, because it reveals a basic misunderstanding of formal logic. Which may in a interesting fedback loop give some light back on the original question. The first sentence  "How can anyone expect you to be able to improve something when you don't even adequately understand it?" is not meaningless. It's a common speech way of stating the statement (which may or may not be true, but I believed is shared by many people): Not "understanding" implies not "able to improve" You can't reply to that with the statement: "How can anyone expect you to be able to improve something when you adequately understand it?" Would it mean ? "Understanding" implies not "able to improve" ? (I believe most people would totally disagree with that statement) or "Understanding" implies "Either able to improve or not able to improve" ? Which is a tautology and already the conclusion you are drawing. It means that the stupid conclusion you are drawing using formal logic (really ? I didn't saw formal logic here) is not coming from the initial statement but completely from the answer you provided itself. And seriously, questions asked in interviews are usually not at all like what you say. Interviewer are rarely asking about details of all existing sorting methods (sorting is an example), far from that. They ask about well known very basic programming methods. It is very unlikely that any interviewer would ever ask you about parallel sorts, or smoothsort, even heapsort. But is is indeed expected that everybody has some notion of bubblesort and quicksort for someone claiming basic knowledge of algorithms. Like it is expected for someone claiming to know C language to know the full list of available operators and their precedence. I interviewed programmers claiming to have 5 years of C programming experience ignoring the existence of modulo operator, and the binary operators, unable to tell the difference between stream io (fread/fwrite) and io using a file descriptor. That is not crispy knowledge, it's basic knowledge. When algorithmic questions are asked, it's more or less a way to observe how a candidate reacts and try to solve something new. If a given candidate is too at ease with a question, my reaction as an interviewver is usually "OK, he was prepared for that, the question is useless! I will have to ask another one. I will also usually ask several questions from several skill domains the candidate is claiming to have (his claims), even if I'm looking for someone who will work using some other technologies tan the ones I asking him about. As an interviewer I'm interested to see if he is genuinely at ease, if he is a kind of a beginner with a mindset toward learning, or if he doesn't have a clue and/or doesn't care or lied about his claimed skilled. Experts or beginners can be ok but the other categories I of course try to avoid. Would you hire a cab driver not knowing the kind of fuel he should put in in tank or would you believe he is lying ? That probably it's not even his car... and that leaving him drive you could be dangerous ? Of course knowing what is in the tank has no impact on driving skills... nevertheless.

Do you hire a lawyer because they can write legalese or because they have intricate knowledge of the law and can solve every law problem ever encountered thus far? There's your answer. When hiring a somebody to build a non-trivial system, one is not just looking for a coder but a mathematician, computer scientist, and all-round problem solver. But if one simply needs to cobble together a trivial CRUD app, hiring the cheapest code monkey is perfectly alright.

If the original interviewer presented the questions about sorting as you said, including something like "you're not allowed to hesitate..." then I would consider that a pretty crappy interview. In-person interviews are pretty rough tools to get to know someone before making a hiring decision. Everyone has an off day (including me), some people are really nervous in interviews, some are nervous writing code outside of an editor, there could be a communication problem, we could just be a bad mix of personalities. But, they're what we have short of 90 day internships. I would hate to pass on a brilliant candidate because they were a little nervous or I was talking too quickly. So, I do what I can to calm them down and stack the odds in their favor by letting them pick the language and giving what is typically a simple problem solvable in 10-15 min.  I'm also not the only person on the interview team, and I have a bunch of data points about how the interview usually goes so it's hopefully easier to spot whether I screwed up the interview or the candidate did. When I'm doing a technical interview, I'm looking for a few things: "1) Is this candidate smart? 2) Is this person at least sort of comfortable writing code?" The coding question will often be pretty simple because I'm really just want them to show me they can take a task and solve a simple problem. I won't be a stickler for syntax, there's no "trick" to the questions. More often than not, it's a way to weed people out. The problem is designed to be simple enough that if a candidate struggles through it, in a language of their choice something must be going on. Either the candidate isn't comfortable translating what should be a pretty simple request into code or the interview went awry somewhere (me, candidate, lack of coffee, whatever). If the candidate does well on the coding, I still have an opportunity to sort them into "average" vs "maybe very very good". I can now have a conversation about the language choice vs another on the resume. Candidates that write code easily and have thought out opinions on languages or other technical topics can be really great hires. One thing many technical groups don't do well is acknowledge that interviewing is a separate skill. Some very talented developers won't have it naturally and may not be interested in getting better. Nearly everyone at any level will need to develop their interviewing skill. That takes time and effort, but it pays of in the long term when building a team.

The objective of the job interview is to separate the wheat from the chaff. Too many applicants can't do the basics, such as what you describe. The assumption is that if they can't explain the basics in an interview, they won't do as well as the applicant who can. One of the most useful things an interviewer can ask for is a work sample. This has been shown to predict job performance. For software developers, that means solving coding problems or something like that.