4 ms·

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 yo

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

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