None. Asking about algorithms isn't a good way to assess candidates (unless they will be writing graph algorithms, which as it turns out doesn't happen very often).
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.
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...
>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.
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.
I also have reservations about algorithms questions as a useful interview filter, but my favourite that I have been asked is "How would you delete a tree using a fixed amount of memory? i.e. no recursion or other dynamic structures".
“If we asked you to sell more ads, which graph would you choose?”
Follow up: “Which graph would be better at tracking and monitizing our users? Preferably, it would be optimized for lowest memory usage while also not letting our users know how we exploit their trust in us.”
14 comments
[ 3.0 ms ] story [ 41.6 ms ] threadMore 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.
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.
If I interview with Google again, I’m gonna memorize all graph algorithms I can. All my interviewers asked me graph questions.
A slight step up from that could be word search/boggle as it involves multiple data structures (trie, etc).
Another good one is topologically sporting a dependency graph to get a list of dependencies to install/operate on in order.
For a take home interview, variations on 8 queens can be interesting since they utilize dfs and backtracking.
Follow up: “Which graph would be better at tracking and monitizing our users? Preferably, it would be optimized for lowest memory usage while also not letting our users know how we exploit their trust in us.”