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

41–50 of 70 posts

Re: Top algorithms in interview questions

#41

Post by amorphid »

leonroy wrote: post #7
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'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 this script taking so long? Oh, exec is being called on every command, so let's just pull that out and put it in a wrapper script."

"What performance tweak can we use to make this Rails app hellza faster, since we've maxed out low hanging fruit caching options? Rewriting this part in Elixir takes advantage of concurrency in a way that Ruby can't do all that well."

I guess real world discussions don't seem to incorporate Big O lingo.

Re: Top algorithms in interview questions

#42

Post by hal9000xp »

snovv_crash wrote: post #40
cle wrote: post #37

Earlier quoted context omitted.

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…

That, of course, depends where you work. My daily work is math intensive and performance critical. I constantly need to think about cache sizes, big-O scaling and that ever-important constant factor. I've seen commits failed by QA because they inadvertently added a shared_ptr copy in a tight loop, which affected performance of the entire pipeline by 20%. So yeah, I regularly have to think about dynamic programming, s…

Your job sounds exciting! Do you work in gamedev? In which company you are working?

Re: Top algorithms in interview questions

#43

Post by vickychijwani »

chadcmulligan wrote: post #20

Would a better way to interview be questions like: 1) I have an array of 1000 integers, which of these would be the best way to sort them a) quicksort b) bubblesort... 2) what sort of structure would you use to store a list of numbers and strings 1) dictionary/hash 2) two arrays ... and so on. These would give you the certainty that they know which is which, you could ask give reasons to see if they mention O() and s…

I like the fact that this tests understanding of certain trade-offs. It can be improved in 2 ways though:

1. It doesn't allow the candidate to map out the available options for themselves, which is an equally important skill in software dev. When I'm working, I often have to spend a good chunk of time exploring the space of solutions, and only then can I move on to assess the trade-offs involved.

2. Another important skill is being able to question assumptions. You could (for example) intentionally under-specify the problem and let the candidate ask follow-up questions to root out assumptions/constraints. Example problem: You have an array of integers, how would you decide on an algorithm to sort it? Expected clarifying questions: (a) is there any relation/pattern in the integers stored? If they're all from a small set (say, 1-1000) then a simple counting sort works best, (b) how large is the array? If it doesn't fit in memory, a disk-based merge sort could be the best option.

Re: Top algorithms in interview questions

#44

Post by invaliduser »

bryanrasmussen wrote: post #35
invaliduser wrote: post #31

This list is very funny, straight out of the 90s, because we are in 2017 and most developers just spend their working days basically writing forms and storing/fetching data over the network/in a database.

I don't know if most developers still do an awful lot of that. At least not for the jobs I do - I do some but it's probably less than 25% of what I do. And anyway if you have gotten the data you often need to do something with the data and sometimes that includes sorting it or other stuff.

Besides calling Array.sort()?

When was the last time a front-end developer, or an app developer, or any developer actually, needed to implement a sort algorithm?

I started programming in the 90s, so I did a lot of it, implemented sorts, btrees, tries, you name it. When was the last time I need to implement it? Honestly, it's been a very long time, around 10 years, and it was just a bloom filter in c++ because it's not very used and few libraries have it.

Could I provide an implementation in an interview situation? Nope. And not interested in using my poor memory for it. If I ever need to implement a specific algorithm, say in a new language in which nobody did it before, I just need to make a search on google, take a few minutes to study it (for a sort), or hours (for more complex structures like btrees or algorithms I never used before), and use my knowledge/experience.

Of course, I don't need to implement those algorithms, but I use them a lot, everywhere. That's where interview questions should focus, where and when to use them appropriately, because that's the business case.

Re: Top algorithms in interview questions

#45

Post by throwaway43 »

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…

I'm currently prepping for an interview at one of the Big 4. I can tell you that this site is quite useful.

They have tons of problems to help you with the recognition part as well. You don't have to be a genius to be able to do these problems. It just comes down to pattern matching.

That said I don't think this is the ideal way to interview people. However no one has as yet proposed a better alternative. I turned down an interview assignment recently because they wanted me to implement an app with :

- Syncing to a database

- UI Tests (with a mock API)

- Unit tests

- Functional reactive programming

- A really complex architectural design pattern

All this just to get a shot at the interview. I was too tired to do it at the time so I turned it down. So I would criticise programming interviews but I don't have a better alternative. Sane assignments are a reasonable middle ground (Perhaps they could have knocked off a few from the above list).

So if you want to work at a top employer and not be forever stuck doing CRUD then your only option is to learn algorithms and practice interviewing. I know it sucks but that is how the game is played.

The reason some people can do them is not because they're geniuses but they come from employers,schools where there is a culture of doing interview problems. They've been doing this for atleast a year if not more. So try doing them for a year and then tell me whether you still find them impossible.

I realised this when I took the help of a champion competitive coder for preparation. It was hard to find a question typically asked in these interviews which he hadn't heard of in some shape or form.

I have some tips I'm compiling which I might turn into a blogpost or book.

For recognition you need to practice abstract thinking . Thinking of something in terms of code should be completely avoided. Suppose I ask you to find the common ancestor of two divs.

In this case the DOM is a tree whose nodes have parent pointers.

Turn every question into a mathematical abstract form. Find a k such that , Find two numbers x & y such that and so on.

The next step is massive repetition. It feels like you're grinding with no understanding , but something happens when you repeat something 20+ times. Depending on how smart you are it happens sooner. Eventually it will become intuitive.

Always learn multiple solutions. Never settle for just one answer. Learn all possible answers and how it might be possible to go from a brute force to the optimal one.

Use Geeks4Geeks and Elements of Programming Interviews to build your pattern recognition.

Next read books and PDFs by Udi Manber on algorithm design.

http://akira.ruc.dk/~keld/teaching/CSS_e10/Manber88.pdf

This is a lot of effort. But that's just how it is. You don't HAVE to work at Google. You can work at other places and do quite well too. But if you want the top jobs then this the road you must take.

Re: Top algorithms in interview questions

#46

Post by snovv_crash »

hal9000xp wrote: post #42
snovv_crash wrote: post #40

Earlier quoted context omitted.

That, of course, depends where you work. My daily work is math intensive and performance critical. I constantly need to think about cache sizes, big-O scaling and that ever-important constant factor. I've seen commits failed by QA because they inadvertently added a shared_ptr copy in a tight loop, which affected performance of the entire pipeline by 20%. So yeah, I regularly have to think about dynamic programming, s…

Your job sounds exciting! Do you work in gamedev? In which company you are working?

Computer vision late-stage startup, 80+ people now I think, of which 50 are devs. Of course not everyone does what I do, we still need people to work on the UI and packaging/licences etc. But at least 50% of the devs here do very research-oriented work.

Re: Top algorithms in interview questions

#47

Post by a_imho »

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…

Software in a nutshell. The 'can you invert a binary tree' coming of age ritual one studies so hard for. You know it will happen before you step into the interview room and there's no escaping it, but you go in nevertheless.

Re: Top algorithms in interview questions

#48

Post by maccard »

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…

Comes up fairly regularly for us in code reviews. People will question the data structures used. E.g. This find operation in a tight loop is actually called on a vector not a map, meaning it's a linear search rather than a constant operation.

Re: Top algorithms in interview questions

#49

Post by alkonaut »

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…

Avoid programming with databases and web servers and the plumbing and repetitive crud work can be minimized.

Pick a math intensive and performance sensitive domain and interesting algorithmic problems like these pop up all the time.

Re: Top algorithms in interview questions

#50

Post by ubernostrum »

jupiter90000 wrote: post #14
ubernostrum wrote: post #12

Earlier quoted context omitted.

All other things being equal, someone who understands these algorithms/data structures and how/when to use them would be preferred over someone who hasn't put time in to get familiarized with them. Correction: all other things being equal, the person who does better on an algorithms/data structures pop quiz is more likely to be a recent college graduate who you can pay less and treat worse than an established develop…

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 algorithm and data-structure questions, the fact would remain that hardly anyone (and more likely no-one) uses them as you advocate.

Getting these questions out of interviews and replacing them with metrics tailored to the desired job skills and responsibilities (rather than proxies for them, or even proxies for proxies for them, as is unfortunately usual in the industry), would be far more effective.

Or perhaps more bluntly: I know of no other field which A) drills students on low-level fundamental techniques in school/training, and B) largely replaces them with higher-level techniques on the job which discourage use and thus continued top-of-mind retention of the low-level techniques, and C) nonetheless requires instantaneous unassisted perfect recall of all details of any arbitrarily-chosen low-level technique as a mandatory qualification for employment even into late stages of the career.

Lawyers learn a lot about the law and its history and important cases, but they don't sit through pop quizzes of 15th-century English common-law rulings on every job interview for the rest of their lives, even though there probably are some such cases that would on occasion be useful to know. Doctors learn a lot of biology and chemistry, but if passing a closed-book organic-chem exam was a prerequisite for every job they'd take after med school we'd have a lot fewer employed doctors.

Only programmers do this to themselves. Only programmers relentlessly demand that it be preserved as a gatekeeping ritual. Only programmers insist that "well, it's fundamental so it must be useful sooner or later" is a sufficient justification for doing this.

It's time to stop doing this. It's time to stop supporting this. It's time to stop perpetuating this.

(and getting back to my initial comment: there's a reason why bootcamps now have a "how to pass code interviews" unit, and a reason why Cracking the Coding Interview sells so well, and it's because these things have stopped having any useful purpose -- if indeed they ever had useful purpose -- and now serve as artificial barriers and ways to perpetuate biases about background while claiming objective grounds to disqualify people the interviewer doesn't want to hire, thus making life miserable for both the hired, who are likely to be inexperienced and easy to take advantage of, and the unhired, who have to try again or give up and find another way to make a living)

Post reply on HN