6 ms·

> Candidates who have learned DP in school usually find them really easy, and candidates who haven't usually don't even have a chance at solving them is direct

> Candidates who have learned DP in school usually find them really easy, and candidates who haven't usually don't even have a chance at solving them is directly related to > DP comes up almost never in the real world If you haven't studied DP at school, done competitive programming, or Leetcoded for interview prep you are not likely to have encountered it doing everyday work. And even naturally talented coders are going to struggle with unfamiliar types of problems. Unfortunately, I don't see a way out of this. It's probably true that programmers who are good at solving DP problems are generally quite good, which is why DP problems get asked at interviews. It's a good signal for ability to learn difficult things, which is a desirable quality in employees. This means that good programmers who don't know DP are forced to learn it or accept that they won't clear some interviews. Absent some other way to clearly signal technical ability, I think DP problems are here to stay.

groby_b 8y ago
> It's probably true that programmers who are good at solving DP problems are generally quite good, which is why DP problems get asked at interviews. Yeah, no. (Source: I've seen a few interviews in my time. On the order of 5k of them) DP problems are absolute shit at giving a signal, even if the candidate knows DP problems. Because "knows DP" is pretty much the only bit of information you get, with possibly a slight seasoning of "doesn't write utterly horrible code". The reason they're asked is the reason most interview questions are asked: The interviewer picked them up somewhere, is now familiar with them, and will ask it till the cows come home. (It also allows you to feel all smart and academic when asking it, but that's rarely if ever the main motivation) Here's an entirely novel concept for evaluating if somebody can write code that solves actual problems. We could ask people to, IDK, write code that solves actual problems. They're there for a day. A good coder can solve some pretty interesting problems in a day. I know, I know. Heresy. Who'd ever evaluate people by looking at how they do their actual work if you can instead recite shibboleths on a whiteboard? (Yes, I'm bitter about the tech interview process)
- brianberns 8y ago
  > Here's an entirely novel concept for evaluating if somebody can write code that solves actual problems. We could ask people to, IDK, write code that solves actual problems. They're there for a day. A good coder can solve some pretty interesting problems in a day. You mean solve an actual business problem that the interviewing company has? The ramp-up time to be productive in any real business that I've been associated with is significantly greater than the time available in a single interview (usually an hour or so). This is why toy problems are used. Another issue is that it's not really fair to ask an interviewee to solve your company's problems for free. In fact, without some sort of contract, the interviewee technically owns her own work, so even if she manages to solve a real problem, the company really shouldn't use it. (BTW, 5K interviews at one hour per interview is 625 eight-hour workdays. Assuming 50 work weeks of five days each in a year, that's 2.5 work years devoted to nothing but interviewing in your career. Yes?)
  - pmiller2 8y ago
    Not an actual problem the company has, but a pared down version of a problem the company had.
    - brianberns 8y ago
      Easier said than done. You probably end up with something that's essentially a toy problem anyway.
  - groby_b 8y ago
    Thankfully not 2.5 work years. See above for explanation. Probably around 0.5 work years, smeared over almost a decade. And no, not an actual business problem, a constructed problem. But in the same domain. (See other comment above)
- jogjayr 8y ago
  > I've seen a few interviews in my time. On the order of 5k of them) That's actually pretty cool. May I ask how? > Because "knows DP" is pretty much the only bit of information you get Yes if the candidate meets with only one interviewer or if every interviewer asks only DP. I hope most companies don't interview that way - that would truly be a broken interview process. Obviously you ask about other stuff in the other interviews. > The interviewer picked them up somewhere, is now familiar with them, Lol, isn't that one reason every interview question is asked? I've never asked a question whose answer I wasn't familiar with. I know how you meant that though. There are plenty of companies that don't do whiteboard problems or ask DP. Here's a few: https://github.com/poteto/hiring-without-whiteboards https://github.com/poteto/hiring-without-whiteboards > We could ask people to, IDK, write code that solves actual problems It's pretty hard to get someone solving actual problems in a single day. Do you have some examples of how this might be done?
  - pmiller2 8y ago
    On a lot of companies’ interview loops, if one interviewer says “no hire,” it’s an overall “no hire.” If that person is asking DP, and you don’t know it, then you will fail the whole interview.
  - nosianu 8y ago
    > It's pretty hard to get someone solving actual problems in a single day. Do you have some examples of how this might be done? Solve a small problem - of which millions can be found in issue trackers. Here is an example I just read on Github: Somebody reports that reading a JSON file results in a value that clearly is an integer being misidentified as "Not an integer". The source code is a parser written in C and the code is quite readable. Give the candidate an hour to try to figure out what is happening (obviously, the language and context must be a match for the job). Important - I think: It would be good if the problem is unsolved and the interviewer him-/herself does not know the answer. Also: Don't send them into a room alone, watch them. I know that adds stress, but learn how to lower it, make it clear you too don't know the answer. If the candidate really can't cope with someone watching, well, okay, let them try alone, I just think if the atmosphere is right this is valuable. There is no right way to approach solving such a problem, but without and not meant for judgment, I think this is just interesting to see how different people approach problems. Of course, if the interviewer has string opinions about how it should be done that is a bad method and I myself would not like to be interviewee in that case.
- lawn 8y ago
  I was in a team with a very talented competitive programmer guy. He came up with solutions for some pretty tough problems I couldn't wrap my head around. Fantastic programmer right? The other 99% except hardcore algorithmic optimizations, like structuring code, creating simple code, naming variables, splitting code into classes/functions and refactoring? No clue about any of that. All he produced was "read-only" and had many glaring problems. It wasn't only during competitions either, he used the same style for assignments. Turns out he got shafted by the assistants and then he copied answers from another student (yes he got caught).
  - blackflame7000 8y ago
    At my first company, there was this one file in the solution that we called DaVinci.cpp because it was over 20000 lines long and written by one developer who had long since retired. The thing is, the code was complex and worked so no one ever refactored it.
  - jogjayr 8y ago
    > The other 99% except hardcore algorithmic optimizations, like structuring code, creating simple code, naming variables, splitting code into classes/functions and refactoring? No clue about any of that. So...you're saying a student wrote code like...a student? Color me shocked. You can coach talented programmers to write neat code, design classes, and name their variables right. It's part of turning a junior engineer into a senior engineer. It's far harder to teach someone how to solve programming problems.
- 52-6F-62 8y ago
  > Here's an entirely novel concept for evaluating if somebody can write code that solves actual problems. We could ask people to, IDK, write code that solves actual problems. They're there for a day. A good coder can solve some pretty interesting problems in a day. My last interview was structured like this. Remote. Able to work on it outside of work hours (so no missed office days). Tracked a shared repo. Was paid a retainer up front for n hours worked on the task at an agreed-upon hourly rate. Needless to say it was a great experience. I've also had interviews in the past where the interviewer didn't have the correct answer to a question they asked me, and just got confused when I tried to explain my answer more fully. In the end they said I was incorrect, due to their incorrect answer (that they must have taken down from another source). I didn't get that job. Probably for the best. There are also some people who just shouldn't be interviewing others. They just don't have the emotional intelligence to manage the situation.
- wildmanx 8y ago
  > I've seen a few interviews in my time. On the order of 5k of them) Sorry, your "5k" doesn't pass the smell test, unless you can give some convincing reason why 20 years of one interview per day would be believable. So, I'm calling BS. You just seem bitter about interviews that you don't like and are trying to con people into giving your opinion more weight than that of others. Besides, if other companies are doing interviewing "wrong" as you think, then just do it "right" in yours and have a competitive edge by hiring all those brilliant coders that other companies are too stupid recognizing. That would be a reason for you to be joyful instead of bitter, no?
  - groby_b 8y ago
    If you interview at a traditional tech company, you go through 5-8 interviews in a day. If somebody were to review, say, around 4 of these packets every week, they see about 20-30 interviews every week. That's ~1000-1500 a year. The 5K mark comes faster than you think. And if you work at a company that size, changing the interview process is a bit more work than "oh, we just won't do that". Not everybody works at a small startup.
blackflame7000 8y ago
It's not like DP is the only way to solve problems even designed for a DP solution. So an interviewee might have a general technique that applies for most problems but when faced with a DP problem their method takes more time. Now in an interview, taking more time is generally bad and this candidate would be judged lower. However, in real life scenarios, since DP problems are so rare, the interviewee's method might actually be faster. Basically, giving any test question that is dependent on someone knowing something they could look up in a book is not as effective as testing how well someone reasons about an unknown type of problem.

groby_b 8y ago

> It's probably true that programmers who are good at solving DP problems are generally quite good, which is why DP problems get asked at interviews. Yeah, no. (Source: I've seen a few interviews in my time. On the order of 5k of them) DP problems are absolute shit at giving a signal, even if the candidate knows DP problems. Because "knows DP" is pretty much the only bit of information you get, with possibly a slight seasoning of "doesn't write utterly horrible code". The reason they're asked is the reason most interview questions are asked: The interviewer picked them up somewhere, is now familiar with them, and will ask it till the cows come home. (It also allows you to feel all smart and academic when asking it, but that's rarely if ever the main motivation) Here's an entirely novel concept for evaluating if somebody can write code that solves actual problems. We could ask people to, IDK, write code that solves actual problems. They're there for a day. A good coder can solve some pretty interesting problems in a day. I know, I know. Heresy. Who'd ever evaluate people by looking at how they do their actual work if you can instead recite shibboleths on a whiteboard? (Yes, I'm bitter about the tech interview process)

brianberns 8y ago
> Here's an entirely novel concept for evaluating if somebody can write code that solves actual problems. We could ask people to, IDK, write code that solves actual problems. They're there for a day. A good coder can solve some pretty interesting problems in a day. You mean solve an actual business problem that the interviewing company has? The ramp-up time to be productive in any real business that I've been associated with is significantly greater than the time available in a single interview (usually an hour or so). This is why toy problems are used. Another issue is that it's not really fair to ask an interviewee to solve your company's problems for free. In fact, without some sort of contract, the interviewee technically owns her own work, so even if she manages to solve a real problem, the company really shouldn't use it. (BTW, 5K interviews at one hour per interview is 625 eight-hour workdays. Assuming 50 work weeks of five days each in a year, that's 2.5 work years devoted to nothing but interviewing in your career. Yes?)
- pmiller2 8y ago
  Not an actual problem the company has, but a pared down version of a problem the company had.
  - brianberns 8y ago
    Easier said than done. You probably end up with something that's essentially a toy problem anyway.
- groby_b 8y ago
  Thankfully not 2.5 work years. See above for explanation. Probably around 0.5 work years, smeared over almost a decade. And no, not an actual business problem, a constructed problem. But in the same domain. (See other comment above)
jogjayr 8y ago
> I've seen a few interviews in my time. On the order of 5k of them) That's actually pretty cool. May I ask how? > Because "knows DP" is pretty much the only bit of information you get Yes if the candidate meets with only one interviewer or if every interviewer asks only DP. I hope most companies don't interview that way - that would truly be a broken interview process. Obviously you ask about other stuff in the other interviews. > The interviewer picked them up somewhere, is now familiar with them, Lol, isn't that one reason every interview question is asked? I've never asked a question whose answer I wasn't familiar with. I know how you meant that though. There are plenty of companies that don't do whiteboard problems or ask DP. Here's a few: https://github.com/poteto/hiring-without-whiteboards https://github.com/poteto/hiring-without-whiteboards > We could ask people to, IDK, write code that solves actual problems It's pretty hard to get someone solving actual problems in a single day. Do you have some examples of how this might be done?
- pmiller2 8y ago
  On a lot of companies’ interview loops, if one interviewer says “no hire,” it’s an overall “no hire.” If that person is asking DP, and you don’t know it, then you will fail the whole interview.
- nosianu 8y ago
  > It's pretty hard to get someone solving actual problems in a single day. Do you have some examples of how this might be done? Solve a small problem - of which millions can be found in issue trackers. Here is an example I just read on Github: Somebody reports that reading a JSON file results in a value that clearly is an integer being misidentified as "Not an integer". The source code is a parser written in C and the code is quite readable. Give the candidate an hour to try to figure out what is happening (obviously, the language and context must be a match for the job). Important - I think: It would be good if the problem is unsolved and the interviewer him-/herself does not know the answer. Also: Don't send them into a room alone, watch them. I know that adds stress, but learn how to lower it, make it clear you too don't know the answer. If the candidate really can't cope with someone watching, well, okay, let them try alone, I just think if the atmosphere is right this is valuable. There is no right way to approach solving such a problem, but without and not meant for judgment, I think this is just interesting to see how different people approach problems. Of course, if the interviewer has string opinions about how it should be done that is a bad method and I myself would not like to be interviewee in that case.
lawn 8y ago
I was in a team with a very talented competitive programmer guy. He came up with solutions for some pretty tough problems I couldn't wrap my head around. Fantastic programmer right? The other 99% except hardcore algorithmic optimizations, like structuring code, creating simple code, naming variables, splitting code into classes/functions and refactoring? No clue about any of that. All he produced was "read-only" and had many glaring problems. It wasn't only during competitions either, he used the same style for assignments. Turns out he got shafted by the assistants and then he copied answers from another student (yes he got caught).
- blackflame7000 8y ago
  At my first company, there was this one file in the solution that we called DaVinci.cpp because it was over 20000 lines long and written by one developer who had long since retired. The thing is, the code was complex and worked so no one ever refactored it.
- jogjayr 8y ago
  > The other 99% except hardcore algorithmic optimizations, like structuring code, creating simple code, naming variables, splitting code into classes/functions and refactoring? No clue about any of that. So...you're saying a student wrote code like...a student? Color me shocked. You can coach talented programmers to write neat code, design classes, and name their variables right. It's part of turning a junior engineer into a senior engineer. It's far harder to teach someone how to solve programming problems.
52-6F-62 8y ago
> Here's an entirely novel concept for evaluating if somebody can write code that solves actual problems. We could ask people to, IDK, write code that solves actual problems. They're there for a day. A good coder can solve some pretty interesting problems in a day. My last interview was structured like this. Remote. Able to work on it outside of work hours (so no missed office days). Tracked a shared repo. Was paid a retainer up front for n hours worked on the task at an agreed-upon hourly rate. Needless to say it was a great experience. I've also had interviews in the past where the interviewer didn't have the correct answer to a question they asked me, and just got confused when I tried to explain my answer more fully. In the end they said I was incorrect, due to their incorrect answer (that they must have taken down from another source). I didn't get that job. Probably for the best. There are also some people who just shouldn't be interviewing others. They just don't have the emotional intelligence to manage the situation.
wildmanx 8y ago
> I've seen a few interviews in my time. On the order of 5k of them) Sorry, your "5k" doesn't pass the smell test, unless you can give some convincing reason why 20 years of one interview per day would be believable. So, I'm calling BS. You just seem bitter about interviews that you don't like and are trying to con people into giving your opinion more weight than that of others. Besides, if other companies are doing interviewing "wrong" as you think, then just do it "right" in yours and have a competitive edge by hiring all those brilliant coders that other companies are too stupid recognizing. That would be a reason for you to be joyful instead of bitter, no?
- groby_b 8y ago
  If you interview at a traditional tech company, you go through 5-8 interviews in a day. If somebody were to review, say, around 4 of these packets every week, they see about 20-30 interviews every week. That's ~1000-1500 a year. The 5K mark comes faster than you think. And if you work at a company that size, changing the interview process is a bit more work than "oh, we just won't do that". Not everybody works at a small startup.

blackflame7000 8y ago

It's not like DP is the only way to solve problems even designed for a DP solution. So an interviewee might have a general technique that applies for most problems but when faced with a DP problem their method takes more time. Now in an interview, taking more time is generally bad and this candidate would be judged lower. However, in real life scenarios, since DP problems are so rare, the interviewee's method might actually be faster. Basically, giving any test question that is dependent on someone knowing something they could look up in a book is not as effective as testing how well someone reasons about an unknown type of problem.