Data Structures for Coding Interviews
interviewcake.com
interviewcake.com
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.
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.
</rant>
- 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.
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.
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 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.
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.
(I used to be that young person and used to pass on opportunities because of superficial reasons like that.)
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.
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.
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?
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.
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.
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.)
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.
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).
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.
Also, I'm quite sure someone could easily come up with comments just as arrogant as yours, about you.
When I saw "Data Structures" for interviews, I didn't think it would be explaining binary to us.
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 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.
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.
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.
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.
- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Thus, the other article on the front page about the staggering space requirements for phone apps.
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.
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.
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.
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.
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 personally don't agree with this reasoning, but that's how businesses operate.
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.
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.
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.
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.
Judging from observation, people become seniors after being employed for about four months (including part time period).
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.
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.
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).
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.)
1 0000 0000 = 256
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.
> 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)!
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.
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?
We had it in one of those gray boxes in an earlier draft (so you didn't have to click anything to see it). We'll probably move it back out.
It's one of the few dead-tree books I ended up buying this year, albeit after perusing a library copy.
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
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.
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.
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.
Target audience is folks who never learned this stuff, or learned it but forgot it. Interesting to hear you had a different assumption from the title.
If you want something trickier, check these ones out:
https://www.interviewcake.com/question/stock-price
https://www.interviewcake.com/question/swift/find-duplicate-...
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.
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.
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??
And eager to receive any feedback.
Thanks for the post!
Ok, time to rethink the email opt-ins.
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.
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?
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!
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.
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.
Indeed; this is a point I make over and over. HR departments aren't smart enough to detect ageism being openly practiced right under their noses...
Looks like Kaplan is not going to be interested in these things after the recent shutdown of DBC.
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.
Best of luck to you!
We're really focused on trying to "twist the knobs" only up to the point right /before/ it starts getting annoying.
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.
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.
For mock interviews, definitely check out:
- http://www.byte-by-byte.com/practice-coding-interviews/
- http://interviewkickstart.com/ (email 'em to ask about mock interviews over Skype)
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.
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.
Now this is all my own experience, and others may disagree, so don't necessarily go changing things just on my account!
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".
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.
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?
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.
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.
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.
Not every company is a startup.
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.
Exactly this. A company making microscopes probably doesn't need to hire biology PhDs, and wouldn't ask obscure biotrivia in an interview...
https://medium.freecodecamp.org/welcome-to-the-software-inte...
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.
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.
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
def revtree(node):
if not node: return None
node.left, node.right = revtree(node.right), revtree(node.left)
return node
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.
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).
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?
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.)
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.
Some people definitely do hiring in different ways.
Time will tell if they're actually better.
I agree with you, this method for interviewing sucks.
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)
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 ...
What...
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.
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.
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.
Thanks.
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.
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.
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.
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.
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.
They need to know if you are skilled enough, and this is the quickest way to find that info out.
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).
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.
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.
You've never had to choose between an array and a list?