Why interviewers ask algorithm questions even if job position doesn't require such knowledge?

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?

Answer 1

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

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.