I do think some people at FB/Google need to know this stuff cold, but even that isn't going to be 100% of their engineers.
I do think some people at FB/Google need to know this stuff cold, but even that isn't going to be 100% of their engineers.
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.
+1
* 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.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.
Source: worked with multiple Math PhDs. Have a few friends who are Math PhD working on some esoteric problems that I could not understand.
Minimizing the CPU and memory usage of your application is engineering more than science; however, doing it requires a lot of CS knowledge.