|
|
|
|
|
|
by organsnyder
2713 days ago
|
|
|
I can't write BFS off the top of my head, but I can probably do it after reading the Wikipedia page on it. The last time I interviewed (for the company I'm working for now), I faced a similar question, and said up-front, "It's been a decade since I've had to implement that, so let me Google for a quick sec." I proceeded to do so, skimmed the Wikipedia article, and wrote the code in the shared editor we were using. I got the job, so the interviewer must have seen my candor and quick comprehension as positives. But I know (based on the parent comment here, as well as discussion with colleagues) that this sentiment is not universal. If I had claimed a lot of algorithm-heavy experience on my resume, I would have expected my response to be met much more harshly. But, as my experience was focused more on API design and interactions with business stakeholders, it wasn't a useful question to gauge my competence. However, it was useful for gauging my personality. Like everything, context is vital. |
|
|
That is actually informative on your programming ability, not regurgitating buzzwords (albeit BFS is a light one) or rote memorization.
Like just hearing these kinds of questions is infuriating because I often immediately ask things like "is the data processing complex enough to justify threading it? what are the synchronization points? if the data processing is variable, we probably want a job pool, etc". The performance of code is almost always noninutitive until you have an implementation done in order to optimize it, and questions about searching graphs are almost always these "optimize light" problems where they want you to really know how to do the navigation right because of my precious 10 cycles per branch but don't want to even consider the operating environment that could influence the decision in anything but a purely academic setting.