Hacker News Reader

The thing is, that 0.1% would probably be better off just looking for a Math PhD. I suspect it is much easier to teach a mathematician C (Or Python/Haskell/OCaml/Java) than a programmer real math.

Math guy here, spent the last year writing high-performance ODE integrators that run on graphics cards. No formal background in CS at all. Hiring maths people to write performative algorithms is more common than not.

The problem is that Math PhDs tend to be arrogant and think that programming is for monkeys and they are above that. Code that they produce tends to be sub-par and under-tested (because they are above writing unit-tests).

Source: worked with multiple Math PhDs. Have a few friends who are Math PhD working on some esoteric problems that I could not understand.

I think you are drawing conclusions from a small sample size. I've had the exact opposite experience.

They can do the algorithms, but they don't engineer, imho.

"For the most part, barring a minority of highly specialized high-level positions, engineering ability trumps computer science knowledge."

+1

That is what gets me about these interview questions. I know a lot of very clever people. I am carefully differentiating 'clever' from 'smart', by the way. So many that are superficially fast and smart about solving whiteboard problems are terrible at all the things that actually seem to matter when it comes to creating value:

  * Keeping a project on budget and schedule
  * being able to create a budget
  * managing people and resources
  * Grinding out boring, but bug free code
  * Writing clean code
  * Being able to refactor
  * Design software that is maintainable
  * not tick off the people around you

SW engineering is a big, fuzzy, ill-defined optimization task in n-dimensional space. There are plenty of clever people that aren't very good at that sort of real-world iterative process. Sure, it is great to have a few people that can quote Knuth (if you don't know what algorithms are available, you'll often choose a substandard one), but by and large I want an engineer, not a scientist. A good one can learn red-black trees, or whatever, when it becomes necessary. The converse (a CS-y type person becoming productive in an engineering environment) seems less likely to occur, in my experience.

+1, and a bit more.

Yes... I ran a small group where we all got too inward focused being clever in our code and optimizations, all the while ignoring (for various reasons) that we had less income each month, and eventually folded.

I've since seen this firsthand at a couple other companies, on the inside and outside, where engineering types get way too focused on trying to hyperoptimize for a theoretically possible scenario X, while ignoring real world tickets that are costing them customers daily. They don't seem to realize that... when enough days pass, and enough customers leave, there is no more money to pay them.

Having lived through a couple failures (personal and professional), it's probably easier for me to spot these behaviors (again, because I used to do it myself). In my case, I wish I'd had someone early on beat that out of me - I simply wasn't aware of what was going on. As much as you can say "people have to learn for themselves", I don't believe that's the right attitude to take when the fate of a dept or company rides on what you're doing - too many other lives are involved.

This is in reaction to your 'budget' stuff above - I don't expect people to be Excel/Quickbooks/Peachtree gurus nor CPAs, but understand that you have to get stuff out, on time, and sometimes have to choose your battles and put out less than optimal code, then have a plan to address the known shortcomings.

I agree too on the CS adapting to engineering being more rare than engineering adapting to CS.

> For the most part, barring a minority of highly specialized high-level positions, engineering ability trumps computer science knowledge.

Minimizing the CPU and memory usage of your application is engineering more than science; however, doing it requires a lot of CS knowledge.