Recently, I have taken interviews and found that many of the questions are related to algorithms and math problems.
I think that there are lots of things that are important other than algorithms, such as experience, domain specific knowledge, basic OS/compiler knowledge, etc..
Why do they ask so many algorithmic problems?
Basically because algorithms are the core of programming. Just about everything you write follows some sort of algorithm, whether you realise it or not.
And math problems show how well you are able to solve logical problems (much like those you experience when coding).
Simple algorithm problems weed out the vast majority of interviewees who say they know something, but actually lack the skills for the job.
To be clear, it should be a problem that the interviewee has to solve, not merely recall.
They wrongly feel that people who memorize are better than those who don't.
Algorithm questions are environment-agnostic and look like being capable to test how smart a person is. It's much harder to fake understanding of algorithms that knowing a set of facts on some technology.
IMO it's worth asking at least simple algorithm questions since it reveals whether a person can actually sit down and think for a while not just google and copy-paste.
Because Algorithm questions is the real test for the smart of a person, and the real programming is to discover and develop a good algorithm not to make a program that you can get most of its code from the internet and you can solve most of the problems from others experience who face and solve the problem for you.
It gives the interviewer a chance to see how well you would work with others in a problem-solving setting; as well as testing the quality of your answers, it shows how well you communicate and interact.
If you know how to solve the root problems then you should be able to do it in any language, with any tools. Basic OS and compiler knowledge can be picked up in days, and I'd rather have someone who can solve problems than someone who can't who happens to have domain knowledge and experience.
Companies invest a lot of time and money into new hires. Skills in a specific domain or technology can be built up quickly, the ability to 'just get it' can't.
If they're giving you the name of an algorithm and asking you to describe it, that's fairly pointless (unless you're a new grad). But if they're giving you a problem that can be easily solved with common algorithms and data structures, then that's reasonable.
As for new grads, math and algo questions are a good way to see if they were actually paying attention during those 4 years. If they didn't learn what they were supposed to learn in school it's a bad sign. More that they weren't really interested or motivated than anything else.
You have to have a basic grasp of data structures and algorithms to do nearly anything. Take for example, storing a list of items. If you can't reason about whether it should be stored in an array, a linked list, or some other data structure based on what operations are going to be performed upon it, I don't want you writing code that I have to interact with in any way. Sure, some of the structures people commonly ask about aren't as often used in the real world (binary trees, for example) but your ability to reason about these structures shows your ability to problem-solve.
EDIT: I've noticed that a lot of the other answers are about memorization and whether you paid attention in school. That's not the point. Given a description of a data structure you haven't seen before, you should still be able to figure out how to perform operations upon it, and figure out the O(n) of the operations.
One of the most misunderstood elements of interviewing is why certain questions are asked. The reason people misunderstand is that most people don't realize that asking you a question you know the answer to is only half of the interview. I need to ask you questions that you don't know the answer to. Why? Because I need to see a couple of things:
As developers, we will constantly face challenges we don't immediately know the answer to. As a hiring manager, I need to assess that ability in a prospect. So, I ask you a question I hope you don't know and watch what you do. When I see you don't know, I ask, "what are you thinking?" to see if you will explain. If you can explain your thoughts in a clear and concise manner and handle the pressure of being in a tough situation, that will tell me a lot about how you will work in a high stress environment.
The last, and possibly most important reason is the BS issue. Many times (especially consultants) will be asked questions in a forum where they must give some sort of answer. In a meeting with a customer for example. I need to understand your propensity to BS. Nothing can get a project in trouble faster than somebody who will BS rather than simply say "I don't know, can I get back to you with an answer to that after I talk to some experts at my company?"
Also, frankly, algorithms are easy questions to ask for the interviewer. Interviewing is extremely tedious. You ask the same stuff over and over and over again. It gets boring and rote. Sometimes, I ask questions I have no clue what the answer is just to break up the monotony!
Algorithms play key roles in computer science and in software engineering. I would personally find it odd for an intense technical interview not to have at least one or two questions in the area.
Algorithm questions can probe a candidate's grasp on general techniques like divide-and-conquer, branch-and-bound, recursion, etc.
Algorithm questions can probe a candidate's knowledge of common useful algorithms like binary search and quick sort.
Algorithm questions can probe a candidate's grasp on the application of algorithmic complexity analysis in performance studies and the development of efficient software.
Finally, difficult algorithm questions can be used to intentionally push the candidate out of his/her comfort level in order to see how the candidate performs in such a scenario.
I don't fully agree with the other answers till now.
The interview should check in a first place if you're suitable for the job you're applying to. I believe that in most of the places that ask interviewer to devise some algorithm, it's not required to develop algorithms on day by day basis and real work is far from academic one.
I might well be one of those interviewers, as I tend to ask a few questions around implementation of a couple of very simple data structures during face to face interviews. I've also been known to ask maths questions in the past but given that those roles did require an understanding of at least high school level maths, that was fair game.
My main reason for asking these questions is twofold:
Algorithms and datastructures are abstract concepts. By asking a candidate to describe them and them implement them in a programming language, you get an idea of both their ability to think through problems then translate/apply them to a problem at hand. This is one of the most important skills for a developer because you are constantly translating between the problem domain and the implementation domain. A developer who struggles to do this might still be OK cranking out code, but will often require someone else to provide the translation for them or create a suboptimal solution. Depending on the size and structure of the team involved, this can be huge burden on the rest of the team.
Algorithms and datastructures are fundamental building blocks of our craft. Languages and technologies change over time, but these basics don't. A good, experienced developer should be able to find his or her feet in a programming language reasonably quickly and will have to multiple times over the course of their career. However what stays the same are the concepts (quicksort doesn't change if you change languages) so even though you might not be an expert in language X, you will still be able to create a solution for a given problem if you can apply existing algorithms. The latter change a lot less often than the former.
As to your question regarding experience - how do you measure and test for experience? There are an awful lot of candidates out there whose "eight years experience" translate into "eight repeats of one year's experience". One way to find out about these candidates (because the recruiter/agent who sent them to you often can't or doesn't) is asking questions that require a deeper, more abstract understanding of certain problems and solutions. Which brings us back to the above...
Okay, this issue really bugs me out too.
Why indeed do we have algorithm questions at all?
Let's consider a real world complex example, our favorite SO for example. We're dealing with a project of considerable size and complexity, how much of it is algorithms?
Again most of the work here is putting it in the db in an accessible fashion (good db design), make it presentable (good interface design), and make it fast (efficient querying system).
Where are the algorithms? I think it is a better idea to ask the interviewee questions about good programming practices, efficiency improvement tools, logic and problem solving questions, and not about algorithms.
Edit: Also remember that algorithms are academic. They teach them in all the universities, books. Academic success (remembering algorithms) does not imply good programming skills [now someone can ask me if I flunked programming school :)]
Algorithms are logical patterns to solve real world problems. If you are good in memorizing algorithms you can successfully reduce your given problem to a certain algorithm, otherwise, you'll have to construct a solution from scratch.
There are already some really good answers, but hopefully I can add something. In my mind, you have to look at this question in the broader context of
"What constitutes an effective interview?'
or even more simply put
"How do you know the person you're interviewing will 'work out'?"
As a dev manager I have very limited options. In an ideal world and given infinite time and resources, you would bring in every potential new hire, have him work for a month or so, and make an assessment at the end of this period as to whether he was worth keeping. That's not feasible, however, for a number of reasons:
A slightly more practical version of this is to provide internships to college students or recent grads. This way you can see how the person works out, build a reslationship, and if he's really outstanding extend an offer.
In most cases, however, it's infeasible to just bring someone in. So, then you're back at some type of interview. The questions one can ask within a limited time-frame are necessarily circumscribed and somewhat contrived. It's difficult to get a feel for someone's abilities in a very short window, so you have to decide how close you can come to the what you might get from the shadowing exercise described above while still limiting the amount of time and resources you invest in the prospective employee.
In my experience, the absolute best test it to come up with a simple programming exercise (something that most people should be able to solve completely in a 2-3 hours), give the candidate a laptop, access to his IDE of choice, Google, and any other resources he would have when actually doing his job. This is the closest you'll be able to come to assessing him under 'real world' conditions. Of course, the exercise will likely still be a bit contrived (though if possible it should be a reflection of similar work to what he'll really be doing). Give him incomplete information, maybe a few misqueues. Put him in a room, give him your phone number, and tell him he can call you at any time, and you'll answer any question he has.
At the end, he may or may not have answered the question completely. But look at what he's done. Is the work conceptually sound? Does his code look reasonable? Did he ask intelligent questions? Did he notice the traps you set for him and ask for clarification?
Usually, that's the last step in the interview process. Back to the original question, I also like to get a more face-to-face feel for the candidates' problem solving skills and knowledge.
As other's have mentioned, 8 out of 10 people who submit a resume can't even solve the simplest of questions in their language of choice. I never cease to be amazed by this. I can't even count the number of people I've interviewed who had resumes listing '8 years of J2EE' experience and yet could barely program 'Hello World' in Java. As a result, I've come to largely ignore resumes. Coversely, some people who have really crappy resumes, do phenomenally in an interview. Unless the resume is just atrocious almost every prospective candidate gets a phone screen. In lieu of anything better, I'll ask a few basic data structure and algorithmic questions.
Again, as other people have mentioned, a question about an algorithm shouldn't be asked as a test to see if the person can memorize things. I'd never ask 'Tell me the QuickSort algorithm?' then if the person couldn't remember, disqualify him. No, these questions are asked to see a person's thought process, get a sense that they understand the basics of computer science (for example, if a person can't give me the basics of linked lists, arrays, and hash tables he's really going to have an uphill battle). The thing is as contrived as such questions are, they are the best thing we've got. If I ignore resumes, I need some way to cull the really atrocious people so I don't waste 3-4 hours on an onsite. And when a candidate makes it to the onsite, I need a way to cull the people who shouldn't have made it past the screen. It's an escalating scale. Again, as contrived as most questions are, questions that devlve into the fundamentals of computer science, ones that illustrative a person's problem solving skills, and that show me the person can think are the best tool I have after seeing how the person performs in the real world.
The worst interview questions to me are ones tha require rote recital of facts. I've always had an uphill battle with HR departments and my bosses arguing that I don't care if a person knows Hibernate or Spring or whatever technologies we happen to use. I care about someone who can think critically, has a firm command of the basics (including efficiency trade-offs of algorithms & data structures) and who seems to have a geniuine interest in learning new things.
That will trump pre-existing knowledge every time.
I would like to just add to the conversation by giving you a hint. Often the question asked will not be entirely clear, and hence a lot harder or impossible for you to solve. I found what works exceptionally well when you are asked a algorithm or math question is that you repeat the question to the interviewer, and at each part in the question that doesn't seem clear to you stop and verify with the interviewer what they mean by that. Not only does it show that you aren't afraid to ask intelligent questions, it also shows that you are trying your best to understand the problem entirely before you even attempt it. Employers love this.
Well, I can think of a few reasons:
Algorithms can make or break a program -- an exponential algorithm where a polynomial exists will create a performance problem no hardware can solve.
Some things are just not possible with reasonable performance. Knowing there are limits to what is possible, and being capable of recognizing the possibility -- and researching to confirm it -- that the problem is not solvable may avoid doomed projects.
Algorithm is logic. Having a logical mind is very important when coding -- if for no other reason, because people maintaining it are more likely to be able to understand it.
Algorithms are the base of computer science. Programming languages and development methodologies come and go -- today's professionals must be able to learn them on the job anyway. The things we know about algorithms will remain true, because they are facts, not theories.
Also, because of that, evaluating algorithm knowledge is not as subjective.
Domain knowledge can be invaluable, but that alone can't help a bad programmer.
We ask simple algorithm questions (reverse a linked list type of stuff) during our interviews for a number of reasons.
But mostly we do it because so many people are so God-awful at them. And to be frank, if you're going to be turned loose as an "experienced developer" in our code base and you can't safely reverse a linked list, we don't want you, and you won't be happy here anyway.
I strongly believes that programming language or framework can be learn very easily. But its very hard to develop problem solving ability(algorithm/puzzles etc.). So algorithm and maths are very much necessary part of any interview process. Every technical interview should contain algorithm and maths related problem as well as some puzzles.
The thing people ask more about algorithm because they are core from performance point of view.
Memory is expensive and we want to utilize it to maximum to get benefits and so we need to know about data structures : Structures which contains data and Algorithms how to used that data in optimal manner.
So it boils down to sorting the data, searching the data and inserting or deleting data from data structure. If one is not confident with this technology than he might want to think of other profession compared to CS.
So to judge candidates knowledge of core CS technologies Interviewer would always put more stress on data structures and algorithm from Interview Point of View.
Thanks.