Yes, and that argument could be used to require every interview candidate to know quantum physics.
At some point you draw a line, and Google/Amazon/Microsoft/etc. have very clear pictures of where their respective lines should be. It seems to work well for them.
Think about it this way. 1st principles knowledge, like algorithms, isn't at all useful 90% of the time. But 1% of the time, not knowing it will cause very out-sized penalties in efficiency or debugging costs. Now take the frequency of the occasional 1st principles usefulness penalties and multiply it by all of the developer-hours at Google/Amazon/Microsoft.
That is why Google/Amazon/Microsoft do that!
There is no proof that they are actually preventing bad engineers with this process or that they couldn't get much better engineers and fewer flops by fixing it.
People want to work there in spite of these irritating hiring processes. I frequently travel via plane but that doesn't mean I think the TSA process is good.
Have you ever done the standard Comp Sci compiler implementation class? Do you write C++ and use the C++ standard library? If you answered yes to both questions, then you should know from first principles how just about everything in the standard library is implemented, and can use those tools with complete knowledge of when they can fail or must be used differently.
I find that developers who constantly get caught up in the performance of individual algorithms will waste incredible amounts of time optimizing them and will miss major optimizations that come from seeing the system as a whole.
Those developers are merely exhibiting yet another kind of ignorance.
For example, I would rather take the developer who points out that a particular program can make use of the fact that most of the code doesn't need sorted widgets rather than the one who spent the whole time optimizing the widget sorting algorithm.
It's the developer who has a clue about algorithms who is more likely to make the valuable insight. The needless optimizer is just doing some Cargo Cult algorithms analysis. (Probably motivated by signalling geekiness, not producing useful results.)
People create value with software when they use code to solve problems.
For some people, that means tackling a gnarly complex problem and by a combination of wits, experience and education, come up with an efficient and elegant solution. Typical example: someone working in a specialized role in back-end (i.e. not user-facing) systems in a large company (small companies can't usually afford specialized roles). Concrete example: V8 JIT engineers.
For other people, it means looking up from the keyboard, figuring out the company strategy and product fit, and seeing what can be most efficiently (in terms of effort) put together to improve or align both. Creating a proof of concept that gets buy-in for a more in-depth solution.
The second category almost always delivers much more value than the first. And there's a spectrum in between, a spectrum of people who are all very good at what they do, all very good at creating value; the spectrum extends from the guts of the machine all the way out to the interface with the customer.
I've worked in some very different industries in my career; ranging from compiler engineer to web app developer. Compiler engineers leave their fingerprints on far more code, and the job is intellectually stimulating. But realistically, most of the reward of the job comes from the fun of job itself. As a web app developer, I apply my knowledge of compiler techniques to things like SQL generation from filter predicates represented as ASTs, for efficient display of the user's data. But I could only deliver that because I saw the possibility of connecting the back end we had with an Excel-like experience we could give the user; and I had to take it on.
I've seen other people take a bunch of open source components - not knowing in depth how they worked - and put them together to create surprisingly credible solutions very cheaply, the kinds of solutions that win 7-figure SaaS deals. You don't get there with your knowledge of binary trees or compiler principles.
But having some basic algorithms knowledge might make the difference between delivering such a solution that runs reliably and quickly enough and not.
The ability to implement the sorting algorithm in the C++ standard lib is completely orthogonal to people who have this insight.
People who have an understanding of complexity analysis is really all it takes to have that insight. Memorizing a bunch of datastructure algorithms has almost no bearing on this ability.
Weak example! Exactly when would you want to use a shared_ptr, and when you you absolutely not want to use a shared_ptr? Why? And what pieces of 1st principles knowledge would let you simply know that in about a minute?
People who have an understanding of complexity analysis is really all it takes to have that insight. Memorizing a bunch of datastructure algorithms has almost no bearing on this ability.
Note that in this thread and others I've been advocating for First Principles knowledge. If you have that knowledge, then you'd probably know several of the most basic algorithms and their analysis from having learned that. I'm not advocating that people just be able to spit out a memorized text!
You're not thinking big enough. My usual extension of the argument is to suggest that part of the interview process should be to give the candidate a bucket of sand and some ore, and make them smelt everything and build their own CPU from scratch.
Because, y'know, it's important to cover fundamentals!
(I'd give people extra credit for coming up with creative and interesting variants based on Buffon's needle, rather than building the full infrastructure to do lithography).
...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
To expand on what you are saying: If you're doing "high level development" on a business app in C++ 11 then knowing assembly and having been through a bog-standard undergraduate CS Compiler Development course will actually help you use a whole bunch of things in the C++ standard library, because you can easily guess about how such things would be implemented from first principles. Otherwise, things like smart pointers are just "magic" and just need to be used in a bunch of disconnected abstruse ways. Having the first principles knowledge lets you easily know when to use another shared_ptr, when to use a reference, and when not to use one -- all just from first principles, no arbitrary memorization required!
Hell, having that kind of knowledge even benefited someone working in Smalltalk back in the day.
Agreed, and my understanding of assembly does help in those ways. I actually feel like compiler design was one of a very few classes in college that really, really taught me something.
But if I'm hiring a Python or JavaScript developer, I'm not going to require they know assembly. If only because that would restrict the hiring pool so much that I'd likely never find an employee.
A senior developer, though, probably should understand what's happening at the low level. And most teams should have a senior developer to keep the team from making rookie mistakes. There are plenty of programming jobs that can be done with less skill or deep knowledge. Like the ones that are discussed in the Wired article on coding being the next "blue collar" job. [1]
[1] https://www.wired.com/2017/02/programming-is-the-new-blue-co...
I think that the lead or "surgeon" (to quote The Mythical Man Month) in charge of any app or service development project should be well trained. Anyone who brings in a junior developer (anyone without a CS degree or equivalent, or less than 5 years of professional experience) to lead a project is asking for trouble.
But I think that average developers don't need the full training any more than a nurse needs to have a full medical degree. There are certainly things that I don't want to have to do, and while I might be able to do them better in some way than a more junior developer, they just don't matter enough.
It is a Catch-22, though: Just having a CS degree and five years of experience doesn't make a developer competent. I'd love to see some kind of certification to help separate the wheat from the chaff, so that non-experts could distinguish a top developer from a mid-tier developer.
But none of the certifications I'm aware of do anything aside from test that you've memorized the right buzzwords associated with a particular technology, and as such having such a cert is almost useless.
So yes, I'm arguing for certifications despite the fact that I view certifications as useless. If we had good certifications, maybe we could help establish a better way to distinguish developer skills. Would love to see that, but I admit it's selfishly motivated: I'm really good at programming and technical tests, so any such regimen I'd likely end up with the highest ratings, except if domain-specific knowledge was required.
A nurse needs to have enough 1st Principles knowledge plus specific training to keep from making egregious mistakes. In fact, where X is a profession, an X needs to have enough 1st Principles knowledge plus specific training to keep from making egregious mistakes.
The fact that our "field" keeps producing X without that minimum level means something is broken. It would be like the nursing field producing nurses who didn't know how to spot a Tension Pneumothorax, because most nurses don't have to deal with that 99% of the time.
So yes, I'm arguing for certifications despite the fact that I view certifications as useless. If we had good certifications, maybe we could help establish a better way to distinguish developer skills.
The fact that you entertain this thought is an indication that something is not quite right with our field.
Agreed. But try as I might, I can't come up with a solution that I'd actually support the implementation of.
If you have any ideas about we can get from where we are to where we should be, I'd be interested in hearing them. Having IEEE license developers at varying levels of skill sounds like a start, and requiring Internet-visible software to be written by developers with certifications sounds nice...until you think about open source projects, which thrive in large part from free effort. And until you think about the fact that software traverses borders fluidly. And what about entrepreneurship? Should we tell people they can't write apps unless they have the certification? Or that they need to pay an expert to audit their apps?
And the fact that big companies will do whatever they can to cut costs, including hiring developers in countries without certification requirements if you don't motivate them otherwise. (Maybe a DMCA-style safe-harbor, where ONLY if they use a development team with sufficient certifications can they be proof against lawsuits for defects; otherwise people can sue them for exploits that result from their software?)
I have lots of ideas, as you can see above. I just don't like any of them. There probably needs to be a constellation of rules in place, set by a professional organization and ensconced as legal requirements... But half of the rules I imagine wanting I also, under other circumstances, would despise.
It's about as relevant as implementing quicksort.
>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.
Or it's actually a javascript event handler that is doing something else expensive per char delete. It's more important to know to profile rather than try to memorize every algorithm used by a system and guess which one is causing the problem. Once you identify where the bottleneck is, you can search for "efficient algorithms to do X".
People who profile and fix bottlenecks are much more valuable than people who think they have implemented the most efficient algorithm for every operation in their program.
...did you actually read my comment? Because I went on to say that I didn't think it was relevant.
That said, understanding how quicksort works is important, not because you'll be called on to implement it, but because there are key strategies used in its implementation.
And yes, I can implement quicksort without looking up the algorithm. It's really not that hard.
> Or it's actually a javascript event handler that is doing something else expensive per char delete. It's more important to know to profile rather than try to memorize every algorithm used by a system and guess which one is causing the problem. Once you identify where the bottleneck is, you can search for "efficient algorithms to do X".
Sorry, but no, wrong answer. Partial credit for suggesting profiling. Let me take this apart:
> Or it's actually a javascript event handler that is doing something else expensive per char delete.
If they're calling a function that triggers an event handler for every character deletion when they're deleting a block of text, then they're Doing It Wrong. Yes, profiling is important. But calling delete one character at a time for a block of text is plain lazy.
> Memorize every algorithm used by a system
Umm....this is a text editor we're talking about. There are very few algorithms, and it shouldn't be a case of "memorize them" as much as "observe them." If there are more than 3-4 algorithms, then it should also include "draw a picture of how they interact," if your abilities at modeling them in your head are insufficient.
But someone who is strong at algorithms should be able to just see what's wrong with a text editor that deletes characters one at a time. It should be obvious that it's likely to be a problem, and they shouldn't do it to begin with.
> People who profile and fix bottlenecks are much more valuable than people who think they have implemented the most efficient algorithm for every operation in their program.
Both are necessary, and as I've said elsewhere, "developers that are anal about optimizing everything" is a straw man; good developers know when optimization is important, and good developers can write more optimal code without making it harder to read. Just knowing how to optimize doesn't automatically make you optimize every single routine, nor does it mean everything is more complex. Half the time when I optimize something the code ends up cleaner and easier to read, in fact.
And it's not always about bottlenecks. Sometimes it really is about the algorithm, and if you don't know your algorithms, you won't be able to recognize this. As said above, it's a prime example of the Dunning-Kruger effect: If you don't know algorithms, you don't even know what you don't know. Claiming you don't need to know algorithms just reinforces the point. Sorry.
In another comment on this post I described an optimization that I did that had no easy-to-fix bottleneck that was slowing things down, and that required a high level algorithmic change to fix. [1] In about an hour I sped it up by a factor of about a thousand. Ultimately I was doing the same things, but I was able to improve the algorithmic efficiency.
And someone strictly looking for bottlenecks can look at that code forever and not see the algorithmic change needed, because the code itself was written to be pretty optimal; it was a high level change to the algorithm that made it so much faster.
So. Much. Fail.
The Amazon Alexa/Echo app is similarly poorly programmed. Takes like 10 seconds just to boot up, which you need to do if you want to look at your shopping list -- and if the gets pushed to the background, you need to boot up the app again. Sigh.
And I'm pretty sure that the person who doesn't want to learn binary-tree traversing will never be able to point that out. That's the point you missed of the post you replied to.
This same exact argument could be used to require every interview candidate to know assembly.
>and the person who likes to think about such things is more likely to spot the potential problem and avoid it altogether!
I find that developers who constantly get caught up in the performance of individual algorithms will waste incredible amounts of time optimizing them and will miss major optimizations that come from seeing the system as a whole.
For example, I would rather take the developer who points out that a particular program can make use of the fact that most of the code doesn't need sorted widgets rather than the one who spent the whole time optimizing the widget sorting algorithm.