4 ms·

Why does nobody get it? The coding interview is not about memorizing algorithms! The coding interview is about demonstrating that you can think from first pri

by ukj 8y ago

Why does nobody get it? The coding interview is not about memorizing algorithms! The coding interview is about demonstrating that you can think from first principles and DERIVE an algorithm! If you understand the problem and the strategy for solving it, you don't need to remember the algorithm.

mattnewton 8y ago
Maybe some very talented candidates will do this but most will memorize a large toolbox of algorithms that people invented over a very long period of time that are known optimal for certain uses. And then the test is recognizing a problem that needs one of these algorthms. Very few questions let someone derive an optimal solution from first principles on a whiteboard in 1 hour with an audience.
- ukj 8y ago
  You assume you are being tested on deriving an optimal solution. What you are actually being tested on is whether you can derive A solution. ANY solution. And if it is inefficient, you can figure out what needs optimisation and where. The very fact you recognize the inefficiency and you can speak up with ideas on how to make it better is data for the interviewer. Perfect is the enemy of good enough.
  - mattnewton 8y ago
    But in an arms race where one person does this and the other person recognizes it as being solved optimally by an algorithm they know, who looks like a better candidate?
    - Traster 8y ago
      I interview people a lot, if you get to a solution to one of my questions too quickly you get a very small amount of credit and I'll move on to another question until I find one you don't know. If you finish the interview having been familiar with all my questions at best I'm bringing you back for another interview, at worst you'll be discounted because I'll get the impression you've memorized everything you know and you'll be stuffed the first time we give you something new.
      - mattnewton 8y ago
        You are unique in that respect then in my experience. I don’t do this in interviews and afaik have never seen this kind of bias against people who study for interviews. It doesn’t make sense to me to discount people who prepared.
        Traster 8y ago
        It's not about discounting people who have prepared, what I'm looking for in an interview is: (1) Does this person approach problems in a systematic and logical way, (2) do they ask the right questions to clarify the task, (3) can they explain to others how their thought processes work, (4) can they formalize a discussion into a written description of the problem, (5) can they discuss in detail the nuances of their solution and relate that back to real world situations. If I ask a question and the candidate knows the most optimal solution then it's very difficult for me to assess most of those questions - because they aren't actually thinking through the problem, they're just remembering the solution and I primarily want to hire people who can figure out solutions - even if takes them a little bit longer, because it's indicative of their ability to actually go beyond what's already established in the field.
        mattnewton 8y ago
        We may be just using different definitions for what it means to prepare / know the solution. Most of the “thinking through the problem” in my experience is mapping the problem to a known class of problems which you have tools for. This is what software engineering is often, making entirely new and untested patterns is rare in my experience (and if it isn’t that could be indicative of an opportunity for improvement). And someone who has studied more will have more examples to map it to, and will likely do so faster. Disregarding a candidate because they have more examples and recognized them faster than someone who had to work through it from first principles is disregarding a candidate who will often provide you an industry standard solution for one who may be unaware someone has solved this problem already. It also seems to be an unrealistic goal, since most engineers I know who do work through things from first principles don’t do so with observers on a whiteboard in 45 minutes.
jeffreyrogers 8y ago
A lot of those algorithms were research questions that people spent a large amount of time on. The best way to prepare for these types of interviews is doing tons of practice problems until you get the pattern recognition to know what algorithms and data structures apply and fill out the code. Some things like DFS are pretty easy to derive from scratch, but others require more thought and very few people will be able to do it under pressure in an interview.
- ukj 8y ago
  Are you seriously trying to tell me that you remember the code for quick sort? I know what it does. Mechanically. I can visualize the recursive divide-and-conquer in my head. I can implement it in any language. All you have to understand is WHY the algorithm works.
  - jeffreyrogers 8y ago
    I know how quicksort works well enough to write out some pseudocode quickly. Then once I've got the structure I can implement it. Same with lots of other algorithms, but if I had never heard of quicksort there's no way I would be able to come up with it during an interview.

by ukj 8y ago

mattnewton 8y ago

Maybe some very talented candidates will do this but most will memorize a large toolbox of algorithms that people invented over a very long period of time that are known optimal for certain uses. And then the test is recognizing a problem that needs one of these algorthms. Very few questions let someone derive an optimal solution from first principles on a whiteboard in 1 hour with an audience.

ukj 8y ago
You assume you are being tested on deriving an optimal solution. What you are actually being tested on is whether you can derive A solution. ANY solution. And if it is inefficient, you can figure out what needs optimisation and where. The very fact you recognize the inefficiency and you can speak up with ideas on how to make it better is data for the interviewer. Perfect is the enemy of good enough.
- mattnewton 8y ago
  But in an arms race where one person does this and the other person recognizes it as being solved optimally by an algorithm they know, who looks like a better candidate?
  - Traster 8y ago
    I interview people a lot, if you get to a solution to one of my questions too quickly you get a very small amount of credit and I'll move on to another question until I find one you don't know. If you finish the interview having been familiar with all my questions at best I'm bringing you back for another interview, at worst you'll be discounted because I'll get the impression you've memorized everything you know and you'll be stuffed the first time we give you something new.
    - mattnewton 8y ago
      You are unique in that respect then in my experience. I don’t do this in interviews and afaik have never seen this kind of bias against people who study for interviews. It doesn’t make sense to me to discount people who prepared.
      - Traster 8y ago
        It's not about discounting people who have prepared, what I'm looking for in an interview is: (1) Does this person approach problems in a systematic and logical way, (2) do they ask the right questions to clarify the task, (3) can they explain to others how their thought processes work, (4) can they formalize a discussion into a written description of the problem, (5) can they discuss in detail the nuances of their solution and relate that back to real world situations. If I ask a question and the candidate knows the most optimal solution then it's very difficult for me to assess most of those questions - because they aren't actually thinking through the problem, they're just remembering the solution and I primarily want to hire people who can figure out solutions - even if takes them a little bit longer, because it's indicative of their ability to actually go beyond what's already established in the field.
        mattnewton 8y ago
        We may be just using different definitions for what it means to prepare / know the solution. Most of the “thinking through the problem” in my experience is mapping the problem to a known class of problems which you have tools for. This is what software engineering is often, making entirely new and untested patterns is rare in my experience (and if it isn’t that could be indicative of an opportunity for improvement). And someone who has studied more will have more examples to map it to, and will likely do so faster. Disregarding a candidate because they have more examples and recognized them faster than someone who had to work through it from first principles is disregarding a candidate who will often provide you an industry standard solution for one who may be unaware someone has solved this problem already. It also seems to be an unrealistic goal, since most engineers I know who do work through things from first principles don’t do so with observers on a whiteboard in 45 minutes.

jeffreyrogers 8y ago

A lot of those algorithms were research questions that people spent a large amount of time on. The best way to prepare for these types of interviews is doing tons of practice problems until you get the pattern recognition to know what algorithms and data structures apply and fill out the code. Some things like DFS are pretty easy to derive from scratch, but others require more thought and very few people will be able to do it under pressure in an interview.

ukj 8y ago
Are you seriously trying to tell me that you remember the code for quick sort? I know what it does. Mechanically. I can visualize the recursive divide-and-conquer in my head. I can implement it in any language. All you have to understand is WHY the algorithm works.
- jeffreyrogers 8y ago
  I know how quicksort works well enough to write out some pseudocode quickly. Then once I've got the structure I can implement it. Same with lots of other algorithms, but if I had never heard of quicksort there's no way I would be able to come up with it during an interview.