4 ms·

Agreed. I think there's a tinge of arrogance to the claim that Google/FB/what have you need The Best(tm) while everyone else does not. The reality is that ther

Agreed. I think there's a tinge of arrogance to the claim that Google/FB/what have you need The Best(tm) while everyone else does not. The reality is that there are some jobs (a small minority) at these companies that require incredibly deep algorithmic knowledge - they really do do some complicated things. But the majority of jobs at TwitGooFace are your run of the mill programming jobs, where the requirement and the reality don't call for anyone at that level, and hiring someone at that level is just going to make them bored. Indeed, the vast majority of people I know at these companies aren't algorithmic encyclopedia, they're just solidly competent engineers. Having worked at a "AAA" tech giant and many more places across the country, I'm happy to report that for the most part there's nothing exceptional about Silicon Valley jobs and what they require. For the most part, barring a minority of highly specialized high-level positions, engineering ability trumps computer science knowledge.

mgkimsal 13y ago
"For the most part, barring a minority of highly specialized high-level positions, engineering ability trumps computer science knowledge." +1
- RogerL 13y ago
  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.
  - mgkimsal 13y ago
    +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.
TylerE 13y ago
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.
- samatman 13y ago
  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.
- smm2000 13y ago
  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.
  - cmbaus 13y ago
    I think you are drawing conclusions from a small sample size. I've had the exact opposite experience.
  - taybin 13y ago
    They can do the algorithms, but they don't engineer, imho.
ahomescu1 13y ago
> 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.

mgkimsal 13y ago

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

RogerL 13y ago
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.
- mgkimsal 13y ago
  +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.

TylerE 13y ago

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.

samatman 13y ago
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.
smm2000 13y ago
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.
- cmbaus 13y ago
  I think you are drawing conclusions from a small sample size. I've had the exact opposite experience.
- taybin 13y ago
  They can do the algorithms, but they don't engineer, imho.

ahomescu1 13y ago

> 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.