Hacker News Reader

Comment by asafira | Hacker News Reader

If you were a graph, which would you be?

More seriously: do people think that any questions that require anything more than DFS, BFS, and/or Dijkstra are reasonable to ask for most general software engineering positions? (I appreciate specific positions might expect more)

Of course, trees are graphs too, and there are loads of tree questions --- I guess I'd narrow my response down to questions regarding general graphs and not just trees.

View on HN

I think it's fine to expect engineers to know graph algorithms in terms of what they do and when to use them, but knowing how to implement them on the spot on a whiteboard is stupid. This one company had an interesting problem that I identified quickly as an application of A* with some interesting edge cases on top. Working through those cases and coming up with the heuristic was clearly the main point of the interview, or so I thought. The interviewer asked me to write out A* on the whiteboard...

At Google an interviewer expected me to come up with topological sort on the spot. I could solve his problem conceptually (figured it was a graph, and that the solution relied on performing a topological sort on it), but no way could remember the algorithm in the 15-20 minutes we had left. It’s something I’ve had to use on the job and I always look it up.

If I interview with Google again, I’m gonna memorize all graph algorithms I can. All my interviewers asked me graph questions.

>do people think that any questions that require anything more than DFS, BFS, and/or Dijkstra are reasonable to ask for most general software engineering positions?

Yes and no.

I enjoy making questions that stretch them to see how well they do in situations they have to solve something.

I always preface with "I don't care about the answer, I want to get into your brain" though. I am not sure how many take that to heart.

Reply on news.ycombinator.com