Why are so many algorithm problems asked in interviews? [closed]

Tag: algorithm Author: wfd369 Date: 2009-07-31

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?

Best Answer

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).


+1. Good answer
Agreed, it's not always about what you know. Sometimes, they just want to see how you approach a problem.
Great concise answer.
Counter-point: algorithms are absolutely important, but are they any more important than design? Knowing how to analyse a problem and map to an efficient solution seems almost more important to me.
@annakata: I agree that it is important to know how to design. Even so, mapping to an efficient solution could (arguably) be called using or creating an algorithm :).

Other Answer1

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:

  1. Your thought process.
  2. How you respond under pressure.
  3. How you resolve the situation (i.e. will you bullshit me).

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!


I agree with everything you said, but want to say that interview pressure is different than on the job pressure.
@PTBNL: Great point, thank you. I agree completely there's only so much you can do in an interview setting. The goal is to minimize the bad hires, I don't think you can eliminate them. :)
+1 for the BS part.
When I face a problem, I do not solve it on a whiteboard, watched by my colleagues/bosses. I take some time to think about it, alone, in quiet, consult with experts. I look it up online, to separate between the already solved details to those not yet. I don't get all of these in an interview. What I get is more like: if you've really graduated from high school and college, let's give you some questions you used to solve back then - now if you are not fluent, can't we doubt your diplomas? Why can't you calculate 34*7 in 12 seconds? Why can't you code bubble sort in 5 minutes?

Other Answer2

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.


-1 for finding something wrong with searching for relevant code on Google and copying-pasting it.
+1 for seeing the difference between good developer and google-kid.
googling is a skill that I believe is important for developers
You find me a developer who knows everything and doesn't have to google once and a while and I'll find you the tooth fairy.
@Cyril Gupta: Copy-pasting any copyright-protected code (and that's alomost all code - GPL and other licenses are also a form of copyright protection) can cause severe legal trouble.

Other Answer3

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:

  • Bringing in a new person is disruptive to existing staff
  • No one will leave his current jobs for a new one if it's not a guaranteed position
  • Companies would not want to foot the bill for ramping someone up, only to subsequently let him go
  • If you did this for everyone, you'd end up wasting a tremendous amount of time on people who were completely unsuitable

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 Java EE' 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.

Other Answer4

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...


I like the statement "'eight years of experience' translate into 'eight repeats of one years experience.." on the spot.

Other Answer5

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.

Other Answer6

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.


In what way does remembering about binary trees tell you if a person is good at SQL or C# or Java for that matter?
It doesn't have to be a commonly-used algorithm. If you are a programmer you better have a good memory; half the job is remembering things.
I don't buy that half the job is remembering things. Maybe it was 15 years ago. Half is problem solving and half is Googling.
Maybe modern IDE's make it not so important to remember things. But auto-completion and IDE's are no replacement for having a decent memory. If you hit 15 up arrows to recall the last "ls" you did, you're wasting time. If you can't remember basic things about your craft, shame on you. Interviews are a place where an IDE-centric knowledge doesn't help you much. Also, if you can't remember your past fubars, and not repeat them. you're screwed. This job isn't for everybody. Some people are better emptying trash bins.
If you can't tell me the strengths and weaknesses of binary trees, hashes, arrays and other common data structures you will end up writing horribly inefficient code in any language.

Other Answer7

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.


+1 I agree with basic grasp, knowing about them not rote-memorization.

Other Answer8

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.

Other Answer9

Okay, this issue really bugs me out too.

Why indeed do we have algorithm questions at all?

  • Most algorithms are well-documented and high level languages have short-cut functions / libraries that do the job so well.
  • Most of the programming is not about algorithm writing, only a very small part of the job is doing math, algorithms or complicated loops.
  • Most of the programming in real world is how to get it working well with the db, make it fast and put it in front of the user in a presentable UI.

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 :)]


The question is about why employers ask these questions. If the job requires algorithmic analysis (arguably the most important part of your application), then algorithm questions are appropriate. Maybe if you learned a few algorithms, you would be more comfortable with them.
What tells you I haven't learnt algorithms? Is there some secret fortune-telling art you practice? Something related to black magic?
It's your experience that all the things you mention are important, and maybe that's to your liking. However, there are lots of domains where this is simply not the case. For example, in lots of scientific programming, there are no databases in the classic sense, the UI is minimal or non-existent (program run from the command line or a batch job), and choosing the wrong algorithm can lead to run times several orders of magnitude slower than the "right" algorithm.

Other Answer10

We ask simple algorithm questions (reverse a linked list type of stuff) during our interviews for a number of reasons.

  • To see how you approach problems
  • To get an idea of how careful you are
  • To see what you do when you get stuck
  • To give us an opportunity to ask questions that dig deeper into your understanding of the issues involved.

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.

Other Answer11

To begin with, this is a very good question. It is very useful and worthwhile to examine and re-examine some of the basic assumptions we make in the formation of our opinions. I have read, and heard, a lot of opinions on the subject of this question. What I can conclude is that these are just that - opinions. What I have not found in this discussion is any hard data to support these opinions.

Real data can be subjected to statistical analysis, which can assign a numerical value to the likelihood that a particular question or problem is VALID and RELIABLE. Validity and reliability assessment has been sorely lacking in any discussion of the relative merit of algorithm questions, or any interview questions, for that matter, as predictors of the probability of job success. Job success is, after all, what the interview game is supposed to somehow predict. My opinion is that people get hired largely on how well they are "liked," or how they are "perceived" as like-minded to the interviewer or the team.

Admittedly, it would be a large-scale project to conduct the type of research I refer to - tracking the job performance of individuals over a significant period of time and comparing their answers to their interview questions, and then subjecting this data to scrutiny and analysis. Question is, "Do we really want to do that?" I don't know the answer to that question. Furthermore, we may never be truly able to predict the likelihood of innovative thinking or creativity within a particular context, or set of circumstances.

What I do know is that the software community, in general, seems not to have bothered to train that keen, analytical, mind on this problem domain. Instead, there seems to be more of a general acceptance of preconceived opinions on the matter.

Other Answer12

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.

Other Answer13

Because of this, this and this.

Other Answer14

They wrongly feel that people who memorize are better than those who don't.


I don't think its a wrong feeling.
Believe me or not excellent memory is one of the key developer skills. Without it you will be trying to fix that bug over and over just to find out again and again that it's actually a feature or some core limitation.
I consider myself mediocre at memorization, but I think I'm pretty good at data structures and algorithms. I think very few people are capable of spouting off how to balance a binary tree from memory, but if you can't figure out in your head or on paper how to do it within a minute or two, you aren't a very good programmer.
You're wrong about that memory thing. I've got a wrong-right-brain and a right-left-brain, meaning everything in my head is so muddled together that I can't sometimes remember the name of the person standing before me. I like to think it's because i am concentrating so much on my job. My staff likes to think I have a crappy memory. But I get things done, crappy memory or not. Hmm.. I don't remember a single algorithm, but I remember where to find 'em. Google! :) Sometimes strong intuition beats the meat out of strong memory.
I don't repeat my mistakes, and I'm terrible at rote memorization.

Other Answer15

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.


Algorithms are the 'real' test for smart of a person? Well, why do you think so? Do you mean to say that someone who remembers the algorithms well is certified to be smart?
@Cyril: For any reasonable algorithm question being asked in an interview, no one can answer it merely by remembering an algorithm. The point of asking algorithm questions is to see whether the interviewee can think algorithmically and devise algorithms for the problem at hand (as this answer says), not a memory test.

Other Answer16

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.


In what way does writing algorithms portray all that ? (teamwork, communications?)
it's not writing algorithms in particular that does it; it's just that the task gives the interviewer a concrete opportunity to interact with the interviewee in a work-like setting.
I think other programming stuff can also fit that description. What say?

Other Answer17

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.


do you mean 'memorizing' or knowing about it?
yes i mean memorizing. U should remember all ins and outs of an algorithms in order to modify and use it in the given scenario or ATLEAST u must remember major intricacies in an algorithm. Using and modifying algorithms is a memory+analytical skill matter both weigh 50% otherwise u need to use only ur analytical ability and spend much more time in devising a new algorithm and we surely do the latter part most often which infact should be minimized for the former one.

Other Answer18

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.


What do you think a software development job is about? You get some more or less fuzzy specs and figure out how to implement them in code. That involves design work, and at the very least selecting good algorithms. While most people don't do major algorithmic development frequently, it can be a good indicator of how you can reduce a user requirement to something that can be coded.
@David Thornley, While I accept that selecting good algorithms is a part of the job, it's not the job, it's not even 10% of the job if you are not in scientific software development. I don't think user's requirements can ever be reduced to algorithms. Again algorithms can be a part of the requirement, but not a major chunk of it.
@Cyril: If you think algorithm is not required in your day to day job then you should switch your company. You are missing the real fun.

Other Answer19

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.

Other Answer20

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.

Other Answer21

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.