This is kind of ridiculous (aside from the errors in it!). Seems like a good checklist of things to avoid including in a technical interview, since it won’t discriminate between people who know their stuff and people who’ve memorized cheat-sheets like this by rote.
(I don’t think I’ve ever had a technical interview where this would have helped.)
I largely agree, but there are definitely career programmers who don’t prioritize this type of knowledge as important, and there are definitely successful companies that don’t, either. If one is looking to move from that into a role where it is viewed as important, it’s a helpful list of the basics. I would not suggest using it as a sole source of information, just a list of topics to understand.
Well, I didn’t mean studying it was ridiculous; I meant that judging programmers on whether they know, say, what a circularly-linked list is seems ridiculous, unless maybe their résumé includes “wrote a new interframe memory allocator for AAA game” or something. It’s a symptom that somebody has a ridiculous interview process. I like studying this stuff, myself, and I think it’s useful under some circumstances, but it seems like a dumb way to judge someone.
Certainly agreed that it should never be about memorization. The best interviews I’ve seen are more along the lines of, how would you come up with a novel structure or algorithm for this problem? But that requires a lot of experience, and a carefully-chosen problem, to fit in the time available.
In some memorable technical interviews, I’ve been asked how to build an index to optimize RMQ (although they didn’t call it that) and what would be needed to design backspace in a text editor with a variable-length character set where each character is either one byte with the high bit clear or two bytes where the first one’s high bit is set and you just have a pointer to the end of a bunch of these representations appended to each other. It took me quite a while to figure out that second one, because I was thinking of UTF-8, where the representation is self-delimiting even when you read it backwards, but surprisingly I got a job offer anyway.
there are definitely career programmers who don’t prioritize this type of knowledge as important
I was turned down by a job at Google because I don’t know Big O notation for different operations on various data structures. I obviously do know the speed difference between them and when to use them etc., I just didn’t know how to express that in the way they wanted. Apparently I can learn it and reapply whenever I feel like. It’s been 3 months and I haven’t bothered yet (I was also approached about the job, I didn’t apply for it).
I’ve heard speculation that dynamic programming is popular at MIT, whereas memoization is popular at Stanford, and so you can tell which coast someone learned on… I am not in a position to assess the truth of this. :)
This is kind of ridiculous (aside from the errors in it!). Seems like a good checklist of things to avoid including in a technical interview, since it won’t discriminate between people who know their stuff and people who’ve memorized cheat-sheets like this by rote.
(I don’t think I’ve ever had a technical interview where this would have helped.)
I largely agree, but there are definitely career programmers who don’t prioritize this type of knowledge as important, and there are definitely successful companies that don’t, either. If one is looking to move from that into a role where it is viewed as important, it’s a helpful list of the basics. I would not suggest using it as a sole source of information, just a list of topics to understand.
Well, I didn’t mean studying it was ridiculous; I meant that judging programmers on whether they know, say, what a circularly-linked list is seems ridiculous, unless maybe their résumé includes “wrote a new interframe memory allocator for AAA game” or something. It’s a symptom that somebody has a ridiculous interview process. I like studying this stuff, myself, and I think it’s useful under some circumstances, but it seems like a dumb way to judge someone.
Certainly agreed that it should never be about memorization. The best interviews I’ve seen are more along the lines of, how would you come up with a novel structure or algorithm for this problem? But that requires a lot of experience, and a carefully-chosen problem, to fit in the time available.
In some memorable technical interviews, I’ve been asked how to build an index to optimize RMQ (although they didn’t call it that) and what would be needed to design backspace in a text editor with a variable-length character set where each character is either one byte with the high bit clear or two bytes where the first one’s high bit is set and you just have a pointer to the end of a bunch of these representations appended to each other. It took me quite a while to figure out that second one, because I was thinking of UTF-8, where the representation is self-delimiting even when you read it backwards, but surprisingly I got a job offer anyway.
I was turned down by a job at Google because I don’t know Big O notation for different operations on various data structures. I obviously do know the speed difference between them and when to use them etc., I just didn’t know how to express that in the way they wanted. Apparently I can learn it and reapply whenever I feel like. It’s been 3 months and I haven’t bothered yet (I was also approached about the job, I didn’t apply for it).
Bubble sort, but not heap sort? No hire.
Nothing about dynamic programming!
I’ve heard speculation that dynamic programming is popular at MIT, whereas memoization is popular at Stanford, and so you can tell which coast someone learned on… I am not in a position to assess the truth of this. :)
It didn’t mention memoization either…
True. :)