Hacker News Reader

Comment by riyadparvez | Hacker News Reader

My issue is more with tricky algorithmic questions. I faced these tricky interview questions, where you either have to know the trick beforehand or there is NO way you can come up with a solution in an interview. I never understand the point of these questions. Because these esoteric hypothetical questions will almost never come up in real-life. They don't test someone's skills, because these problems don't follow any standard algorithmic problem solving procedure. They mostly test whether you know the trick or not, which is not a valid metric of skills.

One famous example of this type of questions is to find loop in a singly connected linked list. Now almost everyone knows the trick. And thanks to that, interviewers have stopped asking questions like that.

View on HN

Most algorithms questions only prove one thing: whether a candidate has brushed up on algorithms beforehand. That has some usefulness, being a proxy measure for conscientiousness, but offers little beyond that. Maybe that they’re able to follow the reasoning, but it could just as easily be learned by rote and parroted back. The fact is that no one comes up with a from-scratch efficient algorithm for doing anything in 5 minutes, the candidate either knows it going in, or they’re screwed.

I've been a cpp and java programmer for 12 years and not once needed to use algorithmic complexity on the job. The fact that so many places focus on this baffles me. Big-O questions should be reserved for system architect positions only. Out of all the arbitrary topics, I think they should focus on pedantic syntax questions for whatever language they use. Show snippets of code and ask "what's wrong with this picture?". That would at least select for people with better language mastery and, in theory, faster development times.

I don't really believe this. You use algorithmic complexity every time you choose between a HashMap and an Array. I'm a javascript developer, and I make that kind of choice several times a day.

Having said that, I've never once needed to know the kinds of questions that the ask in these interviews off the top of my head. And I highly doubt google engineers need to often either.

Since Google is such a well-spring of computational resources and have incredible scalability requirements, I'd question your claim that they don't use algorithmic thinking regularly.

He is saying they do need to care about algorithmic complexity in choosing data structures or implementations, but rarely need to figure out really clever algorithmic tricks (of the sort which tend to be tested by harder algorithmic questions, like the "find whether there is a loop in singly-linked-list", which relies on the running pointer technique which you never need to use in real life).

If you didn't know the answer to the question, would you have been able to come up with it on your own, from scratch?

Merely practicing interview questions without pondering them produces the false impression that they're useless trivia, when actually deciding to come up with the answers to these questions and struggle with the clues inside them which produce the answers show a much richer conceptual tapestry for data structures that goes beyond memorizing tricks.

The test lost its validity over time, but how many people care about their craft enough to know how to write software without using a library, and be willing to reason about it from first principles? Or with systematic method? They would be capable of doing original work. The rest I'd give CRUD tasks to.

Do substantive enough work, give it enough time, and first principles will still bite the butt of the CRUD app maintainer.

An algorithms question proves today what it proved 15 years ago: that the candidate learned the algorithm. It does not and never did prove that the candidate spontaneously generated the solution in the interview. In other words, it isn’t an intelligence test. It isn’t even a programming aptitude test, but it is a conscientiousness test because the candidate went to the trouble of learning many algorithms successfully. That does count for something, but not necessarily what the interviewers expect.

If you want to test for programming aptitude, give the candidate a realistic but difficult real world problem and let them solve it in an IDE.

If I was asked to do some comp-geom problem involving convex hull algorithms or intersecting lines, I would be boned. I haven't touched any of that kind of thing years. Even something simple like a quicksort or Dijkstra's algorithm would be a challenge for me to code off the top of my head. I shouldn't have to study for a job interview, I should be interviewed on things that I do on a daily basis.

The thing with a lot of these algorithms is that they seem so obvious and simple when you know the answer, but they still took a very clever person to discover them in the first place.

A good interview question should be a question where the algorithm to implement is trivial (e.g. binary search), but the application is novel.

A good algorithm question I was asked a while ago was to reverse a string in place ("hello world => "dlrow olleh"). Then after completing this task, I was asked to reverse each word, but keep the words in order ("hello world" => "olleh dlrow").

Neither of them is a difficult algorithm. There's no specialist knowledge required to implement them, but there is a degree of logic and problem solving required.

The problem itself wasn't meant to be hard (although apparently a lot of candidates completely failed at it). It was a vehicle for me to discuss how I went about solving problems. It also ended up being a good discussion about why unit testing makes life a lot easier. My code itself was incorrect at a couple of points due to off-by-one errors, but the interviewer wasn't worried at all, because he was aware that it was a whiteboard, and these kinds of errors would be picked up in a real coding environment with testing very quickly.

Exactly. An on-the-job developer who hand-rolls some tricky but well known algorithm from scratch is being foolish. It would be much more productive to see how their google-fu is.

Do they know which algorithm families to look up? Do they know which libraries in the given language will likely have the algorithms already available? That's what a real developer needs to know so why not interview for that.

I don't know the loop question. Do you have a formulation where it's not obvious but realistically possible to solve?

https://stackoverflow.com/questions/2663115/how-to-detect-a-...

I could not find it but there was an old blog post complaining about this question because it was an open topic in computer science for more than ten years, and if one is not familiar with it they are essentially asking the interviewee to be smarter than then all the people in the computer science world in the 1960's or to be an actor and pretend to figure it out in 30 minutes or less.

Reply on news.ycombinator.com