Hacker News Reader

Comment by ezekg | Hacker News Reader

There's a difference between expecting candidates to know when to recognize graph theory problems and expecting candidates to know (and implement) Dijkstra's algorithm as the correct solution to some abstract problem. I don't remember what Dijkstra's algorithm is exactly off the top of my head (all I remember is that it's for graph traversal and has a memorable name), but I do know when to recognize graph theory problems so I can start looking for the correct solution.

I definitely agree that general CS knowledge is highly beneficial (it's why I put in the time to learn), but knowing implementations for specific algos doesn't seem as important in the day-to-day as interviews make it out to be.

View on HN

That is nice, however when hiring people it is useful to get somebody who can actually implement the solution too, rather than just sitting back smugly having identified a problem as "Dijkstra's".

If somebody can get as far as recognizing the problem as requiring Dijkstra's algorithm, they can go pull a book off the shelf, or use Google, and find the details of the implementation. Or, more likely, find a pre-existing implementation[1] that can be re-used.

Personally, I doubt that many people are walking around with the deep details of Dijkstra's memorized and readily available, unless they have a job that very specifically focuses on graph operations and they do nothing else day in and day out. So you could memorize it just for the interview, and then forget it again by the next day. But is there really any point to all that?

[1]: https://www.google.com/search?num=30&q=graph+algorithm+libra...

There are however people who can fairly easily write graph traversal and recursive code on a whiteboard. I wouldn't mind someone not knowing Dijkstra's well enough to code it from memory, but I'd be leery of someone who struggled with basic recursion, either writing the code or running through it and reasoning about it.

I wouldn't mind someone not knowing Dijkstra's well enough to code it from memory, but I'd be leery of someone who struggled with basic recursion, either writing the code or running through it and reasoning about it.

Fair enough.

I agree with this--but I don't think the interviewer should be asking for an implementation of Dijkstra's in the first place. That's my whole point--it's not a real world problem to need to know an algorithm from memory. If I need a particular algo, I'll look it up and find a supported open source library that implements it 10x better than I could have.

My point is that you can gauge somebody's knowledge without making good software developers feel inferior e.g. by asking them how they would go about finding a person's likely connections given some weighted data for an imaginary social network. And then you can maybe get responses like, "That's a good question--I've dealt with that before when I was working on X, Y, Z and ended up using weighted graphs according to how many friends a person had in common …" or "I'm not entirely sure on the exact algorithm I'd recommend, but that sounds like we would set up a weighted graph and go from there …".

Rather than making talented people feel stupid, you encourage conversation. But what do I know, I don't interview people every day so take what I say with that in mind. I just think tech interviewing is broken. I'm always left frustrated and my excitement to join the team dies down due to thinking I won't fit in because I'm not "smart" enough.

Reply on news.ycombinator.com