If Hacker News hates this, they'll really hate Vaidehi Joshi's explanations of data structures https://medium.com/@vaidehijoshi. She explains them in simple terms AND she's a woman. Hope your heads don't explode, boys.
Data Structures for Coding Interviews
191–200 of 238 posts
Re: Data Structures for Coding Interviews
#192Earlier quoted context omitted.
Nailed it. I have a very hard time explaining to my youngster colleagues that they're neither "engineers" nor "scientists'. Now I can use your words.
I have an actual engineering degree and write code that controls some sophisticated hardware. Am I allowed to be called an engineer and not an artisan or whatever?
I don't even have a degree and I write web stuff and I still call myself an engineer.
We "design, construct and test structures, materials and systems while considering the limitations imposed by practicality, regulation, safety, and cost."
Anyone who doesn't take a systematic approach I suppose might be an artisan, but the vast majority of software engineers I've worked with in my career at least attempt to use a systematic approach of learning and building processes.
Re: Data Structures for Coding Interviews
#193Earlier quoted context omitted.
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.
Oh I agree completely. I just take issue with the fact that it somehow is a "youth problem", as is being pointed out by the parent comment. It's a business problem, not a lazy millennial/education problem. Stop hiring shitty coders and you'll stop getting shitty interviewees. Less shitty interviewees means less need for these types of "beat the coding interview" services/blogs. Honestly a lot of times the comments in…
I'm not defending such comments, but there's more to them than just gatekeeping. Speaking from my own point of view, the "I was a geek and it wasn't cool" sentiment comes from feeling betrayed by having your lifestyle become an industry that too often focuses on profit more than on quality; the "I know CS from the ground up" comes from frustration with all the people who dismiss learning from the ground up without understanding all the insights it gives you; and "nobody deserves to have an easy path to being a coder" is an exaggeration of "when you try to make learning easier than it can really be, you end up dumbing things down".
Recently I found myself struggling to formulate my attitude towards software development and the best I could come up with is "lifestyle coding": sure, it's important to me to make something people will use and like, something that will improve life in some aspect, but in the end, I'm in this because I love to create programs. To me programming is more than my job, more than just means to an end, it's what I truly enjoy. People like me will often feel bitter about many aspects of our industry and it takes a conscious effort to keep aware of that feeling and to make sure it doesn't taint our decisions.
Re: Data Structures for Coding Interviews
#194Earlier quoted context omitted.
http://datascientistjobinterview.com
It's crazy that there is a whole industry dedicated to cheating ahem gaming job interviews in software/IT. Imagine if doctors or lawyers or real engineers did this. No wonder we can't get taken seriously as a profession.
Imagine if docs could be rejected from a new job because they failed to repeat the obscure diagnosis that was featured on the last episode of House, that really has nothing at all to do with the job they wanted to do.
Imagine if lawyers could be rejected for not being able to explain the minority opinion in Foobar v. Bazquux, which again, has absolutely nothing to do with their expected duties as prosecutor of poor people with small amounts of marijuana.
Imagine if real engineers were asked to build a suspension bridge out of silly putty, table salt, and carbon fiber.
The interviewees are simply doing their jobs, which is to analyze a problem and implement the most cost-effective solution. The interviewers are the ones causing the problem. Granted, it isn't always because they are non-technical people trying to gauge the value of skills they don't understand. A lot of times, it is because the interviewer is a tech person that still can't effectively gauge the value of skills they do understand, and also wants to look clever in front of a stranger, subtly discriminate to preserve "culture", and do the same stuff to others that had been previously done to them in their interviews.
Re: Data Structures for Coding Interviews
#195Earlier 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.
By claiming that you was senior engineer on previous project. Usually right after first slightly less experienced person appeared. Alternatively, by having assigned task that you did without much supervision (cause nobody had time).
Judging from observation, people become seniors after being employed for about four months (including part time period).
Re: Data Structures for Coding Interviews
#196Earlier quoted context omitted.
My point was that most of the time one doesn't need to know how they work in the first place for the vast majority of programming. Simply memorizing or referencing a card with very simple performance metrics (e.g. "dict: fast map of keys to values; array: very fast lookup by integer index") is sufficient for most cases today. Very few people who are doing any programming work need to know that the "dict" is a hashtab…
If someone can memorise how a dictionary and an array work, why would they have trouble quickly understanding how a hash table works for example? To me, coding for years and never coming across or being curious about understanding hash tables when they're applicable in so many places and not hard to understand is a bad sign. I don't care about more esoteric data structures but linked lists, hash tables, arrays and bi…
They wouldn't necessarily have trouble understanding what's under the hood, and that isn't my contention anyway: I contend that whether they can and whether they need (or even ought) to do so are separate questions, most of the time with the latter answered in the negative.
Re: Data Structures for Coding Interviews
#197Earlier quoted context omitted.
I never had a software development job where optimizing memory consumption and handling large scale data (for whatever definition of large was for that particular system) wasn't a necessity. It was also useful to know when these measures were and weren't needed depending on the context in the system. I do mostly what's called "systems programming" and did embedded previously but also did some work on "normal" softwar…
I do mostly what's called "systems programming" and did embedded Sure. And what's most crucial to do in those fields is not necessarily what's most crucial to do in other fields. 99% of interview horror stories are basically someone saying "I decided this is an important thing based on my narrow perspective, and anyone who doesn't know it as well as I do will be dismissed as completely incapable".
I agree with what you wrote in theory. But when the narrow perspective is clearly shared by majority of employers and simultaneously it takes like a weekend max to refresh linked list, bubble sort and other few shared datastructures, then the test basically boils down to "are you able to learn this". Which is imo fair test.
Re: Data Structures for Coding Interviews
#198Earlier quoted context omitted.
Good CS fundamentals are important because they are transferable skill to a wide array of problems a startup may face. Just because someone wrote an impressive framework or library doesn't mean given a complex problem outside of their known domain (web framework design or package management tool), they would be have the necessary background to solve it. With strong math and CS knowledge, you can reason through almost…
> Good CS fundamentals are important Yes they are. Except, these interviews aren't testing for that. Finding the maximum sum subarray isn't testing for any fundamental. > Just because someone wrote an impressive framework or library doesn't mean given a complex problem outside of their known domain Why are you even hiring them for something that's not their expertise? Seriously, that's literally the whole point of th…
> Finding the maximum sum subarray isn't testing for any fundamental.
There is quite literally nothing more fundamental to computer science than data organization and access.
And for what it's worth, Google and others are very open about their hiring process: they want generalists. I assume they have the data to justify that's a better investment. So maybe DHH or whoever gave the impression they weren't interested in doing anything they haven't already mastered. We have at least a little bit of evidence that attitude could be the problem: many of these anecdotes are disgruntled people who (often profanely) publicly vent when a company rejects them. Maybe that attitude comes out during the interview when they're asked to do something they deem to be beneath them.
Re: Data Structures for Coding Interviews
#19912 years of professional coding, still haven't been able to use my data structures knowledge!
You've never chosen to use a set over a list because it is quicker to see if a value exists in a set?
You've never had to choose between an array and a list?
Re: Data Structures for Coding Interviews
#200Earlier quoted context omitted.
I guess it's a nice gesture, but this does nothing to address my point that, as far as I can tell, recommending interviewing.io to anyone is wildly inappropriate, and I can't see how it happens at all. (Not that you're the proper person to address that; it's more of a question for gameguy43 et al.) Are the people giving interviewing advice not actually even attempting to do the things they're recommending?
In the past, interviewing.io was free for anybody to try (it was when I looked at it three years ago) and if somebody hasn't looked at it recently they might not know when the situation has changed.
We're still free, and we always will be.