> This same exact argument could be used to require every interview candidate to know assembly. ...because knowing assembly is actually useful to a high level

> This same exact argument could be used to require every interview candidate to know assembly. ...because knowing assembly is actually useful to a high level developer? If it were, then yes, I'd say they should know assembly too. But I know assembly; I've written entire published games in assembly language. And yet I don't believe knowing it is actively useful any more. Knowing the basic concepts like how strings, integers, and floating point values are stored and compared, yes. You typically learn that as you're learning algorithms and data structures. But you can learn those concepts using C; actually knowing assembly language fluently is overkill today. So there's no slippery slope argument to be made here. > I find that developers who constantly get caught up in the performance of individual algorithms Straw-man. [1] Developers who understand how to optimize can, at the same time, make intelligent decisions on when to optimize. Developers who are overly focused on minutia that isn't important are solving the wrong problem, certainly. But part of the skill of optimization is knowing when to do it. The problem is that if you don't know how to optimize algorithms, if you don't understand big-O notation and its implications, then you won't really get how to optimize at either the individual algorithm level or at the system level. Because the concepts are the same across all the levels of complexity. Yes, some developers can get obsessed with optimizing the wrong things. That's why experienced developers will profile before spending a lot of time optimizing. But put a bunch of developers who ignore big-O together and you'll end up with code like the Quora app: If I delete a paragraph in the app it can take 10 seconds to finish deleting it. Sometimes the app will update once or twice with parts of the paragraph deleted. I'm not writing a book in the app; the N can't be more than a thousand or so for the entire answer. Even JavaScript can iterate over a thousand characters in milliseconds. My guess? They've accidentally used an O(n^3) algorithm where they delete one character at a time and copy the entire message, re-concatenating it every time. Experienced developers wouldn't even consider writing that code to begin with, instead using something like ropes when dealing with text that's being actively edited, because that's what you do with text in an editor. [2] There's even already a JavaScript implementation they could have used off the shelf [3] (I'm assuming that the app is hybrid and running in JavaScript; if it's actually native then, well, it's quite an achievement for it to have such poor performance). But you have to be at least passingly familiar with algorithms to even know that it's a likely problem. And you know what? I don't always obsess over "the most optimal" algorithm for every problem. Sometimes the more optimal algorithm for large N will require more overhead for the small N that we're dealing with, and the brute force algorithm will not only be "just fine," it will be faster and require less work AND less memory overhead. And sometimes N is just always going to be too small to worry about. I've sometimes just used a quick-and-dirty algorithm only to discover that its behavior was far worse than I had guessed (something that should be instant is taking seconds), but then because I do understand algorithms it takes me 5 minutes to rewrite for better time complexity, and the performance glitch vanishes. And that's who Google is trying to hire, at least in general. It's not like I don't understand object oriented design as well. [1] https://en.wikipedia.org/wiki/Straw_man https://en.wikipedia.org/wiki/Straw_man [2] https://en.wikipedia.org/wiki/Rope_(data_structure) https://en.wikipedia.org/wiki/Rope_(data_structure) [3] https://github.com/component/rope https://github.com/component/rope