3 ms·

A plumber, sure. What about the guys who design your water heater? Should they just google the thermodynamics as they go as well? My point being, it depends on

• theli0nheart 10y ago
  Sure, it makes sense to ask a compiler engineer the various ways in which to reverse a binary tree. That's going to be a problem that you're probably going to encounter on the job. The fact is that most developers spend 90+% of their time futzing with NPM, dealing with Apple's review process, or renewing SSL certificates. Low-level algorithm work is something very few engineers need to know.
  • phn 10y ago
    I agree, like I said it depends on the position. But still, if the other 10% of the time is designing the system, it can wreck the project if you do a bad job at it. And no amount of futzing with NPM is going to save you, no matter how good you are at it. It also depends on if you want the guy to be more than a front-end bug-fixing guy in the long run.
• zerr 10y ago
  It comes from the point that the candidate is a lair (when we talk about hiring experienced pros). If someone in your company who is in charge of tech hiring is unable to tell if the candidate is laying about her past experience and projects - you should fire him in the first place (or at least keep him away from the hiring). So if you want to hire a "guy" to "design your water heater", ask him about the water heater he designed in the previous company, or a water cooler he designed for the neighbor community...
• Sir_Substance 10y ago
  >A plumber, sure. What about the guys who design your water heater? Should they just google the thermodynamics as they go as well? Honestly, regularly referring to the reference material as you need it rather than trying to remember or derive every single pressure equation off the top of your head sounds like a good idea when designing a potentially explosive boiler.
  • phn 10y ago
    I agree, I'm simply arguing the fundamentals must be somewhat present in your head in order for your research to be productive. Shifting to CS, how do you even know a specific algorithm/data structure might help with your problem if you don't have a rough idea of its specifics? It's easy to dismiss an example case as solving a maze, because that's been done to infinity. But real-world problems are rarely so cleanly defined.
    • Sir_Substance 10y ago
      >Shifting to CS, how do you even know a specific algorithm/data structure might help with your problem if you don't have a rough idea of its specifics? In general, these things are well implemented in either the base language or a library, and thus both easily searchable and well covered in practical examples. It's unusual for 9-to-5 non-R&D developers to be solving a problem which hasn't been solved before at the algorithm level, the job usually revolves around connecting pre-made components together and specializing them. As such, you really only need a loose knowledge of the fact that things like binary trees exist. Being able to hand-write one isn't useful and may be a liability depending on the temperament of the developer. Your hand-rolled implementation is unlikely to perform better by any metric than the pre-made one, and it'll probably be less platform independent and more buggy simply because it's newer and looked at by fewer people. In 95% of all software development today, rolling your own version of any off-the-shelf algorithm is a mugs game and actively bad practice because it places the foundations for technical debt. You really don't want to be hiring people who roll their own just because they can. Now, if you're going to be working in the R&D or experimental areas of software development, kind of where the Oculus driver crew are at the moment (as an example), then sure, you definitely need to know the inner details of these things. The problem is that we're interviewing everyone as if they're going to be writing high-performance drivers, when most of them are never going to work at that level and wouldn't want to.