Preparing for a Technical Interview: Algorithms and Data Structures
primaryobjects.com
primaryobjects.com
For example this text:
>In the case accessing an element within an array or hash, it takes 1 operation to perform. Thus, we can describe the complexity as O(1) for this code example. This is about as good as it gets for algorithm complexity. Of course, while O(1) runtime code is quite fast, it may often come at the expense of storage.
It's clearer to say that O(1) means constant time access in relation to input size. The "1" doesn't mean one operation. The alternative explanations you wrote are actually misleading.
Out of curiosity, how do other employed developers allocate time to study this stuff? Immediately after graduating from college I could spend 4-8 hours a day most days of the week reviewing algorithms and solving problems without issues. Now, after a full day of coding at work, going to the gym, coming home to prepare dinner and run other errands, I'm physically and mentally drained. I might spend an hour or two before bedtime trying to study this stuff (since I completely forgot it since I last did technical interviews 1+ years ago) but progress is slow. Of course there are weekends, but that's usually the only time I get to relax and go outside to see the sun. I now understand why it takes 6+ months for working professionals to find new jobs.
This would require a focus on understanding as opposed to memorization. Also, this ability has broader application than doing well at interviews.
Of course, that means you're to some extent limited by what your work requires, but I think devs should feel not just that it's ok to check out this stuff at work but that they have a responsibility to.
The other way around it, depending on your local market, I find is contracting. Then people tend to care less about your theoretical knowledge and rely more on being able to show you the door if you don't produce the goods.
If you need a job, then practice. While doing your job, do it well. Don't waste your personal time on this "stuff". That's really a waste of time and effort.
The article also says that merge sort is average-case O(n logn), which is true, but is likely to confuse readers, as merge sort is also worst-case O(n logn).
That kind of oversight is simply unacceptable in a modern, agile engineering environment. Especially not in the august company of hand-picked, top-shelf developers such as you've been able to compose your build your team out of, thus far. So I'd fire them (or that is, shift ever-so-glibly to "Do you have any questions for me?" mode) on the spot. And instruct my internal recruiter to make a point of not bothering with any kind of follow-up after the interview -- dense as they are, sooner or later they'll get the hint.†
† Again, I'm being blatantly facetious. But this is exactly how the "modern" (Google-inspired) interview process seems to work much of the time, in practice.
But that's not what the typical whiteboard session actually assesses -- that is, whether you'd never catch yourself, in the normal course of development, from implementing a grossly inefficient algorithm before catching yourself, and long before significant damage has been done. BTW the operative phrase here is "normal"; as in, the normal unhurried pace at which we work, with time to reflect on these things during coffee and bathroom breaks. And of course without being surrounded by tag teams of 20-something dudes you've never met, comfortably assessing your every move -- secure in the knowledge that they'll still be in a reasonably tolerable job, no matter what, at the end of the afternoon; but as to whether you'll get out of your current situation -- that's a total crapshoot, of course.†
What they test, rather, is whether your immediate, muscle-memory recall of the complexity class for each and every use case is 100% correct -- subject to the above-mentioned adverse conditions. Because no matter what they say about "just wanting to see how you think through a problem" -- in reality these quickly devolve into zombie-like grading sessions (and, depending on your state of nourishment and general composure, sometimes outright death marches). Where -- very much unlike under real working conditions -- at the slightest misstep, however temporary -- you start losing "points", and very significantly risk the prospect of failing the process altogether.
So I don't see how complaining about the existence of the process is relevant.
It's an observation about a process that has been widely observed to be deeply flawed, on multiple fronts. There's no need to label it as a complaint.
† Like as not, without adequate breaks for nourishment or bathroom needs -- or a significant portion of the time, without a break of any kind -- during the whole multi-hour ordeal.