Iyfjky

Question

I have seen lot of interviewers asking advance algorithm and data structure questions while job doesn't require any knowledge of them. It is true for a lot of times so why interviewers ask such questions?

What sort of programming jobs don't require knowledge of algorithms and data structures? Without those basics all you can do is thoughtlessly copy data around. You can't even design a good data model. — Jun 14 '14 at 16:20
@kevincline most web development in standard website shops for example. — Jun 14 '14 at 21:32
Associative arrays aren't "knowing data structures", your wife didn't have to spend a minute thinking about the backing hash table or red black tree. That's the beauty of it :) — Jun 14 '14 at 22:01
For many there's a simple answer: they do it because Google does it. — Jun 15 '14 at 3:18

score 30 · Answer 1 · 2014-06-15 00:45:03Z

It's mostly a test of your understanding of the fundamentals of Computer Science (which should be a prerequisite for any programmer).

Software development has evolved to the point where the fundamentals of building good product have been abstracted away from the average developer. "High-level" languages have bred a new crop of copy-n-paste programmers that don't know why it's working, only that it does. While it's not easy, almost anyone can learn an API nowadays.

Asking about algorithms, data structures and design patterns helps a lot of companies weed out the programmers that can raid Stackoverflow for good answers, without understanding the operating principles behind them. You'll also find that many companies that ask about such fundamentals, build in a variety of platforms. Rather than ask for things peculiar to a specific language/platform, they'll open the interview with more general computer science questions.

Knowing the fundamentals of CS helps you make better higher level decisions when programming. If I were an employer, I'd want to recruit a programmer that knows the difference between a Stack and a Queue; a ArrayList from a LinkedHashSet; Bubble sort from Quick Sort; There are performance/design implications for these decisions. It's important to understand them, rather than just ripping something off the net (by an author that may have made the wrong decision without your understanding/knowledge). Knowing the solution is not understanding the solution

@VarunAgw - OS's and Compilers are ultimately built on what? Algorithms. Data Structures. Logic. Fundamentals. That's what everything programming ultimately boils down to. Rather than split hairs between C# and Java, I'd rather ask you questions based on something they both have in common — Jun 15 '14 at 0:16
@Dukeling - If I were an employer, I'd want to recruit a programmer that knows the difference between a Stack and a Queue; a ArrayList from a LinkedHashSet; Bubble sort from Quick Sort; Threads vs Processes. There are performance/design implications for these decisions. Better understand than just rip something off the net that may have made the wrong decision without your understanding/knowledge. Knowing the solution is not understanding the solution. I'm not saying that you must understand the solution 100% of the time, but as an employer, I'd be happier to shell out the bucks if you did. — Jun 15 '14 at 0:20
@Dukeling - I'm quite sure I gave multiple reasons, along the lines of "..weed out the programmers that can raid Stackoverflow for good answers, without understanding the operating principles behind them" etc — Jun 15 '14 at 0:25
helps a lot of companies weed out the programmers Still I think there are better ways. They can ask to code something directly related to work. It can also help in weeding out programmers. Also good algorithm knowledge doesn't means you will do the job well because you will be doing something different than writing good algorithms in the job. — user10125, Jun 15 '14 at 9:17
@VarunAgw, when you are a manager, you can ask whatever questions you want to try to figure out who is and is not capable of doing the job you have. The people you are interviewing have a reason for asking this and it doesn't matter what that reason is ultimately since you will have to have an acceptable answer to move through the process. But since these are questions that test your fundmental understanding of computer science, I don't see them disappearing any time soon. Maybe the weed out some potentially good people but they also weed out most of the incompetent. — Jun 16 '14 at 17:23

score 15 · Answer 2 · 2014-06-15 01:11:32Z

Can you write working code?

This is of course assuming you're actually asked to write actual code in the interview (white-board style).

This isn't so much about not even having a single typo in your code, but more about just knowing what basic constructs like for-loops look like, knowing how to put the bits together and proving that you've actually written a bit of code in a language to know most of the most common methods / classes (apparently interviewers have a bit of a problem with candidates that can't even pass the fizz buzz test).

Can you think through a problem?

This definitely doesn't just apply to algorithms.

You need to be able to understand the problem, analyse the requirements, pick appropriate data structures and algorithms, write the code / walk through the approach, and analyse it - that's required for many / most (non-bug-fix) programming tasks.

Can you communicate well (about programming)?

Do you understand the problem as described?

Do you ask for clarification when required?

Can you explain the high-level approach before you start writing the code?

Are you able to explain your code after the fact?

The ability to communicate well is important in your day-to-day job as a programmer.

Your boss shouldn't be concerned that you're not going to be able to understand the explanation of a problem, not ask for clarification when things are unclear (and just make some radical assumptions), have no ability to walk through how you're planning to solve any given problem and/or have no ability to explain code you've written to anyone else.

Do you have a decent knowledge of data structures and algorithms?

While you may be asked about an advanced data structure or algorithm that you'll never use, knowledge of this data structure may be a fairly accurate indicator that you know pretty much all the basic ones quite well.

I'm also fairly sure you can stick to simple data structures or algorithms (linked-list, array, binary search tree, binary search, etc.) in many cases and still do well in this specific aspect - while an advanced data structure or algorithm may be better suited to solve the problem at hand, you could often fairly efficiently solve the problem with a combination of basic ones - there's still picking between them based on appropriateness and combining them appropriately.

And you definitely need a decent knowledge of data structures and algorithms - you can't be good at what you do if you don't know when to use which tools in your toolbox.

Can you analyse time and space complexity and weigh choices up against each other with them in mind, making the most appropriate choice for the situation?

Any data structure or algorithm question should involve complexity, and it will be very significant to your day-to-day job - no-one wants you to, for example, write code that endlessly does linear search through a large unchanging array because you don't know what's going on on the low level.

Sascha 6,18321231 · Answer 3 · 2018-01-14 17:19:20Z

I do technical interviews. I very often do not ask the people at all about the stuff they will be doing, but about loosely related stuff they have been doing. The rationale behind this is simple:

I can see how deep the person likes to go into technical details.

I can compare the person to their peers

I can test his analytic strength better on something where he actually knows something about that some unknown thing.

I see also the self-reflection and team skills. E.g. when a CS person talks about their master thesis and explicitly states that they left a certain part to do for a team mate - or how they took ownership of something

All of this only can work if I present them with something which I actually can expect them to know. If they are good in these things, then usuually they are also good in other topics.

you are a very sensible technical interviewer and very wise. I do not dismiss the kolossus provides as it makes a lot of sense as well. There is one small detail that kolossus misses. Writing an algorithm solves a very specific problem, CRUD functionality solves a very specific problem. How are they connected? In other words, if I learn the former, will that lead to an intuitive understanding of the latter? — Jan 19 at 4:05

James Adam 1571 · Answer 4 · 2014-06-14 16:01:15Z

There are probably two main answers:

Firstly, because it's an opportunity to see how a candidate approaches a problem. Even if you don't know the specific solution to the problem immediately, how you explain how you would approach the problem may be revealing about your ability to think clearly, to understand the problem, and demonstrate other qualities like patience.

The second answer is that they are just doing it because it is a way of demonstrating how much a candidate knows, and that they believe other companies do the same, and so the question acts as a fairly arbitrary hurdle that they want candidates to jump over.

Quite often it is a way of recruiting people just like me and also some times a way of using ones credentials as a form of dominance behaviour. — Jun 15 '14 at 12:31
@James, the algorithm tests one company had me take thus far, was just a here go take this test on Codility and go away forever. No one ever got back in touch with me to ask me why I wrote the algorithms the way I did. They just saw that not all my solutions were 100% correct, so they said, well we want the guy that gets 100% on it and that's that. — Jan 19 at 4:17
@Daniel I'm sorry you had that experience. It sounds like you're better off not working for that company, if that's how they treat people! — Jan 23 at 17:50
@JamesAdam, to be clear they did not actually say that to me. The point is that a lot of companies are looking for that easy way around having to actually go through a 100 applicants. So they have found that they will grab Codility or Hackerrank and just give everyone a boilerplate algorithm tests that they themselves have no clue about and look for the candidate who gets 100%. But I agree I and others are better off not working for such a company. — Jan 23 at 20:18

score -6 · Answer 5 · 2018-01-16 03:24:47Z

Author asked: "why they check algorithms , even if the work does not require them"

In most of cases, because:

1) it is the easiest way for an immature programmer, fresh from a uni or just good "googler", to argument with a candidate, who knows more than an interviewer.

2) because of unawareness of the complexity of modern high level languages and their APIs.

When they ask algorithms - they think they "check how a candidate thinks".

After 20 years of programming, you naturally forget most of that algorithms material from an university, because it is rarely used in the low-level way.

(Exception: C/Assembly programmers in some layers, language core programmers, data mining)

You more frequently concentrated on APIs and high level data structures.
Plus concurrency language features, design patterns, dark corners of object oriented and functional styles ARE far more important in 80% of programmers jobs, so you naturally keep them in memory. 80% of programmers start recall/refresh algorithms knowledge only for interviews. This is the reality.

So, you asked about "what your interviewer knows or able to google", not about "what the job requires", job real requirement might be a very dark secret for your interviewer!!!

Modern API, concurrency issues, and high level data structures are ten/hundreds times more complex than school algorithms and the requirement to know all that constantly is insane.

So, you actually asked "the safer part", things that your interviewer able to scratch form the web-pages,

non-algorithmic part may be 1000 time more complex, but it is why you rarely asked that part - interviewer is afraid - here experience required, not only "googling".

In my view, industry is paralyzed by those interviewers, most of them are team-leads that got into their position after too short programmer career.

Those questions are a trademark of ignorance and insufficient experience.

Instead of asking 10 questions in each of 10 areas of programming that this company/position involved, for example, design patterns, concurrency, protocols, web, concurrency ,client, server, UML, frameworks, etc... ( 100 questions is a minimum to have a broad view) to discover all weak and strong sides of an candidate, they usually start their interview that way:

"I usually ask only two questions!". (It is obligatory followed by very narcissistic look - note that - like this guy discovered a secret of a good interview and never bothers with many other questions!) One question will be a puzzle, second - algorithm. It is enough! This is what really important for a job - puzzle cracking and a memory from your school days!!!

That just means: "I think I'm smart, because I googled that a week ago, read solution and understood it, now is your turn, you have 10 minutes, but no google".

You can tell "do not exaggerate, people know what they ask".
Really? You really think if I will ask another "puzzle" back I will get the clear answer?

In my view, interviewer must make an effort to ask what he able to do him/herself, not less, but not more. Otherwise - it is a circus, the sole purpose of which is to build up some other ego on an account of the candidate.

That leads to an advance of a fresh, puzzle loving, but in the practice weak guy, in opposite, the working horse that knows 1000 times more, but less concentrated on a puzzling aspect will usually fail - a good memory rarely keeps the impression junk, that you can google, good "operative" memory keeps day-to-day issues.(Except , as I said, certain fields,where algorithms -ARE day-to-day business, not about them the question asked here!)

I would demand algorithms only in fields where they are requirement for a job, not for each programmer job.

BTW, such "two questions" basis is a Klondike for outsourcing companies.

They usually send a "probe" guy to discover those questions, and then a "real candidate" , who will finally answer them (after good googling).

I know that for sure - that way those funny questions usually cracked and the actual job also gets done well. You can in 99% of cases have only one: good "algorithmist" OR good "languagist", not both.

That's one of the reasons why we have those outsourcing companies growing and live exceptionally well, although they give 0 value both for their workers and for companies they employed by.

Really cool to see how they delete that without any apparent reason, except recognizing themselves in the post. — Jan 15 at 10:48
It would help if this read more like a helpful answer and less like a rant. — Jan 16 at 7:10
Sorry that I injured your sensitive consciousness. I will spend the rest of the day in a guilty mode. — Jan 16 at 7:45

score 30 · Answer 6 · 2014-06-15 00:45:03Z

It's mostly a test of your understanding of the fundamentals of Computer Science (which should be a prerequisite for any programmer).

Software development has evolved to the point where the fundamentals of building good product have been abstracted away from the average developer. "High-level" languages have bred a new crop of copy-n-paste programmers that don't know why it's working, only that it does. While it's not easy, almost anyone can learn an API nowadays.

Asking about algorithms, data structures and design patterns helps a lot of companies weed out the programmers that can raid Stackoverflow for good answers, without understanding the operating principles behind them. You'll also find that many companies that ask about such fundamentals, build in a variety of platforms. Rather than ask for things peculiar to a specific language/platform, they'll open the interview with more general computer science questions.

Knowing the fundamentals of CS helps you make better higher level decisions when programming. If I were an employer, I'd want to recruit a programmer that knows the difference between a Stack and a Queue; a ArrayList from a LinkedHashSet; Bubble sort from Quick Sort; There are performance/design implications for these decisions. It's important to understand them, rather than just ripping something off the net (by an author that may have made the wrong decision without your understanding/knowledge). Knowing the solution is not understanding the solution

@VarunAgw - OS's and Compilers are ultimately built on what? Algorithms. Data Structures. Logic. Fundamentals. That's what everything programming ultimately boils down to. Rather than split hairs between C# and Java, I'd rather ask you questions based on something they both have in common — Jun 15 '14 at 0:16
@Dukeling - If I were an employer, I'd want to recruit a programmer that knows the difference between a Stack and a Queue; a ArrayList from a LinkedHashSet; Bubble sort from Quick Sort; Threads vs Processes. There are performance/design implications for these decisions. Better understand than just rip something off the net that may have made the wrong decision without your understanding/knowledge. Knowing the solution is not understanding the solution. I'm not saying that you must understand the solution 100% of the time, but as an employer, I'd be happier to shell out the bucks if you did. — Jun 15 '14 at 0:20
@Dukeling - I'm quite sure I gave multiple reasons, along the lines of "..weed out the programmers that can raid Stackoverflow for good answers, without understanding the operating principles behind them" etc — Jun 15 '14 at 0:25
helps a lot of companies weed out the programmers Still I think there are better ways. They can ask to code something directly related to work. It can also help in weeding out programmers. Also good algorithm knowledge doesn't means you will do the job well because you will be doing something different than writing good algorithms in the job. — user10125, Jun 15 '14 at 9:17
@VarunAgw, when you are a manager, you can ask whatever questions you want to try to figure out who is and is not capable of doing the job you have. The people you are interviewing have a reason for asking this and it doesn't matter what that reason is ultimately since you will have to have an acceptable answer to move through the process. But since these are questions that test your fundmental understanding of computer science, I don't see them disappearing any time soon. Maybe the weed out some potentially good people but they also weed out most of the incompetent. — Jun 16 '14 at 17:23

score 15 · Answer 7 · 2014-06-15 01:11:32Z

Can you write working code?

This is of course assuming you're actually asked to write actual code in the interview (white-board style).

This isn't so much about not even having a single typo in your code, but more about just knowing what basic constructs like for-loops look like, knowing how to put the bits together and proving that you've actually written a bit of code in a language to know most of the most common methods / classes (apparently interviewers have a bit of a problem with candidates that can't even pass the fizz buzz test).

Can you think through a problem?

This definitely doesn't just apply to algorithms.

You need to be able to understand the problem, analyse the requirements, pick appropriate data structures and algorithms, write the code / walk through the approach, and analyse it - that's required for many / most (non-bug-fix) programming tasks.

Can you communicate well (about programming)?

Do you understand the problem as described?

Do you ask for clarification when required?

Can you explain the high-level approach before you start writing the code?

Are you able to explain your code after the fact?

The ability to communicate well is important in your day-to-day job as a programmer.

Your boss shouldn't be concerned that you're not going to be able to understand the explanation of a problem, not ask for clarification when things are unclear (and just make some radical assumptions), have no ability to walk through how you're planning to solve any given problem and/or have no ability to explain code you've written to anyone else.

Do you have a decent knowledge of data structures and algorithms?

While you may be asked about an advanced data structure or algorithm that you'll never use, knowledge of this data structure may be a fairly accurate indicator that you know pretty much all the basic ones quite well.

I'm also fairly sure you can stick to simple data structures or algorithms (linked-list, array, binary search tree, binary search, etc.) in many cases and still do well in this specific aspect - while an advanced data structure or algorithm may be better suited to solve the problem at hand, you could often fairly efficiently solve the problem with a combination of basic ones - there's still picking between them based on appropriateness and combining them appropriately.

And you definitely need a decent knowledge of data structures and algorithms - you can't be good at what you do if you don't know when to use which tools in your toolbox.

Can you analyse time and space complexity and weigh choices up against each other with them in mind, making the most appropriate choice for the situation?

Any data structure or algorithm question should involve complexity, and it will be very significant to your day-to-day job - no-one wants you to, for example, write code that endlessly does linear search through a large unchanging array because you don't know what's going on on the low level.

Sascha 6,18321231 · Answer 8 · 2018-01-14 17:19:20Z

I do technical interviews. I very often do not ask the people at all about the stuff they will be doing, but about loosely related stuff they have been doing. The rationale behind this is simple:

I can see how deep the person likes to go into technical details.

I can compare the person to their peers

I can test his analytic strength better on something where he actually knows something about that some unknown thing.

I see also the self-reflection and team skills. E.g. when a CS person talks about their master thesis and explicitly states that they left a certain part to do for a team mate - or how they took ownership of something

All of this only can work if I present them with something which I actually can expect them to know. If they are good in these things, then usuually they are also good in other topics.

you are a very sensible technical interviewer and very wise. I do not dismiss the kolossus provides as it makes a lot of sense as well. There is one small detail that kolossus misses. Writing an algorithm solves a very specific problem, CRUD functionality solves a very specific problem. How are they connected? In other words, if I learn the former, will that lead to an intuitive understanding of the latter? — Jan 19 at 4:05

James Adam 1571 · Answer 9 · 2014-06-14 16:01:15Z

There are probably two main answers:

Firstly, because it's an opportunity to see how a candidate approaches a problem. Even if you don't know the specific solution to the problem immediately, how you explain how you would approach the problem may be revealing about your ability to think clearly, to understand the problem, and demonstrate other qualities like patience.

The second answer is that they are just doing it because it is a way of demonstrating how much a candidate knows, and that they believe other companies do the same, and so the question acts as a fairly arbitrary hurdle that they want candidates to jump over.

Quite often it is a way of recruiting people just like me and also some times a way of using ones credentials as a form of dominance behaviour. — Jun 15 '14 at 12:31
@James, the algorithm tests one company had me take thus far, was just a here go take this test on Codility and go away forever. No one ever got back in touch with me to ask me why I wrote the algorithms the way I did. They just saw that not all my solutions were 100% correct, so they said, well we want the guy that gets 100% on it and that's that. — Jan 19 at 4:17
@Daniel I'm sorry you had that experience. It sounds like you're better off not working for that company, if that's how they treat people! — Jan 23 at 17:50
@JamesAdam, to be clear they did not actually say that to me. The point is that a lot of companies are looking for that easy way around having to actually go through a 100 applicants. So they have found that they will grab Codility or Hackerrank and just give everyone a boilerplate algorithm tests that they themselves have no clue about and look for the candidate who gets 100%. But I agree I and others are better off not working for such a company. — Jan 23 at 20:18

score -6 · Answer 10 · 2018-01-16 03:24:47Z