Hacker News Reader

Comment by gameswithgo | Hacker News Reader

>You just need to call std::sort, and don’t care it is “bubble sort” or “quick sort” under the hood

This is often the case, but not always. When you know things about the input data you may be able to get better performance than the generic sorts built into a language. Or, when you know more about sorting algorithms you may be better able to choose among the available sorts/sort options provided by a language or library.

I don't understand the attitude of people willfully choosing not to understand their craft better. Yes we can all be mediocre by just using libraries that other people made, but

1. Someone has to make the libraries 2. The average quality of software is not very good, its very often slow (which is astounding given how fast the hardware is) and buggy, often with disastrous consequences, so we should all be striving to do better than average.

View on HN

In case of sorting algorithm, it is important to know the trade-off. However, precisely knowing the details e.g. knowing the details of deleting a node from a balanced tree, is not really useful and that is exactly what is needed to pass whiteboard tests.

In most cases(in my experience), i can always lookup details of some algorithm when i need it. Admittedly, my job doesn't require me to design algorithms, but implement some not so readily available ones sometimes.

which is quite right at my first job we didn't get our very expensive engineers (Oh rate was > 500%) to write our own fourier analysis we just brought one from NAG.

For sure, I'm not arguing that some whiteboard interview questions aren't crazy, i realize there are.

But also I'm not sure how common it is to have interview questions such as "delete a node from a balanced tree" where they actually expect you to get that right vs just see if you get the basic idea. I've never run into it. Perhaps many people on hackernews work in silicon valley and that is more common there.

These are the same people who want "intuitive" understanding of fundamentally mathematical subjects. Anytime I see a title, "X without math," I just see "X without X."

Intuition isn't understanding and ignorance isn't expedience. I think your choice of the word craft really homes in on what we are supposed to be doing. Building things well with craft. There is a place for duct tape and wire, but the craft of software matters.

I understand both of your arguments. In the end I hate whiteboarding problems, because I don't really need to know all of the potential problems in detail, but a certain interest for why some algorithm is faster than another IS indeed helpful when programming fast applications.

I have done some optimizations in the past, and I think what the author is getting at, is that it's not too late to learn about the specific niche algorithm you're dealing with when you have it in front of you.

My favorite rule about optimization is one I learned from a former colleague. First you measure, then you find where you should look, then you optimize. Without measurements you're maybe doing more harm than good. And if you look up different solutions when you know what you're trying to optimize it's usually not that hard to find a better replacement. But you don't need to have the exact solution in your head for this.

What you do need is the rough cursory knowledge of algorithms that grants you the ability to see more quickly where you're losing precious cycles. E.g. knowing the tradeoffs between linked lists and vectors.

I've seen way to many tools that could be sped up by a factor of 30-100 in an afternoon, that I really have to agree with you that a lot of people don't know their craft. I just don't think rote memorization of algorithms Q&A is solving any of this. Take home exams IMHO are a much better measure. I can ask people why they chose a certain data structure, why they didn't do it another way (if I have an idea of what could be better). That gives me much more of an insight in how people think. Not how well they memorize things.

He doesn't seem to be saying that he chooses not to understand but rather he's trying to optimize his time to improve in the context of his current knowledge. This is understandable and it's important to know what's in the standard library in order to be productive. As he gains experience I suspect his curiosity will lead to deeper exploration.

I feel like #2 is caused more because people try to be #1. Instead of letting good programmers develop well-established libraries that everyone uses - you end up with NIHS and a bunch of mediocre developers creating mediocre libraries that only they use. I became a better Javascript developer when I began using well maintained libraries to solve problems instead of wasting time reinventing the wheel every time I had a problem that needed to be solved.

Time is hard. I don't like to deal with localizing time, formatting time, or converting time. Instead I use a library [0] to solve that problem for me. Because while I may need to localize time - localizing time is not the problem I am trying to solve. It's just a roadblock in the process of solving my actual problem.

[0] https://momentjs.com/

I've been in the business for ~20 years and there are very few cases I can recall where it really mattered what the underlying sorting algorithm was, and no cases where the actual details of the algorithm's implementation mattered. Not saying these cases never come up--I am saying they are exceedingly rare [EDIT: and often company-specific], and making them general candidate interview questions might be a bit of a waste of time.

Present a candidate with a simple system with three levels of middleware API and have them plumb a newly exposed low-level value up through all three levels to the high-level API. This is unfortunately 75% of professional software development.

We've reached a point of complexity where few if any people hold the whole stack - from electrons wiggling along to making the button more enticing to click - in their head. You have to eventually decide where you'll settle in the layers of abstraction and let others handle their own.

There is a lot of value in knowing that some algorithms are better for certain problems than others. But knowing them to the level that you can whiteboard them quickly without mistakes in an interview is just an exercise in memorization.

And sometimes you want to do something close to sort but tailored to a specific problem.

Reply on news.ycombinator.com