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.
Top algorithms in interview questions
31–40 of 70 posts
Re: Top algorithms in interview questions
#32But these questions should be a signal to you as an interviewee. Unless they are extremely salient to your proposed job (e.g., you are applying for a position teaching algorithms) they're a sign the recruiting effort at this workplace is not very healthy.
What that means is that talent and skill will be erratically dispersed throughout that organization. Requests for new staff will take a long time and may not fill needs, and that often times specific managers strongly influence who can get hired where for a variety of reasons.
Personally, I play along with these questions but make a game of pointing out how incredibly synthetic and unrealistic the conditions people put around them are. The goal of the game is to basically force the interviewer to come out and say exactly what algorithm they want, by way of how many other aspects of real-world software and systems they want to exclude from the conversation.
Re: Top algorithms in interview questions
#33Would 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…
Certainly. Of course, you should know how they work to the extent that you could write a (trivial) implementation if ever needed, but that very rarely happens.
However, occasionally you do need to write specialised implementations tailored to your particular usecase and chosen data structures. Hash tables in particular come to mind.
For example, I once had to write a statically allocated (fixed-size) hash table with O(1) lookups. A lot of tradeoffs enter the picture at that point so you had better know a dozen different types of hash tables to hash out a suitable implementation for the particular usecase.
Re: Top algorithms in interview questions
#34This 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 work and implemented but it may take years of practice to earn ability to recognize them.
Google won't ask you directly to implement Dijkstra algorithm. They may give you a problem which on surface have nothing to do with graphs. It may take a while before you actually have a light-bulb/aha moment when you realize it's a graph problem.
In practical non-interview problems, ability to recognize algorithms is much more important than knowing their implementation. You can always find their implementation on the Internet after all.
This is why I'm trying hard to improve my problem solving skills by solving competitive programming problems almost everyday.
Re: Top algorithms in interview questions
#35This 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.
Re: Top algorithms in interview questions
#36I think I've only ever had one of these algorithms come up in a hiring situation - unless I have brought them up myself in the normal flow of conversation.
I had to solve a problem for which a binary search was the correct solution (as well as some caching of results and stuff [although that part was fancy show-off stuff and not really necessary to solve the problem satisfactorily]) but I did the caching first and then sort of froze when it came to binary search because I was thinking 'uhm I should describe my thinking here first' and then the developer who was in charge of the exercise took my hesitation as not knowing the solution so he finished it and that was that (the test was also in Python a language I don't know that well - the theory was if you could figure your way through in Python despite not knowing it you would be able to handle new situations with aplomb. So I guess I failed the aplomb part.)
Re: Top algorithms in interview questions
#37This 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 becomes vastly less important than your ability to impress the right people and politically maneuver yourself into winning situations. This is the reality of life in a mega tech corp.
Re: Top algorithms in interview questions
#38This site is EXTREMELY popular in India, and used a lot by students AND interviewers (I know many who simply ask questions from the front page of G4G on a given day). It's the inverted tree equivalent in India. I'm someone who was actually interviewed by GeeksForGeeks because a junior from college connected them to me (They do interviews with people who have gotten placed in * dream * companies... not my terminology)…
I concur in India. I have 10+ years experience with a lot of work in embedded and I had this interviewer who when interviewing opened this page in his laptop and started asking questions from there.
Many of my colleague just learn the algorithm implementation by rote because in India it is very rare for companies to dig into algorithms or talk about its applications and optimizations.
Re: Top algorithms in interview questions
#39Nobody needs to be able to code these in an interview. Ever. For certain domains you should be aware of them and be able to look up decent implementations. But to think that level of knowledge is important in an interview is bogus. I could just as easily ask similar questions and weed out most CS grads that get into Google or Facebook with these: Please implement a first order low pass IIR filter. Tell me how the but…
"The goal of an interview is to ascertain weather the candidate is capable of doing stuff and learning stuff, and if that's likely to carry over into the stuff you need done. It's not to see weather they can produce an answer to some specific problem on the spot. "
I have uttered these words breathlessly so many times and we continue to hire disappointnent after disappointment. These questions are so foolishly beat into silicon valley culture it's absurd. I have zero CS background and rise to the top of every team I've been on, why? Because I'll just grind as hard as it takes to learn the relevant things to solve the problem at hand.
Re: Top algorithms in interview questions
#40This 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…
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, switching away from a linear low-constant algorithm once the problem is no longer small, how something could be restructured to be massively parrellizable, even alignment of arrays so that we get reasonable SIMD performance.
Yes, these jobs exist, and yes, they do require a strong algorithms background, as well as a good understanding of memory heirarchy, branching delays and what can be offloaded to GPU or at least parallized.