5 ms·
And then when you get the job, you will likely never use this skill again. 50% of your time will be spent on plumbing and wiring, 40% on meetings and politics
by cle 10y ago
And then when you get the job, you will likely never use this skill again. 50% of your time will be spent on plumbing and wiring, 40% on meetings and politics and "agile processes", 9% on learning new ways to plumb and wire, and maybe 1% of your time will utilize these sorts of skills that can otherwise be identified from afar and solved by looking up in a book.
Once you get your foot in the door, this sort of trivia becomes vastly less important than your ability to impress the right people and politically maneuver yourself into winning situations. This is the reality of life in a mega tech corp.
- snovv_crash 10y agoThat, of course, depends where you work. My daily work is math intensive and performance critical. I constantly need to think about cache sizes, big-O scaling and that ever-important constant factor. I've seen commits failed by QA because they inadvertently added a shared_ptr copy in a tight loop, which affected performance of the entire pipeline by 20%. So yeah, I regularly have to think about dynamic programming, switching away from a linear low-constant algorithm once the problem is no longer small, how something could be restructured to be massively parrellizable, even alignment of arrays so that we get reasonable SIMD performance. Yes, these jobs exist, and yes, they do require a strong algorithms background, as well as a good understanding of memory heirarchy, branching delays and what can be offloaded to GPU or at least parallized.
- hal9000xp 10y agoYour job sounds exciting! Do you work in gamedev? In which company you are working?
- snovv_crash 10y agoComputer vision late-stage startup, 80+ people now I think, of which 50 are devs. Of course not everyone does what I do, we still need people to work on the UI and packaging/licences etc. But at least 50% of the devs here do very research-oriented work.
- Silhouette 10y agoMy daily work is math intensive and performance critical. I constantly need to think about cache sizes, big-O scaling and that ever-important constant factor. Me too, at least for some of the projects I'm working on, but it's probably fair to say that I've never used most of the "textbook algorithms" I've come across over the years in a production system. The interesting and challenging problems are mostly the ones that aren't just a direct application of such an algorithm. Consequently, I think the more valuable ability is recognising when a part of such a problem probably does have a standard solution, so you can spend a few minutes looking up the current state of the art. Obviously you still need enough familiarity with the theory in the areas you're working in for that recognition to work, and then to understand the current state of the art when you need it.
- majormajor 10y ago> That, of course, depends where you work. Small correction: it depends on what problems you work on. There are people at top companies making big money working on complex problems, there are also people at those companies who passed through a super-algorithm-heavy interview and work on much less mathematically demanding code. And there are people at small companies you've never heard of working on much more intense problems than them. But the people doing boring work at big companies are often making $$$ compared to the people working at small companies working on interesting stuff. (I've been both of those people...)
- threatofrain 10y agoIn terms of business, I question whether most companies have the financial justification to implement math heavy software strategies, or novel strategies. For many businesses, I wonder if their software requirements are generally boring with many parts of their problem already solved and implemented in the form of a framework, with a few libraries waiting to be glued together. I also have the suspicion that for companies such as Cloudflare, where there is justification to implement either novel or math-heavy strategies, these kinds of companies trust very few people to make the business and technical judgment call to pursue a strategy aside from simply using off-the-shelf solutions. But a lot of people may be screened on these matters without the company ever intending to take advantage of the abilities they test for. I really wonder how often Google takes advantage, or even trusts their employees, to make such decisions or exercise such abilities, as opposed to a few superstar Googlers.
- a_imho 10y agoSoftware in a nutshell. The 'can you invert a binary tree' coming of age ritual one studies so hard for. You know it will happen before you step into the interview room and there's no escaping it, but you go in nevertheless.
- alkonaut 10y agoAvoid programming with databases and web servers and the plumbing and repetitive crud work can be minimized. Pick a math intensive and performance sensitive domain and interesting algorithmic problems like these pop up all the time.
- 1_2__3 10y agoGoogle doesn't use agile. Specifically to avoid the kind of nonsense you cite.
- ausjke 10y agobut you still need write them for interview purposes, it is the first step to filter out candidates, no matter how senior you are I think.