4 ms·

Okay, let's start with the obvious one-- why do you believe focusing on excruciatingly difficult algorithmic problems totally unrelated to the work you do is a

Okay, let's start with the obvious one-- why do you believe focusing on excruciatingly difficult algorithmic problems totally unrelated to the work you do is a good way of finding people?

philjohn 7y ago
Not OP, but it's often not about seeing you get a perfect solution straight away, they're judging your problem solving skills - how do you approach something you've probably never seen before. Do you choke? Do you break the problem up into smaller sub-problems?
- ericd 7y ago
  I understand the idea behind it, I just don't think "not choking when asked to code in a stressful situation" correlates well to "being able to design and write functional and maintainable software that maps well to customer and company needs". If the devs at your company need to put out fires constantly, then maybe it's a good test of whether they'll be able to do that.
  - karatestomp 7y ago
    I think a good tell is that when I want to practice for interviews, what I do looks very little like what I do to actually get better at my job. The hands-down most effective ways to practice for it don't much resemble legitimate continuing professional education (i.e. drilling leetcode on physical whiteboards) and, if they help me get better at my job, it's only marginally so and essentially by accident.
- andrewflnr 7y ago
  People who say "oh, I just want to see how you approach the super-hard problem" are often the first to comment on threads like this, but the experiences of OP and others seem to indicate that most interviewers expect you to actually finish or GTFO.
  - deanCommie 7y ago
    It's a bit of both 1) The companies that do this interview a TON, so there are bound to be bad experiences, and those are the ones that people blog about 2) The questions are supposed to be hard, but achievable. So you get two scenarios: A/ candidates who are not good enough and are not aware of it. "How am I supposed to know if the hashmap/dicationary data structure in the language I say I'm best at maintains insertion order? I just google that every time - everyone does!". Sorry, bucko. That's the kind of in-depth understanding of your tools that we DO expect you to give a shit about B/ Immature interviewers with a bar that's too high that are using overly complex questions and don't get noticed right away by the more experienced interviewers. So ultimately, YEAH, the questions I ask, for me to want to move forward with a candidate, I expect you to solve the problem. But I'm not expecting you to solve it in the most efficient way or GTFO
deanCommie 7y ago
Because we want to find the best people at solving difficult problems with limited time, and maximum ambiguity. At a high level that reflects the work that we do. The project scale may be 20 weeks instead of 20 minutes, but the level of complexity is scaled accordingly. Of course, we miss out on some candidates that could be great at executing on a large timeline but can't demonstrate it in a short in person interview. But, (see my edit), this is all we can do to scale our interview process, and we don't want to take risks.
- throway1n 7y ago
  this is so wrong i cant believe i am reading it. solving imaginary problems is not the same as being good at your job as an engineer. if google expects people to solve issues at a machine gun rate, it means google wants brick layers that lay bricks constantly. not people who need to stop and think about design issues over time. it wants workers to implement poorly sketched requirements and execute instructions on the assembly line. i look more after how people approach problems at a high level, where they show how they build the whole system and how they interact with peers and other departments to tell if they can gather data, organise it in specs, and then fine tune nicely build parts of a system. not code monkeys.
  - deanCommie 7y ago
    Yeah, you're right, Google and Amazon hire a bunch of brick layers that can't design a long term sustainable system... Come on man
    - throway1n 7y ago
      thats like saying everyone in the ford factory is hired to design vehicles. some of the bunch are just workers implementing instructions. i interviewed a few ex google, yahoo and amazon and they were exactly that.
      - deanCommie 7y ago
        A few out of tens of thousands will sneak through, especially if they got managed out of couldn't hack it. The vast majority at the FAANGs are full stack engineers which includes long term system design. The comparison to a car assembly factory is so ridiculously out of alignment with reality that I can see why you chose to go with a throwaway account.

Okay, let's start with the obvious one-- why do you believe focusing on excruciatingly difficult algorithmic problems totally unrelated to the work you do is a good way of finding people?

philjohn 7y ago

Not OP, but it's often not about seeing you get a perfect solution straight away, they're judging your problem solving skills - how do you approach something you've probably never seen before. Do you choke? Do you break the problem up into smaller sub-problems?

ericd 7y ago
I understand the idea behind it, I just don't think "not choking when asked to code in a stressful situation" correlates well to "being able to design and write functional and maintainable software that maps well to customer and company needs". If the devs at your company need to put out fires constantly, then maybe it's a good test of whether they'll be able to do that.
- karatestomp 7y ago
  I think a good tell is that when I want to practice for interviews, what I do looks very little like what I do to actually get better at my job. The hands-down most effective ways to practice for it don't much resemble legitimate continuing professional education (i.e. drilling leetcode on physical whiteboards) and, if they help me get better at my job, it's only marginally so and essentially by accident.
andrewflnr 7y ago
People who say "oh, I just want to see how you approach the super-hard problem" are often the first to comment on threads like this, but the experiences of OP and others seem to indicate that most interviewers expect you to actually finish or GTFO.
- deanCommie 7y ago
  It's a bit of both 1) The companies that do this interview a TON, so there are bound to be bad experiences, and those are the ones that people blog about 2) The questions are supposed to be hard, but achievable. So you get two scenarios: A/ candidates who are not good enough and are not aware of it. "How am I supposed to know if the hashmap/dicationary data structure in the language I say I'm best at maintains insertion order? I just google that every time - everyone does!". Sorry, bucko. That's the kind of in-depth understanding of your tools that we DO expect you to give a shit about B/ Immature interviewers with a bar that's too high that are using overly complex questions and don't get noticed right away by the more experienced interviewers. So ultimately, YEAH, the questions I ask, for me to want to move forward with a candidate, I expect you to solve the problem. But I'm not expecting you to solve it in the most efficient way or GTFO

deanCommie 7y ago

Because we want to find the best people at solving difficult problems with limited time, and maximum ambiguity. At a high level that reflects the work that we do. The project scale may be 20 weeks instead of 20 minutes, but the level of complexity is scaled accordingly. Of course, we miss out on some candidates that could be great at executing on a large timeline but can't demonstrate it in a short in person interview. But, (see my edit), this is all we can do to scale our interview process, and we don't want to take risks.

throway1n 7y ago
this is so wrong i cant believe i am reading it. solving imaginary problems is not the same as being good at your job as an engineer. if google expects people to solve issues at a machine gun rate, it means google wants brick layers that lay bricks constantly. not people who need to stop and think about design issues over time. it wants workers to implement poorly sketched requirements and execute instructions on the assembly line. i look more after how people approach problems at a high level, where they show how they build the whole system and how they interact with peers and other departments to tell if they can gather data, organise it in specs, and then fine tune nicely build parts of a system. not code monkeys.
- deanCommie 7y ago
  Yeah, you're right, Google and Amazon hire a bunch of brick layers that can't design a long term sustainable system... Come on man
  - throway1n 7y ago
    thats like saying everyone in the ford factory is hired to design vehicles. some of the bunch are just workers implementing instructions. i interviewed a few ex google, yahoo and amazon and they were exactly that.
    - deanCommie 7y ago
      A few out of tens of thousands will sneak through, especially if they got managed out of couldn't hack it. The vast majority at the FAANGs are full stack engineers which includes long term system design. The comparison to a car assembly factory is so ridiculously out of alignment with reality that I can see why you chose to go with a throwaway account.