4 ms·

The post arrives at the wrong conclusion. DSA style problems are good if used correctly. Give a candidate a good challenge, preferably with some requirements

The post arrives at the wrong conclusion. DSA style problems are good if used correctly. Give a candidate a good challenge, preferably with some requirements that can have different interpretations, ask them questions, help them and collaborate with them. The analysis of the whole exercise should be your hiring determination not whether the problem was actually solved. Did the candidate: - stick with the problem? - ask meaningful questions about requirements? - ask for help from a senior when stuck? - explore different avenues to solve the problem? - handle criticism? Of course it is great if they solve the problem but often that often only shows you that they have memorized algorithms. ( we have the internet these days )

d4nyll 5y ago
I agree with everything you said. The best interviews ive had are those where I felt like I am working together with the interviewer. I think being able to handle criticism is an important trait to look out for. Many times interviewees will defend their method too aggressively. But if you have to pick between two people who are equally pleasant to work with, but one was able to solve the problem, you'll probably pick the one who solved the problem. When the competition is fierce, the candidate would probably still have to spend some time practicing on these problems.
- lhorie 5y ago
  I interview candidates at a company with a relatively high volume of interviews and I use DSA criteria in my interviews. But here's what I do: - I phrase the question in a way that has some semblance of day-to-day relevance. That is to say that at some point in the process of coming up with a solution, the ability to apply a relevant data structure will come up, but it will be in service of an end goal that looks like the deliverable of a sprint task. - I come into the interview aware of multiple solutions and I am open to any of them. - I pace feedback so that the candidate actually solves the problem by the end of the interview, no matter their level (which does mean, in some cases, literally spelling out the step to unblock themselves). The rationale is that solving a hard DSA question doesn't give me all that much signal in and of itself. Watching a candidate bang out something with a level of complexity a little higher than fizz buzz is usually sufficient to evaluate whether the candidate has familiarity with the language. The choice of idioms and APIs can tell me things about their relative level of expertise with the stack (i.e. it can generally be safely assumed that an already employed candidate can hold their candle, and the question for me is more along the lines of "to which extent"). During the course of an interview, I can usually pick up a distinct and noticeable difference in focus between candidates, especially surrounding topics related to proactiveness/curiosity (e.g. does the candidate have understanding of aspects one abstraction level lower than the API they usually use, are they aware of well known pros and cons of some specific idiom, does their argumentation seem derived from personal experience vs parroted from a hivemind, etc). This tends to correlate surprisingly accurately to how much autonomy and growth they demonstrate on the job. "Hardcore" DSA evaluation only really comes in as a criteria to determine whether the candidate is of very high quality when most other criteria have already been evaluated as acceptable/desirable. These nice-to-have criteria come into play in some cases where I want to advocate for the candidate when the evaluation panel is split due to one seemingly bad session (possibly due to factors such as nervousness or mixed signals), or inversely when the role logically demands a higher bar but the panel is situationally incentivized to hire down to meet a quota. I've been told by several candidates that they appreciate my interviewing style, and conversely, I feel like I get a much better feel for the candidate than strictly evaluating DSA skills and nothing else.
jerf 5y ago
What is unique about "DSA style problems" that makes it that only through them you can see if they stuck with the problem, asked meaningful questions, etc.? Why not ask them real questions about the real sorts of things they're going to do, and through those see if they stuck with the problem, asked meaningful questions, etc.? DSA problems don't bring anything to the table here, because it's trivial to substitute them with something meaningful. I'd even go so far as to say that we work bizarrely hard at asking uselessly inappropriate questions. It is easier to ask questions related to the real job.
- capitalsigma 5y ago
  Most of the substitutes you might want to pick are specific to a particular domain (webdev, for example). If you run a big company, you want to give a generic interview that gives you signal on a candidate's fit with a wide variety of teams that touch many domains. So you abstract away the domain-specific parts of the task until you have something that is broad enough to apply to many subdomains... and now you're doing DSA interviews, because DSA is exactly the bits of coding that are generic, abstract, and applicable to many domains.
  - jerf 5y ago
    Just is in programming, if you've abstracted away to the point that you're no longer even doing the task you started with, you've failed. I don't care that you really really want a solution to P = NP; you can't have it. If you try to force it, you will pay the consequences. I don't care that you really really want a single standardized interview for what is essentially several dozen distinct positions, even if they all "use computers". You can't have it. If you try to force it, you will pay the consequences. If you suggested that companies should have completely standardized interviews for salespeople, lawyers, and executives, all because they "talk to people", you'd be laughed at. Change it to "talking to computers" and they lose the thread.
- bluGill 5y ago
  The meaningful question for most DSA problems "does my standard library already have an an algorithm for this?", if no the proper follow up is "okay, I need to head to my library for a few hours to research if there is a known answer that I can copy - will I be given time to propose the addition of the algorithm to my languages standard library so nobody else needs to do this again?" I don't want someone write an algorithm in a couple hours, I want someone to write the one implementation that is correct. Now sometimes there are compromises in algorithms (I can think of 3 different nlogn sorting algorithms and I think I've forgotten a dozen more) and so the company has a propitiatory library that has an implementation with different compromises. They should have benchmarks and pros and cons written down (ad ideally be open source) so that anytime someone asks about the algorithm they can point out why they have their own and possibly contribute it to the standard library if everyone agrees to a different compromise. These days that vast majority of the simple algorithms have already been written. I might need someone to design a more complex algorithm, but they either takes months of thought, or are just a sequence of simple algorithms.
carom 5y ago
In reality though, you learn how to solve a bunch of categories of problems on your own time, then put on a show where you go from the naive solution to the correct one. It's not as if someone is going to figure out dynamic programming during the interview, and once you know those concepts it is pretty apparent where to apply them. Honestly, I probably wouldn't even come up with the trick for the 3sum problem during an interview. Maybe I am dumb or maybe this is common, but the only reason I pass is because I've done the leetcode grind. The interview is just performative.

d4nyll 5y ago

I agree with everything you said. The best interviews ive had are those where I felt like I am working together with the interviewer. I think being able to handle criticism is an important trait to look out for. Many times interviewees will defend their method too aggressively. But if you have to pick between two people who are equally pleasant to work with, but one was able to solve the problem, you'll probably pick the one who solved the problem. When the competition is fierce, the candidate would probably still have to spend some time practicing on these problems.

lhorie 5y ago
I interview candidates at a company with a relatively high volume of interviews and I use DSA criteria in my interviews. But here's what I do: - I phrase the question in a way that has some semblance of day-to-day relevance. That is to say that at some point in the process of coming up with a solution, the ability to apply a relevant data structure will come up, but it will be in service of an end goal that looks like the deliverable of a sprint task. - I come into the interview aware of multiple solutions and I am open to any of them. - I pace feedback so that the candidate actually solves the problem by the end of the interview, no matter their level (which does mean, in some cases, literally spelling out the step to unblock themselves). The rationale is that solving a hard DSA question doesn't give me all that much signal in and of itself. Watching a candidate bang out something with a level of complexity a little higher than fizz buzz is usually sufficient to evaluate whether the candidate has familiarity with the language. The choice of idioms and APIs can tell me things about their relative level of expertise with the stack (i.e. it can generally be safely assumed that an already employed candidate can hold their candle, and the question for me is more along the lines of "to which extent"). During the course of an interview, I can usually pick up a distinct and noticeable difference in focus between candidates, especially surrounding topics related to proactiveness/curiosity (e.g. does the candidate have understanding of aspects one abstraction level lower than the API they usually use, are they aware of well known pros and cons of some specific idiom, does their argumentation seem derived from personal experience vs parroted from a hivemind, etc). This tends to correlate surprisingly accurately to how much autonomy and growth they demonstrate on the job. "Hardcore" DSA evaluation only really comes in as a criteria to determine whether the candidate is of very high quality when most other criteria have already been evaluated as acceptable/desirable. These nice-to-have criteria come into play in some cases where I want to advocate for the candidate when the evaluation panel is split due to one seemingly bad session (possibly due to factors such as nervousness or mixed signals), or inversely when the role logically demands a higher bar but the panel is situationally incentivized to hire down to meet a quota. I've been told by several candidates that they appreciate my interviewing style, and conversely, I feel like I get a much better feel for the candidate than strictly evaluating DSA skills and nothing else.

jerf 5y ago

What is unique about "DSA style problems" that makes it that only through them you can see if they stuck with the problem, asked meaningful questions, etc.? Why not ask them real questions about the real sorts of things they're going to do, and through those see if they stuck with the problem, asked meaningful questions, etc.? DSA problems don't bring anything to the table here, because it's trivial to substitute them with something meaningful. I'd even go so far as to say that we work bizarrely hard at asking uselessly inappropriate questions. It is easier to ask questions related to the real job.

capitalsigma 5y ago
Most of the substitutes you might want to pick are specific to a particular domain (webdev, for example). If you run a big company, you want to give a generic interview that gives you signal on a candidate's fit with a wide variety of teams that touch many domains. So you abstract away the domain-specific parts of the task until you have something that is broad enough to apply to many subdomains... and now you're doing DSA interviews, because DSA is exactly the bits of coding that are generic, abstract, and applicable to many domains.
- jerf 5y ago
  Just is in programming, if you've abstracted away to the point that you're no longer even doing the task you started with, you've failed. I don't care that you really really want a solution to P = NP; you can't have it. If you try to force it, you will pay the consequences. I don't care that you really really want a single standardized interview for what is essentially several dozen distinct positions, even if they all "use computers". You can't have it. If you try to force it, you will pay the consequences. If you suggested that companies should have completely standardized interviews for salespeople, lawyers, and executives, all because they "talk to people", you'd be laughed at. Change it to "talking to computers" and they lose the thread.
bluGill 5y ago
The meaningful question for most DSA problems "does my standard library already have an an algorithm for this?", if no the proper follow up is "okay, I need to head to my library for a few hours to research if there is a known answer that I can copy - will I be given time to propose the addition of the algorithm to my languages standard library so nobody else needs to do this again?" I don't want someone write an algorithm in a couple hours, I want someone to write the one implementation that is correct. Now sometimes there are compromises in algorithms (I can think of 3 different nlogn sorting algorithms and I think I've forgotten a dozen more) and so the company has a propitiatory library that has an implementation with different compromises. They should have benchmarks and pros and cons written down (ad ideally be open source) so that anytime someone asks about the algorithm they can point out why they have their own and possibly contribute it to the standard library if everyone agrees to a different compromise. These days that vast majority of the simple algorithms have already been written. I might need someone to design a more complex algorithm, but they either takes months of thought, or are just a sequence of simple algorithms.

carom 5y ago

In reality though, you learn how to solve a bunch of categories of problems on your own time, then put on a show where you go from the naive solution to the correct one. It's not as if someone is going to figure out dynamic programming during the interview, and once you know those concepts it is pretty apparent where to apply them. Honestly, I probably wouldn't even come up with the trick for the 3sum problem during an interview. Maybe I am dumb or maybe this is common, but the only reason I pass is because I've done the leetcode grind. The interview is just performative.