4 ms·

This could be a good question for interviews. A good candidate should be able to come up with several solutions for implementing strings, and explain the pros a

by ishi 8y ago

This could be a good question for interviews. A good candidate should be able to come up with several solutions for implementing strings, and explain the pros and cons of each solution.

sifoobar 8y ago
A good candidate for what? I've been through enough interviews on both sides. The only thing that will tell you anything of importance is paying candidates to perform real tasks. If doing algorithms on a whiteboard is part of the job; then sure, go for it. But I suspect very few of the really good coders out there would make much of an impression in that setting.
- macintux 8y ago
  I think if you modify it to simply state that having a candidate think out loud about mechanisms for storing strings is a useful exercise in evaluating their problem solving ability, it’s a pretty good idea. I’m rarely concerned about the right answer in an interview, because those are generally searchable.
  - sifoobar 8y ago
    But it's still pretending, solving canned problems with right/wrong answers is not the same as doing the real thing. You'll get completely different behaviors out of most people. I wouldn't be surprised if plenty of whiteboard surfers and sweet talkers turn out to be less than ideal under pressure when there are no clear answers and no authority to back them up.
    - macintux 8y ago
      Thankfully I’m rarely hiring for positions where someone is developing software with a gun to their head.
- alkonaut 8y ago
  I want to hear a candidates train of thought. I want to see their ability to reason about multiple solutions and weighing their benefits and drawbacks. The problem at hand should be something trivial - no whiteboard algorithms - so that the solutions themselves come easily (or may even be provided), the important thing is to test the ability to reason about things like difficulty of implementation performance, etc. “Just doing real world stuff” might be another useful but separate part of an interview.
  - sifoobar 8y ago
    I get what you want, it's the same thing everyone else wants. That doesn't imply it's possible to get it. What we're doing is pretending it works, it's not the same thing. When I'm working on solving real problems, I'll come up with ideas that make your head spin. Put me in front of a whiteboard and feed me canned problems with right/wrong answers and you won't ever see me again.
    - alkonaut 8y ago
      I would never ever have s whiteboard or even an editor in an interview. Arguing the difference between zero termination and length prefixing is a ”real problem” of the kind I have to face multiple times on a daily basis. Also, solving problems without considering all the (or at least multiple) solutions isn’t really a very useful skill. That said, all this varies by the role. If I was hiring a contractor position or regular web dev then “solving the problem” is an essential skill and solution bikeshedding might not be. But I’m hiring developers for low-ish level work on lib style code with 30 year maintenance windows. It’s radically different from creating a web stack with maybe a 5 or 10 year total lifespan.
- kazinator 8y ago
  A good candidate for ... maintaining the legacy flagship product, in which N software components each contribute their own string implementations, and there is N+1th module implementing conversions from any of those strings to any other.
  - sifoobar 8y ago
    God bless his/her soul :)
scarface74 8y ago
The prototypical full stack software as a service web developer or the standard in house bespoke application writer that knew how to implement a string wouldn’t tell me anything about how they can design or write real world systems. If their day to day job is solving hard problems at scale then maybe. But most companies overestimate the complexity of what they are really doing. What would tell me how they write real world systems - and how I interview - is to give them a simple real world skeleton of a problem with failing unit tests, sit them down to a computer and make them make the tests pass. If I am hiring an architect level position, I am not going to have then write algorithms on a board. I am going to do the same set of tests as above and have them design a scalable, fault tolerant system and have them draw it out.

by ishi 8y ago

This could be a good question for interviews. A good candidate should be able to come up with several solutions for implementing strings, and explain the pros and cons of each solution.

sifoobar 8y ago

A good candidate for what? I've been through enough interviews on both sides. The only thing that will tell you anything of importance is paying candidates to perform real tasks. If doing algorithms on a whiteboard is part of the job; then sure, go for it. But I suspect very few of the really good coders out there would make much of an impression in that setting.

macintux 8y ago
I think if you modify it to simply state that having a candidate think out loud about mechanisms for storing strings is a useful exercise in evaluating their problem solving ability, it’s a pretty good idea. I’m rarely concerned about the right answer in an interview, because those are generally searchable.
- sifoobar 8y ago
  But it's still pretending, solving canned problems with right/wrong answers is not the same as doing the real thing. You'll get completely different behaviors out of most people. I wouldn't be surprised if plenty of whiteboard surfers and sweet talkers turn out to be less than ideal under pressure when there are no clear answers and no authority to back them up.
  - macintux 8y ago
    Thankfully I’m rarely hiring for positions where someone is developing software with a gun to their head.
alkonaut 8y ago
I want to hear a candidates train of thought. I want to see their ability to reason about multiple solutions and weighing their benefits and drawbacks. The problem at hand should be something trivial - no whiteboard algorithms - so that the solutions themselves come easily (or may even be provided), the important thing is to test the ability to reason about things like difficulty of implementation performance, etc. “Just doing real world stuff” might be another useful but separate part of an interview.
- sifoobar 8y ago
  I get what you want, it's the same thing everyone else wants. That doesn't imply it's possible to get it. What we're doing is pretending it works, it's not the same thing. When I'm working on solving real problems, I'll come up with ideas that make your head spin. Put me in front of a whiteboard and feed me canned problems with right/wrong answers and you won't ever see me again.
  - alkonaut 8y ago
    I would never ever have s whiteboard or even an editor in an interview. Arguing the difference between zero termination and length prefixing is a ”real problem” of the kind I have to face multiple times on a daily basis. Also, solving problems without considering all the (or at least multiple) solutions isn’t really a very useful skill. That said, all this varies by the role. If I was hiring a contractor position or regular web dev then “solving the problem” is an essential skill and solution bikeshedding might not be. But I’m hiring developers for low-ish level work on lib style code with 30 year maintenance windows. It’s radically different from creating a web stack with maybe a 5 or 10 year total lifespan.
kazinator 8y ago
A good candidate for ... maintaining the legacy flagship product, in which N software components each contribute their own string implementations, and there is N+1th module implementing conversions from any of those strings to any other.
- sifoobar 8y ago
  God bless his/her soul :)

scarface74 8y ago

The prototypical full stack software as a service web developer or the standard in house bespoke application writer that knew how to implement a string wouldn’t tell me anything about how they can design or write real world systems. If their day to day job is solving hard problems at scale then maybe. But most companies overestimate the complexity of what they are really doing. What would tell me how they write real world systems - and how I interview - is to give them a simple real world skeleton of a problem with failing unit tests, sit them down to a computer and make them make the tests pass. If I am hiring an architect level position, I am not going to have then write algorithms on a board. I am going to do the same set of tests as above and have them design a scalable, fault tolerant system and have them draw it out.