Ask HN: Reinventing the wheel during interview challenges
On one end it can be impressive to write code from scratch. On the other, sometimes they just want someone to get the job as soon as possible.
On one end it can be impressive to write code from scratch. On the other, sometimes they just want someone to get the job as soon as possible.
There is a whole range of algorithms (say topological sort, transitive closure, or suffix trees) that will send me immediately to look at an algorithms book or to look up an implementation in the standard or extended library. (e.g. pypi, npm and the maven central repository count as "the extended library")
There's something nice about sorting algorithms from the viewpoint of algorithm theory (usually you can prove that they always make forward progress) but almost any coder today will use the 饾殰饾殬饾殯饾殱() function from the stdlib.
Interviewers come in all shapes and shades, best to ask at the start of the problem. Sometimes you are being evaluated more on your questions and thinking than on getting the right code or answer.
Any good programmer also knows algorithms, not just being able to code them out of their head but also when to look them up in an algorithm book. I'm sure I could figure out a good algorithm for making a suffix tree if I had weeks to spend on it, simply knowing that it's possible. I know there are several clever ideas that have to combined to make it scalable for practical use so if I really need a suffix tree algorithm I am going to either use one somebody else wrote or I am going to start with a description of the algorithm from a book on my shelf.
From the viewpoint of being prepared for an interview ideally you (a) have it all, and barring that (b) gracefully use what it is you have under pressure.