Hacker News new | past | comments | ask | show | jobs | submit login
Preparing for a Technical Interview: Algorithms and Data Structures (primaryobjects.com)
83 points by primaryobjects on March 28, 2017 | hide | past | favorite | 10 comments



Some constructive criticism... I would review your explanations to see if any imprecise sentences can be replaced with more accurate definitions. I get that you're going for a friendly tone but many times, the more accurate definition is just as easy to read.

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.


This is a great guide, thanks for sharing.

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.


Honestly, don't bother practicing "this stuff". Instead, spend your time doing what is important to you (family, friends, side projects, side business, whatever).

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.


For the most part as an employee, do it on work time. If you need an important algorithm or data structure, then put extra time in beyond the one you know you can make it work with. Pay as much attention to what's not suitable for the job today as what is.

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.


Another possibility is to work on your ability to work out the different algorithms and data structures on your own with perhaps a minimal specification or statement of the requirements.

This would require a focus on understanding as opposed to memorization. Also, this ability has broader application than doing well at interviews.


The text does not differentiate between worst-case and average-case analysis. Quicksort is worst-case O(n^2), but average-case O(n logn). Yes, I know the text says "on average" in parenthesis, but that's not going to help a reader understand what that means. For an article that is meant to prepare people for a technical interview, I think it's important to make this kind of distinction.

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).


The BFS tree traversal algorithm is also O(N^2). Very sloppy, I'd take off points.


"Points"?

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.


Is there something wrong with not wanting someone to write an n^2 function that should only take O(n)? And the person who wrote this is supposedly giving advice on how to pass such interviews for "top-shelf" programmers. So I don't see how complaining about the existence of the process is relevant.


Is there something wrong with not wanting someone to write an n^2 function that should only take O(n)?

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: