Comment by codeshaman | Hacker News Reader

Comment by codeshaman | Hacker News Reader

Parent Full thread

Logged in to second that.

I might not be the best programmer, I'd say that I'm about 'average', but I have about 20 years of experience building apps in a dozen programming languages and operating systems.

I could count on my fingers the number of times I had to solve a problem similar to these tech interview puzzles, like 'count the number of mushrooms that a person can collect in M steps' or 'How many jumps can a frog make' or whatever.

My issue is understanding the problems, because they have nothing to do with what I usually have to solve on a day by day basis. Added to that is the fact that many problems have some irrelevant clauses, just to fuck with you :).

Yes, you want the most efficient solution for a tight loop that runs on a list with a gazillion elements, but in a typical application, it's usually the only place where you need to apply deep CS knowledge.

And that thing has to be researched, usually a 10-minute investigation on google/stack overflow or just steal the solution from someone smarter than me on github, even if it involves translating it to a different programming language.

That's how the real world works.

99% of the code deals with APIs, UIs, file formats or network protocols, etc. Real, palpable stuff.

What worries me is that now these interview things are being automated and your 10 minute half-baked solution is being tested against huge datasets with all the possible corner-cases. Good thing in theory, I guess, but still irrelevant for the real world.

I've worked with interview ninjas who couldn't put together more than a console application.

> it's usually the only place where you need to apply deep CS knowledge

And usually, at the level you're talking about, you're probably going to be using a library that's been custom built for the problem you're dealing with.

Amazing how many people will yell out "don't reinvent the wheel" but would also not hire you because you'd choose to just use Apache Commons instead of writing your own sorting algorithms from scratch.

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.

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.

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.

I agree that it has only been a few times in my 20+ years that I needed some CS knowledge to get a project done. However, when those times did arise, it was a complete roadblock for developers who lacked the knowledge.

It is the difference between being able to say, "I can code anything... some things are just harder than others." and "I can only do web development, and cannot be put on project requiring CS or advanced math."

Which does not mean you need a CS degree - on the contrary, I find self-taught coders to be quite good. But self-tech yourself at least some CS knowledge as well.

Reply on news.ycombinator.com