4 ms·

I think people certainly need to understand that DS&A are a thing, and time/space complexity is a thing. The problem is the way they test for this makes no sen

I think people certainly need to understand that DS&A are a thing, and time/space complexity is a thing. The problem is the way they test for this makes no sense. At most having done DS&A will flash some lights in my mind when an n^2 or higher solution comes up, ie I will think about how to do it better. But that thinking will inevitably lead me to google for a better answer, rather than plumb my limited memory capacity for how to do it. So it's a principle that relies on the right tools to get implemented, and that's rarely what anyone asks for in the interview. More than anything else I've ever done, coding is an exploration. And nobody seems to test for that, they seem to all test for whether you've already been down a certain cave, recently. For instance, I can write a mobile app that trades stocks on an exchange through a server. I could write both the apps and the server for you. I've literally done all the bits that you would need to do this. If you ask me some random question about Swift or C++ syntax, I will fail. Because having those in my mind's cache is not sensible. Knowing that sorting is probably already a solved problem, or knowing what the unsolved problems ahead are, those are useful. The real thing you need to do as a programmer is to handle complexity. Not in the big-o sense, but in the sense of keeping the mess of code a sensible size, in a way that allows you to make future changes easily, and allows collaborators to contribute easily. This is both a code thing and a people thing. Yet I don't come across a lot of people asking about how this is done.

username90 5y ago
> More than anything else I've ever done, coding is an exploration The fundamentals of exploration is the ability to traverse different types of obstacles. In programming those obstacles are traversed by being creative with algorithms. Therefore companies test you if you can be creative with algorithms. Of course if you have never done that then you don't see it as exploration but instead tedious nonsense. So at least in my eyes anyone who sees these things as just tedious nonsense are self filtered out, why would you want to hire people who have never tried to be explorative in this field? Them not applying in the first place is great!
- emteycz 5y ago
  Being creative with algorithms is different from carrying algorithms in your head..
  - FartyMcFarter 5y ago
    That's why the best coding interview questions are the ones that can be solved without fancy algorithms.
    - username90 5y ago
      Interviews almost never require fancy algorithms, just the super basic ones that you learn in the first course in college.
      - username90 5y ago
        I've seen a ton of interviews at Google, none of them required fancy algorithms. They did require you to take some fundamental algorithm and change it up a bit, but the end result wasn't fancy algorithms just basic ones with a twist.
  - username90 5y ago
    If you have been creative with algorithms then you will have the fundamental ones in your head. Every time you add layers the last layers needs to be really stable, so testing the layers they need to have built upon is a good way to filter out people who haven't progressed past that layer.
    - tchalla 5y ago
      > If you have been creative with algorithms then you will have the fundamental ones in your head. You can be creative with algorithms without having the "fundamental" ones in your head because you know where to look them up. Therefore, testing the layers; tests for recall and not for those layers. In most situations, these tests only test for short-term preparation.
carlmr 5y ago
Exactly on point, which is why for interviews I like to discuss code snippets. Asking what's wrong here, is this the right collection type to use here, what would you do instead, how would you refactor this. I do like to ask algorithmic questions, but I don't expect the algorithm in detail. Instead I want to know if people understand when to use it, and what is the principle behind it. Because while you don't need to implement your own collections, you should know what their advantages and disadvantages are.
- tzs 5y ago
  >> More than anything else I've ever done, coding is an exploration. And nobody seems to test for that, they seem to all test for whether you've already been down a certain cave, recently > Exactly on point, which is why for interviews I like to discuss code snippets. Asking what's wrong here, is this the right collection type to use here, what would you do instead, how would you refactor this LeetCode can be great for both of those--but not the way most interviewers use it. Instead of using it as a source of problems to throw at someone and expecting them to produce in short order a working, correct implementation, use it collaboratively with the candidate. Pick a problem, read it with them, and discuss possible approaches. Try to let them take the lead on this, nudging them as needed to keep them going in the general direction of a viable approach. When that is done go to the discussion area for the problem. There people post all kinds of purported solutions. Go over a few of those with the candidate, critiquing them together. Plenty of the posts will contain errors, ranging from minor to severe, providing plenty of points for discussion.
  - carlmr 5y ago
    That's a cool idea. I rarely think about these platforms due to my personal distaste for them, but that's actually useful.
kfreds 5y ago
> Yet I don't come across a lot of people asking about how this is done. Please elaborate! How do you handle complexity?
- lordnacho 5y ago
  You can see how people explain what they do. Does the explanation itself become massively complex? Is there a reasonable high level explanation, or is it a mess of ifs and buts? As for actually keeping things clean there's any number of things that can be mentioned. Reasonable abstractions, issue tracking, version control, documentation, choice of frameworks, and so on.
mujina93 5y ago
Once I was interviewed in this way: I was given a test with various questions (algorithms, general knowledge, etc.), and I was given a tablet with which I could google whatever I wanted. I was left alone with the test and the tablet and I was given some time to finish that. I think it's one of the best way that I've ever witnessed or heard of to test for what you mention: the exploration and research that happens in real life when you encounter a problem to solve at work. I haven't seen this anywhere else unfortunately.

username90 5y ago

> More than anything else I've ever done, coding is an exploration The fundamentals of exploration is the ability to traverse different types of obstacles. In programming those obstacles are traversed by being creative with algorithms. Therefore companies test you if you can be creative with algorithms. Of course if you have never done that then you don't see it as exploration but instead tedious nonsense. So at least in my eyes anyone who sees these things as just tedious nonsense are self filtered out, why would you want to hire people who have never tried to be explorative in this field? Them not applying in the first place is great!

emteycz 5y ago
Being creative with algorithms is different from carrying algorithms in your head..
- FartyMcFarter 5y ago
  That's why the best coding interview questions are the ones that can be solved without fancy algorithms.
  - username90 5y ago
    Interviews almost never require fancy algorithms, just the super basic ones that you learn in the first course in college.
    - username90 5y ago
      I've seen a ton of interviews at Google, none of them required fancy algorithms. They did require you to take some fundamental algorithm and change it up a bit, but the end result wasn't fancy algorithms just basic ones with a twist.
- username90 5y ago
  If you have been creative with algorithms then you will have the fundamental ones in your head. Every time you add layers the last layers needs to be really stable, so testing the layers they need to have built upon is a good way to filter out people who haven't progressed past that layer.
  - tchalla 5y ago
    > If you have been creative with algorithms then you will have the fundamental ones in your head. You can be creative with algorithms without having the "fundamental" ones in your head because you know where to look them up. Therefore, testing the layers; tests for recall and not for those layers. In most situations, these tests only test for short-term preparation.

carlmr 5y ago

Exactly on point, which is why for interviews I like to discuss code snippets. Asking what's wrong here, is this the right collection type to use here, what would you do instead, how would you refactor this. I do like to ask algorithmic questions, but I don't expect the algorithm in detail. Instead I want to know if people understand when to use it, and what is the principle behind it. Because while you don't need to implement your own collections, you should know what their advantages and disadvantages are.

tzs 5y ago
>> More than anything else I've ever done, coding is an exploration. And nobody seems to test for that, they seem to all test for whether you've already been down a certain cave, recently > Exactly on point, which is why for interviews I like to discuss code snippets. Asking what's wrong here, is this the right collection type to use here, what would you do instead, how would you refactor this LeetCode can be great for both of those--but not the way most interviewers use it. Instead of using it as a source of problems to throw at someone and expecting them to produce in short order a working, correct implementation, use it collaboratively with the candidate. Pick a problem, read it with them, and discuss possible approaches. Try to let them take the lead on this, nudging them as needed to keep them going in the general direction of a viable approach. When that is done go to the discussion area for the problem. There people post all kinds of purported solutions. Go over a few of those with the candidate, critiquing them together. Plenty of the posts will contain errors, ranging from minor to severe, providing plenty of points for discussion.
- carlmr 5y ago
  That's a cool idea. I rarely think about these platforms due to my personal distaste for them, but that's actually useful.

kfreds 5y ago

> Yet I don't come across a lot of people asking about how this is done. Please elaborate! How do you handle complexity?

lordnacho 5y ago
You can see how people explain what they do. Does the explanation itself become massively complex? Is there a reasonable high level explanation, or is it a mess of ifs and buts? As for actually keeping things clean there's any number of things that can be mentioned. Reasonable abstractions, issue tracking, version control, documentation, choice of frameworks, and so on.

mujina93 5y ago

Once I was interviewed in this way: I was given a test with various questions (algorithms, general knowledge, etc.), and I was given a tablet with which I could google whatever I wanted. I was left alone with the test and the tablet and I was given some time to finish that. I think it's one of the best way that I've ever witnessed or heard of to test for what you mention: the exploration and research that happens in real life when you encounter a problem to solve at work. I haven't seen this anywhere else unfortunately.