Hacker News Reader

Comment by eranation | Hacker News Reader

It is all true for most web / mobile jobs. But if you are looking to work on medical devices, driverless cars, AI / game development, image manipulation, fraud detection, machine learning, data mining, scheduling. Then the real world actually does work this way. You'll need to know these things. Even for uber or home joy, finding the right taxi / cleaning service to match the provider with the client on a map needs usage of graph and scheduling algorithms, and understanding their complexity. You are right that once this is done, most of the work is APIs, UIs etc. but someone needs to write these APIs.

View on HN

Agreed. There's a lot of places where CS knowledge is necessary and those algorithms are usually the main IP of the company.

But these algos are developed during months or years of research, team meetings, white boarding and experimental prototyping.

These things are not developed under the pressure of a ticking timer (well, technically there is the time constraint, but usually the limit is more than 30 minutes).

Also, the problems are very palpable and concrete and the drive to solve them is much stronger than in an interview, where the anxiety of failing the interview hangs over your head.

You are conflating many things. Nobody ever has expected candidates to produce an answer that would be the equivalent of months of work.

Basic CS/Math/AI/Physics knowledge affords you a starting point that's further along in the development/tweaking of an algorithm. That is NOT the end point. Its simply - knowing whats out there.

If you start with "well let me go read about whats out there" you will only have time for superficial knowledge from wikipedia or what have you. Because that starting set of knowledge takes years to accumulate. Testing whether you have this starting set is a crucial setup in knowing whether a candidate is going to constantly end up wasting time reading up on basic stuff. You can't build a plane by opening a high school physics book.

One other thing is that when you have a broad enough set of domain knowledge in your head, its much more likely that you're able to connect the dots cross-domains. This is essential if you're going to be doing some interesting algorithmic work.

Of course, all of what I said is predicated upon you being interested in that sort of work.

Most systems I've worked with have a core piece that embodies the "hard" algorithm (as you say). The 80-90% of code required to make most user-facing systems work is not "hard" algorithm code in my professional experience. Why does every developer at a company that works on "medical devices, driverless cars, AI / game development, image manipulation, fraud detection, machine learning, data mining, scheduling" need to go through the same interview?

On top of that, I've never interviewed at a company doing that level of complexity where I was going to be expected to write it, from scratch. By the time they're interviewing people, they have something in place, and even if I actually could write it better, politics and personalities are likely going to prevent that anyway (or perhaps even legal).

More than likely you'll be working on a team, where you need to understand some of these concepts, and you'll grow in to them. Almost every single person on that team did not come in off the street with expert knowledge in those domains.

Reply on news.ycombinator.com