Hacker News Reader

Comment by cycrutchfield | Hacker News Reader

As somebody that interviews a lot of candidates, I almost never ask rote memorization questions like these. I have to wonder, are there people who do? What sort of signal do you hope to gather by doing so?

View on HN

It's probably better to think of it as the building blocks for answering more complicated questions. E.g. you write an algorithm and one of the followups the interviewer asks you is the runtime of it. Well, you used a hash table, so lookups are constant time, but you iterate over the keys, which is is linear in the size of the table. So when you do some work linear in the size of the input for each item in the table, you can work out that's a quadratic algo. That sort of thing.

That's how I thought of it when I was studying leetcode, and that's the advice I give to other people when they ask how I got my job. Each leetcode solution was another tool in my toolbox. The more tools you have, the easier it will be to put two things together for a larger solution, or to modify a tool to fit a new problem.

I understand the resistance to flash cards as rote memorization without being able to build upon them, I think that's a cogent criticism. At the same time I think some people will be able to take advantage of this to build their toolbox.

And as a minor note, I personally love when people can name an algorithm or concept. There was one interview that I think I completely failed, but I was able to name (but not write out) a concept. I actually incorrectly name dropped Hamming distance, when it was actually the Levenshtein distance, but I was able to diagram the concept behind it. I passed that interview (to my tremendous surprise), and I think the name drop and the simple diagram helped.

Unfortunately there’s a large amount of grifters out there providing tech interview “coaching” to people with no prior experience. Fortunately as someone who also interviews SW candidates it’s really easy to spot who just memorized Cracking the Coding interview and Geeks for Geeks answers.

I literally had someone write down the exact answer for an algorithm question that appears on GeeksforGeeks down to the small bugs which the post had originally.

> I literally had someone write down the exact answer for an algorithm question that appears on GeeksforGeeks down to the small bugs which the post had originally.

how did you know/verify this?

wondering why an interviewer would go GeeksforGeeks and other interview sites and match a candidates answer line by line.

It seems pretty reasonable to me, as an interviewer, to look up the question I am thinking about asking to see what is available online. Is there a reason you wouldn't do this?

> to look up the question I am thinking about asking to see what is available online.

ok if you find that your question is very common leetcode problem. What do you do with that information?

Looks like GP decided to use that common question anyways in the interview.

Write some sort of automated plagiarism test that checks against all common sites and answers ( leetcode can have 100's of user posted solution) ?

When I was writing the interview question I was wondering if some site had already covered it. Turns they had, so I ran their solution and discovered it had some bugs. Whenever I ask the question, I refer to the "answer" on geeks for geeks. If they copy it, they get a no-hire from me.

I interview a lot of candidates as well, and I agree. My philosophy is that an interview is an opportunity to talk about a problem together and sketch out some code. The only reason we choose to talk about algorithms and data structures is because they're a domain that's pretty similar no matter what sort of programming you've been doing.

"Memorizing" these algorithms isn't the approach I'd use at all. No interview of mine will ever be of the form "implement such-and-such well-known algorithm".

However, my questions do begin with "imagine we're on the x team and we have y technical problem - what should we do?", and it's helpful to have a toolchest of coding techniques that includes hash tables, trees, etc.

I haven't used hashtables or trees since I was in university, 15 years ago. I'd look them up if I needed them, but I never really have. Do people really keep these things in active memory?

If you're coding in a modern dynamic language, you're probably using hashtables every day without realizing it (that's one popular way dictionaries/associative arrays are implemented). As for trees, your code is a tree. Every time you're working with a nested data structure, you're working with a tree. Trees are fundamental to programming and data representation in a way hardly anything else is.

> If you're coding in a modern dynamic language

I see. I don't do that very much.

> As for trees, your code is a tree. Every time you're working with a nested data structure, you're working with a tree. Trees are fundamental to programming and data representation in a way hardly anything else is.

I haven't really needed to write a program to traverse my code as a tree, but I guess you're right that I must have used trees in C at some point.

Reply on news.ycombinator.com