4 ms·

I disagree with some of this. At some of my past jobs and the current one, this kind of algorithmic knowledge was important to build features that were differe

by whstl 3y ago

I disagree with some of this. At some of my past jobs and the current one, this kind of algorithmic knowledge was important to build features that were differentiators in the market. As much as people love to pretend, not every single possible solution is in a library. Sometimes you're the one building the library. It doesn't have to be leetcode, but candidates should at least be able to produce some code that doesn't come from the README of their favourite framework. Also, talking for 30/45 mins can be enough, but it produces false positives when you have people coaching candidates. I've had people completely acing interviews that it felt like the perfect candidate. Well, it was rehearsed. When I asked for a fizz-buzz type question they completely messed it up.

emseetech 3y ago
| this kind of algorithmic knowledge was important to build features that were differentiators in the market I agree with this, but with the caveat that it's extremely rare to come up with a truly novel algorithm in a production environment. Those almost always come out of academia or R&D departments. So is it important that people remember how to implement algorithms from scratch? Or is it important that they know when to identify when an existing algorithm would be useful? For instance, if I see that something is suspiciously like a Stable Marriage Problem, do I need to remember how to implement the Gale–Shapley algorithm? Or is just the ability to recognize the problem as something that has a particular solution 90% of the way there? I would argue yes. That said, I'm not sure how to test this is an interview setting.
- whstl 3y ago
  You don't need something "truly novel" to have a market advantage. Far from it. You just need something that is not ready made. Remember that not every algorithm is neatly package-able, or has a cool name like "Stable Marriage Problem" or "Levenshtein Distance". Also: maybe your advantage is implementing some of those in a new language. Maybe your advantage is implementing one of those in SQL! Maybe you have a tree-like or graph-like structure, and you need to do something with it without having to export into some format expected by certain packages. Knowing what to implement is important too. Also, those interviews are often testing for something even simpler than those fancy algorithms. Nobody uses Fizz Buzz or Recursive Fibonacci daily, but you might need to implement something that is beyond creating views/models/controllers in your favourite MVC framework. This is what the test is checking for: coding beyond what's on the README of your framework.

by whstl 3y ago

emseetech 3y ago

| this kind of algorithmic knowledge was important to build features that were differentiators in the market I agree with this, but with the caveat that it's extremely rare to come up with a truly novel algorithm in a production environment. Those almost always come out of academia or R&D departments. So is it important that people remember how to implement algorithms from scratch? Or is it important that they know when to identify when an existing algorithm would be useful? For instance, if I see that something is suspiciously like a Stable Marriage Problem, do I need to remember how to implement the Gale–Shapley algorithm? Or is just the ability to recognize the problem as something that has a particular solution 90% of the way there? I would argue yes. That said, I'm not sure how to test this is an interview setting.

whstl 3y ago
You don't need something "truly novel" to have a market advantage. Far from it. You just need something that is not ready made. Remember that not every algorithm is neatly package-able, or has a cool name like "Stable Marriage Problem" or "Levenshtein Distance". Also: maybe your advantage is implementing some of those in a new language. Maybe your advantage is implementing one of those in SQL! Maybe you have a tree-like or graph-like structure, and you need to do something with it without having to export into some format expected by certain packages. Knowing what to implement is important too. Also, those interviews are often testing for something even simpler than those fancy algorithms. Nobody uses Fizz Buzz or Recursive Fibonacci daily, but you might need to implement something that is beyond creating views/models/controllers in your favourite MVC framework. This is what the test is checking for: coding beyond what's on the README of your framework.