Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Top algorithms in interview questions

geeksforgeeks.org

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Top algorithms in interview questions

#51

Post by alkonaut »

anomk5050 wrote: post #5
andrewvijay wrote: post #3

I genuinely want to know where people use these algorithms in their code. I'm a non CS dev to begin with so may be I don't know where to use them since I didn't get formal CS education. This way of interviewing is not what I prefer. I have been told I write better code than my CS grad peers but I have no clue about these algorithms and data structures. What do you guys think about this form of interview?

Do you really find you can ignore data structures and algorithms in your work (and if so, what sort of work do you do)?

It's enough to know the existence and properties (benefits, drawbacks, running time, memory use) and to be able to recognize when to use a specific algorithm or data structure. I have no use for a candidate that can implement every sort algorithm on a whiteboard. What I want is a candidate that can identify problems and identify the required algorithms.

So I want someone who says "this is analogous a dynamic convex hull problem" or "this can be solved greedily by branch and bound" etc.

That knowledge has to be learned it can't be Googled. Mergesort or an A* implementation is googleable once you know you need them (which was the important bit).

Re: Top algorithms in interview questions

#52

Post by alkonaut »

axiom92 wrote: post #24

In my opinion, it's a settled question now. If you are looking for a job, you better cram these lists or you are dead meat. The screening tests and the interviews basically boil down to these set of questions for most of the companies.

That might be true in Silicon Valley, I would never ever ask for an implementation of a known algorithm from a candidate, it's beyond stupid.

Knowing the running time of merge sort or A* is interesting. Knowing its implementation by heart is not.

Re: Top algorithms in interview questions

#53

Post by jupiter90000 »

ubernostrum wrote: post #50
jupiter90000 wrote: post #14

Earlier quoted context omitted.

In terms of simply getting hired/passed the interview, yes, either a recent grad or someone having studied the algorithms prior to the interviews will probably do best. I won't argue it's annoying to study for an interview. I still think someone who understands these and has studied them will be in better shape to understand when/how to use such things in situations on the job (even if they can't be reproduced in a p…

Except you know this isn't how algorithm/data structure questions are used in interviews. What you're talking about is primarily a function of experience: seeing various situations over time and learning what works well and what doesn't. But these questions are used, quiz-style, as a barrier to even entry-level positions. So even if I grant you the possibility of some effective criterion being developed from algorith…

You're right, and I totally agree with you on what you're saying about the interview/job obtaining process, and that replacing the way this is done with something far more effective for interviews would be ideal. I also agree that actual experience using these types of things seems much more important than seeing if someone has drilled on quiz questions.

The question then for me is, how does one assess if someone can use these things in practice to make a difference for the business? I don't have a good answer for that right now. If anyone here knows a nice approach to use to assess this type of skill, I'd like to know more (to stop perpetuating the usual 'algorithms gauntlet' approach).

Re: Top algorithms in interview questions

#54

Post by w1ntermute »

hal9000xp wrote: post #34

This is nice list and ability to implement these algorithms certainly won't hurt. But I have to say that knowing these algorithms alone won't help you much during job interview with smart employer like Google. The reason is simple but often overlooked by many people: the most important thing is not these algorithms themselves but ability to recognize them in problems. You may learn pretty quickly how these algorithms…

> You may learn pretty quickly how these algorithms work and implemented but it may take years of practice to earn ability to recognize them.

This is false. Just as you can learn pretty quickly how the algorithms work, you can also pretty quickly learn how to recognize which one to use for a given problem - it's basic pattern recognition. The problem for most people isn't that they can't develop this pattern recognition skill, it's that they don't realize they need to (and instead focus on just learning how the algorithms work).

A lot of the time when people say that you can't just "memorize" your way to passing a given test, they're just referring to situations where developing pattern recognition skills instead (or as well) will be more than sufficient. You can get pretty far in life by combining rapid memorization skills with the ability to rapidly develop pattern recognition for a new training set. The more types of inputs/outputs you can map between (muscular, visual, aural, etc.), the better.

Re: Top algorithms in interview questions

#55

Post by Bahamut »

amorphid wrote: post #41
leonroy wrote: post #7

Earlier quoted context omitted.

I've been a team lead and head geek for a small software company for a good number of years. I'd say that these questions matter a lot more than you'd think. Using the wrong data structure or a data structure in the wrong scenario can make the difference between an application which can serve 1000 users per node or 100. That impacts the number of servers we recommend deploying in our cluster and in turn the hardware…

Do you really use Big-O at work? I don't know if I've ever heard it brought up outside of an interview. In my experience, when something is slow, people notice and start complaining about it. "Why does it take 30 seconds to complete this seemingly simple request? Oh, it's making a database call for every element in the list, vs. efficiently sending a single request. I fixed it, and pull request submitted." "What is t…

I have encountered a few situations where time complexity matters during the normal course of work. The most notable one for me was where I did two DB queries to fetch a list of elements in one and another of the same length and related to the first one - to create a list of objects from the first list, I iterated on it, and it had to do another iteration inside to find the element in the second list. It turned out this approach showed some performance problems on larger datasets, so another coworker took a look at optimizing it - he ended up grouping the second list by id in one iteration so that it eliminated the need to iterate again inside the loop, transforming it from time complexity O(n^2) to O(n).

These situations don't come up too often, but when they do, it becomes important to at least be able to solve them in some fashion in a non-high pressure situation.

Re: Top algorithms in interview questions

#56

Post by mavelikara »

andrewvijay wrote: post #3

I genuinely want to know where people use these algorithms in their code. I'm a non CS dev to begin with so may be I don't know where to use them since I didn't get formal CS education. This way of interviewing is not what I prefer. I have been told I write better code than my CS grad peers but I have no clue about these algorithms and data structures. What do you guys think about this form of interview?

> I have been told I write better code than my CS grad peers but I have no clue about these algorithms and data structures.

For a programer in the industry, the ability to write simple "legible" code is very important. An ideal interview process should spend some time evaluating those skills of a candidate - but this is very very hard to measure.

But good familiarity with the basics of CS is also important to be able to perform many of these jobs. Here is a good blog post about this form of interview and the rationale behind it: http://www.goodmath.org/blog/2015/11/19/technical-interviews...

Re: Top algorithms in interview questions

#57

Post by soneca »

hal9000xp wrote: post #34

This is nice list and ability to implement these algorithms certainly won't hurt. But I have to say that knowing these algorithms alone won't help you much during job interview with smart employer like Google. The reason is simple but often overlooked by many people: the most important thing is not these algorithms themselves but ability to recognize them in problems. You may learn pretty quickly how these algorithms…

Is there any resource out there that links these algorithms to real world solutions?

Re: Top algorithms in interview questions

#59

Post by 1_2__3 »

cle wrote: post #37
hal9000xp wrote: post #34

This is nice list and ability to implement these algorithms certainly won't hurt. But I have to say that knowing these algorithms alone won't help you much during job interview with smart employer like Google. The reason is simple but often overlooked by many people: the most important thing is not these algorithms themselves but ability to recognize them in problems. You may learn pretty quickly how these algorithms…

And then when you get the job, you will likely never use this skill again. 50% of your time will be spent on plumbing and wiring, 40% on meetings and politics and "agile processes", 9% on learning new ways to plumb and wire, and maybe 1% of your time will utilize these sorts of skills that can otherwise be identified from afar and solved by looking up in a book. Once you get your foot in the door, this sort of trivia…

Google doesn't use agile. Specifically to avoid the kind of nonsense you cite.

Re: Top algorithms in interview questions

#60

Post by ceronman »

hal9000xp wrote: post #34

This is nice list and ability to implement these algorithms certainly won't hurt. But I have to say that knowing these algorithms alone won't help you much during job interview with smart employer like Google. The reason is simple but often overlooked by many people: the most important thing is not these algorithms themselves but ability to recognize them in problems. You may learn pretty quickly how these algorithms…

> This is why I'm trying hard to improve my problem solving skills by solving competitive programming problems almost everyday.

Here is another simple tip to improve your ability to recognize algorithms: Just look at the software you use every day and ask yourself how does it work.

When you make a click on your web browser, how does the browser know what element you clicked?

When you tell you StarCraft unit to move to a given point, how does the game engine know what path it should follow.

Are you using a Redis cache with an LRU eviction policy, how does that work? Why it's so fast? (hint: it's not only because it's written in C)

You know that adding indexes to your database columns makes them faster. Why? How does that work? What are the tradeoffs of the the different kinds of indexes.

When you type `ls -R` in the console, what's happening?

How is it that Google can give us the results of searching on trillions of webpages in just a fraction of a second?

It's sad to see a general sentiment here on HN against algorithms and data structures. In reality, most of the tools we use everyday use all those algorithms and data structures.

If you feel that you don't need to know about algorithms and data structures, you probably do very mechanic and simple things like CRUD software. The moment you do something slightly more difficult or at a bigger scale, you are going to need this knowledge. You simply can't be a good developer without understanding these concepts (I'm not saying that it's the only thing you need).

Post reply on HN