5 ms·

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 i

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".

mindcrime 9y ago
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+library+"open+source" https://www.google.com/search?num=30&q=graph+algorithm+libra...
- fwefwwfe 9y ago
  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.
  - mindcrime 9y ago
    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.
ezekg 9y ago
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.

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".

mindcrime 9y ago

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+library+"open+source" https://www.google.com/search?num=30&q=graph+algorithm+libra...

fwefwwfe 9y ago
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.
- mindcrime 9y ago
  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.

ezekg 9y ago

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.