Top algorithms in interview questions • Hacker News Board

Re: Top algorithms in interview questions

#61

Post by UncleMeat » Sun, Jan 01, 2017, 5:09 PM UTC

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?

Engineer at one of the big four here. These specific algorithms don't necessarily come up all the time but my work would be impossible without strong algorithmic background. Is it better to use BDDs or Radix Trees to store abstract program state? What is the most efficient iteration strategy for computing fixed points? If I can't give a good answer to these questions then in all likelihood my system will never terminate.

Re: Top algorithms in interview questions

#62

Post by sudshekhar » Sun, Jan 01, 2017, 5:18 PM UTC

jupiter90000 wrote: post #53

ubernostrum wrote: post #50

Earlier quoted context omitted.

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…

As somebody who passed out of university last year, I remember how we had to mug up most of the questions on this website (and practice topcoder + codeforces), so that interviewers could consider us smart.

IMO, algorithmic interviews are maybe a good way to filter for motivation rather than anything else. Candidates who are likely to learn all this are more hardworking and career-consciuos (placements correlated pretty strongly with how much you 'knew').

That said, there was this one interview I had where the interviewer asked me how to design a distributed log collection service. Basically you have GBs of log files being generated on hundreds of servers and you want them sorted and stored on a single central database. What sort algo will you use, why? How to reduce transmitted over the network etc.

It was a fun round and tested a lot of disparate concepts.

To my inexperienced self, this seems like a good format:

- First round: Ask stuff like fizz-buzz, trees, file I/O or string processing stuff. Basically ensure that they know how to code. Another way could be asking them to code the same question in functional, OOP and procedural styles

- Second round: Discuss some project done by the candidate or ask them to design something from scratch. URL shorteners, databases, REST apis are normal candidates. Spreadsheets, DSLs etc might be good to make things harder.

- Third round (If applicable) : Dig into any one specific domain most relevant to your company/team and make them architect* the whole thing.

Ofcourse, any system, once its established and well-known, can be gamed. Banking on open source projects or past achievements is then what remains.

* Very few entry levels jobs really require such skills but (IMO) it will help you get better engineers instead of coders.

Re: Top algorithms in interview questions

#63

Post by ausjke » Sun, Jan 01, 2017, 6:54 PM UTC

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…

but you still need write them for interview purposes, it is the first step to filter out candidates, no matter how senior you are I think.

Re: Top algorithms in interview questions

#64

Post by ajmurmann » Sun, Jan 01, 2017, 8:20 PM UTC

In all my daily work OOP design skills always have battered much more significantly than knowledge of any of these algorithms. Yet I've never seen anyone ask about SOLID for example.

Re: Top algorithms in interview questions

#65

Post by Silhouette » Sun, Jan 01, 2017, 9:30 PM UTC

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…

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.

Me too, at least for some of the projects I'm working on, but it's probably fair to say that I've never used most of the "textbook algorithms" I've come across over the years in a production system.

The interesting and challenging problems are mostly the ones that aren't just a direct application of such an algorithm. Consequently, I think the more valuable ability is recognising when a part of such a problem probably does have a standard solution, so you can spend a few minutes looking up the current state of the art.

Obviously you still need enough familiarity with the theory in the areas you're working in for that recognition to work, and then to understand the current state of the art when you need it.

Re: Top algorithms in interview questions

#66

Post by majormajor » Mon, Jan 02, 2017, 3:22 AM UTC

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…

> That, of course, depends where you work.

Small correction: it depends on what problems you work on.

There are people at top companies making big money working on complex problems, there are also people at those companies who passed through a super-algorithm-heavy interview and work on much less mathematically demanding code. And there are people at small companies you've never heard of working on much more intense problems than them. But the people doing boring work at big companies are often making $$$ compared to the people working at small companies working on interesting stuff. (I've been both of those people...)

Re: Top algorithms in interview questions

#67

Post by threatofrain » Mon, Jan 02, 2017, 5:52 AM UTC

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…

In terms of business, I question whether most companies have the financial justification to implement math heavy software strategies, or novel strategies.

For many businesses, I wonder if their software requirements are generally boring with many parts of their problem already solved and implemented in the form of a framework, with a few libraries waiting to be glued together.

I also have the suspicion that for companies such as Cloudflare, where there is justification to implement either novel or math-heavy strategies, these kinds of companies trust very few people to make the business and technical judgment call to pursue a strategy aside from simply using off-the-shelf solutions.

But a lot of people may be screened on these matters without the company ever intending to take advantage of the abilities they test for. I really wonder how often Google takes advantage, or even trusts their employees, to make such decisions or exercise such abilities, as opposed to a few superstar Googlers.

Re: Top algorithms in interview questions

#68

Post by jules » Mon, Jan 02, 2017, 1:32 PM UTC

madmax108 wrote: post #26

This 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)…

The couple of explanations of algorithms that I looked at were good. Much more concise than a textbook, but with links to additional material.

Re: Top algorithms in interview questions

#69

Post by sh87 » Mon, Jan 02, 2017, 8:39 PM UTC

alkonaut wrote: post #52

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.

I know where you are getting at and there's a subtle difference there.

Knowing the 'implementation' Vs Knowing the 'algorithm'.

I don't think I can 'know' something without actually doing it. Thereby, the road to knowing the algorithm goes through the rock climb of knowing its implementation.

Re: Top algorithms in interview questions

#70

Post by sh87 » Mon, Jan 02, 2017, 8:45 PM UTC

I sense the dire need for separate interviewing processes for anything that involves CRUD/WebApps with a database/Front End etc. and anything that is math/compute heavy.

Although I feel it is correct on the interviewer's part to expect me to know what these algorithms are and their general behaviour, expecting me to have it memorised to be considered eligible for writing CRUD apps and struggling with build tools and outdated test infrastructures is just infuriating. Hello 2017.