Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Data Structures for Coding Interviews

interviewcake.com

Post reply on HN
Print view View original

161–170 of 238 posts

Re: Data Structures for Coding Interviews

#161

Post by nxsynonym »

daliwali wrote: post #87

I got an impression who their target audience is, based on the examples used, drinking kombucha and listening to Spotify. All the young, beautiful people who wouldn't have ever taken a computer science course if it weren't such a lucrative industry to be in right now. Maybe with this guide they can pass an interview at a big company where they just twiddle with bits all day. I won't be holding my breath until they ca…

Blame the young, beautiful people all you want for not slaving away over a 4 year degree that puts them in the same position as 1 year of self learning would get them, OR blame the business yuppies who keep coming up with the SaaS business models that don't need anything more than plug and play code monkeys.

I understand memorizing data structures does not make a good engineer, but honestly who is still asking for cream of the crop engineers, especially at the entry/junior levels?

Re: Data Structures for Coding Interviews

#162

Post by gameguy43 »

Silhouette wrote: post #126
gameguy43 wrote: post #2

Original Author here. Happy to answer questions about this piece or coding interviews in general! And eager to receive any feedback. Thanks for the post!

Honest feedback (short version): Very nice presentation, but for me the content loses credibility thanks partly to some silly mistakes but also to glossing over a few too many details. Some examples: The integer overflow part has incorrect binary/decimal conversions all over the place. The example hash function used (summing elements modulo number of buckets) could be dangerous. I'm not generally a fan of showing bad…

Fixed the bugs in the integer overflow section!

Re: Data Structures for Coding Interviews

#163

Post by lmm »

seanwilson wrote: post #159
lmm wrote: post #147

Earlier quoted context omitted.

> I'd find it highly unlikely they could do that while being unfamiliar with core data structures and algorithms. A big reason to learn basic algorithms and data structures is not to reimplement them yourself but to help you design and understand your own algorithms and data structures. But you so rarely want to implement a new algorithm or data structure. I suspect someone who knows how to implement a red-black tree…

Yes, you should never be reimplementing something that's in a standard library and for what it's worth I would never expect an interview candidate to know how to implement a red-black tree. What I meant was that knowing core algorithms and data structures is important so you can recognise familiar problems so you avoid reinventing the wheel + you know where to look for answers. Maybe you have to use some clever combi…

What do you mean by "knowing core algorithms and data structures" then? Because for me that phrase would definitely include knowing how to implement your own red-black tree, hash table, linked list and so on.

Re: Data Structures for Coding Interviews

#164

Post by seanwilson »

swiley wrote: post #158
seanwilson wrote: post #115

Earlier quoted context omitted.

You'd really be fine hiring a senior developer that had no idea how a linked list, a hash table or a binary tree worked? Understanding which data structures are good for speed and memory usage is at a minimum required for memory constrained apps and dealing with large scale data.

> a senior developer that had no idea how a linked list How do you become a "senior developer" without knowing this? That was one of the first data structures I learned about when I was 15.

> How do you become a "senior developer" without knowing this? That was one of the first data structures I learned about when I was 15.

I swear I've interviewed several senior developers who couldn't even vaguely describe what a linked list or a hash table was. I don't know how anyone can say that's not a bad sign.

Re: Data Structures for Coding Interviews

#165

Post by lmm »

sidlls wrote: post #153
lmm wrote: post #149

Earlier quoted context omitted.

Of course your extra wage goes straight into maintaining that status with uncomfortable clothes, overpriced cars, a big house in the suburbs to support your trophy family who you then spend hours of unpaid overtime avoiding... I mean you do you, but any job is going to involve a certain amount of doing stuff; personally I find CS algorithm puzzles a lot more fun than status games.

Status games? Hours of unpaid overtime? What are you talking about? The engineering managers (below the "C suite") everywhere I've worked have more or less kept the same hours as I have, dressed to the same standard, and used the same commute options as anyone else.

When you say things like "treated like a monkey expected to do tricks on demand", you're playing status games.

Re: Data Structures for Coding Interviews

#166

Post by CodeMage »

nxsynonym wrote: post #161
daliwali wrote: post #87

I got an impression who their target audience is, based on the examples used, drinking kombucha and listening to Spotify. All the young, beautiful people who wouldn't have ever taken a computer science course if it weren't such a lucrative industry to be in right now. Maybe with this guide they can pass an interview at a big company where they just twiddle with bits all day. I won't be holding my breath until they ca…

Blame the young, beautiful people all you want for not slaving away over a 4 year degree that puts them in the same position as 1 year of self learning would get them, OR blame the business yuppies who keep coming up with the SaaS business models that don't need anything more than plug and play code monkeys. I understand memorizing data structures does not make a good engineer, but honestly who is still asking for cr…

At the risk of sounding like a cranky old codger, I'd like to point a couple of things out. If all you have are "plug and play code monkeys", all you'll have is shitty software. The fact that shitty software is "enough" for so many businesses is just another symptom of the biggest problem with our society: we optimize for profit and damn everything else.

Re: Data Structures for Coding Interviews

#167

Post by sidlls »

lmm wrote: post #165
sidlls wrote: post #153

Earlier quoted context omitted.

Status games? Hours of unpaid overtime? What are you talking about? The engineering managers (below the "C suite") everywhere I've worked have more or less kept the same hours as I have, dressed to the same standard, and used the same commute options as anyone else.

When you say things like "treated like a monkey expected to do tricks on demand", you're playing status games.

Ah, I see. You don't believe you're playing what you call a status game, even when you are.

Re: Data Structures for Coding Interviews

#168

Post by seanwilson »

lmm wrote: post #163
seanwilson wrote: post #159

Earlier quoted context omitted.

Yes, you should never be reimplementing something that's in a standard library and for what it's worth I would never expect an interview candidate to know how to implement a red-black tree. What I meant was that knowing core algorithms and data structures is important so you can recognise familiar problems so you avoid reinventing the wheel + you know where to look for answers. Maybe you have to use some clever combi…

What do you mean by "knowing core algorithms and data structures" then? Because for me that phrase would definitely include knowing how to implement your own red-black tree, hash table, linked list and so on.

I mean knowing the memory and runtime costs of basic data structures like binary trees, linked lists, hash tables and arrays along with typical algorithms applied to them like insertion, removal and searching. Implementing each of those data structures (naively at least) shouldn't be challenging if you understand how they work.

Red-black trees however are notoriously fiddly to implement; just knowing they exist is good enough in my opinion and you'd likely never have to implement anything remotely similar. I'm not advocating memorising implementation details but learning general concepts.

Again, I'm not saying you should be writing your own version of these data structures but knowing they exist and recognising when you're implementing something that fits their mould is helpful.

Re: Data Structures for Coding Interviews

#169

Post by [deleted] »

CodeMage wrote: post #166
nxsynonym wrote: post #161

Earlier quoted context omitted.

Blame the young, beautiful people all you want for not slaving away over a 4 year degree that puts them in the same position as 1 year of self learning would get them, OR blame the business yuppies who keep coming up with the SaaS business models that don't need anything more than plug and play code monkeys. I understand memorizing data structures does not make a good engineer, but honestly who is still asking for cr…

At the risk of sounding like a cranky old codger, I'd like to point a couple of things out. If all you have are "plug and play code monkeys", all you'll have is shitty software. The fact that shitty software is "enough" for so many businesses is just another symptom of the biggest problem with our society: we optimize for profit and damn everything else.

[deleted]

Re: Data Structures for Coding Interviews

#170

Post by gameguy43 »

rootlocus wrote: post #123
gameguy43 wrote: post #67

Earlier quoted context omitted.

Author here :) Thanks for the note--this is interesting. Target audience is folks who never learned this stuff, or learned it but forgot it. Interesting to hear you had a different assumption from the title. If you want something trickier, check these ones out: https://www.interviewcake.com/question/stock-price https://www.interviewcake.com/question/swift/find-duplicate-...

I really enjoyed "Find a duplicate, Space Edition™", unfortunately I needed the last hint before finding a solution that doesn't modify the original array. Suggestion: Don't show hints for steps I already skipped. I stopped at "We can do this without destroying the input.", but had to scroll through all the hints before reaching the one I needed.

Good idea!
Post reply on HN