18 ms·

I've used Dijkstra algorithm for calculating distance in a graph once. It was a highlight of that month. Of course I had to look it up(despite learning it and i

by ajuc 6y ago

I've used Dijkstra algorithm for calculating distance in a graph once. It was a highlight of that month. Of course I had to look it up(despite learning it and implementing it at university). Who remembers this stuff exactly after years of glueing libraries together? And even if you remember - won't you check it anyway just to be sure? It's OK to ask people general questions (what's algorithmic complexity, what kind of algorithms and data structures they know about, what are the tradeofs, etc). But expecting people to remember the exact steps of an algorithm they last used 10 years ago at university is just stupid. It's like asking engineers to remember the tensile strength of a material they could use once a decade. That's what the documentation is for. It will take 3 minutes to look it up when I need it (if I need it at all).

namdnay 6y ago
Completely agree. The only thing that's important is knowing what to google for. i.e. being able to map from a real world problem to one or several algorithm/structure classes.
- WalterBright 6y ago
  > The only thing that's important is knowing what to google for. It's even more important to recognize when the solution found with google is subtly wrong.
Taek 6y ago
We always tell our candidates in advance what algorithms we'll be quizzing them on. And it's pretty much always: + fibbonacci + a sort + a linked list I like having candidates write out these problems on paper because it shows that they know how to think about code. Fibbonacci allows us to see that they have basic recursion understanding, and basic iterative loop understanding. Linked lists shows us that they understand pointers. And a sort shows us that you can structure more complex code well. If you truly want the job, you'll take 15 minutes the night before to remind yourself how all of these things work, none of them should be particularly foreign or confusing to an experienced programmer. That covers the coding part of our interview. For the problem solving part of the interview, we may give you problems that require using heaps or skiplists or graph algorithms, but for this part of the interview we're happy to let you import imaginary libraries that do all the hard work.
- arethuza 6y ago
  "write out these problems on paper" I write on paper so infrequently that I actually find it pretty difficult to write more than a few words. I certainly wouldn't want to write something out longhand in an interview! Edit: It seems to me it would be rather unfair of me to ask people to write out their thoughts in Org Mode in VS Code just because that's how I happen to like writing notes :-)
  - ajuc 6y ago
    Writing speed isn't the bottleneck hopefully :)
    - fenomas 6y ago
      It's not a matter of writing speed, it's familiarity. I've been programming for 30 years and I don't think I've ever written code down on paper. Why ask an interview candidate to do something they've never done before and will never do again? You might as well ask them to type their code using only one hand.
      - toomanybeersies 6y ago
        As a heavy smoker, I'd be quite good in an interview where I was forced to type with one hand.
      - TedDoesntTalk 6y ago
        > I've been programming for 30 years and I don't think I've ever written code down on paper I did it once or twice when I was 8 years old and didn’t have a computer yet :)
    - arethuza 6y ago
      Writing speed probably would be the bottleneck for me - plus whatever I wrote would almost certainly be illegible to anyone else.
  - robotron 6y ago
jandrese 6y ago
I remember the joy of finding a Siggraph paper from 1980 to implement Heckbert's Median Cut algorithm.
ausjke 6y ago
It does not matter how us think, I believe these detail-oriented algorithm interviews are intentionally designed for younger coders who can still do them out of memory, though in practice they're not very meaningful and if you really need them sometime you can always dive-in and get what you need. I'm doing leetcode now, as a senior engineer there is no way to get a decent job without being tested like a college fresh-out as far as programmer positions are concerned, no complains, I will do them, it is the market picks me, not the other way around. To me even though this is painful, but at least it is "merit-based", what I dislike the most is that you got a job based on other factors instead of how able you are.
dominotw 6y ago
you don't need to know algorithms with somone's name on it for an interview but there are few exceptions, 1. Dijkstra's 2. Kadane's 3. Bellman ford - negative edges
- ivanhoe 6y ago
  IMHO all you need to know is to recognize a certain category of problems and remember that there is an appropriate algorithm for it - and if can you recall the name even better, will save you some time googling, but it's not that important. After consulting the documentation and if you previously learned it in a school/course, you'll be able to implement it in pretty much the same time as someone who knows how to draw it on a whiteboard from the top of their head.
mikorym 6y ago
> It was a highlight of that month. Just using a graph was the highlight of that month for me. (The data wasn't already in a graph.) Reading the wiki, it may have been Dijkstra that I used under the hood. (I just wanted the sum of simple paths for all leaves to the root, for each leaf.) Cheers for us.

by ajuc 6y ago

namdnay 6y ago

Completely agree. The only thing that's important is knowing what to google for. i.e. being able to map from a real world problem to one or several algorithm/structure classes.

WalterBright 6y ago
> The only thing that's important is knowing what to google for. It's even more important to recognize when the solution found with google is subtly wrong.

Taek 6y ago

We always tell our candidates in advance what algorithms we'll be quizzing them on. And it's pretty much always: + fibbonacci + a sort + a linked list I like having candidates write out these problems on paper because it shows that they know how to think about code. Fibbonacci allows us to see that they have basic recursion understanding, and basic iterative loop understanding. Linked lists shows us that they understand pointers. And a sort shows us that you can structure more complex code well. If you truly want the job, you'll take 15 minutes the night before to remind yourself how all of these things work, none of them should be particularly foreign or confusing to an experienced programmer. That covers the coding part of our interview. For the problem solving part of the interview, we may give you problems that require using heaps or skiplists or graph algorithms, but for this part of the interview we're happy to let you import imaginary libraries that do all the hard work.

arethuza 6y ago
"write out these problems on paper" I write on paper so infrequently that I actually find it pretty difficult to write more than a few words. I certainly wouldn't want to write something out longhand in an interview! Edit: It seems to me it would be rather unfair of me to ask people to write out their thoughts in Org Mode in VS Code just because that's how I happen to like writing notes :-)
- ajuc 6y ago
  Writing speed isn't the bottleneck hopefully :)
  - fenomas 6y ago
    It's not a matter of writing speed, it's familiarity. I've been programming for 30 years and I don't think I've ever written code down on paper. Why ask an interview candidate to do something they've never done before and will never do again? You might as well ask them to type their code using only one hand.
    - toomanybeersies 6y ago
      As a heavy smoker, I'd be quite good in an interview where I was forced to type with one hand.
    - TedDoesntTalk 6y ago
      > I've been programming for 30 years and I don't think I've ever written code down on paper I did it once or twice when I was 8 years old and didn’t have a computer yet :)
  - arethuza 6y ago
    Writing speed probably would be the bottleneck for me - plus whatever I wrote would almost certainly be illegible to anyone else.
- robotron 6y ago

jandrese 6y ago

I remember the joy of finding a Siggraph paper from 1980 to implement Heckbert's Median Cut algorithm.

ausjke 6y ago

It does not matter how us think, I believe these detail-oriented algorithm interviews are intentionally designed for younger coders who can still do them out of memory, though in practice they're not very meaningful and if you really need them sometime you can always dive-in and get what you need. I'm doing leetcode now, as a senior engineer there is no way to get a decent job without being tested like a college fresh-out as far as programmer positions are concerned, no complains, I will do them, it is the market picks me, not the other way around. To me even though this is painful, but at least it is "merit-based", what I dislike the most is that you got a job based on other factors instead of how able you are.

dominotw 6y ago

you don't need to know algorithms with somone's name on it for an interview but there are few exceptions, 1. Dijkstra's 2. Kadane's 3. Bellman ford - negative edges

ivanhoe 6y ago
IMHO all you need to know is to recognize a certain category of problems and remember that there is an appropriate algorithm for it - and if can you recall the name even better, will save you some time googling, but it's not that important. After consulting the documentation and if you previously learned it in a school/course, you'll be able to implement it in pretty much the same time as someone who knows how to draw it on a whiteboard from the top of their head.

mikorym 6y ago

> It was a highlight of that month. Just using a graph was the highlight of that month for me. (The data wasn't already in a graph.) Reading the wiki, it may have been Dijkstra that I used under the hood. (I just wanted the sum of simple paths for all leaves to the root, for each leaf.) Cheers for us.