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 can produce something useful.
This is what you get when you commoditise Computer Science. The article is about coding interviews and then goes on to deliver a lecture about "Computer science in plain English". Isn't it common knowledge that Computer Science and coding are like chalk and cheese?
People used to study DataStructures for a whole semester to get a deep understanding of how these work, and the time/space complexities affect system design. But now we get a pop-culture laced listicle that people will use to ace the interviews and write mediocre software. Does anyone wonder why there aren't listicles like this for Structural Engineering/Thermal Power Engineering/Mechanical Engineering etc?
No wonder we get data-breaches, password leaks, system outages, because we continue to treat Computer Science/Software Engineering as the next fad to make quick buck, and not science.
It isn't science, or engineering, because many of the things that count in computing defy measurement :
- code quality
- software productivity
- expected time between failure
- tolerance to error
- expected life in field
- usefulness to users
Because the science and engineering cultures of computing have failed to address these effectively, or even create cultural norms that support their development, a craft culture has evolved instead. Coders are artizans rather like clock makers in the 16th century.
> Because the science and engineering cultures of computing have failed to address these effectively
That doesn't automatically make coders 'Artists'. There is a huge gamut of software outside the CRUD world of HN. Software that runs mission critical applications like Mars Rovers, power plants, Public transport systems, etc. We should have a fair amount of rigour to ensure the software being written is rock solid, and taking shortcuts to learn basics of CS is bad.
Artizans, not artists. But I agree with your point, failure to understand hashtables is like failure to understand the secret nail in carpentry (I choose this as I've never understood the secret nail in carpentry and therefore do not count myself much of a carpenter).
We shouldn't delude ourselves, software (at the moment) is a craft discipline and craft disciplines can have huge blind spots. Comp-sci needs to spend real effort on the hard to do questions like working out how to make systems usable and other corner cases which are ignored in favour of reams of papers about verifiability and modular composition; note I am not against this work, but I just don't think it should be funded while the experience of watching a six year old trying to use google or a mac is as humiliating (to a professional) as it currently is... and boy is it.
I second the artisanal mindset that you have elaborated, and it will be better for everyone if we adopt the craftmans mindset (Which Cal Newport also talks about). I personally feel that we should model Software Engineering like the Apprenticeship model in Germany. It would be interesting to see how it fares.
I had someone reply to one of my comment that they 'didn't know about the Vietnam War because they weren't born then'.
... I feel like our discipline suffers from a lot of the same problems. IBM mainframe experience doesn't translate into knowing the intricacies of React, but it does provide wisdom on systems and usability problems people coding in React are going to run into too.
Glorify the new, but be informed by that which came before. Otherwise doom, repeating, etc.
Not that I'm disagreeing with you there, but I've also seen the opposite. I've had conversations with people who know their mainframe environment inside out but have no idea how a modern computer really works.
I'm under the impression that it often comes down to a combination of Dunning Kruger and a certain unwillingness to inform oneself about "new" things (i.e. things one doesn't know about yet) - and those seem to exist in both camps. So, just maintaining Aristotle's mindset and keeping an open mind seems like a good starting point to me in that regard.
Job offerings look for "engineers" while they mean coders. Young person who think he/she does not count as engineer will pass over that job, despite being fully able to get it and work there. "You are not actually engineer" is bad advice in current job market.
(I used to be that young person and used to pass on opportunities because of superficial reasons like that.)
Better for competition who gets the job with the same qualification and skills maybe, better for you personally (in both terms of what you learn and how good jobs you get) - no.
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?
As my dad always says, "you can call me a jar, as long as you don't smash me to bits". Since Slavic proverbs don't always translate well to English, it might be best to clarify: what you call yourself is not as important as what you do.
What @sgt101 wrote about measurements is an important and insightful point. Does it mean we can't call ourselves engineers? That's a discussion that won't be resolved any time soon. Personally, I care more about the job itself, than about the label you slap on it.
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.
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?
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 these threads amount to "I was a geek and it wasn't cool, I know CS from the ground up, and nobody deserves to have an easy path to being a coder". It's an exhausted form of gatekeeping and doesn't make anything better for anyone.
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.
A four year degree at a quality program will open up a lot of jobs that the one year of self learning will not prepare you for.
That's not to say one year of self learning won't prepare you for a lot of programming jobs, or that the person with the four year degree won't be starting at one of those same jobs. But there are a lot of types of software I would only want someone with a real CS degree writing.
(Of course, 1 year of self learning, plus 3 to 4 years of real world coding plus further supplemental self study, could very well get you to the same level as a CS grad's knowledge, or beyond.)
I wasn't suggesting that a 4 year degree confers any advantage. I think it's merely status signalling to potential employers. Practically speaking, my degree only helped me at one point in my life: moving to a foreign country.
There's nothing wrong with software that only needs code monkeys to write. It doesn't have to be technical masterpiece to be useful, or valuable to business. Just think of all the code monkeys with jobs.
Basically every place I've worked for in the last 35 years has been desperately seeking new grads who can actually program a computer. And it's getting harder to find them.
Are we now blaming young people for looking at employment perspective before picking up major? Or are we blaming them for trying to learn?
Because last time students were mentioned, they were blamed for picking up unpractical major unlike everyone older in STEM who was supposed to make more rational choices (as supposedly proven by them not picking humanities by passion).
This is not blaming of inadequate teaching methods: "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 can produce something useful.
"
This is bull shit. Are you also the kind of guy (I know you are a guy) that is also on the "look out" for "fake" geek girls? The homepage looks a lot like the programmers I meet. Do they need to be overweight and not care about how they look to be real programmers that can actually produce something useful?
The projection in your comment is unreal: a just world fallacy where only unattractive people can be smart, attractive people are mindless, which was definitely not the point.
How exactly is this projection? Your original comment was stereotyping real developers based on their appearance. They were not "legit developers" in your eyes because of how they looked. I am looking at the home page photos and it is not like they all look like models. They are younger and better looking than average but they would not look out of place on any dev team. This nonsense about what a developer looks like is pure bullshit. Why assume that a person is any less of a legit developer based on your image of how devs look? Why is more OK than any other kind of stereotyping? How is it better than stereotyping woman and driving?
It was clearly not my intention to judge programming competency by appearance. But it is also undeniable that the industry does select for young, good looking people.
To be honest, your comment doesn't make you seem like you're someone who actually knows anything about or is particularly good at coding -- rather, it makes you seem like someone desperate not to have to compete with a larger field of candidates, and grasping for any reason you can find to claim they shouldn't be allowed to try for the same jobs as you.
Also, I'm quite sure someone could easily come up with comments just as arrogant as yours, about you.
Usually, any "(X) for Interviews" post is a review of things that in theory a programmer learns very early on and then forgets due to disuse (since most programming interviews are essentially pop quizzes on such things).
The ironic thing is that this biases toward the most newly-minted programmer; actual experienced working programmers rarely need to implement basic data structures or their relevant algorithms from scratch (they rely on existing implementations), and so move them to dusty disused corners of their minds, while newly-trained programmers with no job experience have been regurgitating these things on exams quite recently.
So even the dismissiveness is wrong -- the original commenter is, to be honest, less likely to pass such an interview without remedial study, compared to the "young, beautiful people drinking kombucha and listening to Spotify" being sneered at, who probably have been taught more recently and have it fresher in their minds.
It should be mandatory for programmers to be able to concoct even bad examples of a sort algorithm in real time and create data structures for anything from a linked list to binary trees.
It is also important to have candidate code samples
for an interview with dissection and analysis by the candidate. This is to understand where the programmer is in their professional development, how much is copy-paste and how much is functional and design integration. All this demonstrates level of knowledge and the candidates productive approaches.
Having to teach programmers how to deal with recursion and other fundamental concepts or language specific approaches like pointer arithmetic or interpreted language nuances like lambda calculus and list comprehension should not be on the table.
All modern software is built on layers upon layers of leaky abstractions. If you view fundamentals as nothing more than hazing rituals, you won't even be aware of just where the abstractions start to leak and you'll end up writing shitty code. Of course, it's perfectly possible nowadays to do so and let it be an SEP (Somebody Else's Problem).
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 can produce something useful.
You don't see any arrogance here? All it needed was an avocado-toast reference to be indistinguishable from a "why millennials are terrible and my generation is much better than them" thinkpiece.
I'm a millenial myself, not older than the people I am critiquing. (after looking up your profile I realize that I am much younger than you)
My comment was made in jest, pointing out how incongruent technical interviews can be to the job they're interviewing for, which I think doesn't imply any arrogance. Maybe you are reading it differently.
Big yellow newsletter box interrupts my reading that I was compelled enough to open inspector and remove it.
The pricing makes no sense, that or its not obvious what you are getting in the full-course.
The testimonials appear phony. I believe in products when I recognize programmer celebrities or the testimonials link to a github or something to prove they are legit.
The pay box is sketch. Even though its powered by stripe. I'm not dumping my credit card without CVC, expiry and postal code.
There's nothing on here you can't already find for free. The value to me is saving time. I've done this before but forget because web-programming the last 10 years rarely required to commit this stuff to memory.
I'm a different use case I suppose but I want a super abridge version. I just don't want to a spend a week. I want to spend a few hours.
Theres nothing telling me how much time I will spending having to read through this course material.
I think these types of questions are a good filter for the big tech companies, just in a different way than most suspect. What these types of interviews filter for is...
- People fresh out of college and therefore relatively young. It would be illegal to make this an explicit policy.
- People who really really really want the job. All employers want to filter by this criteria.
- People who will accept the status quo and tolerate absurd bureaucracy.
> - People who really really really want the job. All employers want to filter by this criteria.
But then you miss out a lot of brilliant people who "just want" (instead of "really really...") the job, but think that it is not worth to allocate month(s) for preparation.
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.
Yes,I'd be fine with it as long as they could read and understand a table of data specifying the time and space complexity of various data structures and algorithms.
The amount of programming done in memory constrained apps and for large scale data is tiny in comparison to all programming, most of which is very basic CRUD type work meant for use in resource rich environments at small scale.
> Yes,I'd be fine with it as long as they could read and understand a table of data specifying the time and space complexity of various data structures and algorithms.
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.
> The amount of programming done in memory constrained apps and for large scale data is tiny in comparison to all programming, most of which is very basic CRUD type work meant for use in resource rich environments at small scale.
Those were just examples. I've seen plenty of cases of code for CRUD apps that had problems handling just a few 1000 records because the coder didn't understand memory usage and algorithmic complexity. I'd certainly want lead/senior developers to have this knowledge even if it's rare they have to step in to help in this area.
> 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 is, all other things being equal (and I know all other things would not be in practice, but bear with me), worse for most programming jobs than someone who doesn't (but who knows what its performance characteristics are) - you'd never want a programmer to implement their own red-black tree, that's a maintenance nightmare even if they do it correctly, you'd want them to use the one from the standard library.
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 combination of data structures to model your data efficiently. Maybe your data is actually a graph so now you can lean on graph algorithms. Maybe you just realised you're naive implementation to answer some question about your data has n^2 growth so now you can consider if a different data structure would help.
Personally, I find people that have poor knowledge of data structures and algorithms are the ones that will reinvent the wheel the most as they don't know what exists already.
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.
Being able to implement off the top of one's head is a skill that fades as soon as one is no longer required to do so.
Requiring it as a criterion of hiring is, essentially, a back-door way of saying "we only hire people fresh out of college", since they're the ones who've recently been having to do this stuff on exams and have it fresh in their minds.
> Being able to implement off the top of one's head is a skill that fades as soon as one is no longer required to do so.
I haven't implemented a hash table, linked list, growable array or binary tree for years but know I could because I understand how they work and I select which one to use often while coding. I find it hard to understand how you could claim to know how those data structures work and not be able to implement them.
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 hashtable or some esoteric data structure with similar performance, or even anything else at all about it except for the API for it.
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 binary trees should be basic knowledge.
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.
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.
The analogy doesn't extend other fields, so I would be skeptical that it holds in computer science and software engineering.
Consider, for instants, a data scientist who does great in Kaggle competitions but has a poor understanding of probability theory. That data scientist will not be able to estimate or control the error in their models effectively, and will not even know that there is a way to do so. You do not want to hire that data scientist for a senior role.
Software development is the art of abstraction, and it works both ways. Do other industries have anything like the "not invented here" problem that software does?
I can't speak for other industries necessarily, but I would suspect the answer is "yes". It's certainly rampant in all forms of social science academia. It's mercifully absent from professional data science in many places.
"The amount of programming done in memory constrained apps and for large scale data is tiny in comparison to all programming, most of which is very basic CRUD type work meant for use in resource rich environments at small scale."
Thus, the other article on the front page about the staggering space requirements for phone apps.
It's amusing that you think these apps are developed by people who aren't CS grads that have not been put through the absurd hazing ritual that is the modern interview.
Look at Facebook's monster, for example.
The reason these apps are bloated is because too much attention is paid to basic CS and not enough to engineering.
I don't understand this kind of reasoning. Why would knowing basic CS correlate with you not caring about memory, storage and CPU usage? It's really grating to be tarred with this brush that having an academic background means you don't know how to optimise or write practical code.
Surely not having a basic CS background means you're not going to be great at picking the right data structures and algorithms? Coders that over abstract and build layers and layers of interfaces likely didn't learn that from university.
> Why would knowing basic CS correlate with you not caring about memory, storage and CPU usage?
It wouldn't necessarily, but I didn't make that claim. GP's claim was that these apps are bloated because a lack of knowledge of CS fundamentals amongst developers who write them. I pointed out that one of the biggest offenders, Facebook, has a strong bias towards hiring people with strong skills in CS fundamentals.
Most "senior developers" I know don't know much about data structures. Standards are pretty low in the industry. One reason might be that optimizing for memory consumption or handling "large scale data" almost never happens in practice.
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" software but in all cases it was useful to care memory, data structures and performance at some levels of the system.
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".
If you're already good at programming and didn't learn computer science foundations along the way it should literally take you a few hours to understand the majority of the core data structures. I don't understand why people complain about common interview questions when you can readily learn the answers in advance.
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.
I work on embedded devices and no one really cares whether changing a setting takes 30 seconds or 30 milliseconds. It does not matter that most of the RAM is wasted by unnecessary copies of unnecessary data. People still buy these devices as long as they solve a problem at the end of the day.
I personally don't agree with this reasoning, but that's how businesses operate.
> Most "senior developers" I know don't know much about data structures. Standards are pretty low in the industry.
Even if standards were low, the point of an interview is to gauge the standard of the developer. Algorithms and data structures knowledge is important.
Important for what? For interviews? In the real world, inefficient software wins because it appears to do more work. When the slow behemoth has to learn a new trick, you feel like a hero for taming the beast. You get praise when you reduce the runtime of something from five minutes down to four minutes. You don't get time to rewrite the mess so that it would complete in seconds. That would obviously be impossible because we just spent weeks on the one-minute improvement, right? With a bit algorithmic knowledge, this kind of speedup would be possible, but the knowledge is rare.
One could even argue that the algorithm interview trope is harmful because it puts this type of knowledge in the "useless in practice" drawer that will never be opened again.
How important though? Rarely does it come into play from my experience, at least for those who work in predominantly the UI layer on the web. Even at my job at Big Co. as a senior engineer (algorithms/data structures knowledge is necessary to pass the interview process here), it hasn’t manifested in a significant way, at least not compared to other skills such as architecting systems for maintainability, identifying the cause of bugs & fixing them, and collaborating with other engineers to implement something the best way possible.
I'm not saying it's impossible to code without knowing this stuff, just that it gives you an edge as it helps a lot when you have to deal with memory and speed constraints. If you're coding UIs for web apps, you're probably not going to run into issues unless you're dealing with large collection or collections where the record sizes are big. If you're writing backend processes, mobile apps, games, embedded apps, graphics processing apps etc. knowing algorithms and data structures is important.
Would you really want to work with an architect who had no understanding of algorithmic complexity, linked lists or hash tables? An architect needs to know how to design something that will scale to the data involved; I don't see how you can do that if you're ignorant about basic data structures and algorithms.
If a backend process is slow, you buy another server, install Hadoop or something and call the whole mess "big data".
Mobile apps are known for taking ages to load and for taking too much space. They usually block on network requests and are eager to throw information away before blocking on a request to fetch the same information again.
Embedded applications know what hardware they are running on, so they can waste all of the available resources. Extending them later is often very difficult due to that.
In realtime graphics the required knowledge is very specific to realtime graphics. 101 algorithms won't help you at all.
In non-realtime graphics, who cares? Let's spend this quarter's budget on a redesign of the progress bar so that we can have meetings and beautiful powerpoints.
> 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.
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).
In that one wouldn't want to hire someone as a marketer who couldn't spell "cat"?
Not because it's necessary to be able to spell "cat", even, but because the inability to do so might indicate in a bayesian sense that the person is not likely equipped to do the job.
Not really apt as to spelling bees. High-level spelling bees try to use words that are as obscure as possible, because people will happily go forever on words they know.
SAT vocabulary questions are chosen to be informative about the test taker's IQ; spelling bee words are chosen to be unfamiliar to everyone. You get a list of words that you're supposed to memorize; they could just as easily be random strings.
Exactly, it's analogous to how companies seek obscure interview question variants, sometimes explicitly stating that their goal is to to see "how you think" rather than to get the right solution.
What happens if we have the number 256 in an 8-bit unsigned
integer (1111 1111 in binary) and we add 1? The answer
(257) needs a 9th bit (1 0000 0000).
and I didn't read any further. I don't think many interviewers would be eager to continue after hearing that, either.
I think you're being a little bit unfair. The same block then continues:
This is called an integer overflow. At best, we might just get an error. At worst, our computer might compute the correct answer but then just throw out the 9th bit, giving us zero (0000 0000) instead of 257 (1 0000 0000)! (Python actually notices that the result won't fit and automatically allocates more bits to store the larger number.)
The article is introducing the concept of integer overflow.
Anyone who claims to understand integer overflow from actual experience, rather than memorizing textbooks, should know that by inspection.
I'd forgive that in a CS grad (possibly) but if someone claimed to have been working in C or other unsafe languages for more than a trivial amount of time I'd be very suspicious.
This is a good cheat sheet for those who don't have (or have forgotten) the knowledge but want to game an algorithm heavy interview. The problem I got with this is exactly the same as when I tried reading the "Cracking the Coding Interview" book:
I got through a few chapters and then the author mentions something off the cuff with an assumption that the reader will know what they mean. But of course, I don't, because these books are basically a collection of cheats and hacks. I get frustrated that I don't understand it, so I seek out something that starts with the fundamentals and expands from there.
What I'm trying to say is that I'd rather slog through 900 pages of Sedgewick and come out with a thorough understanding rather than try 20 quiz questions to be stumped by whatever the hell they were trying to get at with question 21 and then give up.
CEO of Interview Cake here. We work really hard at trying to not do this.
Feedback on where folks get left behind is pure gold to us, because it lets us know what we need to smooth out next. We're not trying to be the /biggest/ resource out there--we're trying to be the /smoothest/.
For this article, do you remember where specifically you got left behind?
To be fair to your article, it actually reads quite well and has good detail for what's covered. I thought the big-o coverage was a bit sparse, but I also didn't see the expand link the first time.
i have the same feelings about "cracking the coding interview"
the day someone unironically asks me to "Write an algorithm to print all ways of arranging eight queens on a chess board so
that none of them share the same row, column or diagonal" - I will jump off a bridge
I went to a CS high-school (not university) and we studied backtracking in the first or second year. Everyone was supposed to know how to solve this and similar problems for tests.
Sure, you'd know that right after a CS high-school - however, if after that school you go on to work on real problems for a decade or two, then you won't know that anymore, since outside of very specific domains you don't really write such things from scratch anymore; you'd always want to use existing, optimized&tested implementations of all the common and less common data structures and traversal algorithms instead of rewriting them.
You forget what you don't use, and this is stuff that you don't use.
IMHO the big problem is that they're missing the point on why we ask students do do these algorithm implementations - it's not so that they'd learn how to do that (though a bit of general programming practice is useful), we put them there as hands on exercises so that students would understand the usage of these algorithms better.
The implementations are just a learning aid, not a learning goal. Asking to reimplement a red-black tree is somewhat comparable to asking what was shown in a particular instructional video or what practice problems were assigned in that class - checking if you remember the details of a particular teaching instrument.
Or you can refuse to do that and then work on getting a position where you aren't treated like a monkey expected to do tricks on demand and also have a better wage and social status.
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.
The perspective that it's all a status game is legitimate in its own way, but not the only way to view things. I find there's a useful distinction to draw betwen trying to influence people's perceptions directly versus trying to do something valuable and trusting people to perceive it for themselves, and find the latter a lot more fun than the former.
See, the thing is that you keep calling it a "status game" when it's not really clear what you mean, other than to belittle work others do because it isn't solving algo puzzles.
I bombed an interview last week. Five straight hours of whiteboarding. One of the interviewers (just a year or two out of school) admitted he got his questions from interviews he went on in the past. What he didn't mention was whether or not he answered the problems correctly. What if I was being judged for not being able to solve something he could not solve himself?
People that ask these types of questions take the easy way out. It's a lot harder to ask thoughtful questions that really try to gauge if somebody knows what they're talking about because you have to really understand things yourself. For instance, somebody can easily say they setup a pipeline that scales. Sounds great. Asking questions that makes them go into finer detail to make sure they're not bullshitting you is a bit tougher.
The article is really well written and has amazing design, but honestly does not seem very helpful. Isn't most of this learned in the first year of university? Who is the target audience in that case? Given the title, I hoped to learn some lesser used data structures rather than what a pointer is. With that said, I do look forward to future articles!
I suggest that you market the series in a different way, perhaps "An Introduction to Data Structures", or something along those lines. Out of all the bullets in your outline you really only cover lists (random access, linked) and hash tables as actual data structures. That's partly why I expected a totally different article based on the title.
You could argue that the others are technically data structures, but I'm willing to bet most people will assume your standard list, map, heap, trie, tree, graph, etc. It's kind of like saying "Calculus for AP tests" and then only covering algebra up to Riemann sums.
Thanks for the links, I'll give them both a shot.
edit: just remembered that Calculus isn't on the SAT :)
Definitely agree that the first half of the article isn't exactly data structures yet.
But I just struggle with calling something "An inroduction to X." Have you ever heard "an introduction" and thought "oh, that's what I need!" I picture a super-dry textbook. Or one of those YouTube videos that promises to teach you how to do a thing but starts off with the person saying, "Now, before we get started..." and talks about nothing for 5 minutes before actually teaching you the thing.
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.
> Target audience is folks who never learned this stuff,
But then why would they be interviewing for a coding job anyways? Shouldn't a coder know what's a RAM, and that it's different from secondary storage??
I'm thinking a lot about folks who come out of coding "boot camps." Those folks for the most part have /heard/ of "RAM" and "disc," but might not know why they both exist and what each one does.
The opt-out button: "I don't need more coding interview practice".
My first thought: Whoever designed this is super salty for me not wanting to provide my e-mail.
Out of all of the problems in my life, too much e-mail is certainly one of them. I like to keep it to a minimum. And as an adult, a weekly coding problem falls so down far on the priority list compared to all the other e-mail I'd get.
You've got a cool site and I appreciate all the hard work creating high quality content (I've looked at the free questions and considered subscribing a few times in the past). I think your business model/pricing could use work. Unless I'm mistaken and things are going well .. in that case, I'll withdraw to my cave :-p
My suggestion would be to have a slightly cheaper tier (probably no more than a hundred bucks). This mirrors the cost of two-to-three interview books. You could add a custom grading or personalized tutoring option for the full 500, or heck, even more (this is sort of like the GRE/GMAT prep option). Come to think of it .. I wonder why the GRE/GMAT prep crowd hasn't tackled programming interviews?
Thanks for the note. Definitely a great point. Not sure yet how we tier out our product, but tiered pricing is definitely the state of the art.
We've been working on some /tech/ to enable tiered pricing in the meantime. The Site's all custom, and so far there's no notion of a "product" yet...just "paid" and "unpaid."
Share your question re: where's Kaplan on this stuff!
Price seems expensive to me as well. In data science there is a similar site which has become pretty popular if you are interviewing in those top tech companies, but it is cheaper.
As the guy above was suggesting, that data science site does personalized feedback and that justifies the high price. Otherwise, the way it is now, it feels like it should be priced similarly to CTCI.
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.
Is it cheating or gaming the system if the vast majority of QUALIFIED engineers would not pass an interview without preparation? Reviewing these cheat sheets every couple of years is essentially part of the job.
Nice graphics! I really like from-the-bits-up explanations of things like this.
I found the newsletter upsell in the sidebar very distracting. I know you're considered a fool if you fail to bash people over the head with newsletter sign-up requests these days, but maybe just keep the ones interspersed in the text and get rid of the one I have to see all the time? Or I guess AB test it or whatever the cool kids are doing for this stuff. I dunno, but it really detracted from what I otherwise thought was great content.
It is a good site. I actually bought the product a year ago. But then I had to do something else which made me to not focus on getting an internship/job, and only recently I noticed it has a one year timeline. I think a one year time limit is too little for a 100 dollar product.
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 practice or incorrect examples when teaching, even at an early stage when the student isn't ready for the real deal yet, but if you must then you could warn the reader that it's a simplistic example for demonstration and shouldn't be used in reality. It would not make a good impression if a candidate said they knew about hash tables but then produced that function as an example of hashing.
Similar comments apply to the treatment of big O notation. I understand that your style is to try to avoid being scary and complicated, but big O is useful because it has a specific meaning. Even in the longer explanation, you hardly mention that fundamentally it is about scalability and bounds, and you mention the danger of overlooking the constant factor only briefly right at the end. Also, the casual initial characterisation as being relative to the size of the input sets up traps when dealing with more sophisticated data structures, such as graphs where you often need to refer to the number of nodes and/or edges when specifying complexities.
Cool site. C++ graphics programmer here. I would like to add that knowing one thing extremely well - even a fairly small thing - can have amazing results in interviews. I can write just about anything, on command, in GLSL.
This has gotten me more interview offers and job offers than I can count, and it really didn't take me all that long to learn.
I hate to promote memorization, but honestly, it works. Some people argue that memorization isn't the same as learning, and it's not. But it definitely helps you learn and increases understanding.
Nice site but your questions are pretty run of the mill these days. Would be nice to see some new, original questions :-). Also an option to schedule some mock interviews would be great!
I got this recommendation about a year ago and tried. The site stated that I couldn't register, but I could sign up for a place in the registration queue.
So I did that. I have yet to hear back from them. I don't quite understand how people keep recommending them, as if it was possible to use the site.
Hey, I'm the founder of interviewing.io. We're coming out of private beta soon, which means we'll be sending out invites to folks on the waiting list shortly. A year is a long time though, and I'm sorry you had to wait that long, so I figured least I could do was kick you an invite (check your email). Thanks for being patient with us while we figured things out.
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?
IIRC, folks who've recommended us on HN have used it (we get notified when people post about us bc it's obviously something we care about a lot). Sorry again about the delay, and I hope you like the product.
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.
Sorry; I meant 'free' as in there wasn't a waiting list but checking my email I see that I was on the waiting list at first, too. I guess I'll just testify that people have used it. :)
Your explanations were excellent. I especially liked the way you introduced hash tables using a simple array where the indices had special meaning.
The diagrams are clear and helpful.
Only nitpick: not sure how somebody who is supposed to learn what an array is by reading this is supposed to already know the meaning of Big O notation. So maybe a little intro to Big O complexity somewhere in there would help as well.
Eep! Did you notice that the first time we mention big O notation, you can click on it and an inline explanation slides down? Probably not, based on the question! We should make that part louder.
The problem with links is that you don't know where they are going to take you. When I have such a nice piece of text to read I don't want to click and potentially land in a completely different site, have to click "back" and all that distracting stuff. That's probably why your link didn't "register" with me. In your case in turns out the link nicely expands in place, so that's pretty cool. I'd still just inline that little explanation on Big O, since you keep referring to it in the rest of the text. It's more than a mere footnote.
Now this is all my own experience, and others may disagree, so don't necessarily go changing things just on my account!
> Don't worry—we'll skip the convoluted academic jargon and proofs.
Aaaaand this is why I hate using this as a method for interviewing. I actually care a great deal about people that care about that stuff. I would rather you know all the principles and can reason your way back up, however slowly, than repeat something you've practiced enough for an interview.
I understand the author really only wants to help people, but let me tell you as someone who works for one of the "cool unicorns" that the quality of software engineers is really bad, most likely because of this efficient "gaming of the system".
It's unfortunate, but all the companies are doing this.
Here's what a Google lead said in a tweet:
> Hello, my name is Tim. I'm a lead at Google with over 30 years coding experience and I need to look up how to get length of a python string.
DHH:
> Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles.
Max Howell:
> Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.
And yet, everyone is asking these questions about print a string in zigzag fashion or something silly like that.
Engineers are gaming the system because the system is garbage. None of us are looking forward to waking up and solving HackerRank, LeetCode and CtCI problems till the joy of programming leaves our bodies.
There's a difference between not being able to write bubble sort and realizing that looking it up is a better use of your time. But when it actually comes time to do something you can't copy/paste off the internet, what do you expect a programmer who can't reinvent a half-decent bubble sort to do? The interview is to convince the other person that you can think logically about programs. Bubble sort is a low, low bar, and basic data structures are not much higher.
Maybe he's being hyperbolic, maybe not. But that's entirely besides the point.
I'm absolutely certain that there are many, many engineers who failed interviews because they couldn't write a zig-zag string and could yet come up with good solutions to problems at a real company.
> what do you expect a programmer who can't reinvent a half-decent bubble sort to do
But interviews aren't testing for that. The guy who invented Homebrew was judged by a Google engineer to be not good enough. Heck, I bet the engineer interviewing him probably had his/her entire dev machine setup via Homebrew.
DHH invented Ruby on Rails, which was used at Twitter for what, 4+ years? And yet if he anonymously gave an interview at Twitter they would probably reject him because he can't find a cycle in a linked list in 30 minutes.
> The interview is to convince the other person that you can think logically about programs.
It's supposed to be about that. The modern CS interview is, however, absolutely not about that. It's whether or not you've grinded through CtCI enough to be able to answer something taken from a vast pool of useless questions.
Tell me, is the Homebrew guy just really not good enough? Do you really think he does not know how to think about programs logically?
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 any problem.
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 the interview. I don't think Max Howell was trying to get in to the DeepMind team.
Calling these just some other web framework or package management tools is doing them an incredible disservice. Twitter used Rails. Airbnb uses Rails. If Airbnb hired DHH, it would be Airbnb's fault if they made him tune hyperparameters of some ML model rather than see how their web performance could be improved.
Honestly, at this point I'm convinced I could get HN to talk poorly about John Carmack's programming skills.
> 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.
> Good CS fundamentals are important because they are transferable skill to a wide array of problems a startup may face
I'm really skeptical of this claim. Nothing about CS fundamentals prepares you for debugging mobile browser performance, or machine learning, or setting up a sharded database. Maybe the big companies have a reason for asking these questions, but few startups benefit from these types of questions.
From the POV of the large tech companies, it's mostly a matter of keeping the interviews short since the questions can be complicated yet fit in under an hour. The top companies are constantly growing, have ~3 year turnover and are flooded with applicants due to their name recognition. Why all the smaller ones copy this approach, I have no idea. The alternatives usually are just as unpalatable: pair programming, a long project, language triva questions, etc. So nothing changes.
>>I'm really skeptical of this claim. Nothing about CS fundamentals prepares you for debugging mobile browser performance, or machine learning, or setting up a sharded database. Maybe the big companies have a reason for asking these questions, but few startups benefit from these types of questions.
To summarize this statement, there's a reason why algos and datastructs is taught only for 1 semester out of 8 in college.
I'd much rather say a company like Google might have problems that require deep knowledge both inside and outside of someone's domain, but startups - no. They need to ship and optimize on the go, rinse and repeat.
> With strong math and CS knowledge, you can reason through almost any problem.
Until you can't. Math and CS, while certainly giving new perspectives, don't add much to the actual solution. What makes developers great is experience and not some text book knowledge of a topic. Hands on experience is a game changer.
Majority of the developers don't work and will most likely never work on something life-changing that they need to know every algorithm and data structure out there. Their time is better spent elsewhere.
That's a good one. My friends in engineering (physical sciences based, e.g. aerospace) and I have decided that the analog in that industry to programming interviews would for the candidate to be bombarded with questions asking him to evaluate complicated integrals from the CRC or something like it.
Yes, I can see the confusion. You see, we are looking for the very best Translators, and it has been proven by major companies that the people that are able to do the job best have a very solid foundation in the science translation is based in, such as Linguistics and Classics.
I would not be surprised if there were other, non-technical issues during such an interview. I know many people who are supposed to be smart, but they consider the basics beneath them and refuse to do anything by hand in the presence of people that might be subordinate in another context.
I'm sure I could do it in something pseudocodish, but it'd probably take an embarrassing amount of time. Honestly I could probably do almost as good a job of implementing quicksort, at least in a naive version based on the stack.
Seems to me that what interviewers should be looking for is not savants who can whack out particular odd bits of code but developers who can look up some things to use as reference as they go and most important who know how to determine what it is that they need. Proper evaluation and decision making is at least as important as actually writing the code, because those are the skills that can keep you from writing the wrong code.
With all due respect, I hear what you mean, but further supporting an interview system so divorced from actual problem solving (because most everyone who really really wants a job just endures the empty tediusness and memorizes these algorithmic puzzles from CTCI and Interview Cake and other sources) just enforces a kind of innane candy-empty arms race just like the SAT did, before it was clear that there were proven ways to master it. (the SAT has become just another pay wall at this point) The ultimate effect of this race is to render every programmer with the money and time to practice this equal. It is, forgive me, an infinite loop (sorry) -- and the bar will just get higher and new innane hoops will be added to the performing monkey obstacle course. Then, employers will be (or already are) selecting for a kind of navy seal squad of pedantry-- coders who like to submit and follow directions and behave themselves. Creative problem solving requires a bit of the rebel/subversive spirit. These kinds of interviews may test for an intrepid spirit. But honestly, There is no more intrepid spirit than that of an actual well-programmed machine. This popular interview method reveals that we are merely looking for programmers to be as similar to intrepid, well-programmed machines as possible. It results in machine-like workers working on machines. In effect, perhaps, the blind leading the blind. Is that what we want? I could be wrong, but I think we need to more highly value what humans bring to the task/process/team that computers can't. It seems less nihilistic, anyway. Or do we not know what that is? Maybe that is the real problem. Ironically, so many job ads say they are looking for "passion" in their programmers. Passion is at odds with what they select for. I wonder if the employers even realize this. My puzzle for them is: Given n programmers (all have memorized CTCI etc) ... so how do you decide what to select for and how would you implement an efficient, blind process that is more likely to include a diverse array of programmers who could work together hapily?
Ah, the perennial apologetics of weaponized mediocrity. If you can't write a simple recursive algorithm that swaps two values (Max Howell), two nested for loops (DHH), or show me that you used Python at least once (uhh length? yes, there is this builtin, I forgot its name...), why would I want to hire you over someone who has seen a computer before?
And to avoid being called hypocritical, here's off the top of my head how the answers would look like (I don't use Python very often either):
1. len(thingie)
2.
def bubsort(arr):
if not arr: return None
for i in range(len(arr)):
for j in range(i+1, len(arr)):
if arr[i] > arr[j]: arr[i], arr[j] = arr[j], arr[i]
return arr
3.
def revtree(node):
if not node: return None
node.left, node.right = revtree(node.right), revtree(node.left)
return node
> why would I want to hire you over someone who has seen a computer before?
Because, you know, they invented Ruby on Rails and Homebrew? Incredible, really. You were so adamant on being hostile that you managed to put yourself over Max Howell and DHH in a couple of sentences. These people have made valuable contributions to the tech industry as it stands today. This is a fact and not an opinion. They invented Homebrew and Ruby on Rails.
Good job, you solved the problems and are more likely to be hired by Google than Max Howell. Except he created the most popular package manager in OSX history and companies still can't see that.
> Except he created the most popular package manager in OSX history and companies still can't see that.
First, Homebrew is just a rehash of package managers that were available on
unices for more than a decade. Then, from what I hear, Homebrew was (still
is?) badly designed and implemented for quite a long time, which is not an
evidence of author's high skills (as a programmer, anyway).
Which part is ridiculous? The fact that Dpkg, RPM, their peers, and
infrastructure on top of all that (APT, up2date, Yum, BSD ports, Gentoo
Portage, and so on) existed for a long time before Homebrew, the fact that
people were constantly complaining about Homebrew breaking their installed
packages on update, the fact that it used to require /usr/local to be
user-owned, or the fact that it wasn't using (still isn't? I haven't checked)
cryptographic signatures for downloading software to install?
For the simple option of length, depending on what you've been working in you might be thinking of len, length, .length, strlen, sizeof, and undoubtedly many other variations of the same thing. Things that may come seamlessly and automatically when you're in the flow of actually coding in language X may be very difficult to choose between while standing at a whiteboard in a conference room
Ah, the perennial apologetics of weaponized mediocrity.
Don't look now, but you just failed every interview I've ever conducted. Maybe consider a field where the skill you've just demonstrated would be useful -- politics, perhaps?
To be fair, I am incredibly interested in the jargon and proofs. What I am not, is proficient in doing them on a whiteboard. Therefore, I do not expect someone else to be.
More, many of the interesting proofs that folks know took a long time to develop. Sure, you could probably throw some up on the board and speak to it. No, you are not likely to be able to derive one. And, I highly doubt that without practice would you be able to even get it on the board correctly.
Which brings up a major point. Discuss more in code reviews. Don't polish them trying to make them perfect. Make them part of your conversation with your peers where you are. I personally even feel recommend to throw up straw men sometimes. It can be odd throwing up a review for the team to see an idea on code you don't intend to push, but it can also be a good conversation. And someone else may be able to take that idea and make it awesome.
Which is ultimately what I want from a coding interview. If you have to handwave over parts, fine. Just be up front about it and hide it behind a function call. I may ask you to drill in on that function, but the key is to get valid code. Not necessarily complete code. (Obviously, YMMV.)
...and we've come full circle. The industry demonstrably brought this upon itself by cargo-culting Google's interview process; combine an environment where people are expected to know how to invert a BST for a Django or Rails job with a group of people who are naturally inclined to optimise and shortcut and this is exactly what you can expect to happen.
From a personal perspective, if I were to decide to switch jobs, I'd break out Cracking the Coding Interview rather than reading papers detailing how best to implement a Splay Tree because it's simply a better use of my time for the task at hand. I'll cheerfully read the latter on my own time, but not in preparation for an interview.
I don't see this culture changing anytime soon. 1) it's difficult to make an industry-wide shift and 2) more crucially, no-one has found a better way of doing it. It'll be interesting to watch though.
I interviewed at Microsoft in 1990 for a software test position and no one asked me a puzzle question so it had already gone out of style by then at least for my interviewers. They asked me a couple of questions that I recently recognized on the leetcode interview questions list in the easy section.
People don't have a choice but to game the system. If you can't solve the problem quickly enough on a whiteboard, you are rejected. You are typically not given enough time arrive the solution from a scratch. You either know the solution or you don't.
I agree with you, this method for interviewing sucks.
Do you care a great deal about that stuff because the job you're recruiting for legitimately needs it, or are you hiring people to crank out Rails/Django/React.js/etc. to add a few more textfields on a webpage? Because many people who are in the latter camp think they are in the former, and that's what got us to where we are.
There's nothing wrong with the latter, btw. Just that if your job is 90% copy pasting from the React docs and 10% coming up with a clever solution based on academic papers, then it's a much better use of your time to hire people who seem like they can get shit done and train & mentor them, rather than trying to hire the ultimate programmer who will ace your amazing question in exactly the time allotted, saying exactly what the interviewer wants to hear.
(the people who read academic papers over breakfast would much rather be at a job where the 90/10 split is the other way around, and will jump ship in the blink of an eye if they've been misled about the job)
I interviewed at some of these companies that liked the puzzles and so on. Then got to a company that actually seemed interested in stuff I've done before and asked enough details to know that I knew the stuff. I learned about what they did and seemed interested and got the job.
Puzzles and tricks are like that are a crutch, because people don't know how to talk and find out about what the other person knows.
Usually what happens if a company becomes successful is they codify whatever they did to get there in stone and that becomes "the golden process" by which everything must be one. If they hired people who knew how invert a binary tree or some stuff like that, they assume they become successful because of it. I would usually think they became successful in spite of it.
At the end of the day there are people who will sit and drill interview questions for months and years and maybe that's what companies want, people who are desperate enough to do that work. Maybe that's what the tests really test for ...
i actually have began to enjoy places that use these types of things for interview questions. it's a good way for me to know that i don't want to work there.
i once interviewed at a prominent company focusing on a certain language. they specifically stated in their job application that they just wanted motivated, enthusiastic, and smart people and that they didn't care if you knew said language. i sent them my resume with some recent code from my job since i had, within a few weeks, learned their language of choice on the job and on the fly for a project. it got their attention since it was decent code for someone new to the language. in the interview, they proceeded to quiz me on the language, including very specific details of how the language is implemented and things that don't even matter in day to day use of the language. and most of the stuff was something you could easily learn over a period of days or a week by just reading. it still boggles my mind. people, even very smart people, have no idea how to interview.
I don't know. I get your point and understand that language is just a tool, but having a vast code base in our company in C++ (for example), we have actively interviewed people who had experience in that language and were not just "smart", as we needed someone who could quickly get to work and we don't have to teach him inheritance and virtual functions from the beginning. Also, not sure about other languages, but efficient C++ code does take some experience IMO. So, personally I'd be willing to accept a good C++ programmer for a Java/C# programming job, but the opposite might not be an easy decision.
just as an elaboration, i was already an expert in another language. my primary skill is robust code and architecture, something that is completely missed by what i consider trivia questions.
although, i can understand if you have very specific needs for a language and need help asap. but i can also wager that people are missing out on some strong talent if they take too short term of a view. that is particularly applicable to potential employees from other fields. i was a mathematician turned software engineer and brought skills that no interview touched on. i just got initially lucky out of graduate school because of some connections.
and yea, i would consider c++ to be one of the most complex languages around, which is why i don't touch it. haha.
yes. The interview process is something out of the eighteenth century. It's just funny that with all the data collection and testing capabilities we have developed, we can't figure out how to create creative interviewing processes that target specific needs. I think it points more to the employers often not understanding what specific candidte qualities would actually make their team stronger. Sometimes, it's the glue that is most needed, and no one has figured out how to test for glue or morale optimization. These would be helpful target areas. They need to look at why certain world-class sports teams and arts organizations are so successful at what they do. A lot of this has to do with heart and morale. This process drains such qualities from candidates over surprisingly short periods of time.
I recently added data structure visualization to a gdb frontend called gdbgui, which might be of interest to people trying to debug their algorithms. https://github.com/cs01/gdbgui
I once walked into an interview with such questions. On the first question I asked them why they asked the question. The interviewer looked puzzled and asked me to finish the question. I again asked him why, what part of my job would require it. He couldn't answer that question whilst he was an engineer at the department I was interviewed for. I asked a follow-up question if he had the same questions when he joined, and if he ever felt the need for that knowledge particularly. He responded it was good to know, companies like Google and Amazon did the same. I walked out five minutes later thanking them for their time. I could have answered the question easily but what for?
In the off chance that someone stumbles along and blindly copies this into interview questions for his company. Think again, realize what your company needs and tailor your recruiting process for that instead of copying stuff others do.
> I could have answered the question easily but what for?
To show that you're not a complete diva who's willing to put in some work even if it's unpleasant?
The question I ask is not real, either. It's entirely contrived. But I ask it because it's the best way I know to identify candidates who:
1. Can think critically about a data structure.
2. Can communicate with me about how to solve non-trivial problems.
3. Can translate an idea into code without thinking about it too hard.
Given lots of time there are much better ways to test a engineer for these attributes. Given an hour it's about the best I can do. That's not to say everyone who asks these types of questions does it well (I think there's a fair bit of cargo-culting around "The Google Interview") but if you're unwilling to even humour me I think walking out is the best response for both parties.
Non-trivial is a subjective thing though. I see people asking the edit-distance problem for example, that was an award winning research paper a few years ago! Also, how do you differentiate between candidates who've seen your question before vs others seeing it for the first time? Most interviewers calibrate on one question. I think the scales these days have tipped on the side of luck. If you've practiced a shit ton of questions and you're asked one of them or closely resembling them, you're golden. Otherwise, you're screwed! I know of several current Googlers who'd attest to this.
In addition to that, it's entirely possible that the candidate is tired after 5 rounds of interviews and isn't able to think straight. But you're right, I don't think a better alternative exists yet.
Don't forget companies the size and status of Google run these questions to quickly reduce the number of applicants. They accept a large number of false negatives in favor of a false positive. They have that luxury but if you don't realize you loose a lot of good candidates because of it.
Also, I think the better alternative is to ask questions you currently struggle with in your daily work. Just ask around in your department(s). There are always good interview questions to be answered that are close to today's issues.
First, if he would have given that answer instead of saying others did it I would have answered the question. However, his answer indicated they asked just because of asking.
Second, even when you have those reasons ask questions on actual situations that would occur on the job. You run a large C# code base that struggles with its size and configuration complexity vs flexibility? Ask questions on how he would design a new speculative module for the Platform. What kind of pitfalls would he foresee? What would he focus on? See if his answer include your struggles indicating he understands what his daily job is about. If you search an engineer to speed up your image processing pipeline which is C++, data structures can be fine but don't forget that before optimizing them you probably have to spend a lot of time optimizing the design of the entire pipeline so also ask questions about that part.
My main advice is think before you ask. If you have valid reasons, feel free to ask data structures. If you don't, think again.
I think that's putting the cart before the horse. Every company I've worked for has had a hard enough time just finding people with basic coding literacy. Finding somebody with good problem solving, communication, and programming skills is the hard part -- wondering if that person is the guy to architect a specific aspect of our platform is secondary. I can't speak for that job in particular but if half of your promising-looking candidates are getting weeded out by simple programming puzzles the bar tends to shift.
It was meant as an example. If I would interview for an architect I would probably ask such a thing as I need to know if s/he would be capable of thinking ahead and outside of the direct requirements.
For an engineer I would ask different questions. However, if I interview them for a job that does not focus on performance or scalability I would rather ask questions based on situations they run into than data structures. Data structures would be a last resort if I had no other options for questions. For most knowing when to use a certain data type is sufficient for me. Like math, I don't need them to give me the full proof of the theorem as long as they know it exists and can apply it in their daily work.
That doesn't mean I wouldn't like a candidate who has it all of course. But those are scarce here, and probably everywhere as you mentioned. I am already happy with a person who can do the job s/he was hired for and hopefully more.
Again, if you have valid reasons to ask what you ask, do. If not, think again if there are better alternatives is all I advocate.
Skilled enough to do what exactly? Answer data structure questions? This is my point. Are the question relevant to the job and does their answer qualify them for it?
I always wonder about genius developers who throw fit when someone asks them to implement linked list (the actual chapter in the linked article). I understand the complaint when people get asked to balance red black trees out of nowhere or something else more complicated, but this article is very basic.
Yeah, this can be memorized pretty easily, but "lets talk about how passionate you are" which is invariably suggested as alternative is even easier to fake for people with good social skills and charisma (and puts actual minority of real geeks at disadvantage).
The only reasonable, real-world solution to the linked list question is "How many bids do you need for me to collect for licensing the third-party code library? Three? It's usually at least three. I'll look at Infragistics, JetBrains, and anything I can find that's open source, and get back to you by COB. Are there any specific features that the linked list has to have? Any deal breakers? Do we need official support, or is community forum support enough?"
You ask me to do a linked list--in 2017--and I'll have to start determining whether that smell is "Not Invented Here" or "Cargo Cult". How many languages don't have such lists as part of their standard libraries now (or at least part of a common libre-license or gratis-license library)?
But no... I'll just continue to answer the question as though my CS prof is grading me on it, and just convert my concerns into salary expectations for the negotiations phase. Any company that asks such questions is obviously bad at gauging real technical skill, therefore I should ask for way more money than I think I am worth, and invest all of my limited acting skill into believing that number. They are relying on me to tell them how good I am, so I will game the system, cram for their stupid questions, and tell them I am the absolute best.
Then I can spend all my working hours copy-pasting the answers to already-solved problems from the Internet.
The real genius developers are spending their free time helping lesser developers on Stack Exchange/Overflow for free, because the companies that hired them have no idea how to make use of that level of expertise, and that's the only way they ever get to encounter any fun or interesting problems to solve.
I guess I'll amend my previous statement. I need to discern between "Not Invented Here", "Cargo Cult", and "Power-Abusing Management". You won't be able to tell by asking me. I know linked lists forward and backward--though the backward part really only concerns doubly-linked lists. I won't stop judging you for asking the question, but I will answer it. It will then provoke automatic follow-up questions about how much you rely on first-party and third-party code libraries, and about which kinds of open source licenses your company finds acceptable for use with their products.
Interviewing is a two-way street. If you ask questions more relevant to academics than real-world employment, I will try to figure out whether the pay your company offers is worth dealing with the apparent dysfunction in it. I can deal with almost anything if you pay me enough.
Your presumption is that the ability to answer linked list questions in an interview gracefully is positively correlated with future job performance.
The burden of proof is on the person making the assertion. The only way I can see evidence for it is if people ask those questions in the interview and make note of the response, but do not use it for the hiring decision. Then, in the future, after the worth of the employee is measurable, correlate it with the answers to the experimental questions.
As far as I am aware, no company asks experimental interview questions that do not impact the hiring decision, in large numbers and for years at a time, just to gauge the merit of those questions before adopting them into the interview process. It is far more common for someone to decide on a theoretical basis that a question has real discriminating power without any real evidence, or to stop asking a particular type of question and then maybe compare employee populations a few years later.
Thanks for doing this. As an interviewer I like to be transparent about my interviews and explain to the candidates what I expect in the answer/code before going ahead with the question.
I've had the same thought - if I actually did the interview-type algorithms and multi-system scalability challenges on a day-to-day basis, it might just be a super cool job.
If you can't explain it simply, you don't understand it well enough. All these CS Degree wizards and gatekeepers need to come out of their ivory towers.
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 can produce something useful.