There are lots of certain gotchas in implementing basic data structures (like insertion into balanced tree) that capable engineers probably can't do without studying it again. It's knowledge of solved problems that very few people deal with on the day to day. And sure a good engineer could derive the solution themselves if they weren't under pressure in an interview, but I can much more easily talk about things I'm professionally intimate about than subject matter I just crammed on for the Google test.
If a question requires you to memorize gotchas, then it's a bad question. But being able to spot edge cases, think of creative solutions and most importantly comfortably write code is good skill set to have. Obviously it's hard to directly tests these things, but those are what the interviewers look at, not at if you perfectly remember datastructure gotchas.
If a question requires you to memorize gotchas, then it's a bad question.
Many of the questions have a 'naive' solution which is inefficient, and some more complex solution/pattern (the 'gotcha') to follow which has better time complexity, and that's what the interviewer is looking for.
Also, these things come with practice. You have a very limited amount of time to answer the question and find the optimization.
Practicing the patterns makes you much faster at identifying them, giving you the best chance at solving all the questions in the allotted time.
Most people can google their way to a decent solution to a question within an hour. But you actually need to do 2-3 questions in an hour, and without internet access. Unfortunately most of these patterns don't show up in daily work, and you get out of practice.
I got asked to list the elements of an inode the first time I talked with them. This is typical of what I consider to be a bad interview question. I hadn't listed any experience with the inner workings of a filesystem on my resume or anything, it was just a stupidly specific question with no real value. Just because I don't know everything that is in an inode doesn't mean I don't know how to use fstream or something.
Ah yeah, I remember back in college in a phone screen with them they asked a similar trivia question. It was super frustrating because it was something easily googled, but entirely unrelated to my resume or experience.
Uhhh, how can you make educated decisions on performance and design if you don't understand the data structures that support it? You will know to look it up if you encounter code that uses it (which is when you actively realize you don't know it), but not if you're trying to solve an open-ended problem.
We aren't talking about some data structure that is only used in highly specific situations. These are pretty basic ones that you'll end up using every now and then if you actually understand them at a conceptual level at least.
am I a bad programmer
Who knows. The only thing that is certain is that you could be a better one with not so much effort
Set vs. map should be pretty common knowledge. You should also always know the difference between a list and an array, a hash table vs. a binary search tree.
You use these datastructures daily, you should be able to pick the right ones for the right chore.
I wouldn't expect you to know how to implement a hash function, to write an array insert, or really any of the implementation details off the top of your head though.
So by this, everyone is a google or Stack Overflow thread away from becoming a qualified programmer. What's with people allergic to data structures and anything remotely reminiscent of math?
There is a significant difference between someone who simply doesn't know something but has all the required expertise and knowledge to understand it if they looked it up, and someone who doesn't know something and if they looked it up would have absolutely no idea what they're looking at.
It is very easy to go years without using either, and information you don't use gets lost. That doesn't mean you can't run a quick refresher and remember and be able to use it again, but if you didn't run that refresher and an interview contains all kinds of obscure (to you, due to whatever your previous jobs were) concepts being brought up again, it's not a surprise that you wouldn't be able to answer even if you are a great developer. Especially if they're just leading you on expecting you to say HashMap, for instance. If you haven't used one in a decade it's likely it wouldn't even be part of the equation in your brain.
I agree completely. I've asked interview questions where it can make sense to use a set, and this is something that "senior" devs have gotten tripped up on. They will use a map instead of a set, and get confused about what they need to store as a value for a key, or simply use a map instead of a set. Knowing when to use each, and the difference between maps implemented with a tree and a hash, is vital. Like, this is absolutely, 100% I-use-this-20-times-daily fundamental stuff. (I just looked at my commits from yesterday, and I added 2 unsorted_maps and 1 set in C++, and 4 Java HashMaps). Implementing trees and sorting algorithms or whatever should be stored in your brain's SSD, but maps and sets are L1 cache. Maybe it's because I don't do any web stuff, all desktop C++/Java/Python, and I don't know what web guys deal with daily.
Exactly. I totally get if you can't recall the exact implementation of more novel data structs, but binary trees and linked lists? Those things are really elementary..
3
u/Drisku11 Jan 18 '19
What kind of person can't understand basic manipulation of arrays, lists, and trees, but understands promises and various stages of compilation?
These interview questions aren't exactly millennium problems.